This is the second part of a series of post about the structure of the Beta 6 Milestone 2 database, which describes the various structures required to store and control the state of the game server. Names and descriptions in this section do not use the internationalisation system, as they are not meant to be seen by players.
Application status
Information regarding the application’s state include the identifier of the next game update, the identifier of the current game update if one is being processed at the time, the date and time at which each type of recapitulation e-mail was last sent (administrative, server errors, player messages), and information about maintenance mode, if enabled (start date & time, scheduled end date & time, reason).
System logs
Entries in the system log include a time stamp, a level (trace, debugging, information, warning or error), a component identifier and a message. In addition, a log entry may be associated with an exception record. Such a record includes the list of exceptions in the proper order, with the exception’s class and message, and the stack trace for each exception. An entry of the stack trace may contain a location (class and method), a file name and a line number.
Ticker status
The “ticker” is the server component which fires the various tasks that ensure the game’s proper functioning. A ticker task is identified by its name. It may be running, stopped or scheduled to start automatically at a later date and time.
Game update status
When the various game updates are being executed, it is necessary to store their current status in order to make sure that an error during a game update can be recovered from. Information regarding a game update includes the type of update (e.g. fleet movement, battle computations, empire research…), the last game update at which the update was last executed, and whether the update has been processed, is being processed, or is scheduled for processing. Finally, there are two major types of updates – updates which affect planets and updates which affect empires; this implies storing a reference to the planet or empire affected by the update, respectively.
Game and system parameters
A game or system parameter is identified by a code name (which is used in the game’s code to refer to the parameter). It possesses both a name and a description, which are stored as text (only administrators will see these strings). A parameter belongs to a category identified by a name. It may include a lower bound and / or a higher bound, and of course has a value.
Session types
The game will, in the future, allow for various types of sessions (in addition to sessions from the usual web interface). A session type is defined by a code (e.g. “web” in the case of the web interface), associated to a flag indicating whether the session type is exclusive. An exclusive session will automatically terminate any concurrent, exclusive session.