Design Notes
Prototype #006 — paper.io-style territory game with a roguelike twist. You control a hero on a 200x200 grid. Drag to paint tiles, form a closed loop back to your territory, everything inside gets claimed. 4 factions (you + 3 AI), each with 6 HP and up to 80 soldiers per base. Game runs 180 seconds.
The grid being 200x200 (40,000 cells) is what makes it chaotic — there's always room to expand, so it doesn't stalemate. But it also created the biggest performance headache of all the prototypes (see dev log).
Originally had 3 skill paths: Attack, Commander, Speed, each with 3 tiers. I tried all of them myself and Commander and Speed just weren't fun — Attack was always the obvious pick. Cut it down to Attack-only with 3 flavors: Blade Rush (wide melee sweep), Shotgun (ranged spread), Bomber (fire trails). Less choice, more impact. The 4-tier leveling system lets you upgrade across a 180-second game, which feels about right for a prototype.
All 23 sound effects are generated via Web Audio API — oscillators, noise, FM synthesis. Zero audio files. It was an experiment: can a game sound decent with no assets? Answer: sort of. It's crunchy and retro, which fits. But if I ever do a full version, the big moments (territory captures, skill activations) would really benefit from proper audio.
Dev Log
40,000 cells and the frame rate cliff
BFS flood fill over 200x200 means visiting up to 40,000 cells. Doing that every frame on a phone was an instant slideshow. The fix: incremental BFS — process about 500 cells per frame and spread the rest over 3-4 frames. At 60fps that's 50-70ms total, visually seamless. This was probably the hardest performance problem I've hit so far.
AI behavior on a big grid
First AI just moved randomly. Useless. Second version always went for the nearest unclaimed tiles, which meant all 3 AI would pile into the same corner. Ended up with an influence grid (downsampled to 50x50) that weights enemy proximity, unclaimed value, and distance from base differently per faction so they spread out. It's not brilliant AI but it's good enough that you can't just ignore them.
Mobile audio autoplay
Browsers block audio until user interaction. Fine. But the rules are different everywhere — Chrome wants a click, Safari wants it inside a specific event handler scope, some browsers accept touch, some don't. I registered click, touchstart, touchend, and keydown listeners that all call AudioContext.resume() on first trigger then remove themselves. Standard approach, looked it up before implementing. Works everywhere now, but the inconsistency across browsers is genuinely baffling.
Credits
3D models by @quaternius