Looking for concept for managing game level views, level selection views, preferences view, storing levels, environment variables

Question

I'm developing a puzzle game application - watch on youtube - for iPhone, and the actual "in-game" part is almost done. It is a separate Class (subclass of UIView) what initializes with a puzzle clue, puzzle pieces, and is ready to send a message for somebody if the puzzle has solved ("completeness" check invoked on every touchesEnded).

Now I'm troubled how to design the whole application pattern programatically.

The game needs a main menu view, a puzzle selector view, fromwhich I can "create" puzzleLevel instances, I have to store the actual puzzle data in a separate class (I suppose), maybe in archive files, and need a preferences view, inwhich I can change the "global" variables that every puzzleLevel instance should use (angular snap values, skins, etc.).

I can feel that I have to do something with the main viewController what controls all the views I've mentioned above, but I don't know how to do it exactly. Where should I store global variables? Where should I store puzzle data? How should I report the "puzzle completeness", and who for should I report? How should I design the view hierarchy?

I'm wondering if somebody could show me some concept, or just a link where I can get along. I'm interestend in concepts mainly, the actual coding part can be "googled" after.

Answer 1

Typically my games have an App object at the top, which owns one of several AppStates (menu, selector, preferences, etc) and switches between them as required, in a pretty typical usage of the State pattern. These states handle their own rendering and input and store whatever resources they need. The App object also owns any global application-wide settings and objects that are shared across the states (eg. rendering, sound). These may be passed in to the states individually, or the states could request the relevant interfaces back from the App at some point.

One of the AppStates will be the game playing state, and that will contain the definition of the current puzzle, plus the current state of this play session (eg. how completed it is). I would tend to still have a separate Game class that is owned by the relevant GamePlayingState, since the former would contain only game logic information and the latter handles input/output.

Answer 2

I think I should use the NSNotification class. It is simply set up a "listener" in the object (viewController) that contains the subviews, then subviews can send notifications to the controller. Then the notification handler can invoke any methods.

viewController part:

-(void) viewDidLoad
{   
//Set up a listener.
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(notificationHandler:) name:@"finishedCurrentLevel" object:nil];   
...
}

-(void) notificationHandler: (NSNotification*) notification
{
//Notification handling.
if ([notification name] == @"finishedCurrentLevel") [self finishedCurrentLevel];
}

-(void) finishedCurrentLevel
{
//View managing code here...
}

The notification, the listening and the "responds" for the notifications set up this was. The actual notifying goes like this (can be executed from any subviews):

[[NSNotificationCenter defaultCenter] postNotificationName:@"finishedCurrentLevel" object:nil];

It solves my "communication" problem, I think.

About globals I simply created a separate globals.m file with the coressponding globals.h without defining any class. They just "attach" some extern variables, so I can reach them from any file having globals.h imported.