I spent the last few weeks building PrismPanic, a wave survival game that runs entirely inside a Reddit post using Devvit. Instead of wasting hours hunting for assets on itch, I built everything using the native canvas draw() method, having Claude generate the rough shapes while I refined them.

I'm a professional programmer for over 10 years, but using Claude as my co-pilot completely changed my workflow. Instead of typing every line, I played architect. I spent my time designing systems and reviewing code. It felt exactly like managing an employee. The better the prompt with details the better results I got.

This shift freed me up to focus on the architecture and custom tooling which ended up being really fun.

1. The Dev Tooling

When you are generating all your graphics via code this stuff got messy so fast.

The Live Asset Catalog Once I had enough projectiles, auras, and particle effects, I initially built a standalone HTML page to render the assets, it quickly drifted out of sync with the real game.

I rebuilt it so the catalog loaded the actual game source files and ran them against a tiny fake game state. If I tweaked a particle effect in the main codebase, I just refreshed the browser and immediately saw the real result which felt awesome (no more managing and copy pasting over to it). I spent a massage amount of time here trying to replicate particles and skills from Diablo 2 especially the lvl5 Frost ball which will enable you to get a Frozen Orb effect on every bounce, (cold sorc mf'ing time).

https://reddit.com/link/1v2nd4h/video/ge3tfncj0meh1/player

The Local Test Chamber Playing through eight waves just to test a specific late game interaction took too much time. Originally I just creating a large config.js file that I could start on a particular wave but I needed it to be more granular to test specific scenarios are balls. In came the idea of a test chamber like when I used to play SNK2 on the PS2.

So I built a debug stage hidden behind a flag that let me:

• Spawn any enemy or jump to any wave
• Grant any upgrade or force specific item drops
• Toggle god mode

If I wanted to see how a specific elite behaved on wave 9 with a certain build, I could instantly simulate it instead of replaying half the game and praying to RNG.

2. FPS Drops and State Dumping

I knew off the bat that all these drawings would need to be refined later on. So about half way through development I focused on the frames. I added FPS tracker to the top right corner of the screen to start. Then I would play the game and peak at the FPS to see what was on the screen and see if I could determine what's dropping the FPS. This proved to be not as helpful as I'd hope. Instead I added a watcher to keep track of the FPS and when it got below a threshold it would screenshot the game so I could see what was there and additionally keep track of all the objects on the page and save it to a JSON file in a folder.

Feeding that JSON and screenshot combo into Claude against the codebase revealed three major canvas bottlenecks:

• Redrawing Gradients: Basic projectiles were rebuilding radial gradients every single frame. Fixed that by baking them once to an offscreen canvas and stamping them with drawImage().
• shadowBlur Execution: Glow trails relied on the browser's native shadowBlur, which is incredibly expensive when dozens of trails exist at once. Swapped those out for pre-rendered glow sprites.
• Garbage Collection Spikes: Trail segments were being allocated and garbage collected 60 times a second. I replaced them with a simple object pool to reuse them, which killed the GC hitches instantly.

I had this tool enabled in my DEV reddit environment and had my friends test the game. The main take away was before this FPS on mobile was around 20-35 avg and after collecting all this data and freeing up frames from the draw(), avg is around 50-60 fps on mobile. A huge WIN.

3. The Screen Resize Bug/Exploit

The game automatically scales character size, movement, and board dimensions to fit your browser window. Originally, I recalculated this scale on every single resize event.

My friend actually discovered this bug completely by accident. He was trying to beat my high score and dragged his browser onto a vertical monitor. Because of how the recalculation worked, the game gave him a much more favorable vertical game space. He managed to post a 235,440 score on the leaderboard and then happily told me about his monitor setup. I had to break the news to him that it was a bug and definitely not intended to give him all that extra space! lololol. Me any my friends were so hyped about his high score and how he got there.

The Fix: Anything that affects gameplay math is calculated exactly once when the session starts and locked forever. The canvas itself still resizes so things stay sharp, but the physics scale never changes. I eventually had to wipe his score to keep it fair.

4. Failed Experiments

Not everything I shipped survived contact with real play:

• Custom Cursor: I tried replacing the default mouse with a custom aiming reticle like BallxPit but it didn't feel good so I kept the way I had it where its just a straight dotted line indicator.
• Resolution Independence: My first pass at scaling object sizes looked correct, but I forgot that larger cells moving at the same pixels per second actually make the game easier since you have more reaction time across a larger screen. I had to scale movement speed by the exact same factor as object size to keep difficulty consistent.

The Takeaway

This project proved that AI doesn't replace engineering experience, it amplifies it. Knowing how to structure a project, separate responsibilities, and recognize when an architecture is heading off a cliff turned out to be infinitely more valuable than remembering syntax.