SGF ovvero Smart Game Format

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.

Concludiamo ora questa parte di descrizione generale mostrando come vengono gestite le varianti di un gioco.

 Nella figura seguente è possibile vedere come varianti e sottovarianti vengano rappresentate.

varianti

Definizioni di base

Come abbiamo già detto l'SGF è un formato di testo, che per poter descrivere correttamente una partita di gioco reale deve possedere un proprio linguaggio, con una propria grammatica e sintassi. Nello specifico l'SGF utilizza un importante metalinguaggio, ovvero l' EBNF (Extended Backus-Naur Form). Per i più curiosi ecco il link alla pagina di Wikipedia su EBNF, invece di seguito riassumiamo solo le caratteristiche fondamentali che ci servono per trattare l'SGF.

Convenzioni EBNF

"..." : simboli di inizio/fine
[...] : 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)
Gli spazi biachi (tipo \n, \t, \r, tab orizzontali, tab verticali, spazi e via dicendo)possono apparire ovunque tra PropValues, Properties, Nodes, Sequences e GameTrees.
Esistono inoltre due tipi di liste di proprietà:
'list of': PropValue { PropValue }
'elist of': ((PropValue { PropValue }) | None)
In other words elist is list or "[]".

Proprietà di un nodo

Gli identificatori di proprietà di un nodo sono costituiti, a tutt'oggi, da due lettere maiuscole e il loro  ordine non è importante. Inoltre in un file SGF è possibile anche definire dei propri identificatori di proprietà a patto che non interferiscano con quelli standard. Ogni nodo deve avere un solo identificatore per ogni proprietà. Infine ad ogni proprietà è associato un tipo che pone delle restrizioni sui nodi a cui si possono applicare, o alle altre proprietà con cui si possono combinare.I tipi associati ad ogni proprietà sono i seguenti:

  • 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.

Cerca

Autenticazione