Now that some basic XNA is in place, I can start to think about architecture. I'm going to use something like the following top-level objects:

• HumanPlayer - manages pieces representing entities controlled by human players via the CameraTracker
• DenizenPlayer - manages non-player pieces in the world (AI)
• WorldPlayer - manages environment pieces like the world grid, buildings, and the like
• Simulator - calculates physical interactions with the world and between pieces (physics simulation, such as it is)
• GameRef - the state manager for game "logic" (win/lose conditions, turns) based on pieces, simulator results, and game state
• GameState - the current state of the game (points per side, etc)
• GameController - the XNA Game object, renamed, handling high-level game start/stop/running.
• GameHUD - the GUI overlay for the game
• PieceWrangler - utility class for handling all the pieces in the game as groups between players
• SoundMgr - manages environmental sound from pieces and the world

Player classes manipulate Pieces, which are representations of the various "self-determining" entities in the game. Pieces possess the following kinds of information at minimum:

• Physical Properties for use by Simulator: position, direction, velocity, geometry, size
• Visual representation (model)
• Life state (spawning, alive, dying, dead)
• Helper methods for related to managing the above three classes of properties
• AI-relevant data: Current "State of Mind" and "Intention" in subclasses
• Other "piece type specific" data in subclasses
• Update() and Draw() methods

Player classes also implement Update() and Draw(). Each Player class maintain a list of managed pieces.

The GameController class, which is the root-level object, essentially will call the following loop:

• Player.Update(gameTime) on each Player class so each Player can update its pieces
• Simulator.Update(gameTime) tells all player pieces how to update their physical properties
• GameRef.Update(gameTime) examines the state of all Player and Piece classes, and changes their states accordingly. Also sets GameState for inspection by GameHUD and GameController
• All players Draw() in order of World, Denizens, and Players
• GameHUD.Draw()
• Loop

The actual loop may be more complicated than this to handle tricky interdependencies, but this is the basic idea.

The Piece classes have a lot of information in them. The one that is most interesting to me right now from a refactoring perspective is how to visually represent it, since that's the code I just wrote.

When a piece is told to draw, it needs to render out lists of triangles with a certain shader (Effect) attached to each. So we need to first know what the dependencies are for drawing, as it requires access to the GraphicDevice in game to set up all that stuff. Furthermore, each model's list of vertices represents memory taken up on the graphics card, so it would be good to just store one model per "type". The appearance of the model in world space (position, orientation, and size) are determined by the Effect's various transforms (world, view, projection), while specific appearance (color, texture) are either baked into the effect or passed in as a parameter. So Effects handle both positioning (vertex shader) and painting (pixel shader) operations.

The basic XNA Model class has a utility drawing method that will draw all the submeshes (if there is more than one) grouped by effect. It essentially draws all the submeshes using one effect in a model, then it draws the next batch with the next effect, and so on.

Effects in the XNA Model are set by the Content Loader, which has some limitations in the number of maps it can load and how it assigns a particular effect to a submesh. I think what I will end up doing is writing logic that chooses from a bank of Effects (I think I read somewhere that storing multiple effects is actually not that expensive) based on the status of the piece itself.

So to represent the visual of a Piece, I need two pieces of information:

• The Model, which contains Meshes with associated Default Effects assigned to them.
• Which Effect(s) to apply to the Model when it is drawn, pulled from an EffectsMgr of some kind. These may ignore the Default Effect.

The actual drawing needs to take place in a class that has access to the GraphicDevice of GameController, so perhaps what needs to happen is GameController.Draw() extracts the selection logic from each piece being drawn (perhaps managed by PieceMgr, which could do some additional group optimization) and uses that to access vertex data from a ModelBank and compiled effects from an EffectBank. The transform data is then pulled from the Piece (pos, etc) and input into the Effect to position the model properly (using SetParameter) before rendering it with the selected Effect. The selection of the appropriate effect would be based on the type of piece being drawn.

So the Piece's visual class will contain:

• MeshBank references to a single Model
• EffectBank references the effects used to draw the model
• A list of Effects to be used to draw the Mesh subparts, which will have to follow a particular naming convention. I will have to look at the Model classes to see what name is stored there. To manage things like Piece States, a list of Effects will have to be provided for each state.

Time for an update!

The basic architecture is still holding, though there's much to be filled in. Right now, the notion of Player classes exists, primarily as the HumanPlayer. HumanPlayer are human-controlled pieces; right now, they are really more like cursors that affect other pieces by proximity (they will soon, anyway). HumanPlayer is a listener to the CameraServer, which feeds the Game information about what's moving around in our interactive space.

The basic idea is that all Pieces in the game (that is, anything that impacts the gameplay) are managed by Player classes. Each Player gets a turn to manipulate its pieces through the Update() method. After every Player gets to move, the GameReferee determines what happens and updates the "logical state" of each Piece and Player. It also updates GameState. Then GameSimulator is allowed to perform a simulation step (handle physics, basically, and also any non-Piece graphics effects updates like particles). GameHUD then gets a chance to update any GUI controls parameters Finally, everything is told to Draw().

Attached is a class diagram (PDF) format.