The Puzzle Schema outlines the sequence of events and puzzles in the escape room. The image below, a screenshot from the Designer, illustrates a basic escape room with only two puzzles. Understanding this example lays the foundation for expanding it into a complete escape room.
A short introduction to this escape room configuration as background:
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. Therefore, each task depends on the completion of its predecessor or predecessors when puzzles can be solved in parallel. 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.
Puzzle Task
Here on the left side is a schematic illustrating how the Puzzle task functions. The puzzle task becomes active when triggered by the completion of the previous task. It can also respond to a reset command, which deactivates the puzzle and returns it to its initial state. Once activated, the puzzle continuously checks if it has been solved.
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 Solved 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, which you can see to the right of the solved conditions. 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 script can be added if you want the puzzle to be interactive, it runs in the loop of check the solved condition. Scripts are necessary for scenarios where player actions require immediate feedback. For example, when a player presses a key on the Crazy Piano, they should hear a corresponding sound. For more details on scripting, refer to the section on Programming Puzzle Scripts.
Action Task
Here on the left is a schematic illustrating how the Action task functions. The Action task is quite similar to the Puzzle task, with the key differences being that it cannot handle a reset and does not support scripts. Other than these distinctions, the tasks are essentially the same.
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.
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.