Observed match recording standards. & Formal standard???
Mark Damish
In article <1994Oct29....@ohstpy.mps.ohio-state.edu> vanc...@ohstpy.mps.ohio-state.edu writes:
[...]
>Yeah. Part of the problem is that over the past years FIBS has gotten
>ALOT of support from developers and users, the end result being a
>state-of-the-art BG server with tons of protocols. Of course, I
>don't know what those protocols are! I have an old 'raw board'
>protocol, but I don't know if it has been changed. I will be happy
>to incorporate any protocols, as long as someone tells me what they
>are.
>
>Secondly, like I said before, I intent on donating the NetGammon code
>to the Net (with the normal "if you use my code to make money I am
>entitled to royalties" restriction) in the near future, I so believe
>it or not, it is worth spending your time helping me to develop
>to whatever 'standards' are out there these days.
>-Garrett
Garrett,
One thing that FIBS doesn't have that you (or fibs) could implement that
would be nice is a way of obtaining a copy of a MATCH in STANDARD format.
The way that GEnie implements this is nice: They archive all completed
matches for a period of about 1 week. Anybody may download a match
of interest during that time frame. Besides ones own matches, it would
be great to download matches of very good players after they had been
played for personal study, or to obtain large collections of such matches
for statistical study.
If you have any modern backgammon match books about, you can get an
idea of how matches are represented in print. For computer matches,
numbering each move, with one move per line is probably easiest to
impliment. Briefly:
-- The board is numbered from 24 to 1 from the rollers point of view.
ie: the numbering changes every turn, with the lower numbers
represing the rollers home board.
-- If a two column format is used, the players are in the same column
in sucessive games, regardless of who moves first. If they are assigned
'X' or 'O' or 'White' or 'Black', they maintain this designation for the
entire match
-- Dice rolls are a pair of numbers, often with followed by a ':', sometimes
in parenthes. ie: 31: is a roll of 3 & 1. I personally prefer NOT
to seperate rolls (or moves) with dashes, as when match info is cut
and pasted into word processers, sometimes the information is broken
accross lines. Non rolls (closed out) are often indicated by two
dashes ie: '--:' or '--'.
-- Moves:
Some people use 'landing point' format, while others use 'from' notation.
And opening 32: would be written as '5 5' in landing point notation, and
as '8/5 6/5' in from-to notation. Again I'm showing my preferance against
'-' as a seperator. If a checker is using more than one die in a move
the intermediate landing spot doesn't need to be represented. ie:
'64: 24/14' (from-to) or '64: 14' (landing pt). It certainly doesn't
hurt to write the entire move: '64: 24/18 18/14' This may also be
written as one move: '64: 24/18/14'.
Non Moves are often written as '-' ie with 2 on the bar: '61: B/24 -'
or '61: 24 -'. '66: - - - -'.
-- Moving mulitple pieces at the same time may be represented by adding
a multiplier in parenthes after the move. ie: '66: 24/18(2) 13/7(2)'.
or '66: 18(2) 7(2)'. Again, to aid in the simplicity of the format
all four dice moves may be indicated seperately.
-- Illegal moves need to be accounted represented and indicated.
-- Hitting. Hitting should be entered as part of the move with an '*'.
ie: making the 5-point and hitting a blot there: '31: 5* 5' or
'31: 8/5* 6/5'. A pick an pass in from-to: '65: 24/18*/13'.
-- Bearing off is usually represented by making the dstination 'O'.
ie: '12: 2/O 1/O' or '12: O O'. The number '0' may also be used in
place of 'O'.
-- Doubling and taking/passing should be counted as a move, and numbered
according to however may columns are being used (1 or 2).
-- Games should have the match score before the games begins, and a way
of determining the number of points won at the end.
-- Matches should have all of the pertinent information about players
names, Location, Date, match length available.
-- Formats. I think that it is best to encapsulate all of the games
within a match and the match info within one file. I've seen one
otherwise very good system take up enourmous amounts of hard disk
space as each 100-200 byte game took up a 16K cluster! A couple hundred
matches is only about a meg, but it takes 30M of disk space. Cluster
sizes tend to rise with disk size on DOS machines.
'Landing Point' only format with full abbrieviations in two columns is
essential for recording live matches with pen and pad. Most printed
matches are in 'from-to' format, also in two columns with full
abbrieviations. For computer generated, computer readable matches,
it could be argued that the simplist form ought to be used. IMHO this
would be a single column format, with each move numbered, and each
move of the die represented indivudually in the from-to system.
This is the easiest to parse, the easiest to convert to any other
system. For printed output, I believe that the 2-column, line numbered,
fully abbriviated, from-to notation is best. This leaves out any
ambiguity that might arise with the landing-pt only format.
Perhaps it is time to form a formal standard(s) for matches which will be
archived electronically. This standard(s) could be used for the archival of
matches played on electronic servers, computer games, as well as matches
played in the past and present and hand recorded by backgammon scribes or
recorded on video.
Once a match/game archive standard has been defined, it is likely to
find its way into programs capable of saving matches (clients, servers,
games, nn, etc...). Programs capable of importing games/matches might be
created to play back, hand annotate, or evaluate matches. Imagine being able
to feed your last match into a (now unavailable) expert level neural
net program, and have it's opinion of your 10 worst plays ready the
next morning?
After a database of high level matches becomes available it becomes
possable to do statistical searches of the database. Information like
the best possable 41: in 20,000 actual games, or the best responces
to opening rolls from a historical perspective would become available.
Soo...
Is a 'formal' standard electronic match archivel format(s) worth persuing?
It seems like it is, but wonder if the people creating public and 'for
profit' backgammon software will adopt it?
[tyrade ends with ball bouncing not knowing what to do or if to do anything
next]
...Mark
dam...@ll.mit.edu
Darse Billings
>Garrett,
> One thing that FIBS doesn't have that you (or fibs) could implement that
>would be nice is a way of obtaining a copy of a MATCH in STANDARD format.
>The way that GEnie implements this is nice: They archive all completed
>matches for a period of about 1 week. Anybody may download a match
>of interest during that time frame. Besides ones own matches, it would
>be great to download matches of very good players after they had been
>played for personal study, or to obtain large collections of such matches
>for statistical study.
I too think there is a real need for a method of recording gamescores
and match results. On IRC poker, there are programs that observe all
hands played, record raw data, and compile statistics into a database.
This source of information has proved to be very valuable, both to
individual players and to the Internet poker community as a whole.
For example, I was able to extract win statistics against each of the
opponents I had ever faced, thereby learning which players I do well
against and which ones have had my number. Armed with a better
characterization of their strategy, I was able to adjust my play and
improve my results.
Even more impressive was a statistical study of expectation and
variance as a function of the number of players in the game, done by
Michael Maurer. This analysis answered many long standing theoretical
questions, and simply would not have been possible without that
database of accumulated knowledge.
A facility for the collection of statistics and gamescores would be a
major asset to FIBS or Netgammon. With it, we could answer many
interesting questions that are intractable from a theoretical approach.
For example, what is the practical match equity for a given score,
between opponents of widely differing strength? How often do
alternative opening moves (such as slotting the five point) win, or
gammon, in practice? What is the best way to play to avoid getting
gammoned? How effective is the rating system in predicting the probable
outcome of a match? There are many more possible inquiries that could
only be answered by analyzing a large body of data.
I don't know the exact specifications of what would be needed, but even
a simple record keeping system would be a start, and could reveal what
other features would be useful for the future.
Of course, for now, there are more pressing needs for NetGammon, and
Garrett's limited time... Pragmatic issues, like line wrapping and
improved playing facilities, have to take precedence over the "nice
features".
I hope everyone will take some time to play on Netgammon, and contribute
to it's development. We will all be better off if there are two good
servers to share the ever-increasing load of users.
See you on sutr.novalink.com 3200 ! Cheers, - Darse.
--
char*p="char*p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Stephen Turner
|>
|> Soo...
|> Is a 'formal' standard electronic match archivel format(s) worth persuing?
|> It seems like it is, but wonder if the people creating public and 'for
|> profit' backgammon software will adopt it?
|>
It would be a nice idea, but as you say it's hard to 'enforce'.
Stephen R. E. Turner
Stochastic Networks Group, Statistical Laboratory, University of Cambridge
e-mail: sr...@cam.ac.uk WWW: http://www.statslab.cam.ac.uk/~sret1/home.html
Sale! 1/3 off! Example: Price #6 You Pay #4 You Save #2! (Shop in Cambridge)
Mark Damish
>In article <1994Oct31.1...@ll.mit.edu>, dam...@ll.mit.edu ( Mark Damish) writes:
>|>
>|> Soo...
>|> Is a 'formal' standard electronic match archivel format(s) worth persuing?
>|> It seems like it is, but wonder if the people creating public and 'for
>|> profit' backgammon software will adopt it?
>|>
>
>It would be a nice idea, but as you say it's hard to 'enforce'.
I think it would be more like 'incentive'. Most CAD/CAE programs are
capable of exporting or importing a common file format: .dxf. Most
text processing programs can embed a postscript (.ps or .eps) picture.
Most PC's use ASCII now. (My first one didn;t).
Currently EVERY program capable of saving or importing a match
or a game uses a differant format. The idea wouldn't be to change
the 'native' format of the program, just to add a 'portable' format.
I don't play chess, but it seems that they have 2 very well defined
formats. Programmers are free to invent their own formats, but since
there are accepted standards, it would be bane to ignore them.
I truely believe that if a standard for saving and importing matches
existed, and if only a couple of programs/clients/servers made use
of it, that it would proliferate and become part of future programs
and revisions to current programs.
I am currenty reviewing the strengths and weaknesses of the formats
used used by 'bg-scribe', 'matchqiz', 'fibs', 'exbg', and 'GEnie'.
I'm all ears for suggestions, and will continue with this when my
current workload lightens.
...Mark
dam...@ll.mit.edu
Muni Savyon
: In <397raj$3...@lyra.csx.cam.ac.uk>
: sr...@statslab.cam.ac.uk (Stephen Turner) wrote:
: > In article <1994Oct31.1...@ll.mit.edu>, dam...@ll.mit.edu ( Mark
: > Damish) writes:
: > |>
: > |> Soo...
: > |> Is a 'formal' standard electronic match archivel format(s) worth
: persuing?
: > |> It seems like it is, but wonder if the people creating public and 'for
: > |> profit' backgammon software will adopt it?
: > |>
: I'm willing to adopt it in FIBS/W, for what its worth. :-)).
That will be very helpful to use fibs/w excellent human interface
as an 'off-line match player' .
: -----------------------------------------------------------------------------
: Robin Davies Standard disclaimer for the self employed:
: Software Consultant This message does not neccessarily reflect
: Windows, NT, OS/2, DOS the views of the author.
: Applications and Device Drivers
: rda...@fox.nstn.ns.ca
: 1-(613)-231-2783
--
- muni . mu...@cibadiag.com
Robin Davies
> In article <1994Oct31.1...@ll.mit.edu>, dam...@ll.mit.edu ( Mark
> Damish) writes:
> |>
> |> Soo...
> |> Is a 'formal' standard electronic match archivel format(s) worth
persuing?
> |> It seems like it is, but wonder if the people creating public and 'for
> |> profit' backgammon software will adopt it?
> |>
I'm willing to adopt it in FIBS/W, for what its worth. :-)).