• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
hpdvs2

Unity
Unity 3D Gotchas?

20 posts in this topic

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. 

0

Share this post


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

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
0

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.

1

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
0

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
0

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.

0

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

2

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

0

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.

0

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
0

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.
 

0

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By E-gore
      Hi all,
      This is our (xDBAGames) first game
      Called Iron Dome Legacy.
      It is a Missile Command clone. In this game you control the Israeli "Iron Dome" anti missile defence system.
      Features: 
      The player has limited amount of missiles. The Iron dome system is upgradable. The money is determined by the outcome of a level. The game is free. There are only rewarded ads. We tried to create a game that has some context to the daily life, but we are sure not trying to be political here.
      I hope you could try this game, and we will appreciate any comments.
      xDBAGames is a company of two programmers. That have no experience in the video game industry, but have a lot of passion for games.

    • By UNNYHOG
      Hello, Colleagues!
       
      We have been working on our newest Fantasy style Gesture based MOBA game for a long time and it's releasing on Steam on July 26. Meanwhile you can already try it out by downloading our launcher from the website.
       
      Any feedback is welcome here. Thank you.
       
      If you don't want to play, I would love to share with you our teaser : 
       
       
       
    • By Scouting Ninja
      So I am working on a mobile game.
      It uses slides for a story, the slides are very large. Each slide is almost 2048*2048; the max texture loading size I am using for the game.
       
      My problem is that Unity keeps each slide in the memory after it's loaded, even when it will show only once per game. This leads to the game crashing on older mobiles.
      My idea was to destroy each object after it was shown using a coroutine, so it deletes the past slide and loads the next slide. This worked because instead of crashing on 23 slides it crashed on 48 slides.
      After some profiling I realized that destroy() isn't clearing all the memory that a slide used.
       
      What I want to do now is assign a limited amount of memory as a slide slot. Then I need some way to unload the slide from the slot, freeing the slot for the next slide; without Unity storing the slides in the memory.
      Any ideas on how I would do this? 
    • By LoverSoul
      Hello everyone.
      I had a problem with transferring my character from the creation editor to the game engine. I created the character in Adobe Fuse, then imported it to Mixamo to put rig and animation.
      However, the appearance of my character has deteriorated significantly, and after importing into Unity, the character even began to look like a meme from the Assassin's Creed. Can you please tell me how I can fix all this so that my character's hair does not look like bits of bacon sticking to her head, and her eyes and mouth have taken their stable position in the skull?
      Thank you for attention.



    • By ilovegames
      Simulator driving with two modes of play - a race and free game in the open world!   Features: - 2 game modes - race and free game - 3 modes of transport - Buggy, ATV, Jeep - The open world - Realistic control - Modern graphics



      DesertTournamentSetup.exe
  • Popular Now