• Register

Epistory immerses you in an atmospheric action / adventure game where you play a girl riding a red giant fox who clears out an insectile corruption from a beautiful origami world. As you progress and explore the fantasy world, the story literally unfolds and the mysteries of the magic power of the words are revealed. Available on PC, Mac, Linux + Free Demo!

Post news Report RSS Lessons learned while switching to Unity

Sharing my experience of going from a C++ environment to Unity and C#

Posted by on

Lessons learned while switching to Unity

Paradigm Shift

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.

Stay organized

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.

False friend

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

Missing Link

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

Daily routine

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

Eventful delegation

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.

This could make a post topic by itself so I leave you with the documentation and an in depth tutorial/study

Epilogue

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.

Post comment Comments
Guest
Guest - - 689,430 comments

Do not you miss the full control and freedom of using C++, because you have to restrict yourself to Unity's ways of doing things?

Reply Good karma Bad karma+1 vote
TheThibz Author
TheThibz - - 12 comments

Not really. Even though you can do a lot of crazy stuff with C++ and its policy of always letting the developer do what he/she wants, 99% of the time you won't use any pointer magic or macro tricks. As for the "Unity way" it's really flexible so you can bend it if you want/need to.

All in all compared to the amount of time saved it's worth it.

Reply Good karma+3 votes
Shuuny
Shuuny - - 12 comments

But this is not about Unity at all, this is about learning C#, besides that 'stay organized'... I think unity is bad. Do they still use .NET 2.0... and that is very old, even garbage compared to modern .Net versions. Not only that, but unit's object component model is counter-productive, it is a limitation, not a feature. Obviously their marketing team has brainwashed plenty so it's become widely accepted as 'good'. It's not. Don't use unity, unless you *really* can't get your rendering working yourself.

Reply Good karma Bad karma+1 vote
TheThibz Author
TheThibz - - 12 comments

Well considering that I'm a programmer most of my getting used to Unity was through the code.
Unity uses a custom version of Mono, which is not tied to any particular .NET version. But it is around .NET 3.5.
Could you be more specific about Unity's object component model?

Reply Good karma+1 vote
Shuuny
Shuuny - - 12 comments

It is unnecessary and restricting paradigm, with performance cost associated with it. Do you like dealing with that GetComponent() and your caching of it and all that? That thing is build more for the sake of quick and dirty way to build an engine, not as wise mode of coding, that is good for the user. It's a restriction, paid by time of its users, not a feature, that is all i wanted to say about that really. Not only that, but learning about different ways the engine is structured can be much more daunting than just writing your own thing, and with Unreal Engine being better performing, costing nothing and build around C++ you used daily, supported by team way more professional than Unity, having more features, it baffles me why would one choose Unity engine, seems like uneducated and bad decision (no offense, we all make mistakes)...

Reply Good karma Bad karma+1 vote
TheThibz Author
TheThibz - - 12 comments

I can't really disagree with any of your points. But I can mitigate the impacts of all the negatives by some at least equivalent positives. Less control & performance for ease of use and development speed. Also, it is only as quick & dirty as you want it (akin to php). And the learning curve of Unity/C# is not what I would call steep.

As for the choice of the engine, as I pointed out at the beginning of the post, there was several factors. Learning curve, price (UE4 wasn't free yet), previous experience of the whole team and so on.

UE4 ranks high on our figurative list of engines but it didn't make it.

Reply Good karma+1 vote
MadballNeek
MadballNeek - - 12 comments

"it baffles me why would one choose Unity engine"

Not everyone has the time, resources and knowledge to create a game engine. It's hard to tell if you're knocking just Unity, or all packaged game engines.

Reply Good karma Bad karma+1 vote
darkeccho
darkeccho - - 75 comments

All the people who say Unity is bad, I think you forget all the awesome and popular games made in Unity. Just because you can't use it, doesn't mean it's bad :P

Reply Good karma Bad karma+3 votes
MadJohny
MadJohny - - 14 comments

Mostlyl ately a lot of games have been showing unity's power, most of games with new and refreshing mechanics are made in unity.

Some examples:
- Ori and The Blind Forest
- Hover Revolt Of Gamers
- Superhot
- Distance (originally a digipen game)
- Path of Shadows: Twin Souls (also originally a c++ game)
- P.A.M.E.L.A.
- Firewatch
- Etc.

Imo there is like no actual reason to say that unity is a **** engine, the "simulators" you see out there don't reflect the engine at all :)

Edit: A lot of these games aren't even finished yet but already look really promising, plus, look into steam, I bet you'll find a lot of games made in unity that you probably didn't even know they were made in unity

Reply Good karma Bad karma+3 votes
darkeccho
darkeccho - - 75 comments

Exactly lol ori and the blind forest was very very well done and super epic. Lots of other really great games are finished already with the Unity engine :) Like MadJohnny said, I am sure there are tons of great games made with Unity that people didn't even know were made with that engine.

Reply Good karma Bad karma+1 vote
MadballNeek
MadballNeek - - 12 comments

Pillars of Eternity and Cities: Skylines are Unity games as well.

Reply Good karma Bad karma+1 vote
alexvandenabeele
alexvandenabeele - - 1 comments

As for the warnings, this is how you can enforce to treat them as errors:

Answers.unity3d.com

Reply Good karma Bad karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: