Subject: Re: A predictably random game: One more try Date: Tue, 26 Feb 2002 10:06:12 +0100 From: Hansjörg Malthaner Newsgroups: rec.games.roguelike.development Tarn wrote: > > "Hansjörg Malthaner" wrote in message > news:3C7A3C24.3C392CDC@danet.de... > > Tarn wrote: > > > I can see how you could get away with > > > forests and other vegetations distributions, as well as altitude, by > laying > > > out a huge sheet of numbers over a 2D grid, but the long squiggly > terrain > > > features still seem like a problem. > > > > If you like, I can add a few canyons and mountain chains :) > > Ooo, ooo! Yeah! I don't see why a canyon isn't like a river... many of > them are made by rivers, but even ignoring that... if you want something > long that squiggles around the random numbers on local x,y coordinates > aren't sufficient. How will that work? Do you know the "perlin noise" function? That's a kind of RNG, too. WHen I wrote the paragraph I had in mind to use perlin noise to create structures like mountains and canyons. I was slightly wrong: Perlin noise will in most cases create circular structures. That's no problem for mountains, their outline is always a closed line. But circular canyons are funny - not that it won't work to create canyons with perlin noise but most of them would be closed lines. Maybe if a heavily turbulent perlin noise is used, a area full of chasms can be generated. The turbulence will disrupt the circles into parts, and each part will create a chasm, winding along a while, but with a definite start and end. Still not exactly what we wanted to have. --- Still another approach can be taken. There are terms line r²=x²+y² that describe a curves (a circle in this case) in a plain. Maybe some one can find a formula that describes points of a long winded structure. We had a mathmatician here with us, maybe he can help us out? > > > I handled this with edge data again (if > > > a river runs through a region, save its exit points to be used in > > > generating > > > the river when the next region is loaded), although again the edge data > > > system leads to an overall sacrifice in predictability, which isn't what > > > we're looking for... > > > > Actually the clue is not to tile the world, but make the algorithm being > > able to produce slices of a bigger world. The world itself is endless, and > > all features are determined by random. Generating slices will assure that > > the areas fit together seemlessly, they are all part of the big seemless > > world. Because the world is entirely build on random numbers (which I made > > dependant on 2D locations) I don't need to store any information, but just > > can generate a new slice of the world once the player enters it. The > > random > > seed is the location, a 2D coordinate. > > .......... > > c.u. > > Hajo > > That's what I meant by a huge sheet of 2D numbers:) Just a two dimensional > function defined on the entire plane (function in the mathematical sense)... > I guess my general confusion now is how to get some control of generation > with your method... if you wanted a large terrain feature of some kind, > like a volcano that spans several squares, how could you build it? The problem is the definition of locality. First I was thinking in location=sqaure. Then you can basically create nothing bigger than a sqaure. In my implementation I used areas of 100x100 sqaures. I could define a location to be 20x20 sqaures, and make a volcano check for every 20x20 patch. If the check succeeds, a volcano of sizes up to 20x20 sqaures can be placed there. This is still not perfect, but maybe 'good enough' for a games world. You can do some trickery like randomly moving smaller volcanos around in the 20x20 area to hide the raster a bit. And if there are not too much volcanos nearby there is a good chance that noone will notice the raster at all. (Maybe players will notice that structures never cross the 100x100 area borders. But Angband also never produces rooms that cross panel borders (or at least has a option to do so) and noone complained.) > Maybe if > the x+C*y number is between 100 and 200, then there's a volcano centered at > that location, then use a different C to grab another random number from 0 > to 2^32-1 to seed the volcano construction. Volcano construction would be > bounded in say an 11x11 area centered at (x,y), and you have completely > creative control over it, and a new seed to use. When the player moves, > scan the neighboring squares (up to 6 squares off screen) that are close > enough that the player might see any square affected by volcano > construction. That'll probaly work, too, but I wnated to avoid the scan of offscreen sqaures. That's why I thought about tiling the map in locations like the 20x20 areas. > What did you have in mind (if you wanted more control over > the map)? I'm still even more confused about the canyons, since I don't > know how to draw out a path from a bunch of x+C*y numbers. Ack. Perlin noise is something like v=f(x,y) (actually there are perlion noise functions for any dimension). The function guarantees that if called for two (x,y) hich are nearby, the v's are raltively close, but the larger the distance the more unrelated the v; above a certain distance the v are completely unrelated, random. The property "similar v for (x,y) close together" can be used to generate local but lengthy strcutures. Unfortunately all perlin noise implementations I know create circular regions of similar v, because the 'nearby' clause is indifferent in regard to direction. If someone finds a perlin noise implementation that has a preferred direction for (x,y), that can maybe used to create long-winded structures (but no rivers, that must end in a lake or sea). Otherwise, we can just add turbulence, to disturb the locality and produce scattered smaller chasms over an area. > (Note: the x+C*y function is in Hajo's other post if it wasn't in the one > I'm replying to) > > Tarn c.u. Hajo