I Prompted My Way to a Published Game in 2 Weeks

I've never built a game. I've played plenty — hundreds of hours sunk into tower defense games alone — but I've never written a game loop, never touched canvas rendering, never dealt with pathfinding or wave spawning or projectile physics. Not once.

Two weeks ago I opened VS Code, started a conversation with Claude, and described the game I wanted to build. Fourteen days later, Siegebox is live. It has 46 towers, 4 biomes, a full level builder, community map sharing, competitive multiplayer for up to 4 players, 101 achievements, a tutorial, and an in-game encyclopedia. I spent maybe 20 hours total. Most of that time was spent playing the game.

What is Siegebox?

Siegebox is a browser-based isometric tower defense game with a built-in level editor and a community platform for sharing maps. Think classic tower defense — enemies march down a path, you build towers to stop them — but with a sandbox layer on top that lets anyone create, publish, and play each other's maps.

The core gameplay loop is tight: 40 waves of enemies, 5 difficulty tiers, bosses every 5th wave, and a scoring system that rewards efficiency. But the real hook is what happens around that loop.

The sandbox

Anyone can open the map editor and build a level from scratch. Paint terrain, lay roads, place water and decorations, set start and end gates, pick a biome, and publish. Your map goes live on the community browser where anyone can play it, compete for the top score, and build campaigns around it.

Maps have versioning — if you update a published map, old versions stay playable and keep their leaderboards. Players can browse community maps by newest, most played, difficulty, or tags. The builder has undo/redo, drag-painting, auto-tiling for roads and water, and generates thumbnails automatically.

This is the part of the game I care about most. The tower defense mechanics are fun, but the community layer is what gives the game legs. Every map someone publishes is new content that everyone else gets to play. I don't have to design levels — the players do.

The towers

There are 46 towers organized into 6 elemental trees plus a support branch and a capstone. You don't start with all of them — you unlock new towers during a match by spending soul gems in a passive upgrade tree. Every run is a set of decisions about which branches to invest in.

A few highlights:

• Fire tree — splash damage, burn DoTs, a meteor tower that drops delayed massive AoE, a furnace that radiates heat to everything nearby
• Ice tree — all about slowing and freezing. A glacier tower that hard-freezes single targets, a blizzard tower that drops ice shards over an area
• Lightning tree — high variance and utility. A chain tower that bounces between enemies, a rail tower that pierces in a line, a rainbow tower that adapts to each enemy's weakness
• Earth tree — control. An oil tower that slows road tiles, barracks that stun with shockwaves, a void tower that buffs every tower around it
• Shadow tree — a poison tower that marks enemies to take bonus damage from all sources, a hex tower where cursed enemies explode on death, a phantom tower that teleports enemies backward on the path
• Support — a life tower that restores lives on kills, a gold tower for bonus gold, a shrine that generates soul gems passively

The capstone — the Plasma Tower — requires mastering two full elemental trees before it unlocks. Its beam ramps up damage the longer it fires and chains to nearby enemies. It's the reward for going deep.

The enemies

Enemies come in three classes (knight, pikeman, scout) plus an assassin class that's invisible to most towers. They scale across five elements with resistances, and four roles that appear in later waves — healers that restore nearby enemies, shielders that reduce damage in a radius, splitters that break into smaller enemies at low health, and commanders that speed up everything around them.

By wave 30, you're dealing with shielded fire-resistant commanders surrounded by healers, and your tower placement decisions from wave 5 are either paying off or falling apart.

Biomes

Maps can be set to one of four biomes — grasslands, desert, snow, or hell — each with gameplay modifiers. Desert boosts fire towers but weakens slows. Snow does the opposite. Hell gives a raw damage boost to everything but slashes gold income. The biome system means the same map layout can play very differently depending on the environment.

Multiplayer

This one still makes me laugh. I added multiplayer as an afterthought. Literally a single prompt while I was in the shower — I described the competitive mode I wanted, came back, and it was built.

The mode is competitive: up to 4 players each play the same map simultaneously. When you kill enemies, a portion of them get sent to your opponents as bonus waves. You can spend gold to fortify, which halves the HP of enemies sent your way. Last player standing wins. It's chaotic and fun in a way I didn't expect from a tower defense game.

The implementation is client-authoritative — each player runs their own game, and the server relays events between them via Socket.io. It's not cheat-proof, but it works well for casual play, and the architecture was designed for that tradeoff.

Everything else

• 101 achievements across categories like combat, economy, progression, streaks, and builder. Secret achievements for playing at 3am or beating a map without upgrading.
• A full tutorial — 13-step guided walkthrough on a purpose-built Tutorial Island map.
• The Siege Codex — an in-game encyclopedia covering every tower, enemy type, biome, difficulty tier, and the full changelog.
• Campaigns — players can group maps into ordered campaigns with their own leaderboards.
• Profiles — stats tracking across games, maps played, total kills, win streaks.
• 5 difficulty tiers — from Beginner (no wave timer, no assassins) to Brutal (tight timers, no starting resources, 2x score multiplier for the brave).

How I built it

The entire game was built using GitHub Copilot with Claude. I worked in VS Code, describing features in natural language, reviewing what Claude generated, playing the result, and then describing what to change. That was the loop. Prompt, play, adjust.

I started with an architecture prompt — describing the game I wanted, the tech stack (Vite, vanilla JS, Canvas 2D, Express, SQLite), and the core requirements. Claude produced a full architecture document: folder structure, module breakdown, REST API design, database schema, map format, and a milestone plan. That document became the blueprint for everything that followed.

From there it was just... building. Each prompt session would add a feature or fix something that didn't feel right. The map renderer. The pathfinding. The tower placement system. The wave spawner. The builder. The UI. Each piece went in over the course of a night or two.

The tech stack is intentionally simple. No React, no TypeScript, no game engine. Just vanilla JavaScript modules, a canvas, and an Express server with SQLite. When the stack is simple, the AI has less to get confused about. There are fewer abstractions to misunderstand, fewer framework opinions to clash with.

What surprised me

The game loop and rendering. I expected canvas rendering and isometric math to be the hard part. It wasn't. Claude handled the coordinate transforms, the draw ordering, the camera system, the sprite loading — all of it came out working on the first or second pass. Isometric tile picking, screen-to-world projection, z-sorting — things I would have spent days learning — just appeared.

Multiplayer. I cannot stress enough how absurd this was. I described a competitive mode where players send killed enemies to each other, came back from the shower, and had a working Socket.io implementation with room management, event relaying, and a lobby UI. It needed tuning, but the bones were solid from one prompt.

The scope. 46 towers with unique mechanics, 4 biomes with gameplay effects, a passive upgrade tree with 68 nodes, 101 achievements — this is a lot of game. And at no point did I hit a wall where Claude couldn't understand what I was asking for or how it should integrate with the existing code. The conversations were iterative and building on context every time.

What was hard

Balance. AI can build systems, but it can't tell you whether a tower costs too much gold or whether wave 25 is too easy. That was all playtesting — nights spent playing my own game, tweaking numbers, and prompting adjustments. The Plasma Tower got nerfed three times before it stopped being absurdly broken.

Visual feel. Getting the isometric sprites to look right, the UI to feel cohesive, the pixel art aesthetic to work at different zoom levels — that required human eyes and opinions. Claude could generate CSS and layout code instantly, but "this doesn't look right" is a feedback loop that only a person can close.

Fighting the urge to add more. When each feature is a prompt away, scope creep is real. "What if there was a tower that teleported enemies backward?" Sure, done. "What about one that makes enemies explode on death?" Done. At some point I had to stop adding towers and start playing the game.

The numbers

The tech stack:

• ~15,000 lines of JavaScript (client + server)
• 46 tower types across 7 categories
• 101 achievements
• 4 biomes with gameplay modifiers
• 5 difficulty tiers
• 40 waves per map
• 68 passive upgrade nodes
• 13-step tutorial
• Competitive multiplayer for up to 4 players
• Full REST API with rate limiting, auth, map versioning, leaderboards, campaigns, profiles

Built in roughly 20 hours across 2 weeks. No game development experience. One AI tool. Zero regrets.

What I learned

You don't need to know how to build a game to build a game. You need to know what the game should feel like. Every decision I made was a design decision, not a technical one. "Enemies should feel overwhelming by wave 30." "The upgrade tree should force meaningful choices." "Selling a tower should hurt." The AI turned those feelings into code.

Simple stacks are an AI multiplier. Vanilla JS, Canvas 2D, Express, SQLite. No framework magic, no build complexity, no type system to argue with. The AI was faster and more accurate because there was less between the intent and the implementation.

Playtesting is the real work. Building features is fast now. Knowing whether they're good requires playing the game. Repeatedly. The hardest part of the last two weeks wasn't prompting — it was sitting in wave 35 on Brutal difficulty, realizing the ice tree was pointless, and figuring out how to describe the fix.

Multiplayer is more accessible than you think. I was intimidated by the idea of real-time multiplayer. Socket.io, room management, state syncing — it sounded like a wall. It wasn't. The client-authoritative approach is a pragmatic compromise that works perfectly for this kind of game, and the AI knew exactly how to structure it.

Ship the game. It's live. People can play it. Maps are being built. That matters more than whether the codebase would survive a code review. The tools have changed what's possible for a solo builder, and the gap between "I have a game idea" and "here's the link" has never been smaller.

What's next

More maps. More players. Balance passes. Maybe a co-op mode where players build towers on the same map together. Maybe mobile support. But mostly — I'll keep prompting, keep playing, and keep shipping.

If you want to play, it's free: siegebox.com.