Best practice for object oriented game design?

[aquaglow]

I'm not having any problems getting my game working with SFML, but currently all my code is just in the main() function. I'm new to C++, and was wondering what's considered the best strategy for splitting up ones code into different classes?

There are certain game objects which different classes will all need access to, is it a better approach to define static class variables or to pass references around?

[Nexus]

I'm new to C++, and was wondering what's considered the best strategy for splitting up ones code into different classes?

First, you should create classes according to the objects in your game. For example a class for the player, one for the enemies, one for projectiles, one for scenery objects... When you see that these objects have certain commonalities (e.g. player and enemy both have a position and a velocity), inheritance is an option.

Apart from that, there are often classes that are responsible of the correct game flow. For example, a class that manages the game (invokes the game object's methods), one for physics, a renderer class etc. But there are many possibilities.

One thing that many game programmers don't do, but that I find relatively important, is the separation of graphics and logics. At least up to a certain limit... Don't inherit Player from sf::Sprite. Rather make the sprite a member of the Player class. Or even better, don't use any SFML stuff in the player class, keep Player a completely logical entity, independent of its graphical representation. While this is idealistic and often not the best solution to apply in practice, the separation of different responsibilities is fundamentally no bad idea. This concerns also other classes: Don't write huge classes that handle everything, and keep dependencies small.

Read also this thread, there (and in the links) are many design tips.

There are certain game objects which different classes will all need access to, is it a better approach to define static class variables or to pass references around?

The latter. Generally, you should try to avoid global/static data when possible.

[Haikarainen]

Nexus summed it up pretty good, i usually do something like:

Code: [Select]

Core
Video
sf::RenderWindow* GetWndHandle();
Audio
Play(SoundResource*);
Resources
Game
Map
Player
Enemy
Maplayers etc
Objects (like soundemitters, items etc)
Menu


Etc, you get the picture, and then in main.cpp i usually have:

Code: [Select]

try{
Core* GameHandle;
GameHandle->Run();
}catch(myException &e){
std::cout << e.what() << std::endl;
}

[Groogy]

You could say you should do it on a "what feels right" basis. But there is something VERY important to this. Do not be afraid to refactor. If you don't know what refactoring is then: http://en.wikipedia.org/wiki/Refactoring

Anyway there's a simple mantra to remember: Make it work, make it right, make it fast.

First you go on your feeling, what feels right? What do you think is needed in order to implement the feature. Then when the system grows you will eventually see mistakes, see places where you can improve the interaction between the objects. That's when you do it right, you refactor your code to work in a better way and be easier to work with. And last and actually optional is to make it fast, optimize the code which most often goes against the previous step.

There is actually books for this that we read in my university. I recommend that you find some. I think one was named Object Oriented Design and Analyse. Best sleep pill ever besides being really good for this subject.

[aquaglow]

Thanks for all the help, I'll try splitting up my code as per your instructions.