Game Structure

We’ve been working on developing games for iPhones/iPods for the last few months. It’s been going slower than we’d like as there was a steep learning curve, but things are moving forward.

We will be writing more about our experiences writing our games so you can see what’s going on and maybe learn something. Let’s start with the structure of a game.

If you load up XCode and create a new OpenGL ES project, you’ll end up a program that has a window with an OpenGL view (EAGLView). Now you could write your game with this but you’d quickly find things get messy. It would greatly help to have some resource management.

The popular pattern for this is to have a singleton object which will manage things like graphics canvas, current game state (is it running? paused?) and what is being displayed. This is usually called a Director.

You then have different Scene objects such as a menu or different levels of the game. The scene will know to draw/render itself and handle events such as user touches. The Director then controls what scene is being displayed at any given time. So say you have a menu scene and the user taps to start a new game. The menu gets the touch event, sees what the users wants to do and tells the Director to swich the scene.

For the game logic, you would put typically put it in the scene object(s). By game logic, I’m talking about object locations in the scenes (e.g. players/enemies), collision detection, scoring, and other items along those lines.

When the game is running, you start a game loop up. This will update the scenes/game state. It can be a infinite loop or timer based. If you run full speed with a tight loop obviously that will draw more power/resources from the device. If you are just displaying a menu, that can be a waste of battery life. From what I can see, most people seem to favor the timer approach.

Also regarding performance, when you are drawing/rendering an OpenGL scene, it’s important to batch the drawing instructions up and pass it all to the hardware. By doing that, the graphics chip will take over and optimize as much as it can. If you make a lot of OpenGL calls in small chunks, you’ll get lower performance and find yourself CPU bound.

If you’d like to see some code examples, see the cocos2d library or this tutorial from 71Squared.