![\"Grass](\"https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/blog/vibegame/grass_cutting_game.gif\")
People are trying to vibe code games. And it kind of works, at first. However, as the project grows, things begin to fall apart. Why? And what can we do about it?
\nI'll talk about the problem, how I fixed it, and where to go from here.
\nFirst, what is vibe coding? It's originally coined by Andrej Karpathy in a viral tweet where it's defined as where you "fully give in to the vibes, embrace exponentials and forget the code even exists".
\nHowever, since then, it's used descriptively to mean a lot of different things, anywhere from just "using AI when coding" to "not thinking about the code at all". In this blog post, I'll define it as: using AI as a high-level programming language to build something. Like other programming languages, this benefits from understanding what's going on under the hood, but doesn't necessarily require it.
\nWith this interpretation, you could make a game without understanding code, though knowing the fundamentals still helps.
\nEarlier I mentioned that "as the project grows, things begin to fall apart". This is because there is evidence that as the context window fills up, model performance begins to degrade. This is especially true for game development, where the context can grow very large, very quickly.
\nTo address this issue, there are many personal ad-hoc solutions, such as writing LLM-specific context directly in the project files, or more comprehensive solutions like Claude Code Development Kit for large-scale context management.
\nI couldn't find a lightweight, accessible solution, which doesn't rely on significant domain knowledge. So I made one: 🧅 Shallot, a simple, lightweight, unopinionated context management system for Claude Code. It relies on two basic commands:
\n/peel [prompt] to load context at the beginning of a conversation/nourish to update context at the end of a conversationAnecdotally, this works well. However, it works best when the project stays lean and well-organized, so all relevant context can easily fit in the model's context window. While Claude Code is used here, the same principles generalize to other models.
\nBeyond context management tools, platform choice is critical. The platform should ideally naturally keep projects lean through high-level abstractions, while also being something AI models understand well. So, what existing platforms are best suited for vibe coding?
\nI initially tried 3 different approaches to vibe coding games: Roblox MCP, Unity MCP, and web. For each, I tried to build a simple incremental game inspired by Grass Cutting Incremental, using Claude Code for each.
\nHere's how it went:
\nThe official MCP server from Roblox. This allows AI to interact with Roblox Studio by sending commands to run code.
\nPros:
\nCons:
\nRoblox provides an excellent layer of abstraction for keeping the codebase lean and manageable, which is perfect for vibe coding. However, the walled garden and lack of context makes it infeasible for vibe coding, unless it's in-house at Roblox.
\nThe unofficial MCP server for Unity. This allows AI to interact with the Unity Editor: reading the console, managing assets, and validating scripts.
\nPros:
\nCons:
\nUnity is a powerful engine with a lot of capabilities. However, the complexity and variability of the engine makes it difficult for AI to consistently produce good results without significant user domain knowledge.
\nThe open web platform, using three.js for 3D rendering, rapier for physics, and bitecs for game logic.
\nPros:
\nCons:
\nThis approach had the best AI performance by far, likely due to the vast amount of web development data available during training. However, the low-level nature of the libraries meant that I had to essentially build a game engine before I could build the game itself. This allows us to work at a much higher level of abstraction, like we did with Roblox.
\nAlthough it required building an engine first, this approach was the only one that produced a fun result without heavy domain knowledge.
\n| Platform | \nAI Performance | \nAbstraction Level | \nContext Management | \nOpen Source | \n
|---|---|---|---|---|
| Roblox | \n⭐⭐⭐ | \n⭐⭐⭐⭐⭐ | \n⭐ | \n❌ | \n
| Unity | \n⭐ | \n⭐⭐ | \n⭐⭐⭐ | \n❌ | \n
| Web | \n⭐⭐⭐⭐⭐ | \n⭐ | \n⭐⭐⭐⭐⭐ | \n✅ | \n
After these experiments, I had a clear picture: the web stack had excellent AI performance but was too low-level, while Roblox had perfect abstraction but lacked openness and context management.
\nSo, what about combining the best of both?
\nIntroducing VibeGame, a high-level declarative game engine built on top of three.js, rapier, and bitecs, designed specifically for AI-assisted game development.
\nThere were three key decisions that went into the design of VibeGame:
\nA basic game looks like this:
\n\n <!-- Ground -->\n \n\n <!-- Ball -->\n \n\n\n\n\n\n ;\n GAME.;\n\nSee it in action in this JSFiddle or the Live Demo.
\nThis will create a simple scene with a ground plane and a falling ball. The player, camera, and lighting are created automatically. All of this is modular and can be replaced. Arbitrary custom components and systems can be added as needed.
\nThis comes bundled with an llms.txt file containing documentation about the engine, designed specifically for AI, to be included in its system prompt or initial context.
\nYes.
\nWell, kind of.
\nHere's the game I built to test building a simple incremental grass collection game using VibeGame and Claude Code. It worked very well, requiring minimal domain knowledge for implementing the core game mechanics.
\n
However, there are still some major caveats:
\nSo, with a definition of vibe coding that is the one-shot "make me a game" approach, it doesn't work. However, with the definition of treating vibe coding like a high-level programming language, it works very well, but requires users to understand the engine's capabilities and limitations.
\nTo try it immediately, I built a demo where you can develop a game directly in the browser using VibeGame with Qwen3-Next-80B-A3B-Instruct: Live Demo on Hugging Face.
\nYou can also test it locally with a frontier model like Claude Code:
\n\n\nThen, paste all the contents of the included llms.txt to CLAUDE.md, providing full documentation about the engine for the AI to reference (or point your own context management system to it). This works with other models as well.
The engine is currently very barebones and only supports very basic mechanics (unless writing it from scratch). However, initial results are promising.
\nNext steps would be:
\nIt's also worth exploring how vibe coding games could harness more proven engines. For example, building a high-level sandbox game editor on top of Unity or Unreal Engine (similar to how Unreal Editor for Fortnite is built on Unreal Engine) could provide a more controlled environment for AI to work with, while leveraging the power of established engines.
\nWe're also likely to see more in-house solutions from major players.
\nFollow me to keep up with what's going on in the space!
\nLinks:
\n\n", "content_markdown": "## The Problem\n\nPeople are trying to vibe code games. And it kind of works, at first. However, as the project grows, things begin to fall apart. Why? And what can we do about it?\n\nI'll talk about the problem, how I fixed it, and where to go from here.\n\n## What Is \"Vibe Coding\"?\n\nFirst, what is vibe coding? It's originally coined by Andrej Karpathy in a [viral tweet](https://x.com/karpathy/status/1886192184808149383) where it's defined as where you \"fully give in to the vibes, embrace exponentials and forget the code even exists\".\n\nHowever, since then, it's used descriptively to mean a lot of different things, anywhere from just \"using AI when coding\" to \"not thinking about the code at all\". In this blog post, I'll define it as: using AI as a high-level programming language to build something. Like other programming languages, this benefits from understanding what's going on under the hood, but doesn't necessarily require it.\n\nWith this interpretation, you could make a game without understanding code, though knowing the fundamentals still helps.\n\n## Context Management\n\nEarlier I mentioned that \"as the project grows, things begin to fall apart\". This is because there is [evidence](https://huggingface.co/blog/helmet) that as the context window fills up, model performance begins to degrade. This is especially true for game development, where the context can grow very large, very quickly.\n\nTo address this issue, there are many personal ad-hoc solutions, such as writing LLM-specific context directly in the project files, or more comprehensive solutions like [Claude Code Development Kit](https://github.com/peterkrueck/Claude-Code-Development-Kit) for large-scale context management.\n\nI couldn't find a lightweight, accessible solution, which doesn't rely on significant domain knowledge. So I made one: 🧅 [Shallot](https://github.com/dylanebert/shallot), a simple, lightweight, unopinionated context management system for Claude Code. It relies on two basic commands:\n\n1. `/peel [prompt]` to load context at the beginning of a conversation\n2. `/nourish` to update context at the end of a conversation\n\nAnecdotally, this works well. However, it works best when the project stays lean and well-organized, so all relevant context can easily fit in the model's context window. While Claude Code is used here, the same principles generalize to other models.\n\nBeyond context management tools, platform choice is critical. The platform should ideally naturally keep projects lean through high-level abstractions, while also being something AI models understand well. So, what existing platforms are best suited for vibe coding?\n\n## Initial Exploration\n\nI initially tried 3 different approaches to vibe coding games: Roblox MCP, Unity MCP, and web. For each, I tried to build a simple incremental game inspired by [Grass Cutting Incremental](https://roblox-grass-cutting-incremental.fandom.com/wiki/Roblox_Grass_Cutting_Incremental_Wiki), using Claude Code for each.\n\nHere's how it went:\n\n### Attempt 1: Roblox MCP\n\nThe [official MCP server](https://github.com/Roblox/studio-rust-mcp-server) from Roblox. This allows AI to interact with Roblox Studio by sending commands to run code.\n\nPros:\n\n- Excellent level of abstraction with built-in game mechanics\n- AI could very easily understand the syntax and convert instructions to code\n\nCons:\n\n- No files, only using code to read data, which severely limits context management\n- Very limited runtime information for AI to work with\n- Proprietary walled garden\n\nRoblox provides an excellent layer of abstraction for keeping the codebase lean and manageable, which is perfect for vibe coding. However, the walled garden and lack of context makes it infeasible for vibe coding, unless it's in-house at Roblox.\n\n### Attempt 2: Unity MCP\n\nThe [unofficial MCP server](https://github.com/CoplayDev/unity-mcp) for Unity. This allows AI to interact with the Unity Editor: reading the console, managing assets, and validating scripts.\n\nPros:\n\n- Full file system access\n\nCons:\n\n- There are many ways to do everything in Unity, changing frequently across versions, causing AI to get confused\n- Requires significant domain knowledge to tell the AI *how* to do things, rather than *what* to do\n- AI performance was inconsistent and unreliable\n- Proprietary engine (though much more transparent than Roblox)\n\nUnity is a powerful engine with a lot of capabilities. However, the complexity and variability of the engine makes it difficult for AI to consistently produce good results without significant user domain knowledge.\n\n### Attempt 3: Web Stack\n\nThe open web platform, using [three.js](https://threejs.org/) for 3D rendering, [rapier](https://rapier.rs/) for physics, and [bitecs](https://github.com/NateTheGreatt/bitECS) for game logic.\n\nPros:\n\n- Far superior AI proficiency compared to game engines, likely due to massive training data\n- Full file system access\n- Fully open source stack with complete control/transparency\n\nCons:\n\n- Relatively low level libraries, requiring essentially building the engine before building the game\n- Lack of ecosystem for high-quality 3D games; web tends toward 2D games and simple 3D experiences\n\nThis approach had the best AI performance by far, likely due to the vast amount of web development data available during training. However, the low-level nature of the libraries meant that I had to essentially build a game engine before I could build the game itself. This allows us to work at a much higher level of abstraction, like we did with Roblox.\n\nAlthough it required building an engine first, this approach was the only one that produced a fun result without heavy domain knowledge.\n\n### Comparison Summary\n\n| Platform | AI Performance | Abstraction Level | Context Management | Open Source |\n| -------- | -------------- | ----------------- | ------------------ | ----------- |\n| Roblox | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ | ❌ |\n| Unity | ⭐ | ⭐⭐ | ⭐⭐⭐ | ❌ |\n| Web | ⭐⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐⭐⭐ | ✅ |\n\n## The Solution: VibeGame\n\nAfter these experiments, I had a clear picture: the web stack had excellent AI performance but was too low-level, while Roblox had perfect abstraction but lacked openness and context management.\n\nSo, what about combining the best of both?\n\nIntroducing [VibeGame](https://github.com/dylanebert/vibegame), a high-level declarative game engine built on top of three.js, rapier, and bitecs, designed specifically for AI-assisted game development.\n\n### Design Philosophy\n\nThere were three key decisions that went into the design of VibeGame:\n\n1. **Abstraction:** A high-level abstraction with built-in features like physics, rendering, and common game mechanics, keeping the codebase lean and manageable. This takes inspiration from popular high-level sandbox games/game \"engines\" like Roblox, Fortnite UEFN, and Minecraft.\n2. **Syntax:** A declarative XML-like syntax for defining game objects and their properties, making it easy for AI to understand and generate code. This is similar to HTML/CSS, which AI models are already proficient in.\n3. **Architecture:** An Entity-Component-System (ECS) architecture for scalability and flexibility. ECS separates data (components) from behavior (systems), encouraging the project to stay modular and organized as it grows, conducive to vibe coding and context management.\n\nA basic game looks like this:\n\n```html\n