Taedrin
   |
Posted - 2006.08.30 16:08:00 -
[1]
 Originally by: Za Po
The main implementation issue with systemwide belts is that a belt would be composed of many billions of asteroids. Now, by itself this isn't unfeasible; you'd generate them dynamically and never actually store a billion of asteroids on the server.
However, you would have to take note of changes to the belt... chiefly, of asteroids that have been mined, how much they have been mined, and of asteroids that have disappeared due to mining.
If the systemwide belts are supposed to be a lot more static than the current belts, ie they don't respawn because there's enough of them for ever (and really, that's the main point of systemwide belts), then this data accumulates and becomes unmanageable.
So, the only real solution is to drastically change the way mining works, to some way that doesn't involve keeping track of data for every single asteroid (or even of every asteroid that has been mined).
All you have to do is designt the generator function to generate the systemwide belt based off of a density. Through out the day, as miners mine, the server keeps track of how much has been mined, and lowers the density accordingly. Here's a graphical example:
Let's say that we start with an asteroid field of 100 asteroids (10x10), before anyone touches it:
**********
**********
**********
**********
**********
**********
**********
**********
**********
**********
Now let's say that a bunch of miners come and mine about half of it:
***
***
***
***
***
***
***
**********
**********
**********
During the daily downtime, the server adjusts the density of the field based off of the fact that 49 asteroids were mined. Let's say it reduces the density by 50%:
* * * * *
* * * * *
* * * * *
* * * * *
* * * * *
Now the generator dynamically creates the asteroids fewer and farther between each other. And since we are technically dealing with a brand new asteroid field (as far as the server is concerned) it no longer has to store the changes that occured to the belt the day before - it only has to store the new density of the field!
Simple, and elegant in theory. Don't know how this would work out code-wise, though.
|