Archive for April, 2015

Current editor issues in Unity 5

April 3rd, 2015 17 comments


First, let me make something clear: I love Unity. I use it every day and it allows me to build my dream game. So don’t take anything I’m about to say as “oh you just don’t like Unity”. I love it to bits; it’s a fantastic tool.

Now that this caveat is out of the way, let’s dig into things which, from my point of view, ought to be addressed. Keep in mind that I spend an ungodly amount of time using Unity to create Ghost of a Tale. So anything that breaks my workflow is really frustrating to me.

As you’ll see those issues are mostly geared towards ergonomic and manipulation of game objects in the editor. To be fair, they don’t strike newcomers; they only become a hindrance for experienced users who rely on every little thing to make their development life easier.

Still, I don’t think that should detract from their pertinence. So here they are, in no particular order:


1) No lateral slider in hierarchy window:

If you need to dig into a complex hierarchy of game objects, you actually have to resize Unity’s window layout. Try to imagine Maya without a lateral slider in its outliner and you get the idea.


2) No drag-and-drop component reordering:

You can click and drag a component directly from one game object (in the inspector) to another game object (in the hierarchy window), but you can’t simply click-and-drag a component up or down on the same game object.

This means tediously clicking dozens of times just to move a newly added component to the top of a long components list.


3) No way to make an object unselectable in the scene view:

In any 3D application it is very important to see some items while not being able to interact with them by mistake. We need a way to mark some game objects as visible but unselectable in the scene view (while still being able to select them in the hierarchy of course).


4) Lack of true labeling system:

There’s no proper labeling system in Unity. Only tags. And only one tag per game object. No way to tell an item it is “Ground”, “Rock”, “Cold”. It can only be one thing.

That’s a big limitation. Being able to set and get game objects’ labels would be a tremendous advantage for development and gameplay purposes.


5) Base selection is not working:

[BaseSelection] is a simple line of code you can add within a component script to make a group (a hierarchy of game objects) behave like a prefab.

It’s super useful as not everything can be one unique prefab; sometimes you want an empty game object housing a couple of prefabs without actually turning the whole thing into a prefab.

So adding that line makes clicking anything in that group select the root node; same behavior as a prefab without actually being a prefab! Super cool stuff.

Except it’s broken. Basically it only behaves as expected during game mode. But if there are prefabs within the group then it doesn’t work outside of game mode (which defeats the purpose).


6) Number appended at the end of a duplicated game object:

This is kind of a recent behavior in Unity. At first I thought of it as a mere annoyance; Unity started renaming copies of duplicated game objects (prefabs or not) by appending a number to the copies’ name.

One thing to know: in Unity it’s never a good idea to rename a prefab in the scene. It’s perfectly possible, but not very wise.

Because if you do, then you’re never quite sure of which was the original prefab’s name. So you need to click on Select to select the prefab on disk to be certain that it’s the right one. Quite cumbersome.

And now, since Unity adds numbers to the name of a duplicated prefab, if you hit “Apply” on that prefab copy, the original prefab (the one on the disk, without the number in the name) will be affected. Without being renamed of course.

And once again renaming prefabs in the hierarchy and “unpairing” them from their original name is asking for trouble. I think this was implemented thinking it would help the user but that’s just not the case. There should at least be a way of opting out of this automatic behavior.

Update: I have stopped worrying and learned to love the numbers-at-the-end. More seriously Unity now uses “(1)” whenever you duplicate a game object and at least it visually stands out. The discrepancy between the original prefab name and the object name remains, but I guess I can live with it.


7) Game objects jumping places in the hierarchy:

Unity fairly recently introduced a new concept of hierarchy sorting, which is really neat. Basically, things are not sorted out by alphabetical order anymore. It means a game object stays where you put it in the scene’s hierarchy.

As I said, really neat. Except it’s still not working properly. Game objects (mainly prefabs) keep changing places when you save a scene, close Unity and reopen it. Which is tedious when you do this often.

Edit: I’ve now changed my way of working to bypass that bug and I don’t use prefabs at the scene’s root level anymore. So I don’t deal with that annoyance anymore.


8) Scene camera teleporting while Unity loads textures:

When moving through the scene view Unity will freeze once in a while to load up textures when a mesh with new textures enters frustum. Which is perfectly understandable.

The real problem though, is that the WASD + right-click input detection of the scene camera does not get notified of the freeze. Meaning that if the texture takes a second to load, then -when you get control back- your camera has actually teleported way away in the last direction before the freeze happened. Just as if you had kept moving at full speed in that direction for a second.

This aggravation would be gone if the editor’s movement input routine would just get suspended while the editor loads the new textures and until actual control is given back to the user.


9) No way to get the members of a layer:

A command like FindGameObjectsWithinLayers() would be extremely useful as there is currently no way to get the list of gameObjects contained within a layer. Which forces us to rely exclusively on using FindGameObjectsWithTags (cf. point 4 for limitations of the Tag system).

(Edit: I’m aware of the solution proposed here but while it does eventually let you find the members of a layer by recursively iterating through every game object in the scene and checking if their layer is the one you’re interested in, it can’t really be considered an efficient solution)


10) No way to access inactive game objects via code in an editor tool:

Let’s say you have deactivated game objects in your scene, at root level, and you want to access them via code for an editor-only tool? That’s not possible.

You could of course list all the game objects in the scene and find out which ones do not have a parent and are inactive, but that means you then have to manually filter internal Unity objects corresponding to that criteria by name like “” (whatever that one is!), “PreviewMaterials”, “HandlesGO”, etc… And that is a really dirty and dangerous way to do things. Especially when the goal is to manipulate (or even destroy) those objects.

There is a need for a command (or a flag) to find deactivated game objects (at least in the editor if not in-game).

Edit: There is actually an undocumented command called HierarchyProperty(HierarchyType.GameObjects) which will return a list of hierarchy-only objects including inactive game objects (as mentioned here: Thanks to Thomas for the heads up!


Finally, please let me know if you can think of anything else or if you’re aware of a way to bypass any of those limitations.

And if I’m actually wrong about any of those points, do let me know! My goal is not to crack down on Unity but rather to streamline my workflow; so if any of these can be taken off the list I’m more than glad to do it! :)

Categories: Unity, update Tags: