Just implement your own interface, perhaps something like IResettable
, and then you can have proper control over precisely what gets reset in each script.
Otherwise, just Destroy() the object and Instantiate() fresh copies like 99% of the games out there. It’s fine. It will likely be plenty performant.
Remember, if you are doing pooling or queueing or anything complicated like that, then you become responsible for all the bookkeeping.
This means you must:
a) write a game
b) write a bookkeeping queueing pooling whatever engine, which may be HARDER than writing a game and involve way more bugs.
Do you want that?
If you haven’t measured first with the profiler to find out if you even need it or if you would even remotely benefit from it, then you are likely wasting your time and tearing up your codebase.
DO NOT OPTIMIZE CODE JUST BECAUSE… If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler means you’re just guessing, making a mess of your code for no good reason.
Notes on optimizing UnityEngine.UI setups: