With nearly 46% market share and 48% developer share worldwide, Unity is by far the most popular game development engine at present. While Cocos and Unreal Engine have their own sets of fans, it is tough to argue with the leadership position of Unity in this domain – particularly when the latter has more than 4.6 million registered game developers working with it. With the barrier to entry being much lower than most of the other engines, many newbies try their hands at creating custom 2D/3D games with Unity too. There are certain common mistakes that Unity developers often face, and we turn our attentions to those in what follows:

• Using both C# and JavaScript in object scripts – Those who make mobile games with Unity can use either JavaScript or C# in the scripts (that would be attached to the objects). Mixing up both would be a folly though. A script that uses both the languages becomes difficult to access by another script – and for the developer too, things can get very confusing. It is an absolute myth that working with C# or JavaScript in Unity has any particular advantage – and developers should stick with any one (and not use both) while coding for games.
• Concatenating strings in every frame – Doing so should not throw up any errors per se, but it is nevertheless a lot of avoidable, time-wasting work. Instead of using the conventional method to concatenate strings (say, ‘Hello’ + ‘World’), programmers should ideally do it without using the ‘+’ sign. Remember that every time you cache stings, a new string object gets created – and hence, concatenating in each frame can make the whole code bulky and unmanageable.
• Runtime null reference error – New Unity2D developers often face the problematic Null Reference Error. This error is generally thrown when either any of the object fields do not have anything called in them (for instance, in GameObject or Transform), or when GetComponent is used but that required component is missing in the game object. For assigning variables at runtime, it is always advisable to include RequireComponent(Type).
• Not using force in Rigidbody – Contrary to what many new mobile game developers think, position is NOT the only property of objects in a game. An object also has values like angular velocity and speed – and all the properties should remain consistent with each other, to make sure that the game physics is not botched up in any way. There is every chance of things going wrong when a developer uses Rigidbody, alters the position of an object with a script – and does not call any force or torque on it. When a force/torque is used, the collision handlers are managed properly, and the overall physics no longer remains dependent on the frame rates. Keep in mind that functions like AddForce and AddExplosiveForce need to be called in FixedUpdate.

Note: OnCollisionEnter and OnTriggerEnter are two examples of collision handlers used in Unity.

• Not making optimal use of the Profiler – With Unity 5, Profiler has arrived in the free version of the game engine (earlier, it was available only in Unity Pro). It serves multiple functions for game development experts. However, many newbies do not know, and hence, fail to use Profiler in the proper manner. For starters, it allows developers to remotely test their Android or iOS games – which leads to more accurate results than testing games on editors in the same system. Garbage collection and fixing memory leaks are two other important functions of the Profiler as well. It can even be used for profiling scripts by making code blocks (to make the overall performance of the algorithm more systematic). Unless the Profiler is used, and used well, developers will not be able take full advantage of the updated Unity game engine.
• Basic syntax errors – There is no other way of putting this – programming requires undivided attention, and that too, for relatively long periods at a stretch. If you are a Unity developer, check and double-check whether you have put brackets and inverted commas in pairs (e.g., if a “ or a [ is present but their closing “ and ] is not, errors will be thrown). In addition, ensure that you have not missed out on any of the semi-colons at the required areas. Finding and rectifying a mistake here later on can be a big (and unnecessary) challenge.
• Overusing the Unity Asset Store – Make no mistake, the Unity Asset Store is wonderfully well-stacked. From audio and scripts, to textures and models – there is a whole lot of things available, and it is hardly surprising that game developers use resources from the Asset Store in their games. Doing so too much would not be a good idea though – particularly if you wish to lend a unique visual feel to your iOS/Android game (field depth, outlines and chromatic aberration are some of the resources that are used by nearly every game-maker). What’s more, in a hurry to gather more resources, new developers often end up downloading scripts that are not even compatible with their games. Make sure that everything you get from the Asset Store indeed goes with your game, and try to create your own effects instead of the standard ones (whenever possible).
• Not using scripts that are generic enough – This is particularly important for mobile app developers coding in C# with Unity. The extent of reusability of a code is directly proportional to the degree of generic nature of the underlying scripts – and if your scripts are too specific, you will have to create everything from scratch for every new project (instead of having a fairly readymade template). Avoid using the same set of interfaces for all classes though – since that can cause serious code maintenance problems. Reusing codes as much as possible also minimizes the potential issue of code duplication.
• Messing up the project scale – Irrespective of whether a Unity game developer is working with PhysX or Box2D, (s)he simply cannot afford to gloss over the issue of project scaling. Before importing them, the size of each object has to be checked – and the developer must do the resizing for the objects which are not in the correct scale (note: size is measured in meters). Do not make the mistake of using too much gravity to show falling objects either. That will only end up making your game more cartoony and less life-like.
• Overlooking Garbage Collection problems – We have already briefly touched upon how the Unity Profiler can handle Garbage Collection (GC) requirements. There are other ways to handle GC efficiently too. For example, developers should enable/disable objects after declaring them at the start, instead of repeatedly instantiating and destroying them. Garbage Collection can also be invoked by calling a set of Components (by GetComponents). The GC will start when this set of collections is no longer required.

Note: Shaky, unstable frame rates – particularly visible in the mobile build of a game project – is a sign that there are problems in the GC method being used.

• Spelling errors in Unity methods – Another common beginner’s mistake. If any of the methods called in Unity (including Start or Update) is not spelled correctly, the entire code is likely to become unresponsive. This ‘freeze’ can also happen if the GameObject has not been correctly attached to MonoBehaviour. For bringing MonoBehaviour on the GameObject, the names of the concerned file and class have to be the same.

The SendMessage function in Unity, while useful, is rather slow and can be unpredictable while generating new scripts. Game developers should stay away from making their projects too reliant on this function. Also, components should be included as their actual type in GetComponent, and not as strings (both options are available, but the former allows fast spelling error detection during compilation). Using prefab references instead of simply calling the name of the prefab is also advisable.

This is, obviously, not an exhaustive set of problems that a mobile game developer can run into, while working with Unity2D/3D. When any error message flashes, check the line that has the error (and the line before it) very carefully. You can also look for help online, either in the many Unity forums, or by simply searching with the error message – along with a keyword (say, Unity or JavaScript or C#) on Google. Making Unity games is fun and is certainly not hugely difficult…all that you have to do is keep an eye out for, and avoid these mistakes!