I've been doing some serious simulation architecture designing and implementation for Azrial. This is a complete reworking on how simulation objects (actors, items, obstacles, areas, etc) are built and used. It's a lot of tedious upfront work, and providing little immediate visual reward. The reward comes in the satisfaction of knowing that this rework is making the simulation framework more generic and datadriven.

My simulation architecture is derived from Thor Alexander's simulation design illustrated in Game Programming Gems [GPG] (forget the number), and Massively Multiplayer Online Game Developement Book #1 [MMOGD] (I guess this makes me an Addison Wesley Charles River Media fanboy -- but hey, that publisher releases some damn good dev books).

In a nutshell, all objects are subclassed from ISimulationObject. Simulation Objects (aka SOB) can contain other simulation objects (e.g. a player can contain a backpack -- backpack can contain several items, etc). Simulation Objects have links to other objects, such as an area will have links to other adjacent areas, party members may have links to other party members. These simulation objects also support the observer pattern, so those object interested in events for a particular SOB can subscribe to it and recieve update notifications.

When a client logs onto the server, the client is attached to an Actor instance (which is a subclass of simulation object). Actors are controlled by Actions. The Actions are modelled using the State Design Pattern. In particular, Actors make use of multiple parallel state machines. The state machines supported thus far include a TurningState machine (controls the orientation of the actor), MovementState machine, ActionState machine, and PostureState machine. Using parallel state machines, keeps the state machine design simple in terms of design and yields more flexible behavior. Using this pattern means that for an actor to change its state from standing and idle to running forward and casting a spell, the actor must be able to transition its movement state from standing to running forward and transition its action state from idle to spell casting. But enough about that, see [MMGD] for more detail.

On the client side, Sobs have corresponding proxy classes. So where we have a CActor on the server, we'll have a lightweight CActorProxy on the client. In attempts to keep simulation separated from the actual rendering, I make use of the Observer Pattern. When we have a SOB that requires rendering, I attach the appropriate observer (such as a RenderModelObserver) that is in charge of registering/unregistering the 3d model with the model manager.

As it stands right now, I can login, and receive my character's base model information from the server. I'm in the process of setting up how models attach to other models in a generic fashion (e.g., attaching a weapon to the hand of the character). This will hopefully be done tonight after work.