Game Sandbox III: How to Solve a Mystery

This entry was originally stored in my personal blog engine, but has been imported into WordPress.

There’s one last big feature I need to add to my adventure game framework. If I haven’t made it clear, the focus is figuring things out. That’s why, to date, I created a conversation engine but no combat mechanism, and players keep inventories of words instead of items.

This is an engine not only for adventure games, but for puzzles, and the goal of the player is to solve them. This, I’ve seen, in not an easy thing. I’m a great fan of mystery novels and treasure hunts, but recreating the essence of such a puzzle within a video game is very difficult.

One model that seems very common in commercial games, I can trace back to Sherlock Holmes: Consulting Detective and several other detective-like games which came out in the early-to-mid 1990s. This one in particular excelled at atmosphere and had the feel of a mystery (having copies of 1800s English newspapers and a London City Directory will do that), but the interactivity was terrible. Once you’d watched certain scenes of Holmes and Watson questioning suspects, the game assumed you knew enough to solve the case. Winning the game depended on answering a few multiple-choice questions from the local magistrate.

Patterns recur. If you’ve played through SquareEnix’s The World Ends with You, you’ve seen this model in the Week 2 campaign, as you scamper around Shibuya in search of a missing microphone.

There is my previously-mentioned favorite, the Professor Layton mysteries, but in those games, every single puzzle is practically its own mini-game. If I programmed games for a living, that might be an option. It isn’t. I need a re-usable engine.

I’ve seen some good indie games, though. At Newgrounds, two in particular stood out over the years.

Detective Grimoire. Here, you interview suspects and logically eliminate them one-by-one. It’s an excellent game, and I applaud the Flash Brothers for trying to develop the series further. However, it has its simplicities. When interviewing suspects, the goal is to “detect lies” during the conversation. But rather than thinking, you only react to in-game stimulus. Second, the “logical elimination” of suspects all takes place automatically, with automated checkboxes. No chance for the player to figure it out.

Why Am I Dead. This stands out not only as a good mystery, but has amazingly innovative gameplay. It takes place in a standard 2D RPG map, but as a ghost, the player can possess NPCs and talk to other NPCs, gaining different perspectives and answers depending on who’s talking. Once again, you’re eliminating suspects. The problem is that this goal isn’t explicit, and again, the game does all the logic for you – after you’ve triggered the correct conversations, it assumes you figured out the remaining suspect.

What all these games lack is the actual solving, and this cannot be emphasized enough. From Michael Moore’s Basics of Game Design:

The fun in playing a puzzle is the Eureka factor, the “Aha!” when the player comes up with the correct solution to solving the puzzle, where all the pieces fall into place. That sudden moment of realization can almost feel physical. In a way, detective novels are fictional puzzles where the reader tries to stay ahead of the sleuth who is gathering clues and come up with the name of the guilty party who committed the crime.

That’s what I believe these games are all missing, that moment when the player can, by their own effort and brainpower, solve the mystery. The problem: how do you turn, say, an Agatha Christie novel into something playable and programmable? Despite some snarky opinions to the contrary, it isn’t easy turning a mystery into something as straightforward as a crossword puzzle!

I’ve found a handful of games that, I believe, do capture the “Eureka factor,” and they all involve in-game puzzles. Specifically, they all involve players having to actually manipulate gathered clues together in order to arrive at a conclusion. The ones I’ve seen are:

Jack the Ripper. This one is pretty obscure, a DOS-based game from before my time. The main gameplay involves searching around 1888 London while looking for clues, interviewing people, etc. If you notice something interesting, it gets recorded in your virtual notebook as a clue. And here’s the kicker – once you get those clues, you can combine them to create more clues, until eventually you identify the Whitechapel killer.

– Several games by indie developer PastelGames, especially this one,, which is actually an advertisement-game for the TV series Body of Proof. You collect physical evidence, fingerprints, notes, and on the PD’s corkboard, you can combine them to generate more clues.

– I was informed that the Nintendo DS game Ace Attorney Investigations: Miles Edgeworth incorporates this feature in the “Logic” section of its gameplay.

In all these games, not only does the player collect clues, but they need to figure out on their own how to interpret them (albeit within some necessary limits).

All this leads to my approach. I first implemented it five years ago, while studying discrete mathematics. Part of the class was a review of logic. The textbook I was using, in the chapter-end exercises, included some puzzles where you converted mysteries into logical form to solve them. Having encountered the aforementioned Jack the Ripper game, I created, as my class project (logicproject), a game that simulated the solving of a mystery using such clues and logic. The result, in C++, was a text-only affair, but it worked. And after all these years, I used some of the original object design for my game engine.


In this screenshot, for instance, the player is reading (by clicking the clue-circles) two different clues. A simple reading shows that these two clues fit a logical form (“If A then B” and “A”). When the player clicks on the “Evaluate” button, a new clue-circle is going to appear on the screen, and the contents are going to be, in logical form, “B,” or in plain English, “The treasure is not in the kitchen.” And all this data is easily stored and manipulated in a JSON object:

  { 'id' : '0', 'available' : '1', 'partner': '2', 'revealed': '5', 'win': '0'
, 'text': 'If this house is next to a lake, then the treasure is not in the kitchen.'}
, { 'id' : '2', 'available' : '1', 'partner': '0', 'revealed': '5', 'win': '0'
, 'text': 'This house is next to a lake.'}
, { 'id' : '5', 'available' : '0', 'partner': '1', 'revealed': '6', 'win': '0'
, 'text': 'The treasure is not in the kitchen'}

This will be the center of my games. You collect clues – perhaps by poking around the map, perhaps during NPC conversations. At any time, you can open a menu like this, and evaluate your clues. Solving some clues will trigger events, perhaps even the end of the game. I’ll just add a mechanism to keep players from solving the game by randomly clicking all combinations.

Work on the game engine continues as fast as possible for someone who already codes as part of a full-time job.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s