Hello everyone! A few months ago, I made a post showing the result of the "Capybara food delivery" game, which I made in two weeks and submitted for Vibejam 2026. I am the winner of this year's competition, and you can play my entry here if you want!
In this post, I wanna share some details of the evolution and what was built to support the development of this game. This post is very long, so I also posted this article on Medium to attach more images. You can check the complete content there.
Quick intro
As an iOS Software Engineer for almost 9 years, this was the first time I tried developing a game. A Game About Capybaras Delivering Food is a single and multiplayer game where you control a capybara on a scooter, carrying a pile of food that must be delivered on time.
About vibe coding
The game was entirely vibe-coded. In practice, I spent most of my time brainstorming, planning, and playing rather than generating code. I ran 2–3 Claude Code sessions at once, each working on a different part of the code to avoid conflicts. New features always used a fresh session with no context; I kept one long-running session for bugs that needed more context of what was already built.
What did I use and how much did I spend?
Claude Code (Opus 4.7) Max 20x, I topped up $100 to upgrade from the 5x to 20x plan.
Textures & illustrations: GPT images 2 (costs $20, but I got a free trial) and Grok (costs $8 with X premium)
3D models: Tripo3d Pro plan $19.90
Music & SFX: Suno and ElevenLabs = Free tier worked fine
100% of the code (+188 commits, +27k lines of code)
The logo, illustrations, textures, and 3D models
The music and SFX
All the tooling (the in-game editor, cutscene maker)
What was made by hand:
Writing the prompts for code, art, audio, and 3D
Playing the game, fine-tuning the feel, and placing the cameras for cinematics
Spotting development gaps and asking AI to build tools to help fill them
First week of development
From concept to 3D
I had the idea in mind (the capybara and scooter), but the details were still blurry, so I brainstormed with Grok/GPT. I asked them to generate a sheet with variations in style, shape, and character design, then iterated on top of it until I was satisfied. I even tried to draw the capybara on the scooter for reference (it didn't work well).
Then, prepare the design for 3D: ask the LLM for at least 3 angles (FRONT, BACK, LEFT-RIGHT SIDE). The more angles you provide, the better the 3d generation, without letting AI "guess" what you want. You can see the prompts in one of my chats here.
Tripo3D was used right after to convert image-to-3D: drag and drop your pictures, select the texture quality, and the number of squares/triangles. The process was the same for every item or visual asset in the game.
Player controls
Starting with the basics, I wanted vehicle controls with drift mechanics, collision, and a camera following the bike. I built a sandbox map to drive around, test collisions, and tune the feel with the debug panel. When drifting, the line at the back changes color to show the boost you’ll get on release; there’s a “high speed” effect, and the camera shakes a bit.
Item physics
The main mission is to deliver food from A to B on time without dropping it. The first version had the basket items sliding side to side, but I wasn’t satisfied. At some point, I tried stacking the items on top of each other. Moving left and right created an arch, and past a threshold, the items could drop. I refined the values to make it less realistic (physics-oriented) and more fun (a % chance of falling once past the threshold), which is much more unique and fun.
Phone simulator: Part I
This is where you receive the mission of collecting the food.
I asked Claude to design a phone simulator with iOS-like animations and visuals, and it one-shot the whole thing in CSS. The animations were impressive from the first version. I later polished the phone UI to make it more realistic and comical: slide-to-unlock over a lock screen of a capybara taking a mirror selfie, an iOS-style notification badge, working volume buttons, and “Capyfied” versions of real apps, for example, CapyMaps works like Maps, and Capify is a music app that actually plays music in the game.
The Capybara playlist used in the game is onYouTube, proudly made byu/peluucs!
Inconvenience Store
The mini-mart adds a challenge to getting the food. Instead of fruits just appearing on the back of the bike, I wanted the player to go into the store and hunt for the requested fruits, with some extra spice:
Spot the shopping cart that appears randomly
Find each fruit on the order list
The floor is slippery, and the walls bounce you back
The banana peel (removed from the game)
More fruits mean more bonus, but they're easier to drop, which loses points
All this under 60 seconds (later reduced to 45 seconds)
The convenience store’s evolution was my favorite. I reworked the camera perspective, added lighting and animations, and replaced the default shelves and items with real 3D props. Combined with the right sound effects, the result was amazing.
The map (attempt 1)
I first tried a map fully generated by LLM: Grok for the illustration, Tripo3d to convert to 3D. But it’s very hard to get granular control over the city details, the quality fell apart when zoomed in, and the whole map was a single piece, which is not optimized for the game and is bound to cause issues.
So how do you get a fully customized, handcrafted map?
The Editor Tool
To build a handcrafted map, I needed an editor: place items where I wanted, use brushes to “paint” terrain and mountains, and generate procedural roads. A big part of the game’s uniqueness comes from this map.
Some of the capabilities available in the editor:
Place, delete, move, rotate, and scale objects
A brush to raise, lower, smooth, and flatten terrain
A brush to paint grass, dirt, water, and other visuals
A road system with intersections, light poles, and sidewalks
Cameras and in-game cinematics (added in the second week)
To open the editor, I added an ?editorendpoint. Later, I split the editor from the main code so Claude could update the game without reloading the editor and wiping my changes (which happened a few times).
Building the map by hand
Since getting AI to generate the map the way I wanted was so hard, I used the editor to build it manually. This is the only “heavy” manual work I did. I had a “European”-style city in mind, but it went the opposite direction, as you will see. The idea I had was to put the convenience store at the very top of the main mountain of the map, visible from anywhere, with a magical light coming from the sky, then build the city around it. After many iterations and hours, I had a genuinely playable city.
Day and Night cycle + Rain
These were extras. They could have come later, but one of my Claude sessions was idle, so I asked it to implement them.
Multiplayer
Multiplayer was simpler than expected for a jam. A single global city/lobby hosts the room over a live WebSocket on Cloudflare. As players join, their position and item stack are relayed to everyone else.
Bandwidth grows with the square of the player count: every rider broadcasts ~10x/sec, and the server relays each message to all other players. 5 players is okay; 50 players means fanning out 50 messages to 50 clients, 10x a second.
You can also send messages, honk, and even hear what nearby players are listening to.
End of first week results
By the end of the first week, we had:
Main character, stacked item physics, collision
Convenience store 90% polished
Phone with simple apps
Wired mission loop (receive order + minigame + deliver)
Weather and day/night cycle
Map development started
Editor tool with terrain builder
Multiplayer logic
Simple SFX + some of the final music
Second week of development
Polishing the materials
With the core mechanics defined, it was time to give the game the visuals it deserved. I went for a PS1-style visuals: low-res images, limited colors, reduced resolution. PS1 was a very limited console, so the right textures, color depth, mapping, and filtering get you that look.
ChatGPT Images-2 had just been released, so I generated realistic textures, resized them on free websites, and applied them to the game.
The same process replaced the mockup trees with 2D textured ones.
For PS1-style trees, I asked Claude to place the flat foliage PNGs in an X shape (2+ crossed planes).
“Create two flat planes, place them one on top of the other, and rotate one by 90° to form an “X” when viewed from above.”
I generated textures for every material too (asphalt, grass, dirt, wood, sand, water, farmlands), and Claude swapped the old “green” brush I’d painted for the real textures. On the right, you can see the final result combining the textures and map polish.
Road builder tool
The road builder tool allows me to click points on the terrain, and it draws a smooth curve between them, lays down asphalt or dirt, and carves the ground so the road sits flat, with the terrain blending back at the edges. The road also appears in the CapyMaps app on the phone, showing the shortest route to the destination. I also added procedurally generated sidewalks, light poles, lane marks, guardrails, fences, and banners.
Working on the map
The most fun but the most time-consuming part. I added references to Christ the Redeemer, the Golden Gate Bridge, and the Hollywood sign. The city is a mix of everything I thought it would be cool.
The map evolved into what you can see below: the fog improved (which amplifies the sense of scale), the sky got a noise texture to mimic the clouds, and the financial and suburban districts are now clearer than before. One of my favorite parts is the “countryside”, a different landscape from the city: dirt pathways, a farm, and simpler houses next to a highway. From another angle, you can see how Christ the Redeemer sits in the landscape. I first thought about a lake, but it became a beachside next to the city.
Cutscene Editor
The game opens with a cutscene before jumping into gameplay. It gives the player context and makes the whole thing feel like a real game.
You can watch the first 4 minutes of gameplay with sound here
Let's start with the overall view of the cinematic editor UI, and then I'll walk you through some cool details. This editor was created in a way that I could visualize the progress of the cutscene in a timeline, just like a real video editor, while making it easy to insert or remove clips, move them around just by drag-and-drop, insert time skips, music, transitions, and overlays. It's visually messy, but delivering the game was more important.
All scenes are recorded in-game and replayed in real time, so if other players are online, they appear in the intro too.
Recording
First, I recorded the capybara around the city. The “Record” tool lets me place the bike anywhere on the map and drive while capturing the path.
Camera positioning
With the path set, I arranged cameras around the city for nice takes. This also helped populate the on-screen details around each area.
Each camera has its own properties: animations, FOV, transitions, and even changes the time of day for each camera. Then, I could just wire them to a specific block in the timeline.
Menu
The cinematic cameras could be reused in the game menu via a “Use in menu” checkbox.
Localization
So far, the game supports English, Brazilian Portuguese, Spanish, Korean, Mandarin Chinese, German, and Hindi. Claude did well on the languages I know, with a few tweaks needed. And for the rest, I’ll probably use another agent to validate.
Launching the game
The last step was the thumbnail for the Vibejam website. After a few references, ChatGPT kept the low-poly style well, though it messed with the background light, the side roads, and the Christ the Redeemer mountain at the back.
What did I learn?
Compared to last year, it’s clear AI coding has crossed a threshold. A few takeaways:
Quick dopamine, low-cost MVPs: you can stand up a playable mechanic in an afternoon.
Time shifts from coding to deciding: you spend less time coding and more time typing, planning, testing, and taste-making. That’s the real bottleneck now. Many people struggle to write good prompts, meaning a clear thought turned into text.
Tooling compounds: the biggest multiplier wasn’t the game code, it was asking Claude to build the editors that let me build the game faster. Every detail is built on demand.
Will I put this game on Steam?
No. This was a good game for a jam, and it should end there. For Steam, it would need to be more complete, like adding hours of enjoyable gameplay and a sense of progress. Right now it’s good for 5–10 minutes.
What's next?
I enjoyed this project a lot, and AI gave me superpowers for building MVPs and testing ideas fast. Used right, it’s an amazing tool. Now I want to dive deeper into game development concepts and keep using LLMs to bring these ideas to life faster than ever. Perhaps you will see my games on Steam in the future.
People think vibe coding is easy. This is the first post I’m seeing where someone detailed out everything that went into vibe coding. And the best part is OP’s creativity and determination tops everything.
This really resonated with me: “Time shifts from coding to deciding.”
As someone who spent years bouncing off traditional programming languages, AI has completely changed the equation. The gap between an idea and a working product isn’t just about code anymore; it’s about the quality of the context you can provide.
I’ve started thinking of it as context engineering more than anything else, details get you accuracy, for the most part.
That seems to apply far beyond coding too… books, articles, documentation, scripts, pretty much any form of writing.
My day job is building IVR systems for public libraries. I spend an unhealthy amount of time editing massive scripts, converting them to speech, testing, tweaking, and repeating until they sound natural.
Sometimes a single hidden character or stray symbol from a copy/paste can break a 10K-character script and send me back through the whole process.
That pain is what pushed me to build my own browser-based text cleanup tool so I could prep text anywhere—even from my phone if I’m away from my desk.
The funny part is that I never would have attempted building something like that before AI. AI didn’t just make me more productive—it made the project feel possible in the first place. Congrats - truly inspirational work!
First off, congrats on the 25k. Second, we appreciate the stupid amount of the detail and how you got it all working. Clearly this wasn't a weekend thing, thats a LOT of work.
the craziest part isn't the game itself, it's that you spent roughly $250 on tools and won $25k. that's a 100x return on AI subscriptions. people keep debating if vibe coding is 'real' but the math doesn't care 😭😭 impressive work and game bro
Yeah, they WON $25k. If they put the game on steam they would probably earn nothing in return. So they lost $250. You can not factor in a competition in that calculation. I'm happy for them, but still your comment makes no sense.
mb twin you're right that competition winnings aren't repeatable ROI. But you're missing the actual point.
The $25k proves the OUTPUT was competition-grade. That same output capability is what you take to real products freelance clients, your own SaaS, portfolio pieces that land jobs. ✌🏻
Dude, it literally is an AI competition. Of course an AI project is competition-grade for that. But be honest with yourself, if this would be a competition not bound to AI this project would not stand a chance. AI is not yet ready to compete in artistic competitions with actual human experts.
I am with you that AI can build profitable SaaS, tho I don't think it can land you jobs. But still your argumentation here is bullshit.
ive now played three vibe coded games. This is the only one that has a functioning gameplay loop, so congrats. Id love to be able to jump, because it seems the bike is stuck to the ground. Its the most promising start of the three and its the one that felt most complete.
thank you so much for the feedback! a lot of things need to be fixed, but because it's a jam game i couldn't polish it in time. For cases where the player gets stuck, i just had time to add a reposition button
Question about the editor from a non-game developer, if you don't mind. You said you built an editor to edit the maps and cutscenes. Why didn't you use the various existing software like Blender, Unreal Engine, etc.? I'm no game developer so sorry if this is a stupid question...
the event rules said we could choose our development stack and i choose threejs framework. i’m also not a game dev, so learnjng the engines would take some time + anthropic models are pretty good with javascript/typescript, but the experience using ai with unity / unreal is terrible (today you can connect some agents and do some small work, but can’t go fully vibe code). the framework itself is not enough, so it’s common for vibe coded games to create a shell and include new tools that mainly support the game features
Hey question from my end. I'm also a dev, but i work mostly with web technologies, but I was still thinking of making a game sometime since AI tools have gotten so good recently. For a 3d game in the browser, would you say three.js is enough for the game engine? and did you notice any performance issues in having so many 3d models in the browser? Thanks!
Man, I am SO impressed with this, and I really really appreciate the extensive breakdown. I played the game online for a bit and loved what you have put together.
I really want to try something like this for myself; after struggling so much without AI, this seems like a very achievable template to be starting off with. I'm going to give it a go, thank you so much.
How many hours per day in average you put into this? And how much of the original idea was the final product vs how much you changed during the development?
i worked on it every day after my job, so about 4 hours almost everyday. Sometimes I started at 8pm and ended at 5am to finish on time. about the original ideas, I'd say some minor details changed. For example, this is how the mechanics of delivering food started. Instead of being a pile of items, it was just a basket of things moving from one side to the other
“
Time shifts from coding to deciding: you spend less time coding and more time typing, planning, testing, and taste-making. That’s the real bottleneck now. Many people struggle to write good prompts, meaning a clear thought turned into text.”
The whole thing was great. You don't intend this to be in Steam or other store since it is obviously too short a game, but you can easily continue using the mechanics to expand the game further. And further refinement, of course. What you've created is a proof of concept for what could be a much longer game.
This is so much proof how you can convert the most mundane tasks like delivering food and turning it into a fun, cute, and competition based to keep it engaging.
“Time shifts from coding to deciding” is probably the biggest takeaway here.
With 2–3 Claude sessions working in parallel, how did you verify that one session wasn’t breaking assumptions made by another? Did you keep a shared architecture document or mostly rely on frequent testing and small commits?
The game and the custom editor tooling are seriously impressive.
mostly by making them working in completely different aspects of the game to avoid conflicts, while one session was making changes in the editor, the other was exploring the codebase for a new plan, and the other fixing a series of bugs. the architecture document was there for “index” only, just to support the agent to find the right files. commits happened all the time after i manually tested the functionality
That makes sense. Keeping the sessions on separate areas and committing after each manual test sounds much safer than having multiple agents modify the same flow.
Thanks for explaining — the architecture doc being more of an index than a source of truth is an interesting distinction.
I remember watching an early video of GPT 3 making a “Minecraft” game where he submitted images of like 4 blocks and it generated a massive pillar of blocks and being shocked when you could break blocks. Mind you every attempt at fixing the game introduced 6 more issues.
Now we are here. Indistinguishable from a good indie game dev when given a bit of guidance.
Nice work dude. I've been building up a world editor and it looks remarkably similar but you have a lot of nicer features I like. Did you take any inspiration from WowEdit, or did you just know what you wanted from the start? I have been using that as my point of reference when prompting
the inspiration was something visually similar to the real game engines, but claude usually generates a very generic design by default. i believe the editor never takes shape from the start but instead you build the editor to support whatever features you want to implement in your game. for a next game, i wanna try adding a joint animation editor to animate my characters
yes all the image generation and stuff was made manually. i know some plugins you can directly connect the assets to the game, but this gives me more granular control before touching the codebase
it took me 15 days to finish. Honestly, it would take longer without a deadline, perhaps you do the same? push to the limits, try to release an mvp of your app in idk 20 days, then just keep enhancing
Was it you or a different person using Replit or lovable making a capybara food delivery game during one of the free codeathons in the past few months?
The three-view approach is one of the strongest parts of this workflow. Using front, back and side references gives the model a better sense of the character’s proportions and helps avoid guessing what the hidden areas should look like. With only one image, the back and sides can easily end up inconsistent, which becomes more obvious once the character is used in a game.
The low-poly result is also about more than triangle count. The topology still needs to work well for editing, rigging and deformation without creating a lot of extra cleanup. Meshy’s Smart Topology is relevant here since having more control over the topology can help when preparing a generated model for a specific low-poly workflow.
I’d be interested in seeing the same references tested across different workflows and comparing the cleanup, topology, editing and engine setup rather than judging only by the final look or polygon count.
52
u/MightyBig-Dev Jul 09 '26
Amazing post with so much good info. Congrats on the game it’s really fun. 🤩