| GGZ Gaming Zone Design Specification | |||
|---|---|---|---|
| <<< Previous Page | Home | Up | Next Page >>> |
While the architecture of the server is divided into the aforementioned four parts, there are a few "subsystems" which are necessary.
This is a two part system. One to parse the command-line arguments, and one to parse the configuration file. Options specified on the command line should have a higher precedence than those in the config file. Additionally, an alternate config file may be specified on the command line.
At the present, the popt library is used for command-line parsing.
The configuration file parsing is a three-phase process which bootstraps itself from a dark, dreary and empty server to one supporting multiple chat rooms, each of which can host one specific game:
Phase One: Read the ggzd.conf file from SYSCONFDIR. The file to read can be determined at runtime with the --file=/path/to/conffile option. This feature is most notably used when testing a new configuration.
The same line parser is used throughout the configuration process. It is relatively simplistic, much like strtok(), but processes an entire line in a single shot. It then sets two module variables 'varname' and 'varvalue' to the appropriate contexts from the configuration line. The file parsers can then use these strings to configure various run-time variables.
Phase Two: Scan all the game description files and parse those which have been signaled as in use by the main configuration file.
Phase Three: Scan all the room description files and parse those which have been signaled as in use by the main configuration file. These must be processed after the game files, as each room will host a game which is already loaded by phase two.
The actual contents of the configuration files is discussed in the server administration documentation.
The server will need to store a database of user ID, name, password and permission at the very least. This system must allow searching by name or ID, and allow for easy addition/deletion. GGZ can use libdb for this. A SQL database is possible too but probably not necessary for most installation. Both PostgreSQL and MySQL are supported at this point.
The message of the day is read at initialization time from a file pointed to by the MOTD configuration file option. The file can consist of up to 80 lines (this is configurable at build via MAX_MOTD_LINES).
The message of the day file can contain % specifiers which are replaced by the server before sending to the client. The following codes are supported:
%a - Server administrator's name
%C - Server cputype (according to last kernel build)
%d - Current date on server
%e - Server administrator's email address
%g - Current number of game tables
%G - Current number of game tables with free seats
%h - Server's hostname
%o - Server's OS name
%p - Port number for this server
%t - Current local time on server
%u - Current server uptime statistic
%U - Current numbers of users on system
%v - Version of running server
Since the game modules are dynamic, it makes sense to store the statistics on a per-game type basis, rather than on a per-user basis. Statistics are currently handled by ggzdmod, independent from ggzd. Several types will be supported eventually, some of them are already implemented, e.g. win/loss or ELO.