La Cripta de Nekkman — A Solo Game, Built Out Loud with AI

The Night I Lost Everything

00:32 AM, August 3rd. I'd spent the entire afternoon in the map editor, room by room: placing torches, adjusting spike traps, deciding where each skeleton would spawn. I closed the session satisfied. I reopened it to keep going.

Nothing had saved. An entire afternoon of work, gone.

"I'm going to have to do this all over again, everything got deleted... I need this to actually save."

That message, sent in the heat of the moment, ended up forcing something good: a real save system, built in the weeks that followed. I didn't know yet the same problem would hit me again, twenty four hours later, for a completely different reason.

The game itself started small: a plain green rectangle the code affectionately nicknamed "Yamel," walking around a room fighting skeletons made of colored blocks.

Designing the Enemies, on Paper First

Before any of the enemies existed in the game, they existed on paper. Early on I sketched out concepts for the three enemy types the game would need: a Mage, a regular Skeleton, and a Tank, plus an alternate, heavier version of the Tank I ended up using instead of the first design.

The final in-game version of the Skeleton's walk cycle, the pixel art sprite you actually see moving around the dungeon, wasn't something I built myself: my friend Lautaro Labella designed it, turning that early concept into the animated sprite the game still uses today.

The Tank, for instance, was shaped around visual reference material I studied and adapted rather than designed from scratch using Nano Banana.

A few days later, those skeletons were already patrolling the dungeon rooms, even if their AI still had a lot of growing up to do.

The Bug That Wouldn't Die

Not every part of solo vibecoding is exciting. At one point the floor started randomly filling with black squares, a texture bug that came and went with no obvious pattern. I reported it, it got "fixed," and it came right back.

"Did the black squares show up on the floor again? Come on, I asked you to get rid of them. What are you even doing?"

Six different hypotheses got tested and ruled out before landing on the most anticlimactic answer possible: browser caching. It resolved itself almost by accident, as a side effect of an unrelated fix days later.

Planning Before Placing

Not everything was reactive. Trap density, room pacing, how much danger to pack into a single space, all of that got sketched out and planned before it went into the editor.

From a Green Rectangle to a Character

Over six weeks, working session by session with Claude, that green rectangle became a full character. The HUD went through the same transformation: what started as a simple reference image for a health icon ended up hand fit into a finished pixel art health bar.

The real turning point came in one long night in early August: a full "Adventurer" sprite pack, 16 spritesheets, 128 frames covering movement and attacks in every direction, applied and tuned in a single session. The hitbox had to be decoupled from the visual size of the sprite, which surfaced a real bug: a spike trap started damaging the player "from a distance," because the collision check was still comparing against the old rectangle instead of the new, much larger sprite.

By the next day, the character had a name too: Klegar, protagonist of a short necromancer origin story I wrote to replace the placeholder dialogue that had been sitting there since day one.

See It in Action

A few seconds are worth more than another paragraph of description here.

The Tool Behind All of It

Almost nothing in the game is hardcoded. Nearly every number that affects how a fight or a room feels lives in one central tool: the map editor. Player health, enemy health, how much damage each enemy deals, how much damage each spell deals, how much damage each trap deals, even how long a trap takes to trigger, all of it is parametrized and editable from the same place, without touching a line of code.

The map itself works the same way. Rooms get built out of blocks: walls, traps, decorative and interactive elements, all placed directly in the editor. One detail I'm particularly happy with: loot isn't manually assigned per room. The game automatically counts how many breakable crates are placed on a map and calculates the total loot from that number on its own.

This is also the tool that made the difficulty math from the next section possible in the first place. Every value that went into those difficulty formulas, every enemy stat, every trap's damage and timing, came directly out of this editor.

When the Math Told the Truth

One of the most useful things from the course was a proper level balancing method: normalizing every enemy stat (health, damage, speed, range) on a 1 to 10 scale using Min-Max normalization, then combining them into a single difficulty score per enemy, trap, and room.

Three levels turned out to be too coarse a resolution to actually see the curve I was trying to build, though. So I broke the three levels down into six rooms each, eighteen data points instead of three, and gave every enemy type and every trap its own difficulty value in a new reference document. That let me calculate an actual difficulty score per room, based on exactly how many enemies and traps were placed in it, instead of one flat number per level.

That's the curve that finally looked like what the course had taught: a steady climb from room 1 to room 18, with the small dips and rises you'd expect from real room-by-room pacing instead of one blunt number per level. It's also the tool that confirmed, room by room, that the fix had actually worked.

What This Project Actually Taught Me

Making a game isn't something you can do purely on instinct, and this was the project that proved it to me. Before this, I designed based on a gut feeling built from years of playing games, without being able to explain why something worked. Now I have an actual method: measurable balancing, documented decisions, and a habit of writing down what's real instead of what I wish were true.

I also learned, the hard way, that trusting the math on paper isn't enough on its own. I leaned on the difficulty formulas more than I should have and left real playtesting for the very end, when it should have run in parallel the whole time. That's the biggest lesson I'm carrying into the next project.

And underneath all of it: building this entire game working session by session with an AI assistant, from the first green rectangle to the final boss room, was its own kind of learning, one I'm still only at the beginning of.

you can play this "game" here!
https://frantarelli.github.io/cripta-de-nekkman-tp2/