VibeGame: Exploring Vibe Coding Games

Persons are attempting to vibe code games. And it type of works, at first. Nevertheless, because the project grows, things begin to collapse. Why? And what can we do about it?

I’ll talk concerning the problem, how I fixed it, and where to go from here.

What Is “Vibe Coding”?

First, what’s 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”.

Nevertheless, since then, it’s used descriptively to mean a variety of various things, anywhere from just “using AI when coding” to “not occupied with the code in any respect”. On this blog post, I’ll define it as: using AI as a high-level programming language to construct something. Like other programming languages, this advantages from understanding what is going on on under the hood, but doesn’t necessarily require it.

With this interpretation, you might make a game without understanding code, though knowing the basics still helps.

Context Management

Earlier I discussed that “because the project grows, things begin to collapse”. It is because there may be evidence that because the context window fills up, model performance begins to degrade. This is particularly true for game development, where the context can grow very large, in a short time.

To handle this issue, there are lots of personal ad-hoc solutions, similar to writing LLM-specific context directly within the project files, or more comprehensive solutions like Claude Code Development Kit for large-scale context management.

I could not find a light-weight, accessible solution, which does not depend on significant domain knowledge. So I made one: 🧅 Shallot, an easy, lightweight, unopinionated context management system for Claude Code. It relies on two basic commands:

1. /peel [prompt] to load context at first of a conversation
2. /nourish to update context at the top of a conversation

Anecdotally, this works well. Nevertheless, it really works best when the project stays lean and well-organized, so all relevant context can easily fit within the model’s context window. While Claude Code is used here, the identical principles generalize to other models.

Beyond context management tools, platform alternative 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 to vibe coding?

Initial Exploration

I initially tried 3 different approaches to vibe coding games: Roblox MCP, Unity MCP, and web. For every, I attempted to construct an easy incremental game inspired by Grass Cutting Incremental, using Claude Code for every.

Here’s the way it went:

Attempt 1: Roblox MCP

The official MCP server from Roblox. This enables AI to interact with Roblox Studio by sending commands to run code.

Pros:

• Excellent level of abstraction with built-in game mechanics
• AI could very easily understand the syntax and convert instructions to code

Cons:

• No files, only using code to read data, which severely limits context management
• Very limited runtime information for AI to work with
• Proprietary walled garden

Roblox provides a superb layer of abstraction for keeping the codebase lean and manageable, which is ideal for vibe coding. Nevertheless, the walled garden and lack of context makes it infeasible for vibe coding, unless it’s in-house at Roblox.

Attempt 2: Unity MCP

The unofficial MCP server for Unity. This enables AI to interact with the Unity Editor: reading the console, managing assets, and validating scripts.

Pros:

Cons:

• There are a lot of ways to do every part in Unity, changing regularly across versions, causing AI to get confused
• Requires significant domain knowledge to inform the AI how to do things, relatively than what to do
• AI performance was inconsistent and unreliable
• Proprietary engine (though far more transparent than Roblox)

Unity is a strong engine with a variety of capabilities. Nevertheless, the complexity and variability of the engine makes it difficult for AI to consistently produce good results without significant user domain knowledge.

Attempt 3: Web Stack

The open web platform, using three.js for 3D rendering, rapier for physics, and bitecs for game logic.

Pros:

• Far superior AI proficiency in comparison with game engines, likely as a result of massive training data
• Full file system access
• Fully open source stack with complete control/transparency

Cons:

• Relatively low level libraries, requiring essentially constructing the engine before constructing the sport
• Lack of ecosystem for high-quality 3D games; web tends toward 2D games and straightforward 3D experiences

This approach had the very best AI performance by far, likely as a result of the vast amount of web development data available during training. Nevertheless, the low-level nature of the libraries meant that I needed to essentially construct a game engine before I could construct the sport itself. This enables us to work at a much higher level of abstraction, like we did with Roblox.

Even though it required constructing an engine first, this approach was the one one which produced a fun result without heavy domain knowledge.

Comparison Summary

The Solution: VibeGame

After these experiments, I had a transparent picture: the net stack had excellent AI performance but was too low-level, while Roblox had perfect abstraction but lacked openness and context management.

So, what about combining the very best of each?

Introducing VibeGame, a high-level declarative game engine built on top of three.js, rapier, and bitecs, designed specifically for AI-assisted game development.

Design Philosophy

There have been three key decisions that went into the design of VibeGame:

1. Abstraction: A high-level abstraction with built-in features like physics, rendering, and customary 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.
2. Syntax: A declarative XML-like syntax for outlining game objects and their properties, making it easy for AI to know and generate code. This is analogous to HTML/CSS, which AI models are already proficient in.
3. Architecture: An Entity-Component-System (ECS) architecture for scalability and adaptability. ECS separates data (components) from behavior (systems), encouraging the project to remain modular and arranged because it grows, conducive to vibe coding and context management.

A basic game looks like this:

<world canvas="#game-canvas" sky="#87ceeb">
  
  <static-part pos="0 -0.5 0" shape="box" size="20 1 20" color="#90ee90">static-part>

  
  <dynamic-part pos="-2 4 -3" shape="sphere" size="1" color="#ff4500">dynamic-part>
world>

<canvas id="game-canvas">canvas>

<script type="module">
  import * as GAME from 'vibegame';
  GAME.run();
script>

See it in motion on this JSFiddle or the Live Demo.

It will create an easy scene with a ground plane and a falling ball. The player, camera, and lighting are created routinely. All of that is modular and will be replaced. Arbitrary custom components and systems will be added as needed.

This comes bundled with an llms.txt file containing documentation concerning the engine, designed specifically for AI, to be included in its system prompt or initial context.

So Does It Actually Work?

Yes.

Well, type of.

Here’s the sport I built to check constructing an easy incremental grass collection game using VibeGame and Claude Code. It worked thoroughly, requiring minimal domain knowledge for implementing the core game mechanics.

Nevertheless, there are still some major caveats:

1. It really works well for constructing what the sport engine supports, i.e. an easy platformer or game that only relies on basic physics and rendering.
2. Nevertheless, it struggles with anything more complex that won’t yet implemented within the engine, like interaction, inventory, multiplayer, combat, etc.

So, with a definition of vibe coding that’s the one-shot “make me a game” approach, it doesn’t work. Nevertheless, with the definition of treating vibe coding like a high-level programming language, it really works thoroughly, but requires users to know the engine’s capabilities and limitations.

Try It Yourself

To try it immediately, I built a demo where you possibly can develop a game directly within the browser using VibeGame with Qwen3-Next-80B-A3B-Instruct: Live Demo on Hugging Face.

You may also test it locally with a frontier model like Claude Code:

npm create vibegame@latest my-game
cd my-game
npm run dev  

Then, paste all of the contents of the included llms.txt to CLAUDE.md, providing full documentation concerning the engine for the AI to reference (or point your individual context management system to it). This works with other models as well.

What’s Next?

The engine is currently very barebones and only supports very basic mechanics (unless writing it from scratch). Nevertheless, initial results are promising.

Next steps could be:

1. Flesh out the engine with more built-in mechanics, getting closer to par with early versions of Roblox or UEFN. This includes:

• Interaction
• Inventory/items
• Multiplayer
• Skinned meshes/animations with curated database
• Audio with curated database

2. Improve the AI guidance systems, providing beginners with a greater experience. This includes:

• Clear messaging about engine capabilities/limitations
• Guided prompts for common tasks
• Many more examples and templates
• Educational resources

It is also price exploring how vibe coding games could harness more proven engines. For instance, constructing a high-level sandbox game editor on top of Unity or Unreal Engine (just like how Unreal Editor for Fortnite is built on Unreal Engine) could provide a more controlled environment for AI to work with, while leveraging the facility of established engines.

We’re also prone to see more in-house solutions from major players.

Follow me to maintain up with what is going on on within the space!

Links: