Unity 3D Gotchas?

Started by
19 comments, last by Dan Violet Sagmiller 11 years, 2 months ago

I've been programming games for a while, and just now trying out unity. Once I got over its initial hump, I'm finding it pretty easy and nice to work with, to the point where I'm going to use it for my next game City Builder first, and then shifting into something more robust.

My question is to any other Unity 3D Devs out there; What kind of Gothca's might I expect? What limitations or issues have you had a hard time resolving (or not resolving) along the way?

Before I get to far into proofs for my game, I want to start looking at challenges that might be common with it.

where there unreasonable hassles? The content loading and descriptor engine nature are really nice.

Also to note, I'm using C# with it, instead of Java. this is In Windows, and I'm planning on picking up the 125$ Visual Studio Unity Plugin, so I can use it with VS2012 Ult.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."

Dan - "Best Description of AI ever."

Advertisement
There's a few.

Some functions just don't work. Like setter functions. If something isn't working, and using a print(whatever) to see it isn't helping, do a google search to make sure the function works. Before you spend all night recompiling the script and wondering what you are doing wrong. This has come up a few times.

The engine has trouble reporting the current window dimensions. The problem changes depending on what client your using, or if you are in the editor or not. You have to make sure you check at the right time and place to get it to work.

The current GUI system is a pain in the ass. You basically redefine it from scratch every frame with a call to OnGUI() in any random script attached to any object in the current scene.

Resource / Asset management is a disaster at times.

They can't seem to do something as simple as to let you fix your model's orientation when you import. So you end up having to create all your objects as empty nodes, and then create another node under that with your model and fix the rotation manually there.

I've found using DLL's to be a big pain. Always make sure to edit your reference's before trying to use a function or class within a .NET/mono library. Another really useful thing to know is that when playing an animation, make sure to set it's culling mode to "Always Animate" if that animation goes off the screen(if its a gun or something you'll probably always want that animation to play). It tends to be those silly little things that you wouldn't think to much about that always get you.

Don't put stuff in the Resources folder. Resources.Load might be a tempting function, but the Resources folder is never pruned; that is everything in it goes into your build.

Don't use .transform, .renderer, .collider, etc.. Under the hood .transform does a GetComponent<Transform>(), it's expensive. Instead cache components in your awake function, ie: cachedTransform = transform;

GameObject.Find is expensive as all hell.

Creating a game object from code is expensive.

Destroying a game object is expensive.

Instead of create / destroy all the time use a pooling strategy. Have the game objects in the scene and just enable / disable them. Only make new game objects when absolutely nescecarry. Calling create game object a lot will lead to memory fragmentation and your game crashing.

I have a lot of pet peves about unity, but the above are the only real issues i've found.

Don't put stuff in the Resources folder. Resources.Load might be a tempting function, but the Resources folder is never pruned; that is everything in it goes into your build.

Don't use .transform, .renderer, .collider, etc.. Under the hood .transform does a GetComponent<Transform>(), it's expensive. Instead cache components in your awake function, ie: cachedTransform = transform;

GameObject.Find is expensive as all hell.

Creating a game object from code is expensive.

Destroying a game object is expensive.

Instead of create / destroy all the time use a pooling strategy. Have the game objects in the scene and just enable / disable them. Only make new game objects when absolutely nescecarry. Calling create game object a lot will lead to memory fragmentation and your game crashing.

I have a lot of pet peves about unity, but the above are the only real issues i've found.

oh, cool didn't know that. Was wondering why some programmers did something like myTransfrom = transform on the start/awake functions.

Is there an other alternative of GameObject.Find('..') rather not doing var go : GameObject and having to drag and drop from the inspector?

You'll probably need to write your own GUI system or buy one of the GUI asset packages that people sell.

The good news is that it is not too difficult to create your own 3D GUI system from scratch. A 3D GUI is more flexible, since the entire GUI for your game can just be created at start and then disabled / enabled when needed in script (you'll need a good parenting / hierarchy setup for complex GUIs). The 3D GUI can also be rendered as 2D at anytime by simply switching the GUI camera from perspective to orthographic.

The GUI system I created for my own game in this video took me only a couple weeks, but I did use someone's free Unity Tween library for all the GUI animations:

">

Superpig's twitter feed - it's basically one long cautionary tale of Unity in 140 characters or less...

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

I think print() doesn't work in certain occasions. Use Debug.Log() instead; I've never had a time where it hasn't worked.

Also, I second what uglybdavis said about creating references to .transform, .gameObject, etc.

If you know what your GameObject is named, you don't have to drag into the inspector, just do something like this:


GameObject player;

function Awake()
{
   player = GameObject.Find("Player");
}

I use this for setting up references and such at the start of the game. This way, you're only calling GameObject.Find() at the start, and it won't cause any lag or framerate drops in the middle of gameplay.

EDIT:

Also, 2D arrays in Unity don't save like other variables do, so for example, you can't save a 2D array of nodes for pathfinding. You have to make a specific class for it.


class Array2D
{
   nodeColumn[] columns;

   public node getNode(int x,int y)
   {
      return columns[x].nodes[y];
   }
}
class nodeColumn
{
   node[] nodes;
}

That might not be 100% proper and you'd probably want functions like setNode(int x,int y) and stuff like that, but I think you get the point. Unity won't save your 2D arrays unless you kind of "hack your way around it" with classes.

[twitter]Casey_Hardman[/twitter]

Here are some good practices when using Unity.

http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/

Here are some good practices when using Unity.
http://devmag.org.za...best-practices/

Very useful link in particular. And thanks to everyone else who posted. this has been pretty useful information, some of which I can apply immediately.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."

Dan - "Best Description of AI ever."

This topic is closed to new replies.

Advertisement