Even though both Unreal Engine and Source have announced free versions for indie developers, Unity 3d remains as the best choice for those about to start making their own games.
In this post you will learn five tricks and tips which will likely be very useful for your projects.
Sit with the rest of the team and assess where your game is going to reach. How big is it going to be?
It is very easy to develop a game fast with Unity, you can even go multiplatform with just a click, but there is a terrible inconvenient: Unity scales really bad in bigger projects.
The editor experiments problems, it slows down if you exceed 3.5 GB and turns making a build into an impossible mission. Even if you’ve done a nice and clean job, performance will decrease and GameObjexcts and MonoBehaviour’s dependences structure will become scary.
Unity 5(x64) has improved in this aspect but there’s a long way to go yet...
The best and most useful thing for big games is literally to divide the project and upload the different parts dynamically into the game.
Any Prefab or Scene can be an AssetBundle. Different levels, characters and enemies can be included in an Assetbundled and divided according to a logical order. In our case, we include each course, car, skin and character as an independent AssetBundle. This gives us the advantage of being able to add extra content like DLC’s or mods.
You will need to create a tool in order to generate the Assets and an AssetBundleManager to upload them easily on your game, however if you are provident you’ll be able to use it again on future projects.
The editor has a problem with everything which is not basic types or native classes not directly supported by Unity. Even if you make use of the attribute (serializable), you can’t trust it 100% and it causes problems.
Among them: many things won’t be shown in the inspector or variables values can be lost when saving or when pressing play. Besides, polymorphism is not allowed, and it can happen that all the elements in a list are casted to the common ancestor (or to NULL if it’s abstract).
Getting down to work!
Locate the interface, SerializationCallbackReceiver with the functions OnAfterDeserialize and OnBeforeSerialize. Now extend class MonoBehaviour and set a serializer that is able to deserialize all elements in a class correctly without losing anything along the way.
You will find interesting challenges because this tool is based on reflection in order to not having to do handmade parsers for each class, including embedded classes, and give support to static or readonly variables.
If you need help, try googling “unity free vfw”
Write lots of Editor Scripts
The more, the better. Every class which is to be reused as a utility for your Monobehaviours should have its own Editor Script, especially collections and/or utilities like Delegates or Actions.
It’s a very common error if there is more than one person working on the project.
A conflict in your repository of a scene can never be merged. The solution lies in being very well organized and to restraint access to each one’s scenes. Not doing this will probably result in one member of the team losing his/her work.
Another solution is to serialize the scene yourself instead of letting Unity manage it by itself. Set your own parser and you will be able to manually solve a conflict.
Unity does not support threads in a native way either, but we have a solution for that: coroutines.
Coroutines are not really threads but they have an asynchrony in their running which may remind us of one. Nevertheless, they have their limitations: they can’t give back values, they don’t have control over concurrence, they don’t capture exceptions, and if they fail they just abort, not giving any feedback.
My advice is to create a series of methods of extension over MonoBehaviour which allows us to launch easily improved coroutines.
Got any personal trick that you want to share with us?
Please leave a comment and tell us!
I wouldn't agree unity is best choice everytime, however great tips.
Thanks for your comment!