Since doing HamQuest, I have typically structured my games such that there are three basic pieces:
- A basic library of common classes that are useful on their own and not specifically for a particular game
- A game specific library of classes with a main class called something like “Game” (consumes the common classes library)
- A client that consumes the game specific library
Additionally, most data is serialized and deserialized from XML, and specifically the class XElement, since it works for both desktop and silverlight.
In Island Interloper, I have attempted to make it “impossible” for the client code to mess with the game data other than through messages, which are validated and handled according to the internal state of the game, so the Game class winds up needing to handle Command objects and return Result objects.
Naturally, the nature of a Command object depends on the command. A command like “UNDOCK” is simple and parameterless, but something like “SET HEADING TO 90 DEGREES” requires parameters. Similarly, the Result object depends on what is being returned from the game.
I decided to go with XElements for both of these as well, and the end result is that my Game class winds up doing very little other than responding to Commands in XElements and returning Results in other XElements.