I like to call them Blueprints

I am working for some time now on my next game, title still undecided. One of the main parts is the procedural generation of the world. Most people would think now either of a 3D heightmap aproach or a 2D top-down roquelike one.

Its neither.

Its something different. Its easy and simple and can lead to surprising complexity while giving me a ton of control of how the end-result will look and play.
I call it Blueprints.

Its just another name for templates to be honest, but its also not simple pre-crafted rooms that get put together. Its more like “building guidelines” for those rooms/areas.
Those blueprints contain what tilesets (textures) the area can hold, they describe a general layout of the area – like here is a stair, there is door etc. but dont define exactly what gets put in there at runtime.

Well, a blueprint alone does nothing. It just sits there and waits till we feed a generator with it. This is a special algorithm that takes the blueprint and transform its information into something useful for game.

But a blueprint alone doesnt make a gameworld. It needs friends.
Its basicly a higher level of blueprints – lets call them Maps. A map is holding information like what kind of blueprints it should use, what generators to feed, how big the world shall be and lots of other “high level” decisions.

I have read lots of discussions in the past what can be called procedural generation and what not. I think it doesnt matter as long as the result is entertaining. (not to forget, the process of making it).

The use of blueprints solves one big issue i faced in the past with procedural content. Its predictable. I can design a specific layout and i know for sure the map in the end will stay true to this layout, no matter what exact tiles it uses (or in the case of maps – what exact blueprints).
Its map designing from a greater perspective. You define the grand outlines, the generator fills in the little details.

The game i am working on is a 2D side perspective dungeon crawler, heavy influenced by trading card games. One of the design choices was to use a really low-rez graphic – not because i am a deep fan of a Retro-look, but because i am mainly programmer, secondly level-designer and maybe at 5th or 6th position comes texture-artist. I am working alone at the moment on this game, so i had to solve this issue with the skills i have. Reaching out for highly polished 2d artwork just wasnt a question.

Thats said, lets have a look at some nice pictures:

worldRender02 worldRender03It is relative easy to recognize the patterns and see where the different blueprints connect. There is a total of 5 blueprints used in those 2 pictures (i havent done much content-producing for now, only quick make-ups to test out the functionality of the algorithms). It is also easy to see that the overall layout is consistent – but its always a bit different what tiletypes gets used in the end.

For now its more a proof of concept. To really shine, there is an urgent need for lots and lots of content (tiletypes, blueprints and maps). But i really like it – its a different aproach to procedural mapmaking and there still so much to discover for me.



In develop version of procedural card art

Based on the algorithm mentioned in my previous Blog i began to work on a card design. The idea is to produce the basic card art (for a unannounced project i am working on) with procedural techniques.

The background is currently done with a simple Perlin Noise and will for sure get some improvements later. The borders are done with the previous mentioned algorithm.

Some changes was needed to do the corner pieces (no mirroring, instead the whole 32×32 pixel art gets generated from a base-texture).

The whole thing is a work in progress of course, there are currently around 20 variables controlling everything, beginning from the perlin-noise to the shading and coloring of the border art.

The main goal is to develop an algorithm that will output a standard card for the game where we can then input artwork for enemys, items etc… as well as descriptions.
In the end most of the variables will get predefined and just a couple of them (mainly coloring) will be changeable at runtime.

Dynamic Systems for PoP4.0

We are still in heavy development phase for PoP4.0  (currently at early alpha stage)

One of the things i did lately, was to develop some concepts i have for several years now and finally wanted to see them alive in a mod:
The basic idea is to be able to track more in detail where exactly a given party is on the map.

The base is the point/triangle-collision detection.  I choosed this over rectangles (which are defintly easier to compute, cause it enables me to layout a better fitting mask. Also i didnt used circles (which would be really easy to setup a algorithm cause i could use the already existing code for checking the distance to a party) cause they either would overlap or have spaces between them and as far as i know extracting a root is really expensive in terms of computation.

Instead i used the following grid setup:
Grid Layout

Now that i am able to track a given region the player is into, its possible to make a lot of real interesting stuff with that.

The easiest things was to inform the player about the region he enters when he travels the map. On the first time he entered he is also given indepth information and lore about the region (in a pop-up) – this is mostly to help people to visualize/understand the world they are exploring better.

The next thing was to tie this information to movement speed modificators.
For example in more hilly regions the player will travel slower, while (on the same terrain) in another region he is faster.
As far as i am aware this is also the first time that using roads in m&b will have any effect beside just beeing a visual gimmick.
This can get as complex as one wants it to be. For example a faction living in a hilly area dont get movement speed penality (simulating they know their homeland terrain).


Another great deal was to improve the weather simulation in M&B.

Weather in M&B currently uses 2 variables: cloud-amount and haze-amount
The first controls rain in battle-maps, the second the fog.
Now the idea was to make a region dependend simulation on base of this.

I used Arrays to store information about the weather for each region

To simulate the weather i used the following concepts:

– Randomize the weather in all regions by a certain amount
This will add some noise to the weather and make sure no region have exactly the same settings than another.

– Averaging / Smoothing surrounding regions weather settings  (too avoid too hard jumps from one region to another)

– Using “Seed” regions outside the grid to control the weather.
The seeds themselves dont get randomized or smoothed

How can we design now the climate/weather of Amala (this is the name of the land PoP4.0 will be playing in)?

Using the Seeds we define a base weather for the border regions.
Something like sunny,and some clouds at Pendor Landing
Cloudy, foggy at ashenborn
no fog, but lots of snow at santara … stuff like that

Then we can define for each region how much randomization they will have
(see this like: lots of randomization = rough weather changes, not so much randomization its more smooth)
So we can say for example: Ashenborn will have rough weather, heavy changes
while Nohseru is more a smooth region, weather changes are more subtle there

Last but no least, and now it gets kinda complex:
We can define a weather cycle for each region. With that i mean that we say for each month the general base weather, and this will cycle every year. This makes it possible to do stuff like:
More rain in the spring, less rain and fog in summer etc…

A final note:
This is a highly dynamic system. Lots of randomization, but also strict rules…
What you recognize ingame tough is at first sight very subtle… but keep in mind that linking such systems creates a truly dynamic, living and breathing game-environment.

Procedural Textures with Werkkzeug3TE

Some may know the demoscene group “Farbrausch”. I really love to watch their demos for several years now and recently i found that they released their toolset for procedural texture generation called “Werkkzeug3TE”.

Its not the first time that i tried my hands on procedural texture generation, but i have to say, this is the best piece of software i found so far. It´s a bit tricky in the beginning to get used to it (there are not many tutorials available in the net) – but i managed to get some pretty nice results after a real short time.

The first picture shows my first try – i used a documented wood texture and while going through the steps to understand whats doing what i created this one…

The next can be called my “hello world” version.
I used a reference photo from a bark tree and used the things i learned in the first texture to do this entirely alone.


Now the really interesting part is that this is entirely procedural made, this means its just a bunch of noise-generators, filters and masks which do their magic.
This means that changing resolutions later wont lead to loosing details (instead higher resolution will automatically have more detail calculated), also changes at a later stage are totally easy and done in a matter of seconds.

WorldMachine terrain rendered with M&B Warband

Terrain, Texture and Normal map made in WorldMaschine,
UV-mapped in Wings3d,
Rendered in Mount&Blade Warband engine

It is defintly not practical to do terrain in such a way, but for a test this went quite well.
Texture is 170 kb
terrain mesh is 9800 polys

Atleast doing the terrain manipulation for special props, aswell as the normal maps in WorldMaschine might be beneficial.