Jump to content

  • Log In with Google      Sign In   
  • Create Account

Unity 3D Gotchas?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
20 replies to this topic

#1 Dan Violet Sagmiller   Members   -  Reputation: 896

Like
0Likes
Like

Posted 23 January 2013 - 02:50 PM

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."

My Game(s), Warp Wars is in early development and can be found here: http://blog.WarpWars.Net.


Sponsor:

#2 MrDaaark   Members   -  Reputation: 3555

Like
2Likes
Like

Posted 23 January 2013 - 04:42 PM

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.

#3 xDarkShadowKnightx   Members   -  Reputation: 405

Like
4Likes
Like

Posted 23 January 2013 - 04:51 PM

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.


Edited by xDarkShadowKnightx, 23 January 2013 - 04:52 PM.


#4 uglybdavis   Members   -  Reputation: 914

Like
6Likes
Like

Posted 23 January 2013 - 05:35 PM

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.



#5 Cdrandin   Members   -  Reputation: 443

Like
0Likes
Like

Posted 23 January 2013 - 05:45 PM

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?


Edited by Cdrandin, 23 January 2013 - 05:47 PM.


#6 Rorakin   Members   -  Reputation: 618

Like
4Likes
Like

Posted 23 January 2013 - 06:11 PM

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:


Edited by Rorakin, 23 January 2013 - 06:13 PM.


#7 swiftcoder   Senior Moderators   -  Reputation: 10075

Like
4Likes
Like

Posted 23 January 2013 - 06:40 PM

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


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#8 Casey Hardman   Crossbones+   -  Reputation: 2211

Like
3Likes
Like

Posted 23 January 2013 - 07:39 PM

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.


Edited by Sir Mac Jefferson, 23 January 2013 - 07:50 PM.


#9 Cdrandin   Members   -  Reputation: 443

Like
3Likes
Like

Posted 23 January 2013 - 07:59 PM

Here are some good practices when using Unity.

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


Edited by Cdrandin, 23 January 2013 - 07:59 PM.


#10 Dan Violet Sagmiller   Members   -  Reputation: 896

Like
0Likes
Like

Posted 23 January 2013 - 09:38 PM

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."

My Game(s), Warp Wars is in early development and can be found here: http://blog.WarpWars.Net.


#11 kburkhart84   Members   -  Reputation: 1661

Like
1Likes
Like

Posted 23 January 2013 - 11:28 PM

My two biggest issues with Unity are the GUI(as mentioned above) and the input system.

 

The GUI could really use some sort of editor.  Each frame you have to draw the GUI, and respond to it, all in the same if statement.  Yes...the same function that you call to create and draw something is also the same one that returns the status of that GUI object.  Supposedly they have a new system in the works....

 

The issue with the input system isn't the system itself, which in general works fine.  It is the fact that you don't have access to the set configuration at run-time.  You can make the player use an external "pre-run" dialog that allows them to set the keys/inputs(and also the screen rez and detail settings), but you can't do this at run-time.  This also makes in game tutorials difficult because you don't have access to the keys the player has chosen.  But even more important than that is that you can't make your own GUI system/options menus to change the control configuration.  There exists a thing in the Unity Asset Store that costs $20 I think, that replaces Unity's input system with similar function calls, but allows you to either use a default GUI to set keys, or use your own, all at run-time, and you also get access to which key the player has chosen, which is good for tutorials.





#12 MrDaaark   Members   -  Reputation: 3555

Like
0Likes
Like

Posted 24 January 2013 - 12:52 AM

The GUI could really use some sort of editor.  Each frame you have to draw the GUI, and respond to it, all in the same if statement.  Yes...the same function that you call to create and draw something is also the same one that returns the status of that GUI object.  Supposedly they have a new system in the works....

There was a talk at Unite 12 about the upcoming GUI and editor. Looks much better, I wish they'd hurry up and ship it.

http://video.unity3d.com/video/6943180/unite-2012-using-the-new-gui

Edited by Daaark, 24 January 2013 - 01:07 AM.


#13 Cdrandin   Members   -  Reputation: 443

Like
1Likes
Like

Posted 24 January 2013 - 02:51 AM

haha, check what I found http://unitygems.com/mistakes1/



#14 TwiiK   Members   -  Reputation: 148

Like
0Likes
Like

Posted 24 January 2013 - 03:03 AM

I agree with most of what's been said here, but I don't understand this:

 

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.

 

Why would you put something in the Resources folder that you didn't want in your build? And as long as you keep this in mind it surely works ok, right? Seems a bit excessive to never use it because of that. I mean, how would Unity know what to prune when it doesn't know what you'll need until you load it?

 

I more or less only use my Resources folder in my recent games because with most of my games I don't use the Unity Editor at all. They are all empty scenes and I load and create objects and maps procedurally at runtime. The Resources folder has worked fine for my needs so far. Not sure if there's an alternative to it. I put meshes in there, textures etc. and the load and assemble them at runtime.


Edited by TwiiK, 24 January 2013 - 03:03 AM.


#15 uglybdavis   Members   -  Reputation: 914

Like
0Likes
Like

Posted 24 January 2013 - 02:48 PM

@twiik  Yeah, i see your point. I'm used to artists putting assets into our game, and they tend to do stupid things like place "level collision rev 1" and "level collision rev 2" in there, using the project as a sort of backup system. And i can't seem to get my point of why this is bad across... Ever.... So we just have a policy to not use the Resources folder. But if you know whats going on and are responsible, sure go for it.

 

@cdrandin, what @Sir Mac Jefferson said. If you must use GameObject.Find to get a reference, cache it once if possible. On a recent project of mine one of the programmers made a static list in a script where each game object of that type was added on awake and removed on destroy. While this gives an easy to traverse list of objects of the type i don't know how i feel about it... Kind of dirty... But that's game development.

 

One of the other things you want to avoid is nesting game objects too deep. If you modify a parent's transform, all it's childrens transforms are modified as well. For some reason reparenting a child takes longer the deeper it is nested. Deeply nested objects also take longer to move for some reason (I can't think of why, but this does happen). Recently we had a scroll list in one of our games that ran at ~30fps. The scroll list was nested like so GUI > Menu > Submenu > Filter > Scroll List  the scroll list had about 21 List Items, and each List Item had about 5 children, nested at most 3 objects deep. Moving all the List Items out of Scroll List and into the root of the scene (That's all, nothing else) boosted our game to about 45 fps. This is one of those minor things not many people realize makes such a difference.



#16 Kylotan   Moderators   -  Reputation: 3338

Like
2Likes
Like

Posted 24 January 2013 - 04:54 PM

I know it's been said several times already but the GUI system is atrocious. Awful. Mixes logic with presentation? Yup. Lacks many useful controls? Yes. Stupid bugs, like various styles not working unless you add a dummy texture? Sure. Almost impossible to align things correctly? Of course! Shading and themes based on global variables? Uh-huh! It's an embarrassment that they haven't replaced it yet, but I suspect that Scaleform might have 'incentivized' them to make this less of a priority.

 

Other things I mentioned on Reddit recently when a similar question came up:

  • No low level tweaking possible. 95% of the time this isn't a problem. 4% of the time it's a problem but you can work around it. 1% of the time it's a real irritation. I ran into a bug with the engine just yesterday, and there's no way I can fix it, only work around it.
  • 2D support isn't there. Yes, you can use 3D as 2D, just like you can chop legs off a lizard and call it a snake. In practice you pay for the parts you don't use and it simply doesn't compare well to a proper 2D engine.
  • The component-based system doesn't suit everybody. It's hard to use well, because hardly anybody really gets how to make the best use of components yet.
  • Doesn't always play nicely with source control. It's dangerous to have 2 people working on the same scene, and updating assets while Unity is open will often corrupt the data. (Though the latter point is fixable - once you notice it - by closing Unity, deleting all the data, then updating again).

(Oh, and one more tiny thing that annoys me is that you can't just change one part of a GameObject's position, because you can't modify a Vector3, only replace it. This is only rarely an irritation, but it's an irritation nonetheless. More of a language thing than a Unity thing, but I wish they'd made that a bit cleaner.)



#17 Casey Hardman   Crossbones+   -  Reputation: 2211

Like
0Likes
Like

Posted 24 January 2013 - 05:34 PM

(Oh, and one more tiny thing that annoys me is that you can't just change one part of a GameObject's position, because you can't modify a Vector3, only replace it. This is only rarely an irritation, but it's an irritation nonetheless. More of a language thing than a Unity thing, but I wish they'd made that a bit cleaner.)

Yeah, that is kind of annoying at times.

Just wanted to note that UnityScript (aka JavaScript) doesn't have this "disadvantage", though C# does.  Not sure about Boo, though (I've never used it).



#18 Cdrandin   Members   -  Reputation: 443

Like
0Likes
Like

Posted 24 January 2013 - 06:56 PM

(Oh, and one more tiny thing that annoys me is that you can't just change one part of a GameObject's position, because you can't modify a Vector3, only replace it. This is only rarely an irritation, but it's an irritation nonetheless. More of a language thing than a Unity thing, but I wish they'd made that a bit cleaner.)

Yeah, that is kind of annoying at times.

Just wanted to note that UnityScript (aka JavaScript) doesn't have this "disadvantage", though C# does.  Not sure about Boo, though (I've never used it).

If you mean something like 

thisVector as Vector3 = Vector3(1,2,3)
print(thisVector) // Vector3(1,2,3)
thisVector.y = 5
print(thisVector) // Vector3(1,5,3)


 

If this is what you mean then Boo can do this with ease.



#19 Dan Violet Sagmiller   Members   -  Reputation: 896

Like
0Likes
Like

Posted 07 February 2013 - 08:50 AM

Time to add one of my own to this list:

 

DLL HELL!  

I've found using DLL's to be a big pain

It has been said already, but vaguely.  The specific issue I had was the Visual studio can use the DLL's, Mono can use the DLL's, but unity runs into errors with them some times.  Normally, when unity finds a script/code error, its easy to go to the source of it.  I.e. double clicking it takes you to the line of code in Mono for instance.  But if it is a DLL, it doesn't express this very well, and double clicking it does nothing.  It would be nice if it actually expanded the references, or highlighted the DLL in your assets folder.

 

Another issue is that Unity doesn't support any cross domain issues out of the box.  For instance, I'm using a JSON database with Cloudant.com to manage user accounts (not for live interactive data, but stored data only).  The problem is that I connect through HTTPS/SSL.  SSL always fails no matter who what website you try.  it has no trusted validators for the SSL.  I had to write my own security handler for accepting it.  Not too tough, but I really don't like the security implications of taking SSL into my own hands.  It now leaves my game open to proxy redirects.  Not to big of a deal, but I'll want to fix it prior to release.

 

Myths:

 - Unity has no 2D support is entirely false, from a programmers perspective.  It makes sense that in a 3D editor that 2D aspects are not included.  I don't expect any 2D object/images/buttons to be persistent   (similar to a prior rendering of a 3D model) - I've never really enjoyed WYSIWYG editors for game design, and proffer procedurally constructed environments.  I will definitely concede that from a Designer's point of view, that Unity has no 2D support, but if your building a game, and have more skills that what it takes to use game maker, I think you'll be fine with GUI.Draw, and managing you own 2D engine.

 - After a discussion with Kylotan, he brought up some significant deficiencies I hadn't thought of.  It worked for a game concept I was thinking about at the time, but not much more.

 

The component-based system doesn't suit everybody. It's hard to use well, because hardly anybody really gets how to make the best use of components yet.

I'll agree that the component based system doesn't suit everyone.  Then I realized its just a basic Decorator Pattern
, which I use all the time in my 2D games for fast development and simple management.  Once I saw that, I typically start everything from the component and head away from it where I need to.  I found it nice, but I've used it before.  I would imagine that having it forced on you as a standard for the tool without training could very well be a pain.  

 

 

Kylotan, on 24 Jan 2013 - 17:00, said:
(Oh, and one more tiny thing that annoys me is that you can't just change one part of a GameObject's position, because you can't modify a Vector3, only replace it. This is only rarely an irritation, but it's an irritation nonetheless. More of a language thing than a Unity thing, but I wish they'd made that a bit cleaner.)
Yeah, that is kind of annoying at times.
Just wanted to note that UnityScript (aka JavaScript) doesn't have this "disadvantage", though C# does.  Not sure about Boo, though (I've never used it)

 

I have to disagree here.  I'm not seeing an issue with this.  Though I'm used to using a transform instead of position when dealing with 3D.  I view the position in use of circular/spherical collision detection.  (I rely on C# instead of Java, came from an XNA world, then VB.BitBlitting, then QB.pixel/line direct, and of course text, I have java, but not as comfortably)

 

The issue with the input system isn't the system itself, which in general works fine.  It is the fact that you don't have access to the set configuration at run-time.  You can make the player use an external "pre-run" dialog that allows them to set the keys/inputs(and also the screen rez and detail settings), but you can't do this at run-time.  This also makes in game tutorials difficult because you don't have access to the keys the player has chosen.  But even more important than that is that you can't make your own GUI system/options menus to change the control configuration.  There exists a thing in the Unity Asset Store that costs $20 I think, that replaces Unity's input system with similar function calls, but allows you to either use a default GUI to set keys, or use your own, all at run-time, and you also get access to which key the player has chosen, which is good for tutorials.

 

I don't see an issue with this either.  I find their current named system for buttons to have been refreshing to see, but it really is just a named collection.  Named collections are ok, but it adds a list search every time a button is pressed to see if it is in the named button calls, and a list search for the name/key reference every time the name is used.  I tend to expect to lock in keys, or set a static variable somewhere for each key.  It can change by config, but that is still faster than the the named list by a factor of [2+ (0.5*Named Command List Count)]

 

 

I suppose a lot of the complications everyone has mentioned also stem from backgrounds, particularly Coder vs Designer. With any thing I found not to have an issue with (yet) it seems it is usually a designer/coder/perspective issue.  Overall, these have been very helpful for me.


Edited by hpdvs2, 07 February 2013 - 01:39 PM.

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."

My Game(s), Warp Wars is in early development and can be found here: http://blog.WarpWars.Net.


#20 Kylotan   Moderators   -  Reputation: 3338

Like
0Likes
Like

Posted 07 February 2013 - 11:19 AM

Unity has no 2D support is entirely false, from a programmers
perspective.

It has less 2D support than almost every other game development library or framework available. It's an engine that literally features drag-and-drop 3D support, in that you can get a 3D model rendering and animating on screen without a single line of code, but has nothing resembling similar support for 2D.
 

if your building a game, and have more skills
that what it takes to use game maker, I think you'll be fine with
GUI.Draw, and managing you own 2D engine.

 
I think you mean GUI.DrawTexture, which needs to be in the OnGUI function (which is inefficient if you don't know the tricks for it, eg. skipping rendering when the current event is a keypress etc), and most importantly, only works if your image meets a set of quite specific criteria. Only want to render part of the texture? Have to calculate the UVs yourself and use GUI.DrawTextureWithTexCoords. Want to use a non-power of two texture? Probably won't work at all.

It's adding insult to injury really that Unity features an automatic atlasing and mesh generating tool for fonts, but can't do something trivially similar for sprites.

Basically, if 2D is your most important aspect, it's hard to argue that Unity saves you much time over just writing DirectX or OpenGL code yourself. Pretty much any other system, eg. Flixel, XNA, SDL, Cocos2D, pyglet, SFML, etc etc., gives you better 2D support.

 

I'll agree that the component based system doesn't suit everyone. Then I realized its just a basic Decorator Pattern

 

I think you have misunderstood the decorator pattern, which is specifically about making a certain function or method call do different things by wrapping the call in another call.
 






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS