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

[Omnirizon]

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.

[Omnirizon]

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.

[Aezeal]

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

[Demantiae]

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

[LDiCesare]

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 )

[Aezeal]

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

[LDiCesare]

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.

[Omnirizon]

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.

[statttis]

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

[Omnirizon]

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.