This page briefly explains the main concepts of TAG.

Board games

  • Action: Independent unit of game logic that modifies slightly a given game state towards a specific effect. Actions are performed by players and can be used by the game engine as well if appropriate to simplify code. Examples: player draws a card; player moves their pawn.
  • Rule: Unit of game logic part of a game flow graph. It modifies slightly a given game state towards a specific effect and informs of the success of the execution, which affects the flow through the game graph. Rules are executed by the game engine after player actions. Examples: trigger a specific game event; decide which player plays next; check end of game conditions; shuffle a deck of cards, reveal the top card and apply its effect to a random player.
  • Turn order: Defines which player is due to play next. In the simplest form it iterates through the players in order, repeating for every round. In more complex forms, it handles necessary reactions from other players triggered by actions or rules.
  • Game phase: Splits up the game into several phases, with different rules applying and/or different actions available for the players depending on the current phase.
  • Component: Umbrella term for all game objects (as follows), with certain properties. Actions and rules modify the state of these components. An Area is a collection of components mapping from an ID to the component object. A Deck is a collection of components keeping track of an ordered list of components, with specific interactions available (e.g. shuffle, pick first, discard a component etc.). Both Area and Deck are considered components themselves. Other components:
    • Token: A game piece of a particular type, with a physical position associated with it (usually).
    • Dice: A die has a number of sides N associated with it and can be rolled to obtain a value between 1 and N (inclusive).
    • Card: A card usually has text, images or numbers associated with it and is the most common type of component used in decks.
    • Counter: An abstract concept used to keep track of a particular variable numerical value; usually represented on a board with tokens used to mark the current value, but recognized as a separate object in this framework. It has a minimum, maximum and current value associated with it, where the current value can vary between the minimum (inclusive) and maximum (inclusive).
    • GraphBoard: A graph representation for a board, as a collection of several board nodes connected between each other.
    • BoardNode: A node in a graph board which keeps track of its neighbours (or connections) in the board.
    • GridBoard: A 2D grid representation of a board, with a width and height associated with it. It can hold elements of any type.


  • Player: Human, random or an Artificial Intelligence agent interacting with the game and performing actions.
  • Game loop: Found in the class, controls execution of a game and links all objects by repeatedly computing observations from the game state, asking players for actions and sending the actions to the forward model; the loop is broken when it is informed the game is over and the result of game (and winners/losers) are reported.
  • Game state: Player independent. A container of all components in the game and any other variables describing a moment in time.
  • Observation: Player specific. A reduced game state which includes only those components (or parts of the components) which are visible (or observable) to the player receiving the observation.
  • Forward model: Performs actions requested by the players and executes any other game rules to modify a given game state, encompassing all logic of the game.
  • GUI: Graphical user interface, displays game states and allows human interaction.
  • Game parameters: Numbers that are specific to a game and control various functionality (e.g. number of cards a player has to draw in their turn; number of bad things that happen to the player).
  • Game data: Information at the basis of the game that allows the creation of components, stored in Json files and read automatically by the component classes (e.g. card definitions - names, effects, counts; tile patterns; board nodes connections).
  • Constants: Contains caches of hashes of string keys for the game, categorical variable definitions or any other constant definitions.