iDevGames Forums

Full Version: Game Data In A OOP World
You're currently viewing a stripped down version of our content. View the full version with proper formatting.


At the moment I'm programming my first OOP game, a RTS to be exact. I have used OOP fundamentals for years, although I have come to something I can not answer.

What I'm trying to do is make common data available to many classes. For example I have a height map object, quadtree object, and a grid object that is all part of the collision system. Each unit on the screen needs to know this data so it can properly walk and interact. Although the only two ways I know how to do this.

1. Make the data global. Good in the fact that I don't need to mess with passing around variables, although tramps over the OOP methodology. Although this seems like the fastest way to do it computationally, and since I'm only going to be running one game at a time it works out nicely. Traditionally this is how I'm implemented data for the game.

2. Pass the reference to all the objects that need this is either to make the data global. Not to hard to implement, yet this also seems messy in the fact that I'm having to pass all these references around. On the other hand it keeps everything inside of the objects so easy to manage.

Other then that I'm not sure how else to do this, I guess I'm looking for a clean and fast way to do this, and I'm not sure if I have too choose between the two ideas I have stated.

How do you find yourself implementing data structures into your game?
What you're looking for is a "singleton" -- kind of an OO way of making yourself feel good about having a global Wink
The advantage of singletons is that you still have a class around your data, which serves to protect it from abuse (read: shoddy programming screwing it up).

On the other hand, with a proper design, you should not have to pass around that many references, at all. You should, for example, have a collision detector object that handles all the internals for the units, so that they just have to query it for collisions.

This is also the more flexible, and maintainable approach, as if you want to switch from an octree to a BSP scheme, you only have to change it in one place for the whole game, and not go update code in a dozen classes.
In the past I was a little too in love with singletons, and that ultimately burned me. My current approach is to have *one* singleton, the application object. Then, the app contains pointers to things like the world, the current camera, entity lists, etc, etc.

So, I can at any time access, say, the terrain by calling something like:

Application::instance()->world()->entityForName( "Terrain" );


I've made a few singleton's before, and they are quite easy to implement. Thanks for the advice, I will certainly have to take a good look on how I should implement it into my own program.


My two bits of advise concerning singletons:

1) Make sure you have a clear division between interface and implementation. This still gives you alot of the OO goodness despite that fact that you basically have a global in disguise. Don't expose more than absolutely nessisary through the interface.

2) With multiple singletons be careful with your startup and shutdown sequences. It's easy to end up with bizarre non deterministic bugs if they all use each other and you have some circular references or other tangles. If you have several singletons I'd suggest putting them in some sort of ownership hierarchy so that its easy to know what is valid when.

Of course these suggestions have numerous exceptions, trade offs and can be taken too far. YMMV.
Reference URL's