This article by Julian Colbus originally appeared on DigiTales Interactive’s blog on November 7.

Game design is such a wide and varied discipline that job titles in the field have become increasingly granular over the years – and ever since we started working on our debut title Lacuna, I’ve become more and more convinced that “detective game designer” merits its own denomination as well. Detective gameplay (or “investigation gameplay”) poses a number of unique challenges centered around two main problems: the struggle between story and puzzles (or “cases”) as well as communication between the player and the game.

Julian Colbus, CEO of DigiTales Interactive

Since some of the explanations will be using our own game as an example, let me give you a quick rundown: Lacuna is a story-driven adventure with platformer controls and investigation elements. Its four fundamental gameplay types are dialogs (with choices), moving around, examining objects, and solving puzzles. All of them are staples of the point & click genre, but their execution is quite unique; I don’t want to go into more detail here because it’s not pertinent to the topic, but you can check out the game on Steam if you want to know more.

This is what the game looks like

Story vs. puzzles

A handful of abstract game design principles lie at Lacuna‘s core. For instance, “no takebacks” dictates that the player only get one shot at every decision, dialog, and puzzle. The game auto-saves and doesn’t allow you to go back if you performed poorly or regret an earlier decision. There’s also “limited feedback,” which means that the player often isn’t told immediately whether a solution was correct and what the consequences of their actions and decisions will be.

However, there’s one in particular I want to highlight here because it concerns the above mentioned divide between story and puzzles in detective games: No getting stuck.

The thought process behind it was simple: In games with both a story and puzzles (e.g. most P&C games), story progress is almost always tied directly to puzzle progress. Until you solve the puzzle at hand, you don’t get to see the next part of the story. For some players, especially those most interested in the story, this can become a problem. If they’re stuck for too long, there’s a chance they’ll just drop out and never pick the game up again. Even if that doesn’t happen, hard puzzles always run the risk of messing up the story’s pacing and interrupting your immersion in the game – because you’re becoming frustrated or, even worse, because you decide to tab out and Google the solution. To avoid people getting stuck, we considered a number of solutions:

Solution 1: Make the puzzles very easy?
This isn’t our favorite since it somewhat defeats the purpose of puzzles. They’d still play a role as a change of pace now and then, but if puzzles aren’t a little hard, nobody will feel like a detective solving them. Some early puzzles in Lacuna are easy, but most aren’t.

Solution 2: Provide hints?
Hint systems can be found in many adventures featuring puzzles. Unfortunately, they often take the player out of the experience in one of three ways: In some cases, the hint is provided by extradiegetic UI (e.g. in the pause menu) and therefore seems to come out of nowhere in the game world. In other cases, the player character is the one giving the hint, disconnecting the player from their avatar’s perspective. The third option of NPCs providing hints is a little better; however, it is often hard to justify why an NPC would be able to point the player in the right direction without possessing the rest of the solution to the ongoing puzzle (and why they didn’t volunteer it in the first place). The two types of (sort-of) hint systems we went with in Lacuna are Highlight Mode, which displays optional outlines around objects and NPCs that hold new information, and redundant information, meaning that sometimes the player is given two ways of obtaining an important clue.

“YOU ARE PLAYING A GAME RIGHT NOW”

Solution 3: Decouple story progress from puzzle progress?
Why not simply make a story-driven game throughout which the player can solve the occasional puzzle if they feel like it? Well, because it would require that puzzles be somewhat detached from the story. As a result, they run the risk of feeling meaningless since solving them is not rewarding and failing is not punishing. However, this can work quite well when combined with…

Solution 4: Make branching content for different solutions?
Instead of impeding the player’s progress, wrong or missing puzzle solutions could lead to a less desirable continuation and/or outcome of the story. Unfortunately, creating a new story branch for each and every wrong solution to a puzzle is hardly feasible. However, there are less extreme ways of realizing this. For instance, the game could account for the player’s overall puzzling performance at certain points in the game, e.g. trigger the “good” finale to an act if they got more than x% of the puzzles right, and the “bad” one if not. There could also be cascading consequences of sorts, e.g. solving one case correctly may give the player an edge in a later one. These approaches have similar downsides as optional puzzles do, but to a lesser degree; puzzle success no longer being required for progress makes them feel more detached from the story and removes immediate feedback. Regardless, we have found this to be the best solution, which is why we employ it quite a bit in Lacuna (while trying to avoid all the pitfalls). By the way, if all of this is becoming too abstract for you, bear with us! The second half of this post is all about a real example from the game.

Detroit: Become Human offers an astonishing number of different outcomes depending on player action, but not everybody has that kind of money to burn

Despite all of these measures being taken to make sure that the player won’t get stuck, Lacuna can still be called a hard game. While it’s not difficult to get to the end, it’s pretty difficult to get a good ending and not mess things up on your way there. In other words, rushing through the whole story is possible if you don’t mind bringing it to a terrible conclusion.

Communicating with the game

While the previous chapter only concerns detective games that also prominently feature a story, this next one is relevant to pretty much every detective game every made. It addresses the topic of communication between the player and the game, and especially how the player can express their thoughts to it. Several principles have proven to make for a good experience across countless approaches to this problem over the years:

Principle 1: Many channels out, few channels back in.
If the game conveys information to the player on many different channels and in many different ways, the process of piecing the solution together tends to feel more interesting and rewarding. In Lacuna, the player picks up clues from dialogs, objects, environments, the news, and e-mails (with all sorts of attachments). At the same time, the channels via which the player communicates that solution back to the game are kept to a minimum, namely cloze texts we like to call “Case Sheets” and (to a lesser degree) dialog choices. Having one or two central mechanics for player input makes the experience more coherent and transparent and facilitates designing the mysteries around it.

Return of the Obra Dinn by Lucas Pope provides a bunch of different sources of information, but just one central mechanic for the player to communicate back to the game

Principle 2: Have the player communicate only the solution.
It is near impossible to create a system through which the player communicates to the game how they arrived at a solution. Luckily, this is not necessary. A well-designed puzzle provides all the information, then moves the entire solution process solely into the player’s head, and finally prompts the player to input only their answer. The player’s objective should be stated clearly, but in a very general way at the start of a case (e.g. “find the culprit”).

Principle 3: Give the player maximum freedom in communicating the solution.
The way in which the player communicates the answer to the game is the most crucial part to get right. One aspect is to give the player many choices (or a large combination of choices) to pick from. Two things should be avoided: 1. Giving the player a high probability to succeed by picking a random answer. 2. Making it easy for the player to guess correctly because only one or a few of the available answers appear plausible. An example for a bad solution like this would be to give the player three dialog choices to solve the puzzle; even worse would be if one of them obviously made the most sense. A better approach would be to give the player a cloze text with a bunch of plausible options for each gap. Another possibility is to have the solution be an unguessable string of characters that the player needs to enter manually. Both ideas utilize combinatorial explosion to make guessing and brute-forcing nearly impossible.

Good luck brute-forcing your way through Detective Grimoire’s cloze texts

Puzzle example

Hopefullly all this will become crystal clear when put to concrete use! The following is an early level in Lacuna. It doesn’t contain some of the difficulties added later (like a large number of channels communicating potential evidence). In harder cases, the player will need to have paid attention to testimonies, news articles etc. from earlier levels to arrive at the correct conclusion, and some cases span multiple levels. Not this one, though; all the information required to solve it is directly contained in the clues and dialogs of the one level where it starts and ends.

This chapter won’t reveal much of importance about the story, but it will spoil the solution to this one puzzle, so consider yourself warned.

The puzzle

Here’s what happens: Our protagonist Neil is called to a crime scene to investigate a murder. His colleague Gary explains that a sniper must’ve taken the fatal shot from one of the opposite high-rises. He mentions that one of them, the casino, is holding a large event with lots of security, so it probably wouldn’t have been the sniper’s first choice. Neil is also told that the bullet hasn’t been found yet.

At this point, the player is given the Case Sheet, allowing them to submit their solution at any time from now on. This way, the player cannot know when exactly they possess enough information to solve it correctly. It also allows them to just submit any random solution if they completely get stuck and want to get on with the story. The Case Sheet simply reads “The shot was fired from ____”, which doesn’t spoil the solution while also formulating the question very clearly. There are only four options to pick from, which does make the answer more guessable, but we decided that was acceptable for the first puzzle, especially given that the player has only one shot.

The player can now walk around the building freely, investigate objects and talk to witnesses. Some of what they learn may be fluff, world-building, or even red herrings, but some is important evidence. The body lies out on the balcony, from where four buildings are visible: Gadle Hotel, Pixie Casino, Sakura Hotel, and Rocket Tower (from left to right). By investigating them, the player learns their approximate distance to the balcony. The position of the body, head to the left, already indicates that the shot probably came from somewhere on the right. A witness inside who saw the body hit the ground corroborates this.

The player may notice that they can also investigate a cupboard next to the balcony door. Its description states that the bullet disappeared into the wall on the other side and that it is locked. Investigating it unlocks a new dialog with a witness who gives the player the keys. They open up the cupboard and find the bullet. Neil’s colleague takes a look at it and surmises that it came from a rather small and quiet rifle that cannot shoot accurately over distances greater than 200 meters.

The player asks for the key in the newly available dialog

Gadle Hotel probably appears unlikely at this point because it’s too far on the left. The casino is also on the left and would additionally be a bad pick due to its increased security that night. This leaves Sakura Hotel and Rocket Tower, only the former of which is close enough to be plausible. (Remember that the player learned both the rifle’s effective range and each of the buildings’ distances to the balcony earlier.) At this point, the player may decide they’ve seen enough and submit the Case Sheet.

Processing the answer

Now the game evaluates if the player got the answer right. If so, that’s perfect: The player’s correct answer causes the story to continue, and they head off to Sakura Hotel to look for the sniper. But how do we handle it if they picked one of the other three buildings?

You might be thinking that we could prevent the Case Sheet from being accepted until it’s correct. Although not unheard of, that’s a bad idea because:

• It allows brute-forcing. And if it didn’t (by introducing combinatorial explosion), it would allow getting stuck.
• It doesn’t make sense that the Case Sheet or the person reviewing it knows the right answer and is withholding it.

Then how about we trigger a game over state if the submission was wrong? Having to replay the level would at least discourage brute-forcing. The thing is:

• We’re trying to avoid game over states since they break the immersion (in any game).
• It’s frustrating chicanery; remember that we want people to be able to get on with the story whenever they want.
• It contradicts another design principle of ours: no takebacks. You submitted the wrong answer, you should have to live with it.

Okay, next idea. We could make all the incorrect buildings levels of their own and have the player go there to eventually realize they’re in a dead end… But we shouldn’t, for a number of reasons:

• It destroys the story’s pacing.
• It’s a lot of extra work most players will never get to see.
• The player may take a long time to realize they’re in the wrong place and will then have to be steered in the right direction anyway.
• It can’t possibly be applied to later cases, where Case Sheets allow for 256 (4x4x4x4) or even more possible answers.

As is the nature of game design, what we did end up doing is the least bad solution with the most acceptable drawbacks. Here’s what happens: If the player picked the wrong building, everything seems fine until they get into a train to their destination. They then get a call about an anonymous tip made by someone at Sakura Hotel and are told to go there instead. This tip (and especially the reason for it being anonymous) is itself a piece of evidence for the puzzle at the hotel, already setting up the next mystery. This hopefully somewhat turns the attention away from the fact that the player just got railroaded back to the correct path. The player is also told that someone else from their squad will follow up on the building they (incorrectly) selected, and they will later learn that it turned out to be a dead end. Plus, Gary will make a snarky comment about the player’s misstep in the next level. These are some small ways to make the player feel like their decision wasn’t completely irrelevant.

And in fact, it wasn’t: Here’s where cascading consequences come in. Each and every correct puzzle solution throughout the first act may produce a piece of evidence relevant to the act’s overarching case. This means that every incorrectly solved case makes it more likely (or even inevitable) that the player will fail the bigger ongoing case. Failing the first act’s overarching case will in turn lead to information not being obtainable in the second act, which in turn prevents the player from getting one of the two “best” endings to the game. This cascading system makes sure that even small failures can have big consequences even though the player is immediately railroaded into the correct path at the time of their misstep.

Of course, this wouldn’t be game design we’re talking about if these cascading consequences didn’t come with their own set of problems. Most notably, the player may find it unfair or, even worse, not realize at all that they cannot know the solution to a later puzzle due to having failed an earlier one. But although we have come up with some solutions for this problem as well, let’s not go down that rabbit hole today.

Have a look at this censored overview of just the second act: bubbles are scenes, and the thinner lines between them represent only the most important (cascading) consequences

Did we stay true to our design?

Let’s quickly go over all the solutions and principles mentioned in the first half and see if we managed to apply them to our case.

Lacuna‘s design principles

No takebacks? Check. The player has one shot at submitting the Case Sheet and will have to live with the consequences.

Limited feedback? Check. The player isn’t told (right away) if their answer was right or wrong, even though they’re always sent to the right building.

What about no getting stuck, did we apply any of the provided solutions?

Did we make the puzzle easy? Yes, but only because it’s an early one.

Did we decouple story and puzzle progress? Yes, the player can always submit their Case Sheet, which ends the level and starts the next one.

Did we make branching content for different solutions? Yes, in two ways: small changes in dialogs and, more importantly, our system of cascasing consequences.

Did we provide hints? Sort of. We did use Highlight Mode (which highlights new information sources) and redundant clues (i.e. multiple ways to obtain the same information, e.g. the direction the victim fell when shot).

The player toggles highlights on and off; blue (objects) and orange (NPCs) indicate new information

Detective game problems

Now for the detective game problems and their solutions discussed above.

Did the game communicate on many channels? Not particularly since this is an early, easy case. The player only has investigatable clues and witness testimonies to work with.

Did the player communicate back on few channels? Yes, the solution to the case is submitted via one central mechanic, a Case Sheet.

Did the player communicate only the solution? Yes, the Case Sheet does not ask how they arrived at the conclusion.

Did the player have big freedom communicating the solution? Not really, but we found it acceptable here as there’s still only a 25% chance of guessing it. A high number of solutions is much more crucial for games that allow infinite retries and thus lend themselves to brute-forcing instead of giving the player just a single shot like Lacuna does.

Final thoughts

Detective gameplay is hard to get right. We’re lucky to be building upon so many experiments by countless other game developers teaching us what works (and what doesn’t), and it’s our hope that we’ve mixed an interesting and unique cocktail of ideas that will keep you engaged and entertained throughout our game. If you want to see for yourself, wishlist Lacuna now and give it a spin when it comes out.

If you have any thoughts on the topic or resources to share, let us know! We’re happy about any opportunity to nerd out about game design.