An idiot’s adventures with procedural generation – Part One

If, like me, you enjoy game development but are a lazy sod, procedural generation is the way to go. Why spend hours designing levels when an algorithm can do it for you?

In between working on Arcus and various other projects, I’m really enjoying experimenting with procedural generation. I’ve decided to take a ‘fuck around and see what happens’ approach, rather than trying to achieve anything in particular with it. I’ve found that by doing this, ideas to create more logical or interesting levels come naturally and quickly to me as I code. A couple of nights ago, I spent about an hour putting together a very basic level generator for a 2D, top down game. The game itself is as simple as they come – collect all of the pickups in the level while avoiding enemies, which have very rudimentary movement. But it was interesting to see how just tweaking a few variables and adding in some very simple logic resulted in levels that actually felt a little bit interesting. I’m going expand on this gradually over time, and chart my progress via future posts here. I’d like my next ‘big’ project (once Arcus is finished) to use procedural generation quite a bit, as I find manually building lots of levels to be incredibly dull compared to coding new and interesting game mechanics. Here’s my simple little randomly-generated game after about an hour – I’ll talk a bit about how I made it further on below:

 

Yeah, it’s pretty basic. Not terrible for an hour’s work though!

My method for generating the levels was very much influenced by Nuclear Throne. Note – I’ve never played Nuclear Throne; I just got the idea from an interview with its creator I watched a while back.

When the level is initially created, it’s completely filled with 32 x 32 blocks, which act as solid walls. A number of objects are then placed at random in the room. Let’s called these objects the ‘path-makers’. At this point, there is only one logic check in place – don’t place a path-maker within 96 pixels of the edge of the level. This avoids the path-makers creating paths that go outside the level.

Upon creation, the path-makers are randomly assigned one of four directions (up, down, left or right), and a random amount of pixels to move per step (between a certain range). If they come within a certain distance of of the edge of the level, they reverse direction, and at random intervals, they switch to another of the four directions. After another, longer, interval, they then move to a point at the center of the map, and upon reaching that point, cease to exist.

As the path-makers move about the level, they destroy any ‘wall’ blocks they come into contact with, creating paths in their wakes. They also randomly place enemies and pickups, until a predetermined number of each of these is reached. Only when all of the path-makers are finished, have reached the center of the level, and are destroyed, can you start playing.

The decision to have all of the path-makers move to the center of the level was to ensure that the chunk of paths created by each path-maker would ultimately link together, so the player could traverse the entire map. This also had quite an interesting and unforeseen impact on design – each level ended up as a central, fairly open hub with narrower, more confined paths leading off towards the edges of the map. I liked it!

For about an hour of work, I had a simple little game with randomly generated levels that followed some logical rules and made sense from a design perspective. Pretty good going I think! I’m going to continue to play around with procedural generation and see what I can come up with, so hopefully there will be a few more parts to this post in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *