Double inputting is a silly source of player confusion in escape room tech, but it’s easy to eliminate.
Double inputting is a silly source of player confusion in escape room tech, but it’s easy to eliminate.
What is Double Inputting?
I’ll set a scene:
I’m at an altar with my team. It’s the end of the game. We have collected a series of magical items and we must place them on the altar, then remove them in a particular order. If we do it correctly we will summon the all-powerful God of Interface Design and win the game.
We place our objects one by one in the correct order… and nothing happens. We were right, but it didn’t work.
It turned out that when placing one item my hand shook just a little.
What happened? The RFID chip in the object moved in and out and then back in range of the reader. The result is that it read as the same object twice. Thus the entire sequence was considered incorrect.
There are a lot of circumstances where signals or inputs can be duplicated quickly and without the player realizing that it has happened.
When this happens, the result is always the same: the solution is incorrect and it’s frustrating.
In some instances this happens so frequently on a particular puzzle that the gamemaster pops onto the hint system to say, “It’s ok guys. You have the right answer. It happens to everyone. Just be really quick and deliberate… and it will work. If you can’t get it, I’ll come in and do it for you.”
Solution: Read Delay
There’s a pretty easy software fix for this problem:
Add a “read delay.” After an input is accepted, put a few second delay on reading another signal. That way if someone’s a bit shaky or fumbles the pieces, the computer won’t get confused by the action.
Exactly how long that delay ought to be is going to vary based on the individual interaction. Take your best guess. Then test it with real players and adapt accordingly. The goal of the timing should be that it doesn’t slow down their pace, but it should prevent double inputs.
Pushbuttons and switches have a similar problem, called “bounce.”
When a read delay is used for buttons, it is called “debouncing.”
Solution: State Machine
Another fix is a “state machine.” A state machine is a list of states and a list of transitions that take you from one state to another. This allows you to control exactly what is/ isn’t considered an input in the sequence.
The following explanation is thanks to Brett Kuehner:
For example, let’s say you have 5 props: A, B, C, D, and E. You want them placed on a single pedestal, one at a time, in that sequence. If the players make a mistake (i.e. A, B, D) you want them to have to start over from the beginning. The diagram below shows a state machine with 6 states (circles), and transitions (lines) between them:
Where there is a line between states, it indicates that the program should move between states if that condition is true.
This gives you complete control over what happens for each input. Each correct input moves the players from Start towards Finish. Each incorrect input sends them back to Start. A duplicate input does nothing because there is no transition. In the example, there is no transition from state 2 when the players place B on the pedestal. They can place B on and off as many times as they want, and the puzzle stays in state 2. When the players get to Finish, the system can unlock the lock, play the fanfare, and flash the lights. You know the only way it can get to Finish is if the exact sequence was followed.
State machines are a robust way to describe puzzle behavior because you can draw a diagram of exactly what you want and to turn it into rules for your control system to follow. Once you have a generic state machine routine, you can easily describe complex puzzles with minimal code or without any code at all. It is just data describing the states and transitions.
Here’s what the code might look like:
AddState(“start”, { DoStuffToResetThePuzzle(); });
AddState(“solved”, { UnlockTheDoorAndSoundTheTrumpets(); });
AddTransition(“start”, { return CheckTheSwitches(); }, “solved”);
SetState(“start”);
There are just 2 states: start and solved. The system continuously checks the current state of every puzzle, and sees if any of the transition conditions are true, which makes that puzzle move to another state. When the system goes to start, it resets the puzzle. (Doing this in start guarantees that every way you reset the puzzle will do exactly the same thing.) If “CheckTheSwitches” becomes true, the state machine goes to solved, which triggers the door to unlock to the trumpets to sound.
The Bottom Line
These kinds of details matter a lot. They are the difference between the technology being invisible and the moment triumphant… and the tech being obvious, broken, and the moment frustrating.
