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

game info properties

Expand Messages
  • Arno Hollosi
    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
    Message 1 of 5 , Dec 10, 1998
      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"?

      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?

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

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

      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 didn't add possible solutions to that problems, because
      I'm curious about the ideas you come up with.


      Ideas welcome
      /Arno
    • 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 2 of 5 , Dec 10, 1998
        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 3 of 5 , Dec 11, 1998
          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 4 of 5 , Dec 11, 1998
            > 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 5 of 5 , Dec 11, 1998
              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.