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!