| Author |
Message |
Mark Thompson (Markt)
| | Posted on Sunday, January 12, 2003 - 4:14 pm: | |
I think it was David Bush who suggested in another conversation adding the ability to save variant lines in the ZSG. I like the idea and have thought about how it might be implemented.
The main line is currently stored something like
1. blah
2. blah
3. blah
A variant line branching at move 3 and continuing till move 5 could be stored with labels like
1. blah
2. blah
3. blah
3.1 blah
4. blah
4.1 blah
5. blah
5.1 blah
6. blah
7. blah
... where the .1 moves are the variant line. A second variant on the main line would be numbered with .2 labels, regardless of which move it branches out from. A variant within variant 1 would be labeled with .1.1 numbers:
1. blah
2. blah
2.1 blah
3. blah
3.1 blah
4. blah
4.1 blah
5. blah
5.1 blah
5.1.1 blah
... so here, 5.1 would be the "main" move following 4.1, and 5.1.1 would another alternative.
There would also need to be two more buttons on the toolbar. Currently there are four,
>>
I would add a down arrow (v) and an up arrow (^):
>>
Pressing the down arrow on move 10 would (temporarily) blank out the moves after move 9 on the move list frame. If the user entered a move, it would be listed as 10.1. If there was already a variant line branching from move 10, the down arrow would display that line. The up arrow would navigate back to the main line.
Maybe the line numbers where a variant branches out would have to be labelled with "+" signs in the move list frame:
1. blah
2. blah
3. blah
+4. blah
5. blah
6. blah
means there is a branch on move 4, so putting the cursor on 4 and clicking the down arrow would move into that variant. |
David J Bush (Twixter)
| | Posted on Sunday, January 12, 2003 - 4:29 pm: | |
This might work, but why re-invent the wheel? That's why I mentioned SGF format, which is specifically designed to record game trees, and is described much more clearly and fully than I could, at http://www.red-bean.com/sgf/
There might be more there than Zillions would need, but just use what you want from it. SGF format could make the notation more palatable to other software. Anyway, this would be up to the Zillions developers, not us. |
Jeff Mallett (Jeffm)
| | Posted on Monday, January 13, 2003 - 8:47 pm: | |
I've actually written a program before that reads/saves/navigates game trees and allows users to add/modify/delete/annotate branches, so I'm familiar with the issues. In this case it was a chess program for the Mac that I never bothered releasing. My save format was designed to be human readable, much like PGN (which the program also read/saved.) One thing I don't care for about SGF is its syntax makes it not so human-readable, although I do like its flexibility. Another possibility is to define a grammar in XML. |
David J Bush (Twixter)
| | Posted on Monday, January 13, 2003 - 9:34 pm: | |
Whichever way you want to go would be fine with me! If you are concerned with human-readable moves, Matthew Burke's idea (in the recent thread on annotating games) seems plausible; it would place the burden of defining a more compact string on the programmer of the ZRF for that particular game. Cascade moves could not be represented by that method, but all cascades should be uniquely determined from the generating move and the game rules, I think. Zillions probably wouldn't be able to read such user-defined notation, but it wouldn't have to. |
Eric Wald (Breadman)
| | Posted on Wednesday, May 21, 2003 - 11:22 pm: | |
While you're at it, any new notation should handle captures more fully, to speed up taking back a move. Granted, it's not always that useful, but certain games can generate thousands of moves. |
|