This time I want to talk about what exactly each one of those little puzzle pieces actually refer to. It's simple enough to say that it is "a puzzle", but what does that mean? That nifty Monkey Island flowchart linked in the last musing had a whole bunch of puzzles, ranging from the mundane ("Take pot from kitchen") to informal information gathering ("Talk to Swordmaster") to summaries of complex, multi-step actions ("Follow 'map' in forest to treasure") to act breaks ("Part II: The Journey").
All of these constitute a "puzzle" in the adventure game world largely because they are decisions that the player must make based on some sort of logical jump. But some of them aren't a big jump (if you can pick it up, don't think about it, just take it). And the whole point of the dependency graph is that these jumps can not be made without obtained items or knowledge that are not available without solving a previous puzzle. In fact, most puzzles are encountered long before they can actually be solved, giving the illusion of freedom and exploration that the rigidly defined dependency graph doesn't really offer. Even a linear series of puzzles, if encountered out of turn, can seem quite open ended.
That's actually what, I believe, separates an adventure game from a puzzle game, like Professor Layton. Similarly, it's what defines a Metroidvania - the ability to see cliffs you can't yet scale or doors you can't yet open. Perhaps the defining trait of these types of games, then, should not be the puzzles themselves, but the order they are encountered and solved.
The reason I bring this up is that each puzzle doesn't actually represent a puzzle. It actually represents a collection of elements that interact together towards a singular event the player must participate in to progress. In very many of these cases, these elements are self contained, though sometimes related by theme or story. For an adventure game, it is very likely that these things come together to represent a puzzle. For a MMO, this might be a series of quests that involve killing 12 of some endangered species. For a Metroidvania, it could simply be parts of a map and the obstacles that prevent you from getting there. For a game like Metal Gear Solid, it could literally be as simple as a bunch of cutscenes you have to watch.
For instance, let's say that you can't cross the desert without a car. There's a garage right outside of town with a truck for sale. The mechanic that owns the garage will sell you the truck if you have enough money, but the truck also needs a full tank of gas and a set of new tires. The puzzle is that you must give three things (cash, tires, gas) to the mechanic, and in return you will gain one thing out of it (a working car). To obtain those three things, you might have three separate "puzzles" (be they actual puzzles, story cutscenes, missions, or grinding and gathering) as a dependency.
(At the moment, I don't have a better word than "puzzle" to describe these components, so I'm sticking to it. In a way, they are still puzzle pieces to the bigger picture, even if they are not always something which must be solved in game. Yeah, I'm talking out of my ass now.)
Anyway, the point that I'm trying to make is that each puzzle is an almost self-contained ecosystem. Were you to cordon off the puzzle into its individual elements, you'd have a reusable component. In a game like an RPG, a puzzle might just be a quest giver to be inserted into the local hub, along with a few rules for building a quest about killing local wildlife. These puzzles don't need to be complete entities unto themselves. They can be rules for building or inserting them into other locations. Perhaps even variables that allow you to control those rules.
If you were writing an adventure game where the puzzles are very tightly woven into the narrative, even though the actual gameplay components are part of a self contained ecosystem, the narrative components would not be. Procedurally generating that is a little above my pay grade. However, if you have a bunch of barely related ecosystems, the ability to connect them together in a logical way is pretty much the first step towards creating a fully procedural game.
Of course, just because the puzzles themselves are self-contained ecosystems, they are not entirely self contained. For instance, due to how the game is structured, perhaps you only have a desert-style garage that would look out of place in a forest. A puzzle may have prerequisites for its use. Nowhere is this more obvious than the dependencies themselves.
A small change I've made to the dependency graph is to include the actual items on the dependency lines. I like to think of it is the input and output of a puzzle. In a very large way, most puzzles are little more than trading one item for another. Put in gasoline, money, and tires and get out a car. Or if not an item, watching a cutscene or registering a particular flag. The dependency of a puzzle is not actually on another puzzle, but instead on the outcome of solving it.
In other words, the mechanic doesn't actually care HOW you got those three items, only that you possess them. The input requirement are the items themselves. The way that each puzzle is connected to each other is through these items - the inputs of one puzzle are the outputs of another. They are the glue which connects the whole tree.
As briefly mentioned above, it doesn't need to be items. A lot of times, it is a simple binary flag being flipped. For instance, in many JRPGs, the plot only advances after you've talked to a specific person in town. The puzzle is "talk to Jim", while the connecting glue is simple "flag #0145 set".
I think I've talked about this before, but I believe that the trick to procedurally generating a dependency graph is about matching the inputs and outputs. Because each puzzle is largely self contained, in most game genres, these can be linked quite easily by choosing a glue that satisfies both the output conditions and input conditions of two puzzles.
Going back to my blueprint system and the concept of domains, you can specify a link not based on a particular item, but on a set of items based on a certain criteria. In this example, searching the ancient ruins is a puzzle which will yield a particular item that is both ANCIENT and VALUABLE. That's a subset of all possible quest items, and the intersection of all quest items declared ANCIENT and all quest items declared VALUABLE. A golden machine gun might be VALUABLE but not ANCIENT while a clay pot might by ANCIENT but not VALUABLE.
The next puzzle declares as input something which is ANCIENT and HISTORICAL. If the intersection of this set of quest items and the output quest items of the ruins quest has more than one item in the resulting set, these two puzzles can be logically linked together. In this example, this would be the subset of all quest items that are ANCIENT, VALUABLE, and HISTORICAL. If there is more than one item in the set, you can choose one randomly the two puzzles will still fit together. Also note that the output of the second puzzle is "ANY", which means that it can conceivably output any quest item.
So the way you go about creating a (simple) puzzle graph is simple to start with the root node (start from the end and work your way backwards from the final puzzle). Create a set of all the possible quest items that are possible values for that node's input. Then run an intersection for the output sets for all the possible puzzle candidates. If this intersection has one or more items in it, it is added to the candidate set. At the end of the search, just randomly pick a puzzle from the candidate set, pick a compatible glue item, and connect the two puzzles together. If the candidate set is empty, that puzzle can not be connected to anything. Pop it off the stack and return to the previous one.
While my efforts here are largely in the realm of procedural generation, I imagine that one could turn a dependency graph into a sort of programming language. Imagine clicking on a glue item and being able to precisely select which of the possible quest items you want to use. Then clicking on a puzzle component to write dialogue or change variables to customize the puzzle in some way. With the computer handling a large chunk of actually laying out the puzzles and landmass, the game designer can instead focus on the game's "outline" with the ability to go in and add additional details as he sees fit.
|