The Case of the Golden Idol sees players trying to solve twelve murder cases that span forty years in the 18^th century. You’re free to explore these scenes and examine clues at will, and you’ll need to use real deductive reasoning to figure out the names of the killers, how they did it, and why. The game won’t guide you to your answers, as you’ll need to piece every clue together yourself.

Game Developer spoke with Andrejs Klavins, game designer at Color Gray Games, to talk about the challenges that come from testing a detective game when you already know the answers, the thoughts that went into guiding the player without giving away too much or too little, and finding the joy in trusting the player to figure things out.

Game Developer: The Case of the Golden Idol involves a very open, free form of investigation to solve its mysteries. What interested you in doing a game with this style?

Klavins: Before we set out to make The Case of the Golden Idol, we started with a brainstorm of “unsolved” problems in the game-design domain that would be interesting to approach. One of these problems was the lack of deduction games that make the player feel like a detective through gameplay and not just through narrative flavor. There are some that do it very well like Return of the Obra Dinn or Her Story, but there are unfortunately very few games like that. So, we saw an opening to create our own.

What challenges come from designing a mystery game that is open to the player to explore? In creating a mystery game that largely trusts the player to figure things out?

Quite a lot of things had to come together for the experience to work out the way we wanted it to. Each scenario had to serve a macro story beat for the narrative, provide a compelling individual mystery, offer an exciting puzzle, and have to match real-life logic. We’d have back-and-forth discussions with each other in various stages of development of each scenario, discussing whether it moved the story forward in a compelling manner, whether the deduction logic was sound, and whether it was actually fun to play.

Secondly, a huge challenge was the fact that we cannot play the game ourselves. We could try out each other’s rudimentary puzzle prototypes, but in order to understand if a scenario delivers on all our criteria, we had to rely on lots of testing. This testing was great because that’s how you make a good game: showing it to others, seeing what’s clicking with them, and seeing what needs a bit more work.

An example of the game's fill-in-the-blanks deduction styling.

Did the mystery-solving mechanics stay largely the same throughout development? If not, how has it changed and been reshaped?

During early prototypes, we experimented with more idealistic ideas such as “construct full sentences from generic phrases”. However, after testing, we realized that the more arbitrary approach of “here is a bunch of phrases, where do you think they fit?” worked much better.

When building an early demo, players had to fill in the scroll puzzle for a scenario and it would tell them if it was correct or incorrect. This worked fine for a smaller, tutorial-like scenario, but with more complex scenarios, players would get very frustrated. This was because there were so many places they might be wrong and they had no idea which of their deductions were correct. Therefore, we introduced the extra puzzles, such as identifying people in the scene and solving an additional custom puzzle for each scenario, which greatly improved the satisfaction with the game. Now, they had a feeling that they are getting somewhere and were rewarded for figuring things out.

Adding the indicator “two or fewer slots are incorrect” served the same purpose of rewarding the player for being close to the solution. However, this reduced the difficulty and length of the game.

How did you decide on the limited tools you would offer the player to help them out (like informing them when they got some things right)? How did you design these tools while being careful not to give too much information away?

A huge problem in deduction and adventure games, in general, is how the players can communicate that they have figured things out. In the old text-based adventure games, they would offer this incredibly flexible tool—just write what you do. However, playing these games could be incredibly frustrating, because you might not know the right syntax or phrasing that the system would accept. On the other side of the spectrum are games that you could call “pretend detective games” where you are offered, for example, three solutions and you have to choose the right one. It’s very easy to input it, but you deny the player the actual act of deduction.

We decided to settle somewhere on that spectrum by still offering lots of information that players don’t need to deduce. For example, the scrolling text is not completely blank—it offers a lot of grammatical and semantic context. Or, there would be a limited amount of phrases in each scenario. The priority was to generate a good balance of steady progress and getting stuck until an insight strikes.

This opened a new can of worms—as the famous quote goes “Given the opportunity, players will optimize the fun out of a game”. With a limited input system, an option to brute force solutions appears. This meant we could not validate each phrase slot, but evaluating the whole puzzle as wrong or right frustrated the players. Thus, we settled on adding the indicator “two or fewer slots are incorrect”.

What thoughts went into the systems that capture information as the player explores and examines things? Into having players gather words, names, and terms to put together their ideas on what they think happened?

We started very idealistically that we would, like in Obra Dinn or Gone Home, craft these lived-in spaces with loads of tangential information for the players to filter through on their own. This quickly proved to create a bad player experience because, on their own, our more complex scenarios contained lots of information to recall. To amend this, we focused on a very minimalistic approach where we would only fill in the contents that were either necessary to the solution or create interesting misdirections.

One other thing that we tried to achieve was offering various paths to solve a scenario. Though not possible in all cases, often players can arrive at the same conclusion by observing different clues, which makes the game very enjoyable to watch.

What challenges came up in getting this system to work well and in giving players enough information that they could figure out the cases without making the answers obvious?

The fundamental challenge that we previously mentioned was that once you know the answer, you cannot “un-know” it, so you have a vague idea of what is too difficult or too easy. Sometimes we would build an early scenario that was very confusing and players were lost in it, so we had to add more and more clues until the playthrough flow was good. In other cases, we built a scenario where everything is clear from the very start and the player does not need the clues—they look at the scene and understand everything, therefore bypassing the deduction process. This meant we had to obfuscate things. For example, in the third scenario, you have to figure out who inherited what, but originally, we had the will written out as a clue, but this made the scenario trivial.

Overall, we used a sort of “thought path” scheme that would inform portions of a mystery that players needed to figure out to progress their understanding. For example, finding out which key opens which door could lead the player to the murderer's room, and then they’d have to find out who lives in that room to get the murderer's name. It helped, but we have to admit we failed to create a reliable framework for mystery building. Maybe that’s for the best.

How did this mystery-solving system affect how the story was written and conveyed? How did it affect what you showed the player during each case? How did you spread information and names across the game so that they didn't figure out information too quickly or all in one place?

Very early on we agreed on a high-level story archetype that we wanted to tell. We knew who would be the protagonist and antagonists, as well as how it should end. However, as discovery is super important in game design, we did not plan each scenario ahead. Instead, we just saw where it would take us as we worked on it—what felt sound and what felt interesting. The scenario still had to fulfill a concrete plot beat, but it might take us there in a different way than we had anticipated. For example, (SPOILER AHEAD) the character Walter Keene initially was planned to be a one-off murder victim, but we realized that we liked him and wanted to keep him around for more (END SPOILER).

Another approach that we did was allowing enough space between the events of each scenario. This meant that, from time to time, we could take a step back, evaluate the whole story so far, and decide if we should fill in some narrative gaps with an additional scenario. Not working in chronological order would sometimes result in us needing to update narrative elements in some of the earlier scenarios.

Murder most foul.

Can you walk us through the thought process of what you presented in one of the murder scenes? How did you decide what to put into a murder scene to get the player started on solving that particular mystery?

We had two types of scenarios—“whodunnit?” and “what the hell is happening here?”. Whodunnits were more classical—someone’s dead, there’s a bunch of suspects, and you need to find the guilty party. “Murder at the Little Mermaid” and “Intoxicating Dinner Party” are strong examples of that approach. “What the hell is happening here” scenarios would instead offer a confusing and mysterious situation where the joy is this transition from a feeling of “I have no idea what is going on here” to the state of “aha, and that’s how all of that happened”. Our game has more of the latter type because we are more effective at world-building and moving the story forward.

To walk through our process (SPOILERS AHEAD), let’s take the example of the “Murder at the Little Mermaid” scenario. Here, we focused on having a victim whose cause of death is quite obvious (stab wounds), but there are a number of very plausible suspects. The victim is on the first floor in their inn room all alone. Now we distribute the suspects in the scenario in a manner that there is no information that immediately eliminates most of them. For example, all of them have weapons on them. Most of them are shady in some manner and at least two or three of the characters have a concrete motive. We also added a strong red herring (the bloody writing on the wall).

Then, we focused on offering clues which gradually eliminated suspects by either not having access to the victim or being busy during the death of the victim. This does not work out so well when players play, because they may easily overlook certain things or invent and focus on things that are not there. This resulted in the actual deduction journey being very individual and bumpy. That’s part of the joy of the game—coming up with lots of hypotheses and gradually eliminating them.

What difficulties and benefits come of creating a mystery game like this as opposed to one that leads the player more? 

Apart from all the small details that have to work together, making such a game is a matter of trusting the players, which is not often easy. During the testing (which we do at least 5-7 times) we would just sit there with our mouths shut, watching them get stuck, confused, and frustrated, wondering to ourselves if we had created something completely illogical, which sometimes would be true! However, often it would take some time and players would suddenly get an insight with a loud “Aha!” and everything would become clear to them.

Those precious “Aha!” moments are something that we strived for. That is the benefit of creating such a game. We hope we make players feel like detectives not because their character is wearing a deerstalker hat, but because they are very smart and solved the mystery.