Over the last couple of months I've been getting my hands dirty with
Unity 3D on a project for
Luma Arcade, and for the most part it's been a fantastic experience. Unity's 5 or so years of building their tools and having a large user base to test it and provide feedback really shines through. Getting simple concepts going is laughably easy (as evidenced by 48 hour gameplay challenges like the recent
Game.Dev one) thanks to the intuitive interface. The powerful art tools and C# scripting also allow those early efforts to be extended and polished into top notch products.
Unity has a reputation in some circles of being a tool limited to mobile, web, or relatively simple PC and Mac games. Their recent push into the traditional console market, with versions of their engine for Xbox 360 and PS3 (there is already a Wii version) is set to change that. For the most part, I would say they are ready for the jump and many developers will welcome their powerful toolchain as another option when targeting these platforms. There are however, some issues I personally feel need serious attention before Unity becomes the ideal tool for medium- and large scale console development which I would like to point out here. Please note that these are my own views, and not necessarily those of Luma, it's directors or employees.
Outdated and unstable IDE support
Unity has the developer-friendly ability to generate project files that allow devs to work with a Unity project file in
Monodevelop (which is bundled with Unity) or
Visual Studio. These projects can be fully debugged like a natively developed project as well. This is the theory anyway and I've seen the system in work on other developers' systems. My personal experience however (and based on reports online I'm far from being alone alone in this) is that Monodevelop will crash within minutes of trying to debug a unity project. The generated projects are also in the outdated Visual Studio 2008 format, and are re-generated whenever a file is added within Unity so manually upgrading the projects to 2010 format is not a practical option. This leaves those of us with up to date software out in the dark. Considering the importance of being able to debug properly, this is a huge issue that needs addressing. Giving developers the option to output 2010 format projects should be a fairly trivial improvement, the stability issues on Monodevelop will of course be more of a challenge.
C# as second class citizen
Unity has script/code support for JavaScript, C# and Boo. The focus in documentation and samples is quite heavily skewed towards JavaScript, and there are some areas (such as lack of proper support for namespaces, quirks trying to import C# code and outdated API support) that point to C# being a second class citizen as far as Unity scripting is concerned. Moving into the console development space, C# is the natural language choice for most teams due to it's similarity with the still-dominant C++. There is no doubt that javascipt's flexible nature holds some advantages over C#'s more traditional rigidity, but I'd wager familiarity will win out in this case and console teams will go with C#. For this reason I believe Unity would benefit from a greater focus on it's C# support. It does appear this is already happening, as online documentation at least now (mostly) includes examples from both languages.
Non nestable prefabs
Unity's excellent prefab system allows the creation of reusable template objects called prefabs that can easily be added to a scene and then have minor changes applied per instance, but still benefit from later tweaks to the prefab. The problem here is that these prefabs can't be nested, so for example if a wheel prefab is created, then added to a car which is then prefabbed, the connection to the wheel template is lost and any future changes to the wheel prefab will not be passed on to the wheel instances in the car. This diminishes the value of prefabs somewhat, and ideally support should be added for this.
Binary object formats
Unity's scene and object files (including their reusable prefabs) are binary, and as such not mergeable by typical version control systems. Considering the modular component model Unity uses, multiple developers or artists often need simultaneous change access to these files as they work on different functionality on the same object. This leads to blocking cases which would potentially get even more acute with larger teams. Ideally these should be an easily mergeable text format such as XML. There are of course potential performance advantages to using a binary format, but there's no reason these can't be generated when doing a build for the target platform, with the working format being XML.
Asset server
Sticking with the topic of version control, there is Unity's integrated asset control system called Asset Server (for which an extra seat license is required). Now while the idea of asset control built into the development environment is appealing, the reality is that this system is not nearly as extensive as the likes of SVN. It also has some serious issues such as updating of certain project files (particularly .asset files defining project wide behavior) causing a project to become unusable. I for one would welcome the replacement of the proprietary asset server system with a more common standard like SVN, or possibly even something like Git or Mercurial that supports distributed teams-an increasingly common occurrence in our industry.
Focus on non-paying customers
Free license Indie developers have taken Unity a long way, and their admirable support for the indie market has arguably been a massive part on getting the platform to where it is today (and for that reason the following is likely to be flame bait). There comes a time however, when paying customers have to take precedence, and if Unity want to push into the console market that change of direction will have to come sooner rather than later. Unity's brilliant
feedback system in which users vote for for improvements and new features is a prime example of a place where this change is needed. Free users get the same weight in this system as paying customers, and as a result blue-sky features that matter less to professional developers (such as
Linux support) end up drowning out improvements that would help professional development such as
some of the changes mentioned above.
Licensing model
Another example of unity's heritage in smaller developers is their license model. They typically charge a per-seat, per platform license. Recently they also announced
a mass licensing deal with EA that gives all of that publisher's in-house devs full access to Unity's tools. Sadly not all professional developers have the clout EA does, and this leaves a big gap for medium to large studios that would rather buy a group license than deal with seat licenses. A bulk license system is needed, ideally with discounts in place as the group size increases.
