Un passo fondamentale per lo sviluppo di un qualsiasi software di gioco è la definizione di uno "standard" di rappresentazione testuale di una partita, ovvero definire una codifica completa, flessibile, semplice per poter descrivere attraverso un file di testo una partita di gioco vero e tutte le possibili informazioni pertinenti.
Si tratta di una scelta importante perchè su tale scelta verranno poi sviluppati i software per analizzare le partite, le interfacce informatiche per giocare, nonchè i software più specifici di analisi "scientifica", o meglio di Intelligenza Artifiicale (AI), delle partite.
Oggigiorno il formato di file utilizzato per registrare le partite di due giocatori di Go è lo "Smart Game Format", abbreviato SGF, (si tratta comunque di un formato che permette di registrare anche partite di altri giochi, quali Hex, Backgammon, ecc. ecc.)
Attualmente la specifica dello standard di questo tipo di file è la FF[4], in attesa della definizione della specifica FF[5].
In questo articolo cercheremo di dare una descrizione di questo formato di file fino ai suoi massimi dettagli in modo tale che ciò possa essere utile sia a capire meglio lo standard (ed eventualmente i punti aperti migliorabili nelle versioni future) che offrire le competenze per eventualmente sviluppare un software in grado di analizzare questo tipo di file.
L' SGF fu inventato da Anders Kierulf nel 1987 ed è diventato sempre più popolare; questa prima versione è identificata come FF[1].
Due importanti sviluppi sono stati la revisione FF[3] dovuta a Matin Müller nel 1993 e che è stato il primo passo vero verso una standardizzazione dell' SGF.
Nel 1997 Arno Halllosi ha dato vita alla revisione attualmente ufficiale, la FF[4].
La struttura base di un SGF è quella di un grafo a forma di albero, dove quindi ogni nodo ha esattamente un solo predecessore (il genitore) e uno o più successori (figli); in tal modo è possibile registrare una sequenza di mosse ed anche di varianti di gioco.
Ad ogni nodo sono associate delle proprietà che contengono una certa informazione, come il colore del giocatore che ha fatto la mossa, dei commenti e altro. Chiaramente un SGF può essere modificato o aggiungendo/eliminando i nodi o le proprietà associate ad essi. Bisogna ricordarsi sempre che l'unità base è il nodo, di cui la mossa è una proprietà!
L' SGF fornisce due modi per poter aggiungere le pietre sul Goban:
- fare una mossa;
- posizionare una pietra.
"Fare una mossa" coincide con l'eseguire una mossa così come accade in una partita reale; invece "posizionare una pietra" corrisponde all'atto di mettere sul Goban una o più pietre per poter analizzare una posizione, una variante di gioco, sistemare le pietre di handicap.
Data questa distinzione esistono di conseguenza anche proprietà che sono specifiche delle mosse e proprietà che si riferiscono invece solo al setup.
Lo standard FF[4] impone che in ogni nodo non si mescolino tali proprietà e che invece siano ben distinte le une dalle altre.
Nella figura seguente è possibile vedere come varianti e sottovarianti vengano rappresentate.
Definizioni di base
Convenzioni EBNF
[...] : opzione: si può presentare al più una volta
{...} : ripetizione: si può presentare un numero a piacere di volte
(...) : raggruppamento
| : OR esclusivo
italics: parametri spiegati in qualche altro posto
Definizioni EBNF
Collection = GameTree { GameTree }GameTree = "(" Sequence { GameTree } ")"
Sequence = Node { Node }
Node = ";" { Property }
Property = PropIdent PropValue { PropValue }
PropIdent = UcLetter { UcLetter }
PropValue = "[" CValueType "]"
CValueType = (ValueType | Compose)
ValueType = (None | Number | Real | Double | Color | SimpleText |
Text | Point | Move | Stone)
'elist of': ((PropValue { PropValue }) | None)
In other words elist is list or "[]".
Proprietà di un nodo
- move: le proprietà di questo tipo si focalizzano sulla mossa fatta e non sulla posizione raggiunta. In uno stesso nodo non è possibile mescolare proprietà di questo tipo con quelle di tipo setup (vedi dopo). Inoltre è sconsigliato assegnare una proprietà di tipo move ai nodi radice (root).
- setup: le proprietà di questo tipo si focalizzano sulla posizione corrente. Le proprietà di setup, come detto precedentemente, non devono essere mescolate con quelle di move per un dato nodo.
- root: queste proprietà sono assegnate solo ed esclusivamente ai nodi radice che sono i primi nodi di ogni gametree. Esse definiscono delle proprietà globali come: dimensione del goban, tipo di gioco, formato di file ...
- game-info: questa proprietà permette di dare informazioni relativamente alla partita (chi, dove, quando, cosa, risultato, regole ...) Queste proprietà di solito sono memorizzate nei nodi radice, e quando più partite vengono fuse a formare un singolo gametree, queste informazioni vengono memorizzate nei primi nodi per cui le diverse partite diventano distinguibili l'una dall'altra all'interno dell'albero. I nodi che contengono informazioni di gioco sono unici all'interno di un percorso dell'albero di gioco.
- - : si tratta di proprietà di nessun tipo specifico e possono apparire in ogni punto all'interno di una Collection
Esiste inoltre un attributo associato ad una proprietà:
- inherit: le proprietà che presentano questo attributo hanno rilevanza non solo per i nodi contenenti esplicitamente tale attributo, ma anche tutti i nodi figli a partire da esso. Questo vale finchè nei nodi figli non viene impostata una nuova proprietà o vengono cancellate le precedenti in modo esplicito.
