How I AI: Speedrun a 3D Multiplayer Game in 15 Minutes with Cody De Arkland

Sentry Senior Director of Developer Experience Cody De Arkland uses Cursor and Claude Code to build playable 3D game prototypes despite having no prior game-development experience.

His Spaceflight project grew through small iterations: movement, imported models, orientation fixes, WebSockets, multiplayer state, and chat. The episode's live build compresses that loop into a 15-minute demonstration.

In this episode of How I AI, Cody explains how Spaceflight evolved and then starts from an empty React project to create a low-poly flight prototype with a parallel multiplayer server. The result is a working demo, not a deployable public game.

Build Spaceflight one capability at a time

The iterative 3D game workflow follows Cody's progression from a grey cube to flight controls, art, effects, and multiplayer behavior. Each prompt asks for one observable capability and each run supplies evidence for the next correction.

Spaceflight was Cody's first game project. He used the model to write code and to explain unfamiliar concepts as the prototype expanded.

Cody drew inspiration from X-Wing and No Man's Sky, then began with the general idea of a multiplayer space-flight simulator. References can guide mechanics and mood without copying protected art, code, characters, or branding.

From grey cube to multiplayer prototype

The first version contained a star field and a grey cube. Cody added one capability at a time and tested each visible change in the browser.

1. Movement: He added controls and worked through pitch, yaw, roll, camera position, and movement in three dimensions.
2. 3D models: Cody found spaceship models on Sketchfab and learned how GLTF and GLB assets enter a Three.js scene. Downloaded models need compatible licenses, attribution where required, provenance, and security checks before redistribution.
3. Orientation: Imported models did not share a consistent forward direction. Cody described the required rotation more precisely until the visual result matched his intent.
4. Multiplayer: He asked the model to compare implementation approaches, chose a WebSocket-based path, and used the model to inspect race conditions and performance concerns. Model review supplements rather than replaces tests, profiling, and security review.

When Cody found useful information about Three.js or another library, he brought that context back into the coding session and asked the model to apply it. Current official documentation and the running program remained the checks on the generated explanation.

Build a multiplayer flight demo in 15 minutes

The 15-minute multiplayer speedrun workflow isolates the project, defines the flight mechanic and visual target, builds client and server work in parallel, and verifies the demo across several local clients.

For the live demonstration, Cody began with an empty folder and aimed for a playable multiplayer prototype rather than a durable game service.

Create an isolated project

Cody created a fresh React project from the terminal, then initialized Claude Code inside that directory.

npm create vite@latest boop-flight -- --template react

The demonstrated command uses an unrestricted approval mode so the agent can change files and run commands without pausing. That is appropriate only in a disposable, isolated environment with no secrets, production credentials, personal files, or important uncommitted work. A normal repository should use scoped permissions and review consequential commands.

claude init --yolo

Initialization inspects the project and creates a CLAUDE.md file describing its structure and conventions. That file should contain project guidance, not credentials or sensitive data.

Describe the game's mechanics and look

Cody gave Claude a broad brief for a Three.js flight simulator, including low-poly art, keyboard controls, banking turns, a field, trees, and surrounding objects.

I want to build a flight simulator game that uses three js. Let's use polygon style art for the planes. WSD for movement. I want turning to bank the plane and arrow keys to control pitch. Let's have it take from a green field with trees and other objects around.

Claude selected dependencies and scaffolded the application. Before keeping those choices, a developer should inspect package names, versions, licenses, install scripts, bundle impact, and known vulnerabilities.

Run the game and describe observable failures

The first build placed a low-poly plane over a field, but the camera faced the wrong direction and the controls were inverted.

• Observed failure: Moving forward sent the plane toward the camera, and the flight controls did not match Cody's expectation.

Cody described the camera problem in plain language:

It looks like my camera is facing the front of the model... we should be looking should be fixed to the tail of the plane.

He then described the control and camera corrections:

All of my flight controls are reversed. Now we should fix that. I also want the camera to be slightly above and behind the model.

Each browser check produced a concrete next instruction. The model revised the code, and Cody tested the result again rather than assuming the change worked.

Build the multiplayer server in parallel

While one Claude Code session worked on camera and controls, Cody opened another terminal, created a server directory, and assigned the multiplayer backend to a second session. Parallel agents can conflict, so each needs a clear directory or branch boundary and a deliberate integration step.

The backend request focused on player joins and a small chat interface:

I want to start implementing multiplayer for this game in the server directory. Handle player joins and give me a chat interface on the top right that shows when people join the game.

Claude created an Express and Socket.IO server for joins, movement synchronization, disconnections, and chat. A public multiplayer service would also need server-authoritative state, authentication, input validation, rate limits, abuse prevention, moderation, privacy controls, observability, load testing, and recovery behavior.

Test the demonstration across several clients

About 15 minutes into the live build, several browser tabs could join the same game, move planes, and use the early chat interface. That verifies the local happy path shown in the episode, not internet-scale multiplayer behavior.

The model also added a cockpit zoom and distant mountains. Controls and layout still needed work. Cody's timing demonstrates prototype speed; it does not include production design, asset review, security, accessibility, testing, deployment, or ongoing operations.

Fast prototypes make the unknowns visible

Cody directs, runs, observes, and corrects rather than writing every line by hand. In a short session, that loop produced something people could play locally and exposed the next set of technical and design questions.

The transferable skill is breaking an idea into observable increments and giving precise feedback when reality differs from the request. The same speed increases the importance of isolation, dependency review, testing, and a clear boundary between a demo and software that other people can safely use.

The 15-minute result is a prototype, not a claim that multiplayer networking is solved. Local clients can prove that objects synchronize and that the basic interaction feels interesting. They do not prove security, authoritative server behavior, latency tolerance, matchmaking, persistence, abuse prevention, or safe deployment on the public internet.

Cody's loop stays effective because feedback is visual and specific. The ship turns too slowly. The camera is in the wrong place. Another player does not appear. Those observations give the agent a concrete failure to locate. "Make it better" would hide the useful information that comes from actually running the game. The playable build is both the prototype and the next prompt: every surprising behavior becomes evidence for a narrower correction.

The isolated project also protects the speedrun from pretending to be a migration plan. Cody can explore a mechanic aggressively, throw away the build if it fails, and carry the lessons into a more deliberate architecture later.