OT: Making a Game System (part 4: A Game World)
 

so summer is creeping ever closer, and when I gets here the plan is to have time to pick up working on the Dominions Roguelike once again.

The goal set for myself to accomplish over the semester was get some sort of map generation. Tiles are the typical roguelike representation of a game world and there's lots of resources on how to implement them. I really wanted to not do tiles (since I've avoided them completely in everything else so far) but with little to no knowledge in map generation (or high level math in general) I was feeling hopelessly overwhelmed.

Fortunately, lch pointed me to some styles of terrain generation that are not archaic roguelike tiling algorithms. I found some existing implementations I could start with. Along the way I learned how PixelArrays work, so I could automatically generate a surface without needing to glue together a bunch of tiles.

I found a Python implementation of an algorithm called Perlin noise. I played with it, tweaked the interface and output, and eventually got it working the way I needed it to. Right now I've got it making greyscale texture surfaces. The plan is to make some color gradient functions that map the greyscale to discrete color values (for example: at some threshold, darker colors will become water, which then can become deeper water).

So that's it right now. In a couple of weeks I hope to post some screenshots of textures mapped to color values, forming landscapes with oceans, lowlands, and mountains. The exciting thing is that I can make a landscape representing terrain height, and then generate another layer of perlin noise to lay over this for placing forests, swamps, and other features.

So here's a pic I generated using my current implementation. It is nine octaves of noise linearly blended with a period of 256, an amplitude of 1, and a persistence of 0.5. This is a pretty typical noise pattern. The algorithm has different parameters that may be modified to influence how the noise looks. This pic has a lot of even clumpiness, but different parameters can make pictures with just a few big clumps, pics with even more granularity, or even pics with a tile pattern

Imagine now the darker portions mapped to water, and the whitest portions as mountain peaks. The greyscale makes it hard to see the difference inbetween, but with a nice lowland green to brownish grey highland gradient the real texture of the noise will become apparent.
http://i39.tinypic.com/6sx4co.png

Re: OT: Making a Game System (part 4: A Game World)
 

here's my first attempt to colorize. my green to brown color ramp leaves a little to be desired, and the image looks cloudy and needs some sort of interpolation, but you can still get the idea.

http://i43.tinypic.com/23jh5kh.png

Re: OT: Making a Game System (part 4: A Game World)
 

looks nice, I don't know what you intend for map movement but I remember something from the past which has always been to my liking: the mapmovent in "shadows over riva" basicly you just move over paths till you get to a crossing and then choose which way to go.. random event etc etc combat/enemies etcetc pop up from time to time

Re: OT: Making a Game System (part 4: A Game World)
 

I've skimmed through the OT Roguelike thread and this one and I can't make heads nor tails of it but it keeps intriging me. What is all this talk? Is this some sort of MUD system? Is there a project to turn Dominions into a MUD with this? Forgiev my curiosity :angel

Re: OT: Making a Game System (part 4: A Game World)
 

Your system will end up with mountains in the middle of continents instead of mostly on the rim. Although they are tile-based, you migth want to look at the various Civ IV map scripts, they are in python and the tiles tend to be an after-effect thing since several models don't really care about them (check PerfectWorld in particular: http://forums.civfanatics.com/showthread.php?t=310891 )

Re: OT: Making a Game System (part 4: A Game World)
 

he';s making a game, only based on dominions lore the rest is basicly a new roguelike

Re: OT: Making a Game System (part 4: A Game World)
 

I know, but using Perlin noise to generate terrain will give something very predictable and unrealistic, whereas the algorithms used in the script I refer generate terrain that's very nice, and scale well so don't depend on tiles (although in the long run, pixels are just small tiles). It's in python, which is the same language as what the OP used, so I guess it's relevant.

Re: OT: Making a Game System (part 4: A Game World)
 

thanks LDiCesare. That script may contain some ideas/inspiration. However I'm not sure what the form of its final product is or if I can even interface with it.

Re: OT: Making a Game System (part 4: A Game World)
 

I'm interested in how you're going to handle a tile free game world. Will there actually be no tiles, or will there be some underlying grid, hidden by the continuous terrain? Without tiles I'm not sure how to properly do turn based movement - unless you're going to attempt real time :eek:

Re: OT: Making a Game System (part 4: A Game World)
 

well as LDiCesare noted, pixels are just itty-bitty tiles. Turn based movement is simply a function of binning time into units. I already have formulas for computing pixel-based vector. I just pick a unit of time that is comfortable to play with (not too big, not too small) and split up movement that way.

So right now I have pixel speed per loop. I simply decide how many loops should be in a unit of time, and voila! turn based movement. A `movement' attribute is simply the number of pixels a unit can move in a single loop. So if I bin time into 10 loops each, a unit with a movement of 1 can move 10 pixels in cardinal direction; I use euclidean distance formulas (not Manhattan block), so moving diagonally would result in fewer pixels moved.

That said, I was actually thinking of doing real time.

Re: OT: Making a Game System (part 4: A Game World)
 

my most recent attempt.

As you can see the map looks much better. The cloudyness is gone, and the color ramp is gorgeous.

To my original program, I added functions for linear interpolation of color, and another that allow for an arbitrary number of discrete {scale : color ramp} mappings to be specified. If you look closely you will also notice some of the color ramps blend in a power-law curve, rather than linearly; you can see it where the green is concentrated around the coasts, but quickly blends to a lighter color where the ramping up slows down.

for color I mimicked the Parganos color scheme (the map had just been posted to the forums and was handy :)

http://i39.tinypic.com/23w1c9u.png

Re: OT: Making a Game System (part 4: A Game World)
 

I'm not a someone "into it" but I can't imagine a real world would look like that. Having said that the coloring etc does look nice. If there are mountains somwhere in there though I'd say they'd need a seperate and more different color (I'm guessing the most light yellow to be the highest points?) since there is too much light yellow for it all to be mountain.

Once I was looking at maps and there are like whole sites and communities dedicated to map making (often for DnD) maybe you should ask someone in one of those to make a map? (if they will do it for their name somewhere)

Just a suggestion since I'm thinking this project of your is quite big and you'll have lots to do and so asking a "specialist" to do things from time to time might
A save you time to work on other stuff
B improve the result

Re: OT: Making a Game System (part 4: A Game World)
 

Aezeal, he is making a roguelike, and one of the big things of that genre is making random maps. So asking someone else to make a map isn't going to work. He wants (I think) a random map generator.

Re: OT: Making a Game System (part 4: A Game World)
 

From his previous descriptions/threads I didn't get that (need for random maps) yet anyway if he does he need to get a formula that makes the landmasses somewhat more realistic IMHO. If you have a fixed map it would allow for much better background for all of his nations and races I'd say just doing like dungeons or something with random maps could be enough.

Somehow I'm thinking of this game that it's intented to be a daggerfall like game I don't know why... anyway... that is why I was thinking about a fixed map (with all or some of the LA nations on there) and then well whatever he wants...

Re: OT: Making a Game System (part 4: A Game World)
 

there might be some algorithms to combine with the perlin noise that produce better results. I've read Fractional Brownian Motion is used in conjunction with Perlin Noise to get rid of the way the noise seems to move in that grid like pattern (the way the land and water are in corridors).

Re: OT: Making a Game System (part 4: A Game World)
 

I must confess that I haven't read the previous threads. But random environments is a huge thing for roguelikes. (The first one of the Berlin interpretation (http://roguebasin.roguelikedevelopme...Interpretation). So based on my knowledge of what a roguelike is, and what Omnirizon was doing, I assumed that he wanted nice looking random maps.

My interpretation:
So each time you play the game, the map is different, but the nations are the ones from dom3, but also with different interactions between each nations. (Just like in dwarf fortress, random interaction between the different nations).

Of course, I'm not Omnirizon. I don't know what he is planning to do. (And I'm more of a bottom up developer, first the local region, world map later).

Re: OT: Making a Game System (part 4: A Game World)
 

I'm finding auto generating a world map frustrating.

* I want it do to things like make sensible placements for cities (put them in bays and other areas where cities would actually be built. Teaching the computer to locate bays seemed difficult, I could just barely begin to think how (I was figuring a bay could be located by attempting to draw triangles with vertices on land, legs of some minimum length, and area of the triangle some minimum amount of water). Of course, with possibly 4000x2500 plus pixels, and the computer needs to check within some kernel around the entire convex hull of all water areas, it seemed computationally intense.

* I had also originally wanted some transformation to rearrange height points around to form actual mountain ranges, rather then clusters. I had the idea of using clustering algorithms (like those used in data mining) to locate clusters and then drawing a regression line (another technique in data mining) and moving 'peaks' in the clusters toward this line, forming a range. This, however, left the problem of me needing to look up and implement a clustering algorithm. Educational for sure, but not something I feel like doing right now.

In the end, it was giving me a headache and only serving to disuade me from wanting to work on the stuff, so I dropped these fantasies and will settle with a manually defined world for now.

I'm off to making site building algorithms now though, it is a little easier. I started with generating cities and buildings. A little house first. Random dimensions, random chance to have 'addons' what give the houses different shapes ('L' 'T', etc, so not just a bunch of squares). Randomly generated rooms, with some constraints like 'mainroom' and 'kitchen' parameters that force certain size and placed rooms to exist, then pretty much uniform 'bedrooms' built around those.

I do have a question that someone might be able to help with. It seems reasonable that big houses would have kitchens and mainrooms with multiple bedrooms, but that must be an exception. What is the typical house in, say, London, like circa 1500-1700? Single room? do they have a set 'kitchen' room? Were these houses or was everything sort of like an apartment? What were the range of dimensions for these houses? small and big ones. I just don't know.

Re: OT: Making a Game System (part 4: A Game World)
 

I believe at the time houses were still mostly tight two-three storey wooden buildings with different families living on each level, having one or two room. I know in Paris until the 19th century people mostly lived outdoors because it was too crowded inside. Kitchens and bedrooms would probably be the only kinds of rooms, except for richer places, which could be mansions with lots of rooms, including separate stairs for the nobility and the stairs for the servants and bathrooms. Water closets were outside.

Regarding random world generation, if you're interested, I could try to adapt something I did for you. Mountain ranges are workable, although I never thought of gulf detection algorithms.

Re: OT: Making a Game System (part 4: A Game World)
 

Yeah, around that time most people had only one room where they'd sleep, cook and eat AFAIK. The house might have had a cellar for storage and a ceiling to dry clothes, those would be shared if there was more than one family living in the building. The pot was outside. Anything more than that and you'd be wealthy.

Re: OT: Making a Game System (part 4: A Game World)
 

ok great. what about the ubiquitous peasant village: did such things exist? what about farmsteads; were there isolated farm houses, or did people always cluster into villages? by the 1500-1700 were there things like bandits and raiders that would threaten villages and individual farmsteads?

lastly, for layout, were these things just clusterflucks? A recursive splitting algorithm (split space into two sub-dungeons, then likewise split sub-dungeons, then split sub-sub-dungeons, so on recursively until no split is larger than some set minimum on any one dimension) tends to make decent looking dungeons, and even halfway sensible city/village layouts, but they will be no means be a grid. Is this probably realistic for villages and maybe a sector of town, and then maybe some parts of towns start with a grid and randomly merge some cells?

Re: OT: Making a Game System (part 4: A Game World)
 

The grid system was pretty rare in history, and (I think) hardly used between Rome and new towns/cities in the early modern era. AFAIK for 1500-1700 it's not really a factor.

Wide avenues would have occurred on occasion, leading to or past major buildings.

Re: OT: Making a Game System (part 4: A Game World)
 

Random map generation is a huge interest of mine. I wrote a terrible random map generator in Java when I first started college and I would like to take another stab at it one of these days. Keep up the good work, I will keep an eye on this thread to see where it goes :).

Re: OT: Making a Game System (part 4: A Game World)
 

It may depend on the country/region, but there were many isolated farms in France. In certain places, farms were fortified. Whether fortified or not, they often had outer walls with several buildings inside, like a barn, housing, stables... Not many walls inside. Often barns have only 3 walls.
Not all villages were fortified either. Bandits would rather attack people on the roads.
I'm not sure what you mean. A medieval town would not look like a grid at all but like a mess of streets. You usually had one main street and a few others which branched out of that. Few meaning sometimes two. Bigger villages or towns would get one market square and several roads leading to it, and then a lot of houses crammed around that. Cities with walls would be similar but since houses had to be built inside the walls, they'd be very crowded. Look at these for instance (in French, but the pictures are the important point):
http://www.yvoiretourism.com/chapitre7_fr_10.html
http://www.saint-denis.culture.fr/fr/1_4a_plan.htm
http://www.vence.fr/Vence-Ville-medievale-du-12e.html
You can also google-map some old villages, like Jouarre in France 70km east of Paris. It's probably not changed much in 5 centuries (it's got a merovingian crypt, so it's at least 1000 years old).