VectorStorm Blog

So someone pointed me at an entry to the recent Ludum Dare entry, The Butler Did It by Surrealix. Butler is another interpretation of the “randomised murder mystery” genre, like my own Nicholas Spratt project which I’ve been poking at on and off for the better part of a month, now. While I was unable to get Butler to run on my computer (the Windows port crashes at startup for me), I did take a quick glance at the source code to see roughly what it’s doing, and how it compares to Spratt.

For those who haven’t heard of it before, Ludum Dare is a 48 hour programming competition which
takes place twice a year, where the theme is announced at the start and then you have 48 hours to complete a game based upon that theme. It’s a bit like my “Game in a Week” thing, only even more compressed.

The thing that impresses me most about The Butler Did It is how much went into the game (developed in under 48 hours) that I had to cut from my Game-in-a-Week-edition of Nicholas Spratt due to implementation time issues. For example, Butler has a randomly generated mansion layout, whereas that was the very first thing I decided not to do in Spratt. I have some serious issues with the particular algorithm that Butler uses for level generation, but it’s extremely impressive to see it working at all in a game which was developed under such a short time deadline.

In addition to that, Butler actually has its characters pathfinding and moving between rooms, so that travel time becomes another way to eliminate possible suspects. That is, if someone has an alibi that proves they were on one side of the mansion at time ‘x’, then you can be sure that they couldn’t have made it to the opposite side of the mansion at time ‘x+1′, simply due to travel time. In Spratt, this sort of deduction was the second thing I cut; I just made my time slices large enough that a character could reasonably be assumed to be able to get anywhere they wanted to go within the 15 minute period between ‘turns’.

Finally, the murder generation itself. Butler is using a very similar murder generation system to the one I wrote for Game-in-a-Week Spratt; it divides the timeline up into slices, and each guest is in a single room in each slice. It starts by randomly selecting a murderer and victim and places them into the timeline first, and then starts filling out what the rest of the guests see and do. But it has some very significant improvements over how I did this in Spratt.

Most notably, it takes steps to ensure that the necessary witnesses are present at appropriate times such that every mystery it generates is actually solvable along a single line of reasoning, whereas Spratt just provided several different ways that a mystery could potentially be solved, and quietly hoped that through random chance, enough witnesses would be around to provide evidence for at least one of those approaches to work (and thus, Spratt’s mysteries were not always solvable). I should really take this extra step, to ensure that witnesses are present where they’re really needed, to ensure that cases are always solvable. Additionally, Butler intentionally and explicitly plants a third character; the “red herring”, as a second likely murder suspect.

In fact, I’d say that about the only major thing that Spratt does that Butler doesn’t do is track the movement of the murder weapon after the murder is committed. In Spratt, the murderer tries to find a place to hide the murder weapon, and in some cases, knowing where the murder weapon was eventually found and approximately when the murder occurred, you can really narrow down the list of people who could have had the murder weapon.

For the last few days, I’ve been struggling trying to figure out how to ramp up Spratt’s timeline and murder generation system for a revision 2 release. I know that I’m not happy with the characters randomly bouncing between rooms the way that they do right now, but I’ve been trying to figure out how to fix it; whether I need to set up a timeline on a much smaller scale (say, a 5 minute increment instead of 15 minutes? Or maybe as little as 1-2 minutes?), or whether to stop using timeslices at all, and move to a more event-driven system. I know that I want characters to move through the mansion at a reasonable rate, but I don’t want the player to have to scroll through 72 data points per witness just to find out where they were during the evening (as would happen if I dropped to five minute increments). That just doesn’t sound like much fun.

It’s very interesting to see that Butler treats its hallways the same as rooms, and has a movement rule that a character can only move one room per timeslice. That makes an awful lot of sense for the way its mansions are laid out, but not so much for the way I’m laying out mine; Butler has a lot of discrete, disconnected short hallways, whereas Spratt has just one long winding hallway that all the rooms adjoin. The more I think about it, the more I think that I’m going to need to make use of the underlying grid pattern, and set some speed with which characters can move. But that’s going to require a bit more thought. It’d be a full rewrite of my current generation algorithm, and so I probably don’t want to do it unless I’m certain.

Anyhow. I’m keeping my eyes on Butler, and am hoping that the author notices and fixes whatever my crash bug turns out to have been. I’d love to get a chance to actually play it!

So it’s been a bit since I released The Incomparable Deductions of Police Constable Sir Nicholas Spratt — The Early Years, and I think I’m ready to do the post-mortem.

What went right:

• Managed to pare down “randomly generated murder mystery” into a concept simple enough to actually be implemented in a week, but still with enough meat to be interesting.
• Actually stuck with a single gameplay concept for the whole week. None of the previous Game in a Week projects have done that; all the others were redesigned into completely different game genres midway through implementing their original designs.
• Last-minute hustle to get a front-end onto the game, even after posting that there wasn’t enough time to include one. (Most of the code was stolen from Muncher’s Labyrinth, except for the intro sequence which was stolen from ThunderStorm, and then slightly modified)

What went wrong:

• I lost a day due to a power outage caused by extreme weather conditions; it was going to be the first day of programming, too. There’s not really a lesson I can take from this, but it’s something that went wrong during the week.
• I wrote the game as a ‘coreGame’, which means that it starts up automatically when the game is launched. I do this on almost every Game in a Week, and have to switch it over into a ‘coreGameMode’ at the last moment, when I’m implementing the wrapper interface. I really need to start out implementing these things as game modes, rather than as games. Always costs me an hour or two, at the very last moment of development.
• The current murder generation scheme is basically to perform a simulation, with some basic AI for each participant, and with the murderer trying to evade detection. This is a legitimate approach, but sadly does sometimes yield murder mysteries which are unsolvable, as there aren’t enough clues. It would have been good to have a computerised solver, so that the game would detect if it had generated an unsolvable mystery, and automatically regenerate until it had a solvable one.
• The game also has a pacing problem, largely caused by the interface used; it really lets people page through data very quickly, whereas murder mysteries call for a slower, more deliberate pace. This would probably be fixed if the player had to move through the mansion to interview suspects.
• The game also basically requires the player to have a pad of paper nearby, to take notes. I really need to figure out a more useful way to present information to the player so that this isn’t necessary. I actually had a few ideas which I didn’t implement for the game, because they likely would have made the pacing problem even worse. Both this and the above would probably both need to be implemented at the same time, to even things out.

I’ve listed a lot of “What Went Wrong” elements, but I actually think that this was one of my more successful Game in a Weeks, in terms of trying out an experimental game concept which I haven’t ever seen before, and finding what bits work and what bits don’t work. I’m definitely going to return to this in the future to refine the game. But as I’ve noted earlier, it won’t be the very next thing I do.

I’ve actually been thinking about possibly doing a sequel to Muncher’s Labyrinth next. Or maybe I’ll split StarShot out into a standalone game, as I think it really would stand up rather well on its own, if I gave it a few more tracks and a nice menu interface. Or maybe I should implement a “Look, I have physics!” game, since I really haven’t gotten much value out of integrating Box2D into VectorStorm yet, and I’m starting to feel guilty about how many people are finding my site via Google searches for Box2D games.

Well, as I’d warned, it’s not really as polished as most of the games that I put together, but that’s because there’s a whole lot more going on under the hood in this one! And I have to apologise in advance, but I’ve taken a sudden fancy to baroque game names, and so I’ve given one to this Game in a Week project; it’s named “The Incomparable Deductions of Police Constable Sir Nicholas Spratt : The Early Years”

I’m putting binary packages together now; they should be available for download within about an hour!

(Edit at 11:04pm: It’s up! Grab OS X or Win32 binaries, or build from source! The download link is here!)

So, with approximately twelve hours to go, here’s the state of play:

Stuff that works:

• Seven guests have dinner together in the mansion (staticly declared floorplan).  The soon-to-be murder weapon is in the Study.
• The evening’s events are randomly generated.  At some point during the night, someone takes and conceals the murder weapon, when they’re alone in the study.  Later, they get one of the other guests alone, and kill them.  Finally, even later, they try to hide the murder weapon (but the police find it when they arrive)
• The evening’s events are used to generate memories for all the surviving guests, including the murderer.
• The player can select guests and view their memories.  These memories show the guest’s own location, who was there with them (and in the event of the victim, whether the victim was alive or dead), and whether or not the murder weapon was in the room.

Stuff that doesn’t work yet:

• The murderer does not yet lie about his memories.  Need to come up with a clever method for the murderer to throw off suspicion;  this means that it’s pretty easy to find the murderer right now, as the murderer is always the first one to see the victim dead.  Once he stops immediately confessing, it’ll be a little more tricky.
• It is not yet guaranteed that someone will discover the body before the end of the evening.  Need to add that as a constraint to the basic plot generation system.
• There is not yet a mechanism for the player to accuse a suspect, or for the game to reveal the true killer.
• Finally, I want a text blurb at the start of the game, which gives a brief text introduction and specifies the victim, the time at which the body was found, and where the murder weapon was found.

And I guess that a nicely atmospheric music track would be nice, too, but this is basically just a prototype of a gameplay mechanic (albeit an extremely complex one), so maybe that would only be distracting.  I’m already getting the impression that this is a game which would play best with a piece of paper and a pencil at your side for notetaking, and that worries me a bit.  Would that kill this as a casual game?

I just spent the last five minutes tracking down a bug which resulted in a fresh corpse occasionally (about one time in three) wandering into another room after being killed.

Algorithmically generated content can be really tricky to get right, even when it’s as simple as this!

It’s really weird, sitting here and writing code for simulating what’s essentially a rather old-fashioned ideal of an Agatha Christie-style dinner party murder mystery, while listening to an old radio show “Night Watch”, which is basically a 1950s version of “Cops”, on the radio.. in this episode, the police were interrogating a murder suspect. (Who in the end turned out to have done it, but in justifiable self defense)

Next up on the schedule, “Dragnet”. And I’m in the middle of writing code to make the murderer try to find somewhere to safely hide the murder weapon, after committing her crime (it’ll be found when the police turn up, but the other guests won’t see it in the meantime). It’s gonna be an odd evening.

Well, the code’s finally to the point where the game can actually randomly generate a murder timeline. As it turns out, Bill killed Sam at approximately 12:15 AM, in the bathroom. Unsurprisingly, he used the Nondescript Murder Weapon(tm) to perform the dastardly deed. (When oh when will they learn that Nondescript Murder Weapons can be dangerous, and should be kept locked up? )

Now I just need to fill out each individual guest’s memories of the night (as opposed to the factual, actual events of the night), and then.. you know.. put in some sort of interface for the user to actually play the game, rather than analysing the events of the night by inspecting variables in a debugger.

I’m finding myself growing more and more surprised at just how much code needs to be written for this mystery game, even as I continue to pare it back to make it achievable in the time limit, and just how little of the code actually puts anything visible up on screen.

Here’s the current state of play:

I’m planning for this game to be the first of two “Games in a Week”;  the second will build on the first one, to make a more well-rounded game, but the first one will be a fully playable game in its own right.

This first game (as yet unnamed) uses a static, fixed mansion layout, currently seven rooms.  There
are also a fixed set of seven “guests” at the mansion.  The events of the evening, however, will be generated randomly.  The player gets the opportunity to replay the events of the evening from each surviving guest’s point of view by using an “interview guest” interface, but guests may have faulty memories or may be lying (due to being the murderer).  In this interface, the player will see the guest’s memories of his movements through the mansion on the evening, along with where they saw other guests, and where they saw the murder weapon.  Once the player has compared the memories of the guests, he will have the opportunity to accuse one of the guests of being the murderer, and optionally to nominate the time at which the murder took place.  Get the murderer right, and you win.  Get the time of the murder right for bonus points.

As you’ve probably noticed, this first game entirely abstracts away the concept of motives, and of determining a murder weapon.  It also removes navigation (as characters can move instantly from any room to any other room;  the hallways are not counted as locations), and theplayer never moves around the house himself;  the game is entirely driven by menus and other interfaces, rather than giving the player a direct avatar within the world.  I’d like to add all of these things into the second game.  But trying to randomly generate a solvable puzzle is turning out to be a big enough task without also worrying about collision detection and pathfinding. 

Big weather here, the last twenty-four hours. Downed trees, cancelled public transport, and total lack of power.

Which pretty much removed a day of development time on the Game in a Week. The power’s back now, though, and I’m back onto it!  With any luck, I’ll have some interesting screenshots soon!

And now for the bit that I didn’t have time to type out last night.

Twisty Little Passages is a neat history of interactive fiction; the genre that has grown out of text adventures. I bought my hardback copy from a bookshop stall at GDC in 2005, and have to confess that I still haven’t read the whole thing; it’s been on my “to be finished the next time I take a flight somewhere” list for ages, but keeps being passed over at the last moment, since it’s a reasonably sizable hardback book. In any case, the book is copyright 2003, and is published by The MIT Press.

I used to be heavily into interactive fiction, to the point that I had a few games of my own in progress, one of which was a tiny little experimental game entitled “The Jaws of Victory”, which I’d intended to finish up and enter in three different IFComp competitions, but was completely stuck for a satisfying endgame sequence. Oh well. But I do still play the IFComp entries each year, though often not in time for the voting deadline.

Since it was mentioned in the quote providing the theme for the GiaW, I spent some time looking at Mystery House today, as well as a few of the revamps and spoofs over at Mystery House Taken Over. I’d not seen the game before, and as it turns out, it’s really an interesting piece of gaming history. I’m going to need to make a few nods to it in my game.

Anyhow. My plan now is to start prototyping the basic gameplay using a static set of data, both level geometry and events. Once I have a basic gameplay prototype, I’ll return to random generation of the game data, to make it play differently each time. Hopefully I’ll have a few concept screenshots within a day or two.