Jump to content
  • Advertisement
Sign in to follow this  
Kris_A

OOP in games - bit of confusion

This topic is 4167 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

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!