Unity Game Development: The horrors

Yeah, my thoughts exactly.

Time for a change of pace from my regular blog posts and just to get a few things off my chest regarding Unity.

Firstly, don’t get me wrong. I hold Unity in my books as probably the best engine I’ve used so far. Before using Unity, I used Multimedia Fusion 1.5 and 2 to make 2D Mario Fangames during my school years. I played a lot of other people’s fangames during that time. I’d go about making my own but they would be scrapped soon after I started. However, as with anything there are some things that have been annoying me for some time.

I’m building a third person shooter with Unity and these are the things that annoy me the most. Take the following with a grain of salt.

Quality Control.

Unity 5.6 was pretty much the gold standard in my books. I used 5.6.3f3 for most of the last quarter of this year, and it had been pretty damn good. The Unity 2017 branch has been a hit and miss to be quite honest. I have tried 2017.1 and it’s been pretty okay for the PC development side of things. Unity 2017.2 has been a fucking nightmare and feels like the most half-baked build I’ve ever used – it falls into the “You tried” category of Unity versions in my books.

Why, you may ask? Well, for starters:

  1. Have the Unity window minimized and be playing a full screen game (Windowed Borderless or not, doesn’t matter). Pause the game, press Windows key to bring up the start menu and select Unity in the task bar. 90% of the time you will hear a Windows default chime indicating Unity is doing something like re-importing scripts and it won’t accept your request. After the chime, clicking the Unity icon in the taskbar brings it back up. Then it takes a second or two for it to realize the Editor is in focus and accept input again.

    It’s not just playing games that trigger it – I might switch to Firefox for example, check something and switch back. Still the same issue.

  2. Random Unity crashes when clicking Play, or the editor just suicides when importing packages. In the former, 90% of the time you’ll get a crash reporter. In the latter, it’s just a silent death –  Oh whoops I crashed, bye bye Windows, ima ded.
  3. Random Unity re-imports because I looked at the icon wrongly and it decided to re-import things. Seriously.
  4. Unity randomly crashes on close or switching projects. This bug has haunted – and seems to still haunt – my overseas development team mate for quite some time. The issue may be related to Visual Studio Code’s integration with Unity.
  5. Random DLL import errors on fresh projects. Apparently Unity can’t even import the standard DLL stacks correctly. However, it sorta fixes itself after a Editor reload.
  6. A lot of other random knick-knack errors and stuff that I remember but can’t really remember the specifics of.

Networking.

Don’t get me started on the current state of the stock Unity UNET. Turns out the guy responsible for making improvements and fixes in the HLAPI (High-level API) for UNET left Unity Technologies and as a result, UNET is pretty much on life support. Things like connecting to a server with a different scene loaded causes a broken scene to load. This type of shit hasn’t been fixed for ages. UNET Phase 3 seems interesting but honestly, if I held my breath at this stage, I’d be dead.

There’s projects like HLAPI Pro that are attempting to do surgery on UNET’s HLAPI and fix the bugs but you’d expect a engine like Unity to come with a solid networking stack, no? Yeah, I wish…

And no, I’m using what comes with Unity because I’m not wanting to bleed money with subscription-based third-party networking stacks that I don’t understand nor know about their reliability.

Bug reporting.

Surprisingly, the Unity bug reporting system is pretty OK. I only had a few bugs that I needed to report that were show-stoppers. The project uploader is slow however, probably due to where the servers are located. The QA team actually give you pretty good feedback and will drill down issues and/or give constructive pointers as to the problem. Gold star.

Documentation.

Majority of the documentation is fine, but the network documentation is horrible. It feels like some off-shore worker wrote the UNET documentation. Look up NetworkManager.OnClientSceneReady in the Scripting Reference and you’ll get a sentence started with “Called on the client when scene completed loaded”. The fuck does “Completed loaded” mean? Of course, it means “completed loading” but come on Unity, you’re not built in China AFAIK. Put some people on the documentation team and flesh that documentation out.

Other subjects are passable apart from no examples on how to use a function when you need one. I expect to be able to understand the documentation in a simple and clear manner but poor grammar and/or english is not acceptable.

Overall.

Yes, Unity 2017.2 sucks in my opinion.
Yes, I’d love the next minor version of Unity to restore my faith in Unity Tech’s ability to provide a solid game engine.
No, I will not be throwing my keyboard out the window or losing sleep over what bugs 2017.2 have.
No, I will not be giving up game development over bugs that hinder my ability to do things. Myself and my team will work around them, and emerge victorious from the battlefield.

Unity itself is a good* engine. However, it’s buggy editor and new-new features without the bug fixes make it fall behind in my books.

My advice to Unity Tech? Forget about being the latest and greatest. Fix your engine bugs THEN innovate. Don’t fucking make new versions of Unity and call them “ready for release” when they break in half randomly.

Alright, that felt good to get off my chest – thanks for reading and I hope you have happy game development. Coburn out.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments Protected by WP-SpamShield for WordPress