tbray@mprvaxa.UUCP (Tim Bray) (01/30/84)
x <-- USENET insecticide Hi - The enclosed is an attempt to help out with the board representation and game transmission issues. The next posting to net.games.go consists of the source for a pair of programs, namely: 1. encode - take a picture of a go board and produce a highly compressed (200 byte) representation. 2. decode - the opposite. The posting includes the header file go.h. Go.h has #defines for the character representation of a white stone, a black stone, a clear point, a handicap point, and what the border of the board should look like. Tailor it and make your board look the way you like it. This effort was dashed off in a couple of hours to regain my sanity as a refreshing change from struggling with the dreaded 4.2bsd conversion. It works as far as I can tell. It does very little intelligent error handling. I tested the version on the VMS DEC C compiler with no problem, so it should be portable. NOTE - I am NOT at all a go expert, just a dabbler who enjoys a few games a year, mostly for lack of acquaintance with other go beginners. Therefore it is quite possible that these programs contain architectural insconsistencies with some advanced aspect of the game of go with which I am not acquainted. Functional description: encode - reads from its standard input a file containing a picture of a go game. The representations for stones, points, and handicap points must match those in go.h. The bottom line must contain a count of black and white captured stones in a hard-coded format. encode writes on its standard output a group of 200 bytes. The first (19*19)/2 + 1 bytes are ascii hex digits each of which encodes the state of two points on the board. Following this are the ascii captured stone counts. decode - reads 200 bytes from its standard input. These are assumed to contain a board representation as produced by encode. decode writes on its standard output a picture of a go game with the representations for the stones, points and board specified in the file go.h. The last line contains a count of captured white and black stones. Usage - create a file containing 200 ascii 0's, run it through decode to get yourself a blank board to start with. Then edit it, encode it, send it off. bugs - board representation should be in a control file, not compiled in. The level of commenting is pitiful, something for which I regularly flame my co-workers. important bug - The representation should include a specification of whose move it is for completeness and what the last move was for convenience. I may even do this. Have fun, and do send me any improvements or fixes. Especially, I would like to see particularly elegant board representations (settings in go.h). So far, I am impressed neither with my own nor with any seen so far in this group. Tim Bray ...decvax!microsoft!ubc-vision!mprvaxa!tbray