Author: David Spira

CaSE, iT MAttErs.

We live in a civilized society with rules. Respecting case is one of them. The utility of letter case is rarely discussed… and we’re not going to get into any of that today.

We are going to dig into how case regularly breaks puzzle inputs in stupid, avoidable ways.

What Escape Room Designers Must Know About Case

Everyone knows that there are 26 letters in the English alphabet, right?

Well to a computer, there are not 26 letters in the English alphabet, there are 52. Unless a computer is told otherwise, it will treat upper case letters and lower case letters as different entities.

When, as players, we find ourselves inputting a puzzle solution into a digital interface, case frequently presents a silly, easily avoidable, joy-killing barrier.

Solutions & Case Sensitivity

My team just solved a puzzle. The solution is “sherlock.” We are confident that we have to input this solution into a computer… so we type it in… and it’s rejected.

In most instances where a password is typed into a digital interface, there are 3 different options for case:

• sherlock
• Sherlock
• SHERLOCK

As a player I can confidently tell you that I don’t give a $#!% which one works. I do care, however, when my right answer fails because I used a lower case “s” when I needed an upper case “S” or vice versa.

This problem is magnified when a team doesn’t stop to think about the implications of case. They might just walk away from a correct answer and dive down some useless rabbit hole. It happens. I’ve seen it.

Keyboards, Shift, & Caps Lock

These problems are often exacerbated by the shift and caps lock keys on a keyboard. Often, when a password is inputted into a computer, the display looks like this:

******** or ●●●●●●●●

UNDER THESE CIRCUMSTANCES I MIGHT NOT NOTICE THAT MY TEAMMATE POKED AT THE CAPS LOCK BUTTON EARLIER… AND NOW I AM SHOUTING MY SOLUTION AT THE COMPUTER LIKE A CRAZY UNCLE FORWARDING A 10-YEAR-OLD POLITICAL CHAIN EMAIL!!!!!!!!

Solutions

There are a few easy solutions to these problems. The right combination of solutions will change based on the game’s individual circumstances.

Program Different Cases

If you’ve custom built the software that accepts your password, you can likely code it to accept multiple responses.

Allowing your software to accept “sherlock” OR “Sherlock” OR “SHERLOCK” nullifies the problem.

Normalize or Ignore Case

Again, if we’re talking custom software, you can usually drop a line of code into the program that either normalizes case or ignores it entirely.

Normalization is probably my favorite solution because when you start typing, it always types in the case that the system wants. I type in “Sherlock” but what displays is “SHERLOCK” and there is zero room for confusion on my part or the computer’s.

Ignoring case is useful as well because I can type “ShErLoCk” or any other permutation of case and the computer accepts it. It’s not limited to the pre-programmed solutions.

Programmatically Disable Shift & Caps Lock

Depending upon the computer you have and software you’re running, you may be able to programmatically disable the shift and caps lock keys so that they do not function.

This could be useful under circumstances where you have full control over the computer, but not the software that needs to accept the password.

Physically Disable Shift & Caps Lock

Finally, if all else fails, you can go nuclear and crack open the keyboard and break the shift and caps lock keys so that they cannot function on a mechanical level.

The Bottom Line

Whichever route you go, the net benefit is that you’ll eliminate a point of needless confusion and friction for your players.

This will also eliminate an entire category of hints and completely streamline a segment of your game that really isn’t supposed to be a challenge in the first place.

Everybody wins.

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.

More Technical Details

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.

[collapse]

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.