Live data from Hacker News

The Unity CLI: manage Unity from your terminal

unity.com

21–30 of 32 posts

Re: The Unity CLI: manage Unity from your terminal

#21
post #11

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.

Rider and Visual Studio do this but you mean outside an IDE that's doing incremental builds on change?

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.

Re: The Unity CLI: manage Unity from your terminal

#22
post #12
post #10

Earlier quoted context omitted.

> 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 w…

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…

I wouldn't be so sure about that. Have you actually tried? You might be surprised.

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.

Re: The Unity CLI: manage Unity from your terminal

#24
post #17
post #11

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.

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 ite…

How long does the headless unity take to boot?

Re: The Unity CLI: manage Unity from your terminal

#26
post #8
post #2

So 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. [1] https://www.tryaura.dev/

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

Re: The Unity CLI: manage Unity from your terminal

#27
post #6
post #5

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.

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.

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.

Re: The Unity CLI: manage Unity from your terminal

#28
post #17

Earlier quoted context omitted.

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 ite…

How long does the headless unity take to boot?

It comes up really fast if you use -nographics and are operating on an incremental/cached workspace path.

Re: The Unity CLI: manage Unity from your terminal

#29
post #12

Earlier quoted context omitted.

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…

I wouldn't be so sure about that. Have you actually tried? You might be surprised. 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 gett…

I've tried it. I've spent about $100 in tokens trying to make it viable. There are cases where it's very impressive but the stability is non-existent for practical use.

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.

Re: The Unity CLI: manage Unity from your terminal

#30

Well, Godot has the cli from 2016 : https://github.com/godotengine/godot-docs/commits/982ffb6b08... 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.

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.

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

Post reply on HN