The Magic Pantry

Tonight I thought I’d start work on KranzkyEngine, after upgrading my AirPlay SDK license to remove the annoying EULA message when launching apps. Porting Box2D can wait for another day!

I want to write a game state manager that supports a stack of game states, making it possible to draw the game menu on top of the game proper, without those two things needing to know about each other, and even to separate the HUD in the game proper out into its own state. Ideally, with nothing more than the game state manager and a little bit of engine framework code, I’ll be able to implement a playable storyboard version of the game that can be clicked through on the iPhone. Once that’s working, it’ll be on to entity management (I want to do a nice clean component-based system, and that’ll take some thinking to get straight). Entities will naturally lead into Physics, and that’s when I can start worrying about Box2D.

The PC version of KranzkyEngine has been used on quite a few projects (Thrust Harder, 99Sheep, Brown Cloud, dBoard and so on), and RocketHands wants to release it as our rapid prototyping framework, much as 2D Boy did with theirs. I’m hoping that working on a mobile device version of KranzkyEngine will help me to clean up the PC version considerably, and that we’ll be able to release both versions Real Soon Now ™.

Game Engine

The Game Engine (or GE) is responsible for setting things up, running the main game loop, and tearing things down afterwards. In the case of the iPhone and other mobile devices, it will probably also be responsible for saving and restoring game state, and handling all of that mess. It calls into the Game State Manager both to update and render the game current state(s) of the game, and knows to call render() as often as possible, and update() at a fixed rate. The GE handles input, routing it into the Game State Manager, and is also responsible for updating the Entities Manager and other subsystems (such as the Physics Manager and the Sound Manager).

Game State Manager

The Game State Manager (or GSM) is responsible for handling game states. It keeps a stack of active game states, and handles transitioning them in and out. It renders the current state of the game by knowing which of the states in the stack can render visible content (the states contain data that provides this information), and then calls render bottom-to-top, so we can have the game scene with a HUD laid over the top, and then a game menu laid over the top of that. Update is called on each game state in the stack, and input is provided to states from the top-down, until a state is reached that requires exclusive input focus.

Each game state can be inactive, transitioning in, active or transitioning out, and they may specify how long each transition occurs. This allows menus to slide in and out, and even such basic things as having the main display fade to black. Game states have init() and fini() methods to allow entities to be created and destroyed, for example. In their update() methods, they may query other subsystems, but aren’t required to call update() on anything else (that’s Someone Else’s Problem.

Tonight I got a very basic game engine up-and-running. It will be a few more nights before I have the game state manager working to my satisfaction. Perhaps a good deadline is to deliver the storyboard clickthrough at the end of this week?