Morkov Maptiler

Data-driven procedural map generation

Landmasses:

Derelict space stations:

...and more!

Usage:

Morkov Maptiler is available both as an app and as a Rust library.

App:

PRE-BUILT:

Simply run the executable (morkovmap.exe on Windows)

FROM SOURCE:

You will need a Rust compiler installed.

1. Download and install a Rust compiler (if you don't have one)
2. Download the source code of this project
3. Open your terminal in the root directory of the project (you should be able to see this README and a src/ at minimum.
4. In your terminal, run cargo run -r .
5. You should now see the code compiling and running.

In both cases, you should now see a new file, map.png, getting created in the same directory as the executable.

Configuration

The map generator rules can be edited in a file called rules.json in the working directory from which you run the app.

If you do not see this file, it will be autogenerated for you after the first run with a default preset.

Alternatively, you could copy and edit one of the ruleset files in the examples/ directory and save it as rules.json.

As of right now, the config contains three main sections:

1. Layout rules

2. Coloring rules

3. Map size

Layout Rules

Layout rules are a map of relative weights; for instance:

{
    "1": {"1": 1.0, "2": 3.0}, 
    "2": {"1": 3.0, "2": 1.0}
}

Indicates that the tile type 1 is thrice as likely to transition to a neighbor of type 2 than to another type 1.

Likewise, a tile of type 2 is thrice as likely to transition to a neighbor of type 1 than to a fellow 2.

This type of rule is likely to provide a slight 'banding' effect with 1s and 2s roughly interlaced with each other.

Coloring Rules

Is that a bit too abstract for you?

Well, that's because the types don't represent anything just yet, and this is where the Coloring Rules come in.

These are a mapping of the types (same as in Layout) to RGB colors for visualization.

For example,

"1": {
  "Rgb": [
    10,
    255,
    10
  ]
},
"2": {
  "Rgb": [
    10,
    10,
    255
  ]
}

Indicates that type 1 tiles are green (e.g. grass) and type 2 tiles are blue (e.g. water).

Note that this visualization convention does not have any 'meaning' attached; we could easily flip the color scheme and the layout would remain the same.

Currently, the only visualization engine colors each tile with a full pixel - in the future, this will be extended.

For that matter, a single map pixel does not need to correspond to a single 'physical' tile!

You can use this as a library to generate 'biomes' and expand each generated tile into hundreds or thousands of sub-tiles across!

How you fill the biome then is up to you - you could even use the library recursively, populating biomes with tiles using a different ruleset for each biome.

Map Size

This should be fairly self-explanatory. Size of the map, as defined by the edge length (it's a square).

For example, 100 results in a 100x100 px map.

Keep in mind that the processing time scales with the number of tiles (linearly) and the number of tiles grows with the map size (quadratically for 2D maps), so if you increase the map size from 100px to 200px, you should expect that it will take 4x slower to complete.

Having said that, the current, under-optimized generator can easily handle up to a million tiles (1000x1000) per run using <700 MB RAM.

Things start to get hairy beyond that point, and trying to generate such huge maps in one go is fundamentally inefficient - we are storing map data that is no longer relevant for our purposes.

This doesn't mean it's impossible - but a better approach is to generate smaller maps and stitch their edges together, which is something this algorithm is REALLY good at.