Iterating on the Dining Room

March 9, 2018

A few weeks back I blogged about using physical items to design one of the upcoming Sleuthhounds: Cruise’s puzzle sequences. This particular sequence takes place in the dining room of the cruise ship and requires the player to move Pureluck Homes and Jane Ampson around other characters on a grid representing the floor of the dining room. This is one of the first sequences being developed for the game as it operates differently from anything I’ve ever done before, which means it’s a bit of a question mark design wise. Now I’m taking that rough prototype and refining it into something that I can put in front of playtesters. The sooner I know if the design works (or doesn’t work!) the better.

[The original physical model of the dining room sequence.]
The original physical model of the dining room sequence.
Click to view larger.

Initial work on this puzzle sequence started with game board pieces and Lego minifigures. This was to get a sense of the basic mechanics of movement around the scene.

[A crude digital prototype of the dining room sequence]
A crude digital prototype of the dining room sequence
Click to view larger.

From there I constructed a crude representation of the game grid within the Sleuthhounds game engine itself. I implemented the basics of movement on this grid so I could see all the pieces (characters) in motion. While these early tests were promising, I knew I couldn’t put this version of the prototype in front of players.

Common wisdom has it that it’s best to get a prototype in front of players as soon as possible. While that’s true to a certain extent it’s important to know what you want to learn from your players and even more important to realize what may (or may not) be in your prototype that will distract them from focusing on what you’re really interested in. In my case, I want to know if players can (a) figure out how to move about the room and (b) solve the puzzle sequence that the room contains. While I could put the above crude prototype in front of players and tell them what the scenario is, there’s so much missing from that version that players will get hung up on what’s missing and not pay attention to what’s present, especially any players who are more literal minded.

[A more refined digital prototype of the dining room sequence]
A more refined digital prototype of the dining room sequence
Click to view larger.

To help players out, I’ve taken the rough grid from the early digital prototype and I’ve reworked it. Now the dining room is actually starting to look like a dining room. The dark gray areas of the grid from the earlier prototype have now been mostly covered up by various furnishings: the tables, the spiral staircase, and the statue in the center of the room.

Additionally, refining the room in this way has allowed me to put some pictures in the background. As I mentioned, this sequence isn’t just about figuring out how to move around the room, it’s also about solving a given puzzle sequence. Some of the pictures arrayed about the room contain subtle hints on how to solve the puzzle in question. Clearly these hints were nowhere to be found in the rougher prototype.

Although the layout of the room is now much more refined, it’s still not quite ready to go in front of players. Just from my own testing I discovered a few issues that still need to be resolved. In a couple of cases, most noticeably around the base of the stairwell, it looks as though characters should be able to walk past one another because some of the grid squares that they can’t walk on aren’t covered up enough. So I’ll be taking this background through another round of illustration to clean up a few of those areas that I’ve identified as problems. Again, it’s keeping in mind what I want my playtesters to focus on when I present this to them to try.

When developing a game, or any piece of software really, where you’re venturing into design territory that you haven’t ventured into before, it’s good to get feedback on an early prototype. The mistake to avoid is placing a prototype in front of people before that prototype is ready. Unless you can easily explain any missing, limited, or incorrect functionality in a prototype that prototype is not ready for people to see. Sure you could give it to them, but the feedback you get will be clouded by them telling you about the problems you already know exist as opposed to the ones that you don’t know exist. At any rate, another couple of days and the prototype should be good to go. Of course, in software things always take longer than expected. ;-)