[Waterluvian]

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.

[Stratoscope]

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.

[mustacheemperor]

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.

[pjmlp]

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

[mustacheemperor]

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.

[icsllaf]

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/

[jfrisby]

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