Jump to content
  • Advertisement
Sign in to follow this  
deadlydog

Gimme your game engines

This topic is 5272 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quote:
Original post by averisk

A course in game programming? Damn, that is sweet. The closest we get up here at the UofS (saskatoon) is graphics. Though I imagine It's pretty close...
Assignments to make ray tracers, NPR, etc. but no mention of games :(

Quote:
Original post by deadlydog
Another question. Is the Quake 2 engine just for graphics, or is it an entire game engine?


It's definately a game engine. How else do you think Quake 2 was made? ;)
Good luck with the project


I dunno. Using the Quake engine for graphics and other simpler engines for the input, sound, and networking maybe. So it is a full game engine though. Good to know. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Now I've got a list of different engines, and for part of the report I am supposed to list some of the different pros and cons of each engine, and what would convince you to pick one over the other. The problem with this is that I haven't used most of these engines before, so I'm not sure how they stack up against one another. Here's my list of engines:

All-in-one engines:
- Tricks of the Windows Game Programming Gurus (free with book)
- Programming RPG’s with DirectX (free with book)
- Quake 2 engine (open source, free)
- Torque (pay $100, Cross Platform)
- Cipher (pay $100)

Just Graphics (and input) engines:
- RenderWare (pay)
- Ogre (open source, free)
- Crystal Space 3D (Cross Platform, free)

- ZIG (Networking only) (free)
- FMOD (Sound only) – very fast, supports most audio types (free for hobbyists, pay for commercial use)

Now I've already been to the websites for all of these, and they do list some of the main extra features of these, but I'm looking for responses from people who have actually used them before. What did you like about it, what didn't you like (example: global function calls vs classes), what were some of the main "selling" features of it, how did it compare to others you've used. That sort of thing. And yes I know that being free is a big "selling" feature, so what would be some reasons you would pay to use the other not free ones? Thanks everyone.

-- Oh, and in my report I will be stating that I didn't have time to actually test and use all of them myself, so I used opinions from people that have.

Share this post


Link to post
Share on other sites
FMOD is still an API and _not_ an "engine" like OGRE is a rendering engine.

My suggestion is that you compile a list of questions and hand em around instead of just "ok everyone, spill your guts"
that also makes it easier to compare answers.

Share this post


Link to post
Share on other sites
I feel it's probably worth stating you're unlikely to find any input engines because there is no reason for them to exist on their own - nobody really writes an app where you just get press keys or something, heh.

Also, from my experience there is nothing particularly complex about writing an input engine, it's a day, maybe two's job if you've got the skills and when you've done it once, it's pretty much the same from then out - I seem to recall John Carmack saying that he finds graphics the interesting part because it evolves, and input is terribly boring because he's basically written it the same way for the past 6 engines or whatever ;)

That said, if you really want I'll zip up the pertinent files from my programs and give you an 'input engine' so to speak (if you really want).

-Mezz

Share this post


Link to post
Share on other sites
Yes, I understand that there are not independent input engines. Someone mentioned that a few posts ago. But are there any "sound engines" out there, since FMOD is just an API...although I don't really see what else would be needed for sound besides the basic API calls like Play, Volume, Pan, etc, but I don't know. Thanks everyone.

Thanks Mezz for the offer of making me an input engine, but I can just use the one's I've gotten from my Tricks and Programming RPG's books.

[Edited by - deadlydog on June 3, 2005 6:06:13 PM]

Share this post


Link to post
Share on other sites
Yes like I said, I also don't see the reason for a "input engine". Although now that you mention it. I wouldn't mind a small lightweight input handler that comes with a event / callback system to bind keys to functions. Pretty nifty when making small demos I guess :)

Also input seems more bound to the OS than graphics and audio which are actual hardware cards. I mean, all libraries that allow you to create a window also has input handling. SDL, GLUT, etc.

An API should give you all the necessary functions to do everything that the hardware can do. Why would anybody buy a card like this if the only functions on it are play/pause/stop? So you see, there's quite alot that can be done with modern audio cards. But when using it in your game then you only want simple functions, that's why you wrap it up in an "engine" (I actually prefer to call them "cores" just like the RPG book you have does).

Share this post


Link to post
Share on other sites
Am I correct on assuming the Quake 2 engine would really only be good for making FPS games, or could it be used to make any type of game, such as RPG, Adventure, Fighting, etc? Thanks.

Share this post


Link to post
Share on other sites
Since you have to source code to it you can do whatever you want with it. the engine as it is is made for FPS but I think you could fix the camera somewhere to get isometric projection very easily, as well as making a "over the shoulders" camera like in many 3rd person action games. The game logic for RPG, RTS, etc. I think speak for themselves, they're not part of the Q2 engine but as I said, since you have to source you can add it in.

Most game engines are focused to one type of game, most typically FPS since they practicly all work the same and doesn't have much actual "game specific code" compared to other game types.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!