# Clanker Arena: AI's impact on product design

**Author:** Walter Lim (https://walt.online/about)
**Published:** 2026-08-19
**Canonical:** https://walt.online/work/clanker-arena
**Play:** https://shoot.walt.online/ · **Source:** https://github.com/waltzaround/2606-devday

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

## Summary

Clanker Arena is a multiplayer browser FPS that began as a 45-minute AI-assisted prototype. The project shows that AI can collapse the distance between product critique and implementation, but it does not replace product design: the limiting work moves to observation, problem framing, systems thinking, and continuous validation in the live product.

- **Role:** Designer & developer
- **Period:** August 2026
- **Format:** Browser multiplayer FPS
- **Disciplines:** Product Design, Game Design, Three.js, TypeScript, Cloudflare Workers, Multiplayer
- **Stats:** 45 minutes to the first playable experience · 5 game modes · 12 distinct map themes · 32 players per room

## 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.

## 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.

1. **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.
2. **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.
3. **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.
4. **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.

## 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 negotiate different budgets, play the result, and keep the version that still felt honest.

1. **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.
2. **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.
3. **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.

## FAQ

**How did AI change the product design process?**
AI made the working product the primary design artefact. Research, critique, implementation, and validation could happen in one continuous loop instead of being separated by handoff and sprint cycles.

**Did AI replace product design on Clanker Arena?**
No. AI made plausible implementation abundant, which increased the importance of judgement. The critical work was identifying experiential failures, finding their underlying system causes, defining behavioural constraints, and verifying the result through playtesting.

**What did AI struggle with?**
AI often satisfied the wording while missing the intended experience. Urban maps became taller boxes, stairs looked correct but were not useful, and additional map labels did not automatically produce additional play styles.

**Why use a multiplayer FPS for this experiment?**
A multiplayer FPS is unforgiving: product quality spans input, movement, level design, interface hierarchy, simulation, networking, latency, and social rules. It made the boundary between plausible output and a coherent experience immediately visible.

## About the game

Clanker Arena is a free multiplayer browser FPS with solo and team PvP, cooperative invasion, training, bots, configurable match series, and procedural multi-level arenas. It runs on authoritative Cloudflare Durable Object game rooms and supports mouse, keyboard, and gamepad controls in any modern browser with WebGL and WebAssembly.

---

More about Walter Lim: https://walt.online/llms.txt