OOP in games - bit of confusion

Started by
2 comments, last by Kris_A 16 years, 12 months ago
Sorry for the pretty vague topic, but I can't think of a much better way to phrase it... I've recently been forcing myself to use OOP more in CPP (that's one of the reasons they made it, right?), and in this case I'm making a game that's going to be more or less completely OO (getting my feet wet, so to speak...). The problem is that I'm confused as to where things should go! For example, I've got two classes at the moment, GFX and GAME. GFX holds all of my surfaces, fonts and details about the size of the graphics window, etc. GAME is where most of the magic will happen, like the main game loop. It's fine up until that point, but then I get a bit confused. I have constants, TILE_W, TILE_H which store the size of my game tiles. I have no idea whether these should be put into GFX or GAME, or somewhere else. Both classes rely on them, and they're related to both things, so theoretically they could go in either place, but that could also mean they belong in a brand new class, I'm sure. This problem of indecision also bothers me in different situations, like this: I also have a LEVEL class which stores information about the current level, and also has some static methods for loading levels. Only one level is going to be loaded at once. Is it best to have a single, completely static LEVEL class; a pointer to an instance of LEVEL inside GAME, or to simply get rid of the LEVEL class and store level info inside GAME? None of these seem particularly advantageous to me, except that the first and last will probably produce the most FPS. I know it's mainly a matter of personal preference, but are there any good 'personal rules' to stick by when faced with things like this? Opinions please! I wanna see how different people approach the same thing. Thanks
Advertisement
Quote:It's fine up until that point, but then I get a bit confused. I have constants, TILE_W, TILE_H which store the size of my game tiles. I have no idea whether these should be put into GFX or GAME, or somewhere else. Both classes rely on them, and they're related to both things, so theoretically they could go in either place, but that could also mean they belong in a brand new class, I'm sure.


The answer is in the name of the constants: they should be placed in a Tile class (which would then also be used to represent the tiles in your game), and re-named width and height. More advanced approaches would distinguish TileAspect objects (what is rendered) from TileNature (how the tile reacts), and have Tile own one instance of each. The width and height would then probably be moved to TileAspect.

Quote:Only one level is going to be loaded at once. Is it best to have a single, completely static LEVEL class; a pointer to an instance of LEVEL inside GAME, or to simply get rid of the LEVEL class and store level info inside GAME? None of these seem particularly advantageous to me, except that the first and last will probably produce the most FPS.


Why not have the game simply own an instance of a level, instead of a pointer? Obviously, almost no object in the game needs to access the level, except for the game object itself. As for the FPS, remember that unless a given detail intervenes thousands of times per frame, it will have no effect on the FPS.

Keep the level class as-is, its not the levels job to keep track that there should be only one. Also you might want several in the future, for example start streaming in the next level when you are nearing the end of the current one so you can switch faster and reduce waiting time for the player.

Also you mentioned that you have static load-a-level functions, it might be better to just use the constructor, thats what its there for (see: RAII one of C++ advantages over C).

Your other classes are hard to comment on since they are a bit general, perhaps too general? its usally good to strive for small, focused classes that only have one responsibility.

The tile size constants would probably fit better in a TileMap class (or Level if thats where you store your tiles), or in a Config class.. or just as global variables if this is a small application.
Thanks for the replies, everyone, they've been incredibly helpful :D

I hope all this OOP business pays off... though I'm sure it will

This topic is closed to new replies.

Advertisement