Using the API Functionality in your Project

Please Note: This section is under construction, and therefore subject to change. Please check back regularly!

Overview

Table Realms adds a wealth of functionality to your C3 project, as well as expanding on existing functionality within C3 and making it easier for developers to implement:

  • Touch Passthrough Functionality
  • Security
  • Multiplayer
    • P2P/P3P
    • Console

Table Realms Behaviours

The Table Realms Networked behaviour plugin is used as a “behaviour” attached to objects within the C3 layout, and they allow for the synchronisation of data between the peers and the host device. The different behaviours belonging to the plugin are:

  • Placed
  • Sync position
  • Sync Size
  • Sync Angle
  • Sync Opacity
  • Sync color (C3 Specific)
  • Sync layer (C3 Specific)
  • Sync Z elevation (C3 Specific)

In order to use these networked behaviours, a sprite object first needs to be added, much like the QR code.

Once the sprite objects have been added, the networked behaviour needs to be added to each object that it will affect. In some cases, there is data that will not need to be synced across the devices, but to be safe, ensure that the position, size, and angle for the objects are synced.

Placed

The default state of this behaviour is active - do not uncheck the box associated with this behaviour.

Sync (Property Name)

This behaviour ensures that the appropriate property/properties of an object are synchronised between the peer and the host. This ensures an accurate and seamless P2P experience.

Send Message

This action is used to send a message across the network. In the P2 model, messages can currently only be sent between client and host devices. To send messages between client and client devices, the P3 model is needed.

Sending and Receiving Commands

The core of the Table Realms interaction model relies on the sending and receiving of network messages containing commands. The way these commands are sent, as well as which devices are able to send and receive commands, varies between P2P and P3P models. These variances are outlined in more detail here.

Sending

The standard communication path is from host to clients, however, P3 allows for commands to be send with a string parameter to the host which the host can then send out. The client command path goes from client to host to clients.

Object for Event Condition Parameters Object for Action Action Parameters
Touch On Touch [Object for Touch] TableRealms Send Command “Command”=“Fired Command from ” & TableRealms.GetDeviceId

Receiving

To receive a specific command, a developer must set up a trigger with the corrosponding key. Alternately, the “Command Received Any” condition can be used.

Object for Event Condition Parameters Object for Action Action Parameters
TableRealms Command Received Named “Command” Browser Log in Console TableRealms.GetCommandReceivedValue

Assigning Avatar Images to Sprites

To assign avatar images to sprite placeholders by player ID, the following steps need to be taken:

  • Create a group for your avatar logic
  • Create a local variable in the avatar group, with the following attributes.
    • Name: AvatarImagePlayerNumber
    • Type: String
    • Initial Value: “”
    • Description:

Where AvatarImagePlayerNumber is AvatarImage, with the Player Number concatenated onto it.

Add the following event to your event sheet, under the avatar group:

Object for Event Condition Parameters Object for Action Action Parameters
System On Start of Layout System Set Value AvatarImagePlayerNumber to TableRealms.GetString(“player.” & TableRealms.GetDeviceId & “.lobby.avatar”)
AvatarImagePlayerNumber Load Image From URL “data:image/png;base64,” & AvatarImagePlayerNumber (Keep current size, cross-origin anonymous)

Alternately, the following event block could be used:

Object for Event Condition Parameters Object for Action Action Parameters
System On Start of Layout AvatarImageObject Load Image From URL “data:image/png;base64,” & TableRealms.GetString(“player.” & TableRealms.GetNthPlayerId(0) & “.lobby.avatar”) (Keep current size, cross-origin anonymous)

Where the Nth player ID follows the standard numbering system, and needs to be replicated per player.


NOTE: The above event block is generic, and will only form the base of your Avatar Image capture within construct. Depending on how you have set up the lobby (if at all) and the assigning of Player IDs, you may need to create additional sub-events to handle the logic.