Gtkboard developer documentation

This is the developer documentation for gtkboard version 0.10.0. The end-user documentation is here.

[ Home
Project page
Contact ]

Gtkboard philosophy

No duplication. The raison d'etre of gtkboard is to reduce the duplication of effort involved in writing hundreds of board games. Therefore, anything that is common between two or more board games must be implemented by gtkboard and available to all games.

Allow games to be created incrementally. Just because a feature exists, a game shouldn't be forced to do something about it. Thus, when writing a new game you can concentrate on exactly what you need and ignore the rest. For instance, you can make a new game compile and display the board without writing any code, just specifying the dimensions, colors and images for the pieces. (Several common pixmaps are available for reuse.) Further, the user can already replay a game from a file -- the game doesn't need to implement anything.

Homogenize. If two games require a thing to be done in slightly different ways, see if both can be expressed as special cases of a more generic way, and the differences expressed in data rather than code. That way, if a new game required the thing to be done in a third way, it is more likely that it can be accomodated without modifying the existing code. This principle is related to the next one.

Generality is more important than efficiency. This is an application of the maxim that premature optimization is the root of all evil. For example, the AI of some games would probably become somwhat more efficient if the search strategy incorporated game specific information, and the evaluation function and the move generation function were tightly coupled. However, the extra complexity is judged to be not worth the gain in efficiency.

TIMTOWTDI. There is more than one way to do it. As far as possible, nothing will be forced on the games. Everything is a hook. The game can choose from among the defaults or provide its own. For example, three defaults are provided for ordering the highscores: decreasing order of score, increasing order of score and decreasing order of time. The game can use one of these or write its own.

Client-server model. This is the most important part. Gtkboard is currently implemented as a pair of processes, one for the ui and one for the number crunching, which communicate through a pair of pipes. This has several benefits:

TODO: complete this

Writing a new game

This is a simple step-by-step guide to get you started writing a new game.

Creating a plugin

To make a plugin follow the same steps as above, but also add a line Game * plugin_game = &Yourgame; to yourgame.c, and compile yourgame.c with the -static flag to create a .so file. The -G option for gtkboard allows you to specify the plugin file to load.

How you can help

Here's a list of ways you can help gtkboard:

Coding style

You are requested to follow these guidelines if you intend to contribute to gtkboard. Well that's it I guess. And also keep in mind the general words of C wisdom, like remember to free() everything, use snprintf rather than sprintf, use lots of assert()s and that sort of thing. So far the code's been rather clean, I've never had a gdb session longer than a couple of minutes, let's keep it that way :)

Gtkboard features

Features currently provided by gtkboard

Features coming real soon now


The current priority is to get a stable 1.0 release out.

The main things that have to be done before this are:

The last is very important, because at 1.0 we will freeze the game API. Until then it will be fluid. We hope that a huge number of games will be written for the 1.0 release, and also that some major distros will include gtkboard 1.0 :) Therefore the API should be complete enough that almost anything that can be called a board game should be implementable in gtkboard.

Post 1.0, our focus will shift to two things:

Of course all this is kinda the best case scenario since gtkboard is entirely a spare time/hobby project.

Valid HTML 4.01! Created with vim Logo