1 Introduction
General Game Playing (GGP) is a subfield of Artificial Intelligence (AI) research, in which the challenge is to develop agents that can successfully play arbitrary games without human intervention or prior knowledge of exactly which games are to be played
[Pitrat1968]. Implementing such an agent in practice typically requires the use of a Game Description Language (GDL); a standardised format such that the rules of any game can be provided to an agent without having to implement it directly in a generalpurpose programming language.The GDL that popularised GGP research [Genesereth et al.2005, Love et al.2008] originated primarily from Stanford; we refer to it as SGDL in this paper. Other systems with GDLs include Regular Boardgames (RBG) [Kowalski et al.2019] and Ludii [Browne et al.2020b, Piette et al.2020] for general games, as well as GVGAI [Schaul2014, PerezLiebana et al.2019] for video games. Aside from facilitating GGP research, the use of domainspecific languages has also been proposed for the ease with which they enable the implementation of custom, targeted testbeds [Samvelyan et al.2021].
SGDL is a relatively lowlevel logicbased GDL. After the introduction of an extension to support randomness and imperfect information [Thielscher2010], it was proven that SGDL is universal [Thielscher2011]; any arbitrary finite extensiveform [Rasmusen2007] game can be faithfully represented in a legal SGDL description. For the GDL of RBG, this was only proven for the subset of fullyobservable, deterministic games [Kowalski et al.2019]. Similarly, Ludii’s GDL (LGDL) was previously only proven to be capable of representing any finite, deterministic, perfectinformation, alternatingmove game, although it did already include basic support for stochasticity and hidden information (without a proof of universality) [Piette et al.2020].
For SGDL, the proof of its universality [Thielscher2011] essentially consists of encoding the entire game tree of any arbitrary finite extensiveform game in logic statements. LGDL is a comparatively higherlevel language that primarily consists of many keywords that game designers and players can readily understand as common game terms, such as board, piece, slide, hop, and so on. By design, it is intended to be easier to read, understand and use for game designers [Browne2016], with less of a focus on including the lowlevel language elements that would enable the exhaustive enumeration of all states of an extensiveform game tree. It has a relatively tightlyenforced structure, with many enforced restrictions due to strong typing. In comparison to the lowerlevel SGDL with a relatively flat structure that makes it straightforward to exhaustively enumerate a complete game tree, this makes it nontrivial to prove a similar level of generality for LGDL. Nevertheless, in this paper we are able to prove the universality of LGDL by demonstrating that it can represent the same class of games as proven by Thielscher Thielscher_2011_Universal for SGDL, including games with randomness and hidden information. This provides a theoretical argument that LGDL is a suitable, sufficiently general and powerful description language for problems for AI research.
2 Background
In this section, we provide background information on the standard, universal formalism of extensiveform games, as well as LGDL.
2.1 ExtensiveForm Games
Extensiveform games [Rasmusen2007] are a standard, general formalisation of games in the broad, mathematical sense of the word (i.e., including many decisionmaking problems that would not generally be viewed by most humans as “fun” games). The formal definition is as follows:
Definition 1.
An extensiveform game is specified by a tuple , where:

is a finite set of players, and a “nature” player to model stochastic events.

is a tree, where every node represents a single game state . The full set of states may be partitioned into a subset of nonterminal states (inner nodes) and a subset of terminal states (leaf nodes) , such that .

is a payoffs function, such that
denotes a vector of
realvalued payoffs (for the players) for any terminal game state . 
is a function such that, for any nonterminal game state , gives the player to play in that state.

gives, for any nonterminal state controlled by the nature player
, a probability
that the nature player “selects”as the successor. Note that this must yield proper probability distributions over successors, i.e.
. 
, where denotes the powerset of , gives the information set of player for state (i.e., the set of states that are indistinguishable from each other from the perspective of player when the true state is ).
In this paper, we focus on finite extensiveform games , where is of a finite size. Furthermore, we focus on alternatingmove games, since the function gives only a single player to move per game state . In theory, this is without loss of generality, since any simultaneousmove game can be equivalently modelled as an alternatingmove game in which the effects of moves are delayed until every active player in a turn has selected their move, and moves within the same turn are hidden information for all other players [Watson2013]. In practice, Ludii does contain additional support for modelling simultaneousmove games, but for our theoretical analysis we do not need this.
2.2 LGdl
The basic structure of an LGDL game description is depicted in Figure 1. It is defined by a grammar, automatically derived from Ludii’s source code [Browne2016], which specifies which keywords (also referred to as ludemes) and types of data (strings, integers, real numbers, and so on) can or cannot be used depending on the context. As shown by Figure 1, a game description file is expected to describe exactly one game, which has three toplevel entries:

players: describes basic data about the players (e.g., how many players the game is played by).

equipment: describes aspects such as any board(s) or graph(s) the game is played on, types of pieces or dice used in the game, and so on.

rules: describes rules used to (i) start the game (generate initial game state, e.g. by placing initial pieces on a board), (ii) play the game (generate lists of legal moves), and (iii) end the game (evaluate whether a state is terminal and determine the outcomes for the players).
Some of these aspects must be specified (such as the play rules), whereas others may be omitted if unnecessary (e.g., start rules are unnecessary in games that start with an empty board) or if they have a suitable default value (e.g., Ludii assumes a default number of players of if left unspecified). Piette et al. Piette_2020_Ludii provide more detailed information on the Ludii system, and Browne et al. Browne_2020_LLR provide a complete, detailed language reference for LGDL. A full example description for the game of TicTacToe is presented in Figure 2.
3 From ExtensiveForm Games to LGDL
Given any arbitrary finite, extensiveform game as defined in Definition 1, we describe how a corresponding Ludii game can be modelled in LGDL. In Section 4, we formally state and prove the theorem that and form equivalent game trees with onetoone correspondences between the set of all possible trajectories in and the set of all possible trajectories in . For simplicity, and without loss of generality, we make several assumptions about :
Assumption 1.
has a single, unique initial game state as root node of its game tree.
This assumption is without loss of generality because a game with multiple distinct possibilities for the initial game state can be equivalently modelled as a game with a single chance node as root, with appropriate probabilities assigned for all the intended “real” initial game states.
Assumption 2.
If the root node of is not a chance node, the player labelled as will be the first player to make a move.
This assumption is without loss of generality because there is otherwise no particular meaning to the labels that are assigned to players.
The following subsections describe how to fill in the basic template LGDL description from Figure 1 to construct such a Ludii game . The intuition behind our approach is similar to that of the proof by Piette et al. Piette_2020_Ludii (which was restricted to deterministic, perfectinformation settings) in the sense that we explicitly enumerate the entire game tree of as a graph that the players play on by moving stones along a path from the root to any leaf. The most significant change is that, to support imperfectinformation settings, we now use multiple “copies” of such a graph, with sets of possibly more than one stone per player moving down each player’s respective tree to track the information sets (rather than individual states) that players navigate between.
3.1 Defining the Players
For a player extensiveform game with players , the set of players in Ludii can simply be defined as (players k). It is not necessary to explicitly define the nature player in Ludii. The player labelled as player in Ludii will, by default, be the first player to make a move, matching Assumption 2.
3.2 Defining the Equipment
Firstly, we define a neutral Marker0 piece type—which we use to keep track of the true game state that we are in during any given trajectory of play—as well as one MarkerP piece type for every player —which are used to reveal the correct information set to each player. This equipment is defined in the equipment({}) section of the game description using (piece "Marker" Neutral) and (piece "Marker" Each).
Secondly, we construct the game board by defining a graph that contains disconnected subgraphs, each consisting of vertices that are connected to follow the same structure of the game tree in . Hence, the game board contains a separate graph representation of the full game tree for each player (including the neutral player). Such a graph can be constructed manually using (graph vertices:{} edges:{}). Let denote the unique index of a state . Then, in the graph for player (assume for the nature player), the index of the node that corresponds to is given by . Without loss of generality, we assume that the index of the initial game state is .
Thirdly, for every state and every player , we define a region in the equipment that contains all the indices of the vertices corresponding to states that are in the information set of when the true state is . More formally, for all and all , we define a region named "InformationSet_i_p" containing all the indices for all . Such a region can be defined in a game description using (regions "InformationSet_i_p" {}). Whenever we know that the true state is , this region allows us to easily access all the vertices corresponding to the complete information set for any given player .
Fourthly, for every player , we define a region in the equipment named "Subgraph_p" that contains all the indices of the vertices in that player’s respective subgraph, i.e. all indices in . Such a region can be defined in a game description using (regions "Subgraph_p" {}). We similarly define a region "Subgraph_0" for the first subgraph.
3.3 Defining the Start Rules
Due to Assumption 1, we know that every player’s information set for the initial game state contains only ; . Hence, we start the game by placing a marker for each player (including a neutral marker for the nature player) on the vertex that represents the initial game state in each player’s respective subgraph in the board. For any player , the index of this vertex is given by , assuming for the nature player. Presence or absence of markers on any site in a subgraph corresponding to a player must be hidden from all other players , to avoid leaking information that those other players should not have access to. Start rules that accomplish this setup for the initial game state are provided in Figure 3.
3.4 Defining the Play Rules
The play rules in Ludii define how to generate a list of legal moves for any given current game state . In our model, where we aim to replicate the structure of the game tree of the extensiveform game , we may distinguish two primary cases:

If is a chance node, i.e. , in Ludii a regular player will be in control because Ludii does not explicitly include a nature player. Hence, we should generate only a single legal move such that the player is forced to traverse the branch that the chance player would have picked in . This can be accomplished by using the (random {} {}) ludeme, where the first array contains a sequence of weights, and the second array contains a sequence of movegenerating ludemes, for a chance node with possible branches. For example, (random { , , } { A B C }) randomly selects one of the ludemes A, B, or C to generate the list of legal moves, with probabilities , , or , respectively. The appropriate weights to use can be derived from the nonzero probabilities as specified in .

If is not a chance node, i.e. , the mover should have one move corresponding to every branch from in the game tree of the extensiveform game . This can be implemented using an (or { }) ludeme that wraps around other ludemes, each of which generates one of the legal moves.
Without any knowledge of any general rules that may determine how legal moves are computed from a game state in the extensiveform game , it is necessary to explicitly enumerate all game states and define the play rules separately per state. One way to accomplish this is by using a chain of (if C A B) ludemes, where:

C is a condition of the form (= (where "Marker" Neutral) i): this checks whether the Marker0 piece is located on vertex , and can hence be used to determine whether or not the current game state is .

A is a ludeme that generates the moves in the case that the condition of C is satisfied by the current game state (i.e., if the current game state is ).

B is a ludeme that generates the moves if the current game state does not satisfy the condition of C; this can again be a ludeme of the same (if C A B) form.
Suppose that there is some branch in the extensiveform game tree of that leads from a state to a state . In the corresponding Ludii game , we require a corresponding move that has the following effects on the game state:

It should move the Marker0 piece, which should currently be located on the vertex with index , to the vertex with index . This enables us to continue tracking the true game state.

For every player , any Marker pieces currently on the board should be removed, and new Marker pieces should be placed on all vertices in the InformationSet__ region. This enables us to let every player know which information set it transitioned into.

By default, Ludii reveals information about positions that become empty. Because the above effects remove some pieces from positions that should still remain hidden from many players, vertices should be appropriately set to hidden again as they were originally set in the start rules.

By default, Ludii updates the index of which player is designated the mover after every move, by incrementing it or resetting it to after player made a move. If this results in a different player to move than the player that should become the mover in , we need to include an extra effect in the move that correctly sets the player to move. Note that, if in , it does not matter which player is set to be the mover in Ludii, since we only generate one legal move anyway that whichever player is the mover will be forced to pick.
Suppose that such a state has legal moves. A straightforward way to present different options to the player is to allow them to select one out of any of vertex , and for each of those “select” moves specify appropriate consequences. These consequences should correspond to the branch from in the game tree of , but otherwise do not necessarily have any particular relationship with the specific vertex ; selecting vertices is simply a mechanism through which the player can distinguish between different moves. Figure 4 depicts the specification of a move rule for a single transition from to .
3.5 Defining the End Rules
For each of the terminal game states in , we can define a separate end rule in that checks whether that specific state has been reached by tracking the position of the Marker0 piece, and assigns a vector of payoffs to the players as given by using the payoffs ludeme. Figure 5 provides an example of such end rules for an example game for players with two terminal game states.
4 Proof of Equivalence
Based on the strategy for constructing a Ludii game for any extensiveform game as described above, we present Theorem 1, which may intuitively be understood as stating that it is possible to model any arbitrary finite extensiveform game in LGDL.
Theorem 1.
Under Assumptions 1 and 2, for any arbitrary extensiveform game , a corresponding Ludii game constructed as described in Subsections 3.1–3.5, is equivalent to in the sense that the following criteria are satisfied:

The game description of is a valid game description according to the specification of LGDL.

There exists a onetoone correspondence between trajectories from the root node to any possible leaf node in the game tree of , and trajectories of play that are possible from the initial game state in . More concretely, this means that:

For every node that is reachable from the root node , including itself, there exists an equivalent game state in that is also reachable in the same number of transitions from the initial game state of .

For every node in the game tree of where (i.e., any node that is not a chance node), the equivalent state in also has as the player to move.

For every node in the game tree of where , if there are branches to successors, there are also legal moves in the equivalent state in .

For any chance node that is reachable from the root node of the game tree of , for every possible that has a probability of being the successor of , there is also a probability that a transition to the equivalent state of in is the only legal transition in any arbitrary trajectory that reaches the equivalent of in .

For any terminal node in the game tree of , the equivalent state in is also terminal, and assigns the same vector of payoffs .


Any player playing the Ludii game cannot distinguish between any pair of states that are the equivalents of two distinct nodes , if and only if they share the same information set .
These criteria are similar to those used for the proof of universality for SGDL [Thielscher2011].
Proof.
By construction, the game description as detailed in subsections 3.1 to 3.5 is a valid LGDL description. As of the public v1.1.17 release of Ludii—which first introduced the (random ) and (payoffs ) ludemes—all of the ludemes used are supported. This satisfies criterion 1.
The start rules of (see Figure 3) ensure that, in the initial game state, a piece of type Marker0 is placed on vertex , and not on any other position. All moves that can possibly be generated are of the form depicted in Figure 4, which can only affect the positions of Marker0 pieces through its (fromTo (from ) (to )) rule, which moves whichever piece is at vertex to vertex . This means that the number of Marker0 pieces cannot change; there must always be one, and only its position can change due to (fromTo (from ) (to )) rules. For any particular value of , such a rule is only used in situations that satisfy the (= (where "Marker" Neutral) i) condition, i.e. only if vertex currently contains the sole Marker0 piece. For any pair of values and , if there is a branch from to in the game tree of , it is also possible for there to be a legal move that moves the Marker0 piece from vertex to vertex in ; such a move is either legal for sure if is not a chance node, or legal with probability if is a chance node. This satisfies criterion 2a; the equivalent state of a node can always be identified as the one that has the Marker0 piece on vertex .
The move rules as described in Figure 4 have, by construction, been set up to ensure that the next player to move is set to —or any arbitrary integer in if —whenever a move is made that moves the Marker0 piece to vertex —which means that the equivalent state of a node is reached. This ensures that criterion 2b is satisfied for every node except for the root node . Assumption 2 ensures that the criterion is also satisfied for .
By construction, as described in Subsection 3.4, for every node that is not a chance node, the equivalent state in has its move rules defined by an (or { }) rule that wraps around different rules, each of which generates exactly legal move, such that is the number of successors of in the game tree of . This satisfies criterion 2c. Similarly, the correct number of moves with correct probabilities as required by 2d are explicitly defined as described in Subsection 3.4.
The end rules as described in Subsection 3.5 explicitly detect any game state in the Ludii game that is the equivalent of a terminal node of the extensiveform game , and explicitly assign the corresponding payoffs vector . This satisfies criterion 2e.
By Assumption 1, there is only a single initial game state, and every player is aware of that. Therefore, every player’s information set for the root node contains only the root node; . This is reflected by the start rules described in Subsection 3.3 which, for every player , place a marker for that player—and only visible to that player—in the subgraph used to represent the state space of for that player. Every move that can be applied in any trajectory is of the form illustrated by Figure 4, which ensures that:

Every player can only ever observe markers on vertices of “its own” subgraph.

Let denote the vertex that contains the neutral marker – hidden from all players – in the first subgraph. For every player , within that player’s “own” subgraph, there is always a marker on every vertex that represents any of the nodes in the information set for that player in that state.
This means that, for any pair of nodes that is in the same information set for a player in the game tree of , the pair of equivalent game states in are also indistinguishable from each other from that player’s perspective (due to the arrangement of markers on vertices visible to that player being identical). Note that the move rules as described in Figure 4 were deliberately set up such that players always select vertex to pick the move in a list of legal moves, irrespective of which vertices are subsequently affected by that move. It might have been more intuitive to directly select the vertex corresponding to the node in the extensiveform game tree to transition into, but this could reveal additional information that the player should not have access to. With this, criterion 3 is also satisfied and the proof is complete. ∎
5 Conclusion
Ludii’s game description language (LGDL) has primarily been designed to be easy to use for game designers, with a focus on facilitating the design of board games and similar abstract games. In practice, its count of over 1,000 distinct game descriptions (which far exceeds the game counts in official repositories of many other systems with GDLs, such as SGDL [Genesereth et al.2005, Love et al.2008], RBG [Kowalski et al.2019], and GVGAI [PerezLiebana et al.2019]) has already demonstrated its flexibility and generality. In this paper, we have also proven its generality from a theoretical angle, demonstrating that it is possible to write an equivalent game in LGDL for any arbitrary finite extensiveform game [Rasmusen2007]. This provides a significant extension of an earlier proof [Piette et al.2020] by including stochastic and imperfectinformation games, and means that the expressiveness of LGDL matches that of SGDL [Thielscher2011].
This result suggests that we can opt to use Ludii over SGDL in GGP research for some of its other advantages, such as computational efficiency [Piette et al.2020] and ease of use, without a loss in expressiveness. While the somewhat convoluted way of defining games used for the theoretical proof is unlikely to be an efficient way of implementing many “real” games in practice, it may be a fruitful starting point for designing synthetic game trees for targeted research into the relations between certain game tree characteristics and the effectiveness of different algorithms [Ramanujan et al.2010, Ramanujan et al.2011] within the same framework and API (Ludii) that also supports many real games.
Acknowledgments
This research is funded by the European Research Council as part of the Digital Ludeme Project (ERC Consolidator Grant #771292) led by Cameron Browne at Maastricht University’s Department of Data Science and Knowledge Engineering.
References
 [Browne et al.2020a] C. Browne, D. J. N. J. Soemers, É. Piette, M. Stephenson, and W. Crist. Ludii language reference. https://ludii.games/downloads/LudiiLanguageReference.pdf, 2020.
 [Browne et al.2020b] C. Browne, M. Stephenson, É. Piette, and D. J. N. J. Soemers. A practical introduction to the Ludii general game system. In T. Cazenave, J. van den Herik, A. Saffidine, and I.C. Wu, editors, Advances in Computer Games. ACG 2019, volume 12516 of Lecture Notes in Computer Science (LNCS). Springer, Cham, 2020.
 [Browne2016] Cameron Browne. A class grammar for general games. In A. Plaat, W. Kosters, and J. van den Herik, editors, Advances in Computer Games, volume 10068 of Lecture Notes in Computer Science, pages 167–182, Leiden, 2016.
 [Genesereth et al.2005] Michael R. Genesereth, Nathaniel Love, and Barney Pell. General game playing: Overview of the AAAI competition. AI Magazine, 26(2):62–72, 2005.
 [Kowalski et al.2019] Jakub Kowalski, Mika Maksymilian, Jakub Sutowicz, and Marek Szykuła. Regular boardgames. In Proceedings of the 33rd AAAI Conference on Artificial Intelligence, pages 1699–1706. AAAI Press, 2019.
 [Love et al.2008] N. Love, T. Hinrichs, D. Haley, E. Schkufza, and M. Genesereth. General game playing: Game description language specification. Technical Report LG200601, Stanford Logic Group, 2008.
 [PerezLiebana et al.2019] Diego PerezLiebana, Jialin Liu, Ahmed Khalifa, Raluca D. Gaina, Julian Togelius, and Simon M. Lucas. General video game AI: A multitrack framework for evaluating agents, games, and content generation algorithms. IEEE Transactions on Games, 11(3):195–214, 2019.
 [Piette et al.2020] É. Piette, D. J. N. J. Soemers, M. Stephenson, C. F. Sironi, M. H. M. Winands, and C. Browne. Ludii – the ludemic general game system. In G. De Giacomo, A. Catala, B. Dilkina, M. Milano, S. Barro, A. Bugarín, and J. Lang, editors, Proceedings of the 24th European Conference on Artificial Intelligence (ECAI 2020), volume 325 of Frontiers in Artificial Intelligence and Applications, pages 411–418. IOS Press, 2020.
 [Pitrat1968] Jacques Pitrat. Realization of a general gameplaying program. In IFIP Congress (2), pages 1570–1574, 1968.
 [Ramanujan et al.2010] R. Ramanujan, A. Sabharwal, and B. Selman. Understanding sampling style adversarial search methods. In Proceedings of the TwentySixth Conference on Uncertainty in Artificial Intelligence, pages 474–483, 2010.
 [Ramanujan et al.2011] R. Ramanujan, A. Sabharwal, and B. Selman. On the behaviour of uct in synthetic search spaces. In ICAPS 2011 Workshop on MonteCarlo Tree Search: Theory and Applications, 2011.

[Rasmusen2007]
Eric Rasmusen.
Games and Information: An Introduction to Game Theory, 4th ed.
Blackwell Publishing, Oxford, England, 2007. 
[Samvelyan et al.2021]
M. Samvelyan, R. Kirk, V. Kurin, J. ParkerHolder, M. Jiang, E. Hambro,
F. Petroni, H. Küttler, E. Grefenstette, and T. Rocktäschel.
Minihack the planet: A sandbox for openended reinforcement learning research.
In Advances in Neural Information Processing Systems, 2021.  [Schaul2014] Tom Schaul. An extensible description language for video games. IEEE Transactions on Computational Intelligence and AI in Games, 6(4):325–331, December 2014.
 [Thielscher2010] M. Thielscher. A general game description language for incomplete information games. In Proceedings of the TwentyFourth AAAI Conference on Artificial Intelligence, pages 994–999. AAAI, 2010.
 [Thielscher2011] M. Thielscher. The general game playing description language is universal. In Proceedings of the Twentysecond International Joint Conference on Artificial Intelligence, IJCAI11, pages 1107–1112, 2011.
 [Watson2013] J. Watson. Strategy: An Introduction to Game Theory. W. W. Norton & Company, New York, third edition, 2013.