Unity3D 4 Pet Peeves

I’ve been updating my older apps to use the newly released Unity3D 4 engine, as well as starting an entirely new project. I haven’t used many of Unity3D 4’s new features yet, but I figured this is as good a time as any to list a few of my pet peeves with Unity3D 4 as I did with Unity3D 3 a few years back.

It’s time Unity3D had a package manager.

Unity3D plug-ins and assets purchased from the Asset Store are invaluable. It’s becoming the most important feature that makes Unity3D the superior choice. However, managing projects with multiple plug-ins is can be a nightmare. A lot of this is how Unity3D handles file deletions.

If you click the “update” button to overwrite an existing plug-in with the latest version from the Asset Store, it may wreak havoc upon your entire project. Unity3D’s file hashing system will sometimes fail to overwrite files with the same name, even if you are importing a newer one. You’ll end up with a mess of old and new plug-in files causing chaos and mayhem. The only way to prevent this is to manually find delete all the old plug-in files before updating with the latest version.

Not to mention the fact that native plug-ins either require you to manually setup your own XCode project with external libraries or have their own proprietary scripts that edit your XCode project. Unity3D should provide an API and package manager that lets plug-ins forcibly delete and update their own files as well as modify settings in the XCode project Unity3D generates.

Let me import files with arbitrary extensions.

A minor annoyance is how Unity3D will only accept files with specific extensions in your project. If you want a custom binary data file you HAVE to give it the txt extension. It’s the only way you can drag the file in to the project. Unity3D should allow you to import files with any extension you want, but provide a method in the AssetPostprocessor API to be called when an unknown file extension is detected.

Where’s the GUI?

Come on now. It’s 2013. The new GUI has been “coming soon” for years. Unity hired the NGUI guy, which leads me to believe the mythical Unity3D 4 GUI is merely the stuff of legends and fantasies. I like NGUI but I’m really looking forward to an official solution from Unity. Although I’m not looking forward to re-writing all my GUIs once it arrives. Let’s just get it over with. Bring it on.

Monodevelop sucks.

My god. Monodevelop sucks. Lots of people use other text editors for code, but you still can’t avoid touching Monodevelop when it comes to debugging on OSX. I’m sure it can be whipped into shape with a minor overhaul, but it’s been awful for so long perhaps this is unlikely. Aside from the crashes and interface weirdness, how much human productivity has been destroyed waiting for Monodevelop to reload the solution every time so much as a single file has been moved to a different folder?

Is it time to update Mono?

While we’re at it, Mono recently updated to C# 5.0. I’m not sure if this is a big performance drag or not, but I’d love to see Unity3D’s Mono implementation updated to the latest. There are some C# 5.0 features I’ve been dying to use in Unity3D.

Tough Love

Don’t take it personally, Unity3D is still my engine of choice. This list of annoyances is pretty minor compared to previous ones. Every year, Unity gives me fewer and fewer things to whine about. It seems competing solutions are having trouble keeping up.

2 thoughts on “Unity3D 4 Pet Peeves

  1. Hey Ralph

    Thanks for the feedback. I’m pleasantly surprised that it wasn’t longer and more negative 😉 Here’s a bit for you:

    When forcing arbitrary assets to import at TextAssets, you should use the .bytes extensions over the .txt one if the file is binary. Otherwise, Unity will (going with the assumption that the file is text) apply potentially destructive encoding to the data.

    It’s a common misconception that mono upgrades make things faster. I know that’s not what you said, but I just wanted it out there.

    People speak of the new gc as the second coming of christ, but actually internal optimisations by us (as we know the exact context of your code) stands a much better chance of significantly improving this aspect of your runtime.

    Regarding the async features of C# 5, I hear you. That would be freggin sweet to play around with. However note that any mono upgrade, while not hugely complicated for us to execute, is not all roses for our users.

    As the mono project is developed, bugs are fixed. That is good. And then not.

    Unfortunately this changes the behaviour of peoples code which can quickly scale up to providing very different results in their game simulation. Obviously not only bug fixes cause behavioural changes – sometimes things just need refactoring for a brighter and happier future, full of flowers and rainbows.

    So we do not want to do mono upgrades very often. We want to group them together with other backwards compatibility breaking changes. And that is a lot of dependency planning and star alignment, which unfortunately usually translates into “not tomorrow”.

    We’re totally with you, though. Just need to do all of that blasted balancing to try and keep an optimal, least-distruptive, experience for all of our users.

    Funny story, we once had a project where we tried to do a non-breaking mono upgrade by upgrading mono and then case-by-case reverting bug fixes in the delta and other behavioural changes. Man that was crazy.

    • Yeah. I was thinking upgrading Mono would end up like AS2 and AS3 in Flash. Where they had to support both as to not break old code bases. Not as drastic a language change going from 3.5 to 5 but I bet you’d have to juggle both versions.

      Anyway, Unity 4 is pretty amazing. I just made a fully functional prototype of a new game in 2 days using Asset Store assets etc. Compare this to the muck I had to slog through to make a similar prototype just a mere 5 years ago!

      Keep it up!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s