A map description language ?

[pyrophorus]

Hello,

Thinking about the way to improve my generator, I was suddenly striken by an idea. Actually, this program is more a rasterization tool than a random map generator (even if it can be used in that way). It takes a declarative map description and produces a map in BfW format. In some way, it's like pictures which can be described as bitmap or vectorial primitives. As everyone knows, both formats have their use and strong points.
For now, the parameters file of YAMG is a description, but not a language. But it could be developed to become more a language instead of adding endlessy new global parameters, defining some primitives like in Postscript or povray. For instance, using a syntax close to the WML one, we could define a primitive 'region' in that way:

Code: Select all

# --- this part already defines the global region ---
heigth=60
width=40
seed=24568
rough=15

[region]
	region=square
	center=10,21
	radius=7
	rough=12
	type=m
[/region]

This would overload the global settings in the square centered around 10,21 (all settings could be overloaded of course, not only those used here). Note I will quite certainly implement that soon.

The really interesting and exciting (to me at least) point is to imagine more primitives, handy to define a map.
What about a:

Code: Select all

[pencil]
	terrain=Wo
	thickness4
[/pencil]

[stroke]
	path= # no idea at this point how we could describe the path
	pencil=mountains
[/stroke]

or a:

Code: Select all

[fill]
	startpoint=12,18
	terrain=Wo
[/fill]

I would be glad to get some primitives suggestions and discuss them seriously.

Friendly,

[iceiceice]

This would overload the global settings in the square centered around 10,21 (all settings could be overloaded of course, not only those used here). Note I will quite certainly implement that soon.

I assume here you mean that it "overrides" the global settings?

Do you have any ideas to set up some kind of multiple inheritance system? This might be too complicated but it might be helpful if you could write

Code: Select all

[filter]
    ... some conditions ...
    [region]
    [/region]
    [pencil]
    [/pencil]
    [stroke]
    [/stroke]
[/filter]

and then those tags would only have effect within the "masked" area defined by "some conditions".

The really interesting and exciting (to me at least) point is to imagine more primitives, handy to define a map.

I remember once time long ago I tried to make an erosion simulator in matlab, it would like take a height field of terrain and some data and try to simulate what happens when rain falls on it, by spawning lots of rain drops which follow a path and carry soil away.

Maybe you could make a collection of very simple erosion primitives? For example you could have like "migrating wildebeasts start here, end here" then they will start at a random place, take the shortest path to some point near the end point, and maybe trample down some hills and forests at random and make the grass land dry. You could maybe have "glaciers start here, end here" which would carve valleys from mountain ranges and make a little river in the valley. You could even have a "grow forests" routine.

It might be nice to be able to define a map by saying "here's the player start, don't touch this, here's the enemy fortress, don't touch this, in the middle start with some hills and mountains, then some geological events happen and settlers carve some roads through it between some points of interest".

[lipk]

I'm not sure I get the point of this feature. The map editor is both simpler and gives more control over the result. Why would people use this instead?

Code: Select all

[stroke]
	path= # no idea at this point how we could describe the path
	pencil=mountains
[/stroke]

Paths are regular in WML, they're described as a list of x and y coordinates (I presume you're familiar with that ). The same technique could work here.

[iceiceice]

So I can't speak to pyrophorus' exact motivations, but at least in case of what I proposed, having a randomized and procedurally generated map could dramatically increase replay value of your campaign without giving up too much control. For example in Hammer of Thursagan there's a mission where you are supposed to find a rune master in the woods, and his location is randomized out of a few possibilities. But it doesn't really have so much replay value if you already know exactly the lay of the land.

I have to say its not that clear to me why you would want a "vectorized" description of a map, since the main point of doing that is so that you can view it at any scale without artifacts. But you almost surely won't be scaling your maps up and down.

[pyrophorus]

Hi !

I'm not sure I get the point of this feature. The map editor is both simpler and gives more control over the result. Why would people use this instead?

Code: Select all

[stroke]
	path= # no idea at this point how we could describe the path
	pencil=mountains
[/stroke]

Paths are regular in WML, they're described as a list of x and y coordinates (I presume you're familiar with that ). The same technique could work here.

Of course it could. But how tedious if you have one hundred points to list !

First of all, I would say don't want to create an universal tool. When drawing pictures, vectorial and bitmap tools are complementary: splines are better to create smooth and simple coloured objects, bitmap tools are better at drawing sprites or complex objects like a human eye.

Generators like mine are good at introducing some structure and consistency to the map. As an example, drawing castles in the map editor is quick and easy, so why using a generator ? Because it will redraw the roads, so you'll not have the hassle of erasing the old ones and draw new ones, regroup villages nearby and so on.
More of it, as iceiceice said, it can give a way to modify a map by program and improve replay value, much more easily than modifying directly terrains. For example, I had the idea of a campaign where you have to manage a land: a big map and some ten or more detailed maps. The maps will change not only according seasons, but because colonization too: roads and houses are built, swamps are dried, forests leave place to bare ground terrain. How many different maps would you need if you take into account all the possible variations ?

For now, the generator has about 40 different parameters which allow to tune many things. But their semantic is not very clear and, often, you have to use parameters not clearly related to the desired effect. For instance, I think it's possible to draw glaciers using a low value of evaporation and setting the snow level rather low. But this is not obvious and the effect being global will give more rivers and large snowy areas which can be unwanted.
So the idea is to introduce new groups, semantically closer to the way users would describe a map, and abstract enough to reduce complexity. For instance, glaciers seems to me too particular: it could be a frozen river instead because river are far more general.

For now, I see two possibilities (not exclusive, and maybe there are more, that's why I ask for ideas). Introducing objects and transformations.

Objects are obviously what could be drawn on maps. Castles, villages, rivers, roads and more. Let's take roads for instance. For now, these parameters operate on roads:

Code: Select all

roads=yes/no # enable/disable roads.
bridges=50 # -500 to 500. This is the bridge cost.
straightness=0 # 0-10 how much the road must be straight. (Note: it's not always possible to draw straight roads)
altroads=Rr,,Rr # terrain codes for roads
altbridges=Bsb # terrain codes for bridges (note negative bridges cost will draw fords not bridges).

Nothing here allows to specify roads endpoints. It would be easy to add a global parameter:
endpoint=x,y
but is it the way to go ? Instead, we could define a [road] block grouping the existing parameters.

Code: Select all

[road]
	from=x,y
	to=x,y
	bridgescost=50
	straightness=0
	roadsterrains=Rr,,,
	bridges=Bsb
[/road]

And even a [roadStyle] for use in other blocks:

Code: Select all

[roadStyle]
	name=forest_track
	bridgescost=30
	straightness=2
	roadsterrains=Rr,,Rr
	bridges=Bsb
[/roadStyle]
[road]
	from=x,y
	to=x,y
	style=forest_track
[/road]

Which objects to introduce ? How to configure them ? That's my questions, and all ideas are welcomed.

Note: the [region] thing is a way to draw some parts of the map using a different parameter set. It will use the global parameter set as a default, so one will only need to declare parameters changes in the block. The real problem with regions is to define them, in other words, declare which hexes belong to it. Of course, squares are an option, but most probably, others could be of use. Which ones ?

[lipk]

Ah, so this is in fact a higher level generator configuration language? That makes sense.

[pyrophorus]

Ah, so this is in fact a higher level generator configuration language? That makes sense.

Yes, that's what I said in the OP. Thanks for your approbation.

I have to say its not that clear to me why you would want a "vectorized" description of a map, since the main point of doing that is so that you can view it at any scale without artifacts. But you almost surely won't be scaling your maps up and down.

Actually, it could be done, because the map generation is fractal, so you can zoom in without any limitation. The problem is Wesnoth terrain tiles have always the same size, so the effect will be uninteresting most of time (large uniform areas). But you could imagine using a global map and create detailed ones from parts or regions of it. With only one level of zooming and some tuning, the detailed maps could look more or less like a real zoom. But yes, it's not the main objective.

Friendly,