Into the procedural caves of Laser Disco Defenders
Published 2 years ago
How iteration led from a game jam prototype to endless groovy action
Hi my name is Alexander Birke and I run Out Of Bounds Games, a small indie studio based in the UK. Today I want to tell you about the procedural level generation in the game I’m working on. It’s called Laser Disco Defenders, and it’s a groovy 70s inspired self inflicted bullet hell, where each laser you fire stays in the level and can hurt you! It started out as a game jam prototype but thanks to finding a publisher I have been able to work on the game full time for the last 10 months.
I have always liked procedural generation since it keeps the gameplay experience varied, so it was an obvious choice for my own game. Because I am the only person doing both game design and programming on the game it’s also an effective way to create a longer lasting game. Here’s how a couple of levels look like in LDD:
[[{"fid":"66778","view_mode":"default","fields":{"format":"default","field_file_image_alt_text[und][0][value]":"Gameplay from Dance Den","field_file_image_title_text[und][0][value]":"Gameplay from Dance Den","field_file_tags[und]":""},"type":"media","link_text":null,"attributes":{"alt":"Gameplay from Dance Den","title":"Gameplay from Dance Den","style":"float: right;","class":"media-element file-default"}}]]
This is the first game where I have made levels with procedural generation, so it took a lot of effort to get right. On top of that the levels had to fit the central mechanic of lasers bouncing around, and since the game is also coming out for Vita it also had to be really performant. Here’s all the different iterations I had to go through before i arrived at the final result. As you will see you can rarely develop one game system in isolation, it affects the rest of the design as well.

Version 0 - Simple beginnings

The original version of the game was made for the Ludum Dare game jam. As you can see it looked slightly different!
In this first version of the game the player had to pick up three keys in order to progress to the next cave while shooting enemies was optional. Each level consisted of one cave that could have short tunnels going out from the center. It therefore didn’t create very varied levels, but it did give me the idea of using polygons as the basic building block for the level generation. It also turned out to be blazing fast, since the level only consists of a single line which made it fast to generate and do collision checks against. However for the full release of the game I needed an approach that could generate more varied levels, and the simple art style had to be replaced with something that allowed the disco theme to come across more easily.


The first attempt after I started working on the game full time. This one would create tunnels and caves on top of each other, and then assemble them afterwards into a level with a single outline shown in cyan. Enemies would then be randomly placed on the outline. From a distance it looks like this one creates a lot of variation in the levels, but as a player you don’t see a level in this bird’s eye view. In fact the levels were hard to navigate since there would often be a lot of empty space to fly through. They were also too random so it was almost impossible to adjust the difficulty of the game and create a good sense of progression. This is something I found out by playing the game myself, and by doing play testing with other people.
Nonetheless I tried really hard to get this version to work. One way was to make lines of music notes the player could pick up for points, that acted as breadcrumbs to guide them to the keys. This was frankly a terrible idea! It was hard to place the notes so they looked good and it was unclear to players what they should do about the enemies, since they didn’t have to destroy them to progress. Something had to change.

Version 2 - Fit room layout to cave size

In this version I prevented caves and tunnels to be created on top of each other. You could still have caves lie so close to each other that they would still be combined into a giant cave, but I was sure that the space inside each cave would be free to spawn enemies inside.
Tunnels and caves were populated by premade layouts based on their size. A layout consisted of a series of conditions and basic rules. That way I could get a certain enemy to spawn only after the player had survived a given amount of caves, and if the cave had the right size.
This worked a lot better since I could make levels that were more varied. I also took out the music notes together with the keys, and made level progression happen by destroying all the enemies in a level which the player would do anyways in order to get points. This made the game a lot easier for players to understand.
So was the level generation finished? Oh no! From playtesting I found that doing things this way had one major drawback. What enemies goes inside a cave determine its difficulty much more than the size of it, so the levels would wary a lot in difficulty. Caves merging together also created levels that players still found hard to navigate.

Version 3 - cave layouts and size defined by rules

So this is where I started to think more about the progression from level to level. I decided to take how many caves the player had survived so far, and use that to get an amount of difficulty points for the current one. Layouts was then given a certain difficulty cost and caves and tunnels would be added to the layout until all the difficulty had been used up. Determining the cost of a layout was done by playtesting. I also made it so caves and tunnels could not cause overlaps, which made it a lot easier to design consistent layouts.
Other things were changed such as preventing the same cave layout from being repeated next to each other. More enemy types also helped to keep the gameplay more varied. With this system I could also create specific rules that would only be used in one zone of the game such as in the dance floor inspired Dance Den you can see below.
As you can see I went from a very generative approach to one that leaned more towards premade designs with a bit of randomization to make the layouts more unpredictable. I therefore had to design more layouts myself but the final gameplay experience was so much better than the earlier versions.


If something is broken in your game design don’t try and fix it by adding in more stuff as I initially did with the music notes. Instead focus on what doesn’t work and either change it or take it out completely. I also found out that for the gameplay of having lasers bouncing around forever, I needed a much more constrained approach than I initially thought. For the next game where I use procedural levels I’m also going to start by first creating a couple by hand to get a feel for how the levels should play before I attempt to write an algorithm that does the job for me. Being able to model the difficulty of the level also turned out to be something that was important and is something I will keep in mind.
If you want to follow the further development of Laser Disco Defenders hit me up on twitter or read the dev log over on my website. We are launching on Vita at the end of July and on PC + other platforms later in the year, so I hope you want to follow me along on the rest of this groovy journey.
Alexander Birke
Programmer & Game Designer