Individual Game Servers

As described above, game servers run in their own processes, and are responsible for handling the gameplay of a particular game.

There are three possibilities for game server design.

• Compiled in. The game table process calls a startup function which begins execution of the game server. This scheme has the benefit that the server has access to ggzd's data structures at the time the process was forked. Communication between the game table and ggzd can be via pipes or a socketpair. The problem with this scheme is that to change which games are offered by a particular server requires a recompile. Not good.

• Dynamically loaded modules. Similar to the above except that game server exist as loadable modules which may be inserted and removed at runtime. This allows for adding new game types without a recompile. Downside is that it requires both game developers and myself to know how to deal with loadable modules.

• Exec() separate program. In this scheme, GGZ acts much like the inet daemon by handling the connections and then doing a fork()/exec() to launch the game server. This scheme also allows for adding new games at runtime and has the bonus effect that game servers can be written in other languages that C.

The current design requires game servers of type three. It is possible however, that in the future GGZ will allow dynamically loaded server modules as well.

Once the game server is running it is necessary that ggzd pass it some required information such as player names and file descriptors. This communication occurs over a pipe or socketpair which is established prior to the forking of the process. The interactions between game modules and the control section are listed above in section 3.1.1.1.