What's new in Unity 4.3 (opens in new tab)

It's one thing if you're a major version behind (unfortunate, but manageable), but 2.0 was 5 years ago. That's not a major version, that's practically an entire generation.

Also, lack of compute shader support for anything other than Windows and DX11 is a bit of a drag. Compute shaders are really the future of development and it's a bit of a pain not to be able to use them without going through a number of hurdles. This should be fixed eventually though, I'd imagine.

Hopefully they figure out a better way to handle all their platforms equally, at least for development purposes. Being held back on the desktop just because Unity can deploy to mobile is, again, a bit of a drag. I'd rather have the option.

I have my game server as a C# MVC app as well (latest .NET running on Windows, not Mono/Linux) and the only things new that I seem to be using are the async and await keywords. But you don't need them inside of Unity since they have Coroutines and yield.

http://forum.unity3d.com/threads/197948-New-version-of-Mono-...

Of course, I find it somewhat amusing that licensing is what prevents Unity from upgrading their C# support, since licensing the Unity source code is something that is also very difficult:

  We license Unity source code on a per-case and per-title
  basis via special arrangements made by our business
  development team. As this can be quite expensive, we do
  not generally license source code to smaller operations,
  educational institutions, nor to companies in countries
  which do not have adequate legal intellectual property
  protection.

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.

I guess you are not really the target audience for Unity if full code-only projects are what you are after. I can't really disagree with you though. I've never used Unity, but I watched the 2D feature video and while I have to see the tooling looks absolutely fantastic, very flexible and powerful, I couldn't shake the feeling that I'd be much more comfortable just doing all that stuff using a code-only IDE and good sprite/animation libraries. There's just so many buttons, sliders, menu's, dialogs and other thingamajigs in that user interface :-S. And then somewhere deep down there you also still have your code tied to all of it. I have to say the video was confusing as anything to me.

We started the project without knowing if the compile to flash target would be done when we needed it, so we hedged our bets and kept unity as separate from the game code as possible.

The downside is step through debugging can only be done with UnityVS or MonoDevelop and you don't get the flexibility of using "that complex UI", which I rather enjoyed using as a REPL. Oh, going from code change to compiled to seeing the game on the screen was sloooooooow.

As a programmer, I still have not reached the point of feeling that I lacked control over the game and engine. And I doubt that easily happens with indie developers, as Unity is incredibly well-equipped to deal with small-to-medium sized games.

Unity is following the workflow most game studios use, with the usual developer <-> designer interactions.

If you don't care about Unity tooling, just use your editor + compiler.

It feels at times a bit dirty to give up control and do things "The Unity Way" but the payoff in productivity from non-programmers on the team makes it worth it.

https://github.com/MattRix/Futile

The IDE does not run on linux, just mac and windows.

I was told by someone familiar that the XBOX One license will be free.

I think it will also be free on XBOX ONE

In general I feel like the best practice is to touch these .unity scenes as little as possible, and spend most of your time iterating on prefab files, which are easier to read.

Haven't tried git with unity so I dunno if there are any special case issues there.

The Editor loads assemblies dynamically as well so you can branch/checkout and the Editor will automatically recompile everything without a restart.

Only problem I've had is with scene objects but I think I recently fixed that once with a tweak to my .gitignore.

Direct link: http://netstorage.unity3d.com/unity/UnitySetup-4.3.0.exe