Dead On Time Postmortem

Here is a (belated) postmortem for Dead On Time, my game for 2020's 7DFPS. I've never done one of these before, but in the jam feedback there were people interested in how the clues were generated. So here it is!

STARTING OUT

I had another idea in mind for 7DFPS but it was pretty large and it involved tech I wasn't super-familiar with. I didn't want to wreck myself on a big ambitious thing (especially after the hellspawn year that was 2020), so I decided to brainstorm a small project.

But what? I knew I didn't want to do a traditional run-n-gun shooter, but I had no ideas beyond that. The answer came from a terrible pun: a 'First Person' shooter, i.e. a game where you have to shoot the first person.

A party seemed a good choice for the setting. Parties have that wierd ettiquette thing about showing up fashionably late, and the setting didn't require a lot of 3D assets.

I added the different party events to try to combat the oatmeal problem, where the procedural elements feel the same with each playthrough despite being randomized. If the game itself felt the same each time, at least the environment would change.

WHO'S ON FIRST?

I've never made a logic puzzle like this before, and frankly I had no idea where to begin. I decided to just make the simplest puzzle layout I could, throw it in the game and see how it went.

I came up with this: Each guest would give a single clue, saying they arrived either before or after another guest. Once the player had talked with everyone, they could infer who arrived first by cross-referencing everything.

This was BAD.

The problem was, since the solution space was so linear (the order of people being a one-dimensional line) there was no way to mix up the clues. As a player, collating all the info was tedious and once you'd done it you always had the right answer - so there was no fun, leap-of-faith tension when you pulled the trigger.

I thought about how to fix it, and I realised that I didn't need to tell the player the arrival order of every guest. It would be easier if the guests who arrived late just said so - removing themselves from the suspect list early on. I kept the existing clue layout for the just first four guests, then had all the others just say they got there late. This meant the player could start ruling out suspects right from the start instead of having to work it all out at the end. Immediately the game felt more like a series of 'a-ha!' moments, which is what I wanted - good!

BUT! With only four guests in the clue matrix it was easy to spot the pattern on repeat plays. To fix this I gave each character a second clue, which in most cases was randomized. It could be a super helpful clue which makes it easier to find the villain, or it could be completely irrelevant. Or it could be empty 'party talk' which doesn't contain a clue at all. But mainly it served as noise which made the 'real' clues less obvious to spot.

When I tested this, I found I could no longer tell which guest was which (in earlier revisions I could always pick them out)... but I could still reliably figure out who came first. Exactly what I wanted! This is the version in the final game.

I mixed things up a little more by adding a second clue tree (and in post-jam updates, a third) with the game picking one randomly each time.

LET'S LOOK AT A CLUE TREE

Here's the code for one of the clue trees...

And here's the same code with only the pertinent clues highlighted.

The first four guests (numbered 0-3 because I stuck them in an array) give the actual clues you need to pin the villain. Guest 0 says Guest 1 arrived after them. Guest 1 says Guest 2 arrived after them. Guest 2 says they arrived in time for the first event AND that Guest 3 arrived after them. Guest 3 says they missed that first event.

The rest is just creating a haystack to hide the needles in. None of that haystack is ever false (the guests never lie), but it's sometimes possible for a later-arriving guest to insinuate themselves if they say they got there before something/someone and other guests don't bail them out. This 'red herring-ness' is highly randomized on each playthrough and helps make each case feel different.

There's three clue trees in the final game. This one is the easiest with no red herrings - every guest after the first 4 either rules themselves out or is ruled out by someone else. The other clue trees have potential red herrings.

(S)COPING MECHANISMS

I had a severe bout of insomnia halfway through the jam and ended up taking two days off to catch up on lost sleep (reminder: never wreck yourself for a game jam!). When I came back I had to scope the project down to allow for the time I'd lost.

I ended up cutting two things. The first was the music: I'd planned for each party event to have a matching theme that played in the background, adding to the party atmosphere. Since the music was linked to the events it would change with each playthrough which would have been really cool. But it was also time-consuming - I'd allowed an entire day (at least) to work on the music, and while it would have been nice it wasn't a mission-critical part of the game.

The other thing I cut was the magnetic noteboard. I'd planned to include a feature where you could arrange the guests on a little noteboard, to put them in order as you gathered the clues. I'd never implemented anything like it before and I had no idea how long it would take. It was already in my 'MAYBE?' column owing to the uncertain time cost. It made sense to cut it as well.

EXCEPT! Cutting this turned out to be a terrible idea. In that first version of the game, the only way to keep track of clues was on paper in the real world - which I thought would be fun and detective-y, but in practice it really wasn't.

Once the jam was over I figured it wouldn't hurt to have a go at making the noteboard, just for fun. I did a quick Internet search for what I needed and it turned out to be three lines of code. Which worked immediately when I put them in the game.

It took a total of forty-five minutes to wire everything up and have the noteboard working in-game. And it changed the game immeasurably for the better - suddenly it was really easy to visualise the clues and put people in order.

THIS OATMEAL IS DELICIOUS, ACTUALLY

Let's talk about the oatmeal thing. I knew this game would suffer badly from the oatmeal problem, but I deliberately didn't fix it. Or more accurately, I allocated the time to other stuff instead. There's only ten variations of each clue type so they start repeating early on - to fix this would mean a spending a lot of time spent writing more clues, and even then the oatmeal would show.

But there's another reason why I left it the way it is. The clues needed to feel oatmeal-y. Since each clue can be randomly assigned to any guest I had to avoid unique speaking styles and character traits (this is the exact opposite of regular dialog writing, where you strive to give each character their own distinct voice).

I wanted the people to be dull anyway, so the player didn't become too attached to anyone (having to shoot your favourite person would be a real drag). This is why they talk in that weird, super passive tone - I didn't want them to be even slightly relatable.

If I added more variation to the clues I risked making the people more 'real'. I didn't want these people to be real. I wanted them to be like the little plastic boats in Battleship - just convincing enough to get the setting across.

BADNESS

As always, there are some things that didn't work as well as they should:

• The party event system isn't great. It's... there? And it works, in that you need to figure out the earliest event to work out the rest. But that's it. It doesn't really intersect with the main clue tree in any interesting way.

• Clues sometimes contradict. It's possible for a guest to say something like "Hey, the party is great since Sally got here" for one clue, then say "I hate Sally, I wouldn't have come if I knew they were here" for the next. To fix this I'd need to split the clues into 'positive' and 'negative' ones and implement some kind of reputation system.

• It would have been nice to have the party songs. Down the track I might do a new build with them in, just for fun.

GOODNESS

Overall, I'm really happy with how Dead On Time turned out. I can play it! I usually make narrative games so I can't really play them way other people do. But this one I can, and I enjoy it.

The final product is really close to what I imagined when designing it. In particular, the leap of faith at the end works exactly like I wanted - you're never 100% sure you've got it right so you sweat it out while you wait for the verdict.

Thanks to everyone who said nice things about the game! It got a much warmer reception than I expected and that always means a lot. And a shout out to my fellow 7DPS jammers - there were a lot of cool games this year and I had a great time going through them. Be sure to check out the entries if you haven't!