In game design, at least the way I do it, there is the concept of keys and locks. These control what I call objective planning. Essentially, the flow from one place or task to the next. Sometimes the keys and locks are literal, like find the red key to enter the door with the red key. Other times, they aren’t literally keys and locks in the traditional sense. For example, needing to jump to a high ledge could be a lock and finding the high jump boots is the key that unlocks it. Other times, it could be that you can’t go to the last boss in the game without taking out all the other bosses first.
One of the first major steps toward world generation is figuring out the objectives in an order that is actually possible. When explaining this to friends and family I refer to Zelda: A Link to the Past for the SNES, specifically randomized versions of it. The example I always use is the hammer upgrade because there are several areas of the game that require the hammer to access them. It’s probably pretty obvious that the hammer cannot be found in any area that requires the hammer to access it because if that were the case you’d never be able to get the hammer or access any of those areas.
This example is pretty straightforward, simply have a way to know which areas need the hammer and make sure you don’t put the hammer in any of them, right? It gets worse.
Now, imagine a second tool, perhaps the hookshot tool. This has its own set of areas that can’t be reached without it. Many of those areas don’t require the hammer to access, so we can just do the same thing as we did with the hammer and make sure the hookshot is safely in a place that doesn’t need the hookshot to access. Except now that doesn’t really work the way you think because these two items can’t be considered separately. What if the hammer is in a place that doesn’t need the hammer to get to, and the hookshot is in a place that doesn’t need the hookshot to get to, but both are in places that require the other tool? You’re locked out again. You can’t get the hookshot without the hammer and you can’t get the hammer without the hookshot.
Now expand this to a dozen or so items that can limit places you can go and the interactions and circular dependencies can become very complex to keep track of. Add to that a fully randomized world not just randomized item locations in a known world and now I can’t hard code what things are needed to get to each place because the places don’t exist yet.
The solution is to build a graph structure that is made up of the keys as nodes with the locks placed on the connections between nodes. Building this graph is tricky but not terrible. Once you have it, you can glue the world space for the player to explore onto it during world generation and be sure you can actually get to everywhere and get every item because the graph already figured that out.
This is the first part of one of the largest systems in the game and it’s critical that I get it at least reasonably correct. It doesn’t have to be perfect, or know about all of the keys and locks right away, but it has to be flexible enough that I can add new keys and locks as I think of them without having to start over.