I spent yesterday outlining some of the basic classes for the interactive Flash game. With the amount of animation in this game, I think I will need a pretty robust event-driven graphics architecture. Also, I’d like to avoid the pain of asynchronous threading that I had in my last (and first) AS 2.0 app in Prove it.

I think I can combine both things into a common “Executor” class, which is an event-triggered serializing execution queue. Each Executor will have an ExecQueue with ExecObj’s, which encapsulate object and method context. This is similar to the method I used in Prove It to create a synchronous XML loader, but more generalized. The rest of the architecture breaks the interaction into Game Logic, I/O Services, and Sprite Utilities. So here’s how it’s shaping up:

I/O Services

• ServerConnection
• ScreenMgr
• SoundMgr
• FileMgr

Sequencer

• Executor (base class or interface)
• ExecObj
• ExecQueue

Graphics

• GArrayMgr
• GArray

Entities

• Player(s)
• World
• Physics
• GM

Utilities

• Timer
• File

I may not worry so much about the executor objects right now, but the queue-based event triggering will be very important for developing a flexible interactive animation system. It’s going to be a long week. :-)