Was ist die schwerwiegendste Einschränkung der Einheit? [geschlossen]


Nachdem ich diese hitzige Frage über Unity vs. UDK vs. ID gelesen habe, bin ich neugierig zu wissen: Was sind die wiederholt auftauchenden, lähmendsten Einschränkungen von Unity?

In order to keep this question non-subjective, again, I'm talking about the top repeated offender(s) of Unity are. This is something that, as a Unity user, you really wish someone had told you about before you started using it.

I have heard from someone that Unity does not deal well with version control, since it generates a lot of binary files (which are un-diffable). This, to me, is not really crippling as I work alone.


DV but no comments, and on a 2.5yo question? Why is that?

Probably just stumbling over it randomly. This question is clearly opinion-based from the get-go. Saying "In order to keep this question non-subjective" doesn't make it not subjective because the top repeated offender you find most annoying won't be the same as the next user's top offender. Such lists have little to no value and only help to enforce myths, for instance what if everyone said "X is the thing" but X gets fixed in a Unity update a week later yet the top-ranking answers probably remain unedited with "X is a HUGE problem" on top of their lists even years later.

Plus, which answer is acceptable as the correct one? If you think about it, none of the answers should be accepted as the answer because there's no right way to answer this question. That's probably the #1 indicator of a subjective question.



Let me preface this that the Unity guys have been pretty good about hearing the major qualms that their community faces and eventually gets around to promising to improve things. There are also a lot of issues that only come up on certain platforms or are a matter of personal preference or specific issues of the game you're working on.

That being said:

1) Poor source control integration and large team tools. As you mentioned, lots of non-diffable binary files. The editor ignores the read only flag for scene files. The actual files you have to check in isn't immediately obvious. Some of this is being rectified in 3.5 with SVN and P4 integration. There is also promises of text based scene formats. UPDATE: The text-based scene format is now available in the Pro version of Unity. See here.

2) Slow, programmer centric UI tools. Each widget is its own draw call, which has a lot of overhead on mobile platforms. There isn't the concept of things like panels with animations and all that other fancy stuff that makes a UI feel good without rolling it yourself. There is a promise of a new UI system on the roadmap (3.6?). There are some third party tools but they're not great.

3) Really rudimentary particle editing. They're promising a new curve-based system in 3.5, though. UPDATE: This curve-based system, called Shuriken, is now available. See here.

4) You can't nest prefabs. A small issue but when you're used to working with the prefab system and all the power it provides you, it can get frustrating. This has been promised but no specific date. UPDATE: You now can nest prefabs.

5) Next to impossible to get an iOS game under the over the air limit. The binary alone is like 8 megs in a best case scenario. This isn't something that's easily fixable.

6) Null reference exceptions crash platforms that don't allow JIT compiled code. On standalone or web versions, NREs are caught. It's still an uncaught exception, but at least the application will try to continue running. On iOS, it crashes the device. You can put it in debug mode and catch some types of exceptions, but performance suffers.

7) When working on a multiplatform game, whenever you switch build targets you have to reimport everything and that takes a long time. I've worked around this by actually just having multiple copies of the project on disk. Apparently there's an imported asset server coming in 3.5.

@iamcreasy, Suit yourself, DUDE. "While Dropbox functions as a storage service, its focus is on synchronization and sharing. It supports revision history, so files deleted from the Dropbox folder may be recovered from any of the synced computers.[33][34] Dropbox's version control also helps users know the history of a file they may be currently working on, enabling more than one person to edit and re-post files without complications of losing its previous form.[35] The version history is limited to 30 days. A paid option for unlimited version history called "Pack-Rat" is available." -Wikipedia

Maybe I'm being unfair, but I'm thinking NullReferenceExceptions are a programmer fault; you should be checking your incoming parameters. Of course, that'd be easier to enforce if we had some sort of code analysis add-on for MonoDevelop like you get in VisualStudio...

@ashes999 There is always some terminology you'll have to have to learn, with a new technology. Words are our handles on concepts. The same goes even for basic Flash. The hype around Unity's usability is not for nothing though. It lowers the barriers to entry for non-professional developers, and enables pros to do far, far more with far less. Don't worry too much over the supposed limitations. Chances are most of them may not even be a barrier for you. The only thing I would be concerned with is null pointer exceptions, and those are debuggable.

How does Tedrad's answer hold up now in Unity 4.1.x? Does anyone know?

When you say 'You can now nest prefabs' What are you referring to? Maybe this functionality has been removed since the question was last edited? Or are you referring to this addin?


When me and a friend evalutad Unity for a bigger project we found that one of the bigger problems was the performance with their software skinning. If I remember correcly we had something like 10 animated objects with about 1000 verts each and I got 20fps while using a midend computer... Not very good...

How long ago was this? It seems like almost every version there's something in the release notes about improved skinning performance. In face on iOS they switched from doing GPU skinning to using the FPU since it was a lot faster.

It was a month ago...
Cpt. Red


My number one problem was re version control. The solution? Just use DropBox for Unity projects. Provided you set it up correctly (i.e. pay for their "PackRat" service), it maintains revision history. It's also much easier to collaborate with designers, this way, who don't want to know about traditional version control, DropBox gives them a transparent solution. The downside is branching / merging aren't really supported in the way they are in eg. git, SVN.

For those who doubt...

While Dropbox functions as a storage service, its focus is on synchronization and sharing. It supports revision history, so files deleted from the Dropbox folder may be recovered from any of the synced computers.[33][34] Dropbox's version control also helps users know the history of a file they may be currently working on, enabling more than one person to edit and re-post files without complications of losing its previous form.[35] The version history is limited to 30 days. A paid option for unlimited version history called "Pack-Rat" is available.

See here for a solid reference from the Unity forums.

Other than that, the only thing I found annoying about Unity is that it doesn't have an application entry point in the way that C does (main()) or AS3 does (document class). But you just put your app init on an empty GameObject, not a big deal. The code flow is a bit different around this inherent structure, too, but again, nothing too hard to get to grips with.

As for the license, most people don't realise (and I am particularly referring to small indie operations and hobbyists who may not have the money to pay for a pro license and the asset manager addon) that you can do just about everything you could ever want with the basic/free edition. Really, it is not some huge barrier, the Unity team have been very generous.

Dropbox, yech. But +1 -- this is essentially what I was after.

Hehe, I think any developer would feel the same. But hey, if it does the job...

We use Git with Unity. It takes a little work to set up the .gitignore files, but it works, and gives the full VCS feature set.

We use Mercurial (with BitBucket) with Unity and works great once you configure the .hgignore files properly.

@JD (&Kylotan) - How did you get around the issue with scene files not being mergable?


I thought of another major limitation that is annoying me on a daily basis so I'll post this separately.

Unity3D wants you to edit your scripts in MonoDevelop, specifically an old version of MonoDevelop that they distribute. The "Find In Files" functionality of this version is broken, in that using it usually causes the IDE to hang, rendering it useless.

This would be a big irritation with any engine, but it is a massive irritation with Unity because it encourages a very decentralised system of separate components acting on the various game objects. But how can you find out which components access which properties if you can't even search across the various components?

EDIT: This answer was posted in 2011: the Find In Files bug was fixed some time ago, thankfully. And as commenters say, you can edit your code in other editors (though your choice is limited if you want to be able to run in the debugger).

For what it's worth, you can use any IDE you want with Unity (I use Visual Studio Pro). But if you want to use the debugger you're limited to MonoDevelop.

Yeah, the debugger is quite important (even though MonoDevelop's isn't that great). Plus, unfortunately it says it doesn't work with Visual Studio Express. I don't know of any other C# IDEs that people use. But really, the one that ships with Unity should be in a better shape.

You can also use other text editors like Sublime Texthttp://wiki.unity3d.com/index.php/Using_Sublime_Text_as_a_script_editor

I haven't tried it, but I've read that there is now a way to use Visual Studio for debugging (via plugin, I think). Might be that this is only for the Pro version though, I'm not sure.

FWIW, UnityVS makes Visual Studio integration much smoother. You can debug, step over, etc.


For me the most serious limitation is in the EULA:

"Gambling Restrictions You may not distribute or publish any Licensee Content in connection with any Gambling Activities without a separate license from Unity."

This means that since v4.0, you cannot use Unity for games involving cash / chance, unless you or your clients are prepared to pay an additional license fee which is negotiated on a case by case basis. I.e. they see how much you are worth and tax you accordingly, with 6 figures being quoted.

More disturbing is that who knows what they will add to v5 EULA. Perhaps all social games? Perhaps all multi-player games?

Any developer using Unity is at risk of being held to ransom in a future release.

Any third-party tools or software could add (or remove) EULA clauses in new versions. I don't really see how that is specific to Unity. Further, without supporting evidence it seems weird to claim that the no-gambling clause is serious enough to be the most damning limitation of the software in general, which is what the original (admittedly now off-topic) question was trying to get at. Unless the majority of Unity games were made relying on gambling as a core feature, this answer reads more like a rant.


Good question. For me, the biggest problem is the GUI. I don't mind it being programmer-centric, but I do mind the awful way in which GUI objects are functions rather than an object, and that GUI handling is all stuffed into one function call which is used for rendering and for event handling, and that there's no integration with the input system (meaning clicks on GUI elements can be interpreted as clicks in the world), etc.

A secondary problem is the lack of adequate version control support (mostly because the system uses the directory layout as the project layout, which confuses the VCS when you move or rename things), but this can be worked around and isn't a problem for everybody.

You can query the GUI system to see if a click was consumed by it, and then ignore the click in your world objec picking code. Cumbersome, but works.
Sean Middleditch

How would you do that?

There's a property on the input system object to get the "hot" element's id, which will be zero if there is no GUI element under the cursor. Forget the exact property name, should be in the unity scripting reference though.
Sean Middleditch
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.