[net.games.go] Comments on Macintosh Go program...

myers@uwmacc.UUCP (Jeff Myers) (03/02/86)

First I'd like to congratulate the author for a fine visual representation of
the board and stones.  There are some things that I would like to see cleaned
up, though, to make the game much more useful.

(1) There should be a utility for taking back the last move, maybe to a depth
of six moves back.

(2) The log utility should not work as it does.  Currently, if you want to
continue a game logged previously and keep logging it, there is no way to do
it with the same log file (that I have figured out, anyway).  When a log file
is established, there should be an option to completely record the current
state of the game rather than automatically just starting from scratch.  When
a log file is read in, you should be forced to specify exactly how many moves
into the game (default: the whole way) to auto-play to; then by default you
should be logging the game to that same file.  To make life easier for the
logging function, why not just ask when exitting the game whether the current
board should be saved?

(3) The default game option should be human vs. human rather than computer
vs. computer.

(4) The debugging display options should be removed from the distributed
version of the game as the output is pretty cryptic.

(5) There should be an option to display the number of stones captured thus
far by each side.  An end-of-game score counting option would be nice, but
might be a bit tough to code.

-- 
Jeff Myers				The views above may or may not
University of Wisconsin-Madison		reflect the views of any other
Madison Academic Computing Center	person or group at UW-Madison.
ARPA: uwmacc!myers@rsch.wisc.edu
UUCP: ..!{harvard,ucbvax,allegra,topaz,akgua,ihnp4,seismo}!uwvax!uwmacc!myers
BitNet: MYERS at WISCMACC

howie@cucca.UUCP (Howie Kaye) (03/03/86)

The sources to this never seemed to make it to Columbia.  Could someone
either repost them, or mail them to me?

-- 
Howie Kaye				Sy.Howie@CU20B.ARPA             
Columbia University 			HKAUS@cuvma (bitnet)          
Systems Integration Group		{?}!seismo!columbia!cucca!howie

mcb@styx.UUCP (03/06/86)

In article <2013@uwmacc.UUCP> myers@uwmacc.UUCP writes:
> First I'd like to congratulate the author for a fine visual representation of
> the board and stones.  There are some things that I would like to see cleaned
> up, though, to make the game much more useful.

Please add my congratulations, too! 

> (1) There should be a utility for taking back the last move, maybe to a depth
> of six moves back.
> 
> (2) The log utility should not work as it does.  Currently, if you want to
> continue a game logged previously and keep logging it, there is no way to do
> it with the same log file (that I have figured out, anyway).  When a log file
> is established, there should be an option to completely record the current
> state of the game rather than automatically just starting from scratch.  When
> a log file is read in, you should be forced to specify exactly how many moves
> into the game (default: the whole way) to auto-play to; then by default you
> should be logging the game to that same file.  To make life easier for the
> logging function, why not just ask when exitting the game whether the current
> board should be saved?

I've also noticed that it does not seem to be possible to interrupt
the replay of a logged game. This might be nice, particularly if after
a few moves of a 280-stone game you decide the replay isn't worthwhile.

> (3) The default game option should be human vs. human rather than computer
> vs. computer.

I'd go with computer vs. human as the default, actually, as the most
common use.

> (4) The debugging display options should be removed from the distributed
> version of the game as the output is pretty cryptic.
> 
> (5) There should be an option to display the number of stones captured thus
> far by each side.  An end-of-game score counting option would be nice, but
> might be a bit tough to code.

We didn't get the source, having no compiler on the Mac, but I think a
scoring module whouldn't be that difficult to implement, assuming the
program has been keeping track of the ownership of unoccupied points
and of the numbers of prisoners captured. No physical rearrangement of
the stones to facilitate scoring (as is usually done by humans) would
be necessary. I've also noticed (at least in the version we got) that
the game does not end when both players pass; it just puts up "your
move" and waits for black (the human) to play.

Again, a fine effort and a wonder to see implemented on the limited memory 
and speed of a Macintosh!

Michael C. Berch
ARPA: mcb@lll-tis-b.ARPA
UUCP: {akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!mcb

greg@unlv.UUCP (03/07/86)

In article <181@cucca.UUCP> howie@cucca.UUCP (Howie Kaye) writes:
>
>The sources to this never seemed to make it to Columbia.  Could someone
>either repost them, or mail them to me?

	or here either...
						--Greg
						 seismo!unrvax\
							       !unlv!greg
						hplabs!parcvax/

timo@boring.uucp (timo krijnen) (03/10/86)

Nice implementation indeed.

But why does nobody mention the nasty bug:
a stone that has taken from the board is not marked as removed in
the internal administration, making it impossible to put another
stone there. You just get: `bad move' in the log.

And it definitely should end the game in a reasonable way (three consecutive
pass's as official, and/or via some I give up, gimmie the count thus far).

No source arrived here yet either...

-- 
 Timo Krijnen
 CWI (Center for Math. & Comp. Science), Amsterdam
 ...{decvax,philabs}!mcvax!timo

sakw@cvaxa.UUCP (03/13/86)

Yes, I think it's a neat program too. But.....

1) in human vs computer mode (the only one I've tried so far), when I pass
   the program removes the last stone IT has played from the board display.
   However the stone still seems to be there 'cos it won't let me play on
   that point. Makes the game more interesting I suppose (whenever it's losing
   it goes into "kriegspiel" mode :-).

2) I find the board background distracting and some of the numbered moves are
   illegible. With a bit more work, this program can double as a move
   recorder/editor.  The British Go Journal is prepared on a Mac, and I think
   the editor will find a use for this. (If only they had PageMaker and a
   LaserWriter.)

3) The move logging is a bit verbose. How about a 2-col format as used for
   chess? Alerts etc should be displayed in alert/dialogue boxes and not in
   the log.

4) Yes, I agree with the others that there needs to be a way of finishing
   the game. After a while both the Mac & I passed but it still wouldn't stop.

Keep up the good work!
-- 
Sak Wathanasin, U of Sussex, Cognitive Studies, Falmer, Sussex BN1 9QN, UK
uucp:...mcvax!ukc!cvaxa!sakw  arpa/janet: sakw%uk.ac.sussex.cvaxa@uk.ac.ucl.cs