Building a wave-survival roguelike from the ground up

From an idea to a playable game

Creating a game as a solo developer means being involved in almost every part of the process, from the first spark of inspiration to the final build uploaded to Steam. For me, heading TheSkullCreativity, that means designing gameplay systems, writing thousands of lines of C# code, creating and implementing isometric art, testing mechanics, fixing game-breaking bugs, balancing gameplay, and constantly asking one question: is the game actually fun to play?

Skeletor is my flagship project — an isometric wave-survival roguelike built around fast-paced combat, reactive enemy AI, deep progression, and replayability. What you see in the finished game is only a small part of the process. Behind every enemy, every sword swing, every animation, and every wave are dozens of prototypes, experiments, failures, and small improvements that stack up into a cohesive experience.

Designing the gameplay loop

At its foundation, Skeletor is built around a simple loop: fight, survive, upgrade, face stronger enemies, repeat. The simplicity is intentional — the real challenge in game design is creating enough depth inside that loop to make every run feel fresh. Too complex, and players get bogged down in menus. Too shallow, and they get bored after twenty minutes.

To get that depth, enemies need to behave differently depending on the situation, combat needs to feel responsive, and progression needs to create meaningful choices. Most importantly, the systems need to interact in ways that produce situations even I can't fully predict. That systems-driven approach is at the heart of how I design Skeletor — everything is built to interlock, creating emergent moments that make every wave its own puzzle of positioning and target priority.

Building combat: starting with the basics

Before worrying about roguelike mechanics, elemental synergies, or screen-clearing ultimates, I always start with the fundamentals: can the player move? Can they attack? Can attacks hit enemies? Can enemies take damage? Can the player intuitively tell when an attack connects? These questions sound simple, but they're the foundation of the whole combat system — if movement feels sluggish or attacks feel weightless in a grey-box prototype, no amount of visual effects will save the final game.

In my development process, I build systems in small, modular pieces rather than one giant script that does everything. Anyone who's worked on a Unity project for long enough knows spaghetti code is the quickest way to kill it — so I strictly decouple logic: movement handles movement, combat handles attacks, health handles damage, AI handles enemy behavior, animation communicates actions, effects communicate impact. Keeping those responsibilities separated with event-driven architecture makes it far easier to experiment, iterate, and scale without breaking existing features.

Designing enemy AI

An enemy doesn't need a complicated, neural-network-driven AI system to be interesting — it just needs to behave in a way the player can quickly read and react to. For Skeletor, I approach enemy behavior through a custom Finite State Machine (FSM) written in C#. An enemy might start searching for the player, enter a "Chase" state when they get close, move into attack range, transition to "Attack," enter a brief "Recover" state, and repeat.

That predictable foundation still lets me build different personalities: a fast, fragile enemy that aggressively swarms; a heavily armored tank that slowly absorbs damage as a moving wall; a ranged enemy that calculates vectors to stay out of melee range while taking shots. Different behaviors interacting during the same wave — a tank blocking your path while ranged units fire from behind it and fast units try to flank you — is where the system turns into a real tactical challenge.

Variety without rebuilding everything

One advantage of modular systems is that I don't need to build every enemy from scratch. Instead I use a common base AI "brain" and just change the properties, state modules, and behaviors that make each enemy unique — speed, health, attack range, damage output, recovery time, detection range, and movement behavior (pathfinding vs. steering).

A few numbers tweaked in the Inspector and a swapped behavior script can turn the same foundation into a completely different enemy. For a roguelike where you face thousands of enemies, that matters — the goal isn't a massive database of enemies, it's combinations of enemies that change how the player approaches each wave.

Code makes it work. Feedback makes it feel good.

One of the biggest lessons I've learned building Skeletor: functional combat isn't automatically satisfying combat. An enemy can lose health correctly and still make a sword swing feel like hitting them with a wet noodle. The player needs to feel what happened — that's where feedback comes in:

• Hit reactions — the enemy's sprite flinching
• Knockback — physically pushing the enemy back to create space
• Particles — sparks and bone splinters on impact
• Animation — the heavy follow-through of a swing
• Sound effects — the crunch of bone or swoosh of a blade
• Damage numbers — popping up to show the math behind the hit
• Screen effects — subtle camera shake on critical hits
• Weapon effects — trails and blur following the weapon path
• Enemy flashes — a custom shader flashing the enemy white for a few frames

All of these turn a cold technical interaction — a hitbox overlapping a hurtbox — into a satisfying gameplay moment. This is where programming and art stop being separate disciplines and become one.

The full development cycle

As a solo developer there's no separate programming, art, design, or QA team — I'm all of them. A system isn't finished when the code compiles; it still needs to look right, communicate clearly, fit the dark isometric style, and hold the frame rate. My day-to-day workflow usually looks like this:

• Design — define what the mechanic should do on paper
• Prototype — build the simplest, ugliest grey-box version in Unity
• Art — create the sprites and animations to communicate it
• Test — play it repeatedly, pushing it to its limits
• Iterate — fix whatever isn't working, code or animation timing
• Polish — add hit-stop, camera shake, and sound to finish the feel

Then it starts over for the next feature. That tight, iterative loop is the reality of working solo — design, code, and art all living in the same hour.

Designing systems that work together

Skeletor is a wave-survival roguelike, so replayability is one of the biggest priorities. I don't want players to experience the same handcrafted sequence every run — I want systems to interact dynamically and create new situations organically. A group of fast enemies creates one kind of pressure; a slow, powerful enemy creates another. Add a ranged enemy and it changes how the player positions; increase enemy density and a previously safe corner becomes a trap.

The difficulty doesn't have to come purely from bigger numbers. A modifier that makes enemies explode on death, combined with one that makes them spawn in tighter clusters, creates a chain-reaction minefield. That kind of systemic, emergent difficulty is one of the things I want to explore most with Skeletor.

Breaking my own game

A huge part of development happens when something goes wrong — and things go wrong constantly. I intentionally try to break my own systems. I'm my own worst QA tester:

• What happens if several enemies attack on the exact same frame?
• What happens if an enemy dies mid-attack animation?
• What happens if the player dashes out of attack range at the last possible millisecond?
• What happens when a wave spawns an absurd number of enemies, maxing out the physics engine?
• What happens when two different status effects try to change an enemy's speed at once?

These edge cases reveal flaws that are almost impossible to catch by just reading the code. This ongoing battle with logic is one of the biggest, least glamorous parts of building this alone — I'm not only documenting what works on the first try, which is rare, but what breaks, what I learn from it, and how I eventually fix it.

What I've learned: simple systems can create deep gameplay

Underlying complexity doesn't automatically equal better gameplay. A mathematically simple enemy with clear, readable behavior can be far more interesting to fight than a complicated one whose behavior makes no sense mid-combat. Players need to understand what an enemy is doing at a glance, recognize telegraphs and patterns, and use that knowledge to improve their positioning. Good AI isn't about making enemies smarter — it's about making their behavior readable and useful for generating fun.

The reality of solo development

When you're developing alone, every problem eventually comes back to your desk — every bug, every design flaw, every awkward animation, every balancing issue. That weight can be overwhelming, but it's also what makes the process rewarding. An idea starts as a vague concept in your head, gets prototyped, breaks horribly, gets researched and fixed and refined, and eventually becomes something real you can share with the world. That exact lifecycle is the part of solo development I most want to share with this community — not just polished screenshots, but the messy, frustrating, exhilarating reality of building a world from scratch.

The road ahead

The AI and combat systems covered here are only one part of the larger project. As development continues, they need to connect cleanly with:

• Enemy variety and boss encounters
• Deep player progression and skill trees
• Dynamic wave generation and pacing directors
• Roguelike weapon upgrades and modifiers
• Advanced visual effects and post-processing
• Dynamic audio mixing
• World design and environmental hazards
• Overall difficulty balancing

The goal is a game where all of these work together as one ecosystem instead of independent silos — combat influencing progression, enemies dictating movement strategy, progression choices changing future combat decisions, and every run feeling like its own distinct, memorable experience.