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?
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.
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.
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.
