Clanker Arena

What building a multiplayer browser FPS taught me about product design when the distance between critique and implementation collapses.

Clanker Arena multiplayer firefight in a generated neon arena

Role

Designer & developer

Period

August 2026

Format

Browser multiplayer FPS

Disciplines

Product DesignGame DesignThree.jsTypeScriptCloudflare WorkersMultiplayer

What changes when implementation stops being the slowest part of product design?

I built Clanker Arena for a challenge at AWS Dev Day 2026 in New Zealand. The brief I set myself was simple: a real-time 3D multiplayer game, designed and in production within 45 minutes. It shipped, winning OpenAI swag and $2,000 in credits.

But the game was really a test of a broader product-design question. If I can move directly from an observation to working software, does my role become less important, or does the work move somewhere else?

The answer emerged through playtesting. Faster execution did not remove design work; it moved the bottleneck from producing artefacts to framing problems, reading behaviour, making systems-level decisions, and knowing when a plausible result was still not good enough.

45m

to the first playable experience

5

game modes

12

distinct map themes

32

players per room

AI changed the unit of design work

The meaningful change was not simply that screens or code were faster to make. It was that research, interaction design, implementation, and validation could happen inside one continuous loop, using the live product as the shared source of truth.

Static artefacts→Live systems

The working product became the primary design material. I could judge movement, latency, hierarchy, and game feel together instead of approximating them across separate deliverables.

01
Handoff→Direct intervention

A product observation could become a tested implementation in the same session. I could move from describing intent to carrying it through the system.

02
Feature requests→Evaluable constraints

Prompts improved when they defined the experience and its success conditions: buildings must be enterable, stairs must be traversable, and hits must resolve against what the player saw.

03
Production bottleneck→Judgement bottleneck

AI made plausible output abundant. The scarce work became noticing what was wrong, finding the underlying product model, and maintaining a coherent quality bar across rapid change.

04

Code as design material

AI let me play with how performance and networking limits shape the player experience

Those limits usually arrive as constraints handed down after the design is finished. Because implementation was cheap, I could neogitate different budgets, play the result, and keep the version that still felt honest.

01

How much can a frame hold?

Raising particles, geometry, and operator count was easy. The design work was feeling the moment the frame budget broke, especially when movement stopped being crisp and the fight became hard to read.

02

How cheap can the network be?

A thinner tick rate and cheaper reconciliation made rooms easier to keep alive. They also made combat resolve against a slightly different fight than the one on screen. The requirement stayed experiential: a valid shot must land on the opponent the player actually saw.

03

How far can I push the experience?

I could push occupancy, bot load, and authoritative state until a room stopped feeling immediate. The useful number was not the maximum the edge could hold, but the budget at which 32 operators still felt like one shared fight.

Impact on my practice

I ended up with a playable multiplayer FPS, but what stuck with me was simpler. When making is this cheap, I can produce plausible ideas faster than I can tell which ones are any good. The work I have to get better at is noticing what feels wrong, deciding how it should behave, and checking whether it actually works for someone.

The product became the deliverable

Working software replaced the gap between a design artefact and its eventual interpretation. I could evaluate decisions in context, not just explain them.

Critique became higher leverage

The quality of my observations, what feels wrong, why it matters, and how success should behave had more impact than the volume of generated output.

Systems thinking became design work

Interaction quality crossed rendering, input, physics, networking, rules, and content. AI helped me traverse the stack; a coherent product model held it together.

Validation had to get faster too

Faster production can simply ship the wrong idea sooner. Keeping playtesting inside the generation loop stopped me from treating plausible output as accepted output.

Try the result

Enter the arena in your browser