Sunday, June 14, 2026

Death at the Derby: A Six-Year Journey

The shortest summary

Pam and I wrote a murder mystery called Death at the Derby, and it's been published by Freeform Games!

Background

In 2015, Alissa and I hosted our first murder mystery party, "Murder at Sea" by Freeform Games. I'd actually played a character in this same MM some years earlier, when a college friend hosted it. In classic Jeremy "go big or go home" style, not only did we host this giant murder mystery of 33 characters, but we opted to include a character expansion pack with a mafia subplot, bringing the total number of people in our house to 41, on a very hot summer's night. It was on that night that I vowed, next time I buy an air conditioner, to buy something top of the line and industrial strength. (Or at least more powerful than SEER 13)

Over the years, Alissa and I, along with my friend Pam Hoffmann, have hosted well over a dozen of FFG's MMs, either at Alissa's and my house or down at St Olaf, where Pam was a Public Safety captain. For some of Pam's parties, she had more students to invite than there were characters, and so she and I wrote a few characters here and there to supplement. Most of these are even published on FFG's site on those individual MM pages!

If you haven't been to one of our parties, you can picture it like this: dozens of people roaming around talking to each other "in character" and trying to achieve their own goals. Everyone gets a character pamphlet with information, goals, abilities, and a secret and a clue. Most characters have the obvious goal of "solve the murder," but then there are other plots: bribery, blackmail, affairs, drugs, mafia tie-ins, people not who they appear to be, etc.

On the props front, Pam continues to outdo herself with props (many purchased from Dollar Tree and then re-purposed/painted/modified), and having a 3D printer at my disposal has also helped with some of the more "unique" props.

After hosting so many of these, Pam and I reached the completely reasonable conclusion that we were now experts and completely qualified to write our own MM.

Like many projects I've blogged about, this undertaking was more complicated than I'd expected going in, though I think I've done enough big projects not to be surprised by that anymore.

The Idea

Pam has considerably more horse knowledge than I do. Which is to say, she has some horse knowledge, and I have approximately none.

Pam's sister breeds horses, and Pam has spent a fair amount of time helping around the farm. When we talked about writing our own MM in 2019, she suggested a Kentucky Derby theme, and I said as long as she could provide the horse knowledge, I was game.

From the start we knew we wanted a large game, meaning 25+ characters. As we started our rough draft (and for some time thereafter), we named the characters things like "Owner #1", "Trainer #3", "Jockey #5", etc. As the plots evolved and we started naming characters, we drew inspiration for many of them from St Olaf-y names. In fact, ALL of the horses in the game got named after St Olaf references. We also decided to include two characters who had appeared in a different MM we'd hosted, and Steve at FFG was okay with us continuing their story in ours. I remember we put other Easter eggs in there, too, but the only other one I remember off the top of my head was naming a character "Bobbie Oldhut", a play on my friend Joe Newhouse's name.

Any case, when we started, I thought we might finish in about a year. That estimate proved to be... optimistic. During the 2019-2024 span of time, Pam moved across the country (twice), and Alissa and I had Rosemary in 2023. Add to that some good ol' procrastination, and, well, there you go.

Writing Process

All of our writing was done on Google Docs and Google Sheets, and almost all of it was done remotely on phone calls.

As for process, we followed FFG's writing guidelines (which have since been removed from their website, otherwise I'd link to it). We did this 1) because we like their games and wanted to emulate them, and 2) because we signed a contract with them in order to sell them the game when we were done, which they'd then sell on their website, so we were contractually obligated to produce something in their format :)

The details are fuzzy, but as I recall, first we brainstormed some basic character types, again those "owner #1" names and so on. This gave us an idea of how people related to each other. We knew we had track staff (like the manager, security guards, vet), owners / trainers / jockeys associated with various horses, and finally race fans / guests. Some characters were more fun to write than others. For instance, we thoroughly enjoyed writing Madison Abbott, a race fan who is color blind and so purchases an atrociously colored hat, thinking it's the most beautiful hat in the world.

Once we had a basic idea of what character types we had, then we started brainstorming plots. Obviously there's the murder plot, but then there's also a jewel thief (the "Emerald Eagle"), drug running, affairs, jockeys who don't like each other because of past conflicts, and so on.

We'd write a brief outline for each plot, then dive into writing the plot out in full; meaning writing out all the verbiage that would eventually get placed into each character's pamphlet, along with noting any item cards, abilities, or clues/secrets that we might want to give that character. All told, this "Derby Plots" Google Doc ended up about 104 pages long. (I also love over-using the word "verbiage" because I guess it has a stronger connotation in British English and so mildly drives Steve at FFG insane. (Steve really is a great guy.))

In addition, our items and handouts document was 101 pages, which is insane compared to all of the other MMs we've hosted. Pam and I like to go overboard with items and handouts. We also are bloodthirsty when it comes to murder mysteries and so that's why I'm still surprised that Derby ended up NOT including any poison. (All of our regular attendees know not to let their drink cups out of sight, lest someone slap a poison sticker on them!)

Let's Not Overcomplicate This

If I had to pick one phrase to represent our writing strategy, it would be: "Let's not overcomplicate this."

One or the other of us said this in, and I think this is literally true, every. single. phone call. Often multiple times.

This statement was then followed immediately by us overcomplicating it, whatever "it" happened to be that writing session.

The first warning came when we spent an agonizing amount of time working on a subplot involving Ariel, a fictional pop superstar. Not the murder plot. Not the victim. Not the suspects. A Hannah Montana parody, whose story we had convinced ourselves was the most important thing to solve first.

Now when we're writing a new plot we literally say, "Let's not turn this into another Ariel."

After some time, we had brainstormed around roughly twenty plots. Some were large, encompassing almost all the characters (like the hat competition, or solving the murder). Others were small, like the peanut butter dessert scandal or the missing horseshoe, involving only a handful of characters. Using FFG's suggested format, we tracked each plot and the characters it touched (along with a score 1-5 of how integrated they were to that plot) on a spreadsheet, so at the end of the day we could see, numerically, how "busy" any specific character was, and therefore, whom we needed to buff up.

We also created spreadsheets to track where characters were during the in-universe timeline. For instance, the "fancy dinner" the night before the race, we created a seating chart so we knew which characters sat with whom, and who might have overheard or seen other conversations nearby. We followed this up (eventually, far too late into the process) with a spreadsheet detailing the murder timeline: who went to the stables, and in what order? Who went to the office? Who was in the stables at the time of the murder, and what were they doing, and whom did they see on the way in and out? All of this background information that no one will ever see helped us craft an internally-consistent story for each character.

Finally, once all our verbiage was completely written, we copy/pasted each block of character text from each plot into individual character pamphlets. This is a surprisingly time-consuming and tedious task, yet oh-so-satisfying in the end.

Playtest

On July 27, 2024, we finally playtested the game. Our friends Roo and Erin graciously let us use their house to host, and we had 30-some-odd guests confirmed and ready to play!

Until, of course, the inevitable last-minute cancellations. This is unfortunately predictable, but no less frustrating. Due to core character cancellations, we needed to reassign people's character's last-minute, which is incredibly unfair to the friends and family who showed up expecting to play a specific character, only to be shoved a new pamphlet and asked to play someone completely different.

Once the event began, though, the evening went by in a blur. Years of effort all culminating in this 3-hour moment in time. Suddenly thirty-odd people were walking around playing characters that had existed only in Google Docs and spreadsheets up until that moment. It was exhilarating, and, like I said, a blur. Honestly I barely remember it. And I also was so busy I forgot to take photos, so I can't even rely on photographic evidence to help jog my memory!

The playtest generated lots of useful feedback.

One of the elements of the game Pam and I are most proud of was our "build your own race" worksheet; where in other MMs we've hosted the horse race was a fixed script, in ours we had created a highly dynamic race that would literally be different for every group that plays the game. Was it literally raining outside your venue when you hosted the MM? That would impact the race results. Did players successfully get their horses exercised within the game, or did a certain jockey ride a particular horse? All these variables, and more, would affect how the race played out. Honestly I'm still really proud of this.

But even I'll admit it was a little too complicated. In the instructions I had confidently written: "This worksheet is meant to be easier than filing your taxes." I then intentionally assigned the character who would fill out this worksheet to my tax preparer. Her feedback was incredibly helpful in simplifying that race worksheet after the playtest.

Are we there yet?

Between that and many other minor changes, we felt pretty good about the game and sent it off to Steve.

Finally done!

Or so I thought.

Maybe not so much. Steve now took a fine-toothed comb through the MM and it was clear we needed to do some significant revisions. To say I was disheartened is an understatement. I'd asked for this very kind of feedback... a year previously. So it was emotionally very difficult to receive it now, after we'd done the playtest, after I thought we were "done".

To be fair, Steve's feedback was spot-on, I was just frustrated about the timing. Steve was incredibly generous with both his time and expertise, pushing us to fix some gaping holes, and the end product is significantly better as a result. The key lessons that stick with me still are: "Does this character have enough to do?" and, "Would I enjoy playing this character?"

Those questions sound obvious, but they weren't (to me) until Steve put them in writing. Any case, we are proud of the finished product, and grateful for Steve's coaching along the way.

Publication

We finished our rewrites in April 2025, just before Alissa's and my daughter Shirley was born.

Steve took all the documents for formatted them into FFG's templates, and sent out a blurb in their email newsletter looking for play testers.

A few months later, I woke up to an email from Steve saying the game had been published! NOW we were officially done! Death at the Derby was finally real!

Looking Forward

Pam and I had so much fun we decided to do it again. Okay, well, we took some time away from MM writing to recover, but in January 2026 we did start writing another MM in FFG's style, and taking all our lessons-learned from Derby, which we hope they will publish.

This one is called Murder on the Red Horizon, and is a hard(ish) sci-fi plot set on a colonist ship bound for Mars. We wanted to do something smaller, so this one only has 11 characters instead of 32, and we're trying to put more responsibility into the hands of the players rather than relying on host intervention.

Of course, we still love handouts, so there are plenty of those. Some habits die hard.

Tuesday, January 04, 2022

3D Printed Stargate Atlantis

The completed gate
After finishing my Stargate SG-1 gate and warp core, my next project was Glitch's Stargate Atlantis model. This one's taken me just shy of two years, owing to, once again, many multi-month breaks in the middle. My preferred coping mechanism is avoidance with a touch of procrastination, and so after having a "smoke event" (where the magic smoke escaped my almost-fully-assembled gate), I had a difficult time overcoming my inertia of doing nothing in order to repair things. And then even after that, I avoided plugging the re-assembled gate in for a long time, rendering it what I called a "Schroedinger's Stargate" (simultaneously worked and broken, until I plugged it in and found out). One might wonder why I'd delay for so long just to find out, and the answer is quite simple: if I plug the gate in and it works, then there's no problem, I can go on to the next programming challenge. But if I plug it in and suffer another smoke event, would I have the emotional energy in that moment to cope with that demoralizing blow? After a string of long days/weeks/months at work, the answer to that second question remained "no," and so the gate waited until I'd built up some energy reserves.

I share that first because I found myself telling that story a lot over the past year as I talked to various friends about the gate project, and also as a reminder in this social-media-highlight-reel-of-people's-lives world that there are also grittier down-swings behind the polished presentations. And while I generally do polish up my work before writing about it on this blog, I think it's important to acknowledge the full breadth of the journey.

Charred wires after the "smoke event"
In any case, I did eventually plug in the gate, it worked (no smoke!), and I was able to move on to the coding. Unlike the SG-1 gate, no one had built one of these Atlantis gates before, and Glitch (the designer) hadn't published his source code. For my SG-1 gate, I had added functionality to Dan Clarke's (aka Boogle's) code, and I used that as a starting point for the Atlantis code. It's hard to say how much of Dan's code is left in the finished Atlantis product, but the basic structure is definitely still his, so he deserves a lot of credit for how much effort he put into creating the original and documenting it well enough that I could come along and keep improving it.

One of the most satisfying challenges to overcome in this project was the combination of having both addressable LEDs (my gate has 211 WS2812B LEDs) and sound, both controlled by a Raspberry Pi. While that might seem like a "so what?" kind of question, "everyone" on the internet said it couldn't be done. "They" said you can have a Raspberry Pi with sound, or you can have a Raspberry Pi with addressable LEDs, but you can't have both, because both the LEDs and sound want to use the same interface for communication, and interfere with each other. The only solution the internet proposed was to use a separate microcontroller (like an Arduino) to drive the lights, while the Pi drove the sound.

I stubbornly couldn't believe there was no way to make this work without the use of an extra device. To work around this suposed limitation, I spent some time working with a 74AHCT125 chip and was able to get the lights to light up, but no sound. Eventually, after a LOT of Googling and trying out several python RGB LED libraries, I found one that worked by using the SPI bus for the LEDs instead of the I2S, which is what the sound board uses. I was giddy and recorded a short video of my Pi playing sound AND turning the LEDs on, and sent it to my parents with a brief explanation, along with our family line of "I drew a star!". (Regular readers may already remember the story from my first Stargate post, but I'll include it here, too: when my Dad was first getting into computer programming (in the early days of personal computers), he excitedly called my Mom into the room so he could show her that he'd drawn a star on the computer screen. My Mom lovingly said (or maybe just thought to herself), "so? If you give me a paper and pencil I can draw a star for you," until Dad explained more about how complicated the programming was, etc. Since then, it's been a comical story my parents tell whenever something looks easy but in fact took an incredible amount of time/effort. As was the case with drawing my "star"[gate].)

My other sort-of-new-to-me experience was designing some of my own printed circut boards, or PCBs. Previously I had made some tweaks to Boogle's PCB designs for his warp core and SG-1 gate, but this was my first time designing my own from scratch. Fortunately, these were not complicated.



The first was just a small board to sit on top of the Pi, with connections for the power supply coming into the board and going out to all the LEDs, along with a couple capacitors. The remainder were for mounting the LEDs. The WS2812B LEDs are very tiny (5mm square) and melt easily when trying to solder wires onto them. As noted above my gate has a total of 211 (though in fairness 61 of those are on a pre-made flexible strip, mounted inside the ring for the wormhole effect; so technically only 150 LEDs if I was hand-soldering them). That was, I decided, more delicate soldering than I felt qualified to tackle. Instead, I opted to design a series of custom PCBs for each specific area of the gate:

  • a single LED (but with easier-to-solder connections, since it was on a tiny circuit board)
  • a three-LED Chevron board, to use on the nine chevrons around the outside of the gate
  • a 15-LED rear-window board
  • Eight different stair PCBs, but all combined into one larger design so they didn't have to be ordered separately

I might have gotten a little carried away, but having these easier-to-solder (and already pre-assembled) boards did make my life a lot easier when it came to assembling the gate. I put on some good audiobooks while soldering and the time went quickly.

I mentioned earlier I had a "smoke event" after assembling the gate. At first, I tried to fit the Pi and all the wiring into the base of the gate, as I'm under the belief that somehow that's what Glitch did in his original model. Well, I have no idea how he fit everything in there, because I couldn't. Well, I guess, I *did*, but in doing so smooshed some of my wires loose and caused a short, and some small amount of smoke. It was at that point I decided I would move the Pi and speaker into an external control box, to make the base less crowded. I learned the basics of using TinkerCad (a free online 3D modeling software) and designed a simple box in that.

It was also around this time that I did some math and realized my power supply was woefully under-rated for what I neeeded. Seperately from the smoke event, I think I actually burned out a small power adapter receptacle - all I know is it used to work, and then I turned a bunch of LEDs on, and then it no longer worked. Turns out that particular adapter was only rated for... 2 amps? I forget now, but it was definitely less than the possible 12 that I could draw with this many LEDs. Thus began my rabbit hole journey about power supplies and wire gauges, and redesigning my Pi's PCB with much thicker traces that could handle the necessary current.

Note the fancy orange power button on the left side of the box
Eventually, everything was assembled, re-soldered, and the control box even has a fancy power switch (it's such a simple little thing but I'm really in love with the fact I made something with a power switch; makes it feel more "real"). Then it was just down to programming. If you're really bored and want to get a glimpse into some of the issues I ran into, you can check out this Troubleshooting document I wrote for future builders to reference. There were many hair-pulling issues, but the one I'll share here that it took me hours and hours to solve, was the story of LED #192.

I still don't know for sure if it's a physically bad LED, or something wonky in the LED software package, or something else entirely. I had an issue where when I turned on the LEDs to the left of the staircase, the topmost LED would flash on for a split second, then turn off, while all the other LEDs remained on. If I turned the LED on by itself, it stayed on. If I did a strand test that turned on ALL the LEDs in the entire gate, the LED worked fine. If I coded it to turn red, green, or blue, it worked fine. If I turned on the side LEDs followed by turning on the wormhole, for instance, the single LED would flicker as if it was being told both to turn on and off at the same time. I'm pretty sure at one point I replaced the LED, though I'm not 100% sure so I can't completely rule out a hardware issue. In any case, it was baffling.

After many hours of troubleshooting and experimenting, I eventually tried setting the 4 LEDs in that side panel to a different color, and the top LED stayed on. So, for reasons I don't understand, that particular LED (#192 on my strand) simply can't be set to the particular color "Color(128,128,128)". Pretty much any other color and it'll work fine. I lost track how many hours it took me to figure that out.

The mystery of LED 192 was the last bug fix I worked through before publishing my finished code on GitHub and posting my make on Thingiverse, as well as this YouTube video of the completed gate, which I'll invite you to enjoy now, followed by some more photos of my gate under construction!

And a simple strand test:


Completed gate, with control box






Spray-paint test for "wormhole" inner LED strip

Hand-soldering individual LEDs is fiddly!!!






Back of the staircase







Testing LEDs during assembly