The Puzzle Schema defines the sequence of puzzles, actions, and experiences that make up your escape room’s logic. In this guide, you’ll learn how the escape room puzzle schema works inside Realix ERC and how to use it to design your own fully automated game flow.
Open Logic and Effects to work with the diagram, then use the shared Properties panel for the selected component or arrow. The workspace has dockable panels.
For example, consider the following escape room flow:
The players enter the room, and the door locks behind them. An intro sequence begins, and once it concludes, the game timer starts, and the first puzzle, the cans puzzle, is activated. The players gather clues to solve this puzzle, which opens a cabinet revealing a cable. They connect the cable to the “Crazy Piano” puzzle and wait for a short musical intro first. Once the keys are active, they must play “Do-Re-Mi” while the keys are shuffled. Successfully completing this unlocks the final door, allowing them to escape and finish the game.
The puzzle schema consists of various tasks, including Puzzle, Action, Experience, and System tasks. When the room is in a reset state, all tasks are inactive. Once the game host starts the room, the first task to be activated is the system task “room start.” This task triggers the next task, which upon completion, activates the subsequent task. Each task depends on the completion of its applicable predecessor or predecessors, including when puzzles can be solved in parallel. An arrow can also be limited to the selected skill levels, as described below. Each type of task serves a different purpose. In the following sections, we will discuss each task type, its behavior, and the associated settings. A complete description about game states, room reset, ready check, game finish and game fail can be found in the article Game States and Flow.
Note: It’s important to understand that “Resetting the room” is often associated with getting the room ready for the next players. However, in the ERC, we use the term “preparing” to describe the process where the game host ensures that everything is properly locked again and the room is clean. In the ERC, resetting refers to actions such as releasing all locks and providing sufficient light, allowing the game host to enter the room and prepare it for the next group of players.
Paths for different skill levels
- In Main → Game Settings, enter skill levels such as
Beginner, Expertand save. - Select a connection arrow in the diagram. Choose Unconditional path to use it at every skill level, or Limit to selected skill levels and select the permitted levels.
- For example, give Beginner players a route through an extra instruction task and let Expert players follow a different route. Select the player group’s level in Game Settings before starting, then test each route.
If a level is renamed or removed, the old selection stays visible as no longer defined. Select a replacement or clear the obsolete choice. A limited path with no currently defined level selected is disabled; it does not silently become unconditional.
Puzzle Task
A Puzzle task becomes active when its applicable predecessors complete. A reset command deactivates the puzzle and returns it to its initial state. While active, the puzzle checks whether it has been solved, unless manual completion is selected.
In the Designer, you can assign an Effect Sequence to the On Activate event. For example, you could start playing music and direct a light towards the puzzle. For the On Completed event, you can define effects such as playing a “solved” sound and unlocking a mechanism. For the On Reset event, you might want to turn off some lights on the puzzle or perform other actions to return it to an inactive state.
Internally, the puzzle task continuously monitors whether the puzzle is solved by checking the status of specific objects. When the puzzle meets the defined conditions, these conditions can be easily configured in the Designer. For example, in the “Can Puzzle,” the RFID codes of the cans are verified to ensure they are placed on the correct reader. Note that “Can Blue,” “Can Red,” and similar items are defined in the RFID library, as described in the article about Objects (RFID Readers).
Pay special attention to the Solved delay in the component’s Properties. This feature is useful in cases where players might accidentally meet the conditions. For example, if a clock needs to be set to 8:00, and someone briefly passes through 8:00 while adjusting the hands, you wouldn’t want the puzzle to be marked as solved. By setting a Solved delay—such as 2 seconds—the condition must be met for the specified duration before the puzzle is considered solved.
Ready conditions are criteria that need to be defined to assist the game host in determining whether a puzzle is in its reset state. Before the game host can start the room, these Ready conditions are checked. Typically, a puzzle is considered Ready when it is in the Unsolved state.
Adding information to the puzzle task can be highly beneficial for the game host during gameplay. You can include text (such as a lock code), images, and dynamic information. Dynamic information provides real-time feedback on the status of objects. For example, in the Can Puzzle, the game host can see which cans are on which readers, making it much easier to assist players.
Optionally, a custom script can be added when a puzzle needs to maintain state. This allows the puzzle to remember previous player actions and implement more advanced logic. The script is executed each time the puzzle evaluates its solved condition. Scripts are useful for scenarios where players must complete a sequence of steps or where earlier actions influence later ones. For example, when a player presses a key on the Crazy Piano, the script can remember which key was pressed most recently and determine which key should be pressed next.
For more information about writing puzzle scripts, see Programming Puzzle Scripts.
Manual completion
For a Puzzle or Action that the operator must finish, select Game Host must manually complete. The component keeps its Events and Gamehost information, but its Solved conditions and Ready conditions tabs are hidden. The operator completes the active task; an automatic solved condition is not the completion rule for this variant.
Designer provides Single Test, Run from Here, Activate, Complete and Reset according to game and component status. Single Test tests one component; Run from Here starts its game route. See Choosing the right test for the prerequisites and saved game settings.
Action Task
An Action task becomes active when its applicable predecessors complete. Like a Puzzle, it finishes when its solved conditions are met or the operator completes it manually. It provides On Activate and On Completed events, but has no custom script or On Reset event.
Why is there an Action task next to a Puzzle task, even though a Puzzle task can do more? The reason is to make your puzzle schema more intuitive. Action tasks are designed for simple actions executed by players, but they aren’t really puzzles. Examples include opening an already unlocked room or cabinet door, pressing a light switch, or pushing an elevator button. By distinguishing between these simple actions and actual puzzles, you can more effectively organize your schema into real puzzles and actions.
Specifying Solved conditions, Ready conditions, and Gamehost information is the same as for the Puzzle task. The manual-completion option described above is available here too; when enabled, the automatic Solved/Ready tabs are hidden.
Experience Task
The Experience task, shown on the left, differs from the Puzzle and Action tasks. The Experience task becomes active when triggered by the completion of the previous task, similar to the Puzzle task. However, instead of checking for a solved condition, it monitors whether the specified duration for the experience task has elapsed.
The Experience task features only the On Activate event, which initiates an Effect Sequence. This sequence includes all the effects that players will encounter during the task. The next task will only be activated once the specified duration has passed. Therefore, the Experience task is intended for situations where no puzzles should be active, and players are expected to wait and experience the effects until the sequence is finished.
System task
When designing a new puzzle schema, the process begins with three predefined system tasks: Room Start, Game Start, and Game Finish. These tasks play specific roles. The Room Start task is the starting point for designing the schema and is the only one that can handle a reset command. The Game Start task triggers the game timer, while the Game Finish task stops the timer.
Why is the reset option only available in the Room Start task? The Room Start task serves as the central point for resetting elements that aren’t reset elsewhere. Light objects, for example, can have a reset condition defined within their own settings. Most outputs and controls are typically reset through the Puzzle task they are associated with. However, if anything remains unreset, it can be done here.
To clarify the Game Finish task, it still includes an “Activate next task” option. This is because, even after the game is finished, players may need to perform a final action or experience certain effects. These can be set up to occur at this stage.