What's new in Unity 4.3
unity3d.comUnity really desperately needs a Mono upgrade, as their version is years old. Unfortunately it seems to be a licensing issue with Xamarin, because of LGPL constraints on mobile platforms.
It's quite frustrating to work with C# without all the features of the last few versions, particularly if you want to use third party libraries.
Agreed. It's starting to become a bit of an issue, particularly, like you said, with third party libraries.
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.
AFAIK, compute shaders only became available in D3D11 and OpenGL 4.3. MacOS was stuck on OpenGL 3.2 for a long time, and even the latest version only supports 4.1. On Linux, Intel and open source drivers (Mesa) only reached OpenGL 3.2 support last month. So that leaves proprietary drivers from AMD (4.3) and Nvidia (4.4) + D3D11 on Windows. I don't know much about mobile platforms but I don't think they support compute shaders.
You're right. It still sucks though. :)
AFAIK you can do OpenCL on OSX with Unity, you just don't have the typical Unity integration so you'd have to handle all the details yourself. It's on my list of things to try out soon... the switch to general purpose GPU processing is too large of a revolution to ignore.
I mostly program C# inside of Unity. What are some of the newer C# language features that it's missing that you think are pretty cool?
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.
I can't speak directly to the differences with Unity, but comparing C# from .NET 2.0 to the latest you're missing: LINQ, dynamic data types, extension methods, optional and named method parameters, covariance and contravariance, async and await... and a whole bunch I'm probably forgetting. It's a lot more flexible now and lets you take advantage of dynamic/functional code. After coding in 4/4.5 for awhile, I certainly wouldn't want to go back to a 2.0 ecosystem.
Extension methods work (I use those all the time), and async and await are unnecessary because Unity gives you coroutines and yield.
The rest of that stuff seems cool though. Oh well =\
Yes, they posted on their forums about the licensing issues:
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:
http://unity3d.com/unity/faqWe 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.It's especially frustrating because ClojureCLR won't run on such old versions of Unity. I spent a good three days trying to backport all the necessary library code and eventually gave up. I was really hoping to get a decent interactive environment working with Unity.
Never used Clojure but Boo has pretty good support for this, including an interpreter and repl hook.
The compiler and parsing pipeline is exposed, there is an interpreter built-in, you can hook into the assemblies, etc. I have a console in my game that does input/output from a Boo interpreter and it is exposed to everything in the game scope with no real extra effort on my part.
Only took a few hours to set up, most of which was spent either writing a UI for it or sorting out some compatibility issues (Unity doesn't come with a copy of Boo.Lang.Interpreter).
It's pretty sweet.
Which might be why this version of Unity updates to MonoDevelop 4.0.1.
MonoDevelop != Mono. MonoDevelop is a standalone application, the default Unity code IDE. No doubt an improvement (at least for folks who don't switch Unity to another editor entirely), but not a change in the Unity C# runtime.
Checking the forums, it's indeed only an update to MonoDevelop. I stand corrected.
As someone who made games throughout my childhood, I'm looking forward to trying out the new built-in 2D functionality with my 9 year old. We've used Scratch, RPG Maker and a few other things but it would be nice to use a framework that has such wide publishing capabilities so he can show his friends his creations more easily. I didn't think he was ready to tackle 3D game creation so we haven't tried Unity yet but I was really waiting for 4.3 to come out - thanks for the heads up!
Unity seems a bit tricky for a 9 year old even with this update, you might want to check out something a bit simpler like Construct 2 to start with. Just an idea
Checked it out - looks awesome and will be downloading the free version to try it out first. Anyone else have other suggestions?
I prefer Gamemaker Studio (http://yoyogames.com/) it's more code oriented but very easy to use. There's a free version too. Look up Hotline Miami if you want to see a commercial game made with it.
For younger developers, you might try out the Intel XDK - it has a really simple interface and emulator for Android, iOS and web browsers (for building HTML5 apps). It includes publishing features and its totally free.
I'd be more happy if Unity goes toward being more programmer-friendly. Fully code-only projects support, no need to waste a lot of time tinkering in that complex UI, etc...
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.
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.
>> I'd be more happy if Unity goes toward being more programmer-friendly. Fully code-only projects support, no need to waste a lot of time tinkering in that complex UI, etc...
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.
I did a fair bit of work in Unity earlier this year. The Unity UI makes a lot more sense once you realise it is built by the objects in the scene. You can code entirely in Visual Studio and just use the Unity window to view the results. But you can also start extending your entities with custom controls and debugging panes and build your own graphical tools. Unity basically makes it incredibly easy to whip up graphical debugging and editing tools for the times when that makes sense but doesn't prevent you from working in whatever IDE you are comfortable with.
For example, I worked on a tool for procedurally deforming enemy meshes to prevent the whole 'attack of the clones' vibe that many games fall into. Rather than use print statements to figure out what was happening in the code, I used Gizmos [1] to draw various important coordinates on whichever mesh section was under the mouse and added handles to let me interactively modify the inputs to the algorithm. I also added debugging output on the side panel that updated in real time as I deformed meshes. In Unity its trivial to build those kinds of custom tools. Debugging the same problems with the usual print statements and compile/restart cycle would have been much slower.
I take issue with a lot of the other design decisions in Unity, but the UI is a massive improvement over most work-flows once you learn how to customise it.
[1] http://docs.unity3d.com/Documentation/ScriptReference/Gizmos...
They support all of that. At my last job, we made a huge 3d facebook game written entirely in c#. We compiled independent libraries, copied them into Assets/Plugins and ran the game using the UI. Everything was procedurally generated because, back then, we had some serious issues with missing texture references. The best part is, because compiling c# libraries has nothing to do with Unity (other than including the Unity libs), it can be done using a variety of methods and IDEs.
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.
Unity has probably one of the best UIs I've seen. I also use Blender, so I know how complex UI can get. But with Unity, they encapsulate everything into game objects and components. That's it. It really can't get much easier. Even their animation system is sensible and fits nicely with the overall architecture. I was up and running within a few days. In a week I had what could arguably be considered a working game. Watch a few youtube videos and you'll have working cloth, triggers, and particles.
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.
Why should they?
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.
You'd be throwing out the differentiating strength of Unity though. The whole point is that non technical designers can put stuff together incredibly quickly.
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.
It's targeted at scripters not professional programmers though. I think in their paradigm professional programmers are focused on creating components for the store and everyone else (level designers, gameplay scripters etc.) just consume components along with some scripting.
Professional game developers are exactly the people that would use a product like Unity, Unreal, CryTek's stuff, etc.
As a professional game developer, I can tell you that using Unity was the least pleasant experience I have had (to put it mildly). I don't see it being a tolerable experience for anything more than simplistic games (like a typical casual game). If you were thinking of something like NFS or Unreal or Dues Ex for mobile, it is very painful and you are better off using a decent engine in its place.
Funnily enough, Deus Ex: The Fall for mobile is made with Unity, and the team that built it said it was much, much better experience than the engines they've used in the past. So YMMV.
(note: I work at Unity)
I've worked on a sports game, a racing game, a 3D virtual world with a lot of mini-games, a flying arcade style game, simple casual games and maybe a few I can't recall. This was just those which I was involved in while using Unity. I can't speak for my ex-employer but I will not choose Unity in a hurry any time soon after that.
I lost at least 20% of my working hours trying to get the project to work again or waiting for it to sync to asset server and would always be half hopeful and half terrified at the time of any updates to Unity. "Did they fix the unresponsive 'cancel' button on the assert server update action?", "Did they make it more stable?", "OMG! Another update! Will my entire project re-import again?" were the kind of things that used to run in my mind.
I'd have to hear strong positive reviews from those I trust to even try Unity again (assuming they back them with good reasons).
That is however a mobile game.
Unity is really nice, and if you plan for it, can scale pretty well. It's much more flexible, so it's easier to shoot yourself in the foot, while other engines are less flexible, which can be advantageous at time. Additionally, it's difficult to get it to shine at the higher end in the ways that other engines do. IMO, I think this is more of a problem of bad defaults than any significant lack of features. But the top tier games released by most of the other engine developers have really forced them to tweak the engine in ways that Unity has not.
Sorry, I meant programmers rather than game developers in general. Of course a game developer such as 3d animator will prefer Unity.
I doubt that would happen, since the Unity editor is what sets it apart from a plain IDE, especially for 3D designers looking to build games. However, they likely have plans to beef up things on the coding front instead of just relying on third-party tools.
For 2D, Futile may be almost exactly what you're looking for
Yep, Futile is great. It's not quite as simple or flexible as a pure 2D engine (like PyGame/SDL), but it lets you make 2D games while taking advantage of Unity's cross-platform engine, GPU acceleration, and any other features you layer on top of it.
Speaking as a Futile fan -- Unity 4.3 includes a whole suite of 2D classes and tools. No need for Futile anymore unless you prefer the way it works.
Not exactly what you meant, but there is UnityVS. http://unityvs.com/
Does it work on Linux?
Yes, as a build target: http://unity3d.com/unity/multiplatform
The IDE does not run on linux, just mac and windows.
which is ironic as it's Mono...
Mono has a good cross-platform GUI library? IDE is mostly very rich GUI I guess.
Monodevelop was primarily developed on Linux, so this is bit ironic indeed.
May be it is because 3D/2D modeling aspects of the IDE, not really because of Coding aspects.
Not any longer, Miguel lost interest.
I have had some mild luck getting it to run under wine, but it does randomly not work, so not a great experience there. I'd love it if they'd port the IDE.
has any small/indie game developer here had experience with their license? I'm curious how much it'll cost to publish to a console system. Their website says it's a per-case basis and I'm not actively developing anything now so calling them won't help. Just curious, thanks!
Deploying to console is very expensive. Wii license is something like 40k, PS3 is more. Not sure about Xbox 360.
I was told by someone familiar that the XBOX One license will be free.
> I was told by someone familiar that the XBOX One license will be free.
This was announced some time ago already, http://blogs.unity3d.com/2013/11/05/big-xbox-one-news-for-un...
Free on Wii u : http://forum.unity3d.com/threads/175564-WiiU-license-comes-f...
I think it will also be free on XBOX ONE
I would keep an eye on MonoGame. It's open-source for a all desktop and mobile platforms and they have recently announced a paid PS4 support is in the works. I think it's likely to be much cheaper than Unity3d. Of course the tooling is not there yet...
publishing to optical media is very expensive. PS and Xbox have lower fees for publishing to their download service (rumors that Xbox live arcade is going to free)
Does it come with HTML5 browser support or is it still using this plugin?
Not yet, but don't be surprised if WebGL export is a big feature of the next major release.
Would be nice to have the tooling on the web :)
Chrome is dropping NPAPI support, which includes the Unity browser plugin. Unity will be temporarily whitelisted probably through the end of 2014 but the goal is to remove support entirely.
http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-f...
So if they want to continue offering a browser plugin they have to switch to NaCl, I think.
Anyone know how "mergeable" the project files are? Are they git friendly?
They are technically mergeable because they're text based, but they're not super easy to comprehend. I've found that .unity scene files seem to develop dramatic changes between check-ins that make it difficult to isolate problems (ie. giant blocks of text removed from one part of the file, then put in another part of the file untouched).
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.
They are pretty git friendly. There's instructions floating around for how to do it but it basically works as you'd expect once you get your .gitignore file set up properly.
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.
Looks like the download link is no good. Getting a 404 (Windows).
It starts after 2 seconds or so.
Direct link: http://netstorage.unity3d.com/unity/UnitySetup-4.3.0.exe
That worked. Thanks.
Background image has some issues in safari when scrolling.
Are there any good tutorials on using the 2D toolset?
Other than the official documentation, you'll probably have to wait a few days/weeks.
Now I know what I have to download tonight! :)
I wonder how does this compare to Corona.
I've used Corona to develop a hobby project in the past and its great for 2D (easier to use and more programmer friendly than Unity) but completely unsuitable for any 3D work so its really just depends on what kind of game you're making. With Unity 4.3, the 2D experience should be much better (before 4.3, you needed ~$100 addons for decent 2D sprite support in Unity).
Am I the only person who opened the link expecting something about Canonical's desktop?
Yeah, the naming has always been unfortunate, but given that the URL after the headline says "unity3d.com" it's kinda clear which of the two was meant.
Unity used 3D acceleration to render its lenses.
If you are completely unaware of the gaming scene and an Ubuntu user (I am in the intersection of both), it's not obvious.
I've had the opposite problem, seeing in the past an article about Unity the compositor, being about 3D rendering of some sort and instantly thought Unity 3D the engine. This is likely due to my exposure to the gaming space.