 |
|
||
| Date: | 1996-01-09 | ||
| From: | Paul | ||
| Subject: | URGENT: Seeking details on "phased" world generation algorithm |
Back in the old days, world generation was easy: plop some land sparks in the SparkList; pick one at random, assign its 8 nearest neighbors as land or sea and add them to the SparkList; drop the random spark from the list. Iterate on this until the SparkList is empty, and voila! - you just created a world.
But this isn't how the code works any more, and here is my problem: I've forgotten many of the details of our new three-phase world generation algorithm. Following are some details, and some related questions:
Instead of individual land sparks, we now start with clumps of Mountain sparks, I think. Mountain sparks generate either mountains or land, but not water - right? This is how my printout of the (hopefully latest) code looks, but it seems appropriate to re-visit the topic and consider if the behavior is sensible. Also, my code listing is truncated at 80 columns or so, and is therefore missing some essential details.
Finally, all startup conditions (like the default probability that a mountain spark will generate a mountain for its neighbor) are lost to me, being stored in a resource rather than code. Any details you have on these sorts of items would be quite useful to me.
Other than the addition of mountains, I think Phase 1 of the new algorithm works about the same as the old algorithm (by "new," I mean, of course, the algorithm from 1-1/2 years ago).
Phase II (when's a good time to start it?) just dumps a bunch of sea sparks into the spark list and then continues with world generation. I'm not sure, but I guess this is supposed to be a performance enhancement of some sort.
Phase III (when's a good time to start it?) throws out the SparkList and assigns everything left as sea. This probably knocks a bunch of cycles off the generation time.
This is actually all pretty interesting; I'd forgotten much of it. Too bad there's *no* documentation in the code. I'm hoping that you have carefully filed away some document proposing the implementation of this, so I can get a memory refresher. And of course we should consider spiffing up the elevation algorithm considerably, right?
Duk