Sleuthhounds Production Update – The Critical Path, Designing from the End

April 3, 2015

With the big technical challenges out of the way, production on the next Sleuthhounds game demo shifted into work on the game’s critical path this week. The critical path is the minimum set of actions a player must perform in the game to progress from the beginning through to the end. Developing the critical path is an interesting combination of traditional software design and prose story outlining.

My background as a software developer has shown that anything of sufficient complexity to need a design is also of sufficient complexity that it can’t be fully designed. Similarly, my background as a writer has shown that outlining a story only gets you so far. In both cases, once you get into the actual production, you start to discover the little details that really make that production special and that you couldn’t possibly envision when doing ten thousand foot designing/outlining/planning.

I like to think of this experience of working through all those little details as exploring the problem space. If you don’t work through the problem space you’re doomed to have holes in your design and/or plot. I firmly believe that in programming and writing it’s critical to get the little things right. The big things tend to take care of themselves because, let’s face it, when you get something big wrong it’s blatantly obvious.

My “proto” design for the next Sleuthhounds demo consisted of about two pages of handwritten notes. This design primarily described the high level story points for the demo and could almost be read as an outline for a prose story rather than a piece of interactive software. In fact, this early design only included brief descriptions of a couple of the puzzles that provide the challenge of adventure games.

I like to get my hands dirty with both coding and writing. I’ve found I make the most progress by jumping in and working out all the bits that I already have in my head and worrying about the rest later. As far as adventure games, those bits might be a cutscene, a puzzle, a dialog tree, or even just the layout of a given room. Those bits tend to be points along the critical path through the game. The hard part is figuring out what needs to happen in the game to connect the points.

As I’ve been designing and developing that critical path, I’ve found one technique that has worked really well and that’s thinking the game through back to front. For any major story point in the game there needs to be some puzzle or challenge for the player to overcome to reach that point. I’ve found it much easier thinking along the lines of “this is where I need to reach, what prevents me from getting there” rather than “I think it’s time to put a puzzle in the game, what should it be?”. It’s a subtle but important difference.

[Working towards a critical clue.]
Working towards a critical clue.

Take the above very rough, work in progress screenshot as an example. In this scene, Jane Ampson needs to search the camera bag (represented by the funny blue squiggle at the base of the two trees on the right) to find a plot-critical clue. It doesn’t make for very engaging gameplay for Jane to just walk up and search the bag. Some challenge needs to get in her way.

The camera bag belongs to a tabloid reporter. He’s the little color figure in the middle of the shot. The obvious challenge then was that he would spot Jane and object to her rummaging through his things. So now the challenge comes into a little more focus, how to distract the reporter so the bag can be searched.

Taking another step closer towards the start of the game, it occurred to me that since the reporter has a camera bag that he should naturally be taking pictures. And he’s taking pictures at night so he’d have to use a flash. And then I thought, what if the flash was so brilliant that it left even him blinded for a few moments? Time enough for Ampson to search the bag. Without spoiling the puzzle, let me just say that the next step towards the start of the game involves finding a way to make the flash even brighter.

As far as intentional design goes, working back to front is great for coming up with puzzles and structuring how players experience the story. However, serendipity is also extremely valuable.

I know it doesn’t look like it, but in the same screenshot that green and blue squiggle on the extreme right is a little rickshaw carriage that Jane uses to get from place to place and is pulled by another character (the green part of the squiggle). Quite by chance, the camera bag and the rickshaw ended up next to one another in the rough scene. As a bonus puzzle for the “hard” difficulty setting of the game I realized that the driver of the rickshaw would also need to be distracted, but in a different way from the reporter. Again I don’t want to spoil things but the solution solves another story problem: that of the reporter catching Jane in the act and demanding the plot-critical clue back.

My main focus on the game now is working through all these critical path points to get the skeleton of the game in place. Once that’s done, then the door opens to a lot of other game development tasks including:

  • Seeing the entirety of the story to determine if anything should be added, moved, or deleted.
  • Creating alternate, easier puzzle solutions that result in a lower rating at the end of the game.
  • Interweaving side quests for the harder difficulty settings.
  • Evaluating the difficulty of puzzles and determining how much they need to be clued in game.

As the name implies, the critical path is critical for firming up as soon as possible. In theory that could be done entirely introspectively, thinking through everything without ever touching a line of code. In practice, it’s far easier and faster to dive in and see what surfaces as I go along.