- Forum
- General C++ Programming
- Game engine structure
Game engine structure
Hello!
I'm currently writing a small game and have hit a little snag with the structuring of my engine, and was hoping someone here could give me a few pointers. I realize this is probably a pretty broad question, but if someone could point me in the right direction and perhaps provide some links that would be most kind.
This is what I have so far: the engine consists of a main class which handles all the basics such as setting up directx and implements classes which handle things like input and resource management.
When I started on this project all I wanted was to successfully render some objects on the screen and provide a camera that you can move around using the keyboard and mouse, so I didn't really bother to structure my code all that well. Now that I've gotten that far, I'm trying to improve upon my structure before venturing further.
Basically what I need is some way for the different parts of my engine to interact with eachother without having to place all the code in one location. For example, when there's input I'd like the input class to modify the camera object. Currently the input class only keeps track of what keys are being pressed at the moment, and then the main class updates the camera object before each render call depending on what keys are being pressed.
So, does anyone know of any good techniques to deal with this? The one thing I could think of was passing around pointers to all the objects that a class would need to perform operations on, but I'm not sure if that's such a good idea since that might end up being a hell of a lot of pointers. For example pressing one key might move a hundred soldiers across the battlefield, meaning the input class has to tell all those soldier objects to move forward.
I've tried googling this and didn't find much. Wasn't really sure what to search for to be honest. Anyways, any help at all would be very much appreciated.
I'm currently writing a small game and have hit a little snag with the structuring of my engine, and was hoping someone here could give me a few pointers. I realize this is probably a pretty broad question, but if someone could point me in the right direction and perhaps provide some links that would be most kind.
This is what I have so far: the engine consists of a main class which handles all the basics such as setting up directx and implements classes which handle things like input and resource management.
When I started on this project all I wanted was to successfully render some objects on the screen and provide a camera that you can move around using the keyboard and mouse, so I didn't really bother to structure my code all that well. Now that I've gotten that far, I'm trying to improve upon my structure before venturing further.
Basically what I need is some way for the different parts of my engine to interact with eachother without having to place all the code in one location. For example, when there's input I'd like the input class to modify the camera object. Currently the input class only keeps track of what keys are being pressed at the moment, and then the main class updates the camera object before each render call depending on what keys are being pressed.
So, does anyone know of any good techniques to deal with this? The one thing I could think of was passing around pointers to all the objects that a class would need to perform operations on, but I'm not sure if that's such a good idea since that might end up being a hell of a lot of pointers. For example pressing one key might move a hundred soldiers across the battlefield, meaning the input class has to tell all those soldier objects to move forward.
I've tried googling this and didn't find much. Wasn't really sure what to search for to be honest. Anyways, any help at all would be very much appreciated.
The game engine that I'm making is loosely based off of Game Maker's system.
http://www.mediafire.com/?ruqde57y7vqy21n
I was explaining it in much more detail, but my browser had a brain fart and deleted everything. Now I'll answer specific questions about it.
http://www.mediafire.com/?ruqde57y7vqy21n
I was explaining it in much more detail, but my browser had a brain fart and deleted everything. Now I'll answer specific questions about it.
I wouldn't be surprised if I got shouted by several forum users here, but since I tend to use singletons quite a lot, a lot of people detest them though. Try googling the singleton pattern, what it does basically is makes one and only one instance of your singleton class which is accessible from anywhere, completely annihilating black boxing.
If it's a small project, there's no harm in it surely =P
If it's a small project, there's no harm in it surely =P
Last edited on
Only use singletons for something you're sure you only want one of.
A "Player" class as a singleton is a terrible choice, because you might want multiple players (via a network, or just side-by-side).
Even a "Game" class as a singleton is a bad choice because you might want multiple games running concurrently (that sounds weird, but think if you have a rewind system or movie playback system -- then it might be useful)
On the other hand a resource manager would be a good use of a singleton because even if you have multiple games running, you would always want all of them to share the same resources.
So yeah, Singletons have thier use, but they're largely abused. They're basically globals with different syntax, and globals are [mostly] evil.
A "Player" class as a singleton is a terrible choice, because you might want multiple players (via a network, or just side-by-side).
Even a "Game" class as a singleton is a bad choice because you might want multiple games running concurrently (that sounds weird, but think if you have a rewind system or movie playback system -- then it might be useful)
On the other hand a resource manager would be a good use of a singleton because even if you have multiple games running, you would always want all of them to share the same resources.
So yeah, Singletons have thier use, but they're largely abused. They're basically globals with different syntax, and globals are [mostly] evil.
Last edited on
PiMaster:
Hehe, sucks when that happens. I'll have a look at your code when I have some time over. Thanks alot :)
Quirky:
I think I'll want to avoid doing that, since I'm probably going to keep adding stuff to the game as I learn more. I want to keep a good solid structure that i can expand upon whenever i want to. Thanks for the tip though, it seems they might be useful for some parts of the game like Disch said.
I guess my problem arises from wanting to keep things separated into different classes. If i just wrote everything smack into the same scope i wouldn't have a problem. But then the code would be impossible to work with.
Isn't there some general technique that's used in the case where different objects needs to access eachother?
Hehe, sucks when that happens. I'll have a look at your code when I have some time over. Thanks alot :)
Quirky:
I think I'll want to avoid doing that, since I'm probably going to keep adding stuff to the game as I learn more. I want to keep a good solid structure that i can expand upon whenever i want to. Thanks for the tip though, it seems they might be useful for some parts of the game like Disch said.
I guess my problem arises from wanting to keep things separated into different classes. If i just wrote everything smack into the same scope i wouldn't have a problem. But then the code would be impossible to work with.
Isn't there some general technique that's used in the case where different objects needs to access eachother?
| Isn't there some general technique that's used in the case where different objects needs to access eachother? |
Program design is tricky. It's much trickier than actually writing the code.
There is no general rule for a good design. The needs of every program just varies too much.
The best advice/rules I can give is:
1) Work out what you want your classes to be. Classes should represent clear "things", should be logical and intuitive. For example you might want a Player class, Enemy class, maybe a Map class, etc, etc.
2) Work out how the classes work together. For example a Player would need to communicate with Map in order to be able to interact with the environment (no walking through walls, etc)
3) Try to keep interactions 1-way whenever possible. Player may need to know about Map, but Map shouldn't need to know about Player. Two-way communication between classes is a huge source of maintanance issues -- it often leads to situations where if you have to change one thing over here, you have to change something else over there (and
4) Abstract to recycle code where logical/practical. For example Enemies and Players will both need to interact with the Map, but it doesn't make sense to write separate interaction code for both. Maybe make a MapObject class and derive Player and Enemy from it. Then MapObject can work with Map, then players and enemies don't have to worry about it.
5) Design first, code later. Don't dive right into code. Sit down and think about all of the above. Get an idea of how it's going to work before you start writing a single line. I can say from experience that "slap it together as you go" programs are doomed to either wretched obfuscation, or even complete failure.
This may be a bit advanced for you, but I recommend you grab a copy of Game Engine Architecture http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135. Great book on engine subsystems and design.
Disch:
Thanks for all the tips. I'm starting to realize now how important it is to plan out your code before starting to write it. I've already begun drawing some diagrams ;)
Return 0:
I had actually been meaning to buy that book for a while now. It was on the recommended books list at toymaker.info whose tutorials i've been following.
I believe i have found just what i was looking for though. http://gpwiki.org/index.php/Programming_Techniques lists the Observer Pattern. It sounds like something I could use. Does anyone have any experience with this pattern? Know any pros/cons or perhaps an alternative pattern that works better?
Thanks for all the tips. I'm starting to realize now how important it is to plan out your code before starting to write it. I've already begun drawing some diagrams ;)
Return 0:
I had actually been meaning to buy that book for a while now. It was on the recommended books list at toymaker.info whose tutorials i've been following.
I believe i have found just what i was looking for though. http://gpwiki.org/index.php/Programming_Techniques lists the Observer Pattern. It sounds like something I could use. Does anyone have any experience with this pattern? Know any pros/cons or perhaps an alternative pattern that works better?
The Observer pattern is *exactly* what you need. It allows you to decouple things like your controls class from your character instances. All your controls class needs to do then is announce whenever the user presses a key on the keyboard. The human-controlled character instance(s) listen for those announcements.
Last edited on
Topic archived. No new replies allowed.