Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a small-ish 2d fixed shoot 'em up for iPhone.

I have a master Game object that stores lives, score, current level, etc...

The game will have some other persistent attributes like Music and Sound mute state, difficulty level (easy, medium, hard).

Should I put those attributes in the Game class or should they be on their own?

What's the rule of thumb to decide how to partition attributes among classes?

share|improve this question
Rule of thumb I use: If it needs releasing, don't bother too much. If it's scalable, try your best to keep it organised. – The Communist Duck Nov 18 '10 at 16:50
up vote 5 down vote accepted

It's all subjective, but consider the Single Responsibility Principle as a "rule of thumb". If you break them up now then you can potentially do things with the separate classes later without worrying about messing it up. Maybe you'll want the game object to be deleted and recreated every level, and if you split them up you won't have to worry about the design needs of one affecting the other.

share|improve this answer

This is a relative question and I'd say it depends on how you feel would be easier to maintain. If your game would grow 2, 3 or 10 times its size. Would it get lost outside the Game object? Or would it be lost inside the Game object? You just have to put it where you feel it belong, I don't think there are any rule of thumb here.

share|improve this answer

A common approach is to have a central "Settings" object which is implemented as a class which follows the Singleton pattern. When another class needs to look up the value of a setting, they obtain the instance of the Settings class and look it up.

The Settings class should also include the necessary code to persist and retrieve the settings. Any values which are not supposed to be persisted between runs of the game (like the game state, extra lifes, score etc.) should not be stored in that class. If you want to persist these in form of savegames, you should write separate functionality in your "master Game object" to serialize it to a savegame file and to initialize it from a savegame file.

The reason for the separation between settings and savegames is that players usually expect that their settings are global and not bound to a specific savegame.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.