
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