Inspiration
Everything burns. Even your home.
Most survival games ask what you'll build next. I wanted one that asks what you can stand to lose.
EMBERS started with one image: a small fire in a freezing dark, and the moment the only fuel left is something you care about. Survival here is emotional, not a depleting stat bar.
What it does
EMBERS is a portrait mobile survival prototype built on one rule: every item has a use value and a burn value. Burn it, and that use is gone for the run. A full run is about 15 to 20 minutes.
By day, move yourself and assign your eight survivors to gather wood, scavenge scrap, or hunt for tallow, while you strike out yourself toward the far ruins for rescue parts. By night, the cold drains the camp and wolves press the walls. When the fire finally goes cold, decide what to feed it:
- 🪓 A tool. The camp gathers slower for good.
- 🧱 The walls. All of them, at once. Nothing left between the camp and the dark.
- 🛢️ Your oil. The last easy choice, and it was your flares. Everything above this costs a person or your way home.
- 📦 A rescue part. Survive tonight, but push rescue another day away.
- 🧑 A keepsake. That person, and what they did, is gone.
The list climbs in heat, and the price climbs with it. Difficulty comes from your own choices, not random events.
How we built it
EMBERS was built with Claude Code through prompt-driven development, with each session documented in a build log. Small source files are combined into one readable index.html. Three.js r128, artwork, ambient loops and sound effects are bundled locally, alongside oscillator-generated cues. The prototype runs fully offline with no network requests.
A fixed-tick simulation drives heat, wolves and walls. The fire's defensive light radius and the warmth bar share the same heat value, connecting survival to visible feedback. A top-down camera follows the player, while HTML/CSS handles the HUD and burn menu. A separate verification script calculates balance curves from the live configuration to support playtesting.
Visual simplicity kept development focused on decisions and feedback. Terrain, fire, wolves, walls and survivors use coloured Three.js primitives, with warm, rounded forms for the camp and cold, angular forms for threats. Portraits and icons help distinguish survivors and burn choices. Firelight responds to heat, walls show damage before breaking, and the burn menu reveals each sacrifice's cost before confirmation.
Challenges we ran into
The hardest balance was keeping a loss-heavy loop tense without feeling punishing. The cold and the wolves come on a schedule you can read. Every permanent loss traces back to a decision you made.
One concrete example: the reinforced wall was worthless. However much HP I gave it, one wolf still broke it before dawn, so the upgrade only changed when it failed, never whether. And a wall that was going to break anyway costs nothing to burn, which quietly broke the one rule the whole game rests on.
Tuning the numbers did not fix it. Letting survivors repair walls during the night did. Durability only means something if the damage can be undone, and that one verb turned the wall from a countdown into something worth protecting, and therefore worth losing.
Adding crafting, rescue parts, and escalating nights risked diluting the core. Every new system had to give one more meaningful thing to burn, not a separate game to manage.
Accomplishments that we're proud of
A premise that fits in one line, backed by one mechanic that ties resources to emotion.
Everything you can pick up becomes the same thing when it burns: heat. One light source, one rule governing every object. That restraint produced deeper decisions than more systems would have. The rule takes one sentence to learn and a whole run to feel.
What we learned
- 🎯 Start from a question, not a feature list. "What can you stand to lose?" kept the scope honest.
- 🧱 One strong rule can carry a whole game.
- ✂️ Design by subtraction. Every new idea had to add one more thing to burn, or it got cut.
- 💡 Set the feeling first, then prove it with numbers. Deciding a night should feel desperate came first; a balance script checked whether it actually was.
- 🛠️ Prototype the core early. A rough playable loop taught me more in a day than more design notes could.
What's next for Embers
The next step is to deepen the choices each run demands and give creators a foundation they can remix:
- 🎨 Develop the intended visual style. Bring the concept art above into the game, preserving the fire's role as a signal of safety and the warm/cold shape language that makes the world readable.
- 🧩 Make the systems remixable. Package the burn rule, survivor roles, escalation and crafting as reusable systems. A sinking ship or a dying station could change the setting while keeping the dilemma intact.
- 🤝 Explore co-op for up to eight players. Each player controls one survivor around a shared fire. During the Dark Hour, the group votes on what to sacrifice, including keepsakes whose loss removes a survivor and their ability.
- 🗺️ Expand the world beyond camp. Add hazards and discoveries beyond the near wood and far ruins, giving players more reasons to risk leaving the fire.
Single-player stays the heart. Everything else exists to let more people feel the burn together.
Log in or sign up for Devpost to join the conversation.