Loading ...
Sorry, an error occurred while loading the content.

Re: game info properties

Expand Messages
  • Robert Jasiek
    Concerning character sets, the property in FF[4] is CA[]. But I still don t know how to use this for Asian sets. Also there is the character encoding problem,
    Message 1 of 5 , Dec 10, 1998
    • 0 Attachment
      Concerning character sets, the property in FF[4] is CA[].
      But I still don't know how to use this for Asian sets.
      Also there is the character encoding problem, as others
      have mentioned.
      ***

      > Date DT[]:
      > How do we record a certain period of time?
      > E.g. Played from 1998-01-09 to 1998-04-12

      Currently, I would suggest to use
      ;DT[1998-01-09]C[Played from 1998-01-09 to 1998-04-12]

      > How do we record "played in early Qing era"?

      ;C[played in early Qing era]

      Both ought to be in the root node of the game.
      (Or is it better to use a game comment property for this purpose?)

      > Time TM[]:
      > How do we record players having different times?

      Certainly, this must be possible somehow.

      > How do we record traditional handicaps?
      > E.g. "sen-ai-sen" (BBW)

      ;C[sen-ai-sen]

      This is in a root mode.
      Together with a difficult date:

      ;DT[1998-01-09]C[Played from 1998-01-09 to 1998-04-12\nsen-ai-sen]

      > Result:
      > Is RE[Void] a good expression for unfinished games?

      IMO, for the standard case of a "no result" game under Japanese rules
      it is good.

      > (think of all the possible causes why the game was
      > not finsihed)

      Before realization of FF[4] I suggested another result "Suspended".
      However, there are more possibilities like
      - no result due to constant game end (e.g. on IGS after currently
      1000th move)
      - loss due to constant game end
      - loss due to no possibility to move (e.g. Conway rules)
      - adjourned game
      - net breaked game

      And then we have special results like

      > How do we record a game where both players lost?

      or
      - both players forfeit

      If you liked all possibilities within RE[], I would make a thorough
      list.
      Else special cases could be included in the root's C[]. Still, it is
      much more convenient for server programmers to have explicit results
      of the type RE[W+Adjourn], IMHO:)

      --
      robert jasiek
      http://www.snafu.de/~jasiek/rules.html
    • Arno Hollosi
      ... The current system doesn t support multi-player games at all. I would suggest creating a game-specific move property. E.g. MV[player:move]. This way you
      Message 2 of 5 , Dec 11, 1998
      • 0 Attachment
        Dave Dyer wrote:
        > I"d like to use SGF to represent a game for four players.

        The current system doesn't support multi-player games at all.
        I would suggest creating a game-specific move property.
        E.g. MV[player:move].
        This way you can have unlimited number of players with only
        one property. It wouldn't disturb the current standard, as
        this is a game-specific property and would not be used in other games.


        About Robert's / William's point of view:
        > let me first say that I agree with Robert Jasiek in that a lot
        > of things should be put in general comments. IMHO, most
        > properties are for machine-readable-and-understandable data

        I understand that point. On the other hand think about people
        maintaining large archives, and using scripts or other programs
        to manage them. Let's take dates (DT[]) as an example.

        I agree that any date that can be given in ISO format should
        be listed that way, e.g. "1998-03-02" instead of "March 2nd, 98".
        But there are dates that can't be listed as ISO as the example
        "played in early Qing eara" shows.

        Moving these "non-standard" informations into the Comment field
        (actually I would suggest GC[] instead of C[]) makes them
        difficult to handle for archive/database applications.

        What John Fairbairn suggested (and what I find quite reasonable)
        is that we should have mandatory formats for information that
        can be strictly defined, such as game-results or (western) dates.
        But that we allow "non-standard" information in these game-info
        properties as well, such as DT[early quing eara], but only in those
        cases which are not covered by the specification.


        About marking with TB[]/TW[]:
        I don't see an easy solution. I'm reluctant to introduce new
        properties. And as Robert pointed out, it depends on the rules,
        if the stone is counted or not. Which in turn requires that the
        player should have captured the stone, to get the point.
        And yes, it might fall into the "it's-so-rare-that-who-cares"
        category :o)


        /Arno
      • Robert Jasiek
        ... The players should be introduced in the root, thereby get an automatic ordering 0,1,2,.., and referred to by their numbers to keep the file length short:
        Message 3 of 5 , Dec 11, 1998
        • 0 Attachment
          > MV[player:move]

          The players should be introduced in the root, thereby get an
          automatic ordering 0,1,2,.., and referred to by their numbers
          to keep the file length short: E.g. player_2 plays at fh:
          MV[2:fh]
          But is this at all necessary? So far I have only seen fixed
          order of players during an entire game. So introducing this
          order once in the root should be enough. Then just use MV[fh].
          Why do we have B[] and W[] at all, except for backward compability?
          To allow dull variations like black may move once twice?

          > On the other hand think about people
          > maintaining large archives, and using scripts or other programs
          > to manage them. Let's take dates (DT[]) as an example.>
          > I agree that any date that can be given in ISO format should
          > be listed that way, e.g. "1998-03-02" instead of "March 2nd, 98".
          > But there are dates that can't be listed as ISO as the example
          > "played in early Qing eara" shows.

          Do you suspect that programs would manage DT[played after Qing aera]
          correctly if used for interpretation rather than citation? I severely
          doubt this. Also not every program will swap YYYY, MM, DD fields in
          a window to a misc_text_interpretation_date field. So whether
          non-interpretable data are in GC or DT is immaterial, ALA SGF allows it.
          I can also live with a non-standard DT option (everything that is not
          ISO).

          > What John Fairbairn suggested (and what I find quite reasonable)
          > is that we should have mandatory formats for information that
          > can be strictly defined, such as game-results or (western) dates.
          > But that we allow "non-standard" information in these game-info
          > properties as well, such as DT[early quing eara], but only in those
          > cases which are not covered by the specification.

          This should be fine for all. Besides it resolves current misuses:)

          > it might fall into the "it's-so-rare-that-who-cares"
          > category :o)

          It is not that rare. Molasses ko at a Japanese game end would be.
          On a related matter, IMO programmers should be much more careful
          in evaluating life and death at the game end, if at all. I have
          seen advanced CG programs that score the human opponent's live
          groups as dead and do not allow manual correction, etc.

          --
          robert jasiek
          http://www.snafu.de/~jasiek/
        • David Fotland
          ... I allow arbitraty text in the date field, since lots of old files have strange date formats. In my GUI I have 4 fields: Year ____ Month _____ Day
          Message 4 of 5 , Dec 11, 1998
          • 0 Attachment
            At 02:29 PM 12/10/98 +0100, you wrote:
            >From: Arno Hollosi <ahollosi@...-graz.ac.at>
            >
            >
            >Hi again,
            >
            >here are some questions that came up in emails
            >with Jan and John Fairbairn.
            >
            >Date DT[]:
            > How do we record a certain period of time?
            > E.g. Played from 1998-01-09 to 1998-04-12
            >
            > How do we record "played in early Qing era"?

            I allow arbitraty text in the date field, since lots of old files
            have strange date formats. In my GUI I have 4 fields:

            Year ____ Month _____ Day _____ Date ________

            If I recognize the date and can convert it to yyyy-mm-dd format,
            I do so, and display it in the year/month/day fields. If I can't
            recognize it, I display it in the date field. If the user starts a game and
            uses the year/month/day fields I use that data, but the user can still enter
            arbitrary text in the fourth field.


            >
            >Time TM[]:
            > How do we record players having different times?
            > E.g. pro vs. amateur
            > Should we merge TM & OT (and remove OT), as TM[] is one
            > of the entries which is most often not formated according
            > to the specs?

            I treat the TM property as arbitrary text and let user type whatever he
            wants there
            (like "10 hours each", or "1 minute, plus 10 moves per 10 minutes").

            I don't use the OT property.

            >
            >Handicap HA[]:
            > Should we allow HA[0]?
            > How do we record traditional handicaps?
            > E.g. "sen-ai-sen" (BBW)

            I have no objection to HA[0].

            Traditional handicaps cover more than one game, and an sgf file is a single
            game. I
            think using comments is good enough for this. "In this game XXX played
            black, with BBW
            handicap used over several games".

            >
            >Players:
            > How do we record rank and names of players of
            > a rengo or team go game?

            I would use PB and PW, listing all of the black player's names in PB. I
            think about the
            format from the GUI point of view. I don't want to clutterup the interface
            with extra text
            fields for player names when they are hardly ever used. The names can be
            arbitrary length,
            so there no reason not to put the entire black team's names there.

            >
            >Result:
            > Is RE[Void] a good expression for unfinished games?
            > (think of all the possible causes why the game was
            > not finsihed)
            > How do we record a game where both players lost?

            I would leave the result off and explain it using a comment.

            David

            >
            >
            >I didn't add possible solutions to that problems, because
            >I'm curious about the ideas you come up with.
            >
            >
            >Ideas welcome
            >/Arno
            >
            >------------------------------------------------------------------------
            >Help support ONElist, while generating interest in your product or
            >service. ONElist has a variety of advertising packages. Visit
            >http://www.onelist.com/advert.html for more information.
            >------------------------------------------------------------------------
            >Sent through the SGF mailing list at http://www.onelist.com/
            >SGF spec: http://www.sbox.tu-graz.ac.at/home/h/hollosi/sgf/
            >Moderator: Arno Hollosi <ahollosi@...>
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.