Tic-Tac-Toe explained

Tic-Tac-Toe is the most simple game for GGZ. The protocol is simple, the server is well documented and allows for disabling most features at compile time, and the corresponding clients exist for each toolkit and programming language. An alternative server written in Ruby emerged in addition to the default one written in C. Hence, Tic-Tac-Toe is the ideal game for learning GGZ game module development.

The protocol

The TTT protocol consists of 7 messages from the server to the client and 2 messages for the other direction. It is formally documented in an XML file named tictactoe.protocol for use with GGZComm.

The server sends the seat number and the assignments of all seats to each joining player. It then requests a move from the player whose turn is active, and waits for the move message. The move is then responded at by the server again, and broadcasted as a move message in case it was successful. During the game, the client might request the board synchronisation, for which a corresponding server message exists. Finally, a game over message can be broadcasted by the server.

The server

All in all, the TTT server consists of 675 lines of C code. But how much of an effort does it really involve? The server is made up of four components: The initialisation code, the game logic, the network interface and the artificial intelligence (AI).

Initialisation code

The main() function, defined in the file main.c, already handles the game startup including GGZ initialisation. Among other things, it calls game_init() which is defined in game.c and handles some more internal variables. Depending on the compile-time configuration, the TTT server might or might not support the following in addition to a basic two-player TTT game: unlimited number of game spectators, a bot player (replacing a human), resuming interrupted games, player statistics, savegames, and individual bot players, meaning that they are assigned a name and will have certain unique properties and difficulty levels. In addition, it is prepared for offering the game initiator to play another game, although this is not implemented yet.

Game logic

This term covers a lot of small actions. Whenever someone joins a game, some data is sent and/or internal variables are modified. When a move message is read, it is evaluated and the server acts according to the result. Similar in nature, after each move the game state is evaluated, as each move might lead to the game-over status. The selection of the next player depending on the current turn is part of the game logic, too. All of it is contained within the file game.c.

Network interface

All network handling is abstracted away in the auto-generated file net.c. Some functions of it (ggzcomm_*) are called from game.c, and in return some callback handlers are invoked from it whenever network data has been read or an error occurred. Using ggzcommgen, the network support can be updated easily.

AI player

The file ttt-ai.c contains a single exported function, ai_findmove(), which is all that is needed to let the AI determine its next move. Having the AI separated is useful for other game server implementations which do however share the AI routines to avoid code duplication.

The client

There are five clients so far: for the command line (TTTXT), for SDL with OpenGL (TTT3D), and desktop-affine ones for Gtk+ and KDE. The last one is a client without any GUI, which is used by Grubby, the GGZ chat bot, and is named Guru-TTT. Depending on the preference for toolkit and programming language, studying one or more of the above will help into getting into the client side of GGZ game module development, using the simple TTT game as example.
Josef Spillner, 27.12.2005, updated 06.01.2007