Let me tell at first that I absolutely enjoy using unity and I think it’s the best available option for teams smaller than 20 people creating games and interactive applications. Loving something means you want it to become better and pointing out the dark corners of it is a pretty useful activity toward that. Ah and It can be the best option for teams with 200 people depending on what they are making as well.

Unity editor is the best existing editor in the widely available game engines when it comes to workflow and development of single player games. It has problems for sure and many of them are identified by big and small studios. Different people tried to solve different problems by different ways. Problems of unity as a tool set and authoring tool can be classified in two groups.

The first set of problems are those associated with developing 2D games in unity or using it as broadcasting, offline rendering or data visualization viewing tool or a tool to create and test/debug multiplayer games. Unity is originally made for making 3d games and the first version of the engine was single player. The multiplayer part is added to it later on and rarely touched in later releases. Unity is made for making games running as a soft realtime process and not offline rendering or broadcasting so when someone tries to push unity to it’s limits on different ends they’ll have problems.

The second set of problems are related to the fact that unity is a very young technology compared to other stuff like C++, .NET, Web programming and … so less tools are available for it and big companies don’t provide tooling support for it. Things are changing but until now on, unity had to support any tool that it wanted. This problem should fade away since unity technologies is becoming bigger and making relations with companies like Microsoft. But for these reasons and because unity is not available as a set of standard tools using the normal C++ compilers and/or visual studio’s .NET runtime we can not use the state of the art unit testing, continuous integration and debugging tools with it. Things got better with mono debugger. Even support for version control systems was not available until unity became popular. Unity is still great even in this regard compared to many tool sets but compared to having your own tech in C++ you have much less goodies available. Let me to be clear, because visual studio is available to use at least as code editor and now as debugger for windows 8 projects (a company is providing better visual studio integration for unity) and because many .NET libraries are available to us out of the box unity is ahead of the most competitors I’m not fooling myself.

As a group of unity users which love the tool and as people using it to make a living and solve real world problems we hope to help the community and even unity technologies by spotlighting scenarios which unity can benefit from supporting and does not support well yet, and also provide solutions in possible cases. Unity is solving some of the problems (for example by providing 2D support in the up coming version) but some of them are still here to stay. Others might be hard at work to solve some of them. We’ve made multiplayer games with unity for a few years and tried to study the tool and identify the problems associated specifically to making multiplayer games with unity. Here we try to define the problem as good as we can and provide solutions or at least possible solutions whenever we can.

At first I said unity is a great tool for making single player games in terms of work flow because in multiplayer game development tools like hero blade of hero engine beat unity in several ways however unity is superior to many MMO development tools so the situation is not that bad. The point is that it can be much much better. When I refer to multiplayer game development with unity I mean large scale development of projects which are a little more complex than simple prototypes and games which are using unity both as client and server platform. There are two set of features which can help unity to become the ultimate toolset with an ultimate workflow for multiplayer games.

World building in editors like hero blade is done once for multiplayer games and only client only and server only parts are marked appropriately. You work in one environment and build server and client level at the same time. This feature by itself is a huge thing, It can be done currently with a simple editor script and some discipline but is not built-in. You can for example have a special script which you attach to server only gameObjects and a client only script which you attach to client only gameObjects. Then at saving time you can create two separate scenes using all objects but those which are only for the other version (e.g. build anything for server other than client only objects).

World building is a huge task in big multiplayer games so we usually love to separate the task between people and the ability of creating the level together at realtime on multiple machines could be fantastic. The feature can also be useful in single player games with big worlds like RPGs. This has been tried in previous ninja camps by unity technologies staff and also by other people as well. There are not enough hooks in editor scripting feature of unity to make doing it very easy but still it’s possible to be done as a user made tool but it’s no easy task.

The more important set of improvements are about the multiplayer being a first citizen of the editor. I mean it was great if you could just choose from a drop down that you want to run as client or as server or even both. It was awesome if we had the option of having multiple build scene lists for client, server and other builds. It was great if we could run multiple clients together in the editor or open up the same project in multiple editors without having to sacrifice some other stuff. The build settings problem is relatively easy to solve and one can make the simplest support for it in a few hours and a great tool can be done in matter of few weeks.

Here I’m not talking of any new feature in the networking library of unity. I’m not talking of unreliable RPCs or the ability to write custom serializers for custom classes. I consider these solved problems because middleware vendors solved them. I’m talking of editor features which makes the editor aware of your game being multiplayer. The list can go on and on, supporting consoles which can show logs of players in other machines for example can be really valuable even for single player games and for testing purposes. Again this can be done by editor scripting easily. Application class has a way to register for callbacks for receiving logs and the feature can be used to create a networked console in unity editor. If we could easily remove server code from clients and client code from servers it would be great. It’s possible to do by #define directives in scripts but unfortunately it’s not possible to send defines to unity’s compilers by editor scripts and the only way of adding them is using player settings which limits us in the ability of automatically building clients and servers.

Asset bundles of unity are a good feature but they are limited a little when considering the fact that they can not have code in themselves as first class members. I know we can compile our DLL and put it in the bundle and then using reflection use it. I’m not afraid of reflection at all and used it much in a project but the thing is that in this way we have to serialize everything ourselves and need to write a good amount of code for it. Theoretically we can save all serializable properties of our prefabs (fields I mean) and then use the custom serialized stuff to recreate our prefabs at runtime but even then we can not use the feature in iOS or web player. So this is only solvable by unity technologies. At least for web player it should be solvable. To make it valid from a security point of view the player can request privilege from user just like what it does for web cam and microphone. Since unity’s iOS compiler is AOT it is not possible to support this in the iOS and we should deal with it in the current state.

I think many of these can be solved easily by third parties provided that unity exposes more and more hooks to the editor. Openning up the scene and prefab format was a good first step but having more and more hooks can really help a lot. Documenting the editor APIs in a better manner would help a lot as well. Unity technologies seem to have good unit testing tools and maybe some others, if they provide those to other developers with ease then others could test their stuff with more confidence. Also currently there are some callbacks available which does not provide much useful information. For example the OnHierarchyChanged callback could be much more useful if it would provide the changes made or if we had hooks for the time that a prefab is created/changed. Maybe if OnInspectorChanged provide us with the property changed in the event we could do more useful things with it. Of course we can do our own house keeping and monitor everything and ... at least to some extent and we even can call internal members of UnityEditor.dll using reflection but it means we can not try and iterate ideas fast.

When things are easy to test then people try to do creative things with them and I’m sure that unity technology’s intelligent and smart staff know this much better than us. One day I’ve made a menu in Assets menu which allowed me to right click a scene and build it alone and it was a hell of usefulness in testing our different server and client scenes. I’ve done this in less than 30 minutes because build settings, asset database and other required things were exposed enough in 3.5 but for example in 2.6 many of the build related settings like list of selected scenes for build and … were not available so one would try the task harder. We now have the ability to centralize our settings in references dialog, it would be great if we had the sort of integration with build dialog as well. In a somewhat related note I want to mention that some APIs of unity are not documented well and the algorithms are not specified. I’m talking about methods like Vector3.Slerp and other mathematical stuff that people might want to reimplement in exact same way in their none unity based game servers or tools. It would be awesome if unity technologies describe everything in their editor API reference as good as the runtime classes so working with them would be easier. In general the more the beter. Openness and descriptiveness are features which could help a lot the extenders.

The great thing is that they know editor scripting is great. It was Aras or Lucas which once said if we’ve done one thing really right at first, it was editor scripting. Thanks for the great engine and keep up the good work guys and gals at UT.

Update/Correction I've added this here instead of correcting the article for you guys to notice the advancements being happened while you are reducing the number of remaining seconds in your life. Unity now has methods in it's UnityEditor.PlayerSettings class to set and get defines for a specific platform so while building for server you can add SERVER to flags in your build scripts. Addingthe flags. Disclaimer the thing happened before this blog. I have no power over the guys at UT!