The Rapid Level Generation: Procedural Generation in The Rapid Treasure Escape

The first game project I ever worked on was called The Rapid Treasure Escape, a pirate themed local coop racing game.

The goal of the game is to steer a rowing boat together with a player, that you locally share a controller with, through an obstacle course while being chased. You can get a better impression of the game by watching the trailer below.

The Rapid Treasure Escape was my first game project. I’d worked on some small assignments and followed some tutorials before but had never worked on anything that was supposed to be a game and not just a mechanic and also never worked on something with a team of specialists that have lots of talent and skill in their discipline.

Very early on we settled on procedural level generation which seemed a bit ambitious given that I had barely made my first steps in Unity and was just about to be able to translate some of the learnings in C# from my apprenticeship into the engine. 

Even then, with some guidance from Manuel who was more familiar working in game engines, I was confident that we could pull it off in the short time frame we had.

The first thing we worked on was the flow of the river being generated. That was done by using tiles facing a certain direction and connecting to each other.

There were a bunch of issues that came with the lack of experience such as not knowing how to code when framerate is of importance and that not everything should be done in the Start() method. I also learned that encapsulation is nice but making sure that designers have enough control over tweakable values is almost as important (I didn't know [SerializeField] back then). The phenomenon that probably took most braincells and time was the fact that in Unity objects don't get destroyed immediately but instead in the next frame. This was a problem because of the way I was generating the level. I placed a tile and then checked for collisions and would then remove it. With the knowledge of today I would probably check that before with a BoxCast and prevent the looping into itself by setting some restrictions on the tiles that are allowed to be used.

Anyway, we eventually got it working and once the greyboxing started, things were looking whole lot more interesting.

Later on, we wanted to also have obstacles that a procedurally placed allowing for a challenging but fair difficulty progression throughout the level and from level to level. We went through a number of iterations and at the very end, I discovered a bug that was causing for unpredictable behaviour so we had to make some more adjustments.

We first started out just generating obstacles which could be destructible or indestructible and then move to obstacle patterns that group obstacles for more control.

I was able to learn a lot from this project and a lot of that is thanks to the wonderful people I worked with. I'd go about a number of things differently today but I'm very happy and proud of what we have achieved.