Of necessity, game descriptions are logically incomplete in that
they don't uniquely specify the moves of all the players.
However, every game description does contain complete definitions
for initial state, legality, termination, goalhood,and so forth.
The upshot is that every state, in
every state, every player can determine those things.
Legality, termination, goalhood. And given a joint
move can update the state as well.
A game terminates if all infinite sequences of legal moves from the initial
state of the game reach a terminal state after a finite number of steps.
In general game playing we currently require
that all games terminate in exactly this way.
The game description in GDL is playable, game is playable if and only if every role
has at least one legal move in every
non-terminal state that's reachable from the initial state.
Note that in chess, a player cannot move, if a player cannot move, it's a stalemate.
Fortunately, this is a terminal state.
In GGP, we guarantee that, every game is playable.
A game is strongly winnable, if and only if, for
some player there is a sequence of individual moves that player.
That leads to a terminating goal state for
that player independently of whatever the other player's do.
A game is weakly winnable if and only if for every player there's a sequence
of joint moves of the players that leads
to a terminating goal state for that player.
In GGP, every game is at least weakly winnable and
all single player games are strongly winnable.
Okay, those are three properties we require of all games.
Now we talk a little bit about how games are played.
The first issue here is obfuscation.
In order to prevent programmers from building in specialized capabilities for
specific words in game descriptions, other then the game can independent vocabulary.
It's common for game managers to obfuscate their descriptions.
This means that all words are consistently replaced by nonsense words,
as in examples shown here.
The only exceptions are variables, and a selection of constants, common
to all games, such as next, does, true, and so forth.
And finally, there's the issue of syntax.
The version of GDL we've been looking at uses traditional in fix syntax.
Easy for humans to read.
However, it is not the only version of Linux.
There's also a version that uses prefix syntax.
Although, some general game playing environments support in fix GDL.
It's not universal.
On the other hand, all current systems support Prefix GDL.
The good news is that there is a direct relationship
between the two syntaxes, and it's easy to convert between them.
It's just a, well let's see, I'll summarize some of these things here.
So first of all.
variables are repla, re-prefixed with question
mark, since the language is case independent.
Operators are renamed. Colon minus is replaced by a left arrow.
Ampersand is replaced by and.
And the tilde symbol is replaced by not, not.
There's just one issue to worry about in
this transition between, translation between prefix and infix.
Issue is the spelling of constants and variables.
Prefix GDL is case independent, so it
cannot use capital letters to distinguish the two.
Constants that are spelled the same in both versions.
But in prefix GDL we distinguish variables
by beginning with a character, question mark.
Thus, the constant A is the same in both
languages, while the variable X in infix GDL is spelled?
X or question mark capital X in prefix GDL.
Unfortunately, mapping between the two can be tricky
since the case independent system might discourage case information.
Hence it's generally good practiced to use just one case
in naming constants and it's common practice to use lower case.
Finally, just to be clear on this, in prefix GDL,
white space, spaces, tabs, carriage returns, line feeds and so forth.
can appear anywhere other than the middle of
the constants, variables, and operator names, that is.
Thus, there can be multiple spaces between the components of an expression.
There can be spaces after the opening parenthesis of an
expression and before the operator or relation constant or function constant.
And there can be spaces after the last component of
an expression and before the closing parenthesis.
Just no spaces in the middle of words,
relation constants, function constants, object constants and variables.
[SOUND]