![[F9]](http://portal.f9.net.uk/images/header/f9-header_logo.gif){kind=logo}
As I write this, the latest version of Tourk is the Alpha-grade 2002-Aug-09. Since it is still very much under development, you'll need this document to work out what is going on.
Tourk uses (or rather, plans to use) conforming ISO C code, so it should work on any C compiler that claims standards compliance. However, the build system does use a bit of Unix.
If you use MS Windows, I recommend Cygwin. (Make sure you include gcc, binutils and make.) Cygwin supplies a Unix-work-alike layer, which runs at the same time as Windows. (I developed Tourk using cygwin.)
The bug trackers, support trackers and source code management are all hosted on Sourceforge. If you have not already joined, please do so.
Download the latest sources from Sourceforge, and expand the tarball into a convienient location. (A single top level directory is included.)
The tarball contains these subdirectories;
The files in tourcon are shared between all games. Combine all the files in tourcon with all the files in boxes or rummy, you get a complete program.
If you use Unix or Cygwin, the rumdev and boxdev directories are ideal for working in, as they contain symbolic links to all the required files. If you modify (say) tourcon.c, the change is reflected in the other games, as the file is shared.
If you use cygwin-less-MS Windows, or indeed any operating system without symbolic links, you'll need to copy the tourcon files into the rummy or boxes directory. Alternatively, check if your build system allows you to bring in files from many directories.
tourcon.c derives much of it's behaviour from the header file from the specific game controller. So this file can be shared without modifications, it attempts to #include a file from the specific game controller which is allways called "thisgame.h". The purpose of "thisgame.h" is only to #include the real game controller file.
If you use the Makefiles supplied with version 2002-Aug-09, you may need to adapt the CFLAGS variable. The Makefile sets CFLAGS to "-Ae -g", which roughly means ANSI+extensions on various Unix C compilers.
However, if you use GCC, these are the wrong options to use. If you get an error, ( *Initialization*:1: missing token-sequence in `#assert' ) then this probably means you need to change the command line options.
For GCC, use this command line;
make CFLAGS="-Wall -O3 -g"
The PLAYERS variable may also need adapting. It lists the player names by
filename, without the usual ".c" suffix. You may prefer to edit the Makefile
by listing your own players, or simply change the value on the command line, in
a similar way to CFLAGS above.
make PLAYERS="random random2 myfunkyplayer"
(Note, if you can use the supplied Makefile, then all this should be automatic. This information is supplied for those who cannot.)
All games require a header file called "builtins.h" which list all the supplied builtin players. (All players are builtins for now.)
To generate this file, you need to compile and run a utility called "genbi", supplied as "genbi.c" in the tourcon directory. This utility will go through all the files in the current directory and look for player code. (By the presence of a #define PLAYER_NAME directive.)
genbi uses the POSIX functions opendir(), readdir() and closedir(). If you cannot compile it because you do not have these functions, then you can either modify genbi to use your operating system's directory functions, or manually create "builtins.h" yourself. (An example builtins.h.)
If you do create a local form of genbi, please send me a copy.
As well as this, the rummy game controller also requires a file called "bitarray.h", which is generated by "genarray.c". The result of this file is fixed for now, so until furthur notice, if you are having trouble running genarray, you may as well use this copy.
Once you have compiled rummy or boxes, you may run it from the command line. (A gui is planned.)
In these examples, the rummy executable is used, but boxes will work just as well.
Note that -g and -s may be combined, but only the first game will use the supplied seed. (Playing with the same seed and the same players should produce the same outcome.)
Specific game controllers may also have provided thier own command line options. If the tourcon code cannot recognise a command line option, it is offered to the game controller. (Both rummy and boxes do not use this facility.)
As well as these options is the -dn option, for specifying the debug level. This is detailed in the next section.
| Level | Use | Generated by |
|---|---|---|
| 1 | Final results of tournament | Tourk core |
| 2 | Results of each individual game | Tourk core |
| 3 | Turn by turn commentary | Specific game controller |
| 4-9 | Reserved for the player code | Players |
Player code does not get the opportunity to use the I/O system, but a programmer needs to know how their code is working.
Single steppers may be used, but the player may choose to generated debug strings instead. To do this, the player code should call a function debugmsg(), which works in a similar manner to printf().
void debugmsg(int level, char *fmt, ...);
level is the priority level of this message. fmt is the printf style format string. As with printf, you can put any number of variables and values after the format string.
When the user runs the executable, they may choose how much debug they want to see. For example, -d2 asks that only level 1 and 2 debug is collected.
To indicate that you do indeed want to see certain level of debug, use -d followed (no space) by the requested debug level. The generated debug will be written into a text file, named "game-player.txt".
Never mind, to seek help...