I wanted to answer a question we get from clients constantly: “What can this AI stuff actually build — not in a demo, but for real?”
So instead of another slide deck, I built a game.
It’s called Emberfall: a turn-based dungeon crawler where you create a hero, take contracts from a town, explore randomized maze-like dungeons room by room, fight monsters, collect loot and elemental essences, climb through rank tiers, and ultimately face a Red Dragon. It runs in a single HTML file — no install, no server, no app store, no ads — and you can play it on your phone.
Here’s the part that matters: I didn’t write a single line of code by hand. I built the whole thing by describing what I wanted to an AI assistant from my phone, testing from my phone, and making every revision from my phone. By the end it had grown to version 2.1 and just over 1,300 lines of code in one file.
This article is “how I did it” — the actual prompts, why they worked, what came out, where we hit snags, and roughly how long it took. Let’s get started.
The setup
There was almost no setup, which is part of the point.
- One file. The entire game is a single
emberfall.html— just HTML, CSS, and vanilla JavaScript in one document. No frameworks, no build step, no dependencies to manage. - No environment. I never opened a code editor. I described what I wanted, the AI produced the game file, and I downloaded it to my phone to test and play in my browser.
- It saves itself. The game uses the browser’s built-in storage, so progress survives a refresh — which mattered a lot for playtesting.
- The tool. I used a paid personal AI plan; you could likely do this on a cheaper tier.
The reason this matters for a business audience: there was no infrastructure to stand up and no specialized tooling. The “interface” was a conversation.
The method that actually worked
If there’s one takeaway for anyone wanting to try this, it’s the loop:
- Get a playable core first. Don’t try to specify the whole game up front. Get something you can run, then react to it.
- Play it, then ask for one change. Almost every good prompt I wrote came from actually playing and noticing something — too easy, too grindy, a confusing screen, a bug, a missing feature.
- Be specific, and bring real numbers. “It’s too hard” is weak. “I need 2,003 XP and the two bounties only give 1,050” is a prompt the AI can act on precisely.
- One thing at a time. Bundling ten requests gets you ten half-done things. Small, focused asks got clean, tested results.
That’s it. The rest of this article is that loop in action.
The prompts — and why they worked
These are real prompts from the actual build, lightly trimmed. After each, a note on why it landed.
Tuning the difficulty by reporting what I saw
“It’s too easy to level up to a new rank, I got to diamond after a couple of missions. Leveling up should be slower/harder.”
Why it worked: It described an observed problem (“I got to diamond after a couple of missions”) rather than a vague preference. The AI could translate that directly into concrete changes — steepening the experience curve and spreading the rank thresholds further apart.
It took a couple of rounds to get right. After the first pass:
“Overall, I love it. It’s still too easy to level up. Need to make it a bit tougher or slower.”
Why it worked: Honest, iterative feedback. We weren’t trying to nail it in one shot — we were converging. A few rounds later: “Difficulty is much better.”
Designing a rule, not just a value
“Each level after — silver, gold, diamond — should be twice as difficult as the previous. I think monsters should also be 25% more difficult than the previous level. It’s not a sewer rat but a mutant rat… etc.”
Why it worked: This gave a rule the AI could implement systematically — each rank costs 2× the prior one, each dungeon tier scales monster stats by 25%. The “mutant rat” aside captured the flavor we wanted, so the AI renamed escalating monsters (“Feral,” “Mutant,” “Dire,” “Abyssal”) instead of just silently bumping numbers.
Adding whole systems
“What about to sell stuff, potions, weapons and armor?”
“We have the ability to upgrade weapons but not armor?”
Why they worked: I pointed at a gap — an asymmetry I noticed. “We can do X but not the obvious matching Y” is one of the most effective prompts you can write, because the AI can mirror an existing pattern instead of inventing one.
The big one: a randomized, explorable dungeon
This is the prompt I’m proudest of, because it shows you can ask for an ambitious feature in plain English:
“What if we pick up some contracts and while we are playing, we walk through a randomized 2d dungeon map. Of course we do not know the map until it’s completed… we enter a room and maybe there is nothing, but into another and there is the monster(s)?”
Why it worked: It described the experience — explore room by room, fog of war, you don’t know what’s behind the next door — rather than dictating implementation. The AI turned that into a generated maze with connected rooms hidden until visited, with empty rooms, monster rooms, treasure, and an exit you have to find.
We refined it the same way we built it — by playing:
“I would like to be able to fully explore the dungeon before exiting.”
“While you are walking around an empty room, you should be able to heal.”
“What about healing powers?”
Why they worked: Each came from a real moment of play. “I found the exit but wanted to keep exploring” → the exit became optional until you choose it. “I’m hurt between fights with no way to recover” → potions, then healing spells, became usable on the map.
Catching bugs just by playing
You don’t need to read code to report a bug well. You just describe what you saw:
“I am at the dragon, and gold rank. Since there are no more contracts, I cannot move up rank?”
Why it worked: This caught a genuine progression dead-end — the endgame had switched off the only remaining source of experience. The fix was real game-design work, prompted by one observant sentence.
“Not enough, the two new missions are 1,050 XP and I need 2,003 XP.”
Why it worked: Exact numbers. This turned a fuzzy “still feels stuck” into a precise rebalancing target. The reward math got rescaled so bounties actually move you toward the next level.
“In the upper right corner there is a broken symbol, what’s that?”
Why it worked: It quoted the exact broken text on screen — instantly diagnosable as a malformed emoji. The speaker/mute icon had been written as a raw escape code instead of the character. One-line fix, found because I noticed something looked wrong.
“When playing and using powers, can’t scroll down to choose the last ones.”
Why it worked: Clear symptom, clear context. The combat screen had been locked to keep the action buttons in place, which accidentally trapped long menus. The lock now releases when a menu is open.
The “make it feel finished” asks
“Can we add some audio? And a version history.”
“Can you add a PWA install option?”
“We need to add a difficulty setting. Easy, normal, hard.”
Why they worked: Short, unambiguous, and self-contained. “Add audio” produced procedurally generated sound effects (no audio files needed). “PWA install” made it installable to a phone. “Easy, normal, hard” produced three difficulty tiers that scale enemy toughness and experience rate. None needed a paragraph of explanation — the feature names carried clear intent.
From “easy, normal, hard” — three balanced tiers, each adjusting enemy health, enemy damage, and your experience rate:
- 🛡️ Easy — enemies ~25% less health, hit ~30% softer, +15% experience.
- ⚔️ Normal — the balanced baseline.
- 💀 Hard — enemies ~35% tougher, hit ~40% harder, −10% experience.
From “each rank twice as hard” — the experience required per rank now doubles cleanly: roughly 560 to reach Bronze, ~1,120 more for Silver, ~2,240 for Gold, ~4,480 for Diamond.
From “add a version history” — an in-game changelog the game maintains for itself, tracking the journey all the way to v2.1: the explorable map, field healing, the install option, the difficulty setting, and every bug fix in between.
How long did this actually take?
Honestly? Less than most people would guess — and the time was spent in a surprising place. I started this from my phone while out to eat with my wife.
My estimate from the first prompt to version 2.1 is roughly 5 to 7 hours of hands-on time, comfortably spread across a few days, mostly playtesting. A rough breakdown:
| Phase | Approx. time |
|---|---|
| Playable core (hero creation, combat, first dungeon, look-and-feel) | ~1–1.5 hrs |
| Combat depth (group fights, damage types, abilities, elemental essences) | ~1 hr |
| Economy + save system + selling/upgrading gear | ~1 hr |
| Balance tuning (several passes) | ~45 min |
| The explorable dungeon map | ~45 min |
| Field healing, auto-loot, devouring beasts, armor upgrades | ~30 min |
| Audio, version history, install support, difficulty setting | ~30 min |
| Bug fixes caught during play | ~30 min |
Here’s the part worth underlining: I didn’t write any code at all. The biggest single chunk of time was playing the game — noticing what felt off, deciding what to change next, and confirming the change worked. The AI handled the implementation in seconds to a minute or two per request; the human work was design judgment and quality control.
That’s the real lesson for any business looking at AI seriously: the bottleneck stops being “can we build it” and becomes “do we know what we want.” Taste, judgment, and clear communication become the valuable skills.
Want to try this yourself?
You don’t need to be a developer. Here’s the short version of what worked for us:
- Start with the end goal. Describe your complete idea. Don’t worry about getting it perfect — you’ll adjust as you build.
- Ask for a small, usable version first. Get something running, then react to it and build from there.
- Use it like a real user would, and report what you notice. Most of my best prompts were just honest observations.
- Be specific. Bring numbers. “Slower” is weaker than “this should take about twice as long.”
- Describe the experience, not the code. “I shouldn’t know what’s behind the door until I open it” got us a fog-of-war dungeon. You don’t need the technical terms.
- Change one thing at a time, and keep playing between changes.
The same loop that built a game builds internal tools, customer-facing calculators, data dashboards, and the kind of small, specific software that used to sit in a backlog forever because it was never quite worth a developer’s time. That’s the shift.
If you want the deeper version of this for real business software, see building apps with AI. And if you’d rather start smaller, here’s how I built a card game with AI the same way.
Where Braintek fits
This is exactly the kind of capability we help our clients put to work — not as a novelty, but as a practical way to close the gap between “we have an idea” and “we have a working thing.” If you’re looking to get more out of the software you already own, link systems together, or eliminate manual data entry, we can help you implement AI automation in your business.
This little dragon game is real software I built through conversation, sitting at a bar. Think of what else we could build together for your business. Book a discovery call and let’s talk it through.
▶ Play Emberfall Download the game (HTML)
Give it a play — it’s fun. You can even download it and keep it on your phone forever.