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.
