I don’t know why but the sound is a little jerky at times. :( And with my terrible accent, it may not be easy to understand certain parts. So I will transcript the talk in this article.

Before we start, you can get the demo code that accompanies the talk on my GitHub account and the slides here.

What’s a Room Generator

So let’s start by defining, what’s a room generator.

Before	After

The input is simply any structure, it can be a building, a dungeon, anything. And it doesn’t matter what algorithm generated it. As it looks desperately empty, we want to fill the structure with objects, decorations and monsters. That’s what is room generation.

Before	After

Before	After

It works for buildings, but it also works well for caves or dungeons.

And even for outdoor structures like the ruins on the left, or for the market place in this village.

What’s a Constraint Satisfaction Problem (CSP)?

The generator is based on constraint satisfaction problems that I will abbreviate as CSP.

A CSP is composed of three things:

1. There are variables which in room generation will represent the objects to place in the room.
2. There is a domain for each variable. They are the finite sets of possible values for each variable. In room generation, the domains are simply all the possible positions for each object.
3. There are the constraints, which are predicates on the values taken by the variables. In room generation, we may require that objects don’t overlap, that there are paths to access objects or we may want specific objects to be against a wall or in a corner.

Solving a CSP is just finding an assignment that satisfies all the constraints.

We can notice two things. First, it’s very intuitive to use. If we want to have a shower next to a wall, we just have to add a constraint to do so. And we have strong guarantees on the output, which is always a nice thing in procedural generation.

Basic Solver: Backtracking

Now, let’s see the basic algorithm to solve a CSP. It is called the “Backtracking Algorithm”.

This is just a refined brute force approach, we will enumerate all the possible assignments by recursively assigning the variables one after the other.

The only subtlety is that each time we try to assign a variable, we check the constraints, if they are satisfied we move to the next variable with a recursive call. But if the constraints are not satisfied or the recursive call fails, we move to the next value in the domain. And if there is no value left in the domain, we backtrack to the previous variable.

def solve(i, assignment):
    if i >= n:
        return True
    for value in domains[i]:
        assignment[i] = value
        if check_constraints(i, assignment):
            if solve(i + 1, assignment):
                return True
    return False

It’s simple as you can see it’s less than 10 lines of code. And, it works very well, if there is a solution to the problem, it will find it. And with the constraints that I am presenting here, it is also very fast.

But as we always try the values in the same order, the solver is deterministic and will always output the same solution. Not ideal for a procedural generator.

How to Turn That into a Generator

However, it is very easy to fix this problem.

We just have to shuffle the domains each time we want a new room.

If you are using an external library to solve your CSPs, just make sure that the selection process of values in domains is random.

Notice that the order in which the variables are processed doesn’t matter. And it doesn’t need to be random.

In fact, there is a heuristic called “Minimum Remaining Value” that can speed up the solver significantly. It consists in assigning the variables with smaller domains first because they are more constrained than the others.

Modeling the Room

The structure of the room is simply represented as a 2D or a 3D grid.

Room	Grid

A 3D grid can be useful even for a 2D game. For example, in my game, I use a 3D grid with three layers to be able to have objects above others.

Cells in this grid can be in three different states:

1. The empty state, when a cell is free and can receive an object. These are the black tiles on the pictures.
2. The margin state when a cell is free and we want it to remain free. These are the grey tiles on the pictures. We can notice that the connections to the other rooms are margin cells to make sure that these tiles remain free.
3. The full state when a cell is already physically occupied by an object or a wall. These are the white tiles on the pictures.

We may also want to add more data to a cell like marking it as a wall or a door which will be useful for certain constraints.

Modeling the Objects

First, I find it more useful if a variable can represent not only one object but a group of objects. For example, a table with two chairs.

We could do that by using several variables and constraints to force the objects to be next to each others. But it would make the CSP much more complex and difficult to solve for no good reason.

Then, I specify a collision box which is the physical space that the objects will occupy.

And a margin box which will be the space around the objects that will need to remain free for gameplay or aesthetic reasons.

For example, we want space in front of the forge to make sure the players can access it.

Finally, I added the support for optional boolean masks for the two boxes to be able to add finer details if needed. As you can see with the counter.

More Randomness

I specify the lists of objects for my rooms in JSON and here is what looks like the definition of a variable.

{
    "objects": ["Painting1", "Painting2", ...],
    "constraints": [
        {
            "NextToWallConstraint": {}
        }
    ],
    "range": [1, 3]
}

First, we can notice that for a given variable I sample among a list of objects. In the example, I want to add a painting in the room and I choose among a list of them.

Then, let’s observe that the more we add variables to the CSP, the more difficult it will be for the solver to find a solution. And there are some objects like decorations, if the solver fails to place them, it’s not a big deal, the room stays valid.

So I separate the objects in two lists. The required objects which are the objects that the solver needs to place, otherwise the room loses its meaning.

And the optional objects, the solver will try to place them after the required objects but it will just try each value in their domains once and don’t backtrack if it fails to place an object.

What’s nice with optional objects as they are not required, we can make them more random with for example a probability of appearance or a random count. For example, the paintings have a range attribute and the solver will try to place between one and three in the room.

I will stress more on that at the end of the talk but optional objects are very useful to add variability in the generated rooms.

Unary Constraints

Let’s look quickly at some of the constraints.

The simplest constraints are the unary constraints. They are the constraints that deal with only one variable.

For example, you want an object to be at a certain distance to a wall or in a corner.

The strategy for these constraints is just to remove the values in the domain that don’t satisfy the constraint before running the solver.

So if you add a constraint that an object needs to be against the north wall, the domain will be only the purple cells of the first row. And if you want the object to be in a corner, the domain will be only the four purple cells in the corners.

No Overlap Constraint

The two next constraints are so important for room generation and they need to be implemented efficiently that I baked them directly in the solver.

To quickly check the overlap between objects, we will just reuse the grid we got as input but we will update it after each assignment or backtracking. After an assignment, we add the object, and after a backtracking, we remove the object.

Connectivity Constraint

The connectivity constraint implies that all the free cells must be reachable.

You can check that using a simple depth-first search algorithm. But you would need to run the DFS after each assignment which could be very expensive.

There is a little trick that can help a lot.

If we look at the tiles around the object we just placed, and the free tiles are in one piece, then we are sure that the room is still connected.

Don’t disconnect	Do disconnect

However, if the surrounding is in two or more pieces then, we may have disconnected the rooms and we need to run the expensive DFS to check. This heuristic can save us most of the DFS calls.

“10’000 bowls of oatmeal” Problem

So far so good but we have an issue and it has a name, it’s called the “10’000 bowls of oatmeal Problem”.

It says that we can very easily generate a lot of bowls of oatmeal by just changing the position or the rotation of each oat, but they will all look the same.

In our case:

• the bowl is the room.
• the oatmeal is the objects.

And as you can see on the picture, if we use the same input, the solver just move the objects in the rooms and we get a very similar output.

Solution 1: Change the Bowl

The solution to the 10’000 bowls of oatmeal problem is of course, as all procedural generation practitioners know, to generate different bowls. Different shapes of bowls, different colors of bowls. And that way, all the bowls are different!

Of course, I’m kidding but there is an idea there to mitigate the issue.

If you change the context in which the objects are seen, the pattern may be less recognizable.

You can play on the shape of the structure, the textures, the skins of objects, etc.

Solution 2: Don’t Just Eat Oatmeal

But the real solution to the 10’000 bowls of oatmeal problem is of course to change the inputs.

First, don’t overuse a room template. In particular, avoid using the same room template for two rooms close to each other.

Then, use alternative and optional objects. As explained, it helps to add variability in the room templates. That’s what we can see on the animation.

The best solution is to have a higher level generator to generate the inputs to make the room very different or so that they have more meaning.

For example, maybe you have to generate a house for a character. And you have already generated the hobbies for this character. Let’s say he’s fond of astronomy. That would be nice, if you can inject this meaning into the room generator and place a telescope in the house.

Tags and Triggers

One nice and simple way to achieve this, that I am using in my game, is to use tags and triggers.

Your other generators will generate a context which is just a bag of tags. In our example, it will contain the tag “hobby_astronomy”.

{
    "objects": ["Telescope"],
    "trigger": "hobby_astronomy"
}

Then, in the object description, you just add a trigger that will add the object only if the given tag is in the context.

That way, your generators are only loosely coupled. And if you need it you can make more advanced conditions for your triggers using propositional logic.

Conclusion

To conclude, I would say the using CSP in your generators is easy to reason about and easy to implement. But be careful of the 10’000 bowls of oatmeal issue.

Here are some references if you want to go further in some of the topics we dealt with:

• On CSP Theory: Chapter 6 of Artificial Intelligence: A Modern Approach, Russel & Norvig
• On “10’000 bowls of oatmeal” issue: So you want to build a generator…, Kate Compton
• On Tags: Procedural Level and Story Generation Using Tag-Based Content Selection, Jurie Horneman in Game AI Pro 3

Few weeks ago, I released the version alpha 2 of Vagabond. One of the new features is the ability to mine ore veins in caves. This article is the follow-up of the two previous parts on dungeon generation (part 1, part 2) where I explained how the structure of the caves were generated. However, the rooms were completely empty. In this article, I will explain how the rooms are filled with monsters, bosses, ore veins and treasures.

If you want to try the game and explore the procedurally generated caves presented here, you can play the free demo available on Steam. If you have any feedback, do not hesitate to send me a message, I would be delighted to read it.

Current State

To quickly recap where I stopped my dungeon generation algorithm, I use a BSP algorithm to create rooms, then I select a subset of the room edges as corridors, and I run a constrained cellular automaton to create walls with an organic shape. Finally, I run several post-processing steps to clean the result. You can see all this steps in the animation above.

So, as we can see on the image below, I have a clean abstract structure of the dungeon: clearly delimited rooms, a graph of rooms and a 2D array of booleans that represents the obstacles.

Assigning Room Types

My first step is to assign a type to each room. The type will then determine what the room will look like. I do that just before the cellular automaton pass to be able to add specific constraints if necessary.

Firstly, I choose the entrance room. There is a specific constraint: the door needs a wall on which it can be placed on as in the image below.

To achieve this, I randomly choose a room with no corridor on its north edge and a constraint is added in the cellular automaton. You can see this constraint in the example below: it is the little black square in the north western room:

Then, when tiles are generated a door is placed there:

Secondly, I randomly choose a room to be the boss room but I give more weight to the rooms far from the entrance so that the boss is rarely next to the entrance.

Finally, for the other rooms, a random type is chosen among the types for “normal” rooms.

Nothing fancy here, but if you have a large pool of room types and different types of dungeons with different subsets of room types, you can already have interesting results.

In the future, I may choose to use a more complex algorithm to choose room types. For instance, I can use the graph structure to place keys and locks.

Decorating the Rooms

To decorate the rooms, I reuse the room generator I originally created for the building generator. It takes as input an abstract representation of the room as an array of booleans and a list of objects with their constraints, and it uses a CSP solver to place the objects in the room. If you want to read more there is an entire section about it in this article.

For now, as there is only caves in the world, the normal rooms are pretty simple: they are filled with monsters and ore veins. The entrance room only contains the door. The boss room contains a chest filled with a procedurally generated loot. But beware, it is protected by a boss which have boosted stats and a unique name procedurally generated by handcrafted grammars.

The only subtlety was that the room generator can only place objects in rooms not monsters. So I created an object “monster spawner” whose only purpose is to spawn monster to circumvent the issue.

Here is the final result:

Conclusion

That’s all for this quick update on the dungeon generator. The dungeons are now fully playable!

In the future, I would like to make the dungeons more interesting, I have several avenues to explore in mind. On the one hand, I would like to work on the lore of dungeons: to generate stories and quests for each dungeons. On the other hand, I would like to make dungeons more interesting by theirself: maybe by adding keys, locks and puzzles, by having several stairs, and also by adding some special objects in corners and dead ends to encourage the players to explore.

In this post, I will show you how I used falling sand automata to generate death animations for monsters of my game Vagabond.

Falling Sand Automata

A falling sand automaton is a cellular automaton that simulates how grains of sand move due to gravity and create piles.

The rules are simple:

• If the cell below a sand grain is empty, the sand grain moves to the empty cell (see (a)).
• If the cell below a sand grain is full but the cell at bottom left or the cell at bottom right is free, the sand grain moves there (see (b)). If both are free, choose one randomly.
• In the other cases, the sand grain does not move.

If you want to know more about falling sand automata, you can look at this article.

With these simple rules you can obtain animations like this:

Generating Death Animations

Now let us see how to use the falling sand automata to create death animations for the monsters.

The idea is to consider the non transparent pixels of the image as the sand grains and to make them fall to create a pile from the corpse of the monster. The only difference with the rules previously mentionned is that each sand grain has now a color. Here is what we obtain:

In my opinion it is not very appealing for two reasons: the pile is very high and everything is falling at the same speed.

To fix the height issue, I use a 3D cellular automaton. I use several layers of the simple 2D cellular automaton. At the initial state, the image is in the middle layer, then the grain sands can not only move to bottom left and bottom right cells but also to the bottom cells of the previous and next layers:

To obtain an image from the 3D state of the cellular automaton, I project the state to 2D by taking, for each (i, j) coordinates, the first non transparent cell where k iterates the layers. Here is the result with three layers:

To improve the speed issue, I randomize the number of rows a grain fall in one step between 1 and \(n\). In practice, I use \(n = 2\) or \(n = 3\). Here is the result:

It produces some holes during the fall as if the monster is disintegrating.

Finally, I skip some frames to have animations with exactly 6 frames. Here is the final result:

The grains are falling, on average, at a constant pace, while the gravity should make them accelerate. If you want you can skip more frames at the end of the animation to simulate that.

You can find the complete script on GitHub.

What’s nice is that if we are not happy with the result, we can rerun the script with a different seed to obtain a new animation. Here are several animations for the bat:

See you next time for more!

Hi everyone!

It has been a while since last time. I was working very hard on Vagabond to be able to announce you today that Vagabond is now in alpha!

The game is available on Steam and its official website is vagabondgame.com.

I wrote an article on the game website about this first version if you want to know more. All the announcements about the game (releases, changelogs, news, etc.) will be there, while the devlogs will stay here, on my personal website.

During these nearly nine months without post, I did many things and therefore I have many things to write so expect several articles in the comings days and weeks! :)

See you next time for more!

Last month, I had been working on city generation. The goal was to use buildings generated by my building generator, to place them on the map and to link them using roads.

In this post, I will share with you the main ideas and techniques I used to achieve that.

Here is an animation showing the overall process:

Building Placement

To place the buildings I use an algorithm inspired by Bridson’s algorithm for Poisson Disk Sampling. The idea is to place buildings one by one, and to place a new building next to an already placed building. The already placed building are tried from oldest to newest, this way, the cities have a concentric shape that is more organic.

Contrary to the original algorithm for Poisson Disk Sampling, I do not use a grid to check for collisions because the bounding box of each building is different, instead, I use a quadtree.

Road Network Generation

For road generation, I decided to reuse the algorithm I have already developed for roads between cities described here: pathfind each door to each door using A* algorithm with a discount for already used road segments.

The problem is that contrary to the problem with cities where I had a dozen cities, here I may have several dozens buildings and as the number of pathfinding runs is quadratic with the number of buildings, it makes a huge difference. Moreover, for roads between cities, the graph was small, but for roads between buildings, the graph is a grid, it has a lot more nodes and edges.

For a city with 40 buildings, it took 200ms to compute the roads. I thought it was too much.

My solution to reduce the time spent is to reduce the number of pathfinding runs done. The idea is to find paths only between a building and its direct neighbors. To find the neighbors of buildings, I compute the Delaunay graph (I use my library to compute it, you can read more about it here). Here is the Delaunay graph of a set of buildings:

Now, I only have a linear number of pathfindings to perform. For a city with 40 buildings, it now took only 20ms, that is a big improvement!

We now have a road network but it lacks structure and it is a bad navigation mesh. To fix that, I modified the cost function of A* to penalize turns. Consequently, the paths are more straight and simpler as you can see:

Currently, the edges are all of length one: they link two cells of the grid. But as the graph is composed of long straight lines, we can compress the graph by retrieving these lines. I achieve that using a DFS:

This graph is way more suitable as a navigation mesh.

The final step is to represent these roads as tiles. I simply rasterize a disk of random radius and with a random offset on each cell of the road network to have something a bit chaotic:

And here is the final result with buildings displayed:

Conclusion

Let us look at some cities generated by the generator to conclude this blog post:

The results are still a bit monotonous but it will be better when the buildings will be more distinct and new types of structures such as market places, wells or castles will be added.

The next step is to populate the cities with villagers.

All the assets used in this post were made by OpenGameArt artists, you can find them there.

See you next time for more!

These last weeks, I had been working on building generation. I want to share with you the main ideas of my method, some insights, and my results!

Here is a quick glimpse of the overall process:

Floor Plan Generation

The first step is to generate the floor plan that will be the input for the next steps.

There were a lot of trials and errors at this step. I wanted something flexible, that is, the generator takes as input a list of rooms that the building must contain and it generates a floor plan, whatever the number of rooms or their shape is. Thus, we cannot rely on some patterns to arrange the rooms. Moreover, I wanted the generator to be robust and always return good enough shapes.

I decided to use an incremental method: to place the rooms one by one.

My first attempt was to maintain the frontier of the building as a list of edges. Then, at each step, I would select an edge and grow a new room from it. The size of the new room was randomly generated. It was a terrible idea, it creates a lot of holes in the building shapes.

My second attempt to prevent the strange holes from occuring was to use a grid to place the rooms. A room would occupy exactly one cell and the frontier is now the set of cells that are neighbors to the already selected cells. Again, at each step, we select a cell in the frontier and add a room in this cell. But to have more variety, I chose to have columns with variable widths and rows with variable heights. It was a terrible idea, again. The issue, this time, is that all the rooms in the same column have the same width, and all the rooms in the same row have the same height, it was a bit weird. Moreover, the topology of the building was too simple for my liking.

In my third attempt, I decided to fix the size of columns and rows, but the rooms can now occupy several cells which will allow more complex topologies. I think this is a good trade-off: we lose a bit of variety on the room shapes but having predictable room sizes will ease the next steps. Moreover, I find this solution particularly clean and simple to implement. I am still wondering why this was not the first thing I tried.

I want to give a bit more insight into how a cell is chosen from the frontier. If you select a random cell, there may be a collision problem (if the room takes several cells) and after several steps, you may have something very weird. To prevent that, all the cells in the frontier are tried, we check for collisions and a score is attributed to the configuration. Then, I randomly pick a cell among the cells that have the highest scores.

One question remains: how to determine the score? Well, in the beginning, I tried to quantify the beauty of a floor plan, and it was hard to find good criteria. Then, I changed my way of thinking instead of trying to select the most beautiful floor plans, I penalize ugly and weird floor plans. And, it reveals to be way simpler to craft a score function that penalizes weird floor plans than one that finds the beautiful ones. I mainly penalize two things: extreme ratios, I don’t want too flattened buildings, and holes. Just with these two criteria, most weird building shapes are ruled out and the ones that are kept are at least correct.

Interior Generation

Now, that we have floor plans, we can generate floors and walls. As the generator is for a 2D game, I have to take care of the projection and let enough place between rooms to be able to put the walls.

I can assign different tiles for the floor and walls of the rooms. But for now, they are uniform for the whole building.

Exterior Generation

Oddly, this was the first thing, I implemented. Even before I finished floor plan generation. Surely because I thought it was one of the easiest steps. In fact, there are some subtleties so that everything works well with 2D tiles.

One preprocessing step that reveals useful is to merge rooms to have larger rectangle parts. To achieve that, I used a greedy meshing algorithm.

Wall Generation

Nothing really difficult there. I just draw the bottom walls of building parts.

Roof Generation

Roofs are more challenging. I studied the different types of roofs a bit. For now, two of the simplest types, flat roofs and mansard roofs, are supported.

I also have an experimental implementation of hip roof generation. Hip roofs are more complex because the tiling depends on the width and you must have a special case for the transition between two building parts. I will finish that later.

Room Generation

Placing objects in the rooms is by far the most interesting part of this generator.

The first step is to define object groups, it may be one object alone or objects that should always be placed together, for instance, a table with chairs. For each object group, I will also associate a collision box and a margin box. The collision box corresponds to the tiles used by the object group while the margin box corresponds to the tiles that must be free around the group to be able to interact with the objects in the game.

Here you can visualize the collision box and the margin box for some objects:

Then, for each room definition, I make a difference between objects that are necessary and those that are optional. Necessary objects must be placed in the room, otherwise, the room is invalid. For example, there must be a bed in a bedroom, if we fail to place one there, then the generator fails. On the contrary, decorations, such as a pot with a plant, are optional and if we fail to place them, the room is still valid.

Besides, for each object group in the room, constraints can be assigned to it. Some constraints I implemented are: distance to a wall, in a corner of the room or horizontally centered in the room.

To place, necessary objects, I use a CSP solver I have designed especially for this problem. In particular, it can check very quickly for collisions between objects and that the room is connected, that is, we can access to all objects and doors in the room. My CSP solver uses a simple backtracking algorithm.

One important thing, for procedural generation, is to keep the solver “non-deterministic” i.e. it does not always return the same solution. Otherwise, it would be boring. To achieve that, I simply shuffle the domains, the sets of positions tried for each object group.

On the contrary, for optional objects, I do not use the CSP solver. This allows keeping the problems relatively small and easy for the solver and thus to solve them very quickly. For each optional object, I just pick randomly one of its valid position and if there are none, it is not placed and I try the next object.

Here are some living rooms generated with the same set of parameters:

And some buildings with objects:

For now, there are only three different types of rooms: a bedroom, a kitchen and a living room. I will design more later.

Conclusion

Let us look at some buildings generated by the generator to conclude this blog post:

The whole process is quite fast, under 1ms for a whole building, it will allow me to generate hundreds to thousands of buildings during world generation!

Most of the ideas described here are very simple, but as we say, the devil is in the detail, and there were a lot of details there!

Now, that we have buildings, the next step is obviously to generate cities. It is one of the last steps before the release of the alpha version. I am so excited to eventually share my work with people! :)

All the assets used in this post were made by OpenGameArt artists, you can find them there.

See you next time for more!

It’s been a long time since the last devlog.

I have been mainly working on monsters and combats. I created a lot of components and systems but nothing which deserves its own blog post. Let’s see the improvements.

Monsters

Firstly, I ingested several monsters, even if you will only see bats in this devlog. And implemented a very basic artificial intelligence: they wander in rooms of dungeons.

Combat System

It was then time to kick their ass. I had to modify the physics engine to support hurtboxes and hitboxes.

Then, I had to improve the way animations are synchronized between clients which requires me to do huge changes in the codebase.

Eventually, it was possible to attack the monsters:

Monsters receive a small knockout just after being hit.

It is not impressive yet, but with some particle effects and sound effects, it should be funnier.

HUD

It had been weeks, I was postponing the work on the user interface. I rolled up my sleeves and made a basic HUD to display the target monster name and health.

Moreover, I change the inputs. Now, everything is done with the mouse. Thus, I created a custom golden cursor you can see in the video below.

I also started to do preparatory work on a drag and drop system for the future inventory interface.

Cave Generation Update

Finally, I worked on the cave generator. I fixed pernicious bugs occurring during tile generation. Moreover, I added some cycles during maze generation. I am very happy with the results:

I shared this animation on Reddit on r/gamedev, I received many kind comments, it was very motivating!

Conclusion

That’s all for this devlog.

I am currently working on items, inventory, and characters. I think it will be a great step for the game and I hope I will have a lot of nice stuff to show.

See you next time for more!

Last two weeks, I was working on teleporting the players from one map to another. I will use this system to enter into dungeons, buildings, etc. and also to leave them. But it was not that easy to implement as it required some deep architectural changes in the game engine.

A Multilayer World

In a 2D top-down game, it is hard to make an open-world with only one map like Minecraft. It would mean it is not possible to go underground or upstairs in buildings. Thus, I need to be able to display several maps and to go from one map to another using doors.

But it is easier said than done. In particular for a multiplayer game, as there may be several players on different maps, and so you must manage several maps simultaneously. While in a single-player game, you just keep the map where the player is currently on.

Moreover, when I store the position of an entity, not only I must store its x and y coordinates but also the map on which it is. More precisely, as the world can be quite large, it is cut in chunks so I store the indices of the chunk on which the entity is currently on.

Previously, I was using a data structure like this one:

struct Position
{
    float x;
    float y;
};

And now, I am using something like that:

struct Position
{
    // Chunk id
    int i;
    int j;
    int k;
    // Offset
    float x;
    float y;
};

This little change in the Position data structure forced me to rework my physics engine and other systems.

Teleportation System

Once these architectural changes were done, I was ready to implement my teleportation system. As I use an entity-component-system, implementing this was just creating a new component and a new system.

The door component just contains a destination:

struct DoorComponent
{
    Position destination;
}

The door system receives collision messages from the physics engine. If a collision occurs between an entity that has a door component and another entity, it transports the other entity at the door destination. Nothing difficult, once all the other systems are in place.

And it works well, even in multilayer mode where there are two players on different maps:

Dungeon Entrances

Finally, I worked on a dungeon entrance generator. Nothing fancy but it works well and you can change the materials of the walls to match the one used in the dungeon:

Conclusion

That’s all for this devlog.

Next week, I will work on monsters and add them inside the dungeons. That will be a big step!

See you next week for more!

In this devlog, I will show you a technique that I love and that I will abuse in Vagabond: palette swapping.

Palette swapping is simply changing the palette of a texture. Here, we will do that at runtime using shaders. It was a useful technique in the old days to add variety in the assets without using too much memory. Now, it is used in procedural generation to produce new assets, I will show many examples in later devlogs.

Preparing the Images

The first step is to prepare your images for palette swapping. In a raster image, each pixel contains a color. What we would like instead is that each pixel contains the index of its color in a palette. This way, we decouple the structure of the image (the areas with the same color) with the real colors.

In fact, several image formats support this way of storing images. For instance, the PNG image format has an indexed color option. Unfortunately, many libraries that load images will provide an array of colors even if the image was stored in indexed mode. It is the case of SFML, the library I used. It uses stb_image under the hood which automatically “depalettizes” images i.e. it replaces indices by the corresponding color in the palette.

Consequently, to avoid this problem, I store separately the image and the palette. The image is in grayscale mode and the gray level of each pixel corresponds to the index of its color in the palette.

Here is an example of what we expect:

To do that, I use a little Python function that uses the Pillow library:

import io
import numpy as np
from PIL import Image

def convert_to_indexed_image(image, palette_size):
    # Convert to an indexed image
    indexed_image = image.convert('RGBA').convert(mode='P', dither='NONE', colors=palette_size) # Be careful it can remove colors
    # Save and load the image to update the info (transparency field in particular)
    f = io.BytesIO()
    indexed_image.save(f, 'png')
    indexed_image = Image.open(f)
    # Reinterpret the indexed image as a grayscale image
    grayscale_image = Image.fromarray(np.asarray(indexed_image), 'L')
    # Create the palette
    palette = indexed_image.getpalette()
    transparency = list(indexed_image.info['transparency'])
    palette_colors = np.asarray([[palette[3*i:3*i+3] + [transparency[i]] \
        for i in range(palette_size)]]).astype('uint8')
    palette_image = Image.fromarray(palette_colors, mode='RGBA')
    return grayscale_image, palette_image

Firstly, the function converts the image to the palette mode. Then, it reinterprets it as a grayscale image. Finally, it extracts the palette. Nothing fancy, all the hard work is done by Pillow.

Shader

Now, that we have preprocessed our images, we are ready to write the shader to finally swap the palettes. There are two strategies to pass the palette to the shader: by using a texture or a uniform array. I find that it is easier to do it using a uniform array so I use that.

Here is my shader, I use GLSL but I think you can easily translate it in another shading language as it is dead simple:

#version 330 core
in vec2 TexCoords;

uniform sampler2D Texture;
uniform vec4 Palette[32];

out vec4 Color;

void main()
{
    Color = Palette[int(texture(Texture, TexCoords).r * 255)];
}

We just use the texture to read the red channel of the current texel. The red channel value is a floating-point number between 0 and 1 so we multiply by 255 and we cast to int to retrieve the original gray level between 0 and 255 that is stored in the image. Finally, we used that to get the color from the palette.

The animation at the beginning of the article comes from in-game screenshots where I use the following palettes to color the body of the character:

Conclusion

That is all for palette swapping. I hope it gives you some ideas.

In a later post, I will show you how to procedurally generate palettes to push limits of palette swapping.

See you next week for more!

This is the first devlog since I stopped working on the game engine and really started working on the game. I did not publish a post last week, I started writing an article about the new implementation of my entity-component-system library but I did not find the time to finish it yet. The last two weeks were pretty busy.

Moving in the World

The first goal was to be able to move a character in a generated world. To do that, I had to plug the world generator with the rest of the game engine. Then, displaying the world and the character was just creating some nodes in the scene graph.

I tried to use the entity-component-system pattern as much as possible. It was a bit difficult at the beginning as it was the first time I used it in practice. Separating data in components and logic in systems is a manner of thinking I was not familiar with. However, it revealed extremely powerful, in particular in a roguelite and a multiplayer context. Being able to create new entities by blending components is useful to generate a huge amount of content. Moreover, the separation of logic in systems allows reusing common parts of logic between the server and the client easily.

Here is a small screencast of a (naked) character walking in the world:

Multiplayer Mode Is Working

I decided to directly create the multiplayer mode. In fact, the single-player mode just runs a local server which does not accept any external connection. I think that in the long term, starting with this design is easier than firstly creating the single-player game and then trying to add a multiplayer mode.

The client does not generate nor store the world, it is streamed by the server. Thus, the connection is pretty fast, the player does not have to wait while the entire world is downloading.

Here is a small screencast of a second player joining the server opened by another player:

Conclusion

The next goal is to be able to add pieces of equipment to the characters so that they are not naked anymore!

See you next week for more!