Creating the bones: Procedural Generation | DevLog_011

For the Hypercasual brief, I have decided to go with an endless runner. The idea is Temple Run meets frogger. With each Grid (Street) being procedurally generated. This idea has been modified over the past few weeks as I have gone back and forth between what I thought was playable. 

First Pass

Initially, I had made a level that was generating new Grids spawning in 3 different directions that the player could travel: West, East and North. This means the player would have freedom of movement while traveling, instead of linear guiding like would be seen in Temple Run. As I created this and briefly tested it, I found that giving the player complete freedom of movement made for a very slowly paced “runner” as the player was always choosing where to go next.  

This idea was immediately scratched as I feel it really went against the original concept of a fast-paced runner with split-decision obstacles to dodge. Which sounded more fun.

Linear Design

I felt this was a key breakthrough as now I have more of an idea of how to structure the level. Again, still in early stages, there were a few more ideas to test. First idea was to have a data set of Grid Templates to spawn in that could randomly spawn in powerups or the occasional obstacle. This in theory makes sense and how I assume many endless runners work. But having done something similar in the past, I wanted to introduce a newer challenge that I felt was more suited to a “true” Procedurally Generated Experience. 
 
Instead of having a master data set of pre-produced Grid Templates to spawn in, I could dynamically create these Grid Templates on the fly.

Procedural Generation

This element would increase complexity, but as I am still in early stages, the template that I have created from earlier passes seems to be a good structure to build off. I already have many of the bones built, such as: GridTemplate Actor with properties, SpawnHandler that spawns new GridTemplates and functionality to dynamically size the existent Grids in the world to limit memory space and extraneous actors in the Game World. 

With the GridTemplate, I have introduced a new Struct called Layout, which will hold all the properties that would spawn onto the Grid itself. These struct elements can then instruct where the SpawnHandler should travel to next according to where the Player is heading (Forward, Left, or Right). By Default, I will initialize these elements to be a forward-facing Grid to spawn in but can change them on creation as the player progresses in the level. 

Current implementation of Layout Struct

By having this Dynamic layout, I could implement many different elements to the gameplay: Higher difficulty with faster/more vehicles to manage, less powerups, change in direction, etc. 

These Layout properties can be accessed when a new GridTemplate is spawned and then guide the Spawnhandler where to travel next so the Player can have a continuous, endless runner that’s difficulty is scaled as they progress and hopefully, a more interesting experience as a result.  

Layout Properties used to change SpawnHandler Collision that interacts with player
DeleteGrids function which will Pop last (oldest) element off array and destroy actor

Much more testing and iteration will have to be done to scale the difficulty correctly. But as of right now, the bones are there for a more interesting experience in the long run.  

Leave a comment

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