Creating bullets and enemies on the fly... performance?

[c.noeth]

I wonder what is best practice for creating enemy objects and bullets in a game, like for example a tower defense game where a lot of action can be shown.

Is it okay to create “towers” and their bullets “on the fly” whenever this graphics are needed? Or is this a performance problem in Corona?

What is your experience to do this kind of object creation?

Oh… and if it is okay to create the stuff during gameplay… what is the best way to remove the images? When they are not needed anymore… means for bullets when they have hit something or left the screen… or better after the level is done completely… so blending them out before with isVisible=false is enough?

[Alan_PlantPot]

If you just use isVisible=false then the object will still be in memory, and so I would only use it if you need the object to still exist.  

The way I remove an object when it is not needed is to remove the display object and then set the variable to nil:

myObject:removeSelf() myObject = nil

There is no problem creating objects as you need them, I would imagine that most developers only create bullets as they are needed. 

In fact I would suggest that in general the less objects you have “preloaded” the smoother your game will run. There are exceptions of course, if you notice that a particular object or animation or whatever is taking a long time to be loaded, then maybe you could preload that and then set isVisible=false until you need it.

[roaminggamer]

My experience has been that it is perfectly fine to create new assets as needed.  However, if you’re creating hundreds to thousands in a frame, then it is not fine.  

There will always be a limit/threshold where you find the creation of new display objects overwhelms the ability of the hardware to keep up.

My suggestion is that before you do anything complex, approach it as if you have no budget limit.  Make simple test cases that approximate your end result, then double that value.  If it still works well on low-end devices… awesome.  If not, time to investigate the cause of your slow downs and then deal with it.

Also: Please note that we talked about object caching on Corona Geek #178 and I made some examples:

http://github.com/roaminggamer/CoronaGeek/raw/master/Hangouts/Tips_and_Tricks/objectCaching.zip

PS - Once you start worrying about optimization and caching, you’ve added a whole new level of complexity to your development.  The caching itself has a cost that you must understand very well to properly implement a usage specific solution.  Generic solutions exist but suffer from unnecessary computational overhead.

[Alan_PlantPot]

Well said roaminggamer. On a related note, I’ve found this profiling tool to be useful in the past:  

http://www.mydevelopersgames.com/profiler.html

It’s good for seeing which functions/loops/etc are taking the longest, which is helpful for identifying slowdowns. It’s not perfect (sometimes it will tell me the wrong function name but the correct line number), but it’s definitely assisted me in hunting down pieces of code that I thought were fine but were in desperate need of optimisation.

[Danny]

Premature optimization is the root of all evils.

If you do see performance issues with creating your objects on the fly however, I recommend creating a pool of objects at the start of the level.

So you would create say a pool of 50 bullets. When one hits an enemy or goes off screen, you would simply hide it (say off screen and isVisible = false). Then when you want to fire it again, set its position to the gun and make it visible again.

This works wonders for performance, but is trickier to set up.

So if you don’t have performance issues, you’re good. If you do, you can look into implementing such optimizations

[Alan_PlantPot]

If you just use isVisible=false then the object will still be in memory, and so I would only use it if you need the object to still exist.  

The way I remove an object when it is not needed is to remove the display object and then set the variable to nil:

myObject:removeSelf() myObject = nil

There is no problem creating objects as you need them, I would imagine that most developers only create bullets as they are needed. 

In fact I would suggest that in general the less objects you have “preloaded” the smoother your game will run. There are exceptions of course, if you notice that a particular object or animation or whatever is taking a long time to be loaded, then maybe you could preload that and then set isVisible=false until you need it.

[roaminggamer]

My experience has been that it is perfectly fine to create new assets as needed.  However, if you’re creating hundreds to thousands in a frame, then it is not fine.  

There will always be a limit/threshold where you find the creation of new display objects overwhelms the ability of the hardware to keep up.

My suggestion is that before you do anything complex, approach it as if you have no budget limit.  Make simple test cases that approximate your end result, then double that value.  If it still works well on low-end devices… awesome.  If not, time to investigate the cause of your slow downs and then deal with it.

Also: Please note that we talked about object caching on Corona Geek #178 and I made some examples:

http://github.com/roaminggamer/CoronaGeek/raw/master/Hangouts/Tips_and_Tricks/objectCaching.zip

PS - Once you start worrying about optimization and caching, you’ve added a whole new level of complexity to your development.  The caching itself has a cost that you must understand very well to properly implement a usage specific solution.  Generic solutions exist but suffer from unnecessary computational overhead.

[Alan_PlantPot]

Well said roaminggamer. On a related note, I’ve found this profiling tool to be useful in the past:  

http://www.mydevelopersgames.com/profiler.html

It’s good for seeing which functions/loops/etc are taking the longest, which is helpful for identifying slowdowns. It’s not perfect (sometimes it will tell me the wrong function name but the correct line number), but it’s definitely assisted me in hunting down pieces of code that I thought were fine but were in desperate need of optimisation.

[Danny]

Premature optimization is the root of all evils.

If you do see performance issues with creating your objects on the fly however, I recommend creating a pool of objects at the start of the level.

So you would create say a pool of 50 bullets. When one hits an enemy or goes off screen, you would simply hide it (say off screen and isVisible = false). Then when you want to fire it again, set its position to the gun and make it visible again.

This works wonders for performance, but is trickier to set up.

So if you don’t have performance issues, you’re good. If you do, you can look into implementing such optimizations