koobas.hobune.stream
UI Design - should you hide it, disable it, or destroy it when it is not in use
Hello, I've been reading a few of the best practices posts regarding UI design but still haven't found an answer to the question above. Say I have a game where I tap a button, opens up a menu. Tap another button, closes the menu. When the menu is not open, should it be there in the scene?
Should the menu be instantiated when you call it? or should it be hidden in the scene (invisible or disabled? or off-screen?) and only appear when you need it. (would it make a difference if the platform was mobile?)
My current project has it as disabled and hiding (invisible). My friend on the other hand told me that you're still taking up memory, so best destroy it and instantiate it whenever you need it. I figured instantiating something as often as an in-game menu might take time, so you'll see some noticeable lag, but in his game, it went smoothly.
So just wondering what are some best practices when designing UI in terms of optimization.
Generally, you best hide and disable it. Instantiating and destroying are the most expensive operations, so you really shouldn't use them if you don't have to and saving a few kb of memory will most likely not be an issue, but performance spikes on mobile might be. If you make something invisible, it should also be set inactive. Just good practice to prevent errors like being able to select off-screen elements with a controller or some other script accessing that shouldn't be available at that time. Also, you shouldn't care much about optimizing for speed. Optimize for maintainability. ;) Best practices are usually the ones, which make things easy to use and understand.
I agree with everything @Xarbrough said. Another gotcha that I'd add is that you don't want to make a habit of setting objects to alpha of 0 either to denote "not in use". If the alpha tweens to 0, set them to inactive after they reach their target alpha.
I've also worked on games where people moved UI elements off of the edge of the screen. This is a slippery slope, especially when dealing with multiple resolutions as "just off of the screen" could become on screen when the camera's frustum has to change to a different resolution than the default one the scene was setup in.
$$anonymous$$oving elements off screen works pretty well with the new UI system, as far as I've experienced. You can slide off panels by using their pivot in screenspace, which is always normalized, even if the screen/canvas size changed at runtime. But yea, turning off things is always a good idea.
