The complex bit for this next leg of the journey, creating a world, is being able to cut the world up into small chunks that can be shown to the player at any point. I can think of two ways of solving this.
One is to load only the area immediately around the player, running the algorithms for terrain generation on the fly. The downside to this is that it is computationally intensive, and the terrain suffers from not being able to have several passes done, so it's going to be simplistic. The upside is that it is quick and easy to get it working.
The alternative is to create the world on a previous pass and store it in some manner, then send it to the program to display. This requires some computation upfront, and space to store the results, but allows a more complex world to be created since you can run several functions over the data set.
Clearly, in either case, you can't try to display the whole world at once. Instead, the attempt should be to display only portions at a time. An approach to try is to use oct-trees to store the data in memory and pass it to the program, after it has been created. I'm still not sure how that would work, actually. I have to do some reading up.
After all of Shamus' recent posts, what do you think about his solution? If I understand correctly, he's keeping the computationally intensive parts of the world limited to near the player and then having two different grades of cheaper portions in layers as you get further from the player. Then the finished profits are stored to disk?
ReplyDeleteIs that method in between the two you described here?
I can't edit my comment, sadly. Phone auto-complete changed "parts" to"profits" in my last sentence. Sorry for any confusion!
ReplyDeleteShamus' solution is closer to the second method I described, where he creates the world ahead of time, does a few passes over the information, then stores it.
ReplyDeleteHe first creates a map with the average height of each region, and all the other qualities each region will hold, then based on that output places rivers and adjusts height and other details to account for it, then generates the weather for each region based on terrain features, distance from coasts, rivers, latitude, etc.
So you can see, there's a previous step, before showing anything to the player, where he runs several times over his data, detailing the world.
Personally, I think it's the right approach, the alternative requires less storage space but makes a sort of disjointed, static world (admittedly, not needing to store anything means you can have an infinite world as well, instead of the 32kmx32km island he builds).
On what I differ in my planned approach with him is that his high level overview of the world (the pixel-per-region map) and the ground level appearance of each region are independent of each other. Each region doesn't know anything about its neighbors.
My planned approach is to create a map with a function that can produce more and more detail on subsequent iterations. That way, the large-scale map is a low-detail version of the ground level map. I won't have several regions, but a simplified world. As more detail is necessary, it would be generated on the spot. I wouldn't need to generate the details for the whole world at once, though, the way he does.
Still, until I actually get down to it, I can't say much about how it will ultimately work.
Sure. It's nice to have plans though. It never works out that way, but it gives a framework from which to draw when you need to adapt and change to circumstances.
ReplyDeleteWhere will you be stopping in terms of detail before player interaction begins? I mean, Shamus does a few passes, yes, and then waits for the player's proximity to initiate the generation of high detail. In your description, you say that you'll "produce more and more detail on subsequent iterations". How detailed will that be when compared with the final product that the player sees?
Another way to say it is, will you be performing all of the number crunching up front? Or are you saving some for as-you-go?
I'm not sure. Doing several passes will require looking at what I have, so I'll probably have a low resolution world map saved, and describe weather and such in broad strokes. That has to be stored.
ReplyDeleteI'm going to be doing a bit of real-time number crunching as well. Not just terrain generation, but figuring out other stuff. I have mostly a vague idea, however, so until I get to toy with that I can't say anything for certain.