Server-side Development

Server-side Development

Design Rationale

High Priority

• It should be no UI necessary to test and develop server-side code.
• There should be support to develop UI by providing automated clients, or something similar.
• The server implements all game logic. Client inputs should be validated.
• The server should know the expected task for each client at each point.
  • Which player's turn is it? Reject input from other players.
  • Which task is expected by that player? Reject invalid input.
  • Provide end-user compatible error messages.
  • Provide a message with task information to other users. E.g. player X is expected to do Y.

Lower Priority

• The server should know what data needs to be sent to a client. That data should be minimized, e.g. by sending incremental data.
• It should be possible to replay a complete game and/or have an overview of what happened in which turn after the game is finished.
• The server should minimize it's own state.
• The server should be able to restore it's state from persistent storage as GAE might kill a servlet.
• The game logic should be implemented in a readable, extensible way. A state machine? Rules?

Nice to have

• A possibility to undo/redo a turn or some parts of a turn.
• An overview of how much time each player requires.

Ideas

Commands and Persistence

• commands could be used to persist data
  • e.g. by using JDO which can be used together with Google App Engine http://code.google.com/intl/de-DE/appengine/docs/java/gettingstarted/usingdatastore.html
• commands could be used for client/server communication
  • this is currently not the case, but that can be changed
  • might ease the incremental data transfer
  • might make client development more complex???
• as this is a turn based game, there should be some possibility to know the game state as it was in any turn of any player - either the domain model can have knowledge of "modifications over time" (probably quite complicated) or there could be commands that modify the game state

Documentation

Design

• ServerRuntime is a singleton. This class provides access to all server functionality.
  • It is setup either from a command line application, like StarcraftBordgameServer,
  • or by the web server, like StarCraftWebServer (which is actually a servlet that is initialized at server startup)
• The ServerRuntime holds a (currently stateful) instance of StarCraftRemoteServiceImpl. It may register a RMI proxy and delegate all calls to that implementation.
• In case of GWT, there is the servlet StarCraftServiceImpl regisered, which simply delegates all calls to the StarCraftRemoteService implementation of the ServerRuntime.

Client/Server Communication

• [GameStateModifications] lists all tasks that modify the game state. The clients must be somehow able to trigger these modifications.
• See StarCraftRemoteService for the communication interface, StarCraftRemoteServiceImpl for the server-side implementation.