Construct has a wonderful function that allows you to preview a build of your project. The quirk with that related to Table Realms is that the projects are usually previewed in HTTP, while Table Realms accessess HTTPS. In order to build and run your project, you will need to have installed the TR build/test tools.
From Construct, export your project to the TRBuildTool\game folder. Executing the run.bat file in the root folder will bring up the default layout of your project, with the QR code ready to scan!
Changing pages on an Aug file can be a bit tricky, when it comes to Construct. The default “page changing” behaviour would be to change the pages on each individual device, which can lead to the games not syncing up correctly. In order to change the pages globally, you would need to use the “Set String” action under the Table Realms.
Include Screencap for SetString
Once you have selected the “Set String” action, you would need to set the following parameters need to be included:
Now you’re all set - Once the trigger fires the event, the pages on the devices’ Augs will change globally.
Console logging is very handy, particularly if you’re trying to debug your game without having to resort to a rubber duck. To activate console logging in Construct, you need to add the “Browser” object to your project’s list of object types.
Once this has been done, you can assign console logging as an action to any trigger. An example of this would be creating a console message that displays when a specific named action has been performed.
The quirk that arises from console logging with Table Realms in Construct is that no model data can be logged on the “Player Joined” trigger.
A good practice is to wrap code that controls game flow around the isHost condition. This allows the host to manage the overall game flow. The way to do this is to create an isHost event block, and create sub-events within the “wrapper”.
isHost Event Block:
| Object for Event | Condition | Parameters | Object for Action | Action | Parameters |
|---|---|---|---|---|---|
| TableRealms | Is this instance the host | ||||
| -> [sub-events go here] |
It is rare but possible to run client-specific code. Usually the client is simply a viewer, only running logic that displays information. With the introduction of the P3 architecture model, we now have a chance for client to run special client only code. Generally code that runs on the client should run on the host too. Much like the isHost condition, client-specific code should be wrapped in an isClient condition.
isClient Event Block:
| Object for Event | Condition | Parameters | Object for Action | Action | Parameters |
|---|---|---|---|---|---|
| TableRealms | Is this instance a client | ||||
| -> [sub-events go here] |
===
When testing a game with the lobby component using the Table Realms test tool, there is the potential for multiple instances of the game to be created if the client devices scan the QR code present on the host device. To prevent this, have all the devices scan the QR code present on the browser page of the Table Realms test tool.
===
There are times when Table Realms will not initialise with an “On Start of Layout” parameter. If this is the case, in the event block, it will be prudent to include a “waiting period”, as follows:
| Object for Event | Condition | Parameters | Object for Action | Action | Parameters |
|---|---|---|---|---|---|
| System | On Start of Layout | System | Wait | X Seconds | |
| -> [sub-events go here] |