Safe Haven — the story

What inspired me

Safe Haven started as a rough idea. I wanted to make a survival game but different. First of all no zombies, which led me to vampires. Then that grew to the idea of day-time gameplay of scavenging for supplies while at night just hoping your defenses could hold. The things you do by day decide whether you live through the night, and what happens at night reshapes the next morning. If your defenses were destroyed, you had to rebuild, vs. focusing on building additional defenses for new weak points.

From that I built the premise: a vampire apocalypse, a dead city, and your safe haven in an abandoned gas station. You're a small crew of survivors trying to make it one more night. You dispatch them to scavenge and rescue, you build the line before dark, and at night you watch and steer. The hordes don't see the lights, they track the heartbeat of the living, so your growing crew literally makes the horde bigger. Day and night feed each other, and that interdependence is the game.

How I built it

First, I made a possibly stupid decision at the start. I wanted to see how good local AI models have gotten. So while the entire game was made with AI, it was made using locally hosted AI on my own server, using open source weights including Qwen, Gemma, and Muse.

Given this was my first experience with AI building a larger project, there was one key rule: every step leaves the game booting and verifiable. Development is plain ES modules over a local server, no build step, so there's no "works in the build, broken in the repo" gap. A build step exists only for the submission: it assembles the modules into one readable, non-minified index.html plus a vendor/ folder, zips it, and an extra testing step to re-verifies the extracted zip before anything ships.

Two habits carried the project. First, a build log: every session gets an entry, honestly what worked, what didn't, and the wrong turns included. This acted as a longer-term memory for the AI between sessions and when something needed to be reviewed. Second, determinism as a testing tool: the world is seeded (a mulberry32 PRNG, value noise), so the same seed gives the same city, and the ultimate goal is two fresh runs producing a byte-identical event dump. On top of that, a headless-Chrome test rig drove the game over CDP including pixel-band reads and network audits that assert zero external requests. The difficulty itself follows a rubric: it scales by information density, not by stat inflation, and every failure must be diagnosable.

What I learned

• Presentation and simulation can and likely should be separate. The visual effects and audio are presentation only and not the game itself; the determinism gate stays byte-identical no matter what the presentation does, and that contract is what made it safe to add effects without the worry of breaking the simulation.
• Automated tests are great but can't cover everything. Multiple times there were UI specific issues not found by any of the structured testing. It was only when play testing manually between changes that I had to raise questions about what was built and why it worked the way it did. The HUD is part of the simulation's contract, not decoration.
• Building with AI is closer to being an engineering manager than an engineer. You're not writing code or systems, you're defining systems. And the better job you do at defining what you want, the better result you'll end up with.
• Trustable AI generation across larger session counts is possible. It takes effort to setup right, and you have to ensure safe guards are in place, but it's doable.
• Even with AI, source control is a must. It went off the rails a few times, or accidentally blew up the whole project failing to understand how the submission packaging had to work. But thanks to the combination of git and the build log, I was able to roll back the git commit, start a new session, have it read over the build log to remind itself where it was (at the time of that commit!) and continue from there.

The challenges I faced

The first challenge? I'm a control freak. So giving up all the power to AI to build everything and managing its work rather than doing the work itself was a hard habit to form. It also meant I had to learn how to trust the code being written, which meant nearly everything had to be testable, and for a game that means everything has to be deterministic. The second was time. The AI did what I asked it to do... ensure that everything was testable and could be verified to ensure nothing broke. Unfortunately those tests grew unwieldy and before I knew it there were hours of tests being run for every couple of small changes being requested. And I think third was figuring out the best way to iterate when I'm not the one making the changes. I couldn't just go change something to see if it worked, I had to think through every change and how to define what I wanted changed and why. In all honesty it probably meant the changes were better thought out, but I still feel like it took some of the spontaneity out of the creation process.

What I'm most proud of

I'd say I'm most proud of the fact that I now feel comfortable building a larger project with AI. Prior to this I'd use it for cool little one-shot tests, or small projects (3-4 prompts for a little command line tool or service). But I've taken away from this the confidence to lean on AI for larger projects as well as experience with how to best manage it.

What's next?

I'd love to be able to move the game closer to my original vision. Originally I wanted you to start out in a small haven. Easier to defend but only so many resources. As you rescue people you'd have to eventually find your next safe haven to move to. It could fit more people, hold more defenses, but also be a larger target for attacks.

I'd also want to replace the programmatic art and audio with "real" art assets and audio. They're not my forte, and keeping the game AI-generated per the requirements meant I just let it do its thing. Yes I was allowed to use art, but for the prototype I felt this was fine. For a real full finished game not so much.

Built With

• ai
• javascript
• llama.cpp
• pi
• three.js
• vllm