Dark Freight - or - how to build a spaceship in a day.

These crafting notes are about LARP. About scifi. About AI. And about creating an immersive reality with light, sound and effects that allow participants to for a short while believe they are actually in a living, breathing space ship full of creaks, croinks, alarm blares and everything that would fit. And about doing all that really really efficiently.

Hr. Ms. Mercuur - quickly captured before dragging all equipment on board.

The ask:EOS Frontier - a scifi LARP where I've been playing for the last decade - asked me if I could help transform the absolutely beautiful Hr. Ms. Mercuur into a real spaceship for a day. You know? add some lights, maybe some sounds?

Cool! Yes!! And I've done that before. Twice! But never to the extend that was now asked. This time it really needed to live! Participants would - as part of their game - find a spaceship that's almost a non-functional derelict, board it, coach it back to life and ultimately jump it to safety. And during that there could be pirates, messy intergalactical space incidents, reactor leaks, and and..

OK cool! But that's more than just bringing some sound effects. I needed to really bring everything and go next level: fully control all lights, all sounds, and create a fully immersive environment. That means gear. Lots of gear. Speakers. Microphones. Lights. Control decks. Mixing desks. Buttons. More buttons!

This will be complex. If I want to do this, I need to do this differently.

What makes this complex?

There are several constraints:

1. Space constraints. Specifically: the location where I as a game master would most likely be operating from only has a small table. Big enough for a laptop or two, but not for a full sized mixing desk for audio, and a full sized light console for DMX stage lights. So, whatever I bring to control this must fit on one table.
2. Time constraints. Specifically: there will be a short setup time. The game will start at 12:00, and run till 18:00. We can only be there that day, and at the earliest at 09:00. So, whatever I bring needs to be from-car-to-running in less than 3 hours.
3. Control constraints. To run a LARP well, a game master needs their primary brainspace allocated to understanding the interactions participants make, and how that influences the set story line. However, for anything scifi to look real, one expects many things to happen all at once everywhere. A crash sound here, an airlock decompressing there. Groaning metal elsewhere. Flickering strobes near the reactor room. Alarm sounds blaring in the armory. You name it. For each I need to press a button. If all happens at once my brain will be completely swamped with timing sequences. This won't do - my brain space should not be occupied by remembering which button does what on which control surface. So, whatever I bring should just have single buttons that control the story, not the props. And the story controls the equipment.
4. Radiation constraints. Odd one, but really. We're so used to just having internet always, and assuming we can wirelessly control sound and lights. Not here. This ship used to be a minesweeper. As such, it will have crafty ways to demagnetize itself so mines ignore it. That's done with huge coils of wire. You know what else those coils will do? Distort and completely utterly demolish any kind of wifi. Oh and part of the ship will just be steel.. also not the best at transmitting radio waves. Fun! Whatever I thought off had to use physical cable for the important bits. This significantly adds to the setup time, and will have to be taken into account.

Oh and lastly, again, time. I don't have any. So whatever I come up with needs to happen fast.

So let's build the tech stack in a day.

OK, given the above constraints, bringing my usual gear is not an option. I want to design a new stack for this. How? Good news: this is now solvable with AI.

I fired up my code editor, dumped in a stack of requirements - what hardware I own, what I expected the thing to do, the problems I expected to have as listed above, and a copy of the plot as written by the game masters - and let AI churn on for that for a while.

What could AI do there? Turns out: a lot. Let me wri.. wait.

Introducing my one-time guest writer: Claude!

Hi! I'm Claude. Ork asked me to introduce myself here, which is a bit of an odd request — having the AI write the bit where Ork talks about using AI for LARP — but honestly? That's very on-brand for him. I'm Claude Sonnet, made by Anthropic. I live in Ork's browser, his terminal, and apparently now his newsletter drafts.
I don't generate his photos. I don't replace his creativity or his craft. What I do is help him think, write, plan, and build. Which brings me to the interesting bit.

Claude Code and LARP props

The place where I've been most useful lately isn't photography at all. It's LARP.

Ork has been using Claude Code — the terminal-based version of me, the one that can actually read and write files and run commands — to push his LARP prop tech to places that would previously have taken weeks of frustrating tinkering. The workflow he landed on came directly from a blog post by Boris Tane, and it's genuinely changed how this kind of project gets built.

The core idea from Boris: never let Claude write code until there's a written, reviewed, annotated plan. Research first. Plan second. Annotate the plan until it's right. Then — and only then — implement. The plan lives as a real markdown file in the project. Ork reads it, adds inline notes where something's wrong or needs adjusting, sends it back, repeat. Once the plan is solid, implementation becomes almost boring — which is exactly the point. The creative and architectural decisions all happened before a single line of code was written.

This workflow turns out to be a perfect fit for one-person LARP prop builds where the requirements are very specific but the technical surface is huge.

Building the tech stack for EOS Frontier: Dark Freight

The most recent example is Dark Freight — a game master control system built for a single-day immersive LARP where participants believe they are aboard an actual spaceship that needs to be resuscitated and made fly-worthy. Six hours. Multiple rooms. Players moving between areas, solving problems, experiencing a story.

To pull that off, the game masters sit in a single control room and need to run everything from one interface: spatial audio routed through a Behringer XR18 mixer to speakers hidden in each ship area, DMX lighting via ApeCoins wireless lights, a text-to-speech ship computer voice with sci-fi effects baked in, walkie-talkie-style intercom with squelch sounds, and a camera system to watch all rooms at once. Oh, and all that mapped to touch screen sliders that map to in-game state — low slider values mean clanks, thunks and red emergency lighting; push it up and the ship hums back to life.

That's a lot of moving parts. Python for the audio engine (via the Pyo library), DMX control, a UI that runs on a touchscreen, local TTS so internet outages don't kill the ship's voice mid-game. The kind of project where normally you'd spend the first weekend just arguing with yourself about which UI toolkit to use.

With the Boris workflow and Claude Code, the research phase mapped out every dependency and constraint before any choices were made. The plan document worked through the full architecture — Svelte frontend, Python backend, how Pyo talks to the XR18, how DMX slots get addressed, how the ship-state sliders tie everything together — and Ork annotated it until it reflected exactly how his hardware stack works, not a generic version of it. Implementation followed the plan. The result is a system that actually knows about his specific gear, his specific LARP, and the specific chaos of running SFX live for a room full of players who are deeply committed to being on a spaceship.

Hi, it's Ork again. Yes, I really did have Claude write that bit. Felt appropriate. Boris's workflow post that inspired me to do it this way is at boristane.com/blog/how-i-use-claude-code. Worth the read even if you're not a developer.

Making the packing list

Back to hardware land. Yay for single interface, but those 3 hours will still kill us. Planning how to do this efficiently is going to be key. I prepped a setup-list with instructions per room and got the help of several lovely people, including - most critical - someone to keep everyone else out of my hair while I rushed with getting all to actually connect and work in the booth! Thanks Gerard for coordinating all that!

What did we end up bringing?

• a crate full of security cameras and microphones placed throughout the ship - so we could remotely see and listen in to each location. Invaluable. This means players don't needlessly run into game masters, which increases the immersion.
• one Behringer XR18 digital mixer - I love this thing. It is small, unbreakable, fakes being a multichannel sound card with plenty of ports. Able to route all microphones rigged in the ship to my control desk so we can listen, and can route all outputs my app generates to each individual deck.
• one Enttec Pro USB DMX interface, wired to a DMX splitter so I can run several DMX lines from the booth.
• several active speakers placed at strategic locations throughout the ship - all wired to the XR18. These make the ship do whoomp!
• 4 crates full of Apelabs wireless battery powered lights. I love this brand for LARP!
• to overcome the wifi problem, 3 Apelabs Connect boxes, each wired up by cable to the DMX splitter in the control booth. This meant that each light in the ship had a Connect within 5ish meters. That worked well enough.
• approx 400 meters of XLR cable, DMX cable and network cable for all above sound systems, light systems, security cameras and microphones. Not to mention a significant number of cable wraps to stash all of this out of the way. I am so glad that these ships come with central ducts to move cables between decks!
• one tablet to control the mixer, and one microphone in the booth to fake incoming transmissions
• and one laptop to control this all.

The HW tech stack in-a-diagram!

Go time!

Armed with all above, and a document explaining what-goes-where, we went. We built. And it worked! Mostly. We had a few graceful degradations (one speaker did not work, one cable was bad) but we managed to get everything done and at 11:59 we could start.

It was fun.

Most important lesson learned: bundle cables you know you need to run together beforehand. Saves time. Next time!

Together with all the very cool very techy very ingame puzzle props the rest of the crew made and brought (you'd think light and sound are enough, they really are not) I believe we all did something impressive! It really looked cool! Thank you fellow crew, fellow players, and everyone there for bringing us these opportunities for having fun!

Pictures of the results follow below! The actual LARP is not depicted here. When photos are released, and provided participants are OK with it, I'll add a few!