Unity: a few fundamentally banal tips

I found this unpublished and incomplete post of mine, written in July 2014, on December 2017. Even if it’s pretty old I decided to publish it anyway (keeping the original date when I wrote it), since I believe it can still be useful advice. I hope that soon I’ll find the time to write something more recent, because I learned a lot in the past 3 years (well obviously), but who knows.

Logic

Don’t break privacy

Unity makes serialization very easy (within its limits). Just put a public field inside a MonoBehaviour and voilà, it gets serialized. So a lot of people just make stuff public for this reason. DON’T DO THAT. Keep your shit private unless you truly need to access it from somewhere else: you will be grateful of that when your project grows and you will want to refactor stuff. You can serialize a field even if it’s private, just add the SerializeField attribute before defining it.

Don’t auto-serialize everything

As mentioned above, Unity will serialize every public field inside your MonoBehaviour classes. But, are you sure you want to serialize everything? Probably you don’t. Just add the System.NonSerialized attribute to all the public fields you don’t need/want to be serialized and it’s done.

No scene is an island

Your Unity scene runs perfectly and it blows your mind. Cool. But did you check if it runs even when accessed by another scene? Or when restarted from within the game? Always keep in mind the whole game logic, not just the scene logic, and use some manager so that every scene works correctly both when played directly from the Editor and when played in the correct sequence.

UnityEditor is one of Unity’s strengths: use it

Really. You can do incredible stuff with the UnityEditor classes. Like global settings panels (so you can keep everything centralized instead of having to hunt through scenes and gameObjects in case you want, I don’t know, change the player’s max lives), game panels, debug panels, panels panels panels. But also nifty utilities and menus. Learn to use it: it’s awesome.

Debugging

Play with your framerate

Your game works perfectly at 60/30 FPS. Cool. Now try running it at 4 FPS. Then at 300. If it still works the same you’re good, otherwise you better fix it. To force your game to a low framerate, just use Application.targetFrameRate (but remember that vsync will need to be disabled or it won’t work). To make it go as fast as you can, just set the game quality to Fastest.

Debug.Log accepts rich text

It does, and since a while. It’s mostly useless eye-candy, but sometimes it can be important. Also remember that you have Debug.LogWarning and Debug.LogError (and Debug.LogException) too.

Matters of taste

Don’t release a game which starts with Unity’s configuration panel

As the title says. It’s a horrible thing that will annoy players. I know, I know, creating screen and most of all input customization inside Unity is a hassle, but there are ways. So you should really try to implement them. And maybe, one day, Unity will make his own Input Manager customizable at runtime (as it should be) and we will all be happy.

Naming conventions

I know that naming conventions are the stuff that makes wars, and me too I’m not happy at all with some conventions I used in the past. Still, one thing must be said. You’re not just working in C#/UnityScript/Boo: you’re working in Unity. So at least for public members, think about using Unity’s naming conventions, otherwise things won’t make any sense.