Continuing my experiments with AI coding agents, I decided to spend the weekend playing around with Claude Code and getting to know a little bit about its capabilities. Most of my AI coding agent experimentation so far has been in the Github Copilot space. Yes, I’ve use the Claude agents in that format before, but it’s not quite the same experience as using Claude’s native tooling like Claude Code. So it was time to get out of VS Code and Copilot and try something a little different.

Installing & Subscription

Using the native tools, and using any model other than Sonnet, requires a subscription so I dropped my hard-earned cash down on a Pro tier subscription to Claude. I’m certainly not to the point where I’m going to go full=on legendary and pay $200 a month. There are several tools available, including integration into VS Code, a desktop app, a command line interface, or via a web browser. I’d already installed the desktop app to play around a bit with Claude in a non-programming related interaction, so I just added the Code addition to the web app and paid for my subscription.

Here’s where I ran into a problem. If you’re already signed in with a free-tier, then you pay for the a subscription, the app and web interfaces don’t recognize that you now are a paid subscriber. You have to log out, and log back in. Annoying, but whatever.

Starting Development

Once I got that sorted out, I opened the Code tab in the desktop add and gave it my prompt:

I want to create a new project. I want to create a web based game that is a Rogue-like dungeon crawler. We’ll call it Rogue-B. Create a new folder in c:\projects. We’ll put the game there

I didn’t have a name in mind at that point so I just said call it “Rogue-B” for now. I intentionally left it fairly vague just to see how Claude would approach the idea. Claude nearly immediately came back with several questions:

What tech stack do you want to use for the game?

It offered several suggestions, all of them HTML/JavaScript pairings of various flavors. I selected TypeScript + Canvas from the list of options

What visual style do you want for the dungeon?

Again, several options were presented: Text characters, simple sprites, or detailed images. I selected sprites.

What core features should be in the initial version?

It presented several features common to these types of games, and instead of a single selection, it let me select as many of the 4 options as I wanted. I selected all 5 suggested options: procedural dungeon, turn-based combat, items & inventory, permadeath, and scoring.

Of course, being AI, no matter what I selected it said they were great choices. I was running in Plan mode for Claude, which basically means that it will come up with a plan and ask you to sign off on the plan before it actually creates anything. It presented to me the following plan, which I signed off on.

The plan covers the full game architecture and a 7-phase incremental build order — starting with getting a dungeon on screen and ending with sprite polish. Each phase produces a playable (if incomplete) game, so you’ll see progress at every step.

Key highlights:

  • Turn-based loop — no animation frames, one keypress = one turn, simple and clean
  • BSP dungeon generation — the classic roguelike algorithm for random rooms + corridors
  • Shadowcasting FOV — proper fog of war with explored memory
  • Colored rectangles first — playable immediately, sprite art added last
  • ~20 source files — small enough to navigate, separated enough to stay organized

After my approval, it proceeded to create the code project, building out the initial files, and then running the game and capturing screenshots after each phase, verifying that each piece was working correctly. For instance, the post Phase 1 output was as follows:

Post Phase 1 screenshot

The game is running! I can see:

  • The ROGUE-B title
  • A dungeon with rooms and corridors rendered with FOV
  • The @ player character in yellow
  • The HUD with HP bar, stats (Depth 1, ATK 5, DEF 2, Score 0, Turn 0)
  • The welcome message
  • Control hints at the bottom

Let me test some gameplay — move around, check if monsters and items are visible:

It then proceeded to open a preview screen to the right and I watched as Claude interacted with the game and verified the output, taking screenshots at various steps as it tested the various features that it had implemented. Having verified Phase 1’s output, it proceeded to implement the remaining planned phases, one at a time, testing and taking screenshots as it went. Frankly, it was a big step up from Copilot. I admit to being impressed.

It finished up its testing and proceeded to provide me with a summary of what it had built and verified through playtesting. It even provided me with instructions for running the game myself to test so I could see the finished product. The only missing piece is that it never implemented the use of sprites. At the end it was still character placeholders.

My next prompt:

Good start. Next up is to upgrade from alphanumeric characters to actual images for player, items, monsters

It jumped back into plan mode and asked me where the sprites should be sourced from (AI generated, user provided, or it offered to find a set on the web and download them). I said I would provide the sprites as I had a set I wanted to use. It asked what format they were in, and after getting my response, it proceeded to provide the plan for the next step. It generated placeholder sprites and tested the game with them.

Initial Claude created sprites

After the successful test, it told me what folder to put the sprites in and what to name them. Therein lay my next conundrum.

Testing the Creativity

Claude had come up with a default set of monsters for the game, but those didn’t match the list of monster sprites I had. I also had a bunch of different player character sprites and I wanted to let the player choose which hero to play. So I dropped in the sprites I had to the folders and gave Claude my next prompt:

Let’s update the game to allow the player to pick their character. I have placed images in the public/sprites folder for each possible player character

That was it. Each sprite had a name like drow_warrior_male.png or h_warrior_female.png. That was the only context Claude would have for each player character. It proceeded to come up with a player select screen and correctly gave a name to each image. It further decided that each race and class of hero would have slightly different starting stats, and it proceeded to alter the starting stats to align with the hero. For instance, the barbarian had a higher attack and a lower defense. And it was entirely unguided by me that Claude added this.

The hero select screen

The results for the monsters were similarly creative.

I also added a bunch of images to the monsters folder. Let’s replace the defaults with that group of monsters

Instead of the default 7 monsters Claude had added, I gave it 37 monster sprites with nothing but filenames. It proceeded to add these, replacing the originals, giving each a proper name and stats with the following response:

37 monster sprites — great variety. Let me redesign the monster roster to use these images, organized by dungeon depth with a good difficulty progression.

Limits, Limits

It was at this point I reached my token limit for the current time block. You see, Claude’s token limit, even for the Pro tier paid subscription, is based on a number of tokens per 6 hour time period. And those are fixed time-windows, not rolling windows. So mid-monster update I got the following message:

You’ve hit your limit · resets 6pm (America/New_York)

I came back at 6pm and told it to continue and it picked up where it left off, adding the monsters, testing the output, and giving me screenshots to show the results, with commentary.

Testing the monsters

I can see the Slug monster sprite rendered right next to the player — it’s showing the actual PNG sprite from public/sprites/monsters/Slug.png. There’s also a health potion item visible to the right. The new monster sprites are loading and rendering correctly!

Wrapping it up

There were a few other tweaks I had Claude add to the code. The inventory screen needed some more details and when the game ended, I wanted the player to have the ability to post the output to social media. But other than that, the output was a fun and playable little game, which I ended up naming:

Gloomstep Dungeon

Go on, click on the link, and go give it a try. And if you’d like to see the generated code, the repo is in my Github.

All in all, a fairly successful little experiment. Enjoy.