Procedural Level Generation System
In this blog post, we are going to talk about how we designed and implemented a procedural-level-generating system to prototype levels faster and create vanilla levels with the required prerequisites in an instant.
The need to build such a system
In the early days of developing Remortal, specifically in the pre-production phase, there was no pre-defined approach to how to design levels. Mainly because we ourselves, didn’t know what we exactly want from a level in our game. There were some restrictions here and there on how not to design levels but the only useful piece of information on how to build the gameplay was the high-level vision and feeling that our team had agreed on.
To be clear, we had a rough picture of how the game should feel and what mechanics are needed in each chapter to match the atmosphere and the story that we intended to narrate but everything else was too abstract at that time. So it began with our vision. We had some clear sources of inspiration; games like Thumper, and Sayonara wild hearts, and the narration style of titles like Journey. By doing a fair amount of playing, researching, and MDA analysis we reached a point where we could easily describe how a level should be designed and feel in Remortal. To replicate these feelings we came to the conclusion that a general-purpose system has to be designed. A system that based on its inputs would create a level or at least a viable skeleton for one. To clarify, a level in this context means a series of static and animated obstacles which players have to dodge in order to finish that level. But why create a complex system when you can build a level manually on your own? We made this decision for multiple reasons:
- Based on the needs of our development pipeline, we wanted levels, like lots of levels, but we needed them fast and in a reliable approach.
- On many occasions, we had to create and test our envisioned flows multiple times with minor tweaks and differences. To develop these game flows, certain metrics had to be applied and then observed.
- In the pre-production phase, we had to build levels with lots of trial and error but at the same time, we knew that generated levels at this stage would be thrown away. So there had to be a way to develop not-so-accurate levels fast and cheaply.
So we decided to build a procedural level generating system, now let’s review the design process behind that system.
The design process of developing this system
Based on our needs and what we wanted from this system, which was to only prototype and test levels; we decided to build everything based on one important metric, difficulty. Therefore a few guidelines were written to help with developing the system:
- One or a number of difficulty curves should be outlined and all the levels should follow such curves.
- If we assign numeric values to each data point of a difficulty curve, we ought to be able to calculate the difficulty at any given time. In other words, we should have a function or at least some pre-defined curves where we can find the required difficulty at any time.
- Assuming we know how difficult the level should be at a certain time, there should be some variables to control this numeric value that represents the difficulty. For example, the time to react or the distance that needs to be traversed in the 2D space (where the player can move in) could be some of these variables.
The next step was to design the system based on these guidelines. Centered on our research, we decided to have an overall rising level of challenge at most of our game levels. But it’s so important not to always increase the difficulty at all times at one level. In other words, there should be timeframes where players can catch their breath and get ready for the incoming challenges.
The other important design decision was to choose the underlying variables that are going to affect the difficulty at any time. After a few talks and experiments, we chose the camera speed and the traversed distance in the 2D playable space, as the main elements that will affect the difficulty at any point. But choosing these variables was not the only decision in that regard, we also had to determine the relationship between the mentioned features and the game difficulty. Without going into details, after a few experiments, we decided if the difficulty is going to be multiplied by X , the distance should also get multiplied by X but the camera speed will be multiplied by \sqrt{X} .
Here you can see a picture of one of our pre-defined difficulty curves:
The big picture and some afterthoughts
So far, we’ve explained how a single level would be generated with the help of our procedural level generating system. But there’s a bigger scope too. There are multiple chapters in Remortal and each chapter has a bunch of levels. The connection between these levels and the flow had to be tuned according to our high-level vision to create the best possible experience for everyone. Therefore we took the next step and created an extensive difficulty curve to cover the whole game based on one of the most famous plots in this respect which is the picture below:
Not only a similar curve to this picture was used as the expansive difficulty curve for the entirety of the game, but also it was used in each chapter. To explain this matter briefly:
- At first in the Intro section, the player will learn the basics of the game and will become familiar with the controller scheme.
- Then in each chapter, the player will learn new mechanics and master them towards the end of the chapter. Accordingly, this will happen in the learning and progress section of the difficulty curve.
- The final levels of each chapter would be the kill-off section where players’ limits will be tested and they have to combine and use their movements and mechanics really well.
- Now imagine what was explained in the previous bullet points and scale it up to the whole game. This means that gradually the game will become harder and later chapters will require more skill. In other words, the later chapters are going to have a higher entry barrier.
The Implementation
In this last part, we are going to take a look at what got implemented based on the design of the procedural level generating system. Developers decided to break down the difficulty curve into two separate curves which were the camera speed curve and the distance curve. Here’s a picture of the implemented system:
You can see that there’s a solid connection between this system and the shape of our pre-defined curve which was shown earlier. It’s worth mentioning that this implementation made the whole procedure of making levels a lot easier. By pressing the spawn button, in a matter of seconds, there would be a new level or in other words, a series of obstacles spawned exactly based on the intended difficulty curve. It means according to the inputs, at times the camera speed would be increased, and at times the distance that players had to move their finger on the screen would increase or decrease based on the pre-provided curves.
To wrap up this post, it’s noteworthy to say that this system was used mostly in the pre-production phase to prototype cheap levels fast and reliably. Game designers also used this system even in production to create vanilla levels as a starting point and then iterated over those levels to enhance and craft the best version out of them.
Leave a Reply