Each node in the graph represents a room, and can contain the letter of a boolean variable to set true on entry. The next thing to abstract is the grid of rooms: it’s now a graph. The extension may not even be necessary for a game to be entertaining: keys and doors can be made colored like in Doom and the player might not notice that they never need to turn a switch off (especially if there are multiple sets of switches and pistons). For the sake of simplicity later on, we’re going to assume these variables never go false again: keys are not consumed by use with a locked door, and the switch does not need to be turned back off to solve a puzzle.Īn extension to the algorithm would allow consumable keys and off-switch puzzles, but is not explored in this post. Each of these variables is false initially, but goes true when the player collects the key, hits the switch or picks up the equipment. We’ll give a letter to each of these boolean variables, e.g. Let’s forget for now that these items are keys, switches and equipment, and instead think about boolean variables: you either have a key or you don’t the switch is either on or off you either have the equipment or you don’t. Puzzling abstractionĪll of the elements of these puzzles – the keys, switches and equipment – have one important thing in common: there’s originally some obstacle you can’t pass until you find a certain item that eliminates the obstacle. killing all the enemies) within the room to get that room’s item, but they’re not the focus of this article. There are also intra-room puzzles, where you have to perform some specific action (e.g. These inter-room puzzles are the kind I want to generate procedurally. You have to find the right sequence of rooms to go through to get to the goal. But: you can’t go to the goal without first beating the boss you can’t get to the boss without jumping over the pit surrounding his door you can’t jump the pit without getting the feather you can’t get the feather without unlocking the door to it and you can’t unlock the door without getting the key. The player starts (obviously) at the start, and the goal is (obviously) to get to the goal. For some real examples from real Link’s Awakening, see the Zelda Infinite website. If there was a level like this in a Zelda game, I’d be getting my money back.) More often there are multiple locked doors, and multiple keys, and a miniboss or two in there. The following image is an example of what a really minimalist dungeon in Link’s awakening might look like. Switches that lower and raise piston blocks elsewhere in the dungeon that block your way Īnd equipment such as the Roc’s Feather that allows you to jump over pits that otherwise don’t let you pass. Keys that unlock a door (and leave the door unlocked, but can only be used once) Ī single boss key (aka a big key) that unlocks the door to the boss In these rooms you can find, amongst other items that are unimportant for the sake of this article: Some rooms have walls separating them, and some of those walls have doors, which are possibly locked. Item-based puzzlesĭungeons in Link’s Awakening are broken down into discrete rooms of fixed size, laid out in a grid.
In this post, I’ll introduce an abstraction for Zelda-like item-based puzzles, and an initial algorithm for generating puzzles procedurally. The Binding of Isaac went some way towards this, but doesn’t contain the item-based puzzles that (to me, at least) characterize Zelda.
I mentioned in my post, The Inception of Lenna’s Inception, that I wanted to combine Zelda’s game mechanics with roguelike randomization for my game Lenna’s Inception.
There’s an updated post here, albeit with a different writing style. I’ve redesigned the algorithm for several reasons.
0 kommentar(er)
