So there you are, you’re sitting downstairs on the Dev Floor sweating bullets over your final project and the line of code or prefab that you’re staring at just isn’t working and all you can think is “WTF is going on — I know I’m doing everything right… it must be Unity‘s fault.” So you take the next logical course of action; you wander over to Bren Lynne and Peter Walsh‘s office. No dice; they are off helping someone else or teaching… What now?
Sadly, for those of you who fit the above scenario, this article may have come a little bit too late. But for the rest of you, this article may give you a hand with some of the stickier points that you may encounter, as well as with some common problems that my class had a hard time with. As of my writing this I believe that VFS Game Design has upgraded to the newest Unity (4.1) but all or almost all of this is relevant, regardless.
This article is the first in a series that will be written alternately by myself and current Game Design student Hampus Gross (gd28), which are meant to help take the edge off some of the pains of working with Unity.
So, without further ado I give you: The first 8 ‘gotchas’ of Unity — in no particular order of importance.
1: It’s fine; we’ll just use Mecanum.
For those of you who don’t know, Mecanum is the fancy new bipedal animation system in Unity 4.
Let me start off by saying that Mecanum is great, if you know how to use it. What Mecanum does is read a variable and change the character’s animation based on that variable. For example, it could change your character from a walking to a running animation when it detects that their speed has changed sufficiently. Sounds super useful, and it is — however, it is a bit of a trick to get the thing to run, and it’s new, so support from inside and outside of VFS is limited. Mecanum is NOT intuitive and is a bit of a beast to set up. If you plan on using it, start early… as in, term 4 early, and learn it inside and out before trying to implement it. It is also expensive, so don’t bother using it on anything that only has a few animations; for that stick with Legacy animation.
2: Tile/Modular Level Design and Light-Baking and You!
Modular level design seems to be one of those holy grails of level design and it’s definitely super awesome and can make your level designer’s life easier (not that level designers do any REAL work). It can play havoc with your light baking, though, with each tile getting its own light instead of ‘combining’ during the bake. Check your camera settings — being on deferred lighting or not can make all the difference. This seems simple enough, but certain shaders require different camera settings, so try and plan ahead if you think you need to bake lights in your game!
It should also be noted that you could implement a script that would combine all of your meshes in unity, which is fine for a few things but will choke it with too many objects.
3: What do you mean only one person at a time can work on a Scene!?
Yup, it’s true, welcome to working on a game in a team. Unless someone figures out something amazing in the near future for version control, this is something you’ll have to deal with for the duration of your career in level design.
Here is the trick: What you CAN do is have one person work in the scene and another person adding lights into the scene, then dump all the lights into a single prefab and save that prefab. Then, even after the lighter’s work in the scene has been overwritten, all you have to do is drag in and line up the prefab full of all your lights. This won’t work for everything, but it sure can be a useful thing to keep in mind.
4: Read up on A* Pathfinding.
If you are using any sort of pathfinding in your game, you should Google “A* Pathfinding” and read the results. It’s well worth the 30-60 min it’ll take.
5: Well, there is this thing I heard about that we can just download from the asset store…..
Be careful with 3rd party assets!!! I cannot stress this enough. In my team’s game (Fragment), we used several pieces of 3rd party software and some of it was great, but some cost us a ton of time. We wound up going through FIVE character controllers before we found one we could use… I used probably 20% of the Dev time messing about with character controllers until we finally just settled on the standard one that comes with Unity.
Be careful what you download and MAKESURE IT WAS MADE FOR UNITY 4 OR LATER and not Unity 3.5 or something. Just because it comes from the asset store doesn’t mean it’s good, especially if it’s free.
This also goes for any scripts and answers you get online. Generally, the Unity forum is awesome and will solve 98% of your problems very quickly, but they are written by humans who are just as fallible as you are.
6: Make Use of the Standard Stuff in Unity!
Do yourself a big favor and see what is available in the Pro and Standard Unity asset packages that come with the engine. There are all kinds of useful bits in there, which there just isn’t enough time to cover in class — such as, water planes (the pro version is very nice!), character controllers for first and 3rd person, and a wind generator.
7: The Asset Server OF DOOM and Multiple Versions of Unity.
Yup, you probably hate it already, but you’re stuck with it, unless you took the time to learn Perforce.
This is a problem that might have been unique to my class (gd27) but something that may be of interest in future.
If you start a game project in Unity v3.X and later move to Unity v4.X any changes made to the Input inspector, or any other project settings, would cause a crash when brought down from the asset server. The moral of the story is to watch what you do when you move a project between versions of Unity and to try and test it on one machine as often as possible. Also, always save before you make an update.
As much as you hate the Asset server, I can personally vouch for the fact that there are worse things out there… I’m looking at you Cornerstone.
8: Prefab EVERYTHING!
Being able to update everything at once is awesome — as well as adding extra empty game objects to create things like compound colliders. Make use of prefabs and make sure that everyone on your team actually knows how to make use of them.
Lastly, make sure that all items inside are at 0,0,0 or as close to it as possible and don’t make a mesh into the root of the prefab!
Bonus tip for programmers: If you haven’t yet figured out what an Invoke is, go look it up; very useful!
