Everyone is talking about models: which one is smartest, which one is fastest, which one to use for what. For anyone building a game, those questions all come down to one: what gets this game built best?
At Tesana, that’s the only question we care about. Our goal is the best possible game build from start to finish. The model is a small part of the system that gets you there. It isn’t the system.
Models are moving targets. New ones come out almost every week, and each has its own strengths and weaknesses. One animates characters well. Another handles game logic better. Some need exact, step-by-step instructions, while others do their best work from a loose creative brief. Some only perform well with image references. How each one succeeds and fails keeps changing daily.
So for the past few months, we’ve been building the Tesana Quality Index (TQI), our benchmark for agentic game building. In one eval, a frontier model built a game mechanic 15% faster than the alternative, took 30% fewer turns, and scored 6–8% higher on graphics. That made it the clear choice for that type of game and that type of task, at that point in time.
Every new model now goes through TQI. That covers game logic, assets, worldbuilding, sound design and UI. Whichever model does the job best gets the work.
That’s why we’re removing the model picker. If the choice of model decides whether your game plays well, you shouldn’t have to get it right before your first prompt. That choice is our job.
As part of this, we’re retiring our two previous engines, Muranyi and Atomos. Everything we learned building them is now folded into Tesana, so there’s one system to build with instead of engines to choose between.
Model independence: the right model for each part of your game
Removing the picker doesn’t mean we treat models as interchangeable. It means the opposite.
Being model-indifferent would mean swapping one model for another behind the same prompt and hoping the game still works. Being model-independent means we tune the instructions, tools and context for each model, so each one is set up to do the part of a game it’s best at.
Games make this harder than most software. A single build touches very different kinds of work:
- Game logic: movement, physics, collision, combat, progression, win and lose states
- Assets: characters, animation, props and textures that match a visual style
- Worldbuilding: terrain, lighting, layout and level structure
- Sound design: music, effects and audio cues tied to gameplay events
- UI: menus, HUDs, inventories and controls that feel right on web and mobile
A model that writes clean combat code can still produce characters that don’t match your reference art. A model that nails a visual style can still break a jump arc. Our team studies where each model is strong, where it fails, and what it needs to be told, one type of work at a time.
The game director: orchestration is the challenge
The layer that decides which model does what is the real challenge. We call it the Director — think of it as a game Director that sits between your idea, your prompt and the models.
Instead of handing your whole game to one model, the Director breaks the build into its parts and routes each part to the model that does it best. The level layout might go to one model, the enemy AI to another, and the character sprites to a third. It adjusts each model’s instructions, tools and context along the way.
The Director also watches the build as it happens. If a model gets stuck on a physics bug, keeps rewriting code that already works, or drifts away from your art style, the Director catches it and changes course. You see one conversation and one game. Underneath, several models, tools, libraries and agents may have worked on it.
Context is everything: why swapping models mid-build makes for bad games
Being able to use any model doesn’t mean switching models all the time. Switching has a cost.
A game grows with every prompt. Over a long session, the model builds up an understanding of your game: its file structure, its mechanics, the edits you’ve asked for, the bugs it already fixed. When you hand the build to a new model, some of that is lost or compressed. The new model may re-read files, undo earlier decisions, or break a mechanic that was working.
So the Director weighs the trade-off every time. Is the gain from a better model bigger than the cost of lost context and repeated work? If yes, it switches. If not, it keeps the current model and adjusts its instructions instead. Your game should feel like it was built by one team, not a series of strangers.
If it doesn’t play, it doesn’t count: the game is the benchmark
Public leaderboards measure how models answer coding and reasoning questions. They don’t tell you whether a model can ship a platformer where the jump feels right. TQI measures the thing our users care about: the finished, playable game.
That changes what “fast” and “cheap” mean. A model can respond quickly and still be slow if it takes three times as many turns to get a working game. A cheap call gets expensive when it sends the build down the wrong path and the user has to spend credits fixing it.
So TQI scores the whole build, not a single response:
- Does it play? The game loads, controls respond, and the core loop works from start to finish.
- Does it look right? Graphics, animation and style match the prompt and any reference images.
- How much effort did it take? Time to a working build and number of turns.
- Does it hold up to edits? Follow-up prompts change what was asked without breaking what already worked.
We combine human playtesting, automated checks and model-based judges, and we test the tests too. If a judge scores two near-identical games very differently, we recalibrate the judge before we trust its results.
Your game, the whole frontier underneath
Models will keep improving, and that’s a good thing. But progress is uneven: one gets better at animation, another at game logic, and no one can predict which comes next.
That’s our problem to solve, not yours. You build the game you want. We make sure the best model for each part of it is doing the work, today and every time the landscape shifts.
— The Tesana team