The Last Ember

• 

Inspiration

I kept seeing mobile survival-game ads built around the same fantasy: a tiny fire against the cold, survivors gathered around its light, and every log feeling like the difference between life and death.

But when you actually play many of those games, that experience disappears behind menus, timers, upgrades, and claim buttons.

I wanted to make the game those ads made me want to play.

That led to the question that became the foundation of Last Ember: what if the fire's light radius wasn't just another meter? What if it was the actual playable map?

The fire doesn't simply represent your remaining resources. Its light is your territory, your safety, and the only part of the world you can reach. Feed it and the playable space expands. Neglect it and the darkness closes in around you.

What it does

Last Ember is a five-minute, one-handed survival and resource-management game where every log forces a choice.

A bonfire casts the only light, and its light is the only safe ground. The world has color, life, and reach only where the firelight touches it.

Wood is your only resource, but it has three competing uses:

• Burn it to keep the fire alive, expand the map, and reach more trees.
• Stack it on the rescue signal. Collect 75 logs there and your survivors are rescued.
• Invest it in upgrades for that run, including an axe, warm coats, and a windbreak.

You can never comfortably do all three. Every log moved toward rescue is one less log keeping everyone warm. Every log burned to survive keeps the signal unfinished. Every investment that may protect you later makes the present moment more dangerous.

As the night continues, the storm drains the fire faster. Reaching new rescue-signal milestones makes the storm even more aggressive, which means progressing toward victory creates its own difficulty. The closer you get to being rescued, the harder the game pushes back.

Named survivors gather the wood, but you decide where they go and how much danger they face. If someone is caught outside the light, they begin to freeze. Their name appears with a filling alarm ring, and you have to make a real decision: burn precious logs to extend the firelight and save them, or protect your remaining resources and let the darkness take them permanently.

A complete run takes about five minutes. Each run is graded based on rescue speed, and your best times persist between runs. Every successful rescue permanently deepens the storm by increasing its drain rate by 7%. After the first victory, the question changes from "Can I win?" to "How deep into the storm can I go?"

How we built it

Last Ember was built through an AI-directed development process across more than 50 documented sessions.

I started with a blank page and a group of possible concepts, then ran them through a tournament-style evaluation against the brief: a five-minute, phone-first prototype built around one loop worth repeating. Last Ember won because its central mechanic was easy to understand, visually distinctive, designed specifically for mobile play, and capable of creating meaningful decisions with a single tap.

AI generated the game's implementation through prompting, but my role went far beyond asking it to "make a game." I designed the concept, directed the systems and visual identity, evaluated every result, organized outside playtests, identified what was failing, and decided how each problem should be solved.

The most important part of the process wasn't code generation. It was the loop between real players and targeted revisions. Outside playtesters completed dozens of runs on their own phones. Every point of confusion or frustration became a documented development session: identify the problem, design a focused solution, implement it, test it, and add automated coverage where possible so that fixing one system didn't quietly break another.

The visual redesign followed the same process. I developed it separately on an experimental fork, revised it through multiple rounds of outside art feedback, and only merged it into the final submission after confirming that every game state remained immediately readable. The exact submission build was then regression-tested across eight environments, including the official judging runtime.

Challenges we ran into

Making crafts genuinely attainable. The original crafting system required players to pay the full cost of an upgrade at once. It looked reasonable on paper, but simulation showed that some upgrades were mathematically unreachable — even with optimal play. Instead of simply lowering the prices, I redesigned crafting as an incremental investment. Players can now contribute one log at a time using the same interaction they already understand from building the rescue signal. This made crafting achievable without removing the tension: a partially completed upgrade still represents resources that are no longer keeping the fire alive.

Making fire sound like fire. The game's synthesized fire sounds repeatedly turned musical. Resonant filters created noticeable tones, regular intervals created rhythms, and several attempts sounded more like popcorn than a burning bonfire. The final result uses a pre-rendered 29-second DSP fire bed combined with randomized runtime crackles. It took five focused audio sessions to make the fire feel natural without becoming repetitive or distracting.

Teaching the game without stopping it. I didn't want Last Ember to begin with a wall of text or a traditional tutorial. The game needed to teach players while they were already playing. The onboarding now uses small pieces of guidance that disappear permanently once they are no longer needed: pulsing interactive elements, a one-time three-beat introduction after the first wood delivery, a tapping hand on the crafting cards, and a changing objective line that always answers the question, "What should I do now?" The game helps when help is needed and gets out of the way once the player understands.

Making sure the game never lies. Some of the most important problems weren't mechanical — they were trust problems. Playtesters found end-screen messages that claimed "3 of 3 made it" after a failed rescue, or praised a run because "nobody even shivered" when someone had nearly frozen. Those messages may have seemed small, but they made the game feel dishonest. I rebuilt the end-screen logic so it only celebrates things the player's actual run proves.

Accomplishments that we're proud of

My favorite result came from a first-time player who described herself as a non-gamer. After playing six runs without being prompted, she texted: "I'll bloody well keep playing it until I figure out how to win it." She then won twice and reached Storm Level 2.

That sentence meant more to me than a perfect test result because it confirmed the experience I was trying to create: a game that is immediately understandable, difficult for reasons that feel fair, and compelling enough to make someone genuinely want another attempt.

I'm also proud of the final build itself. The game is one readable file plus a single audio data file, with zero external libraries and zero network requests. It was verified across eight environments, and its 50-plus-session build log documents the complete process — from the original idea to the exact submission package.

What we learned

I learned that one global difficulty curve cannot serve both new and experienced players equally well. Last Ember solves that by connecting difficulty to the player's own progress: as the rescue signal grows, the storm grows stronger. Skilled players advance faster and trigger greater pressure sooner, while newer players encounter that pressure more gradually. The climax adjusts itself to the person playing.

I also learned that one of the simplest engagement tools is still one of the strongest: give players a number they believe they can beat.

Most importantly, I learned that atmosphere is only valuable when it preserves clarity. A visual effect may be beautiful on its own, but if it makes the fire radius, survivor danger, or available choices harder to understand, it is not an upgrade. It is a readability problem wearing nicer clothes.

What's next for Last Ember

I see this prototype as the first night of a much larger journey.

The full version would follow a persistent camp of named survivors travelling north through increasingly dangerous winters. Each location would introduce a new phase: settling temporarily, gathering what the land can provide, surviving the night, and eventually carrying the last living ember between fires. Survivors would carry their skills, relationships, injuries, and scars forward. Saving someone — or choosing not to — would affect more than a single five-minute run.

Future nights could expand the weather, crafting, survivor roles, environments, and resource decisions while keeping the same central rule at the heart of the game: the light is the map, the fire is always dying, and survival means deciding what you are willing to sacrifice to keep it alive.

Built With

• claude