VectorStorm Blog

Well, it’s been well over a week, time to talk about how things went with Robot Finds Ice Cream.

In general, I’m pleased with the game, but less pleased with the production quality that came out of it.  I justify it by pointing out that it was implemented in just a week, and that explanation seems to satisfy everyone except me.

More beneath the fold.

Continue reading “Robot Finds Ice Cream Post-Mortem”

So it’s time to talk a little about the Game in a Week that I’m ostensibly working on.

This particular GiaW is interesting, in that of all the GiaWs I have done, I got the final game idea for this one the earliest in the week (Tuesday morning), but left the first implementation the latest.  This was primarily due to work and other real-life factors distracting me.  Also, I was introduced to several neat TV shows this week, all of which have conspired to pull me away from the computer.  Also also, I’ve been a little distracted by MMORPG Tycoon bugfixes and development.  Now I know how Petri feels, trying to do his monthly games while still getting work done on Crayon Physics Deluxe!

Anyhow, this is also the GiaW where I’ve used the most words from the initial quote, in setting the game theme.  The initial quote (from J.K. Rowling’s Harry Potter and the Sorcerer’s Stone, although I’m sure that the same sentence appears in the less deprecatingly-titled Philosopher’s Stone), I’ll remind, was this:

It was also very hard to remember where anything was, because it all seemed to move around a lot.

I’ve pulled words from this passage to form my game’s theme, and the game’s theme is this:  “It is very hard to move around, because it remembers a lot.”

So.  In this game, the player takes on the role of a young boy.  This boy has a robot pet/friend/nanny, and is going shopping with that robot.  Unfortunately, the robot is being a little difficult today;  owing to a minor design flaw in its object-avoidance programming, the robot absolutely refuses to cross its own path, for fear of colliding with itself in the past.

Also unfortunately, the robot has the money.  And so the boy must get the robot to each of the vending machines in each level by pulling on the robot’s leash or shoving the robot, but with the robot never agreeing to cross its own path.

This game is strongly grid-based, and there is no time limit;  each level is a maneuverability puzzle which players must solve to reach the next level.  And it’ll be trivially easy for anyone to create new levels for the game.  And I’m hoping to set it up so that the computer can automatically generate new levels itself.  Though that might be a bit of a push, by the end of the day tomorrow.  We’ll see!

Anyhow, I don’t have a title for the game yet;  possible options I’ve entertained are “Robot Pal”, “Robot Goes Shopping”, and my current favourite, “Robot Finds Ice-Cream”.  So for right now, I’m just calling it “Robot”.

I’ve gotten very little coding done in the past week;  mostly feeling a little worn out and uninspired.  So I’m going to kick myself into gear by starting another Game in a Week, as a break from development on MMORPG Tycoon.  Not to fret, though;  I’ll be back on MMORPG Tycoon after this is done. 

It’s past midnight at the moment, and I really need my sleep, so I’m going to keep this short.  The book for this Game in a Week is a hardback edition of “Harry Potter and the Sorcerer’s Stone”, by J.K. Rowling (as though I had to tell you that).  This is a US printing of the book, published by Scholastic Press, and the text is copyrighted 1997.  There probably aren’t many copies of the US-titled version of the book here in Australia, but somehow I wound up with one of them, so it’s the one that I’m using.

As always, my topic selection method is to open a book randomly, and take the first sentence which is completely on the leftmost page.  From this sentence, I must choose one or more words to take as the theme for the game I’m to design and implement within the next seven days.  In this case, I’ve opened to page 132, and the first sentence entirely on that page is:

“It was also very hard to remember where anything was, because it all seemed to move around a lot.”

In my mind, that passage kind of conjures images of a cross between Concentration and the Three Card Monte.  But I’m not nearly cruel enough to inflict such a horror on any of you fine people.  At least, not unless it gets to be Sunday and I haven’t come up with anything better. 

My initial thoughts are that good words for starting with would be “remember”, and “move around”.  And if I twist it a little, maybe I could turn “lot” into “lots”, and do something with small stones.  Or the game could take place in an empty lot.  Or there could just be a lot of things to remember or move around.  So many possibilities!

Anyhow, I’ll post more thoughts tomorrow, when I’ve had proper sleep.

So it sounds like the upcoming TIG competition is likely to be focused around procedural content.  I’d recently decided that I’ll need to rewrite Nicholas Spratt from scratch anyway, so I’ve decided not to start on Spratt 2.0 just yet;  instead, I’ll wait until the start of the upcoming TIG competition, which will presumably be sometime in May. 

In the meantime, I’ll work on a different project.  In fact, I’m pretty sure that I’m going to do another Game in a Week this coming week.  But since I’ll be away from home for the start of the week (and lose about a day due to plane travel), I’m going to make it easy on myself and select my own topic to complete, rather than go for the more traditional randomly selected topic.

But I’m still not sure about just exactly what I’ll be doing;  I’ll choose the final topic on Sunday night, as usual.  But I can say that the two GiaW topics I’m considering right now are:

1. Pulling StarShot out of the testbed games and turning it into a full GiaW game.
2. Making a MMORPG game.

And no, I’m not pulling your leg.  If I decide against doing the game-in-a-week MMORPG game this coming week, then it’ll be somewhere soon further down the line.

C’mon, you all knew I was going there when I mentioned networking a week or so ago, right? 

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.