Will too many asteroids kill the game?

[RPC]

This is a tad bit overkill but yeah, just wondering.

[digdug]

I wonder if there is a spaceObj limit for each system.

[Jay2Jay]

I made this for you

[george moromisato]

I haven't done any empirical tests, and perhaps someone can supply some numbers (how many asteroids do you need before the game starts slowing down?)

In general there are two performance issues:

1. Linear update time: The game updates every object in the system once per tick (1/30th of a second). That means we execute some amount of code for every object. For an asteroid, that code is minimal, but you will eventually get a slow down. The best way to mitigate this is to decrease the number of asteroids or decrease the time per asteroids update. The latter is probably already close to (but not exactly) zero. I could get it to zero by optimizing the case of objects that do nothing in their update.

2. N-squared collision detection: For each object we loop to see if it hit anything. This is a double loop and thus O(n^2). If there are lots of asteroids and lots of bullets, then this could get really ugly fast. There are a couple of optimizations for this. I can use a quad-tree to only search for objects in a particular spot on the map (I have something similar today, but I bet I can optimize it). And I can optimize the time for non-colliding objects to zero.

[Arisaya]

For updates, you can used a 'touch' based system, which in worst case is still O(N), but more likely will be much less than that.

Take a queue or a stack, your pick
If anything happens to an object, (such as a collision is detected, or a script is called on it) then put it in the queue/stack. At the end, when everything needs to be updated, iterate though only these objects and update them, instead of updating everything.

Of course, depending on how the system is implemented and what the updates are doing, it could be a bit more complex than that, but it should greatly improve performance because in most cases, its just iterating through things that do nothing.

[Atarlost]

For updates, you can used a 'touch' based system, which in worst case is still O(N), but more likely will be much less than that.

Take a queue or a stack, your pick
If anything happens to an object, (such as a collision is detected, or a script is called on it) then put it in the queue/stack. At the end, when everything needs to be updated, iterate though only these objects and update them, instead of updating everything.

Of course, depending on how the system is implemented and what the updates are doing, it could be a bit more complex than that, but it should greatly improve performance because in most cases, its just iterating through things that do nothing.

That may not work for objects with timers running on them.

[Arisaya]

Hm, depends on how the timers are implemented, but in the worst case, i think you could just have a minheap of all timers pointing to the objects they are timing-on or however you would say it (thus the items closest to the top are the ones that are due to be run)

Or something