I’ve achieved the following things in my first sabbatical week:

1. Found an office in Leederville that I’ll be moving into next Wednesday.
2. Completed a prototype of one of my projects, the d-board (get it here).
3. Pitched three of my other ideas to a handful of people who are interested in funding them with Real Money ™.
4. Met with an accountant to set things up for if and when I actually do make any money.
5. Started planning the implementation of MegaHAL10, another of my projects.

Thanks all so much for the overwhelming support. It’s been great. And don’t forget to subscribe to “The Occasional Jason” if you want more detailed updates; the subscription form is over there on the right (if you’re viewing this on my blog).

The other goal of the InputManager is to give game contexts and game systems controlled access to input controllers. For example, when a particular game context is active, it may require exclusive access to touch. In other circumstances, several game systems and contexts may use touch simultaneously (as would be the case when implementing game entity control with touch and overlaying a HUD that contains buttons that may be pressed). I want to avoid the usual technique of having entities, contexts and systems query the input devices directly, so that’s taking a bit of thought and hacking to figure out.

I expect I’ll be a day or two on this, and then will move onto entities.

Tonight I started by implementing a pause mode in KranzkyEngine. You can now pause, resume and stop it. Pause is pretty straightforward to implement; the engine sets or clears a boolean flag, and passes a time delta of 0 to all update methods if it is paused. It worked without issues in the HelloKranzky sample game.

Of course, once the pause mode was in, I wanted to tap to pause and tap again to unpause. Sure, this could be hacked in quickly, but the whole point of this exercise is to build a neat, re-usable game engine, so I took the lengthier route. I realised that I want at least four “managers” in the game engine:

• The ContextManager, which you’ve met before
• An InputManager, to take player input (keyboard, multitouch), appropriately transformed
• An EntityManager, to handle all of the game objects, and
• A SystemsManager, to handle various systems (like Physics), where each System is responsible for all of the Components that may be attached to Entities

So I began by refactoring the ContextManager to derive from a KranzkyManager ABC, and then I added addManager and getManager calls to the Engine. Internally, the Engine iterates over the list of managers, calling update() and render() on each one.

The cool thing about this is that a game could, conceivably, add a new manager to the engine without touching any engine code. Which is awesome.

Anyway, by the end of the night I had the sample game running, identically to before, using the new system. And I didn’t have any time to implement the InputManager that started this whole thing off. That’ll be for next week :)

After that, I expect I’ll start looking at handling user input, and making the various game contexts able to process input, steal focus and so forth.

Tonight I got the first version of the ContextManager up and running. Right now the KranzkyEngine has the following structure:

• KranzkySingleton
• KranzkyEngine < KranzkySingleton
  • Initialise the AirPlay framework
  • Hook into iPhone events
  • Run the main loop
    • Call KranzkyContextManager to update and render
• KranzkyContextManager < KranzkySingleton
  • Manage the list of known KranzkyContext objects
  • Manage the list of currently running KranzkyContext objects
  • Handle overlaying one KranzkyContext on another
  • Handle transitioning from one KranzkyContext to another
• KranzkyContext
  • Handle state transitions (ready -> waiting -> starting -> running -> stopping -> stopped

The “HelloKranzky” sample game looks like this:

• GameContext < KranzkyContext
  • Implement update and render
• HelloKranzky
  • Add the GameContext to the KranzkyEngine
  • Then tell the KranzkyEngine to start at the GameContext
  • Then call Kranzky::Engine::instance()->main()

This is all very cool. The next step will be to implement a bunch of different contexts to represent all of the different states of PostalWorker, and to hook them up to implement the click-through storyboard that I mentioned previously (and which I was hoping to have done by this update). I’ll likely find a few bugs in the implementation so far, as the storyboard will make use of stacked contexts with transitions as they start and stop. But that’s all good!

Apart from that, we RocketHands folks have been debating the best way to involve a third-party in the development of one of our games. This was motivated because Postal Worker was conceived by me and two outsiders at GCAP in Melbourne last December, and one of those people (Pazu) will likely be doing the art for the game. RocketHands will publish the game, and I’m working in my role as a RocketHands team member, so what happens if the game does ballistic and pulls in a cool one million dollars?

Well, in that case, Pazu (who would happily work on a project such as this just for the fun of it) would be rightly annoyed. So how much of that $1m would he deserve to get? And what about the mysterious “third man” who helped us conceive this baby? Should he get anything? How much value can be placed on that brief conversation over coffees during a conference compared to actually designing and implementing a game? Really, my main motivation would be to funnel a substantial amount of that $1m into RocketHands, to allow us to set up the company as our primary concern, and to do what we love for a living.

We’re toying with a three-tiered model, which goes something like this:

• The first $X of revenue goes straight to RocketHands (to recoup costs associated with marketing and publishing).
• The next $Y of revenue is used to pay for work done, at a reasonable rate.
• After that, Z% goes to RocketHands, and (100 – Z%) goes to the development team. The development team decides how to split things up.

So, in our hypothetical “Postal Worker Makes One Million Dollars” thought experiment, we might do something like this:

• $1000 goes to RocketHands, to pay for mailing out all that fancy Postal Worker schwag to the games journalists, helping us get awesome revues.
• $9000 goes to Pazu and me. I get $6000 (100 hours at $60/hr) and he gets $3000 (50 hours at $60/hr).
• 70% of what’s left goes to RocketHands (that’s $693000 – we quit our jobs, lease an office and start working on our XBLA game).
• 30% of what’s left goes to Pazu and me (that’s $297000).  We give $25k to the mysterious “third man” to keep him quiet, and $2k to charity. I then get 2/3 of it (because I worked 100 hours and Pazu worked 50), which comes out to $180k. Pazu gets a measly $90k.

My question to you is this: who is getting ripped off here? Does it seem fair that RocketHands, which didn’t really do all that much, made a whopping amount of money? Especially when Pazu only ends up getting a bit less than 10% of the total earnings? Or, does $93k for a coffee in a hotel and a weeks worth of work seem like a good deal?

Pazu, your thoughts please…

I finished off the night by stubbing out the rest of the Context Manager (which I’m now calling the Game State Manager). I should be able to finish off the bulk of that tomorrow. I expect the trickiest part will be investigating how to maintain a stack of Contexts, and how to retrieve them by name. AirPlay SDK has an Array type and a fast string hashing implementation to enable that kind of thing, and recommends not to use the STL. So a simple hash map may be a bit more work, and more of a lower level, than normal. Got to make sure I get it right!

• set Pazu up with an ad-hoc build;
• made sure my iMac has a static IP, as I need to run a server on it for packaging the game for iPhone deployment;
• figured out how to view crash logs on the iPhone;
• got more excited about GDB on Windows for debugging the ARM build (yep, found and fixed a crash bug);
• continued work on the game state manager; and
• improved the main game loop.

Things are progressing nicely, and I’m quite comfortable with the tools I’m using to build stuff. I need to sweat the small stuff at this stage of the project, as getting things right now will provide me with firm foundations for building the rest of the game. One example of this is the main game loop. I need to make sure that the time deltas I pass to the update are either fixed or within some reasonable range, I need to yield to the OS correctly and frequently enough, and I need to make sure I can handle being interrupted (by a phone call, for example).

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?