Games Practical Project Development Blog - Week #8

This weeks work was very much a continuation of last week, progressing further with Cellular Automata development, ending up with the first playable version of the new level generation, alongside implementing the groundwork for the player to be able to block.

Following quickly on from last week, I set about implementing the rules required for the iterative process of Cellular Automata, in summary, checking the neighbouring cells around the current one, checking how many are walls and how many are floors, then depending on the set lenience, either leave the cell as is, or change into whatever the majority of its neighbours are. This process is repeated for every cell, 4 times to normalise each cell and create a more coherent floor plan.

The first fully realised version of cellular automata in my project, generating different layouts each time

After the level is generated, I needed to set up the function to populate the floor after the generation and iteration is settled, and knowing that the levels could be wider or taller depending on what numbers are placed into the Cellular Automata BP, I knew the function for spawning things into the level would need to be equally scale-able. In order to allow this, I made sure to have the max number of things spawned also be a public variable, to allow for more or less crowded levels as it suits.

The function to populate the floor with randomly selected things, currently showing spawning an arch from an asset pack, and melee enemies

In order to keep with the overarching theme of procedural and replayable gameplay, I made sure to have no set forced spawns or locations, except for the next ladder down, by checking after the final thing has been spawned if said ladder exists. If it doesn't it will manually spawn the ladder at a random location. The locations for all spawns are chosen at random from the list of all the floor cells that were generated. This works well initially, but as things get larger, or rooms get smaller, things may choose the same cells to spawn on, and overlap with eachother. This could cause silly clipping glitches, or run endingly disasterous spawn locations for the player. This is something I will continue to test and plan around to find the best solution going forward. A problem that rarely comes up, but comes up none the less, is the possibility of the floor generating a wall that cannot be bypassed, and the path down be on the other side of the wall, essentially soft locking the players progression and forcing them to return to the hub, and regenerate the levels to hope for a path. To get around this, I plan on developing a pathing system to check if there are floor cells from point a to point b, and if there is a problem find a solution to it.

The player being placed into the generated and populated level, ready to play

Finally, after some feedback from playtesting, the combat felt somewhat lacking. My ideas to solve this is to put more control of the combats flow into the players hand. This lead me straight to the idea of blocking, and I got ahead of myself immediately jumping into implementation, still high off of the success of getting the first version of true level generation implemented. I got some quick animations set up, and altered the way the player moves while blocking. It was only then that I thought about how blocking would be balanced. Should I go against my original plans and add a stamina bar, a la Dark Souls, do I take a percentage off of the damage taken while blocking, does it knock the player back a fair distance, but block all damage? I wasn't sure where to take this mechanic, and ended up leaving it in the back burner for now. Whether or not the mechanic changes, I'll decide at a later date.

Currently only a change to the players animations and walk speed