I know pretty much zero about game performance in Unity. I am trying to figure out if I can afford to put this feature in my game: I would like to have the enemies killed to pile up in a sort of heap, so I was thinking about not using the same old destroying routine after they die.

The game itself is really simple, it's 2D and for mobile. It has a fixed background and there's not much moving around aside from the player, the enemies and few npcs (which would get destroyed when offscreen), we're talking around ten 32X32 sprites onscreen at a time. Once dead the enemies would not be removed but they wouldn't need to be raycasting, colliding, ecc.. Just only be there for visual sake.

So the question is: would a mobile device easily handle not removed enemies in the order of a hundred or so (I could destroy those at the bottom of the heap) and not slow down or crash the game? Are there some example of this kind of feature (other games that don't destroy dead enemies)? Or is there a good practice too keep enemies in game without impacting memory resources?

Thanks for the attention.

  • 3
    \$\begingroup\$ If you haven't watched Unity's tutorials you can look here, it can give you ideas. You can make so the "oldest" dead enemy is reset as newly spawned enemy once some threshold of enemies is reached. \$\endgroup\$
    – Nikaas
    Aug 3 '16 at 20:37
  • 2
    \$\begingroup\$ 10 sprites? Meh. No problem. Add the feature. \$\endgroup\$
    – Evorlor
    Aug 3 '16 at 20:37
  • \$\begingroup\$ @Nikaas Well I guess pooling while being more efficient than destroying/respawning would have have the same visual effect of 'eliminating' the enemies so not actually my goal. \$\endgroup\$
    – Uknowho
    Aug 3 '16 at 20:48
  • 2
    \$\begingroup\$ I am not sure how exactly I would do this in 2d unity, but the usual optimization method I would be using here would be to have one texture onto which every new corpse is drawn and then just draw that one texture on each render-call. \$\endgroup\$
    – Philipp
    Aug 3 '16 at 21:20
  • 2
    \$\begingroup\$ The most reliable answer to any performance question is to profile it yourself on your target hardware. That way you know exactly how it performs in the context of everything you're doing, the details of which we don't know. There's a decent chance it won't be a problem and, as Philipp notes, there are ways to mitigate the cost if it proves to be an issue. \$\endgroup\$
    – DMGregory
    Aug 4 '16 at 3:10

You must log in to answer this question.

Browse other questions tagged .