User experience (UX) refers to a person's entire experience using a particular product, system or service. - Wikipedia

I am a programmer, and I make games with Unity. Most of the times when we talk about UX in the team it’s from an end user perspective. “How can we build the game in such a way that it is intuitive to use for the player?” But as a programmer the users I directly impact with my work are my fellow programmers and other developers in the team.

In this post I like to talk about how to make the “Unity experience” as intuitive as possible and my ‘10 golden rules’ of achieving this. Eventually this will save a lot of time and makes working in Unity a lot faster and less painful, paving the way towards that ultimate end-user UX.

The Background

I decided to write this blogpost after watching this awesome video Entity System for Unity. I figured I could add some of my personal experiences from working with Unity to the mix.

The idea behind entity frameworks and the Entitias system itself is amazing. I played around with it a bit, did some small experiments, but after some time I fell into the same pitfalls I've I fell into so many times. It is just too counter-intuitive for any (Unity) developer - seasoned or not - to ask them to fix a bug, and expect it to be fixed fast.

The Entity system is very deep and optimized, and of course there are games out there that are in need of such a system. There is nothing wrong with the usability or the implementation of the system, but from my point of view it is an overkill of complexity without actually returning much of the initial investment. The point that I am trying to make that in order to get the best UX, you have to meet the needs of the user in regards to everything they already know about the subject.

When I started with Unity I was amazed by everything that was supported supported; JavaScript, Boo Script C#,a good IDE, integration with Visual Studio. My first experience was quite amazing, I could just add a Rigidbody to a box and things started falling as if they had physics. Much wow, such intuitive! From someone who came from AS3 Box2D, APE / Cocos2D Box2D that was such a revelation. But there is a downside.

There are a lot of right ways of doing something, thus no one right way of doing anything. Every single tutorial I took during my ‘critical period’ taught me things in a different way. Some of the tutorials used a lot of inspectors, some of them used none. Some of them used depth complex inspectors, some of them did everything by code. This freaked me out because I had no "best" way of doing anything, unlike the other languages I was used to working with.

Now, almost 7 years later and having worked with a lot of different developers in different teams, I found some best practices for myself. But let’s start with something Unity isn’t good at, and which hurts the user experience a lot… consistency. I’d like to walk to a couple of examples to paint a good picture.

Example #1: Unity and monobehaviour.

Unity harbors so many different methods in which monobehaviour can be implemented, and most of them are in a slightly in a black box. For instance, you have something like hits:

OnEnable, OnDisable, OnTriggerEnter, OnDestroy and 20 other OnSomething methods in Unity. Besides that you also have: Reset, Awake, Start, Update, LateUpdate ... methods! WHY NOT OnReset, OnAwake, OnStart, to keep it consistent?!

And this applies to a lot of other things in Unity in as well. You got a couple of property drawers working in this way, and a couple of others working in a completely different way but accomplishing the same thing.

I do like how Unity is dealing with the new Physics Raycaster. Basically you can implement IPointerEVENTHandler in any monobehaviour that has a collider on it, 2D or 3D and you get a nice implementation of the method: