Managing Game State with Persistent Objects
Communication is necessary and important, but without game state there is no game. You can talk until your blue in the face, but its very difficult to play a game of chess without a board and pieces to refer to. Game state contains all of the data necessary to represent current state of the entire game world. In chess it is the location of positions on the board and who's move it is. A massively multiplayer online role playing game (MMORPG) has a more complex game state. It contains your character, the possessions you were carrying, the nearby dragon that you were battling, the cost of beer at the local inn, and much more. In an online chess game it would contain the state of the chess board and whose move it is.
To simplify the lives of developers, in Darkstar all of this state
is represented by traditional Java objects. You can use object-oriented
design to construct objects that represent your game state. If you need to
represent a sword in a MMORPG, you just declare a
class. Better yet, that
Sword class can extend from a
Weapon parent class, which could, in turn, extend from
Item class. Designing the state of your game is just
like designing the objects for any other program you might write.
In the traditional server-client model, the entire state of the game world is stored on the server. This ensures a single authoritative copy of the data, but it potentially requires simultaneous (or concurrent) access and modification of ...