In this post I summarize four principles of real-time interaction. Shoot.

1. State Driven Control

Event driven control is inductive – it relies on assumptions about the state of the world. Unfortunately, as often as not, these assumptions are incorrect.

State Driven Control is deductive – it relies on evaluating the current state of the world before deciding how an entity should be updated.

2. Conflictual Ownership

By default, game objects tend to be modeled as commons. This, quite naturally, leads to the disaster of commons.

Ownership: an interaction cannot take control of a resource without acquiring this resource.

Conflictual: explicit resource conflicts. By default, fail fast. Whenever necessary, define resolution clauses.

3. The Rule of Return

Never register any callback that may never return. Conversely (and more usefully), do not provide registration methods unless you can warrant that the associate callback will fire. At runtime, validate the callback by asserting return conditions.

4. Pedantic Command

In debug mode, do not allow overly concise control – to the contrary, require control to be somewhat declarative as it allows asserting its integrity. Three examples may illuminate this idea:

Compare this…

• glPush() / glPop() - unsafe
• [foo retain] / [foo release] – unsafe
• startAnimation(“dodge”) / stopAnimation() - unsafe

• glPush(myToken) / glEnd(myToken) - safe
• [foo retain:fromBar] / [foo release:fromBar] - safe
  (but avoid back references using hash values)
• startAnimation(“dodge”) / stopAnimation(“dodge”) - safe

Timeout

I’m not especially in the mood to elaborate on this today; questions, however, are not unwelcome.

On the 1st of December, major Japanese iPhone site App-Bank reviewed Antistar: Rising and posted a gameplay video. Thanks guys, getting a little attention is all we needed to steal the spotlight this week-end :)

We’re still way off the next Antistar update. Essentially changing the way our game engine works, without actually rewriting the bulk of code that makes it work, has occupied the best of my time in the past 6 weeks or so – although I’d like to rush into chapters VI-XI and all the fun of designing new stuff, I’m actually just piecing Chapter I together again, patiently. On this note, here are ‘three questions to a young game code designer’:

1. How do you handle cut-scenes?
2. How do you switch scene?
3. Can you serialize game state?

If your game engine/framework supports you when you want to cleanly disable PC controls and substitute a 2D UI while a dedicated class orchestrates an animated sequence, momentarily taking controls of both the  PC and NPCs, you’re doing good.

If you can teardown a scene and replace it by another, quickly (ideally without loading times), then you’re also good.

These two design problems emphasize the need for modularity and clean memory management in our game code. It’s quite easy to get started with something great, only to realize way way down the line that we just wouldn’t know how to teardown/disable/replace the game UI, or that you find yourself unwilling to switch scenes because you don’t know which wire to cut first.

It would be mindless for me to suggest an answer to these questions. Every game programmer will find their answer  if they bother asking – point being, the more we delay asking these questions, the more we’re likely to have a hard time answering them.

Activities, said we? [edit, 25/02/2011]

This post used to include short guidance about how to write Actuators. Actuators are classes that provide a simple [AnActuator step:(int)millisecondsElapsed] method in charge of performing time based updates. They should only be used when necessary and, most of the time, Activities should be preferred. Activities are even driven controllers managing actuators over longer periods of time.

Both activities and actuators are central to clean game design. I removed the original explanation (which misleadingly confused them both) and hope to write a better, sturdier introduction to this topic quite soon