5 ms·

The Unity CLI: manage Unity from your terminal

86 points by nateb2022 3mo ago

rnewme 3mo ago
So it begins.
- avaer 3mo ago
  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. [1] https://www.tryaura.dev/ https://www.tryaura.dev/
  - redbridgerock 3mo ago
    True that there has been many companies with their own implementations but I feel like a native implementation done by unity will have a huge effect. There is just so many indie devs using it, when the unity team starts adopting it more like how they have started with this cli, I think the use of AI in game development will skyrocket
    - KronisLV 3mo ago
      I believe that everyone could benefit from such a CLI regardless of AI. 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.
  - rnewme 3mo ago
    June is not really a while ago. Native integrations are not same as casual projects that come and go.Tue gamers perspective change begins, noobies now have access to those tools from the house owner etc
Woshiwuja 3mo ago
[dead]
0xnyn 3mo ago
seems 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
xandrius 3mo ago
Will 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.
- avaer 3mo ago
  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.
  - xandrius 3mo ago
    Ok, I spent some time with it and I think the biggest updates are: - 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.
deleted 3mo ago
[deleted]
bob1029 3mo ago
> 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.
- avaer 3mo ago
  > 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.
  - bob1029 3mo ago
    Letting the agent take screenshots of the scene is not effective. A human needs to be in that loop. 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.
thurn 3mo ago
What I really want is the ability to do more operations which are decoupled from the editor. Even just being able to reliably type check Unity C# code without a running editor would be great, or running unit tests. Would really improve things like CI as well as the ability to run parallel development sessions.
- embedding-shape 3mo ago
  I did that for my Unity games like a decade ago, you can too :) Requires a design that has one core and then using Unity basically as a renderer/viewer though, but is a relatively easy design actually. And yes, automation and DX gets so much easier. I think Captain of Industry is built like this too, remember reading about it here on HN from the developers in some comments.
  - BowBun 3mo ago
    Same here, in Godot! This is a common practice for games with performance/networking constraints too. For example building a deterministic sim in a regular engine tends to fail without custom primitives or a nice library to handle some of the intricacies. By moving non-display code out of the engines you can reliably build and control all of this.
- bob1029 3mo ago
  Headless execution exists and is one of the simplest ways to get at this experience. 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.
  - 0x1ceb00da 3mo ago
    How long does the headless unity take to boot?
zulban 3mo ago
Great. For my game [1] I have long had the capacity to compile a separate commandline application using unity code [2]. This lets me do benchmarks and unit tests on the core chess AI code without the editor. However I've had to maintain a separate second unit test suite that I can only run in the editor manually if any unity specific code is involved. Naturally, it's run far less often. 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. [1] https://www.chesscraft.ca https://www.chesscraft.ca [2] https://youtu.be/U4xBLTpZ9Xo?si=Gd2aAWKvLqBVBU66 https://youtu.be/U4xBLTpZ9Xo?si=Gd2aAWKvLqBVBU66
jonathanhefner 3mo ago
Is there an accompanying Agent Skill?
mdtrooper 3mo ago
Well, Godot has the cli from 2016 : https://github.com/godotengine/godot-docs/commits/982ffb6b08a65d19133e7b9b802fd0ceb692987b/advanced_topics/command_line_tutorial.rst?browsing_rename_history=true&new_path=tutorials/editor/command_line_tutorial.rst&original_branch=master https://github.com/godotengine/godot-docs/commits/982ffb6b08... Here's the tutorial https://docs.godotengine.org/en/4.4/tutorials/editor/command_line_tutorial.html 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.
- CollinEMac 3mo ago
  I don't think Godot's cli is exactly the same thing as this. Godot's cli allows you to start Godot, do some command, and exit. This allows you to do operations on a running instance of Unity and get structured text output back. It's explicitly made with LLMs in mind. They're both cli's and Godot was there first, but this isn't really an apples to apples comparison.
  - Rohansi 3mo ago
    > Godot's cli allows you to start Godot, do some command, and exit. [...] They're both cli's and Godot was there first Unity has this too and it predates Godot entirely (2010?). `-batchmode`, `-executeMethod`, etc. are there. Chances are Godot was inspired by Unity.
jayd16 3mo ago
Honestly one of the major upsides of all the AI hype is the FOMO overtook the desire to wall your garden and all these APIs are opening up. 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.
aranw 3mo ago
Is this closed-source? I was unable to find a link to the source code for it?
KHRZ 3mo ago
I already am managing Unity from my terminal, using Codex. Although one issue is that PowerShell + C# reflection gets flagged as malware by Windows Defender.

86 points by nateb2022 3mo ago

rnewme 3mo ago

So it begins.

avaer 3mo ago
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. [1] https://www.tryaura.dev/ https://www.tryaura.dev/
- redbridgerock 3mo ago
  True that there has been many companies with their own implementations but I feel like a native implementation done by unity will have a huge effect. There is just so many indie devs using it, when the unity team starts adopting it more like how they have started with this cli, I think the use of AI in game development will skyrocket
  - KronisLV 3mo ago
    I believe that everyone could benefit from such a CLI regardless of AI. 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.
- rnewme 3mo ago
  June is not really a while ago. Native integrations are not same as casual projects that come and go.Tue gamers perspective change begins, noobies now have access to those tools from the house owner etc

Woshiwuja 3mo ago

[dead]

0xnyn 3mo ago

seems 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

xandrius 3mo ago

Will 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.

avaer 3mo ago
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.
- xandrius 3mo ago
  Ok, I spent some time with it and I think the biggest updates are: - 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.

deleted 3mo ago

[deleted]

bob1029 3mo ago

> 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.

avaer 3mo ago
> 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.
- bob1029 3mo ago
  Letting the agent take screenshots of the scene is not effective. A human needs to be in that loop. 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.

thurn 3mo ago

What I really want is the ability to do more operations which are decoupled from the editor. Even just being able to reliably type check Unity C# code without a running editor would be great, or running unit tests. Would really improve things like CI as well as the ability to run parallel development sessions.

embedding-shape 3mo ago
I did that for my Unity games like a decade ago, you can too :) Requires a design that has one core and then using Unity basically as a renderer/viewer though, but is a relatively easy design actually. And yes, automation and DX gets so much easier. I think Captain of Industry is built like this too, remember reading about it here on HN from the developers in some comments.
- BowBun 3mo ago
  Same here, in Godot! This is a common practice for games with performance/networking constraints too. For example building a deterministic sim in a regular engine tends to fail without custom primitives or a nice library to handle some of the intricacies. By moving non-display code out of the engines you can reliably build and control all of this.
bob1029 3mo ago
Headless execution exists and is one of the simplest ways to get at this experience. 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.
- 0x1ceb00da 3mo ago
  How long does the headless unity take to boot?

zulban 3mo ago

Great. For my game [1] I have long had the capacity to compile a separate commandline application using unity code [2]. This lets me do benchmarks and unit tests on the core chess AI code without the editor. However I've had to maintain a separate second unit test suite that I can only run in the editor manually if any unity specific code is involved. Naturally, it's run far less often. 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. [1] https://www.chesscraft.ca https://www.chesscraft.ca [2] https://youtu.be/U4xBLTpZ9Xo?si=Gd2aAWKvLqBVBU66 https://youtu.be/U4xBLTpZ9Xo?si=Gd2aAWKvLqBVBU66

jonathanhefner 3mo ago

Is there an accompanying Agent Skill?

mdtrooper 3mo ago

Well, Godot has the cli from 2016 : https://github.com/godotengine/godot-docs/commits/982ffb6b08a65d19133e7b9b802fd0ceb692987b/advanced_topics/command_line_tutorial.rst?browsing_rename_history=true&new_path=tutorials/editor/command_line_tutorial.rst&original_branch=master https://github.com/godotengine/godot-docs/commits/982ffb6b08... Here's the tutorial https://docs.godotengine.org/en/4.4/tutorials/editor/command_line_tutorial.html 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.

CollinEMac 3mo ago
I don't think Godot's cli is exactly the same thing as this. Godot's cli allows you to start Godot, do some command, and exit. This allows you to do operations on a running instance of Unity and get structured text output back. It's explicitly made with LLMs in mind. They're both cli's and Godot was there first, but this isn't really an apples to apples comparison.
- Rohansi 3mo ago
  > Godot's cli allows you to start Godot, do some command, and exit. [...] They're both cli's and Godot was there first Unity has this too and it predates Godot entirely (2010?). `-batchmode`, `-executeMethod`, etc. are there. Chances are Godot was inspired by Unity.

jayd16 3mo ago

Honestly one of the major upsides of all the AI hype is the FOMO overtook the desire to wall your garden and all these APIs are opening up. 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.

aranw 3mo ago

Is this closed-source? I was unable to find a link to the source code for it?

KHRZ 3mo ago

I already am managing Unity from my terminal, using Codex. Although one issue is that PowerShell + C# reflection gets flagged as malware by Windows Defender.