The central-most Objective-C class in this game I’m developing is called “HBDGame”. The main source file has gone beyond the previously-mentioned 6000 lines and is now over 7200 lines. It seems a lot (for my own records).
Now I want to make a quick post because I will forget if I don’t… and because I do not want to write about this in detail right now.
There is a difficulty in maintaining strong organization when I have over 40 classes and dozens or hundreds of images, giant world map files (around 10/25 made so far) with dozens of configured elements within each, and a handful of soundeffects.
So I have probably 100+ pages of hand-written notes and diagrams and pencil illustrations, plus all the source mockup files for the computer graphics, and e-documents typed to keep myself organized.
And it’s becoming very challenging. I make constant use of text-based two-way references. That’s one of the best helps for me to keep track of execution paths in the program. blah. Now this is really starting to sound technical.. hah.
The major point of this post is simply this: the source-code and information hierarchy model I’ve found myself using (and pretty comfortable with) is something like this:
- Main game class is HBDGame, and it is the ultimate boss, next to the app delegate itself.
- There is a layer of persistent data (game settings that are important to keep the same for every game-session, like music volume and choice of accelerometer control versus touch-screen control). This persistent data is saved and loaded by 3 different simple functions. The HBDGame controls these, and every class that wants stuff saved goes through the boss class.
- Significant game components, including the GamePlayer, menu systems (main menu, pause menu, quick popup menus) and other significant game objects.
- Interaction layer which handles the inputs to affect the game. Some of this goes through the boss, and the boss passes off the inputs to the proper recipient. Other times it goes directly to the recipient (specifically in the case of menus).
- Finally, the graphics themselves. The graphics are controlled almost all completely through the main game components.
Probably doesn’t qualify as a model-view-controller layout. More like a Global support-storage-model-controller-view. I think the model-view-controller is a great model for software, but it seems complex projects have blurry lines of communication between the three concepts.
Perhaps there is a better way to organize what I’m doing, but right now I’m still finishing up the core of the game.
I’ll try to write more about this, with concise details, later on.
