Depends what you game needs to be honest. If UI system is setup for your game properly you will fundamentally have less time spending on these aspects of interface handling.
For short answers.
- Should I use
RemoveFromParent()manually?
Yes, depending on the system.
- Is it better to keep one persistent UI manager that handles all widget transitions?
Yes, have a UI manager that handles these for you.
- Any risk of memory leaks if widgets are cached or reused?
When a widget is removed from viewport (remove from parent) it generally doesn’t consume memory since its not rendered. However remove from parent doesn’t destroys the widget fully unless its garbage. If a widget have heavy operations besides rendering yes it can, its better to garbage them or keep their reference somewhere and dstruct. However its very edge case scenario.
For best practices.
- Have UI Logic layers for frontend. GameLayer, GameMenuLayer, MenuLayer, DebugLayer. So you can control Z index with ease and how they behave when they are open from get go. Let’s say you insert a MenuLayer by default you can enable inputs in manager. You add a game layer, let’s say HUD Change, you can remove previous HUD.
- Have a manager to do these for you. For menu you can use stack mindset. When you open a menu over another menu, its added to StackArray and last in stack is displayed to player. When you press back, if there is something on the stackarray->is brought back and displayed.
- There is more best practices like, if a menu added to ingame, where you can interact with both like a loot dialog.How to keep track of their Z-index or change them but think you can solve those after setting the base fundamentals.
This is how I do it, can be different approaches too, however stacking is a common pattern in ui development where you make use of previusly created interfaces.
