The Unity CLI: manage Unity from your terminal
unity.com
unity.com
The biggest issue with unity is that the editor (even when headless) is designed to take an exclusive lock over the physical project directory. This can be solved by doing a robocopy of the project to a temporary path, deleting any lock files, and then running headless execution there. You can keep the same temp path(s) over many iterations with incremental sync so it's not copying the entire universe each time.
This works for CI, LLM automation, etc.
Hmm I guess yeah you're going to need multiple separate workspaces to work on multiple large changes in parallel. For games that can be a large cost.
Multiple sandboxes on the same workspace wound be nice.
This new unity cli doesn't replace that design, since it's important to me that my core chess variant AI code remains a project on its own, totally independent of unity. But it does mean lots of my utilities like my second unity test, which normally require clicking a button in the editor, can now be run without the editor. Excellent!
Making a 2d chess variant game means almost all unity editor features just get in my way.
I had to struggle for years managing Unity editor installs by hand and then through the headless mode in Hub.
It would be nice if they finally released docker images of the editor so you could more easily spin up build machines too. Oh uh, the AI needs it... yeah. Its for AI.
I guess the build pipeline part is nice as we can finally have a fully automated build process from build to distribution without finnicky build/postbuild scripts/profiles.
> The same surface is open to any agent, whether that's Unity's own tooling routing through its MCP server, a third-party assistant, or a script you write yourself. Unity’s AI is one consumer of it, not a replacement for it.
I hope this means games get more automated tests! The state of the industry is generally woeful in that regard.
- Easier automating builds via shell
- Creating entry points for agents to modify and probe a running built game when in dev mode. This is huge, as you can create a lot of scaffolding to debug really complex states and stuff.
For most of the dev stuff, I'd still go for the usual UnityMCP.
I played around with automating Unity with LLMs for a while. The ability to do this would have been very compelling to me at the beginning.
At this point, I think the more productive way for frontier models to interact with a unity project is to directly manipulate the raw scene files. They are not binary. These files are effectively YAML documents that you can parse, grep and patch just like any other text/code document. The key is to build the tools around these in the same way you would build tools around an agent that can read and manipulate multi-megabyte json documents. It's the same pattern.
Working with a unity project from the filesystem is so much simpler than working with one through all the APIs/CLIs/etc. The files in the unity project path represent 100% of the required information, so the editor feature surface is not relevant unless you are explicitly trying to build editor tooling.
I spent a solid month fighting the domain reload dragon only to realize it didn't fucking matter. I can just wait for the domain reload. As long as the work iteration step size is meaningful, this is not a huge deal.
I disagree. Even moreso than webdev, gamedev benefits from a fast and reliable loop, especially one that can capture realtime state and screenshots. It's the difference between having a new well tested mechanic in your game next morning and giving up after a week of debugging.
Agents will work around slow iteration loops perfectly fine given enough time, but when you're shipping 20 core things in your game each day, the agent's test harness becomes the bottleneck.
IMO it's worth it to spend a day or two to make sure your test loop is tight, it will pay dividends. Not saying Unity is great at playing ball here though. Hopefully their new effort helps.
You can get primitive layouts working if you feed it orthographic projections from the 6 faces, but it falls apart once you need to start looking at things in perspective. It's also absolutely ass at interpreting scene illumination.
We need models trained on 3d scene transforms (aka world models). Passing raster images into the model is a really inefficient method of sending this logical information.
Screenshots are a hell of a big baby to be throwing out with the bathwater.
The structured data this cli returns is great, but screen snapshots can be extremely useful too, both together.
Editing raw yaml files can be tricky, so you do want a formal editing api you can go through, that is extensible for your own component property getters and setters and apis and editors, that correctly maintains all the constraints and dependencies, instead of just letting the LLM hot dog it with your raw yaml files by peeking and poking.
Allowing raw YAML access is the only way I've gotten things like automatic configuration of lightmap baking to actually succeed such that it renders correctly on the first try without me monkey patching things the API exposes poorly.
Epic jumped on the AI bandwagon a while ago.
Unity has been the laggard in terms of AI adoption. If anything this is an "ending" to their old ways.
Hell, take the AI money and build actually useful stuff with the hype money - I personally think ALL GUI software should be possible to fully interact with and control headlessly.
Here's the tutorial
https://docs.godotengine.org/en/4.4/tutorials/editor/command...
History is cyclical. Because I remember same situations m$ windows released features years after the same feature in GNU/Linux, or Iphon€ vs android.
They're both cli's and Godot was there first, but this isn't really an apples to apples comparison.
Unity has this too and it predates Godot entirely (2010?). `-batchmode`, `-executeMethod`, etc. are there. Chances are Godot was inspired by Unity.