Agar.io rebuild deck
BRUTAL
Interpolation, prediction and area-of-interest culling are three separate systems an agent will skip unless named, and even with all three the game is still two hundred strangers you do not have.
The hard part is not game design at all.
Single player is an afternoon. The KINDA is entirely about the netcode: interpolation, prediction and area-of-interest filtering are three distinct systems that every agent will skip unless you name them, and without them the game is unplayable over real internet. Read Gambetta before you prompt, so you can tell whether what you got back is right.
- Difficulty
- BRUTAL · 5 of 5
- First playable
- A weekend
- The original
- 1 team-years
- Released
- 2015 · Browser
- Genre
- Multiplayer
Build a real-time multiplayer .io game: cells eat pellets and smaller cells to grow. Node server plus a Canvas client, WebSockets. Requirements: - Authoritative server. The client sends only its target direction; the server owns all positions, mass and collisions, and broadcasts state at 20Hz. Never trust the client with its own position — that is the entire threat model of a .io game. - Client-side interpolation: render every remote entity 100ms in the past between two known states, so movement is smooth despite the 20Hz tick. Apply client-side prediction with server reconciliation for your own cell. - Area-of-interest filtering: send each player only the entities inside their viewport plus a margin. Without this, bandwidth is O(players^2) and the server dies at 50 players. - Mass mechanics: speed scales inversely with mass (roughly mass^-0.44), you may eat a cell at least 1.25x smaller by area, and mass slowly decays so leaders cannot idle at the top. - Split on space into two halves with a launch impulse and a merge cooldown; eject mass on W. Cap cells per player at 16. - Viruses that split a large cell that touches them, and a spatial hash on the server for collision so the tick stays under 10ms with 200 entities. - Client: smooth camera zoom by total mass, a leaderboard, a minimap, and name rendering scaled to cell size. Definition of done: two browser tabs on different networks see each other move smoothly, and the tick loop stays under 10ms with 100 bots.
- Servers that hold hundreds of concurrent players per room without melting
- Netcode that survives 150ms of latency — interpolation, prediction, reconciliation
- Anti-cheat, which for a browser multiplayer game is a permanent war
- The critical mass of players that makes a .io game fun at all
Render remote entities 100ms in the past
Everything else in a .io game is negotiable; drawing other players slightly in the past is the single trick that turns a 10Hz packet stream into movement people call smooth. Build it once against a fake network with sliders and you will spot its absence instantly in every laggy prototype you touch afterwards.
ScopeAn evening— build just this, not the game
Build a networked-movement demonstrator in a single self-contained HTML file. Canvas 2D, no build step, no dependencies, and no real network. - A simulation object ticks at 8Hz and steers 30 dots around the canvas. No render code may read it directly — this is the whole discipline of the exercise. - A fake transport delivers timestamped snapshots to the renderer with sliders for one-way latency (0-300ms), jitter (0-100ms) and packet loss (0-20%). Packets may arrive out of order; the receiver drops stale ones. - The renderer keeps a short snapshot buffer per entity and draws each one at (now minus interpolationDelay), finding the two snapshots straddling that time and lerping between them. Delay is a slider, default 100ms. - Three modes on a key: latest snapshot only, extrapolated dead reckoning, and buffered interpolation. - Draw true simulation positions as faint outlines behind everything. Definition of done: at 200ms latency with 50ms jitter, mode one visibly stutters, mode three is smooth, and the smooth dots trail their outlines by a constant distance.
Not a clone — Agar.io re-themed and cut down to something you can finish. The angle is the important reel: it is what turns a project into a weekend. 24,360 ways to land.
Once Turn Order
Agar.io, but turn-based instead of real-time, set in a fairy tale gone wrong. Rendered in comic-book halftone.
Build a browser game called "Once Turn Order". The pitch in one line: a multiplayer in the spirit of Agar.io, but turn-based instead of real-time, set in a fairy tale gone wrong. WHAT THIS IS Take the SHAPE of Agar.io — its core loop, and whatever makes that loop good — and rebuild it as your own game in a different world at a smaller scope. Use your own names, art and audio, which you want anyway: a reskin of somebody else's game is less interesting than a new one that works the same way. THE ANGLE — this is the important constraint, honour it above everything else Turn-based instead of real-time. Time only advances when the player acts. Removes every timing, netcode and animation-blending problem and turns reflexes into decisions. This is what makes the project finishable. If a decision would push the scope back towards the original's, take the smaller option every time. THE THEME A fairy tale gone wrong. Rules of stories treated as physics — deals, thirds, true names — and a moral that costs something. The theme is not a coat of paint. Let it change what the mechanics mean — a reload, a health pack and a locked door should all be things that make sense in this world and nowhere else. LOOK Comic-book halftone. Bold ink, Ben-Day dots, speed lines on hits, and panel-border flashes on big moments. REQUIREMENTS - Runs in a browser with no build step. Canvas 2D unless the angle genuinely requires 3D, in which case three.js. - Fixed-timestep update loop with interpolated rendering, so it behaves the same at 60Hz and 144Hz. - Every tuning constant in one CONFIG object at the top, exposed as live sliders in a debug panel. You will find the feel by dragging those, not by prompting. - All content — levels, entities, balance numbers — in JSON or plain data files, never inline in the logic. - Audio generated with the Web Audio API rather than asset files. - Respect prefers-reduced-motion: keep the fades, drop the shake and the parallax. BUILD ORDER 1. The core loop with placeholder rectangles, at the reduced scope the angle demands. No theme, no art, no audio. Make it fun as rectangles first. 2. The angle's consequences. Cutting to bots, or to turn-based, or to one level changes the design rather than just shrinking it — find out how and rewrite step 1. 3. The theme, as content and data. 4. The look, applied last as a rendering layer over a game that already works. Start by writing a one-page plan: the core loop, what the angle removes and what that frees you to do properly, and what you are deliberately leaving out. Wait for me to approve it before writing code.
- agar.io-clone — full open-source client and server
- Gabriel Gambetta on client-side prediction — read this first
Half the time one of these already does what you wanted, and the other half it saves you a week of solving a problem someone documented in 1997.
One count per game. No account — it is tied to a salted hash of your IP, which is not stored in a form anyone can reverse. Every build adds 1 team-years to the counter on the homepage.
Then try these
Questions
How hard is Agar.io to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Agar.io is BRUTAL (5 of 5). The hard part is not game design at all. Interpolation, prediction and area-of-interest culling are three separate systems an agent will skip unless named, and even with all three the game is still two hundred strangers you do not have. Reckon on a weekend to something you can actually play — not to something that matches the 1 team-years Matheus Valadares spent.
What makes Agar.io hard to rebuild?
Interpolation, prediction and area-of-interest culling are three separate systems an agent will skip unless named, and even with all three the game is still two hundred strangers you do not have. That is why it sits at BRUTAL rather than a tier either side of it. If you want the idea without the project, the transferable part is render remote entities 100ms in the past — an evening of work.
How long does it take to build a Agar.io clone?
Wrong question, and it is worth saying why. Nobody rebuilds Agar.io — the original took Matheus Valadares on the order of 1 team-years, released in 2015 on Browser. What you can do is reach something playable and genuinely yours in about a weekend, and then keep going for as long as it stays interesting. Any figure that claims otherwise is measuring a prototype and calling it a game.
What do I lose by building my own Agar.io?
Servers that hold hundreds of concurrent players per room without melting. Netcode that survives 150ms of latency — interpolation, prediction, reconciliation. Anti-cheat, which for a browser multiplayer game is a permanent war. Those are the parts a prompt will not hand you.
Which AI coding agent should I use to build it?
Any of Claude Code, Codex or Cursor will handle this prompt. Paste it as your first message, let the agent scaffold the project, then iterate on feel — the second, third and tenth prompts are where a game actually gets good. Work in an empty folder or a fresh git branch so you can throw it away cheaply.
One email when new games go on the list. No other reason to email you, ever.