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. :-)
