Warloop: turning generated character art into a playable prototype

Warloop: Echoes of Solmara is a dark-fantasy 2D game prototype. The game-design document came from a collaborator. I worked with Claude Code on turning that design into phases of implementation, using TypeScript and Phaser.

I was concerned about the art from the beginning. I wanted the game to look good, and generating the assets was part of the development problem. I also asked for separate phase documents and session notes, because the work would have to continue across conversations with limited context.

The downloaded image and the character on screen were different tests

The art pass used Ludo.ai for character images and animations. Aurha, the player character, served as a visual reference for later characters. The intended style was detailed 2D dark fantasy rather than pixel art.

The files could look good on their own and still fail in the game. During a playtest I reported that the downloaded characters had good-quality images, but were so small on screen that they were barely recognizable. Aurha also walked while facing the opposite direction, so I asked to invert it.

Those were visible problems I could point to. They weren't answered by a successful image-generation request or a successful build.

Phaser needs to know how to read a spritesheet: an image containing multiple animation frames. BootScene loads it with explicit frame dimensions and creates named animation sequences. The game then has to display the right sequence at a useful size, facing the right way, with a collision body that fits the character.

The development notes record problems with frame layouts, facing direction and body offsets after resolution changes. At one point I adjusted a boss's height manually. Getting a good-looking asset was only the beginning of making that character work in its scene.

An animation should not decide whether the boss was defeated

One bug involved the boss's death animation. The code waited for a 1,500 ms visual effect to finish before reporting the defeat. If the player died during that interval, the scene could restart and cancel the animation. Its completion callback would never run, and the defeat could be lost.

The changed BaseBoss.die() method reports the game event before playing the visual effect. It marks the boss dead, stops movement, disables collision, creates the rewards and emits boss-defeated. The animation comes afterward; its final callback only destroys the sprite.

The early dead-state check also stops the same defeat from being processed twice. The ordering lets the game finish the important transition even if the screen changes before the visual effect ends.

The zone code has related cleanup: reset the enemy list and boss reference when a scene starts, and remove its player-death and shadow-defeat listeners when it shuts down. Otherwise an old scene can keep responding to events after it is no longer the active one.

Keep the mistakes with the project

I asked whether we had a file for the pitfalls we were finding and fixing, so a later session would know what to do and what to avoid. The resulting record covers scene reuse, event listeners, the delayed defeat event and sprite geometry.

That record mattered because I was continuing through separate development phases. I wanted the next session to know what had been built and what remained, rather than rediscover the same problems from a fresh prompt.

The prototype reached generated characters, animations and game scenes, and Vite builds passed during development. It wasn't finished. In later playtesting I still couldn't find bosses in several levels and asked for their placement to be checked. Those remaining playability problems belong alongside the parts that worked.