iDevGames Forums
Game State Management - Printable Version

+- iDevGames Forums (
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: iPhone, iPad & iPod Game Development (/forum-11.html)
+--- Thread: Game State Management (/thread-8839.html)

Game State Management - Mattonaise - Apr 14, 2011 05:52 PM

Hello forum. I am planning to have some sort of game state management for my iphone game but I have some questions. I would have a certain class be my "state-manager" and some other class be my "state" class. The only problem is what classes to use. For my "state-manager" class I could use either the appdelegate or a viewcontroller. I think the appdelegate class may suite me better because I can access it anywhere, including inside the "state" class to notify the appdelegate to change states. However, I'm wondering if a viewcontroller would be better to use as a "state-manager" if it has any features that would be useful but not avaliable in the appdelegate. Also, the "state" class has a similar decision. I could use a viewcontroller or a single UIView. A viewcontroller may add more flexibility with the states, for example I was thinking that the "game state" class could be a subclassed viewcontroller, and that a "game view" UIView subclass would be contained inside of the viewcontroller. I could also have a "game data" class contained inside of the viewcontroller, so that the "game view" class could access the "game data" class to find locations to move certain CALayers to (which are used as the sprites in the game). The original viewcontroller could control the timer (or display link), control a soundmanager, and maybe handle networking. However, a viewcontroller as the "state" class may be unnecessary, and a UIView class as the "state" class may be easier when using transitions from one state to the next. It would be great if anyone has some input or suggestions on this decision, and if anyone else has used something like this before.

RE: Game State Management - OneSadCookie - Apr 14, 2011 07:08 PM

Ignore the UI* and CA* classes when designing your game. They're irrelevant. In general, your game should be portable to any other platform by removing the input, graphics and audio layers and keeping every other aspect of the design.

In other words: none of your game logic should even include UIKit or CoreAnimation or really anything other than Foundation.

RE: Game State Management - Mattonaise - Apr 14, 2011 07:17 PM

Okay. I was trying to seperate the game logic from the UIKit, I was going to store the game logic and data in a class seperate from the view, inside the viewcontroller. Do you mean to keep the game data class out of the viewcontroller? I wasn't planning to port the game to any other platform, so I'm not sure this kind of seperation is necessary.

RE: Game State Management - OneSadCookie - Apr 14, 2011 09:58 PM

Whether you ever do the port or not is equally irrelevant (though having a Mac version is incredibly helpful for iOS development). Design is mostly about what pieces of the puzzle to keep apart, and "windows, graphics, input and audio" are all things that should be as decoupled as possible from the rest.

RE: Game State Management - Mattonaise - Apr 15, 2011 09:08 PM

So are you suggesting to take the game data out of the viewcontroller?

RE: Game State Management - Baldock - Apr 16, 2011 02:55 AM

I think what OSC is saying is create your own class to manage your state and send messages to your viewcontroller

RE: Game State Management - Mattonaise - Apr 16, 2011 10:18 AM

That is similar to what I was going to do. I was going to have my game data class contain all the data and logic and keep that away from the rest. The viewcontroller would handle the timer and tell the game data class to update itself, and would also tell the view class to update itself. When the view updates itself, it needs to get the postitions of all the game entities from the game data class and update all of its CALayers that correspond to each entity. If I did this, the view class would need to be able to fetch the data from the game data class, possibly via a reference to the game data class that is setup when both classes are being initialized. Is this what you are concerned about? The only class so far that deals with any Core Animation or view-related classes is the game view class, so the game data and logic doesn't interact with any of the view-related classes. I'm not sure I understand exactly what you think should be changed. Can you elaborate on this?