One step deeper into the tech: A first look at the procgen under the hood
Arguably one of the few things that stands out in Sure Footing - other than the lovable characters - is our level generation. We’re quite a small team, but the game itself is pretty big, how do we pull that off? Well, today we'll start to give an idea of what we do as we pop open the hood of the level generation engine.
Like we've said in previous blog entries, this started out as a research project. I was interested in how do you build level generators for games that will scale with difficulty - making the game harder as you go - or at least have it change how it builds levels throughout the game. There is quite a bit of research on how to build procedural generators into layers, such that you first focus on what you want players to do and how you make them do it. There's been some really interesting research in using this method for platforming levels [1] and dungeons [2], including some work I've been involved in as part of my job as a researcher for constructing NPCs [3] and even Legend of Zelda Dungeons [4] (also www.beckylavender.co.uk/the-zelda-dungeon-generator.html). A lot that has informed how Sure Footing works.
So every time you play Sure Footing, you start on the market street, Deletion Dave gives chase as you run across a bunch of platforms, only to reach the next market street. This is what we call a 'sprint'. Our PCG engine builds sprints and places them in front of the player. Each sprint is built in two phases:
What do we want the player to experience?
How will the player to do it (and how difficult will we make it)?
Each of these phases uses a different system to do their job, but are reliant on each other to complete a sprint. The first part decides on a list of activities for the player to do. We have lots of different ways of managing this, but the simplest version just picks them at random.
What this does is that it selects from a series of basic action or concepts: flat runs, incline ramps, decline ramps, springs that shoot you skyward, splits in the track, traps etc. And puts them together in a sequence. We’ll save discussing how this works for another time, but the key thing is that action has a cost attributed to it. Some of them - such as running on a flat straight - are rather cheap, while others are more expensive. We have multiple modes this system can adopt where these costs can shift based on what we want it to prioritise.
Meanwhile, the second part then decides what platforms should be used to represent that in the game. We figure out what the actions are in one big chunk of computation - which doesn't take all that long - after that, we then place the required platforms every frame until the sprint is completed. We changed it to start working like this for the itch.io build as before you used to be able to spot a dip in performance when we created new sprints. That's not all that desirable.
Once all the platforms in the sprint are positioned in the Unity game scene, the next market street is placed, followed by the cityscapes or 'Sectors' are built behind it. We gather a lot of data about each sprint we make, but two important pieces are:
What is the height of the last platform in the sprint?
What's the highest and lowest points of the sprint?
The maximum and minimum heights influence the distance the player has to fall before the game will automatically kill them (e.g. if they fell through a gap in the platforms). Meanwhile, the height of the last platform is used to ensure we place the next street in the right place, but it also determines the level at which the horizon is placed for the background. Next time you play Sure Footing, you'll notice that the horizon of the sector is always level with the end street. This is done for a number of technical reasons, but also a design issue in that we want you to always be able to see the background. We can guarantee you always see the sector cityscapes because the sprint will always meet it at the end.
Now this is just skimming the surface of how this works. I'll be back in future blog posts to discuss:
How do we decide the activities for players to commit?
How are platforms selected and positioned?
How do we decide where MIPS (coins) and crates appear?
Just how many different level generators run behind the scenes (there's more than you think)?
Some of the other procedural generators that are used every time you play.
How do the difficulty settings work with the level generator?
The current and future work we're doing in creating even more level generators.
[1] Dahlskog, Steve, and Julian Togelius. "Patterns and procedural content generation: revisiting Mario in world 1 level 1." Proceedings of the First Workshop on Design Patterns in Games. ACM, 2012.
[2] Dormans, Joris. "Adventures in level design: generating missions and spaces for action adventure games." Proceedings of the 2010 workshop on procedural content generation in games. ACM, 2010.
[3] Vinciguerra, Michele, and Tommy Thompson. "A procedural generation framework for a robot construction game." Computer Science and Electronic Engineering Conference (CEEC), 2015 7th. IEEE, 2015.
[4] Lavender, Becky, and Tommy Thompson. "Adventures in Hyrule: Generating Missions & Maps For Action Adventure Games." AI and Games Track, Symposium for Artificial Intelligence, Simulation & Behaviour (AISB) 2016.
areudirty
blakekathryn
andulkaphoto
origamiaround
vaporwave
kaledo-art
turnnoffyourmind
kianamaiart