When I dropped my toes into game Dev, one thing that really bothered me was that you had to use the GUI tools for lots of stuff. I wanted to do everything programmatically and just use Unity3D's GUI as a test/viz environment. But in trying to do that I really ran into a wall where everything felt second class to using the GUI.

I dunno... I just can't come to trust the magical files generated by drag and dropping a scene together.

One thing that helps a little is to switch the project to text mode assets. This is the first thing I do in a new project. Then the .unity files and the like are saved as YAML instead of binary.

It's still not a format where you'd want to make major changes by hand; assets are linked together by GUIDs that the Editor assigns. But at least the YAML asset files are not completely opaque, and they play a lot better with source control.

I wouldn't fret much about trusting the editor, it's no more magic than the scene appearing when you load it from XML. But I agree that this remains my biggest frustration with Unity. It's fun to use, it's very fast to prototype with, but you hit the nail right on the head that "everything feels second class to using the GUI," and once you've worked in an engine that accommodates a text-first workflow it can really feel like mandatory training wheels sometimes. Maybe someone with more professional Unity experience can drop in, it's such a popular platform that it seems to me like there must be productive workflows that aren't hampered by the GUI in use out there.

Most other engines have different tradeoffs in my experience, and Unity is hard to beat because of how relatively robust and stable it is.

I have yet to see a professional game engine that wasn't GUI oriented.

Professional game studios are mostly Windows based, and developers are actually a minority in teams, mostly responsible for low level engine code.

So understandably the workflows are optimized for animators, artists, level designers, gameplay developers, script writers, ...

Aha, that's a very good explanation. Most of my experience with 3D development has been alongside something LOB oriented rather than a "game" per se; like the other commenter suggested Monogame is an example of what I had in mind in my post above.

I have to add the note, Monogame is absolutely up to par with "professional" engines in many ways. I quoted because Monogame originated from such an engine, XDE, Microsoft's managed SharpDX framework for developing games for Xbox Live Arcade. The community took over when MS cancelled XDE. I don't know if it can compete with Unreal or Unity on everything these days, given some of the demos I've seen of Unreal's lighting etc.

I believe MonoGame can be used as text oriented. At least when I tried to use it to make some small games. It's definitely not on the same level of professional use as Unreal or Unity though I think.

http://www.monogame.net/

It's just serialization as a workflow mechanism, and it really gets rid of a lot of workflow cliffs.

It's also nothing to be afraid of: You can absolutely do everything programmatically, using the same (mostly-public) APIs that the Unity editor (which is built using much of Unity itself). If you're ever wondering how something gets achieved in the editor, use MonoDevelop to decompile/disassemble the various .dll's that Unity includes.

I built UnityREPL precisely because I wanted to do a lot of things programmatically (especially, for example, making similar changes to a set of related prefabs).

For people interested in this I can also recommend Arcadia which unites Unity and Clojure: https://arcadia-unity.github.io/

I never heard of it until I released UnityShell. Funny how you can miss such big things. I'll look more into it.

This is awesome project. For the last week I was developing essentially the same thing, but with F# as shell/REPL language. It's not yet ready to be open-sourced but if there is any interest I can clean it up and move to Github in a week or so.

This is a great idea.

I wouldn't be surprised if Unity builds this feature into a future version of Unity.

Every other 3D creation tool has like, Clara.io, 3DS Max, Blender, Maya. How did Unity not have this?

Please correct me if I’m misunderstanding, but at least for 3ds Max, Blender, Maya, their Python integrations make this sort of thing as simple as launching the proprietary Python interpreter (mayapy.exe, maxpy.exe), with consideration of a few limited proprietary details. I think Python is just very well suited for this.

Good question, there were already 2 tools out there that do the same as what I now did, but not with the same kind of UX (they didn't look like a usual shell). If Unity sees there's a lot of interest in this, maybe they might integrate it, let's see.

I like where this is going, but not sure of the practical use case. Can this help me inspect my game objects at runtime or just act like a standalone playground CLI?

You can inspects game objects at runtime. You could, for example, do: GameObject.Find("YourGameObject).GetComponent<Sprite>(). There's probably features that would make it easier to access game objects though, as names are not unique. So you could use the instance ID, but that's a bit of a hassle.

This is pretty handy still. Sometimes I just want to grab an object and map it’s children’s properties into a debug friendly format for output.

Nice work

Nice! Does it work to add a TCP listener so one can pump commands to it from an editor or treat it as an integrated terminal in VS Code or similar?

Interesting idea, well under the hood it only just uses the Mono Evaluator class. So would rather see that as a new project.

Glad to be the first to say here, this is fantastic! I'm going to give it a little go later this evening. Seems interesting!

Great! Let me know what you think.