Category: Random

Posted: 10/11/07 A way to organize and expose the procedural generation concept to the player. Part 1.

This entry is kicking off a series of many entries on the topic of procedurally generated content. It is not intended to be taken alone. In fact, I'm not even sure that this stuff even belongs in this project at all, much like the other entries on procedural design that I've done. But of the venues available to me (comic, this, blog), this is the most appropriate one to share this stuff given that this is design related and technical.

But! Before I get to the technical stuff, I want to do a quick overview of where the idea comes from. As many of you know, my dream is of a purely procedurally designed game. I dream of the day when I can sit down at a computer and type "design scifi rpg" and it does so, instantly. I see that possibility (and have, I believe, solved it), but I see other possibilities as well.

Procedural design is the next evolution of design - and I don't just mean of videogames. Already, we've separated the design concept from the implementation, much like you have an architect and carpenters. But even the architect requires a lot of, let's call it "design busywork". You've designed the outside and layout of the house, but you've still got to work out supporting walls, where the wall electric sockets go, how the pipes go from the bathroom to the septic tank, and so on.

Many of those decisions are largely dependent. That is, once you have a layout of the room and what it is used for, where the electric sockets go is largely a function of that. You are going to want roughly one socket per wall for bedrooms, and perhaps a few more in living rooms. That's not a decision the designer has to work real hard on. Wouldn't it be great if such decisions were made automatically? If by simply deciding that this room isn't a bedroom but a children's playroom, all the fixtures automatically change to compensate?

That's the future of design. Computers aren't going to replace human designers. They are going to increasingly deal with the small details leaving the designer open to focus on the things that perhaps he finds more interesting. Not just games. Not just buildings. But anything you can design. Cars. Chairs. Computers. Essay assignments. Heck, even blogs. I'm already using that kind of thing right now - the computer is creating the headings in a particular style, I just tell it what words to use.

But it goes deeper than that. It goes larger than that. Why let a computer write a header when a computer could one day be capable of writing the text itself? Why let a computer design wall socket locations when it could design entire houses? Not every creation is a work of art. Not ever creation is a work of inspiration. Many creations are simple the outcome of a functional design. It has less a design than simply an implementer, following the blueprints necessitated by what it is an does. We don't need people to create something generic!

I see two problems with procedural design right now. The first is one of perception. The other of structure. Attempting to solve for these problems is what lead me to this card concept. As it turns out, card games exhibit the two major qualities that are required of PGC. Namely, trees and sets.

The problem of perception is a relatively obvious one. People don't see the potential in PGC because people don't get to see what's going on behind the scenes. As such, all the back room stuff is limited to being shared amongst geeks already interested in the subject in some usenet forum somewhere. When all people see is the result of a procedure, all they can judge it by is the outcome - and if that outcome is lame, like more roguelike dungeons, that's all they'll see as the end potential.

For instance, let's say you have an algorithm that generates a small world with four dungeons on it. Those dungeons could either be selected completely at random, or you could ensure that there are no duplicates and that each choice is weighted based on the last time the player played that type of dungeon and how quickly he generally defeats it. Doesn't matter. To the player, the end result is four dungeons chosen by magic.

I want to get the player involved with the process itself, but not to the point where the player is outright replacing the procedural stuff. Poker is a perfect example of a weighted randomness. The player gets five cards at random. He elects to keep three of them and receives another two randomly selected cards. It's random, but it is interactive and the player has a chance to give weight to the random selection according to his own sensibilities.

The second problem with PGC is largely that of scope. Most PGC is used for extremely limited, and obvious, things, like designing the floor plan for a dungeon or designing large, largely empty terrain or even simply deciding whether a monster dropped a short sword or a long sword. PGC is capable of so much more, but in order to do that, you've got to have a structure capable of dealing with it.

My dream, as I said, is the ability for the computer to instantly build an rpg in any chosen genre on command. But to do that, it requires more than just a floor plan. There needs to be a narrative to the work - a story which takes the player from A to B to C to D - and that narrative has to control everything from how the dungeons are designed to what monsters are fought to what characters he meets to how many towns there are to how many floors in each dungeon there are.

At face value, one can look at that as a bunch of individual problems that are solved one at a time. But by doing that, each new addition to engine will require another special case. That means that each new project you work on, you've got to invent a new procedural pipeline. Randomize this then that, while on the next project, that then this and then that again twice.

A better approach is to encapsulate the structure of a game into a single problem - much like how LEGOs encapsulate building structures into interlocking bricks. Everything LEGOs can build works on the simple principle of snapping the tapered pegs into an appropriate hole. On top of that are the different types of bricks which can dynamically affect how structures are built. Though there are over a thousand types of bricks (of which there are only a few dozen functionally unique pieces), there is no limit to what can be built with them. In a way, LEGO took an infinite problem and reduced it to a problem of dozens.

I though about using the LEGO metaphor, but as it turns out, cards once again already take care of the greatest metaphorical issue, that of sets... or as you may know them, decks. At the simplest level, there are 52 cards in a deck, 13 per suit, four per type. When playing a game like Hearts, the suit represents a particular set that has virtues unto itself.

Taking it even further, Magic the Gathering allows players to design their own decks out of their own choosing - in effect, creating a set of possibilities. The cards in these decks themselves come from sets themselves. For instance, a location card belongs to the set of all location cards and potentially a smaller subset of location cards that share some attributes. Ultimately, MtG is a game where you design your experience through a little bit of randomness, but mainly through the manipulation of sets.

So, if I wanted a computer to design a scifi rpg, couldn't that be likened to a computer building a game using cards from a specific deck? Couldn't you design entire games (or rather genres) simply by deciding which cards go into the deck? Absolutely. Ultimately, procedurally designing an entire world is a lot like playing Magic the Gathering. Structurally speaking, the process can be almost identical.

Let's go back to the example where you have a world that is going to be created with four dungeons in it. Please keep in mind that this is a simplified example, but it illustrates the concept well. Anyway, you are dealt five dungeon cards: volcano, undersea ruins, dark castle, cave, and ice cave.

You are instructed to select two. You do, and those two are then added to the world set. The rest are reshuffled back into the genre deck (a deck comprised of all the cards that make up fantasy locations, items, and monsters). Finally, two cards are randomly chosen (let's say the Treetop Fortress and Desert Ruins) from the set of all remaining possible dungeon cards. These are kept hidden from the player, so that he'll be surprised when he plays the game.

That is essentially it. What has happened is that the process of selecting the those dungeons is not only made explicit to the player, he has the ability to affect it. Dungeons are no longer chosen by magic. And now the player understands that a World is essentially a collection of dungeons - the benefit of which is that he may now imagine the possibility of a World which is a collection of dungeons and towns or some other idea. No longer magic, it is now in reach and hopefully enough to inspire the player to dig deeper into the process and perhaps even design his own.

That is by no means the end of it. Hidden in the above example is a very explicit structure. Namely, that a WORLD is made up of four DUNGEONS. One can easily imagine a DUNGEON being made up of elements too. In other words, it is essentially one large tree, but one that is designed top down, but built bottom up. In other words, before we create what a world is, we're going to create those four dungeons. Build each leaf and work up to the root node.

Essentially, the whole process of designing an entire game (or any entire anything really) comes from building that tree and creating the set of cards which can go in it.

In future entries, I'm going to go into more detail about what a card actually is (hint, see [#034 - PGC Templates]), and about how they fit together. I'm going to show how cards can be built out of other cards, the difference between Engine cards and Genre cards, how data can be passed down from top to bottom, how cards and sets of cards can be selected, genre default selections, narratives, and plenty of other cool stuff.

At the end, it is my hope to show that the days of sitting at a computer and typing "design scifi rpg" aren't as far away as maybe it seems. Then, I'm going to build something that does.