sequba / h3mapgen-cellular-terrain

Part of the Heroes 3 Map Generator. Module builds terrain shape using cellular automata.

h3mapgen-cellular-terrain

Part of the Heroes 3 Map Generator. Module builds terrain shape using cellular automata.

Data representation description:

The game map (board) is represented as a 2-d vector of cells. Namely: typedef vector<vector<Cell> > Board;

A single cell can be in one of 4 states: white, black, swhite or sblack:

enum Cell {
        white,	black,
        swhite,	sblack
};

How to use the generator?

First of all, you need to include the header: #include "cellular_terrain.hpp".

Then take a look on facade function terrain(...) as well as specialized neighbourhood functions:

void terrain(const Board& board, Board& result, const TerrainParams& parameters, unsigned int iterations);

• board is an input; meant to contain some swhite and sblack cells
• result will hold the resulting terrain map
• parameters structure may be easly obtained from functions such as moore_neighbourhood(...) etc.
• iterations just specifies the number of succesive CA generations

TerrainParams *_neighbourhood(float probability, int self_weight=1, int threshold=0);

• probability is a probability of a black cell on the initial board before running CA
• threshold defines the minimum value for the weighted sum (over the nighbourhood) for a cell to survive or be born; leaving it to 0 will cause the generator function to pick the best value automatically (recommended)
• self_weight specifies the degree of contribution of the current cell's state to the wighted sum

Example usage:

terrain(my_map, terrain_map, moore_neighbourhood(0.5), 2);
terrain(my_map, terrain_map, neumann_neighbourhood(0.4, 3), 4);
terrain(my_map, terrain_map, moore_neighbourhood(0.4, 1, 5), 3);

A quick glance at the code in facade_test.cpp would leave no doubts, I belive.

Which files exactly do you need?

Just four of them:

• board.hpp and board.cpp for general board representation related stuff
• cellular_terrain.hpp and cellular_terrain.cpp for CA mechanics

As a bonus, you may also want to use my ascii -> bmp conversion for resulting maps. Then you'll need draw.cpp in addition.

The report

For the thorough description of the method used, theoretical background, some interesting findings and practical tips, see the project report (the PDF file in the report directory).

Note

Bash scripts producing maps require imagemagick.

h3mapgen-cellular-terrain's Issues

More of "the context" in the report.

As acatai suggested:

(szkic) , plus zdania z Twojego opisu

...the map, which we will briefly depict.

It is worth to notice that the model is general and it can be used for most of the strategy video games, not only HOMM3.

We start from the map settings given by the user, including map size, number of players an their associated castles, map richness, difficulty settings, etc. Then, we translate these settings into the generator parameters, used throughout the process.

The earliest stage focuses on the generation of map layout, which determines the flow of the game and placement of the most important objects (towns, mines).
And ensures map fairness.
The nodes of the graph are map zones and edges are passages between the zones.

It is generated using the grammar based generation....

The layout structe has to be mapped on the grid...

The shape of each zone is created using the distorted voronoi diagrams, and have to presereve connectivity...

Here CA comes into place.

After that, the map has to be filled with the rest of the content - treasures, monsters, and other game objects.
This is planned to be done in a heuristic based way - using the simulation of player's progress ble ble ble

Write a paragraph about postprocessing at the end of the report

Something about digging tunnels in order to connect the remote caves to the main one.

Pseudo random generator always uses the same seed

The seed should be taken from current time.

More convenient use of number of iterations

Currently the number of iterations is treated differently than other parameters (does not belong to TerrainParams struct). It was convenient in the early prototyping stage, but now all the parameters should be placed there.

Also, some kind of automatic way of determining the number of iterations should be considered.

Add a picture of the terrain generated on Voronoi input to the report

Structure "frequency" measure needed

We have a way of measuring the black/white percentage (the black_rate function). A way to distinguish large open caves from labyrinth-like structures would be very useful.