Best way to "destroy" and "spawn"?
On the heels of JohnP's advice to avoid Spawning and destroying too many actors in my game he suggested that I simply move the actor outside the viewing area and then back to the viewing area when it's supposed to "spawn."
Whats the simplest way to do this when making a game like a bubble shooter game? I want the actor (bubble) to be destroyed when the ball hits it, then I guess it to "respawn" above all the other bubbles...
Off the top of my head I guess: When ball hits actor; set visible to false, set collisions to off, move to (random(x,y)), then set visible to true and turn collisions back on? Is this right? Or is there a simpler way to do this?
Whats the simplest way to do this when making a game like a bubble shooter game? I want the actor (bubble) to be destroyed when the ball hits it, then I guess it to "respawn" above all the other bubbles...
Off the top of my head I guess: When ball hits actor; set visible to false, set collisions to off, move to (random(x,y)), then set visible to true and turn collisions back on? Is this right? Or is there a simpler way to do this?
Comments
thats called recycling...
i've never "recycled" before bcuz my games wouldn't work well with it, not yet anyways....
but i think ur somewhat in the right direction...
Recycling actors manually is by far the best way to go.
Ace
I don't recycle except in the most mundane circumstances.
If you are trying to get your game to run in GS on the older devices (iPhone 3G, iPod Touch 2nd Gen, etc) then with their limited amount of memory recycling is a good idea. However, if you are satisfied with Arm7 devices which have a baseline of 256MB of memory you are safe to not recycle your actors and keep your spawning / destroying logic in play.
However, one word of caution. GS does not release memory very rapidly, so it will "ramp-up" allocated memory until it figures out a threshold of max memory usage and then begin to ramp-off slowly. Basically, it allocates as fast as it can until it doesn't need to allocate anymore. This memory is then "Held" for a while because it's the memory allocation step that slows the game down GS keeps the allocation around for a while. Think caching but not quite.
So if you spawn a bunch of stuff real quick it will be slow and choppy, but if you let it keep doing that for a few cycles eventually the spawns will be smoother and the memory allocation will stabalize.
Example, the game i'm working on starts off a little bit choppy (but tolerable) and allocates 26MB of memory, but it quickly ramps up to 48, then 52MB, it levels off around 52 to 58MB of memory fluctuating around that point. Speed improves once it's settled.
However, my same game on a 3G is unplayable because the 3G doesn't have enough free memory so it has to go to swap space, constantly juggling free memory with the disk.
Therefor, if you want to prevent allocation spikes you should use recycling. A better way to do this would be to let us define an expected memory usage parameter somewhere in the settings and have GS pre-allocate the amount of memory it will need. Alas, not so lucky
I believe this is all due to the memory allocation behavior of Lua. Pure speculation.
We need a "collect garbage" behavior