Smart Game Format - Revision history

Selinger: Another small typo

2025-08-12T03:30:22Z

Another small typo

Selinger: /* Semantic rules */ Minor typos

2025-08-12T03:25:18Z

‎Semantic rules: Minor typos

Selinger: Some copy-editing, and added filename extension.

2023-01-08T14:16:33Z

Some copy-editing, and added filename extension.

Selinger: Some copy-editing.

2022-12-07T00:44:51Z

Some copy-editing.

Show changes

Selinger: Added descriptions of the main properties, and an example.

2022-12-06T23:52:22Z

Added descriptions of the main properties, and an example.

Selinger: Added some examples of trees.

2022-12-06T07:29:17Z

Added some examples of trees.

Selinger: Started adding some details on the SGF format. Not finished.

2022-12-06T06:41:38Z

Started adding some details on the SGF format. Not finished.

Halladba: inner link + headings

2008-12-03T22:37:11Z

inner link + headings

Halladba: cat. game record

2007-12-17T01:52:57Z

cat. game record

Halladba: cat. computer Hex

2007-12-17T01:46:51Z

cat. computer Hex

@@ Line 207: / Line 207: @@
 == External links ==
-You can find more info in the [http://www.red-bean.com/sgf/ Official Specifications Site].
+You can find more info in the [http://www.red-bean.com/sgf/ Official Specification Site].
 [[category:computer Hex]]
 [[category:game record]]

@@ Line 148: / Line 148: @@
 * Simpletext. This is arbitrary text, except that all whitespace characters including newlines are converted to spaces.
-The SGF format defines a large number of property names, but many are rarely used, not relevant to Hex, or not supported by current software. We only list the most common property values. Others can be found in the [http://www.red-bean.com/sgf/ official SGF specifications].
+The SGF format defines a large number of property names, but many are rarely used, not relevant to Hex, or not supported by current software. We only list the most common property values. Others can be found in the [http://www.red-bean.com/sgf/ official SGF specification].
 Users and applications are permitted to define their own private property names, as long as they do not clash with existing ones. A useful convention is for private property names to start with 'X'. Applications that read SGF files should ignore property names that they do not know about, and if possible, should preserve them (i.e., when writing the same file again).
@@ Line 167: / Line 167: @@
 * '''PB''', '''PW'''. Value: simpletext. The name of the black player and white player, respectively. Example: <code>PB[Bill LeBoeuf]</code>.
 * '''RE'''. Value: simpletext. The result of the game. If given, it must be one of the following: 'B+' or 'W+' for a black or white win, respectively, 'Void' for no result (such as suspended play), '?' for an unknown result. Optionally, the method of winning can be specified after '+', as follows: 'B+R', 'B+Resign', 'W+R', or 'W+Resign' for win by [[resigning]], 'B+T', 'B+Time', 'W+T', 'W+Time' for a win on time, 'B+F', 'B+Forfeit', 'W+F', or 'W+Forfeit' for a win by forfeit.
-* '''DT'''. Value: date. The date on which the game was played, in the format 'YYYY-MM-DD'. There is support for partial dates and date ranges; see the [http://www.red-bean.com/sgf/ official specifications site] for details.
+* '''DT'''. Value: date. The date on which the game was played, in the format 'YYYY-MM-DD'. There is support for partial dates and date ranges; see the [http://www.red-bean.com/sgf/ official specification site] for details.
 * '''EV'''. Value: simpletext. The name of the event, e.g., tournament. Example: <code>EV[2022 Mind Sports Olympiad]</code>
 * '''GC'''. Value: text. Background information on the game, or a summary of the game itself. This free-form text not usually interpreted by software.

@@ Line 1: / Line 1: @@
-The SGF file format is designed to store game records of 2-player board games. It's a text-only, tree-based format that was originally designed for the game of [[Go]], but has been adapted for a number of other games including Hex. Games stored in SGF format can easily be emailed, posted or processed with text-based tools.
+The Smart Game Format (SGF) is a file format for game records of 2-player board games. It's a text-only, tree-based format that was originally designed for the game of [[Go]], but has been adapted for a number of other games including Hex. Games stored in the SGF format can easily be emailed, posted or processed with text-based tools. SGF files usually use the filename extension <code>.sgf</code>.
 The main purpose of SGF is to store records of completed games, and to provide features for storing games that have been analyzed and annotated (e.g., board markup, comments, and variations).
@@ Line 167: / Line 167: @@
 * '''PB''', '''PW'''. Value: simpletext. The name of the black player and white player, respectively. Example: <code>PB[Bill LeBoeuf]</code>.
 * '''RE'''. Value: simpletext. The result of the game. If given, it must be one of the following: 'B+' or 'W+' for a black or white win, respectively, 'Void' for no result (such as suspended play), '?' for an unknown result. Optionally, the method of winning can be specified after '+', as follows: 'B+R', 'B+Resign', 'W+R', or 'W+Resign' for win by [[resigning]], 'B+T', 'B+Time', 'W+T', 'W+Time' for a win on time, 'B+F', 'B+Forfeit', 'W+F', or 'W+Forfeit' for a win by forfeit.
-* '''DT'''. Value: date. The date on which the game was played, in the format 'YYYY-MM-DD'. There is support for partial dates and date ranges, see the [http://www.red-bean.com/sgf/ official specifications site] for details.
+* '''DT'''. Value: date. The date on which the game was played, in the format 'YYYY-MM-DD'. There is support for partial dates and date ranges; see the [http://www.red-bean.com/sgf/ official specifications site] for details.
 * '''EV'''. Value: simpletext. The name of the event, e.g., tournament. Example: <code>EV[2022 Mind Sports Olympiad]</code>
 * '''GC'''. Value: text. Background information on the game, or a summary of the game itself. This free-form text not usually interpreted by software.

@@ Line 28: / Line 28: @@
 * colon ':'
 * a key, which is a sequence of one or more upper-case ASCII letters
-* literal string, which is any sequence of:
+* a literal string, which is any sequence of:
-** characters except ':', ']', and '\'
+** any characters except ':', ']', and '\'
 ** two-character escape sequences, which consist of '\' followed by any character
 A literal string starts immediately after a '[' or ':' token, and extends until the next unescaped ']' or ':'. No characters except ':', ']', and '\' have any special syntactic meaning in literal strings, and in particular, if '[', '(', ')', or ';' appear in a literal string, they are not interpreted as separate tokens. Literal strings may include whitespace, including newlines, and these are preserved. Whitespace is also preserved at the beginning or end of literal strings. If an unescaped '\' is immediately followed by a newline, both are removed. Semantic rules may place further limits on the string data, and may prohibit certain kinds of strings from including whitespace.
-All of the tokens are expressed in the ASCII character set, except for literal string data, which can use any character set. The interpretation of this data is further described by semantic rules. White space before or after tokens is ignored except when it is part of a literal string.
+All of the tokens are expressed in the ASCII character set, except for literal string data, which can use any character set. Newlines can be encoded as NL, CR, CRNL, or NLCR. The interpretation of literal string data is further described by semantic rules. White space before or after tokens is ignored except when it is part of a literal string.
 In current applications, keys consist of one or two upper-case ASCII letters, and some implementations may not recognize keys that are longer than 2 letters.
@@ Line 77: / Line 77: @@
 The semantic rules place further restrictions on how many tuples are allowed after certain keywords, and how many components are allowed in certain tuples. Current applications only permit 1 or 2 components per tuple.
-A ''dictionary'' consists of zero more more bindings. The keys in any one dictionary ''must'' be distinct. Example:
+A ''dictionary'' consists of zero more more bindings. The keys in any one dictionary ''must'' be distinct, and their ordering is not significant. Example:
   AP[HexGui:0.9]FF[4]GM[11]SZ[11]
@@ Line 138: / Line 138: @@
 === Semantic rules ===
-(to be written).
+Each key accepts specific types of values specified below. There are also rules about which node a given key may appear in, and which keys can or can't be combined with other keys within a node.
 == See Also ==
-[[Coordinates]]
+* [[Coordinates]]
 == External links ==

@@ Line 99: / Line 99: @@
   ( node₁ node₂ node₃ ... nodeₙ tree₁ ... treeₖ )
-has a single root <code>node₁</code> with a single child <code>node₂</code>, which has a single child <code>node₃</code> and so on until <code>nodeₙ</code>, which has ''k'' children <code>tree₁ ... treeₖ</code>. Note that it is possible that ''k'' = 0, in which case <code>nodeₙ</code> is a leaf; it is also possible that ''n'' = 1, in which case the entire tree is a leaf. Here are some examples:
+has a single root <code>node₁</code> with a single child <code>node₂</code>, which has a single child <code>node₃</code> and so on until <code>nodeₙ</code>, which has ''k'' children <code>tree₁ ... treeₖ</code>:
-(to be continued).
+[[Image: Tree1.png|x101px]]
 === Semantic rules ===

← Older revision		Revision as of 06:41, 6 December 2022
Line 6:		Line 6:

	SGF files are comprised of pairs of ''properties'' and ''property values'', each of which describes a feature of the game.		SGF files are comprised of pairs of ''properties'' and ''property values'', each of which describes a feature of the game.
		+
		+	== Description of the file format ==
		+
		+	The SGF file format is a text-based format (not a binary format). The description of the format can be separated into two parts:
		+
		+	1. Syntactic rules. This governs how SGF files are parsed. At this level, the format describes a very generic representation of abstract trees of key-value dictionaries. It can be used for all kinds of tree-like data and is not necessarily limited to game trees.
		+
		+	2. Semantic rules. This governs how specific keys and values should be interpreted in the context of game trees, and more specifically in the context of Hex. It also limits the set of possible keys and the types of values that may be associated with them.
		+
		+	The [http://www.red-bean.com/sgf/ official SGF specification] mixes syntactic and semantics concepts; for example, it distinguishes two different syntactic text types, Text and SimpleText, and it gives semantic rules for which of these types must be used in a given context and how they are to be parsed. By contrast, here we give an (equivalent) description that strictly separates syntax from semantics. This allows the file format to be parsed without any semantic knowledge, and it allows semantic properties to be checked without any knowledge of parsing. It also allows the same parser to be re-used for other, more general kinds of tree-like data.
		+
		+	=== Lexical structure ===
		+
		+	When reading SGF, the text is first converted to a sequence of lexical tokens. There are 8 different kinds of token:
		+
		+	* left parenthesis '('
		+	* right parenthesis ')'
		+	* semicolon ';'
		+	* left square bracket '['
		+	* right square bracket ']'
		+	* colon ':'
		+	* a key, which is a sequence of one or more upper-case ASCII letters
		+	* literal string, which is any sequence of:
		+	** characters except ':', ']', and '\'
		+	** two-character escape sequences, which consist of '\' followed by any character
		+
		+	A literal string starts immediately after a '[' or ':' token, and extends until the next unescaped ']' or ':'. No characters except ':', ']', and '\' have any special syntactic meaning in literal strings, and in particular, if '[', '(', ')', or ';' appear in a literal string, they are not interpreted as separate tokens. Literal strings may include whitespace, including newlines, and these are preserved. Whitespace is also preserved at the beginning or end of literal strings. If an unescaped '\' is immediately followed by a newline, both are removed. Semantic rules may place further limits on the string data, and may prohibit certain kinds of strings from including whitespace.
		+
		+	All of the tokens are expressed in the ASCII character set, except for literal string data, which can use any character set. The interpretation of this data is further described by semantic rules. White space before or after tokens is ignored except when it is part of a literal string.
		+
		+	In current applications, keys consist of one or two upper-case ASCII letters, and some implementations may not recognize keys that are longer than 2 letters.
		+
		+	=== Syntactic structure ===
		+
		+	An SGF file describes a finitely branching ordered tree, possibly with more than one root (technically a forest). Moreover, at each node of the tree, there is a dictionary, which is a mapping from keys to certain kinds of structured values. We begin by describing the encoding of dictionaries.
		+
		+	==== Dictionaries ====
		+
		+	A ''tuple'' consists of the token '[', zero or more literal strings that are separated by ':', and the token ']'. Examples of tuples are:
		+
		+	[]
		+	[value]
		+	[value1:value2]
		+	[value1:value2:value3]
		+	[Values may be arbitrary strings of characters,
		+	including newlines and other whitespace.
		+	Be aware\: the characters '\:', '\]', and '\\' must be escaped.
		+	Other characters \m\a\y be escaped but this is optional. Sequences
		+	such as \n have no special meaning; this is just another way to
		+	write the letter n.
		+	]
		+
		+	A ''binding'' consists of a key followed by one or more tuples. Examples are:
		+
		+	FF[4]
		+	AP[HexGui:0.9]
		+	AB[a1][a2][a3]
		+	C[This is a comment!]
		+
		+	Where a key is followed by more than one tuple, the data is intended to be unordered. In other words, the following are two ways of expressing exactly the same data:
		+
		+	AB[a1][a2]
		+	AB[a2][a1]
		+
		+	The data within each tuple is ordered. For example, the following are distinct:
		+
		+	AP[name:version]
		+	AP[version:name]
		+
		+	The semantic rules place further restrictions on how many tuples are allowed after certain keywords, and how many components are allowed in certain tuples. Current applications only permit 1 or 2 components per tuple.
		+
		+	A ''dictionary'' consists of zero more more bindings. The keys in any one dictionary ''must'' be distinct. Example:
		+
		+	AP[HexGui:0.9]FF[4]GM[11]SZ[11]
		+
		+	==== Tree structure ====
		+
		+	A ''node'' in the tree consists of the token ';' followed by a dictionary (remember that dictionaries can be empty).
		+	Here are some examples of nodes:
		+
		+	;AP[HexGui:0.9]FF[4]GM[11]SZ[11]
		+	;B[i3]
		+	;
		+	;AB[f4][g2]PL[B]
		+
		+	A ''tree'' is given by the following grammar:
		+
		+	tree ::= '(' node+ tree* ')'
		+
		+	Here, <code>node+</code> means a sequence of one or more nodes, and <code>tree*</code> means a sequence of zero or more trees. Trees are interpreted as follows: the tree
		+
		+	( node₁ node₂ node₃ ... nodeₙ tree₁ ... treeₖ )
		+
		+	has a single root <code>node₁</code> with a single child <code>node₂</code>, which has a single child <code>node₃</code> and so on until <code>nodeₙ</code>, which has ''k'' children <code>tree₁ ... treeₖ</code>. Note that it is possible that ''k'' = 0, in which case <code>nodeₙ</code> is a leaf; it is also possible that ''n'' = 1, in which case the entire tree is a leaf. Here are some examples:
		+
		+	(to be continued).
		+
		+	=== Semantic rules ===
		+
		+	(to be written).

	== See Also ==		== See Also ==

← Older revision		Revision as of 22:37, 3 December 2008
Line 6:		Line 6:

	SGF files are comprised of pairs of ''properties'' and ''property values'', each of which describes a feature of the game.		SGF files are comprised of pairs of ''properties'' and ''property values'', each of which describes a feature of the game.
		+
		+	== See Also ==
		+
		+	[[Coordinates]]
		+
		+	== External links ==

	You can find more info in the [http://www.red-bean.com/sgf/ Official Specifications Site].		You can find more info in the [http://www.red-bean.com/sgf/ Official Specifications Site].

← Older revision		Revision as of 01:52, 17 December 2007
Line 10:		Line 10:

	[[category:computer Hex]]		[[category:computer Hex]]
		+	[[category:game record]]

← Older revision		Revision as of 01:46, 17 December 2007
Line 8:		Line 8:

	You can find more info in the [http://www.red-bean.com/sgf/ Official Specifications Site].		You can find more info in the [http://www.red-bean.com/sgf/ Official Specifications Site].
		+
		+	[[category:computer Hex]]