Universal Concepts in Table Realms

These concepts apply regardless of platform, engine, or IDE.

The Structure Behind a Console Game Session

A console game requires 2 or more devices, with one dedicated device (preferably a PC or laptop) acting as console and seen as the host device by all other connections.

The Structure Behind a P2P Game Session

Certain aspects of P2P sessions differ between engines. The core concept is that a P2P session is run using 2 or more mobile devices ONLY, one acting as a host and the remainder as peers. All instantiation needs to happen through the P2P API specific to your preferred engine/platform.

Hosts and Peers

  • The game session running on one device is seen as the “host”.
    • This is the first device that connects to the TR backend.
  • The game sessions running on all other devices are peers, because they connected to the TR backend after the “host”.
  • The game session runs on all devices in webviews, with the aug overlaid on webviews.
  • All game state is handled on the host, with peers being “viewers” which send network messages to the “host” device.

A Table Realms Game

This is a game that uses the Table Realms API or Plugin, and which has the following properties:

  • Name
  • Unique ID

Game Session

An instance players connect to, to interact with each other. Game sessions have certain constraints, including:

  • Users wanting to join the same session must scan the same QR code.
  • Users wanting to join the same session must be on the same network e.g. LAN
    • This is true for both console and P2P game modes.

Sessions have the following properties:

  • A Session ID that uniquely identifies the session

The Table Realms Model

The heart of the interaction system, which is explained in greater detail in the next chapter. Some things that are important to remember when using the model are:

  • The model stores data in key-value pairs. Examples of model data include:
    • Player ID
    • Game ID
    • Player Name
  • Different components are accessible through the model. An example of this would be <playerID>.Buttons.<buttonName>.Pressed.
    • By accessing this data through the model, you are also able to change values programatically according to specific triggers. This allows for a greater level of customisation within your game.
  • Both host and client devices have Lua and Game components.
  • In P2P mode, if a key is prefixed with a playerID, then data is synchronised to that particular player’s instance of the game.
  • The host device receives network messages, and updates the viewer/lua to all clients.
  • There are separate models for the Lua and the game itself. This means that if there are two devices, there will be four models. Everything is kept in sync by the host Lua.
  • To propogate actions, the host needs to send commands to itself and to clients.

Changing Data in the Model

  • Model changes always go to the host Lua first.
  • An example of changing data in the model would be as follows: When an action is sent by a button, use an if statement in your game to access and mutate the data within the model. This allows you to set the value for a specific key Can set things to true, false, or nil.
  • Setting a page for one person will not set it for everyone. To set it for everyone, a function needs to be called.

Design

A Table Realms game can render augmentations (or augs) to a device. These augs must be created using the TR IDE.

Within the IDE, an aug is structured as follows:

  • Pages
    • Components
      • Buttons
      • Layouts
      • Etc
  • Styles
  • Images
  • Fonts
  • Audio
  • Scripts
    • Generated
    • Base
    • Components
      • Basic
    • Players
    • MODEL
      • The model is not visibly present in the structure of the aug, but it is still accessible programatically.

A visual representation of the structure of an aug is laid out more clearly in chapter 2.2.