Lessons learned while switching to Unity
When we started working on Epistory, we had to choose whether to use our proprietary engine or not. For reasons that go beyond the scope of this post we decided to go with Unity. While the prospect of working with a tool as streamlined as Unity was stimulating, after five years working in a workflow dominated by C++ my C# habits were rusty if not inexistent.
After some time with C# I remembered and saw some of the neat tricks you can do with this language. I also received and read a few tips for Unity itself that can do wonders to keep performance high and coding time low. I will keep this as code free as possible and direct you to the relevant documentation -if necessary- to get all the juicy details that would needlessly blow up the length of this post.
While Unity is very flexible and lets you do basically anything, it can be a blessing as well as a curse. If you don’t force yourself to organize the project and the code from the start, it will become messy really fast. One performance hit that is negligible at the beginning but can grow into a big problem later down the road is the caching of your GetComponent(). Basically each time you ask for a specific component in a GameObject, Unity will go through its component list. In most cases you can safely cache the result and keep a reference. If you start adding components at runtime you’ll have to decide whether to cache it or not.
Leave no warnings behind
Even though most programmers will treat warning as error -or at least minimize the amount of warnings- it bears repeating. The more serious warnings are almost always a bug waiting to be triggered. That is even more important in C# because of some leeway given to the developer. For example: you can hide a virtual function if you don’t explicitly add the override keyword to the sub-class function declaration. And a warning will remind you to make your intentions explicit. The difference between overriding and hiding is that the overridden function will call the runtime type and the hidden function will call the compile-time type.
The switch statement is a good way to keep the code readable. But in this case its behavior is slightly different in C#. You cannot fall through to the next case section. You have to place a break/return/goto… However, there is a walkaround. You can use something like “goto case 1;” to jump to another case. More details here
LINQ can be a powerful tool to interface a program seamlessly with a database. Even though its syntax can be off putting, you should at least try it before you leave it. You can use SQL-like statements to query an xml file, for example. You can also use it to perform operations on IEnumerable (a.k.a. Arrays and Array-like) classes. All you can eat buffet here
Coroutines can be achieved in pure C# but Unity made their use very easy and intuitive. It is akin to starting a new thread without the problems associated with thread safety issues like concurrency, race condition & deadlock. The coroutine also behaves like any other member function. It has access to other functions and member variables.
I will leave the implementation details aside (see links below) but know that it can easily be used to provide easing to an object over time or calculate the next score increment. Another, more advanced, use-case is a very elegant way to implement a state machine. More information here and there and state charts here
Event firing and registering is built into the language. Events & delegates are two sides of the same coin. The delegate provides an equivalent to an array of function pointers and the event is the message being sent. This makes for painless event driven programming and we all know how much a game can be event heavy.
There you have it. A non-exhaustive list of tips, tricks and gotcha. Thank you for reading and feel free to ask any question in the comments.