What all is required for a working game engine?
Author
Ah, thanks for that info. I knew there were some basic parts required for a good engine, and didn't know them exactly. Now that you mention, I remember something like those being mentioned in a book a bought. I'm gonna start looking for it. Once again, thanks.
They might be under a different name, since I just thought those up (it makes perfect sense in my head at least).
Ok here's my shot at this. There are only three things you need for a working game engine. Those are graphics, sound, and input.
Graphics:
One of the main aspects to games nowadays, and for big reasons too. It is essential to have some system of being able to draw objects to the screen in a manner that is fast and efficient. It should support a lot of hardware and software features if you are going to do 3D as well as be able to run on older machines to a certain degree of not killing your audience base. I.e. support people with a 32+MB video card, but don't require them to have some 256+MB card.
Your graphics engine should be able to handle a variety of formats, or you will suffer later on when trying to add content to your game. No one appreciates a graphics engine that they have no choices on what they can use to model their stuff with, unless it is top notch (3dsmax and Maya quality) and you give it to them for free. Best bet is have something that the main package users can work with. These are 3dsmax, Maya, and LightWave. Blender is a must as well sa Milkshape since they are free and low cost, respectively.
Ideally your graphics engine should be graphics api neutral. What I mean is that you are doing everything abstractly and not to one specific API. By doing this, you will end up making your engine more versitile and let people worry about the important stuff rather than how to do what in each language. Yes, that is more work on your part, but in the end it is worth it. If that is not possible at least take care of wrapping everything up so the end user has a more high level api to work with rather than the core API of your language of choice.
Sound:
We are in the 21st century. If your game doesn't have sound, well good luck. Sound is one of the often overlooked, pardon the pun, aspect of games. I mean you want to have something that does not take away for your game, but you don't want it being the main feature of it either. In your engine you should have something that wraps up all the dirty low level stuff.
Ideally, IMO, you want something that the end user can easily work with and have no troubles. The way I did mine was more along the lines of one function wonders. One function to initialze, one function to load anything, then the respective functions to play, pause, stop, modify settings, etc... If you decide to use DirectSound or DirectMusic, you'd better wrap it all up! Make the end user do as less work as possible. Which leads us to..
As to what you want to use for your API there are few options. FMOD is popular because it's easy as pie to get working and use. However that does come at quite a cost, so you might want a free solution, such as OpenAL or Audiere. The decision is your though, try to keep in mind that many people might want to be able to plug in other stuff, so making it flexible, while challengine, makes it more promising.
Input:
Ahh the glorious input. Without your game is just a movie, more or less. There is not much here to consider, either Win32 for your game (big no-no) or DirectInput. DI is the best thing to use, hands down. It has support for a whole bunch of devices as well as force feedback support. Unless you are using something such as SDL, which does have its own input, DI is your onestop solution. Well there are other things such as GLFW that has its own input, but for a serious game, I think DI is your best bet really. If there is only one thing from DX that you have to use, it should be DI.
Once you have all three of those, then I mean that can be all tossed together and you can make a game with it. But there is so much more to engines! That is just the bare skeleton requirements. Physics is a must for 3D games and perhaps some 2D games. While you do not have to get a lbirary, you should at least have your own simple stuff. So in response to your first post on the stuff here's mine:
Graphics: Ogre3D
Sound: OpenAL
Physics: ODE
Input: Direct Input
As for everythign else, not there yet, but a few things are the scripting, resource management, saving systems, and I can go on and on, but the main point is that its more of a 'what you need' kind of thing. I'd say if you make your engine use plugins, so people can add whatever the heck they want and can use it, then you are all set!
So heed the advice of the wise that have said to take a look at other engines, there is another recent thread about this topic as well. Each engine does sutff a it different and can give you lots of neat ideas. Take a look at that XML thread too, it has some neat ideas for game engines as well. Good luck!
Graphics:
One of the main aspects to games nowadays, and for big reasons too. It is essential to have some system of being able to draw objects to the screen in a manner that is fast and efficient. It should support a lot of hardware and software features if you are going to do 3D as well as be able to run on older machines to a certain degree of not killing your audience base. I.e. support people with a 32+MB video card, but don't require them to have some 256+MB card.
Your graphics engine should be able to handle a variety of formats, or you will suffer later on when trying to add content to your game. No one appreciates a graphics engine that they have no choices on what they can use to model their stuff with, unless it is top notch (3dsmax and Maya quality) and you give it to them for free. Best bet is have something that the main package users can work with. These are 3dsmax, Maya, and LightWave. Blender is a must as well sa Milkshape since they are free and low cost, respectively.
Ideally your graphics engine should be graphics api neutral. What I mean is that you are doing everything abstractly and not to one specific API. By doing this, you will end up making your engine more versitile and let people worry about the important stuff rather than how to do what in each language. Yes, that is more work on your part, but in the end it is worth it. If that is not possible at least take care of wrapping everything up so the end user has a more high level api to work with rather than the core API of your language of choice.
Sound:
We are in the 21st century. If your game doesn't have sound, well good luck. Sound is one of the often overlooked, pardon the pun, aspect of games. I mean you want to have something that does not take away for your game, but you don't want it being the main feature of it either. In your engine you should have something that wraps up all the dirty low level stuff.
Ideally, IMO, you want something that the end user can easily work with and have no troubles. The way I did mine was more along the lines of one function wonders. One function to initialze, one function to load anything, then the respective functions to play, pause, stop, modify settings, etc... If you decide to use DirectSound or DirectMusic, you'd better wrap it all up! Make the end user do as less work as possible. Which leads us to..
As to what you want to use for your API there are few options. FMOD is popular because it's easy as pie to get working and use. However that does come at quite a cost, so you might want a free solution, such as OpenAL or Audiere. The decision is your though, try to keep in mind that many people might want to be able to plug in other stuff, so making it flexible, while challengine, makes it more promising.
Input:
Ahh the glorious input. Without your game is just a movie, more or less. There is not much here to consider, either Win32 for your game (big no-no) or DirectInput. DI is the best thing to use, hands down. It has support for a whole bunch of devices as well as force feedback support. Unless you are using something such as SDL, which does have its own input, DI is your onestop solution. Well there are other things such as GLFW that has its own input, but for a serious game, I think DI is your best bet really. If there is only one thing from DX that you have to use, it should be DI.
Once you have all three of those, then I mean that can be all tossed together and you can make a game with it. But there is so much more to engines! That is just the bare skeleton requirements. Physics is a must for 3D games and perhaps some 2D games. While you do not have to get a lbirary, you should at least have your own simple stuff. So in response to your first post on the stuff here's mine:
Graphics: Ogre3D
Sound: OpenAL
Physics: ODE
Input: Direct Input
As for everythign else, not there yet, but a few things are the scripting, resource management, saving systems, and I can go on and on, but the main point is that its more of a 'what you need' kind of thing. I'd say if you make your engine use plugins, so people can add whatever the heck they want and can use it, then you are all set!
So heed the advice of the wise that have said to take a look at other engines, there is another recent thread about this topic as well. Each engine does sutff a it different and can give you lots of neat ideas. Take a look at that XML thread too, it has some neat ideas for game engines as well. Good luck!
My requirements are a little different. But it depends on the quality and if the engine is to be genre specific or general. I think a good high quality engine should have physics but a lower level one won't. Also, I think the best engines for the job will be ones made for the purpose, like the quake lineup. They are close to the best for FPS games, but they don't work too well for RPGs or RTSs. Any general engine that works with all genres will probably be slower, less quality, but work in variety.
Author
Thanks for the great replies.
@Drew: That was very informative. Thank you so much for the precise description of each neccessity, and even the extra tidbits. You're a lifesaver man.
@Kburk: I'm planning on making the engine pretty specific, for thirdperson action games. It's specifically going to be the engine for my stealth game. I'm just planning on releasing the GDK I form out of the libraries when I'm finished.
On a side note: I know stealth games should never be made by beginners in c++, but I love them, and I've used some other languages before. I'm going to make sure I know the engine well, and then start work on it. I think the reason I'm wanting to make it so bad is because of how much I love the source material for game.
Once again, thanks for the replies.
[edit]I just noticed SxDL. I saw that it also uses DX 9.0b. Any chance that this is a decent framework? What about it's actual power?
[Edited by - tg_matt on May 16, 2005 9:57:30 PM]
@Drew: That was very informative. Thank you so much for the precise description of each neccessity, and even the extra tidbits. You're a lifesaver man.
@Kburk: I'm planning on making the engine pretty specific, for thirdperson action games. It's specifically going to be the engine for my stealth game. I'm just planning on releasing the GDK I form out of the libraries when I'm finished.
On a side note: I know stealth games should never be made by beginners in c++, but I love them, and I've used some other languages before. I'm going to make sure I know the engine well, and then start work on it. I think the reason I'm wanting to make it so bad is because of how much I love the source material for game.
Once again, thanks for the replies.
[edit]I just noticed SxDL. I saw that it also uses DX 9.0b. Any chance that this is a decent framework? What about it's actual power?
[Edited by - tg_matt on May 16, 2005 9:57:30 PM]
Quote:Original post by tg_matt[edit]I just noticed SxDL. I saw that it also uses DX 9.0b. Any chance that this is a decent framework? What about it's actual power?
If your project is Windows-only, you might look into it. SDL apparently only uses software blitting, and is painfully slow. On the other hand (if you are working on a 2D game), you could write OpenGL sprite routines like I have, which are painfully fast!
Author
Once again thanks. I'll probably leave SxDL alone, in that case. Another awesome and informative post drew. Interesting stuff.
edit: I guess i'm trying to get famous for side notes, because here comes another one.
What about DevLib. It looks neat, but I'm not sure about it's graphics rendering. Any info on it?
Also, the other day, I thought about modifying the quake engine. I considered learning something like DirectX 9 or OpenGL to implement modern features such as higher polygon counts and bumpmapping. It wouldn't be to the core rendering, I'd leave that as a fallback path for old hardware, but do you guys think it'd even be worth the effort. It is a really old engine.... Maybe I should wait until the q3 engine is released to try something like that. Oh well.
[Edited by - tg_matt on May 17, 2005 5:24:22 PM]
edit: I guess i'm trying to get famous for side notes, because here comes another one.
What about DevLib. It looks neat, but I'm not sure about it's graphics rendering. Any info on it?
Also, the other day, I thought about modifying the quake engine. I considered learning something like DirectX 9 or OpenGL to implement modern features such as higher polygon counts and bumpmapping. It wouldn't be to the core rendering, I'd leave that as a fallback path for old hardware, but do you guys think it'd even be worth the effort. It is a really old engine.... Maybe I should wait until the q3 engine is released to try something like that. Oh well.
[Edited by - tg_matt on May 17, 2005 5:24:22 PM]
My recommendation is to use either OpenGL or DirectX if your looking at 3d. A good engine will have both and the rendering will be unknown to the user of the engine, thoug the user may be able to request one or the other. The engine usually decides which to use. I know torque works like this and there are a few others. You could also just use one or the other, which would make for easier programming of the engine itself. If this is for a 3rd person view game like you said, then I recommend you get pretty specific with the details. Program the camera to automatically follow the "player" object from within the engine. If you have weapons, program that into the engine, though make it where you can choose what they are externally. Point is, as the engine is for a specific genre/game, you can get down and dirty with low level stuff so that the programmer who uses the engine gets the work done faster. With a multi-genre engine, this is not possible.
Author
Yeah, I'm planning on it being rather specific. The plan is to set the engine or GDK for my own game and then release a somewhat less specific version when the game is complete, or at least a good % done. I'm looking pretty closely at openGL right now. Then again, Direct X is still really good. Oh decisions, decisions. Btw, if I'm not mistaken, The Nebula Device 2 is a full game engine right? Lacking a few minor parts probably, but it seems as though it's a full engine according to the site.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement