Get this the source code (and executable) of this project from GitHub (https://github.com/twistedroomescapes/EscapeRoomController). Additional updates and documentation can be found on the GitHub page. Everyone is encouraged to contribute to this open source project.

We built our own controller software. We are using a Window Form application.

We have implemented a very simple interface where most of the configuration is driven off the file system (i.e. directories, sub-directories, and files).

The one assumption that we made while developing the controller was the fact they we knew we were going to run the software off of a computer and Duplicate the display onto a HDTV in the escape room. With this in mind, we tried to come up with a design that wouldn't distract game participants. Any character/word typing and movement of the mouse cursor is minimized.

The design has these basic elements

- A Count Down timer with start, stop, pause, adjust, end type of controls.
- A Message (notepad) Area where messages are displayed to the game participants.
- The ability to show predefined clues.
- The ability to show free form text clues.
- The ability to play user defined sounds and videos.
- The ability to systematically play user defined sounds at minute:second times

Some interesting features and setup

All of the games and files for a game are discovered based on directories, sub-directories, and file types. By default, the hierarchy of the games files are displayed in a tree structure, much like Window's Explorer or Window's File Manager. This allows a game Master to visually see some of the clues, sounds, and videos for a given game if needed. Experience game masters hide the tree view during game play.

Each game has set of "clue" files. The files are user defined (named), but we tend to name them with a numbering scheme or ordering. This allows the tree control (when visible) to display them in order. Our naming convention is usually room number (room within the escape game) "-" clue number. The clue files are HTML files, which allows HTML mark up (bold, underline, color schemes, images, videos, etc.). The clue is displayed in the message area of the controller when you navigate to the file in the tree control and right click and choose the menu item "Show". When the tree control is hidden, the command line interface can be used to display a clue using a "command augment" structure, i.e.

>show 01-01

We use clue files for a consistent game play. Instead of the game master free form texting messages to the participants, we have them display one of many variations of a clue or hint. Depending on the game participants, we may give them a nudge instead of a clue or answer. In any event, the presentation of the clue is predefined and consistent. We don't have issues with wrong verbiage or game master accents or bad articulation, etc. The clue can be digested by the game participants by reading it more than once. We also have clues that are riddles... the clue has to be solved to get the clue, so to speak.

The interface also allows the game master to construct and send a free form message as well.

When the message is sent, a user defined sound is played to get the attention of the game participants. Training for the listening and acknowledgement of the sound is done in the introductory spiel (background story) at the start of the game. The game host and participants typically start inside the initial room of the game. The game host goes over the rules and interacts with the game master. The host might say "game master please give us a sample clue" and the clue is displayed and the sound plays. This gives the participants the general idea on how things work.

The game master uses a laminated card or sheet of paper that tracks the progress of the game participants. A dry erase board marker is used to check off milestones of the game. A separate sheet of clue numbers is also used by the game master. Given a puzzle that game participants need help with, there are several clue "file names" that the game master can choose from to send to the game participants.

We have found that there is rarely a need to have bi-directional conversations with the game participants. Usually the participants ask for a hint or clue and the game master responds with a text message. When there is a need for the game master to say something, an amplifier with a press to talk microphone is used. See the Control Room to Escape Room Communications article for more information on this setup.

The controller uses a lot of hot keys (Control-x type of commands) and a tiny command line window at the bottom of the screen. When the game master wants to invoke some sort of command, they hit a Control-Q and this brings up a very tiny modal window at the bottom of the screen. The game master types in commands like

>show clue-01
>play sound-01
>video video-01

When the enter key is pressed, the action is taken and the modal window is dismissed. Game participants rarely notice these actions. (Remember, game participants see the same screen as the game master, including mouse movements).

The controller has the ability to play sounds and or video at a predefined time. Subdirectories under the root game can be made that represent minutes:seconds. When the controller counts down to the specific minute/second the sound file or video in that directory is played. Several of our escape room games have a suspense aspect. Playing a surprising sound like a dog bark or trumpet startles the participants and adds to the feeling that time is running out.

We use Dropbox to hold the configuration for all games. All of the computers are linked to the same Dropbox account. Any computer can be used for any game.

We don't rely on a server or a database or special license software or anything fancy. We keep things simple (KISS). There are enough technical challenges aside from the controller that need attention and babysitting. We didn't want to have to deal with any technical issues in regards to the controller.

We allow many of our game participants to continue playing after time runs out, if there isn't a booking back to back. We have a separate timer that increments, keeping track of the overage time. When the game master ends the game, all timers stop and a screen shot of the screen is taken and saved into a predefined directory inside the game directory structure. This allows us to post to Facebook or merge into group photos.