Hacker News new | ask | show | jobs
by Cacti 4602 days ago
Source: me. I don't work for Unity. Software engineer and use Unity for a lot of 'traditional development'.

You'd be surprised... there isn't a ton of documentation about it, but most of the engine is pretty well exposed for programmers.

You can punch into the rendering pipeline (down to immediate OpenGL mode if you need to), the compilation pipeline (recompiling on the fly or setting up a custom preprocessor), hook into the assemblies (for, say, an interactive interpreter run in the game), and hook into native binaries in unmanaged code. Naturally you can use any language that can compile into IL, so, you don't even have to use C# or Boo if you don't like it (though you'll want to take a look at Boo... UnityScript interpreter was written in it for a reason! yay, LISP MACROS with dynamic recompilation and loading!)

The editor will, in turn, handle a lot of things for you that are a waste of time to do normally, like visualizing things without having the game running (tweak a shader on the fly), handle all of the recompiling for you in the background, dyanmically load and unload resource files, let you easily browse the scene graph, let you write custom editors (for example, I wrote a converter to convert files of different types so that it happens when those files are added to your resources, instead of converting them on the fly at run-time or with some external half-assed console script), etc. Naturally, you can use your own editor if you're more comfortable (for example, I use Emacs and git and the mono profiler and debugger, rather than Unity and Unity Source Server and Monodevelop, and it works just fine, and I don't spend much time at all in the actual Unity Editor)

And the library itself has all kinds of things that you'd expect to make your life easy: screen graph manipulation, transforms and other 3D math, physics basics like raycasts and bounding box intersections, input handling, camera manipulations, sound and audio handling, event handlers and hooks on all kinds of stuff, color management, network handling and resource streaming, etc.

The tool also comes with a number of pre-written scripts (plus store, of course) to help you out with things you really should never have to re-invent and that a programmer probably doesn't even want to be bothered with, like a first-person or third person controller (complete with physics, camera work, input control and movement, etc.). Or you could go to the Store and pick up, say, a Mini-Map tool for $30 and have it working in about 5 minutes, which, to me, is very programmer friendly (who wants to spend their time reinventing a mini-map?!).

On top of that, your game will be almost entirely cross-platform automatically across a wide array of devices, AND will have native code for those devices for performance-heavy sections. You don't have to waste much time tracking down errors on all kinds of different platforms, which is also very programmer-friendly.

Couple problems: the docs aren't as good as they could be, the Mono version is still a ways back (~2.10ish), compute shaders aren't built-in to OSX yet (though you could do this yourself if you really wanted to), the community is geared around "scripting and drag/drop/click" so getting detailed assistance for very technical matters is sometimes difficult, etc.

All in all though, it's pretty amazing. Now, it will take you awhile to learn all that, to find out where everything is exposed, what you need to hook into, etc., but, once you do, it is actually very programmer friendly.

2 comments

Are there any plans by Unity to improve the documentation outlining this?
No idea. I'd hope so... learning it for me was a bit of a pain as all the relevant facts are split across the manual, the reference manual, the scripting manual, the forums, and answers website, some random websites, the google groups, the mono documentation and references and resources, etc.

I mean, it's not really that bad, just that some things that should be easy to look up are hard to find, and some things that are easy to look up and easy to find have to then be translated from "scripting and drag/drop/click" into actual code (particularly frustrating when you're just starting).

You seem knowledgeable so I figure I'd reply here since I keep getting mixed messages on this point: Is it easy to commit your Unity code in a VCS and have teammates work on it with you simultaneously? Some people say yes, some say no.
I have been using git for source control with no issues (haven't tested in a team environment however).

Not sure if you were aware of this already but theres a non-default setting in the Unity preferences for enabling "Version control support" that basically makes Unity save metadata in a text format instead of its standard binary format: http://docs.unity3d.com/Documentation/Manual/ExternalVersion...

Personally I haven't had a problem using Git. I also haven't done that in a heavy team environment but I've heard good things in general since 3.0ish.

There are a couple things to be aware of regarding how you set up your .gitignore, and now, in 4.3, apparently meta files, but, it's pretty straight-forward, IMO.

I'd ask on the forums and get a current response... a lot of problems with the external VCS were things from back in 2.0ish land, which was quite awhile ago.

You really can't have multiple people working on the same prefabs or the same scene at once. The files are text, so you can merge them, but anything more than just minor changes will not work properly and someone will have to redo their work.

Working on code is fine and your normal guidelines apply to simultaneous work.

I have Unity projects with 3-5 teammates and we don't run into too many problems with scene/prefab merges. Normally each person is working on separate stuff so it would be rare for 2 people to need to touch the same prefab or scene.

If your scenes or prefabs are huge and it becomes a problem then you probably should think about redoing your architecture to keep your scenes and prefabs smaller.