Dear reader,

This was originally written as a development log, but if you're looking for general advice on detective game design, you're in the right place! Feel free to treat the passages on our game as detailed practical examples; there's plenty of theoretical reflection and general advice to be found in this article.

Enjoy!

Welcome to Lacuna's very first devlog! Let's catch you up on the past five years of its development.

Just kidding; Lacuna's first prototype did exist back in 2015, but we'll spare you most of the details of its long journey. The first few devlogs will each give you an overview on a certain aspect of development, and we thought that game design might be a good way to kick off the series.

Gameplay

Since the game isn't out yet, we want to start by telling you what it will generally be like. Let's attempt a description without marketing lingo: Lacuna is a story-driven adventure game 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 adventure genre, especially point & click games, but each one is a little different than you might expect:

Dialogs in adventures often loop back to one central node where the player can select all the options they didn't previously select. In Lacuna, each dialog can only be played a single time. Dialogs branch based on player decisions, which oftentimes lead to consequences later in the game – some big, some small.

Movement in Lacuna can be described as "platformer controls without jumping". Pointing and clicking tends to feel too strategic, somewhat removing the player from the action. We found a direct control scheme (using WASD or a controller) more modern and immersive. However, since the game is primarily aimed at people interested in experiencing the story and solving puzzles, Lacuna never demands quick reactions or precise hand-eye coordination.

Examining is one of the basic actions of any P&C adventure. In Lacuna, the player uses Investigation Mode to investigate nearby objects that might be of interest. They are recognized and highlighted automatically because we don't consider searching things a particularly interesting type of challenge. Having a defined array of available objects to toggle through also lends itself to controller-based input (more than being able to select any pixel on the screen hoping it will react in some way).

Puzzles in adventures are often self-contained mini games testing the player's dexterity or logical thinking. Alternatively, especially in P&C games, they involve handling and combining items. Both types have a tendency to not make sense in the game world and/or not tie into the story in a meaningful way. By contrast, all puzzles in Lacuna are mysteries directly arising from the story and dialogs. The player solves them via dialog choices, investigating evidence, and ultimately via a central mechanic dubbed Case Sheets (more on all those mechanics in our example down below).

This is the game's first Case Sheet, very short and to the point

Game Design principles

From the very start, we laid out some design principles we've been trying our best to follow ever since. Some of them have become somewhat apparent in the previous paragraphs (e.g. unique dialogs, story-focused puzzles), but there's a few underlying, abstract ones worth highlighting.

The first one is no takebacks: We wanted to make choices and their consequences front and center in the game's design and story. We felt like manual saving and loading would take away from that, and we opted for an automatic save system instead that always overrides your previous save file (in that slot). Non-replayable dialogs as described above were another consequence of this design principle. Not being able to go back might be frustrating at times, so to somewhat make up for it, we created three save slots allowing for multiple concurrent playthroughs. Plus, the game only saves after each level (i.e. every few minutes), so if you immediately regret something or made a choice by accident, you can undo it by reloading the level right away.

We also decided to give the player very limited feedback. As much as we like some of Telltale's titles, we were never fans of "x will remember this". It yanks you right out of the action by giving you explicit information that your avatar doesn't have (and that seemed to mostly be a smokescreen anyway). Lacuna gives no hints of this sort and doesn't disclose which decisions matter more than others, quietly adapting to the player’s behavior. That being said, the reasons for certain consequences need to be made clear later to mitigate frustration.

There are some more principles related to writing, but they're a topic for another day. Let's skip ahead and get to the big one. It's so big, in fact, we need to give it its own headline:

No getting stuck

This design principle has been making our lives so much harder (but our game better) ever since we came up with it.

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.

Detective game problems

Many of the problems we encountered when designing Lacuna are as old as detective games themselves. Most of them are centered around how the player and the game communicate with one another, and especially how the player conveys their thoughts to the game. Several principles have proven to make for a good experience (across countless approaches to this problem over the years), some of which have made their way into Lacuna:

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 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 (which is what Case Sheets boil down to) 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, and both of them can be found in Lacuna.

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

Puzzle example

This has been a lot to take in, but hopefullly it'll all become crystal clear when put to concrete use! The following is a level the player encounters early on in Lacuna. It won't reveal much of importance about the story, but it will spoil the solution to this one puzzle, so consider yourself warned.

Since this is essentially the game's first puzzle, it won'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.

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 highrisers. 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:

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:

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:

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 the two things described above: use Highlight Mode and redundant information. Let's briefly talk about how exactly:

Highlight Mode, which enables colored outlines on evidence and people holding new information, is explicitly introduced at the start of this level. It helps the player notice a number of important things: that they can investigate the cupboard; that a new dialog becomes available once they start looking for the key; and after that dialog (in which the player obtains the key), that the cupboard holds new information because it can now be opened. Highlight Mode also acts as an indirect way of telling the player that they can solve the puzzle and stop looking for clues at a certain point, as there are no colored highlights left on any of the people or objects. Of course, Highlight Mode is optional, so players who like a challenge can just leave it off.

There are also some redundant pieces of information. For instance, the player might already have the idea that the sniper was somewhere on the right based on just looking at Banny's body. However, the dialog with the secretary confirms this again. Similarly, the player might think that Pixie Casino is far enough on the right to still be a possibility, but Gary telling them about the increased security there should make it clear that it's not the right answer.

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 and it's naturally at odds with a game's story in a number of ways. 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.

Julian