Hint System 2.0
April 5, 2024
I’ve been promising it for the past couple of months and now, finally, here it is. A post on the changes to the in-game hint system for Sleuthhounds: Cruise. Yay, hurray!
All of the Sleuthhounds games have incorporated a hint system since the very beginning with The Unlocked Room. I patterned this off of the Universal Hint System, which presents hints in the form of questions that can then provide multiple answers with increasing levels of detail. Sometimes, if you’re stuck in a game, all you need is a nudge in the right direction. Sometimes, you’re just not getting it and need the full solution presented. The Universal Hint System provides for this, making it superior to traditional written walkthroughs where, even using a search tool, it can be hard to find the exact hint you need, especially without spoiling something else. And video walkthroughs/Let’s Plays are even more difficult to use, as they lack an effective way of searching.
The benefit of creating a UHS style system right in the game itself though, is that all of the game’s “state” is available to check. Has the player encountered that locked door yet? Do they have a bad paint job to clean up but don’t know where to find the paint thinner? Do they need to assemble some kind of disguise but are unsure of how to get started? With the hint system right in the game, it’s easy to tell what puzzles the player currently needs to solve, which allows for presenting only those hint questions that would be beneficial. There’s no worry of spoiling something even by reading a question.
In the earlier Sleuthhounds games, the player could go into the in-game journal and switch to the Hints tab for a bit of help. Here they’d find all of the available questions listed out on the left side of the journal, with three hints for each that could then be revealed one-by-one on the right side of the journal. Listing all of the hints worked fine in the earlier games. They were short enough and didn’t have too much non-linearity that it would create an unwieldy list of questions to have to wade through.
Then along came Sleuthhounds: Cruise.
One of the big challenges of Cruise, in general, is that it’s, well, BIG! A number of problems that I never had to deal with in the earlier games, or else could safely ignore, now must be confronted due, essentially, to the sheer amount of data that Cruise has. This certainly applies to the hint system. Not only is the game much bigger, but there are several non-linear sections where many avenues of investigation are open to the player at once. This means that using the same simple list of questions results in a looong list that is simply overwhelming to use. And if it’s overwhelming to use then people won’t use it, defeating the purpose of having it there in the first place.
Confronted with this issue, I knew that I needed to introduce some level of hierarchy into the hints. Some way to group multiple related hints together to make the system more manageable. For a while, I toyed with the notion of changing the hint system to use a tree view with different sections that players could expand and contract. The problem I foresaw with that, though, was that players, who are looking for a quick answer to what they’re stuck on, would have to deal with managing the tree.
Step back and think. A former manager of mine once told me that with regards to designing software – though it’s quite usable for pretty much any problem – and it’s something I’ve remembered ever since. Software designers have a tendency to go down the rabbit hole of “What about this? What about that?” and think of all the crazy fringe cases that could possibly come up. This almost always leads to an over engineered system, like implementing a fully expandable and collapsible tree of hints.
In stepping back and thinking about both the hint hierarchy and how the game itself works, I was struck by a blinding bolt of the obvious. Narratively, the game breaks up what players can do into discrete investigations and within those investigations are a number of steps to carry out. I’d vaguely known that before, but once I cemented that in my mind, I realized that I didn’t need a full tree view. I just needed one list of the open investigations and then a second list that would display the pertinent questions for a given investigation as selected in the first list. I didn’t need an arbitrary number of layers in a tree, I just needed two.
That was the biggest design decision out of the way. Of course, once you lock in a choice like that, you then have to deal with all the ramifications. One of the nice things about the old way being a simple list of questions, was that it was very easy to remove a question from the list once the in-game action associated with it was done. If there was a question like “How do I open the red door?”, then that question could be dropped from the list as soon as the door was opened. However, now I’m adding in a second, higher level list.
With this second list representing whole investigatory lines, I didn’t want to ever leave one of these investigations sitting in the list, but then having no questions in it when it was selected. I also didn’t want an investigation to arbitrarily come and go if, for example, you answered one question that then left the section empty but later on another question got added in to bring that investigation back.
Fortunately, almost all of the investigations had a clear start, a clear end, and a series of steps in between such that there was never a point in time where an investigation was sitting there with nothing to do. In the few situations where a section could get emptied out and then get more questions later, I realized that either I was missing questions to make that investigation complete or that section actually needed to be broken into two sections.
With the questions properly separated into sections for the different investigations, that still left one issue to deal with. Whenever the hints page of the journal is opened, which section and which hint should be selected?
Some scenarios are easy. If there’s only one question in total, then it and its section should be selected. Or, if the player had a question previously selected and that question is still unresolved, then start with that question and its section selected.
Things get more complicated if the player had a question selected but then, in-game, completed the actions associated with that question. At that point, the question goes away and the game needs to select a different question to start the player on. This, I determined broke down into two cases, one where the question goes away but its section is still present and one where both the question and the section go away because the question was the last one in the section.
To help determine which question should be selected, I had to introduce one more feature into the questions. A differentiation between ones the player had already viewed the hints on and ones they hadn’t viewed any hints for yet.
With that in mind, when a question disappears, if the section it was in remains, then that section is selected and the first question with no hints revealed is selected. The idea here is that the first question with no hint revealed is likely to be a question that was newly added due to completing the actions associated with the question that disappeared. More simply, the new question is the next step in the chain of actions the player needs to do. If there are no questions with unrevealed hints in the section, then the first hint in that section is selected instead.
Of course, if both a question and its section disappear, then it’s not just a matter of selecting a new question, but selecting which section to go to next. In this case I opted to go to the first section with a question with unrevealed hints. If no such section exists, then go to the first section that only has revealed hints.
I wasn’t certain if the rules I’d picked were good ones or not. However, I had to replay the entire game a couple of times to test that all the questions appeared and disappeared when they should. This gave me the opportunity to test how sections and questions became selected. On one playthrough, I went for the worst case scenario, leaving as many sections and as many questions open as I possibly could to see how bad the navigation of the hints became. I’ll readily admit, at its worst, the hint system does get a little awkward to deal with. However, it wasn’t nearly as bad as I feared. Since I had to specifically go out of my way to leave as many open questions as I could, I deemed the whole solution to be good enough to handle most situations.
It’s taken a good chunk of time to work through the in-game hint system. As complex as reworking the hint interface was, that was really only a small portion of the time in comparison to getting all the individual sections, questions, and hints in place. All of that work was definitely worth it though. Building up all of the hints forced me as the developer to go step-by-step through the game multiple times. This was excellent for finding and squashing a variety of logic bugs in the game and for identifying various small plot holes that I also patched as I went along.
The game was already in a really good state programming wise prior to my starting on the hints. Now that the hints are done, it’s even more solid. At present, I’m now doing a final dialog review of the game. There’s a few last places on the fringes that need dialog lines written for them, and I’m completing those now. Once that process is done, all the dialog will be finalized. At that point, I can move on to the task of voice recording. But that’s a topic for another time.