So I’ve been working on a Flash game for a client. It’s got a bit of everything: a little physics, a dash of GUI, and a lot of animation. Unfortunately I can’t show anything because I have a “blog clause” in the work contract, which permits general discussion about the techniques used but no revealing of the process until it’s released.

So this week’s challenge is to refine the class hierarchy and shake out some sequence bugs. The hierarchy is based largely on the concepts we had at Qualia: Sprites, Sequences, Pieces, Players, and Controllers. The hard part is to get them all to talk together, in a specific order, without creating odd interpendencies.

The game architecture is based on timesteps, during which a number of things happen. For each timestep, the cycle goes something like this: 1. Graphic State updated to reflect piece changes from previous step 1. GameController calculates game logic conditions from all Players 1. Players get control, get information about the World 1. Players submit Inputs to their managed Pieces. 1. All Pieces modify their underlying properties according to inputs by their Players 1. All Pieces get called for a Simulation Step (movement, etc) 1. All Pieces check to see what happened to themselves, and updates their underlying status, which isn’t the same as a property.

My first past implements sprites and sequences into Flash movieclips with frame scripts, which allows the artists to make changes independent of code fairly easily. Sound effects can even be embedded, and I as programmer care not.

I made a mistake by combining Pieces and Players into the same class…I will need to separate them again. I also didn’t make a clean separation between the pre-step, step, and post-step actions that had to occur, so I am getting inconsistent behavior due to variables fighting each other during different parts of the cycle. So this weekend I’ll be rewriting the hierarchy and interaction more tightly. This is all new code, so I’m excited about layout a new foundation for future development.