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. :)