Walking Through the Evolution of the Walkthrough

November 3, 2023

One of the features of the Sleuthhounds games, right from the very start with Sleuthhounds: The Unlocked Room, has been the inclusion of an in-game walkthrough. It’s no fun playing a game and getting stuck because you simply have no idea what to do. I’d like to think my games provide enough subtle clues within the environments and the comments the characters make to spark puzzle solutions without needing a walkthrough. However, (a) I’m the developer of the games, which makes me the worst person to judge how solvable they are, and (b) different people find different puzzles easy or difficult. This past month I’ve been working on the in-game walkthrough for Sleuthhounds: Cruise and thought I’d throw the spotlight on its development.

When I created the first Sleuthhounds game, The Unlocked Room, the walkthrough system was a little different from what it became in all subsequent games. In that first outing, when players start a new game they first must choose the difficulty level from one of Gumshoe (easy), Detective (medium), or Super Sleuth (hard). With each of these, there were additional options for including or excluding access to the walkthrough and for enabling or disabling the hot spot highlighter. On Easy both of these are on by default but can be turned off. On Medium only the hints are on by default but both can still be turned on or off. On Hard both of these are turned off and the options are disabled so they can’t be turned on.

By the time I came to the second game in the series, The Cursed Cannon, I’d had a chance to think about these options more. I decided it would be better to always have the walkthrough available. After all, if a player was going to get stuck, wouldn’t it be more likely on Hard than Easy? Removing the choice for that from the initial options left the hot spot highlighter option by its lonesome, so I moved that into the game options proper for anyone who really wanted to get rid of it.

So why incldue a walkthrough anyway? They do take a fair amount of work to put together. The reason is simple, every time a player stops playing a game there’s a chance they won’t start again. And if they’re stopping because they’ve become stuck and frustrated trying to solve a given puzzle, well, I figured that didn’t improve the chances of a player coming back. To be sure, a player could just pop out to a browser and look up a walkthrough online, but why put them through that effort and additional level of frustration?

When creating the walkthrough system for the Sleuthhounds games, I cosidered the types of walkthroughs I’d seen over the years in terms of their usefulness. The least usable type of walkthrough is the video walkthrough (otherwise known as “let’s play” videos). These walkthroughs are hard to use because they’re not searchable. You can’t go right to the part of the walkthrough you want to see. You either have to watch the video in its entirety or else skip around trying to find the solution you need while hoping not to spoil anything else by going too far.

More usable than that is the text/narrative/guide walkthrough. These are written ones that are a click-by-click description of how to get through the game. These are better than video walkthroughs in that you can search the text for key terms to try to find the part that applies to the situation you’re stuck in. This greatly reduces the chances of seeing a spoiler for some part of the game you haven’t reached yet. However, the search through these documents can still take a bit of a time to do.

The third type of walkthrough is reminiscent of the old hint books for adventure games and is one that was popularized, for a time, by the Universal Hint System website. With this type of walkthrough, a series of questions are provided like, “How do I unlock the red door?”. Within each question are a number of answers that are initially hidden. As you click through the answers they become visible and also more specific. This allows the hints to start by giving players a gentle nudge in the right direction, which often times is all a player needs rather than the fully spelled out solution the other walkthrough types offer. (For those who’ve never seen an old pritned hint book, the effect of moving from general to more specific hints was usually achieved by writing the hints in blue text with an obscuring red pattern on top. You then had to place a band of red cellophane over top to filter out the red on the page and allow you to read the blue text beneath.)

Even with UHS style hints there’s still a change, though significantly less likely, to encounter spoilers simply through the hint questions that are available. However, it’s possible to take that style of hints a step farther by incorporating them right into the game itself, as I’ve done with the Sleuthhounds series. I first encountered this with the wonderful Tex Murphy: Under a Killing Moon. Having the hints right in the game means that the game itself is aware of the state of things. With proper design, the game knows where a player is at, what they’ve done, what pieces of information they have available, what characters they’ve talked to, and so on. This means that when the game provides the list of questions from which to read hints, only those questions that contextually make sense for where the player is at, need be shown. This has the double benefit of providing hints that the player doesn’t have to search through and removing virtually any chance of reading a spoiler.

Writing hints in this question and answer format can be tricky and it’s definitely more time consuming than writing a straightforward click-by-click guide. Over the course of the Sleuthhounds series I’ve evolved how the hints are generated to make them less time consuming to do.

From The Unlocked Room through the second holiday game, The Hallowen Deception, I wrote the hints right in the game code itself. This meant that I had to deal with writing the hint text at the same time as writing the logic to control which hints appear when. It was a tedious process and one that kept my attention divided between those two aspects.

With the third holiday game, The Yuletide Tail, I improved the process by taking advantage of the repetitive nature of the coding side. Hints are pretty standard in their format. Each hint consists of a question and a series of increasingly specific answers. I already had in place a system for generating code templates for things like looking and interacting with hotspots in the game proper. I was able to use that same system to create a starting point for all the hints in code. To make that even easier, with the Yuletide Tail I added the ability to fill in the templates with data from comma separated files. This allowed me to write the hints in Excel without having to worry about the display logic at the same time. I wrote the hints in Excel, saved them to a comma separated CSV file, and then imported them into the templates. All that was needed after that was to add the logic controlling when each hint needed to display in game.

For Sleuthhounds: Cruise I’ve added another refinement to the process. Using an Excel spreadsheet to write all the hints is definitely a step up from doing them directly in the code. However, Excel’s not so great at freely editing text. You have to move through cells or double-click into them to make any corrections and if you want to see the entire context of a question and its answers then screen real eastate becomes an issue. How wide do you make columns? How wide can you make columns before too much information starts going off screen?

The snazzy walkthrough editor. Um, just ignore the non-Hints tabs.

To deal with the walkthrough creation limitations of Excel, for Cruise I have developed a dedicated walkthrough editor. This editor arranges hints in a tree like structure. Each hint starts with a question, which is a parent node in the tree. Below those hints, I can add child nodes for each of the answers at the click of a button. This takes the question and answers that have to be placed horizontally in Excel and rearranges them to be placed vertically, which allows a lot more horizontal space for the text itself. The tree view also allows me to expand or collapse questions, so I can hide the ones I’m not currently working on. Since this editor is my own tool, I was able to write it such that it natively saves out to a CSV file that is immediately suitable for importing into the game code. So this tool has wins for me all around.

Even with improved code support and a dedicated tool, the walkthrough still takes time to get through. I have to play the game to figure out what steps need to be done to complete it. I then have to translate those into suitable written questions and answers. Finally, I need to integrate all of that into the game itself along with the logic for controlling when the questions appear and disappear. For example, if there’s a locked door, the walkthrough shouldn’t show a question about that door until the player runs into it. And once the door has been unlocked, then the question should be removed from the list. All of this is why it’s taken me over a month – with a fair bit left to go – to incorporate the hints into the game. That’s all right. My players are worth it!

Previous:   |   Next: