browser-multiplayer-case-study

Prompt file imported from tehwave/peterchrjoergensen.dk (.github/prompts/browser-multiplayer-case-study.prompt.md). Copyright stays with the author.

I need to write a blog post / case study on how I explored and built the browser-multiplayer / WebRTC experiment using only AI. I am not familiar previously with WebRTC, but now I've learned through reading the code the agents wrote. The goal of the case study is to showcase how I efficiently use agnetic coding, how awesome WebRTC is and the takeaways.

Ask me anything. #askQuestions

Here's a summarization of the different conversations I had with the agents:

I pulled the five chat sessions from the VS Code debug logs and rewrote them as case-study-ready summaries in first person, so they’re easy to fold into a blog post. I kept the emphasis on intent, iteration, and the decisions that shaped the experiment.

## 1) Browser-based multiplayer game brainstorming session

I started this session in pure planning mode. The prompt was very specific: I wanted to brainstorm a browser experiment where two browsers could play together using only browser APIs and JavaScript, with a strong preference for something small, 2D, and easy to build. I also anchored it to `#file:plan.md` and an earlier “Multiplayer Web Game Without Server?” conversation, which made this feel less like a blank-slate ideation exercise and more like a living design document that would keep evolving. The assistant immediately treated it as a brainstorming problem rather than a coding one, which matched my intention perfectly.

I kept tightening the constraints as the conversation went on. I said I didn’t want code yet, I wanted detail, and I wanted the assistant to leave the final decisions to me. I pushed the design toward a mobile-first experience, specifically portrait mode on a phone, because that was the target device that mattered. I also asked for polish: game feel, springy motion, easing, animation, and a sense that it should feel like a real game rather than a technical demo. At the same time, I made the purpose of the experiment very clear: this was about learning WebRTC and browser-to-browser multiplayer, not about anti-cheat, competition balance, or long-term content depth.

The assistant responded by asking the right kind of questions: how players should connect, what kind of game loop I wanted, and whether one browser should act as the authoritative host. That mattered because it forced the architecture conversation into the open early. I also steered the session toward practical tooling by asking about browser share features, TypeScript, and whether any other libraries beyond PixiJS would make sense. This session set the tone for everything that followed: one narrow multiplayer experiment, mobile-first, polished, 2D, and deliberately scoped so I could move fast without getting trapped in a giant game-design rabbit hole.

## 2) UI/UX redesign feedback

This was the session where the prototype got its most brutal feedback, and honestly, that was the point. I came in saying the UI was terrible and that it needed a heavy revision. I defined some hard constraints immediately: every UI element except the multiplayer invitation had to live inside the game canvas, the invitation system had to live outside it, and the game itself should probably stay hidden until signaling and handshake logic were done. I also made a hard mobile requirement explicit: everything had to fit within the viewport, and if the page needed scrolling, that meant the layout had failed. That framed the whole redesign as a viewport discipline problem, not just a visual polish issue.

From there, the feedback became very specific and very iterative. I asked for the white background to be removed, for helper text to say something useful instead of repeating the button label, for inputs that couldn’t accept paste to stop implying paste was possible, and for buttons to stay disabled until the required code had been entered. I also pushed for better feedback during invite-code generation, because the creating-game step had a noticeable processing delay that wasn’t communicated at all. That led to discussion of loading states, button placement, top-row actions, back-button behavior, and naming: “Join a game” instead of a too-generic label, and “recreate game” where it made more sense.

The biggest theme, though, was avoiding layout collapse on small screens. I kept calling out duplicated controls, overflow, clipped shadows, and the wrong relationship between the game card and the canvas. I wanted the copy button inline with the invite code, I wanted top buttons to stay on one line, and I wanted `nowrap`-style behavior rather than wrapped chaos. Later in the session I got even stricter: the game canvas and surrounding card had to match dimensions exactly, no disconnect, no padding mismatch, no black border, and no persistent overlay text blocking play. I also asked for “opponent” instead of “host/client,” which is a subtle but important usability shift. This session was basically the point where the prototype stopped being a rough network demo and started becoming a real mobile game interface.

## 3) Game art style revision to pop art

This session was about turning the prototype from “functional” into “visually intentional.” I opened by asking for a pop-art redesign, and then I immediately forced the implementation direction by saying to start working on it. My first correction was a readability one: the background couldn’t be transparent, because the transparent version was hard to read. I wanted solid color treatment, which is a very practical constraint once you start layering sprites, score text, and tutorial hints on a phone screen. I also explicitly said that some sections didn’t need extra background, color, or shadow at all, because part of good art direction is knowing when to stop styling something.

The visual direction then got much more concrete. I asked for a white background on the canvas, a drawn arena, a centered middle circle, and no star or red fill in that circle. I wanted the score to sit about a quarter of the way down from the top instead of hugging the very top edge, because that made the layout feel more deliberate and less like a debug overlay. I also asked for the draggable input area to have a dotted border and pill-shaped rounding, which helped the UI lean into the comic/pop-art language rather than generic game chrome.

There were also several rounds of feedback focused on clarity and motion. I asked to remove the tutorial text after the first successful drag, because repeating guidance becomes noise once the mechanic is learned. I removed the boxed goal area because the score condition already made the boundary obvious, and I wanted the visuals to support the rules instead of contradicting them. I asked for the black border around the arena to go away, requested a dotted background pattern that was subtle enough not to steal focus, and then kept refining the motion language: the ball should only elongate at full speed, hit-stop effects should be visible at the impact point, countdown text should sit lower, and the “win/lose” text should be fixed size rather than responsive. I also called out a Sass variable error when it appeared, which tells you this session wasn’t just concept art; it was real implementation, real debugging, and a lot of iteration to keep the style coherent. By the end, the experiment had a much clearer identity: bright, graphic, readable, and intentionally arcade-like instead of looking like a generic web demo.

## 4) Add browser-multiplayer to `Projects.astro`

This was the shortest session, but it mattered strategically. I asked to add the `browser-multiplayer` experiment to `Projects.astro` as a game and specified `browser-multiplayer.png` as the image. That sounds small, but it’s the moment a side experiment starts becoming part of the portfolio story. It moves the work from “something I built in a playground” to “something I’m willing to showcase on the site.”

What I like about this step is that it shows the experiment had enough substance to deserve a spot alongside the rest of the work. It also means the visual identity had to be good enough to survive as a project card, which is a different bar than working code. A portfolio entry is a public claim: this is the thing I made, this is the quality standard I stand behind, and this is how I want people to discover it. Adding it to `Projects.astro` made the experiment discoverable from the site navigation rather than hiding it in a dev-only corner.

The session also ties back to the earlier design work. By this point, the multiplayer experiment had moved far enough through brainstorming, UI restructuring, and art-direction work that it could be presented as a legitimate game project. That matters for the blog post/case study angle you want: it lets you tell the story as a sequence of increasingly concrete commitments. First I explored the architecture. Then I tightened the UI. Then I gave it a style. Finally, I put it in the projects list so it became part of the public site. That’s a clean narrative arc, and this session is the “publish it” checkpoint in that arc.

## 5) Fix `npm run check` issues for `browser-multiplayer`

This was the cleanup pass. I asked for the issues from `npm run check` related to `browser-multiplayer` to be fixed, which tells me the experiment had already progressed far enough to deserve a proper validation sweep. This kind of session is the unglamorous but essential part of the workflow: after all the design and implementation changes, I wanted the codebase to be green again and the experiment to be clean under the project’s TypeScript and Astro checks.

I don’t want to invent specifics the log doesn’t show, but the intent is clear: this was not a feature session, it was a quality-control session. It’s the point where I stopped adding new ideas and started making sure the existing work actually held up under repository checks. That’s especially important in an Astro project with strict TypeScript and component conventions, because a feature can look fine in the browser and still leave behind little errors, broken typing, or formatting problems that will bite later.

From a case-study perspective, this session is actually important because it shows discipline. It’s easy to stop after the exciting part — the multiplayer, the interface, the art direction — and leave the repo slightly messy. Instead, this pass says: I’m treating the AI-assisted build like real software, not a throwaway prototype. I’m validating the result. I’m fixing the red flags. I’m making sure the experiment can survive checks before I call it done. That’s a strong point for the article, because it supports the bigger thesis: I wasn’t just generating code with AI, I was using it as a fast iteration partner and then still doing the serious engineering work of cleanup and verification.

Here's some meta details about those conversations:

## Session metadata

Here are the log-level details from each `main.jsonl` conversation stream:

| Session | Window | User messages | Tool calls | Assistant responses | Notes |
|---|---:|---:|---:|---:|---|
| Brainstorming | 2026-05-02 18:08:22 → 18:34:10 | 6 | 22 | 22 | Early planning, lots of questioning and doc-shaping |
| UI/UX redesign feedback | 2026-05-03 14:11:18 → 17:15:06 | 21 | 289 | 285 | The big iterative redesign pass |
| Pop art art-direction revision | 2026-05-03 14:11:18 → 17:15:06 | 15 | 139 | 142 | Visual polish, motion tuning, and bug fixes |
| Add to Projects | 2026-05-03 17:03-ish window | 1 | 6 | 7 | One-shot portfolio inclusion |
| `npm run check` fixes | 2026-05-03 17:15:06 → 17:16:24 | 1 | 15 | 13 | Cleanup and validation pass |

## Add-on details by session

### 1) Browser-based multiplayer brainstorming session
- **Conversation span:** about **25m 48s**
- **User messages:** 6
- **Tool calls:** 22
- **Assistant responses:** 22
- **Main tools used:** `manage_todo_list`, `vscode_askQuestions`, `read_file`, `replace_string_in_file`
- **What this says about the session:** this was a high-iteration ideation session. I wasn’t just asking for a game idea; I was turning the chat into a living design doc, then tightening constraints around mobile-first, portrait mode, polish, and WebRTC learning goals.

### 2) UI/UX redesign feedback
- **Conversation span:** about **3h 3m 48s**
- **User messages:** 21
- **Tool calls:** 289
- **Assistant responses:** 285
- **Main tools used:** `run_in_terminal`, `replace_string_in_file`, `run_playwright_code`, `manage_todo_list`
- **What this says about the session:** this was the longest, most iterative redesign loop. It had a lot of back-and-forth because the UI needed repeated constraint tightening: canvas vs card sizing, invitation flow placement, button behavior, overflow issues, and mobile viewport discipline.

### 3) Pop art art-style revision
- **Conversation span:** about **3h 3m 48s**
- **User messages:** 15
- **Tool calls:** 139
- **Assistant responses:** 142
- **Main tools used:** `replace_string_in_file`, `run_in_terminal`, `manage_todo_list`
- **What this says about the session:** this was a dense implementation/refinement session. The prompts kept pushing the assistant toward stronger art direction, better readability, better motion language, and cleanup of visual bugs as they appeared.

### 4) Add browser-multiplayer to `Projects.astro`
- **User messages:** 1
- **Tool calls:** 6
- **Assistant responses:** 7
- **What this says about the session:** a quick publication step. The experiment had reached the point where it was ready to be surfaced as a portfolio item, which is useful proof for your “AI-assisted build to public artifact” story.

### 5) Fix `npm run check` issues
- **Conversation span:** about **1m 18s**
- **User messages:** 1
- **Tool calls:** 15
- **Assistant responses:** 13
- **What this says about the session:** this was the validation sweep. The work had moved from building and redesigning into getting the project green again under repo checks.

## Small note on the numbers

These counts are from the main session logs, so they reflect the primary conversation stream. Some sessions are extremely chatty because they include many micro-iterations, which is exactly what makes them interesting for a case study: they show how much the AI-assisted workflow depended on tight feedback loops rather than one-shot generation.