• Advertisement
Sign in to follow this  

Unity Unity 3D Gotchas?

This topic is 1806 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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:

https://www.youtube.com/watch?v=LZ2KRN5nuHg

Edited by Rorakin

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

(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).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.
 

Share this post


Link to post
Share on other sites

I have to concede on the image issues.  I'll append this to my original statement.  for my usage of it, it seems to handle all the basic features I want.  But you make a good point about it not working well with sprites, as you have to reprocess the UVs

 

which is inefficient if you don't know the tricks for it, eg. skipping rendering when the current event is a keypress etc

 That is particularly interesting.  I can't imagine why that would help.  Do you have a link to anything that explains the issue?  

 

 

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.

 

After the rest of your post, this makes sense in general, but I will argue one point.  Unity is will placed to execute on a lot of environments.  that gives it more clout than DirectX, XNA or a lot of others.  But the Multi-OS issue is probably about the only thing, and if its just 2D, Java would probably be the most flexible.

 

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.

 

In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class. - Wikipedia

 

It adds a behavior to a class.  There is no limitation as to whether that is as an object or a method.  I typically use it as a series of interfaces, like IModify, IPaint, IDelete, etc...  Then I would create objects like FrictionModifier : IModify, and then add copies to lists on the gameObjects of choice so they have friction, or gravity, or EnemyMissileCollision, etc...  

 

If you perceive the decorator pattern as object based, instead of method based, then its the same principal.  You tie an object that inherits the BehaviorModifier to the gameObject of your choice, and their properties apply without affecting the rest of the game objects of the same type.  I can see the benefit of method based Decorators, but with objects, I found it easier to apply custom alterations per gameObject.

 

But back to the core concept of my quote, no 2D support is entirely false, I agree that it is partially false.  Depending on your needs for a 2D game, their stuff would be really annoying.  For a 2D space shooter with individual images, and not a lot, it seems like it would work just as well as most other basic 2D engines.  Sprites and a UI Designer, not so much.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By Nostalgic Saint
      https://play.google.com/store/apps/details?id=com.SaintSoftware.TRAP.io
      Trap.io is a game I made and released in one week . I'm in dire need of constructive criticism before I release the first big update, so that I know what is in need of a change or to be redone. Any opinion whether harsh or not will be valuable.
      Trap.io is a game where you collect the trap power-ups and place them and then lead the corresponding enemy (based on color) into the trap to destroy the enemy and score points.The game is endless easy to play difficult to master. The game features highly fast paced combat with an arcade-like feel to movement, to bring back the nostalgia from the past retro space shooter games. With addictive fast paced gameplay a mistake might be your last, keeping up with the fast paced flow games typically lasting 2 minutes, this game is all about fast movement and quick thinking with an element of strategy to trick your cunning, wity enemies into the traps to score points.
      The next planned update will include:
      Leaderboard
      Buying Skins
      Improved Ui
      Improved Overall visuals
      Improved game flow
      Sound Effects
       
      Thanks in advance. Any form of support or opinion will be highly appreciated . 

    • By Affgoo
      https://play.google.com/store/apps/details?id=com.NE.Alien
      still a lot of work to do, but its pretty stable  please let me know what you think <3
      Atlas Sentry is a game of destroy everything. Using your turret, simply swivel and shoot your way to victory, upgrading your weapons to unleash destruction on the variety of spaceships. The bigger your combo’s the more score you get! Earn silver as you play and then purchase new weapons and abilities to better deal with your enemy. Different enemies use different tactics and weapons, work out your own priorities in their destruction order. 

      Features: 
      **2 different game modes 
      **A level select mode with 20 difficult levels including a final boss, can you defeat it? **Arcade mode of endless destruction, how long will you last? 
      **High scores to compete against others, see who can take the top spot. 
       
    • By Chamferbox
      Chamferbox, a mini game asset store has just opened with some nice game assets, 
      Here you can find a free greek statue asset 

      Also check their dragon, zombie dragon and scorpion monster out:



      They're running the Grand Opening Sale, it's 30% off for all items, but for gamedev member, you can use this coupon code:
      GRANDOPEN
      to get 50% off prices What are you waiting for, go to
      http://chamferbox.com
      and get those models now!

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By DevdogUnity

      Ho ho ho
      Tis the season of Christmas surprises, and we have a awesome one for you! 🎅  
      Sponsored by all your favorite Unity Asset Store developers, Nordic Game Jam, Pocket Gamer Connects, and co-hosted by Game Analytics, we (Joris and I – Devdog) are launching the second edition of our yearly Christmas Giveaway Calendar for all Unity game developers!
      You can already now sign up right here.
       
      So what’s this all about?
      For the past weeks, we’ve been collecting sponsored gifts related to Unity (asset vouchers, product keys, conference tickets etc.), and throughout each day of December leading up to Christmas Day on the 25th, we will be sending out these sponsored gifts as early gamedev Christmas presents via e-mail to hundreds of lucky winners.
      The total prize pool is at $35,000, with over 1200 presents donated by the awesome sponsors!
       
      Merry Christmas from Devdog, Game Analytics, and every single one of the sponsors.

      View full story
  • Advertisement