Home > Unity, update > Current editor issues in Unity 5

Current editor issues in Unity 5

Unity-5-logo

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: http://answers.unity3d.com/questions/27729/finding-the-root-gameobjects-in-the-scene-.html). 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:
  1. April 6th, 2015 at 16:42 | #1

    Hi,

    I agree with most of your sadness except for one point : adding a number or whatever at the end of a copy was a long long overdue necessity. Unity was one of the very very rare piece of software where copies had the same name as the original by default and it’s a very bad default behaviour IMHO. If your code relies on the old behaviour (i.e. if you identify your objects by their name), it’s probably a good thing to change it and not rename your copies manually.

    Creating your own labelling system is actually not that complicated and you should definitely do this instead of using names if you do. I’m very curious to know how you work on Ghost of Tale and I’d be more than happy to help, so do not hesitate to contact me :)

    – Alain

  2. Seith
    April 7th, 2015 at 08:32 | #2

    Hi Alain, I totally understand why you would like this behavior and I respect that of course. :) All I’m asking for is having an option to opt out of that behavior. Like the new hierarchy sorting; Unity provides for a way to revert to alphabetical sorting for those who prefer it. It’s not like Unity suddenly HAS to rename copies; technically it doesn’t rely on names but instead uses internal ID numbers. So non-unique names are perfectly possible (as opposed to say Maya).

    Also I’m not sure I follow you when you mention “using names”. In general relying on names to identify root objects in your code is never a good idea (and comparing strings is rather slow). In this case I was referring to the Tag system. Which is very fast to query but forces a unique tag on any given game object. Now if you actually extended Unity’s Tag system to allow multi-tags on a single object I’m VERY interested indeed! 😀

  3. April 7th, 2015 at 10:07 | #3

    It doesn’t HAVE to rename copies indeed but it’s ‘safer’ that way or at least it doesn’t promote risky behaviours. If you’re not using names to query lists of objects in your scene (what I called “using names”), you shouldn’t be bothered all that much by this change.

    Tags are just a way to keep lists of objects. Maintaining lists of types of objects whether you add them in the editor or during runtime should not prove difficult. Never bothered to really do this for the editor because we’re using Unity as an asset library and a 3D API. All our games logic run on a single Monobehaviour. We pretty much never add Scripts to GameObjects and keep lists of objects in the managed environment which is faster than accessing Unity all the time.

    Since I’m willing to start a new game prototype with a different approach on my free time. I’ll try to think of a quick way to handle that…

    – Alain

  4. July 18th, 2015 at 19:53 | #4

    I think issue 2) -component reordering- is solved now 😉 https://www.assetstore.unity3d.com/en/#!/content/39677

  5. Seith
    July 22nd, 2015 at 20:10 | #5

    Thanks for the heads up Jose! I’ll need to find some time to test your solution. I’m very good at making things crash… :)

  6. July 23rd, 2015 at 15:37 | #6

    Hi Seith!

    Firstly, I’ve been following your site since your times with CryEngine, and I’d like to say that I love your work!

    Anyways, after reading through your post I actually stumbled upon a solution for #3 a couple days ago. On the top right corner of the Unity Editor window under the layers drop menu, you can show/hide layers as well as lock them from being picked. In my own project, I’ve used this method to prevent myself from accidentally selecting sky elements from within the scene view.

    Hopefully this helps and makes your development process smoother!

    – Vadim

  7. July 23rd, 2015 at 15:45 | #7

    @Vadim
    Alternatively, if you need to lock individual objects. The below editor extension may be heaps of help!
    https://www.assetstore.unity3d.com/en/#!/content/28577

  8. Seith
    July 23rd, 2015 at 21:04 | #8

    Hi Vadim! Thanks for your suggestion; it can be useful in several cases indeed. Although what would really be needed is a way to simply lock an item from within the hierarchy window without having to juggle with layers. Anyway, thanks again for this workaround!

  9. Seith
    July 23rd, 2015 at 21:05 | #9

    Thanks Vadim, I will give it a try!

  10. September 10th, 2015 at 16:54 | #10

    Hey Seith, for 4)
    A very simple and useful way to use multiple tags is to add “_’ or whatever you like between the keywords, eg:

    Floor_Rock

    Then in your script you can use tag.Contains to search for keywords, eg:

    if (transform.tag.Contains(“Rock”))

    Does this help?

  11. September 10th, 2015 at 16:59 | #11

    But for sure I agree a true multi tag feature would be better!

  12. Seith
    September 10th, 2015 at 20:24 | #12

    Thanks Lucky, that’s a good idea. I’d be interested to find out if it’s significantly slower than just accessing tags using CompareTag(). I remember a while ago when I started using Unity I used to manually compare tags and strings (before I discovered CompareTag) and THAT was awfully slow!

  13. lucky
    September 10th, 2015 at 20:37 | #13

    You’re right the only drawback may be performance, however as long as I use it for my game I get good FPS. So I’d guess only very heavy use of tags should be avoided, or low performance devices such as smartphones may be affected.

  14. lucky
    September 10th, 2015 at 21:32 | #14

    Hey, i’ve just tested 100 cubes raycasting in the floor direction on every frame, assigning a value if the tag is true.
    Tested directly in-game ( + player, backgrounds, textures…). Would be interesting to know how you tested it?
    Here are my results:

    CompareTag: max 280fps
    Tag.Contains: max 281fps

  15. Seith
    September 11th, 2015 at 15:42 | #15

    That’s cool! Thanks for doing the test! It’s been a long time since I tried manually comparing strings in Unity so I can’t remember exactly what I was doing but that was probably not very smart… :)

  16. Mark
    November 25th, 2015 at 05:14 | #16

    Hey Seth,

    I’m curious on your thoughts about Cryengine vs Unity? I’m looking to build a fps/rpg or maybe just go for an rpg in Cryengine. I know it seems to cater to FPS games and I have used Unity but I feel for the realistic look and so many built in assets that Cryengine has for my game Idea, that it might be the best way to go to make a game I have in mind. It will have a forest for it’s open world but was curious with your experience what would be the fastest way to create a game that is realistic with a good game mechanic. Do you think Unity is some how better then Cryengine? Thanks for making the MayaCE, I found you looking for a tool to kinda streamline the workflow a bit. Looks like it will be useful.

  17. Seith
    December 5th, 2015 at 10:14 | #17

    Hi Mark, I haven’t used the CryEngine for 3 years so I really don’t know where the engine’s at currently. What I do know though is that nowadays Unity is a more versatile engine and more than capable of delivering a very satisfying level of visual fidelity. As far as assets are concerned you could find pretty much anything you need in the Asset Store (if you can’t create them them yourself that is). So I do believe Unity is the better engine in terms of simplicity of use and control over what you do and how you do it. Maybe you could do more flashy things quicker in the CryEngine, but if your goal is to actually create a complete game and you don’t have a tech team with you, then Unity is the way to go. Hope this helps!

  1. No trackbacks yet.