At the41 we opened a laboratory to see how a game gets made today. Out came The Fox in the Portal: an armoured fox that walks through portals. Blender for the modelling, an LLM driving Blender over MCP, and Unity to build the game. We liked what came out.
A laboratory does not start with a product plan. It starts with a question: how is this done today?
We work with automation, data and integrations. A game looks nothing like that, and that is exactly the point. It forces you to pick up tools you never touch, to solve problems from another family, and to see — without a delivery date pressing — how much the ground has shifted since the last time you stood on it.
What came out of the laboratory has a name: The Fox in the Portal.
Blender, many years later
We had not opened Blender in years. The surprise was a good one, and it is not nostalgia: the tool is a different thing now.
Voxel modelling turned out to be the natural route. Every piece is a block, which turns modelling into something close to building: the fox, its armour, the sword, the chests, the lanterns, the mushrooms lighting the floor. A style that reads well in motion, that forgives in the mesh what a realistic character would not, and that gives you a visual identity from the very first render.
The best part was not the result but how fast we got to it. What used to be an afternoon of tutorials is now half an hour of trying things.
An LLM driving Blender over MCP
This is the part that interested us most.
We connected an LLM to Blender over MCP. Instead of working only with the mouse, you can ask in plain language for geometry, for a structure repeated, for materials adjusted, for a scene laid out; the model drives Blender and you watch the result in the viewport as it happens.
It does not replace the judgement of whoever is modelling: the repetitive work gets delegated, and whatever defines the style stays a hand decision. But it changes the rhythm of the work. Variants stop being expensive: you try five versions of a piece in the time one used to take, and you choose with your eyes instead of your patience.
It is also the same pattern we have been using across the rest of our work: the model does not write the final result, it drives a tool that already knows how to do the job.
Unity: where the model becomes a game
A good-looking character is not a game. The game shows up when the character answers back.
That part was built in Unity: the scene, the isometric camera, the fox's controls, the attacks, the abilities, the enemies, the HUD. It is the least spectacular part and the one that decides whether something feels right: how long a hit takes to land, how far a dash carries, whether the jump makes it. You tune it by playing.
What the laboratory left us
The tools matured more than we assumed. Coming back to Blender after years was the best part of the exercise. If there is a tool you wrote off a while ago, it is probably a different thing today.
MCP is not a demo. Connecting a model to a real tool — with its window open, its scene and its history — is a different thing from asking it to write code. We tried it on a game because a game is fun; the conclusion holds for any tool you already use.
What decides the result is still judgement. The model makes variants cheap; which one stays is a person's call. It is the same lesson the software we build every day keeps teaching us.
A laboratory earns its place when something comes out that you can show. This one did, and it came out playable: a fox, a portal and a block forest you actually walk through.
We are going to keep polishing it. And we are going to keep opening laboratories: it is the most honest way we know to find out what can be done today with what is out there.
Marcos Reynoso
Founder – The41
https://the41.io