Game Dev: Unintended Sophistication

March 25, 2016

When I developed the second Sleuthhounds computer game, The Cursed Cannon, there were various technical improvements and additions that I knew I wanted to incorporate beyond what the first game, The Unlocked Room, had. When I came to work on The Valentine’s Vendetta and the new Sleuthhounds Halloween game; however, I had no such intentions. I thought the game engine I had by that point was quite refined and evolved and that the holiday games would simply use what already existed. In reality, both holiday games have provided opportunities to improve the technical capabilities of the game engine upon which Sleuthhounds is built. And I didn’t even intend for that to happen.

I firmly believe that when a game incorporates a story that it is the story that should drive the technology for that game and not the other way around. Too often the tech for games is developed and then a story is tacked on at the end rather than being considered throughout. This is a shame as it means the story is unnecessarily limited. Think of it as creating an abridged dictionary of say 500 words first (the game technology) and then being forced to tell the story only with those words. Sure, you can probably do it, but there will be no room for style, for flare, for panache. Keeping that in mind, as I design my own games, and I consider the story and where it needs to go, I allow myself to design freely. I allow myself to write things into the story that I’m not sure if my current game tech can handle or can even attempt at all. It’s this approach that’s led to the unintended improvements in sophistication in the game engine I’ve developed for creating the Sleuthhounds games.

A good example of story demanding technical additions in the game engine is the dusting sequence in The Valentine’s Vendetta. In that game there comes a point where you have to convince the maid, Henrietta, to help you or at least not to interfere with your movements. There are several ways to do this and one is to offer to do some of the maid’s work – specifically some dusting.

Dusting the pictures directly.

During this sequence, the player is taken to a close up of a picture gallery. Here they have to move a feather duster across the pictures to remove a layer of dust. The thing was, at the point I wrote that into the story the game engine didn’t have anything in it to support drawing a layer of dust over top of an underlying image and having that dust be selectively removed away based on where the player moved the duster.

I could have changed the sequence so that the dusting was just a simple animation. The player clicks the feather duster on the pictures and then Homes or Ampson are shown dusting the pictures off. However, I really wanted to give the player the chance to do the dusting themselves, something a little more direct control. So I added that in. One of the benefits of rolling your own game engine is you can do stuff like that when the whim strikes you.

The interesting thing – to me, at any rate – is that this dusting technology is not a one-time deal. As I developed it and tested it out, I came to realize that it could be used in other non-dusting scenarios. The same underlying technology could be used to represent lemon juice being squeezed over an invisible ink message to reveal hidden words. Or it could be a pencil being rubbed over a sheet of paper in classic detective style to show what was written on the torn off page from above. Or, if the Sleuthhounds ever become archeologists, it could be used to represent layers of dirt and debris that have to be brushed aside. Whatever the case, it’s technology that can be used to create interesting interactions in the future.

The Valentine’s Vendetta isn’t the only game to push the technology of the game engine. The new Sleuthhounds Halloween game I’m working on is doing much the same thing. Without giving too much of the new game away, there are several sequences where “bad things” happen to some of the suspects and the Sleuthhounds have to render assistance. During these sequences, I want the player to be able to move around within a limited area of the suspect and to be called back if they’re straying too far away.

Limiting where the player can move is something I’ve done in past games. For each room in the game I have a data file that defines the walkable area of that room. In the past I’ve limited where the player can walk by swapping the definitions for the walkable area. While this limited where the player could move, it didn’t provide me with the means to detect when they were trying to move beyond that area. That was something the game engine just didn’t do. Without getting into the technical details of it, I’ve now enhanced the walking system of the game engine so I can detect when the player is straying too far. It’s not something I planned to do from the beginning, it was something that I needed to implement because the requirements of the story demanded it.

Story is not the only thing that can impact the technology of the game engine. In the case of the Halloween game, the visual design of some of the new characters also had an impact. When a given character is talking in a game, that character is actually represented by two images: a single static image for the character’s body and a series of images for the character’s head depicting all of the talking mouth positions. The head images are then rapidly swapped through to give the impression of speech.

Homes’s body and head.

When it comes to drawing the characters on screen, the game engine has previously always drawn the head first and then drawn the body. As you can see above with Pureluck Homes, the head goes down into a neck that is wider than the gap in the collar of Homes’s coat. That’s OK because the body is drawn over top of the head, so the excess neck is covered up.

Doc’s body and head.

The tricky thing with the Halloween game is that there are a couple of characters who have heads that, for one reason or the other, don’t work if they’re drawn below the body. Above is one of these new characters, dressed as the Tin Man from the Wizard of Oz. When he talks, his metal jaw opens and closes fairly wide. To look right, it needs to cover part of the character’s body. This obviously doesn’t work if the body always draws on top of the head. So now, the game engine allows for the head to be drawn either below the body, as used to always be the case, or to draw above the body when required. There’s actually a character that could have benefitted from this in The Cursed Cannon but I’ll leave it as an exercise for the reader to determine which character that was.

Creating tech for the sake of creating tech can be fun, but at best it doesn’t do anything except use up development time. At worst it may force a game’s story to bend to fit that tech rather than to be the story it’s meant to be. Conversely, developing tech to fit the requirements of the story means that the story can be told the way it’s meant to be. That provides a rich experience all around and is the root cause for the unintended increases in sophistication of Charlotte. Whoops, I mean the game engine.

Previous: A Sleuthhounds Trick or Treat in March?   |   Next: Walking for Ideas and Creativity