The Unity CLI: manage Unity from your terminal
1–10 of 32 posts
Re: The Unity CLI: manage Unity from your terminal
#2So it begins.
Re: The Unity CLI: manage Unity from your terminal
#3[dead]
Re: The Unity CLI: manage Unity from your terminal
#4seems like agent-native CLIs are going to become a thing, where machine-readable, token-efficient output and discoverability matter just as much as human ergonomics
Re: The Unity CLI: manage Unity from your terminal
#5Will be exploring this but so far using a Unity MCP has proven mostly enough to do pretty much anything from outside.
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.
Re: The Unity CLI: manage Unity from your terminal
#6Will be exploring this but so far using a Unity MCP has proven mostly enough to do pretty much anything from outside. 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.
Apparently this is the same surface as Unity MCP.
> 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.
Re: The Unity CLI: manage Unity from your terminal
#7[deleted]
Re: The Unity CLI: manage Unity from your terminal
#8So it begins.
What "begins"? There's been several Unity AI companies come and gone already, including some mergers and acquisitions. [1] comes to mind.
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.
Re: The Unity CLI: manage Unity from your terminal
#9> unity command eval runs C# code live inside a running Editor or Player and returns the result, with no project-level recompile or domain reload required.
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.
Re: The Unity CLI: manage Unity from your terminal
#10> unity command eval runs C# code live inside a running Editor or Player and returns the result, with no project-level recompile or domain reload required. 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 manipulat…
> I think the more productive way for frontier models to interact with a unity project is to directly manipulate the raw scene files.
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.