DEV Community: Tony Costanzo

I Spent 22 Years Programming Just to Fail at Making a Skeleton Swing a Sword

Tony Costanzo — Fri, 29 Aug 2025 15:43:11 +0000

Originally published at techhivelabs.net

Why I'm Building an MMORPG (By Learning How NOT to Build One First)

Every Game Developer Tells Us The Same Thing...

"Don't build an MMO."

It's literally the first rule of indie game devs. Right up there with "start small" and "your first 10 games will suck." And you know what? After 22 years of programming and two months of trying to build one, can confirm: they're absolutely right.

The thing is.. I'm still going to build my MMORPG. I'm just taking a massive detour through a completely different game first. Let me explain why building my dream game meant stepping the hell away from it.

From RuneScape Private Servers to Full-Stack Development

My programming journey started when I was 11, doing what any reasonable (totally not degenerate) pre-teen would do in 2004: hacking together RuneScape private servers so I could spawn max cash stacks and party hats. Those early days of tearing apart poorly-written Java codebases by other degenerates taught me one thing exceptionally well: how to duct-tape other people's code together until it (mostly) worked.

Over the years, I graduated from game server shenanigans to real backend development. I built RESTful APIs, managed millions of rows of data for EPC contractors, and became what I'd call a "real programmer." Java, Kotlin, Python, TypeScript, PostgreSQL, microservices.. you name it, I could architect it.

But deep down? I never stopped scoping out game ideas in markdown files. Mountains of them.

Enter Thundoria: My Beautiful, Overscoped Monster

Earlier this year, I finally said "screw it" and started building Thundoria, a browser-based multiplayer roguelike bullet-hell with:

Procedurally generated dungeons
Real-time multiplayer combat
RPG progression systems (because why not?)
Crafting, fishing, mining (who doesn't love scope creep)
Social features like guilds and parties
And yes... it's an MMO

[Want to watch this trainwreck unfold? Join the mailing list at thundoria.com!]

The Technical Flex That Nobody Asked For

In two months of near-daily work, I built some fairly impressive infra:

NuxtJS Frontend:

Supabase auth with JWT passthrough to the game client
Embedded game frame with seamless auth

Kotlin Service Layer:

RESTful API for game server orchestration
Dynamic instance balancing
Procedural map generation
HTTP map data serving to both client and server

Nakama Game Server (Go):

Multi-character system per account
Server-authoritative collision detection using map data from Kotlin
Real-time multiplayer synchronization
Full inventory and stats persistence

Godot Client:

Fully integrated with the entire stack
Complete UI with MMO-style panels
Character creation with class selection
Multiple polished scenes

I was crushing it. Architecture? Check. Data flow? Nailed it. Scalability? Ready for millions of players that would definitely (never) come.

Here's some posts where I talked about progress:
// Detect dark theme var iframe = document.getElementById('tweet-1954976218299895986-830'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1954976218299895986&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1953539709730205787-385'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1953539709730205787&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1952172653894148553-928'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1952172653894148553&theme=dark" }

The Brutal Realization

Then I tried to implement combat.
And NPCs.
And enemy AI.
And suddenly, it hit me like a wave attack from a boss I needed to design: I had no idea how to actually design game systems.

Twenty-two years of programming experience, and I was paralyzed by questions like:

Should enemies attack on a timer or use complex behavior trees?
What percentage of loot should be rare vs common?
How do you make death punishing but not ragequit inducing?
Why does every design decision have 47 interdependent systems?

I knew HOW to make an enemy attack. I knew HOW to implement a loot table. Shit, I could build you a distributed loot service with Redis caching. But WHAT should that enemy's attack pattern teach the player? WHAT loot distribution keeps players engaged without breaking the economy?

I was an architect and never built a house.

The YouTube Immersion Therapy

When I started this journey a few months ago, my entire YouTube feed became game development content. I immersed myself in design philosophy while coding, listening to creators like:

Thomas Brush (indie success stories and reality checks)
Jonas Tyroller (the science of game feel)
Aarimous (roguelike design deep dives)
Jackie Codes (Godot-specific wisdom)
DevWorm (practical indie dev insights)

Not tutorials, mind you. Working with the Fireship YouTube channel has taught me that tutorial hell is real, and most developers just need concepts, not code-alongs, something he does a great job at. I needed to understand how game designers THINK, not how they type.

Everyone kept saying the same damn thing: "Start small. Build Pong. Make a platformer."

But telling a seasoned developer to make Pong is like telling Gordon Ramsay to make a ham sandwhich. Sure, I could do it, but what would I actually learn?

Dungeon Supply Co: My "Small" Game That's Actually Perfect

Instead of abandoning everything like so many times in the past, I started designing a new game specifically to teach me what I didn't know: Dungeon Supply Co.

The premise?
We've all crawled our fair share of dungeons, right? We grind and grind for gear, pots, and food for hours before finally attempting the dungeon. How the hell do the dungeon NPCs always have everything that they need??
You're enslaved by an asshole orc who forces you to run a factory that supplies dungeons with everything—swords for skeletons, potions for bosses, and yes, all those ceramic pots that heroes compulsively smash.

It's automation meets subtle dark humor and a bit of irony.

More importantly, it's designed to force me to learn:

State Management: Hundreds of items on conveyor belts without melting CPUs
Game Feel: Making automation satisfying (that sweet, sweet production line dopamine)
Art Pipeline: Expanding on Mwaayk's excellent 16x16 automation pack with my own sprites
Scope Control: 4-8 week timeline, not 4-8 years of development hell
Player Psychology: What makes "just one more production line" addictive

Why This Actually Works

Building an automation game teaches fundamental game development skills without the complexity of combat, multiplayer networking, or making sure your netcode doesn't let players phase through walls like interdimensional ghosts.

The technical challenges are real (managing thousands of moving items at 60 FPS), but bounded. The design space is constrained but meaningful. Most importantly, it's a game I'd actually want to play while procrastinating on building my actual dream game.

The Developer's Paradox: Failing Up

Here's what nobody tells you: As programmers, we're trained to build incrementally. We start with "Hello World," not "Let's rebuild Google from scratch." But the moment passion enters the equation, we immediately try to build our own GSuite replacement for enterprise customers.

My MMORPG isn't dead. In fact, working on Dungeon Supply Co. has made me MORE excited about Thundoria, not less. Every system I implement teaches me something I'll need. Every optimization technique, every player feedback loop, every scene implementation, it's all training for the main event.

The Real Lesson: Your Dream Game Needs Practice Games

If you're a developer sitting on your own "dream game" idea, here's my advice: Don't abandon it. Orbit it.

Build smaller games that teach you specific skills you'll need. Want to make an RPG? Build an inventory system game first. Dream of a shooter? Start with a wave defense game.
Think of it as building your own curriculum where every assignment directly contributes to your final project, except nobody's grading you and you can drink while doing it.

Join Me on This Beautiful Disaster

I'm documenting everything—the successes, failures, and the times I spent 6 hours debugging only to realize I spelled "strength" wrong. Thundoria is still happening, and I'm trying to build it in public because apparently I'm a masochist.

The game design is stupidly ambitious:

Roguelike extraction mechanics where you gamble progression like a degenerate
Bullet-hell combat that scales from "tutorial grandmother" to "what the fuck is happening"
"Just one more floor" addiction that ruins friendships
No pay-to-win BS, just honest "give me money for cosmetics" capitalism

Meanwhile, Dungeon Supply Co. is teaching me how to actually deliver on that vision without having a complete mental breakdown.

Want to watch this slow-motion catastrophe?

Sign up for development updates at thundoria.com
Watch me learn game dev fundamentals the hardest way possible
Get early access to both games (whenever the hell they're ready)

The Bottom Line

Every game developer is right: don't build an MMO as your first game. But also, don't let your dreams die in a folder called "maybe_someday_projects_final_v2_actual_final."
Instead, be strategic. Build towards your dream, not away from it. Learn in public. Fail spectacularly. And remember—even the creators of World of Warcraft probably started by spawning themselves max cash stacks in someone else's terrible code.

Although... how can I expect you to listen to me? I didn't listen, and honestly, I don't really expect anyone else to either. I'm just a guy with a dream and a tendency to overcomplicate things.

Now if you'll excuse me, I have some conveyor belts to optimize. These skeletons won't arm themselves, and my orc overlord is getting bitchy.

Links

Are you also building a game way above your skill level? Learning game development after years of "real" programming? Let's suffer together!
Follow the journey at thundoria.com and let's fail upward as a community.

I post about my progressions sometimes on Bluesky and X / Twitter as well.

I Let Amazon's AI Build My Game for 3 Days. Here's What Happened

Tony Costanzo — Tue, 17 Jun 2025 17:08:56 +0000

Originally published at techhivelabs.net

TL;DR: Built a working roguelike with Amazon Q in hours. It was amazing until it wasn't. Enemy projectiles broke me. AI coding is powerful but not ready to fly solo yet.

🎮 Try the Game | 💻 GitHub Repo

The Setup

When Amazon threw down the gauntlet with their AI coding challenge, I couldn't resist. The mission? Build a browser-based game using their new AI assistant, Q. As someone who's been curious about the current state of AI-powered development, this seemed like the perfect opportunity to push the boundaries and see just how far we could go with "vibe coding" - that magical state where you describe what you want and the AI makes it happen.

My weapon of choice? A fresh Nuxt.js project, my go-to framework for web development. I fired up Tabby and was pleasantly surprised to see Q integrate seamlessly with it - I'd half expected it to only work with the built-in terminal. While I noticed Q only offered Claude models (no complaints there, it's my LLM of choice anyway), I was ready to embark on this adventure.

First Contact: Setting Expectations

I started by spitballing a rough idea for a roguelike game:

The initial response was... well, exactly what you'd expect from an eager AI assistant - way too affirmative. I don't need a yes-man; I need honest feedback and alternative suggestions!

After some gentle encouragement (okay, I may have talked some shit to the LLM), I finally got the honest feedback I was looking for. Be careful what you wish for, though - the reality check was humbling!

Finding the Perfect Assets

Before diving deeper, I needed some visual assets. I stumbled upon an absolutely gorgeous asset pack on itch.io by Trevor Pupkin - affordable, high-quality, and perfect for the cyberpunk roguelike vibe I was going for. I dropped it in the root directory and asked Q for its honest opinion about our game design and timeline.

Okay check out the asset pack in q-roguelike/TechDungeonAssets I really like this and think we could build a simple roguelike.. We can just do projectile combat, no building.. we can have upgrades like speed, multi projectile (adds +1 at a slight angle each time), health, fire speed, exploding bullets, etc.. We can keep it simple enough I suppose. What do you think about game engine with this design? is it doable in our timeframe? again dont just reaffirm, give honest feedback

Q suggested we should just yeet a 2d canvas and start building on that. I was certainly hesitant about that considering all of the helpers libraries like Phaser or PixiJS gives us..

The First Attempt: A Comedy of Errors

The "actual" first attempt was... let's call it educational. The code was non-functioning, mixing Vue 2 Options API inside a Vue 3 Composition API script block. But hey, I was being intentionally vague with my requirements, so I can't blame Claude or Q entirely. One prompt later pointing out the issue, and we had our first error-free pass.

Well... it was something:

I'm still not entirely sure what I was looking at, but asking an LLM to parse multiple spritesheets and properly set up sprites with animations is admittedly a tall order.

Before diving into fixing the sprite issues, I noticed Q had done something quite thoughtful - it had taken all the assets I'd dumped in the root directory and organized them nicely in the public folder. Small wins!

The TexturePacker Breakthrough

Then I thought of a way to give more image context.. the TexturePacker app outputs JSON data alongside its spritesheets. If I gave each image and animation a descriptive name, Q should be able to parse and use them correctly... right?

RIGHT!

Suddenly, we had a working run animation and projectiles firing in the direction of my mouse! Sure, my character wasn't facing the right direction and the projectiles were angled incorrectly, but this was genuine progress. This was the point where I thought I'd need to take over completely, but I was curious to see how far Q could go.

Building the Core Game Loop

Instead of getting bogged down in perfectionism, I asked Q to outline the next steps:

Q provided a solid roadmap:

## Priority Order:

1. Collision & Combat System
• Projectile-enemy collision detection
• Enemy health and death
• Basic enemy AI (move toward player)

2. Wave System
• Spawn enemies in waves
• Wave progression with increasing difficulty
• Wave completion detection

3. Roguelike Upgrades
• Upgrade selection screen between waves
• Core upgrades: damage, fire rate, health, speed, multi-shot
• Persistent upgrade effects

4. Game State Management
• Health system for player
• Game over/restart
• Score tracking

Implementing Combat

Starting with collision and combat systems, I prompted: Okay let's go in order! We can go ahead and implement the projectile hits, enemies chasing, health system, and death animations!

The first attempt introduced some bugs - I couldn't shoot and spawned with 0 HP. By the time I died, my health was between -5 and -10. Classic game development!

One clarifying prompt later: I'm ready to move on but we do have some issues. I'm not able to shoot but I think it may be because I spawn with 0hp and by the time I die, my hp is -5 - -10.. I think we need some delay between death and restarting so that the death animation can play as well. Finally I see a lot of warnings in the console from the animation manager stating that our animation keys already exist.. Are we reinitializing these unnecessarily?

And just like that, we had a functioning combat system! Complete with health management, incremental damage, immunity periods, and even a score system:

Code Quality Check

At this point, I hadn't really examined the code beyond fixing that initial Vue 2/3 issue. I was expecting a thousand lines of spaghetti. To my surprise, we had only ~450 lines of surprisingly clean code. All in a single component (not ideal, but workable), including ~20 lines of CSS and 10 lines of templating. The JavaScript was well-structured, without duplicated logic, and documented concisely - not in that typical verbose AI fashion. Color me impressed!

The Wave System

Next up: the wave system. One prompt. Just one prompt, and boom:

I was genuinely impressed at this point. We had a working wave system with progressive difficulty in a single iteration.

Hitting the Wall: Context Limits and Collision Detection

The next challenge - implementing the upgrade system and tilemap collision - is where things got rocky. Q struggled. Hard. My codebase ballooned from ~500 lines to about 1,000 lines. Despite having all the tilemap data in JSON format, Q couldn't get the collision layers working properly.

It loaded the map and registered all the layers correctly, but when it came to setting up collision detection, we went in circles. Q eventually decided that Phaser's built-in collision system was broken (spoiler: it wasn't) and attempted to write its own per-tile collision system. Yikes.

I tried to guide it back to using Phaser's built-in features, but we'd hit the classic AI coding limitation: context window exhaustion. Under 1,000 lines of code and we were already having fundamental issues. Q started creating basic TypeScript errors that prevented the page from running entirely.

Recognizing the signs, I asked Q to strip out all the collision work so I could handle it myself. I created a git commit (should have done this earlier!) and prompted Q to create documentation to maintain high-level context.

Taking Back Control

I performed a major refactor, splitting the monolithic component into separate TypeScript files and Phaser scenes. With the help of Ourcade TV's excellent YouTube tutorials, I implemented proper collision detection myself.

This created a new problem: the basic straight-line enemy AI couldn't navigate around walls. Time to see how Q handled pathfinding:

Well... the enemies were certainly moving, just not in any useful direction. When I clarified that I needed proper pathfinding, Q implemented A* pathfinding with heuristic functions for 8-directional movement. The first attempt was too precise, causing enemies to overshoot waypoints and backtrack:

But third time's the charm! In just three prompts, Q had implemented fairly sophisticated pathfinding:

Pushing Forward and Finding the Limits

At this point, we'd essentially completed the original goal, but I was feeling inspired. I've had this concept for a browser-based MMO/roguelike hybrid brewing for a while, and this seemed like the perfect opportunity to explore it further.

I took more control from here, using Q as a coding assistant rather than the primary developer. We added more enemy types, complex wave patterns, tiered upgrades, and other roguelike elements. But the final straw? Enemy projectiles.

Getting enemy projectiles to move correctly, deal damage, and not freeze the entire game took over 10 prompts. I never successfully got Q to implement this feature without game-breaking bugs.

The Verdict: Impressive but Not Ready for Prime Time

Let me be clear: I was genuinely impressed with how quickly Q created a functioning game that felt like a real project worth iterating on. The initial results had me excited about the possibilities of AI-assisted development.

But here's the bottom line: I ended up with a pile of unfamiliar, difficult-to-maintain code with a clunky development pattern that I didn't want to continue building on.

As a reasonably experienced developer, I had to guide Q toward correct solutions fairly early in the process. I'm not confident that less experienced developers would be able to provide the same guidance when things go sideways.

This isn't really a criticism of Q specifically - it's more about the current state of AI coding assistants in general. Language models will undoubtedly improve, but will we ever be able to go completely hands-free on larger projects? I doubt it. Context windows need to expand dramatically, and tools like Q need more sophisticated agentic processes to prevent the accumulation of "AI slop."

Final Thoughts

I'm glad Amazon put this challenge out there. It gave me a valuable opportunity to assess the current state of AI coding assistants in a real-world scenario. The technology is impressive and shows tremendous promise, but for now, I'll stick with using LLMs through web interfaces and copilot-style IDE extensions for specific tasks rather than full project development.

I'm not quite ready to hand over the reins completely - but I'm excited to see where this technology goes. The future of AI-assisted development is bright, even if we're not quite there yet. Who knows? Maybe in a year or two, I'll be writing a follow-up post about how I built an entire MMO using just voice commands and interpretive dance.

Until then, happy coding - whether you're doing it with AI assistance or good old-fashioned keyboard mashing!