Hi
I’m actively developing a tower defense game, and its coming along nicely. However, a concern of mine is to try to create my game as modular as possible - and i got to thinking about AppStates and how to use them. Currently, the hiearchy of my game goes in the line of the following:
SimpleApp > InGameState > A set of manager-classers (towermanager, worldmanager, playermanager, creepmanager etc.)
The InGameState does ‘nothing more than’ initialize the different manager-classes (which then in turn, activates world, creeps, player etc). Later on i’d perhaps implement a MenuScreenState, a MultiplayerGameState and what not. Am I taking a wrong turn here ? A question is, would it be reasonable to implement my manager-classes as AppStates instead ?
I currently have trouble ‘predicting’ the benefits of implementing my game in one way rather than the other.
I guess I’d like to see if anyone’s willing to share how they use AppStates in their games ?
Kind regards,
Asser
For the most part I use app states for one of two things:
I have a set of “game mode” app states for various states of the game. Only one of these is active at once. I then have a few “utility” app states that provide functionality used by all the game mode app states.
For example I’ve rolled my own nifty popup message handling, I’ve got one that is a sort of popup menu used by all the other states when they need a menu opening, etc. These are all running when needed.
In your case I don’t really know enough about your game but in general encapsulation is good. If each of those manager classes is its own independent thing and could usefully do something with its own update call, initialise, enable/disable/etc then that’s a good case for making them app states.
Check out MonkeyZone, it uses them. One book sample also creates a tower defense game: https://code.google.com/p/jmonkeyengine/source/browse/#svn%2FBookSamples%2Fsrc%2Fmygame
Thanks, both 