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.

Thoughts?

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.

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

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.

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

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.