My Super First Day #2: Passenger

A more-or-less-collaborative writing project instigated by Andrea Philips: My Super First Day.  This year’s effort is not as elaborate as my first one, but I didn’t want this to pass by without contribuing something.  Go read.

Slightly more than two weeks ago I asked people to contribute ideas for an interactive fiction game.

Play “Improvised Story #0 – Release 0, First Draft” now!

What Went Right

• The “call to action” was on Twitter, but I have my accounts set up so that most things I post on Twitter also show up on my Facebook page.  All the ideas came from Facebook.  Nobody on Twitter seemed interested.
• Reusing old code from previous projects.  I’ve built up quite the repertoire of IF objects to play with.
• Evocative suggestions.  A couple of these were great for sparking the imagination.
• Creating a framework to fit everything together.  I’m starting to think that what I’m really best at is creating systems to help things (or people) work together.
• Hacking at Parchment, the tool I’m using to let people play the game over the web.  Now that I’ve gained some experience with it, I can do even more cool things.

What Went Wrong

• Overly ambitious ideas.  Seriously, a time machine?  Not in the “First Draft”, I’m afraid.  (I made sure, however, to include at least one idea from each contributor in the first draft.)
• Characters.  They’re the most complicated IF objects to create.  (I only created one; another will come in a later release.)
• A dearth of puzzles.  Puzzles are hard to think up; I had to brainstorm some based on the contributed objects and characters.  That was the part of the project where I just kind of sat there grimacing; testing and debugging is annoying, but at least I felt like I was doing something.

What’s Next

More ideas can be implemented.  Of course, the project will be even more interesting if more people contribute…

As you might know, I play Dwarf Fortress fairly often.  Tonight I feel like talking about something that happened in a recent game.

One of the things you can do in Dwarf Fortress is dig deeply into the ground and find hidden secrets.  Without spoiling too much (if you want to be spoiled, read about it yourself), these secrets contain both valuable treasures and powerful enemies.  It’s possible to spend a great deal of time preparing your fortress and its warriors for taking on these enemies; eventually you dig down and “crack open” the hidden stuff.  (This was version 40d of DF; those who care will know what that means.)

So, I thought my fortress was ready, but it really wasn’t.  I dug down and released a horde of demons.  As they swarmed up the specially prepared hallway, crossbow-dwarves filled them with bolts.  At the end, champion axe-wielders in full steel plate armor met them in hand-to-hand.

And yet the demons still broke through the lines and started slaughtering civilians.  It was a true mess.  Eventually, however, the last demon fell.

That wasn’t the end of it, though.  Dwarves were sickened by their fellows having been cut down.  Flaming corpses filled the halls with smoke and foul vapors.  Dwarves started going insane from the stress of seeing their family members rotting in the halls.  Some of them even went berserk and killed more dwarves.  I tried to get all the bodies moved into coffins.

Then I ran out of coffins.

I had started a catacombs area with nicely smoothed and engraved rooms holding one coffin each.  When those ran out, I set the masons to make more coffins while the miners hacked more tombs out of the rock.

Eventually the fortress stabilized.  All the bodies either rotted away or were stored in coffins.  The fires went out; food and drink production recovered.  No one else was depressed enough to go insane.

My catacombs have a couple of hallways of exquisite tombs; each room is not that large, but its walls are smoothed and engraved with pictures of dwarven life.

Then there are a couple of hallways with tombs roughly, quickly dug from the rock, a coffin resting in each one.

Then there’s a wide hallway with forty coffins stacked along the sides, each waiting to be moved into its ultimate resting place.

All told there are about eighty full coffins.  The fortress held slightly more than two hundred souls at its peak; it will be years before it recovers, if ever.

If I ever need reminding of the price my mistakes exacted, I just look at the hallway stacked with coffins.  It was not something the designer scripted into the game—it emerged from the choices I made during play.  To me, it’s a single image that encompasses all the tragedy and horror of what happened in this game.

Forty coffins stacked in one hallway.

That is art.

What is procedural generation?

Computer games have a lot of data associated with them; level designs, monster characteristics, items, all sorts of stuff usually referred to as content.  Where does this content come from?  Usually the game designers create it, they make it up and polish it to ensure that it meets requirements.

Still, if all your content is “hand-made”, that means someone has to make every bit of it.  For some games it’s more convenient to have the content automatically generated; generated by a procedure.  The process used to create the content is therefore called procedural generation.

Some people will refer to “random” generation, but there are usually strong constraints on the content produced.

The Diablo series of games uses a lot of procedural generation.  In Diablo 2, there are a certain number of levels set in the sewers under a desert town.  Those levels all use “desert sewer” graphics, but the layout is procedurally generation for each game.  The tunnel twists and turns are generated, then populated with monsters.  Enemies and treasure chests drop generated treasure hoards featuring magical items with randomly chosen properties.  And there are many more examples in the computer game world.

(I keep talking about games, but I’m sure procedural generation has applications in other fields.  I just can’t think of any off the top of my head.)

How To

I’m going to cover some basic techniques for procedurally generating content.  They won’t solve every problem, but they’ll form a good framework for learning more.

The problem

A while back I wrote a program to generate randomized “demon” descriptions.  Inspired by Dungeons & Dragons demons, it produces descriptions of creatures that appear to be assembled from various creatures:

Ramalfal is a female demoness, of a quadreped shape, of generally a gray color. She has a woman’s head mounted on the body of a scorpion.

For this post I’ll go through making a (simpler) version of this program.  I’ll provide some code in PHP.

Pseudorandom seeds

It’s nearly impossible to create true randomness in computer programs.  Fortunately, nowadays it’s easy to create randomness that’s “good enough”.  Most languages provide a facility for creating pseudorandom numbers.  Give the number generator a seed, and it will return a string of numbers.  More precisely, there’s usually a “seed” function and a “rand” function; after you seed the generator, you call the rand function repeatedly, and you receive a number each time.

Pseudorandom number generators have two useful properties (assuming they’re working correctly, of course):

1. Each seed generates a different string of numbers.
2. A specific seed will generate the same string of numbers each time it is used.

The point here is that a seed will generate a string of numbers—and thus it will generate the entire passel of content you’re creating.  In a sense, the content is “compressed” into one seed (which is itself just a number).  The end users can trade seeds that they find interesting.  You’ll notice that the original demon generator uses user-input seeds.

PHP provides the mt_rand() pseudorandom number generator.  You can seed it with the mt_srand() function, although the generator is automatically seeded when mt_rand() is called for the first time.  (One trick programmers use with pseudorandom number generators is to seed them with the current time…if you find yourself in need of a seed.)

Modular arithmetic

Modular arithmetic is a simple concept, but powerful and useful in certain areas of programming (like this one).  It all has to do with division.  Imagine you’re dividing two integers; the divisor goes into the dividend a certain number of times, and then often a bit is left over.  This amount, the remainder, is the whole point of modular arithmetic.

7 divided by 3 is 2 with a remainder of 1; thus, 7 mod 3 is 1.

321 mod 10 is 1.

It may be easiest to think of it as the face of a clock, disregarding AM or PM.  If the clock says 12:00, and then we wait for 16 hours, what does the clock say?  It says 4, because 16 mod 12 is 4.  Of course, on a clock we have 12, and in modular arithmetic we would use 0.  For modulus 12, we use the numbers 0 to 11, since those are the only possible remainders.

This is important because a lot of times the numbers returned by the random number generator are rather large.  Let’s say we want to generate the roll of a standard six-sided die, and mt_rand() returns 8714182.  What now?  Well, if we take that number modulus 6, we will get a number from 0 to 5.  Then we can add 1 to get a number from 1 to 6.  (Of course, mt_rand() will take parameters specifying the minimum and maximum number to return.)

Modular arithmetic can be used in a pinch to let you do without random number generators.  If we have an array of five entries, they’re numbered from 0 to 4.  If we calculate our seed mod 5, we’ll get an index into the array.  Most programming languages use % for modular arithmetic, like so:

$chosen = $array[$seed % 5];

In fact, in PHP we don’t even have to worry about the size of the array, we can just calculate it:

$chosen = $array[$seed % count($array)];

Relative Primality

Relative primality is another simple concept that can be quite useful in this area.  However, if you’re really scared off by math, this section is optional.

Two numbers are relatively prime if they have no divisors in common.

• 15 = 3 * 5.  12 = 3 * 2 * 2.  15 and 12 are not relatively prime, because they’re both divisible by 3.
• 15 = 3 * 5.  14 = 2 * 7.  15 and 14 are relatively prime.

Let’s say that instead of using a simple modulus you want to mix things up a bit.  One way to do this is to add a number to your seed, but that just adds a bit of an offset.  A better way is to multiply your seed by a number.  (Combining the methods works well too.)  The one thing to remember is that if you multiplay your seed by a number, the multiplier and the modulus must be relatively prime.

If they aren’t relatively prime, you’ll get repeats in your pattern.  Let’s say we want to ultimately take a modulus of 6; let’s look at every possible seed in turn; 0, 1, 2 and so on.  They’ll make a sequence that looks like this:

0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2…

Now let’s multiply our seeds by 4.  0, 1, 2 becomes 0, 4, 8, 12, 16, 20, 24…and we get this:

0, 4, 2, 0, 4, 2, 0…

Because 6 and 4 are not relatively prime, we get repeats in the pattern.  Some of our elements aren’t even being used!  Let’s try multiplying by 5 instead.  0, 5, 10, 15, 20, 25, 30 gives us:

0, 5, 4, 3, 2, 1, 0…

That pattern might not seem too odd, but notice that every number is represented.  That’s what’s really important.

Rerolling

At this point we can make a little program to illustrate our points.  Let’s think of demons in the form of the head of some creature placed on the body of some other creature.

$heads = array("a man", "a woman", "a bird", "a dragon", "an insect");
$bodies = array("a man", "a woman", "a bird", "a dragon", "an insect", "an octopus");
$head = $heads[mt_rand() % count($heads)];
$body = $bodies[mt_rand() % count($bodies)];
$desc = "the head of $head on the body of $body";

If we run this program a few times, we’ll get output like the following:

the head of the man on the body of a dragon

the head of a bird on the body of a woman

the head of an insect on the body of an insect

But wait—that last one seems a bit boring.  We’re trying to make really bizarre creatures here, so how do we fix that?  One way would be to make sure none of the entries in the heads array match the entries in the bodies array, but that solution has problems.

The best solution is to choose a head, then choose a body; then if the body is unacceptable, choose a different body.  (Or, just keep choosing bodies until we find one that works.)

$heads = array("a man", "a woman", "a bird", "a dragon", "an insect");
$bodies = array("a man", "a woman", "a bird", "a dragon", "an insect", "an octopus");
$head = $heads[mt_rand() % count($heads)];
do
{
$body = $bodies[mt_rand() % count($bodies)];
}
while ($body == $head);
$desc = "the head of $head on the body of $body";

(This is one of the few places where I routinely use do/while loops, as opposed to while or for loops.)

I call this technique “rerolling” because it’s like rolling dice to look up entries on a table.

Massaging

This is a slightly more advanced technique that can be useful in some situations.  The original demon generator produces names as well.  These names are assembled from randomly chosen syllables.  However, sometimes the combinations are a little awkward, like “Ioeththul”.

The way I dealt with this was to massage the data.  The program replaces awkward letter combinations with better ones.

• “io” at the beginning becomes “yo”
• “thth” becomes “th”

By these rules, our awkward name becomes the more palatable “Yothul”.

The great thing about this technique is that it can produce text that is more intricate than parts assembled together.  The drawback is figuring out appropriate text replacement rules; with the original demons program, I pored over output from it to find names that sounded too awkward.

Emergent Properties

In the same vein as massaging, randomly chosen elements could contribute to characteristics of the final product.  For example, different body parts could add to the demon’s “combat rating”.

$head_combat = array("a man" => 3, "a woman" => 3, "a bird" => 0, "a dragon" => 2, "an insect" => 1);
$body_combat = array("a man" => 1, "a woman" => 1, "a bird" => 2, "a dragon" => 4, "an insect" => 3, "an octopus" => 1);

(Human heads are smarter, thus they’re more lethal in combat. )

So, after choosing all our parts, we can calculate stats for our demon.

$combat = $head_combat[$head] + $body_combat[$body];

Culling

Culling is rerolling taken a step further.  If we get to the end of an assemblage of parts and we decide we don’t like it, we can throw it out and start again.  It’s possible to do this instead of rerolling, but it’s best to start over as soon as you know you want to—and only change what’s necessary.

So why would we have to start over completely?  It would have to do with something that cares about the entire demon, like the combat statistic we just created.  Perhaps there’s an option on our new demon program that lets users ask for only demons with a certain combat statistic.

The simplest way to implement this is to take everything we’ve done so far and make it a function.  The main loop (“generate 100 demons”) calls the function to get a demon; if the combat statistic is appropriate, it adds the generated demon to the list…if not, it gets another one.

This approach may seem inefficient, but it has the advantage of being clear, straightforward and easily maintained.  (Just be sure to check that you’re not trying to create invalid content, like a demon with a combat statistic of 10!)  It would be difficult to write a program to make intelligent choices based on a target statistic…hardly impossible, of course, just difficult.

In Conclusion

I believe that designing an interesting procedural generation can be a challenge, but implementing it is not that hard.  I hope this post has helped you agree with me!

Brooke Thompson recently wrote about defining the term “transmedia”. To summarize (go read the article, really), “transmedia” refers to a fictional continuity consisting of products released in multiple media, and—the different products influence each other; their story elements interact.

After reading that article, I found myself thinking about some of the challenges inherent in transmedia stories.  There’s one problem that suggests itself immediately.

What happens when someone reading one segment realizes that other segments also have elements important to the story?

Some people may feel betrayal.  They may have the impression that the thing they just bought is really just an advertisement for some other thing.  The best defense against this, as far as I can tell, is to make sure each product provides value on its own—for a story, that would mean that it feels like a complete story on its own.

Some people might feel confusion or frustration.  They may feel there are things in the story that they don’t understand, and these things are keeping them from enjoying the story.  However, I believe there are techniques to help prevent this reaction.

Transmedia Grounding

Many stories (I might even say “most”) make use of a viewpoint character.  This is a character that the reader (/viewer/player) understands and sympathizes with.  Whatever strange events happen in the story, the viewpoint character is surprised by them.  This lets the reader know that it’s okay to be confused or startled by odd things happening in the story.  It’s especially important for stories featuring elements of science fiction, fantasy or horror, because those elements are far removed from the reader’s daily life.  The reactions of an “everyday” character makes sure the story is grounded.

This device can be useful in transmedia stories.  If someone is reading one story, and elements of another story are introduced, those elements are foreign to the reader.  Therefore, the viewpoint character should react to them with surprise.  This will help the reader accept the new story elements as part of the fictional continuity.

A quick example should illustrate the point better.

Spirit Cards

Let’s say we have a television series called “Urban Mage”.  A twentysomething named Josiah and some of his friends discover that they each have a talent for sorcery, and they fall in with various urban mages and get drawn in to their conflicts.  The mages fight by manipulating electricity, starting fires, divining information and occasionally warping matter.  (I promise I made this all up for the purpose of this blog post, although I did recently reread Mage: the Ascension…)  So, in this case Josiah is our male lead and viewpoint character.  He knows next-to-nothing about magery, but he has to learn quickly.

Now let’s say there’s a web game where players learn about “Spirit Cards”, a form of magic that uses enchanted cards to call in favors from spirits.  Players of the game learn about another new mage named Acacia, and along with her they learn the rules by which Spirit Cards work (incidentally forming a nifty strategy game).  Acacia’s story is told through quests and updates on the website, and while the Spirit Cards are obviously built on the Urban Mage conception of magic, specific references to the television show are rare and far between.

Finally, let’s say that there’s an episode of Urban Mage where Acacia appears and consults with Josiah.  This is the first time that Spirit Cards are even mentioned on the show, but Josiah knows all about them and is able to use his mastery of Spirit Card rule nuances to do whatever it is that needs to be done in this episode…

That will probably upset some people.  People watching the television show without playing the game will be completely confused by the Spirit Card stuff.  People who started out playing the game will be upset that everyone in the main Urban Mage universe seems to know about the cards and rules they spent so much time mastering.

A much better way to handle the situation would be to have Josiah surprised by Acacia and her cards.  He has the opportunity to be taught about this new form of magic, and through sympathizing with him, the TV audience is able to understand it as well.  Also, the web game players are shown that their card game has an important role to play in the larger Urban Mage universe.  (It’s also a great opportunity for subtle in-jokes.)

Of course, it’s possible to go too far with this example.  If Acacia’s magic is played up too highly, she can seem like a Deus Ex Machina (or a Mary Sue!).  The ideal resolution would show that each character has something to offer the other.

Ultimately, I believe that when people read (/watch/play) media, and they really enjoy that media, they will pursue mastery of it.  If you respect your audience’s mastery of your content—if you show them that you’re proud they care about your stories so much—they’ll love you for it.

Innovation, in computer games at least, is always good. Well, that depends on what you mean by “good”.

Is an innovative game always a fun game? No.
Does an innovative game always make money? No.

So what’s the point? The point is that every innovative game advances knowledge in some way. Even if only one person plays the game and thinks “Hm, I never thought about that”, the game is a success. That innovation will go on to influence other game makers. It will never be forgotten.

Now, if a game designer wants to create a game that makes money, they will value things other than innovation—polish, ease of play, “fun factor”. And that’s perfectly logical. It’s just that I, myself, believe there’s always a place for games that focus on innovation.

I thought I might take a moment to explain where I got the name for this blog.

I was certainly inspired by another blog, Lost Garden; it’s also a number of essays and meditations on game design by someone named Danc.  I don’t agree with everything he says, but it’s always thought-provoking.

I don’t mean any disrespect to Danc in using such a similar name.  It’s just that it really is perfect for this blog.  My main site is Chaoseed; the name refers to chaos, seeds, creativity, possibility, development.  Therefore, a “garden” is exactly the right place to find seeds of possibility.

In Uplink, you play a computer criminal in the semi-near-future; someone who breaks into computer systems to make money.  I’ve had a lot of fun with this game, and while it might not be perfect, I feel no hesitation in recommending it to someone who likes the idea of portraying a computer cracker.

The flow of the game, at least in the early parts, is straightforward.  You visit the Uplink Corporation and take missions (contracts for jobs).  When you finish the mission, you get paid.  If you complete enough missions your rank improves, and this makes tougher missions available (and, often, easier missions unavailable).  Tougher missions require better hardware and software, which must be bought with the money earned from the missions.

But there’s an interesting side objective you can take on.  Certain missions require you to break into bank accounts to discover monetary balances.  Occasionally you will find a bank account with hundreds of thousands of credits—one or two orders of magnitude higher than the money you’ve accumulated so far!

Since the player has been encouraged to break into computer systems—even bank systems—from the beginning of the game, one obvious course of action is to break into a bank account and steal the money for themselves.  It’s difficult, but far from impossible.  After cleaning out one of the well-stocked accounts, the player can buy the most powerful hardware and software available.

This strategy could be thought of as an emergent property of the game’s realism.  However, I think it’s more likely the result of a conscious effort on the part of the game’s developers.  This game mechanic rewards investigating possibilities and orchestrating a breakin that you don’t fully know will work—in other words, acting like a computer cracker—and that’s what the game is all about.  Even without the “theme”, it’s still a delightful way to have a “sidequest” in the game.

Recently I’ve been playing Super Robot Taisen OG Saga: Endless Frontier on the DS.  (Yes, it’s one of the Super Robot Wars games I talked about in a previous post.)  It’s a pretty fun game.  There’s one feature—a very minor feature—that nonetheless sticks out in my mind as worthy of comment.

Endless Frontier features a number of characters in your party.  Each of these characters is carefully designed and characterized.  Each of them is represented in conversations by several portraits that show various emotions; “default”, “happy”, “grim” and so on.  Some characters have portraits that are quite individual to them; Kaguya has a “flirty” portrait, for example, and Xiaomu has a “just been spanked” portrait.  (Don’t ask, just take my word for it.)

When you visit a town in the game, you’re presented with a screen that has several menu options; “Inn”, “Save”, “Shop” and so forth.  The background of this screen is a street in the town, with several of the character portraits visible as well.  The impression is one of your characters chatting on a street corner while they decide where to go next in town.

The really interesting thing, though, is that the character portraits are chosen randomly.  (“Aleatory” means “having to do with chance or randomness”.)  When confronted with a tableau of random character portraits, the player can’t help but think—”What the heck are they talking about?”.  The character tableaux give the impression of being a snapshot of a conversation.  It really makes the player wonder what the characters are doing.  Why is Kaguya embarrassed and Suzuka exasperated?  The urge to think up a rationale for the situation is strong.  (“Apophenia” is the tendency for humans to discern patterns in meaningless data.)

The ultimate impression conveyed by this little feature is that your characters hang out together, converse, banter among themselves.  It really makes them feel like real people.

With PHP, you often want to process input from forms.  Sometimes GET forms are appropriate, sometimes POST.  But which of those you use is a decision for the input side; when you’re processing the form information, do you really care if it’s from GET or POST?  I’ve found that, while I sometimes want to have the same page accept either GET or POST, I never care which it is.  (If it matters, I include some other parameter to show which action the user is performing.)

Therefore, it would be nice if there were a way to treat the input as “just an array” without caring if it’s GET or POST.  Fortunately, there is a way, a simple one at that.

$getpost = array_merge((array) $_GET, (array) $_POST);

This will create an array, $getpost, that contains every key and value from both $_GET and $_POST.  It will work even if the arrays are null (assuming you’re running a recent version of PHP, that is, PHP 5).  Now you can use $getpost to access your submitted form elements without worrying which type of request it was.  Also, the array_merge will not affect the original $_GET or $_POST arrays, so you can still access them if you which.

There are just a couple of caveats:

1. If your keys are numeric, they may get renumbered.  I don’t know if it’s even possible to have form elements with numeric names (and even if it’s possible, it’s not a good idea).
2. If both $_GET and $_POST each have a key with the same name, the latter ($_POST in this case) will be used and the former will be forgotten.  (As KimikoMuffin points out in the comments, it is possible to have both GET and POST in the same request.)