Discussion Is it better to Instantiate and Destroy or to Recycle when visualizing cards.

Hi, I am currently making a game where you can control on multiple characters, with each of them has their own hand of cards.
I have an Object that visualize their hand when the player click on one of the characters. Each of the cards is then represented with a GameObject with a SpriteRenderer component.
The question is that should I destroy every one of those object every time the the chosen character change or there is no more chosen character, and make new one for the newly chosen characters. Or should I store those component in a list, and deactivate/activate them and only change the values inside them.

 

Use the simplest (cleanest code) solution that works and does not cause a very apparent performance problem.

 

Another possibility is to just make a separate instance of the visualizer object for each character and then just flip which one is visible.

 

It often depends on the specific aspects of your game. You could re-use the same sprite renderers and just swap out the sprites for the specific cards. When not being viewed that "hand" of sprite renderers is hidden, and no sprites need to be assigned. Depending on how many types of cards there are, you may want to manage which card sprites are loaded in memory at a given time. If those sprites are all in the same texture atlas, it's possible for the GPU to render the whole hand with a single draw call. However, it depends on certain factors, so you would want to use the frame debugger to see if it is actually being rendered that way. Putting all the sprites into one big atlas though would have an effect on how the sprites are loaded into memory. So, you have to consider those trade offs when organizing and loading your sprites. The best way to balance the pros and cons depends on the particulars of your game.

 

This is SO important early on in prototyping. This is absolutely CRITICAL!

Early unnecessary complexity sinks so many projects and makes them so unpleasant to work with.


And whatever you do, do NOT reach for pooling, EVER:

The costs and issues associated with object pooling / pools:

https://forum.unity.com/threads/object-pooling.1329729/#post-8405055

https://forum.unity.com/threads/object-pooling-in-a-tower-defense-game.1076897/#post-6945089


DO NOT OPTIMIZE "JUST BECAUSE..." If you don't have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window -> Analysis -> Profiler

Failure to use the profiler first means you're just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

Remember that you are gathering information at this stage. You cannot FIX until you FIND.

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Don't forget about the Frame Debugger either, available right near the Profiler in the menu system.

Notes on optimizing UnityEngine.UI setups:

https://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

At a minimum you want to clearly understand what performance issues you are having:

- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as "reimport all textures as 32x32 tiny textures" or "replace some complex 3D objects with cubes/capsules" to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you're properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

"Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs." - Mike Acton

 

The traditional trick, often known as "decoupling", is to write functions to push aside the exact way it's done. Everywhere in your program call your showCardsForPlayer function to put them on screen, and your new hideCardsForPlayer function to get them off. Inside, write those functions the simplest way possible. If that's slow or looks like crap, you can still test your game, build it out, and any time you want you can go back and rewrite the insides to be nicer -- like if it was using Destroy and Instantiate, you can switch to setting them inActive and Active without having to redo anything else.