After a month(or maybe less?) of playing with Defold, and due to the great support of Defold Community, the game is now nearing its end. The last part, which I am not able to solve is how to create an Asteroid Field. In the testing purpose, I used a distance based creation , in which every asteroid was spawned from a fixed distance from player. But I don’t think its gonna work for very large maps like mine(spanning -3200 to 3200 pixels per map).
So, is there a more memory efficient way of spawning them so that they don’t consume much of the sprite buffers??
thanks in advance…
You can keep a list of ids / positions / types in a table, and then create/destroy asteroid GOs depending on the distance between each asteroid and the player.
If you then save these values in sub tables based on chunk you can save cpu checking distances and just check to see if the player is in a near enough chunk to make the asteroids have an active GO.
This requires an asteroid manager script of some kind. If you want the asteroids to be simulated while they have no GO currently then you’ll need to save velocity / direction etc. in the table too so it can be updated over time / move asteroids between chunks and make them active if they move into a chunk near the player.
How many asteroids are we talking about?
I won’t put it to a numerical value but will just say that they are gonna be >50 large ones active at once , with some smaller ones,
This sounds pretty interesting. Will definitely give it a try this evening…
Ok. I’m thinking that you have all of them as GOs at all times. Important then is that you don’t have scripts on all if them, at least not with an update() function. You could then disable their sprites if they are outside the screen. You can detect this through a large trigger on the player that on enter enables the sprite and on exit disables it.
But will it be possible to have so many asteroids at the same time on screen(the estimate I gave was just the no. of asteroids present at once on the screen, if I delete the rest), especially when the map size will range from -4800 to 4800 px and with the build target Android devices .
Not sure, it depends on complexity of asteroid behavior but in general I’d say yes. Is this for a mobile or desktop game?
The behavior is not very complex, just a randomizer to change the looks and a collision response and an object script which on registering broadcast ( your BROADCAST) destroys it
BTW: The game is targeted for mobile .
Well, it’s hard to say which solution will be best. I think you need to try yourself. There’s pros and cons with both.