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