I recently wrote here about how Anthropic's pending acquisition of Decart isn't only about cheaper inference it's also about robotics. The argument in short: you can't train a control loop on internet text, because control needs consequences. It needs an environment that responds to actions, cheaply and a million times over. And that is structurally what Oasis is. A frame predictor conditioned on actions is a simulator nobody had to write physics for.
This is the more personal follow-up. About why the topic actually got to me — and why I'd been crawling toward it from a completely different direction the whole time, without planning to.
The Firefox bridge
Making games has been my hobby for a long time. Never professionally, never for money it just never wore off.
At some point it started overlapping with the other thing I do: agents and MCP. I contributed to Godot MCP, which has since become a sort of de facto standard for connecting Godot to agents. And before that, I wrote a bridge between Firefox and MCP agents.
I wanted a simple thing: for a model to actually work with the browser, not write about it.
That turned out to be the smaller part of the problem. At the time, Firefox's approach to external control was badly outdated — a protocol built for testing, not for something acting autonomously inside the browser. Most of the work in the end wasn't about the agent at all. It was about working around or translating an interface that never anticipated this kind of use.
I wrote it, put it out there, and moved on. Mozilla later adopted it and took it their own way: https://github.com/mozilla/firefox-devtools-mcp
This happens to me a lot with my own projects: I start something because the question is interesting, and somebody else finishes it. It used to bother me. These days it strikes me as a fair enough division of labour — the part I enjoy is the part where it isn't yet clear whether the thing makes any sense at all.
My own engine, because it's fun
Alongside that, I write my own game engines. Not in Unity, not in Unreal, not because it's the sensible thing to do.
The reason is mundane: when you write the engine yourself, you know what happens in every single frame. There aren't twenty layers underneath that already decided something for you. You have state, you have input, you have a rule for how one produces the other.
And that's exactly the property I started wanting for a different reason.
Worth saying plainly, because it's the part that usually gets misread: the engine is the work. I'm not training anything, I'm not building a model, and I have no ambition to. Models are something other people make and I'm happy to leave it that way. What I'm building is the instrument you point at one.
What I actually want
I want a model to play my game. And then to design it itself.
Not in the "generate me a level" sense. That's content generation and everybody can do that by now. I mean: let the agent play, let it lose, let it change the rules and try again and watch what comes out.
This is where it meets the distinction I wrote about in the previous post, and the thing I think the whole conversation keeps glossing over:
- Model as the control loop — perceive, decide, act. Every tick, inside a latency budget.
- Model as the author of the control loop — read the docs, write code, test, iterate. At human timescales.
Almost every number you see about LLMs and robotics measures the second and gets reported as the first. Models today are good at writing code for robots. They are not yet good at being that code.
Your own engine is a pretty good instrument for that distinction. I can open it from both ends. I can hand the agent inputs and let it play in real time. And I can hand it the source and let it change the rules of the world. Same world, same consequences.
The side effect this is really about now
It was supposed to be a nice experiment about games. Gradually it turned into something else, and the next step has almost nothing to do with games anymore.
I don't want to use the engine to generate games. I want it to be a place where you can put a model in a loop with consequences and see what it does. Not to make the model better — to be able to watch it at all.
Because a game is a cheap environment with consequences. It has state, it has time, it has physics dumb physics, but physics — it has object permanence, and it has a cost for being wrong. It's the cheapest thing you can use to check whether a model understands that actions have consequences, or whether it's just good at describing frames.
And because I wrote it myself, I can break that physics at will. Crank up gravity, remove inertia, invert causality. That's hard to do in an off-the-shelf engine and impossible in recorded video. A test harness where you can't change the rules isn't much of a test harness.
It's the exact opposite direction from Decart. They learn the dynamics of the world from video in order to generate frames conditioned on actions. I have a hand-written world I know absolutely everything about, and I'm curious how much of it a model can work out. Smaller, dumber, but fully legible and legible is the whole point when the thing you're building is an instrument.
Where this ends up, I have no idea. It's entirely possible I'll find out only that a model can play my game and nothing further follows. I'll take that.
Why any of this
This is where I'd normally write a sentence about the market opportunity.
I don't have one. I make no money from this and probably never will. There's no startup behind it, no pitch deck, no plan. I'm not competing with anyone building models, because I'm not building one. I do it because I like exactly the stage where it isn't clear yet what it's for and because the things I make this way have a habit of turning out useful somewhere else entirely.
I wrote the Firefox bridge out of curiosity. A year later I was building production MCP infrastructure at work, and that experience saved me a lot of dead ends. The engines started as pure nostalgia for a kind of game nobody makes anymore. Now one of them is turning into a test environment for agents.
I don't think that's a recipe. More of an observation: the most useful things I've made came out as a side effect of something I was doing purely for fun. And I never knew in advance which ones.
So: for fun. And if something interesting falls out of it, all the better.
If any of you are running similar experiments your own engines, agents in simulation, anything on this boundary I'd be glad to compare notes. Especially if you've found where exactly a model breaks once you put it in a loop with consequences.
Top comments (0)