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.

Procedural Pixel Art

One of the main issues of my little game-studio is that we lack a proper pixel-artist. While we tried to team up with some artists we had no luck with finding one that works reliable and wanted to take the risk of doing work without knowing if we make money or not.

So i decided to research methods of producing pixel-art myself. While i am not a great pixel-artist, i have a deep interest in procedural generation. Inspired by the work of Dave Bollinger i came up with some experiments that i wanted to share here:

Procedural Pixel Art

So how does this algorithm work?

The basic idea is to use a mask that provides information where to paint pixels. My current setup is using only 3 possible states: 1) always paint a pixel here 2) never paint a pixel here 3) paint / not paint based on randomness

The second important thing is that we only construct half of the image in a random way, the second half will get mirrored.
In the above example, each image is 64×64 pixels, wich means the base mask is 32×64 pixel (i am only mirroring at the y – axis)

In this first step we only gather information if we paint a pixel or not – nothing more.
The next step is outlining the resulting shape, wich means painting black around the borders. This is fairly simple: we just check if a pixel is not painted (we dont want to override the existing shape) and also check if there is a painted pixel in the “von Neumann” – neighbourhood wich means the 4 cells orthogonally surrounding our current cell.
If both equals true we know we found a valid border and paint it black.

Now, cause of the randomness we will face lots of 1 pixel “holes” in the interiour that we as a human might recognize as beeing inside the resulting shape. Those will all get outlined black, resulting in lots and lots of black pixels. One solution is trying to recognize whether we are painting a border on the “real” outside or not.
To test this we just check if we find cells in the “von Neumann” neighbourhood that are marked “not painted”. If we dont find any we can mark this cell as “inside border” (and treat it different later in the coloring process) – else we know its an outside border and can be painted black.

Another step that helps reducing “noise” in the final image is to delete single pixels that are completely surrounded by “not painted” cells in the “von Neumann” neighbourhood. This step have to be done before the outlining process.

Till now we just produced a black/white image. To add coloring i used the idea from Dave Bollinger outlined in his PixelRobots tutorial.
The main idea is to use the HSB color space (Hue, Saturation, Brightness) and map saturation according the Y-Axis and brightness according to X-Axis.

I came up with my own modifications to this algorithm wich mainly extend it and let me define minimum and maximum values for all 3 parameters.

To get structure into the shape i use the previously gathered information about “interior” borders and color them similar to normal painted cells, but reduce the saturation and/or brightness to let them stand out.

Till now we just processed half of the final image, the last step is now to mirror it along the Y-Axis and draw the final texture.
A nice coloring trick here is to slightly reduce the brightness and/or saturation in the mirrored image to further improve the lighting on the final image.

While this algorithm already provides nicely colored shapes there is plenty of room for experiments.

The incredible power of procedural content generation

Its quite a while since my last post, and lots of stuff happened inbetween. Founded an indie-game studio together with a friend. We produced and published our first game and are now working on the second.

While the first game was more a proof to ourselves that we are able to do a complete development cycle, beginning from scratch up to finalizing and publishing it – the second one is now getting into more interesting realms.
I was always quite fascinated from procedural content generation (PCG) in general, and some of the fruits of my early experiments are shown in some older posts here.

The new project is making heavy use of some PCG techniques. Namely map generation and word/sentence generators. While both are often used and well known, i wanted to go a bit further and test out some ideas.
The main issue during out last game was that our Designer created game-content like texts and stats/balance – i had to hardcode them into the scripts. This was a bad aproach cause it basicly doubled the time needed for it.
Now i tried to develop some tools to outsource this data from the game. This not only allows for a quicked development but also makes the game moddable. I chose XML for this, cause its rather easy to use complex data-structures with it, without the need to re-invent the wheel with developing our own data-formats (and scripting exporter/importer algorithms).

Now, you may wonder what this have to do with PCG.
Well, lets take as example the word/sentence Generator:

Word / Sentence Generator

Generators like that work quite simple. Lets say we want to come up with a bunch of names that all sound nordic. An easy way to do this is to analyze nordic names and get a list of syllables that make up those names.
A simple formula would be: Beginning syllable + middle syllable + ending syllable = name

Depending on the data for those syllables you can produce a large amount of names that all sound quite believable.

Alffdanr Jakobhjalsen, Aris Rasberg, Fenrir Sorenhauser, Svadildorr Leonbak, Gudnarr Leonhaugen, Sleipbrandr Herhjallum, Fentoppr Hagerickbak, Hallki Skjeggeardgen

A more complex example would be descriptions for items, or book-descriptions. Basicly you try to make up rules that tell how the sentence is made up of different pieces. In general its the same concept like with the names, just more complex.
After developing the base concepts of this generator i tested it with setting up a simple sentence for a book-review. The output is something like the following:

This roll published by Alfris Hauthonvik  is muddled mostly due to uninspiring features.
This writing is totally senseless mostly due to the totally lack of content.
This writing from the known writer Eijotr Lundgen  is very easy to understand despite the really great crafted content.
This atlas is reasonable clear thanks to the very great done organization.
This book is totally senseless.
This work written by the well known writer Hallfrodr Harbak  is interesting.
This text from the writer Ganfari Sorenrickvik  is hard to understand thanks to the totally uninspiring diagrams.
This book published by the unknown writer Favnir Anter  is quite clear.

The quality of the sentences differs, sometimes its coming up with strange or amuzing curiositys, but in most cases it already giving pretty good results.

Now the great part about this is that both examples are done with the same generator. To be able to allow this i came up with a simply ruleset wich you describe in XMLs.

An example XML dataset looks like this:

<TextGen description=”Dwarven Name”>
<rule>       <string>A,Ba,Bi,Bo,Bom,Da,Do,Du,Dwa,Fa,Fi,Fre,Fun,Ki,Lo,Na,O,Tel,Tho,Thra,:100</string> <string>za,:10</string>

This ruleset have an ID wich is used to reference this specific rule (#DWARVNAME#), and it have a list of rules wich are basicly strings that hold a number of elements, each seperated by a commata.
Those strings get parsed by the engine to “deconstruct” the rules and get the seperated elements. I mainly did this to avoid unneccesary complex XML structures. The number at the end of each rule is describing the chance that this rule gets applied at all.
This simple trick already allows for quite some variations.

Instead of all the time having 3 syllables added together, its easy to describe a ruleset here wich often only uses 2 syllables, but sometimes uses 3.
The above ruleset could output names like:

Bomli, Thrazamil, Aghal etc…

Another quite important thing is the option to reference other rules in those elements. To seperate normal content and rule-references correctly i suspect that each rule-ID is beginning with a # sign.
The process of generating the final words/sentences is recursiv. It would be of course quite easy now to “script” infinite loops”. To avoid this i count the number of recursion steps the algorithm takes, and just break out if i get over a hardcoded limit.

The last thing i implemented for now is the option to save the output of a generator in a variable and be able to use that variable in the rules.

With this simple setup we are already able to make up quite some complex generators for different use. Again some example:

<TextGen description=”Dwarv pseudo text”>
<string>A ,:100</string>                <!– here we begin actually building the text –>
<string>small ,ugly ,tiny ,crude ,greedy ,funny ,:50</string>
<string>dwarf ,guy ,person ,:100</string>
<string>called ,named ,known as ,with the name ,:100</string>
<string> met a , was a friend of , travelled together with ,:100</string>
<string>a person , someone ,a guy ,:100</string>
<string>called ,named ,known as ,with the name ,:100</string>
<string>. ,:100</string>;

The special new functionality here is the command !1 and ?1, wich basicly saves and loads into the variable slot 1. Currently i am providing 20 slots wich should be more than enough for quite some complex setups. They can be also used to pass things from within the game, so it would be quite easy to construct sentences that mention the name of the player for example.
The above example isnt the complete ruleset, i am calling the ruleset #DWARVNAME_FULL#, saving the output in slot1, calling it again (and getting another result), saving that in slot2, after this basic setup i begin to construct the simple sentence. This is just an example i wrote for our game-designer to show off how all elements are working together – its not used in the actual game.
With this simple tool, the players could mod their own name-variants, item-descriptions and so on. At the moment its more a proof of concept and still in early experimentation phase, so we havent decided how its actually linked to the game and how much freedom we give to players in respect to modding.

Well, enough text for today, stay tuned for more insights into our use of PCG techniques for our new game.

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.