Cliff Hanger is an incredibly generic and copyright-infringing working title for the game I'm making to play around with procedural generation. The goal of this project is to incorporate strategic elements like equipment and resource management into a turn-based game without it becoming a dungeon crawl. To get away from the feel of roaming a dungeon, I thought it would be interesting to flip the typical turn-based strategy perspective by making it vertical. Rock climbing seemed like a theme dramatic and concrete enough to inspire some game mechanics I haven't worked with before while providing that verticality.
While equipment and other character-differentiating components haven't been implemented yet, the basic game loop and map randomization are working. Designing the game loop itself has been a little scary since there aren't a lot of climbing games out there to draw upon, and I'll probably tweak it some more by the time the project is done. On the other hand, it feels nice to be developing something off the beaten path and getting back to basics. When coming up with new game mechanics, one approach is to view them as metaphors for real-life experiences.
In rock climbing, two clear factors jumped out at me as important - how fatigued you were from climbing, and how good your current handholds and footholds were. As game resources, we could concisely label them stamina and grip. Stamina is something that decreases over time and is hard to recover, so a meter represents it well. By contrast grip is something that can be lost at any moment, but is just as easily recovered. Grip is more of a state, so its representation should be more like a switch or traffic light. With that in mind, the current UI overlay looks like this:
The green bar just to the left of the climber is his stamina. Just to the left of that are 1, 2, or 3 yellow tokens representing how good their hold is on the wall. To the left of that is the only item implemented so far - wall anchors. A yellow pedestal is drawn under characters who haven't yet taken their turn.
Stamina's interaction with the game is relatively simple - players lose some amount each turn and if it hits 0 they fall off. Stamina can be recovered by standing on an outcropping. If the player falls off the wall they will die unless they've placed a wall anchor in a crack; in that case they will drop below the anchor and it will pop out. Each player gets 3 anchors. A player currently has to forfeit a turn to place an anchor by selecting a climber who is on a crack and then clicking them again.
Grip's interaction with the game is still a bit up in the air. As currently implemented, grip determines how far a climber can move in a turn - if they're barely holding on then they aren't stable enough to make a big move. Whenever a climber tries to move, a real-time mini-game pops up. If the player succeeds, the climber moves that distance. If not, the climber loses a turn and some grip. If the player fails 3 times in a row, the climber falls.
A successful move will recover 1 grip token (max of 3). The difficulty of the mini-game is based on how far the player wants to move: 1 for each square +1 if ending on an outcropping -1 if ending on a crack. When a climber is selected, their movement range is highlighted, and mousing over a square will display the difficulty value of the move.
A turn limit was added to provide time pressure with the idea that the climbers are either escaping a threat from below or racing the sunset. If at least 1 climber gets to the top of the screen by the end of the timer they proceed to the next level. There are 3 climbers, which are sort of like lives since there is no interaction between them currently.
The procedure used to generate the cliff face is super simple right now. It starts with a base to ensure that a few ledges and cracks are available to the climbers...
Some number of ledges and cracks are then added randomly based on the level. Each new level has 10 more tiles of outcropping and 5 fewer tile cracks placed. By level 8, the only cracks that remain are from the initial setup.
The random spattering of tiles can sometimes turn out interesting, but not very often. That's where the procedure of procedural generation comes in - the logic needs to know what shapes are interesting and how the game works. I work with chemical analysis of proteins for a living, so I like to think of level complexity in the same way as protein complexity. For a protein, there are three levels of complexity:
For level design these levels correspond to the following complexity levels:
A level generator should first carve out the path(s) of player movement, then the sorts of areas the paths are composed of, then the individual tiles, traps, etc. within those areas. For this system, luckily, the location of the tiles doesn't entirely block player movement so it's impossible to make an unsolvable level. The player's path is always from the bottom to the top of the screen. Ledges make it more difficult to progress, but the top of each ledge is also an area of recovery. Tertiary complexity can be introduced by making outcroppings that are at least 3x3 tiles since maximum movement is 3 so a player is deterred from going in that direction.
Within the areas delineated by those outcroppings, secondary complexity would involve interspersing outcroppings in generally horizontal configurations since ledges tend to form that way in real cliff faces. Cracks are both checkpoints and a means to reduce movement difficulty, so they could be used within rooms as an obvious path or to connect areas by spanning the larger ledge chunks. Primary complexity is pretty simple right now since the only tiles I'm working with right now are ledges and cracks. The shape of each is handled by the tile swapping algorithm.
Aside from improving the map generator, a lot can still be added to the game.
But for now, there's a simple demo. Play it here!