A game engine should expose game concepts such as character, animated, and double jump instead of making users assemble low-level components first.
2
Nereu builds an assistant's context from the nearby scene, using level of detail so distant objects contribute less information and unimportant objects such as grass can be ignored.
3
The assistant is meant to help people get unstuck while they make and learn games, rather than generate a finished game in one prompt.
Summary
Arturo Nunez argues that conventional game engines force developers to think in engine vocabulary before they can express game ideas. Controlling a character may require a mesh, renderer, animator, rigid body, collider, audio source, and movement logic, even though much of that setup is repeated across games. Nereu treats everything as an asset and uses tags such as character, animated, vehicle, and double jump to describe intent. Systems query those tags and apply the built-in behavior. An assistant called Bibi uses the scene, the available asset types, and the user's description of the game to add or remove tags. Nunez explains that context assembly borrows level of detail from rendering. Nearby objects receive detailed tag values, distant objects receive only basic information, and irrelevant objects can be omitted. He wants the assistant to help users keep making progress and learn the language of game design, rather than one-shot games nobody plays.
Game creation can start with familiar descriptions instead of code
Nunez demonstrates adding a robot, making it a controllable character, and telling the assistant to move it with WASD and animate it. He then describes buildings, rain, and a camera that follows the character. The user does not need to import models or write code for these steps. Nunez says the useful language is already familiar to people who play games, such as describing movement or saying what should happen when a coin is collected. He compares the process to playing with toys or Legos, where the goal is to explore an idea without first mastering the tool.
Traditional game development demands many different skills
Nunez says making a game requires programming, 3D modeling, rendering, music, animation, camera composition, and game design. A solo developer or small team has to cover several of these areas, while the game also has to be fun for players. After almost ten years at Unity, he saw people struggle with the same problems repeatedly. He became dissatisfied with developers spending their time reinventing the same setup, especially when many people make games as a creative outlet rather than as a commercial product. He argues that enjoying the process matters alongside releasing a game.
Engine vocabulary makes coding agents repeat the same work
Nunez says powerful engines such as Unreal and Unity still do not compose well with powerful language models and agents. The user must understand the vocabulary of the engine or code to ask for something useful. When someone asks for a camera that follows a character, an LLM may reinvent the implementation each time even though the result is a common behavior. Nunez says the context is centered on the engine instead of the game design. His proposed change is to flip that relationship so users can describe the game behavior directly.
In a conventional engine, a controllable character needs a mesh, renderer, animator, rigid body, collider, audio source, and movement logic. Nunez calls most of this boilerplate that appears in characters across games. Nereu treats everything as an asset and lets users attach tags such as character, animated, and double jump. The engine still handles rendering and physics, while systems query the tags and apply behavior. Nunez also describes event behavior with a phrase such as increasing the score when a coin is collected. This puts game rules above the repeated component setup.
The tag system comes from entity component system ideas
Nunez connects Nereu's asset tag system to entity component system thinking and data-oriented design. Systems query all assets in the world and act on those with matching tags. A system might move every asset tagged vehicle, player, and drivable. The tags are reusable across games. A building normally does not move because it lacks those tags, but nothing prevents a user from adding vehicle and drivable to the building and placing it in a Mario Kart style game. The assistant knows the available tags and tools, then applies them to the asset described in the user's request.
The assistant's prompt combines the scene with game-specific context
Bibi builds a prompt from the current scene and from extra information about the game. That extra context can include the types of assets in use, such as robots or medieval objects, and the user's description of the kind of game they want to make. The agent performs calls that add or remove tags. Nunez says the systems and tags are built into the engine, which has no scripting system by design. The engine runs JavaScript in the browser for people who want to extend it, but most users should not need to write scripts. He describes composing genres, moods, lighting, and post-processing into tags and systems as the difficult design work.
Context assembly uses rendering-style level of detail
Nunez says sending an entire scene to an LLM makes the context grow quickly. A scene may contain around 100 objects, many of them grass that does not matter to the current edit. He borrows level of detail from rendering. A nearby object gets detailed information, including its tag values and settings. A distant object can be reduced to a type and a position. As the user moves around and changes the scene, the assistant receives more information about the newly relevant objects. This keeps context focused on what the user is editing instead of describing every object equally.
The assistant should help users continue making the game
Nunez says Bibi is intended to get people unstuck rather than one-shot games that nobody will play. Users can ask how to make a car move, then continue shaping the game themselves. He wants them to learn the language of game design, even if learning programming was not the original goal. He contrasts this approach with world-model tools that generate a game or environment on the fly. He expects those tools to become a different medium because rendering at 60 frames per second and 4K resolution, along with simulating physics, remains difficult for a world model.
"Nothing prevents you from adding the vehicle and drivable tag to your building and then you have a building that you can put in a Mario Kart style of game."10:14
Who should watch
You are building tools for game development and want an interface that exposes game behavior before engine implementation details.
You are evaluating coding agents for creative workflows and need to understand why a model may repeatedly rebuild common systems.
You are working on scene-aware AI tools and want a practical example of reducing model context with rendering-style level of detail.
