Overengineering

Creating an endless level for Run Die Retry seemed like an arduous task, something I could automate. My thinking was that it I’m better off writing a random level generator, which will provide players with “infinite” combinations, rather than manually creating everything. Read on to see how automation is not always the best way forward.
Since my only initial requirements was that there should be no dead ends, i.e. the player shouldn’t be able to get stuck, the prototype was done quickly.

Next up were the turrets. This is where the problems started showing up. Since the turrets fire on a regular interval it is possible to generate an impassable section simply by stacking a few turrets in a row.Good luck with that…

To solve this I added a rule that no more than two turrets can be next to each other. The issue with this approach is that the number of rules grows exponentially.

Every new obstacle requires rules that determine where and how often it can be placed, and all existing obstacles need new rules to avoid creating impassable combinations. Even worse, after all of this, the levels are still not fun, they are too random.Chances of something like this being randomly generated are close to zero…

I’m not saying that writing good rules for the generator is impossible, but in this case it is simply overkill.

In the end I gave up on randomly generating the whole level. Instead now I manually create small sections, which look interesting and vary in difficulty. These sections are dynamically connected in random order to create the level as the player progresses. The beauty of this approach is that it was very fast to implement and it is very easy to add new sections combining existing and new obstacles. In the end it took less time and produces better results.

It’s easy to time the spikes manually.

I should really follow the KISSKeep It Simple Stupid principle more. Maybe then I won’t waste so much time.