Unity has a QA problem

As I go through my fourth year using Unity3D, I can’t help but notice an astonishing lack of quality assurance. The engine’s featureset is incredible in depth and variety, but the issues with reliability and structural integrity threaten the overall usability of the engine.

  • Crashes: In Unity 2017.1X, I get constant editor crashes without prompt, often just from hitting the play button. This crash has persisted from at least p3 to p5, if not earlier. The Animator Window has a related crash that has been in the engine for several versions.
  • Scripting Reference garbage: While Unity has released a blog post on improving this, the Unity script reference has long since been filled with pages completely without or somewhat lacking any proper documentation, unsubstantial documentation on important features, and most criminal of all, documented code that doesn’t even work. (I’m looking at you, Shuriken docs) The script reference is often the only place to turn when the forums and StackOverflow fail to help, and a lack of proper documentation on lesser-used features can make certain tasks near-impossible.
  • Lack of transparency: As an engine, Unity often makes choices that obfuscate inner workings and confuse newer users, especially those from a pure CS background. This can be anything from how Unity uses ‘magic functions’ like Start and Update, to how Components cannot be accessed as a list, to how little it is expressed how coroutines depend on their host object existing, being active and the timescale not being 0. If the timescale is 0, some things work, like UI, but it can be hard to tell if a certain Update function will even do anything at timescale 0. As there is no global pause, this lack of transparency can make late-stage bug-patching extremely painful. Other architectural deficiencies contribute to this; Unity may be a great engine to get a project off the ground, but it utterly fails at providing the maintainability larger projects need to make it through production.
  • Redundancy, Code deficiencies: In many parts of the engine, usage can be very redundant. For example, if working in Screen Space, you might be working in UV space (0,0 to 1,1 from bottom left to top right), Coordinate space (-1,-1, 1,1 from bottom left to top right), among others. It is often not communicated what space certain functions/properties (like Input.mousePosition) return, and thus is confusing for newer users. Trigonometry functions similarly often fail to document whether they take radians or degrees. The fake null system alone is a horrible hack, and has created numerous issues for the engine and for projects, like Null Propagation not even working for .NET 4.6 preview for monobehaviours. I had my first real fake-null encounter of the third kind when working with potentially destroyed objects, and having to deal with whether or not they were Unity null or C# null. While SceneManagement is a huge improvement over the old system, it’s still incredibly painful, between being unclear in what scene is active, to what being active even entails, to working with multi-scene setups and not loading duplicate scenes.

I wouldn’t consider anything other than Unity at this point for my projects, and it beats the competition in many places, but these issues are making it very hard to take the engine seriously as a professional tool. Many of these issues may be simply too difficult to do, however I think that a backend rewrite is worth a large gap in patches to have a consistent and structurally sound engine.

tl;dr: Unity has many issues that would require potentially months of work from the Unity team to repair, but is probably worth it.

Leave a Reply