Not the key

This opinion piece on the Zelda series elegantly summarises why I don't think a 'procedural Zelda' will ever be interesting.

Brogue 1.5 released

I seldom mention other roguelikes being released, but I think this one is a little special. We recently discussed Brogue on Roguelike Radio and the first line of the Brogue 1.5 change log caught my eye.

Dungeons now include interactive “quest rooms,” which include lock-
and-key puzzles, collapsing/flooding terrain, hidden items, elaborate
traps, challenges, boss monsters and more. 

I asked Pender the obvious question 'How random are these? Will you get the same lock and key puzzle in the same room every time?'. His response has got me genuinely excited:

Pretty random, and definitely not. The level geography is generated
randomly, and then the quest room function takes over, picks a quest
room type (of which there are currently 17, defined by the data in a
master blueprints table) and scans the level to find discrete areas
that meet certain requirements of that quest room -- e.g. a dead-end
area of certain size range that is dominated by a single chokepoint
cell. Then it adapts that area to serve as that kind of quest room.  

He goes on to describe a nifty flood trap (that you may want to avoid reading to not spoil yourself) which is completely dynamically generated and triggered when you get a key from the centre of the room. And the puzzles can have dependencies on each other:

So the key that you take from the room, assuming you escape, will be
used to unlock a door elsewhere on the level. These locked rooms can
be nested within each other, as can the rooms that guard the keys, and
it is always possible to unlock them all in a single game

For the full explanation, change log and download links, see the Google groups thread.

Another response

I thought I was going to use this in the last Proceduralism article, but didn't so I'd better highlight it here. Rune Skovbo Johansen has written an excellent response to my Proceduralism article on architecture: Forcing Structure in Procedural Spaces. I highly recommend it as well as following his blog if you're not already.

Proceduralism: Part Eight (Content)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three, four, five, six and seven of this series.]
What do I mean by content?

This is one of the foundational ideas of procedural content generation: that there is something we can generate procedurally which has an impact on game play. From the PCG wiki:

Procedural content generation (PCG) is the programmatic generation of game content using a random or pseudo-random process that results in an unpredictable range of possible game play spaces. This wiki uses the term procedural content generation as opposed to procedural generation: the wikipedia definition of procedural generation includes using dynamic as opposed to precomputed light maps, and procedurally generated textures, which while procedural in scope, do not affect game play in a meaningful way. The concept of randomness is also key: procedural content generation should ensure that from a few parameters, a large number of possible types of content can be generated.

When I wrote the original Death of the Level Designer article series I set up PCG in direct opposition to PG, but they can clearly be seen as a continuum: dynamic lights and other traditional procedural generation techniques don't affect your ability to play the game until they do (see e.g. the flashlight in Doom, HDR bloom blinding you, trying to snipe through procedurally textured grass and so on).

Here I'm going to be more specific about my use of the word content: I'm going to define it in opposition to what I referred to as architecture in part six. Architecture is when you generate something procedurally and then try to fit game play to it, content is when you generate something procedurally for only game plays sake, and then let the player try to fit meaning to it.

[Edit to add: I'm using the word content in two different ways. As the C in PCG, content includes architecture, but I think it is relatively uninteresting. Topology is more interesting, but if you're just designing a maze for mazes sake: because you're game is set in a labyrinth for instance, then it doesn't help much. A better example would be buildings. If your building interiors are designed primarily to look like real building interiors, it is architecture, but if they're primarily designed to have waist high cover and door ways you can hide behind, it is 'content' driven in the way I'm defining in this article.]

A concrete example should help you. Later versions of Zangband (an Angband variant) feature a procedurally generated wilderness. Briefly, the wilderness map is a 2d array where each cell has three values: law, population and height, where each value is generated using Perlin noise and then normalised to guarantee that extremes of each value exist somewhere in the wilderness. The actual terrain selected for each grid location in the map array is selected from a 3d Whittaker diagram (basically a way of choosing a terrain type where adjacent values are usually similar, but with boundaries between terrain), where each axis is the law, population and height value. Each grid location is subdivided into a 16x16 map array where individual terrain features are generated as defined by the terrain in the Whittaker diagram - sparse trees, grass and occasional pools of water in savannah terrain for instance.

Zangband terrain looks beautiful, and natural up close, but has no bearing to any real world situation because the values used to pick terrain have no relationship to reality. Law is the (inverse) difficulty level of monsters generated in the terrain, population is the frequency of said monsters, and height is a randomiser to ensure that there's sufficient variety in terrain of similar population and law values (remember, the Zangband map is a 2d array), with a value picked for sea level so that a certain percentage of the map is water. High population are converted to towns and cities, high population, high law areas are fields, and low law areas include more dangerous terrain types like pools of acid and lava to complement the increased difficulty of monsters in those regions.

The Zangband procedural generation is, with the exception of height, a content-based PCG system. There is a direct relationship between terrain and the difficulty of the region, which the player can discover, with some explicit linking to player preconceptions (pools of lava), and some less direct linkages (are snowy forests more difficult, or simply at higher altitudes?).

While I said the values used to generate this terrain have no bearing on reality, the player is going to make sufficient meaningful connections between terrain and reality when they play the game. This is possible because the fine grade scale of the game looks plausible: everywhere the player looks appears that it might correspond to something in reality, so the player doesn't notice that the macro scale is nonsensical: actually not nonsensical, but generated completely around game play requirements, instead of ensuring the game matches an approximation of the real world.

While Zangband's wilderness generation code is elegant it doesn't play terribly well in its current form. There's no hard barriers (except for city walls) so it is very easy to move from safe terrain to deadly terrain without recognising the significance of the change, and the destinations you are looking for (dungeons) are sparsely populated because of a design decision to have different dungeon types without enough variety in what can occur in each dungeon. Both those problems can be fixed: one of the first posts for this blog is about wilderness generation using Voronoi diagrams where I propose generating the wilderness more as an undirected graph from randomly generated points on a plane, where some edges are eliminated from the Delaunay triangulation by putting up barriers, and some points are filled with untraversable terrain (mountains, seas, lava) while ensuring that all traversable nodes remain connected.

And I've written about how to make dungeons interesting in the Unangband Dungeon Generation article series: by subdividing the dungeon into one or more 'ecologies' of different but related monster collections which are used as selection lists for what monsters should exist here, and then decorates the dungeon rooms with randomly selected items and terrain types biased towards those which are related the most powerful monster in the dungeon ecology. The assumption here is that the player wants information about the most important thing on the current dungeon level - the most powerful monster that they are going to face, and so ecologies and decorations are selected which relate to some feature of that monster - if it breathes fire, the ecology may have other fire breathers and there may be burn marks on walls and floor and trees, if it is evil, there may be evil monsters and blood spattered furnishings, if it summons wolves, there will be at least one type of wolf available to choose from.

The correlations if you see an orc are only weak: you might be seeing it because the boss was an orc, and the ecology was partially filled with 'orc' monsters, or because the boss was an evil priest and the ecology had 'evil' monsters, or because the boss was a black dragon and it was a black orc (matching on names, instead of creature flags). Each ecology could be built from several such matches so you have multiple hints (and to ensure more variety); similarly the dungeon features chosen were heavily biased (5:1) or (10:1) to pick a feature with a similar match process, but could always pick a random one instead.

This ends up with a biased randomness, where you are being fed enough clues and enough noise that while you think something is going on behind the scenes, you are never quite sure if each piece of information in isolation is relevant. Information is a commodity when it comes to procedural content, but also a litmus test: it's not procedural if it can be spoiled.

The breakthrough in designing this came when I realised that there should be multiple ecologies on a level - with boundaries between each ecology which were filled with weaker related monsters, and that the architecture of the level (huge hallways, narrow burrows, natural caves) could be independent of what was filling it. Prior to those two conclusions, levels had ended up boring, but with multiple overlapping themes the dungeon became a lot more interesting. (For instance, Terraria has three axis in which themes overlap: depth, type of rock, and the presence of water or lava.)

That's because biased randomness was necessary but insufficient: you also require juxtapositions - where something unexpected occurs the player is forced to come up with a way to rationalize it. People are good at telling stories: the positioning of an arrow trap, a skeleton and a snake in Spelunky may be read as the dramatic death of a former explorer, whereas each of these elements separately may lack this meaning.

The big weakness with this biased randomness + juxtaposition approach to creating interesting content (and the simulate everything approach of Dwarf Fortress) is that you need a lot of content to make it interesting because otherwise you never have enough possible combinations to create any significant meaning. Luckily the total cost of creating a new creature in Unangband is incredibly low, somewhat more so for the complicated raw format that Dwarf Fortress uses, but compared to a 3d model (or in some instances a 2d sprite), it pales into insignificance.

Where the advantage is in the marginal cost: the cost to add an extra creature is generally fixed for a procedurally generated environment because once the rules are in place you can generate an infinite number of new levels; whereas in a hand-designed environment you have to potentially change every single level by hand if you should change an assumption about how a creature moves or the player acts, and as the total playable space goes up, the cost of additional content in that space goes up even faster. Procedural generation is how Terraria has been able to add so much content since release.

It is possible to combine procedural and hand-designed content without requiring a huge overhead of content types, by creating vignettes (small scenes) of artist created content which can be inserted into a larger procedural space. Some procedural generation systems consist of nothing but templates of hand-built scenes combined in such a way they can fit together. To make them effective, the vignette should have some random content so that it remains unpredictable when it is encountered over multiple playthroughs, as well as some interior space where the theme of the larger procedural area around them can break through (rather than merely restricting the template to a single theme). Part of the genius of Spelunky is that it consists of pieces of small platforming 'beats' combined together in a way that is only perceptible after multiple play throughs (Darius Kazemi suggests about 500 or so). I would also suggest considering adding bread crumbs of content which can be procedurally placed in the path leading to the vignette to help further integrate the template and the wider level.

Unangband does one better in that it has a room generator that is deliberately designed to create interesting rooms by placing content about the room in a combination of patterns and random placement. Briefly, two overlapping rectangles are created, and then content is placed in either the north, south, east, west or intersection of the two rectangles while a description of the room is created using a Markov chain. The tableau that is created can mimic player actions: bodies and blood can be scattered around the room in a manner similar to the consequences of player combat - creating additional resonance and meaning. More games could benefit from the procedural placement of the detritus of fire fights and assassinations.

Another piece of the content puzzle is progression. I've referred to increasing difficulty level already, but it needs to be stated that increasing reward levels are equally important. You can be sure that any newly generated weapons or treasures are going to be interesting for the player by ensuring that they will be more powerful than what the player has already found (give or take some random variance). Similarly, more challenging monsters are inherently interesting, to a point. To avoid the treadmill of more powerful items + more powerful monsters feeling like Ground hog day you should also expand the range of permitted behaviours: firstly by introducing them singly (ranged attacks, alternative movement) and then in combination.

The final piece of the puzzle is making sure your content is porous and well connected. This allows the player to find the optimal difficulty level for the way they want to play, and to move to freshly generated spaces when the content they have already encountered is exhausted. Terraria does this by allowing a new world to be generated at any time, Angband by allowing new levels to be created on the fly and so on.

But increasingly, developers aren't just relying on the player to find and create interesting content in procedural games, they're inventing methods that rely on simulating player wants and needs. The AI director in Left4Dead and Dark Spore is the best known example, but there are a number of others, and the most promising avenue of new research into procedural generation techniques. And I'll be looking at those in part nine.

Proceduralism: Part Seven (Education)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three, four, five and six of this series.]

I was going to be talking about content, but I think there's an important point that is worth underlining now, especially seeing as the previous post ruffled a few feathers.

One of the key challenges about procedural content generation is that so much of it is 'intuitive'. Not intuitive in the sense that it is easy to understand, but intuitive in the sense that you have to use your intuition to figure out what works and what doesn't work.

You will sit for hours, watching your algorithms generate content over and over, tweaking the parameters until you are satisfied with the outcome. It is an incredibly powerful feeling, like being a god in some sense, in that you are literally creating (and destroying) worlds with the click of a button or invocation of the command line. Even the smallest change can butterfly into unintended consequences or beauty, and there are a surprising number of times where accidents turn into final implementation. My favourite is the erosion simulation from Tribal Trouble, where a thermal erosion algorithm failed to produce the desired results, until the sign was reversed on the equation being used - turning a sophisticated model into a nonsensical result which happened to look better.

I've coined what I call Doull's Law: 'Any time saved using procedural generation will be wasted watching the resulting screen saver', to try to capture at least the amount of time this takes, if not the power of this idea.

The consequence of this centrality of intuition, is that you have to be told the story of developing a PCG algorithm, instead of just seeing the final code, in order to understand what was done and why. Projects that describe the process of development like Project Frontier, Procedural World, rune | vision, Making Worlds, Procedural Planets, Dungeon League, Polygon Map Generation, Infinity: the Quest for Earth, L.o.V.E. and Spore and all the other creation stories are incredibly important: not just as beautiful repositories of code and images and ideas, but as foundational documents to their procedural worlds.

And I believe, fundamentally, why procedural generation has never become mainstream, is that it takes time, especially time spent coding, to develop this procedural literacy. If you look at, for instance, the Braving Procedural Generation thread on TIGsource, you see variations on the same, simple cellular automata cave generation over and over, because each person who falls in love with PCG has to go through the same learning process themselves to try to discover this intuition.

That is why I set up the PCG wiki [1]- to try to improve the overall literacy in this field. And the feedback to the survey I'm running at the moment has been incredibly positive, but almost everyone feels like they don't know enough to contribute back. My vision ultimately is to have an online PCG paintbox on the wiki, that'll let you explore cellular automata, and height maps, and fire propagation and so on, all in your browser so you can experience this feeling without coding - I just don't have time to create such a beast.

Back on track in part eight.

[1] That and I needed a bibliography of PCG.

[Edit to add: I know we'll have achieved that level of literacy when we start talking about a Cepero nave, or Young trees. At the moment all we have is Perlin noise, which is a bit high frequency for my liking :) ]

Proceduralism: Part Six (Architecture)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three, four and five of this series.]

Edge Magazine recently featured an article, Building Worlds with a Single Click, which highlighted and praised two exciting new projects by independent developers: Project Frontier by Shamus Young and Procedural World by Miguel Cepero, both of which feature beautiful procedurally generated worlds.

The thing is, we've got very good at building procedural worlds - so good that virtually every example uses the same small underlying set of well understood systems: noise, L-system based architecture, Whittaker diagrams and so on that even a single programmer working in their spare time can implement. Just to pick a few featured in the World Building page on the PCG wiki: Making Worlds, Procedural Planets, Dungeon League, Polygon Map Generation. And of course, there's Infinity: the Quest for Earth, L.o.V.E. and Spore; all of which feature incredibly detailed environments created by incredibly talented and smart programmers.

And all these amazing worlds? Almost everyone is focused on building these curate's eggs - which, if they eventually end up being released as a game, become a disappointing, empty and lifeless one.

[Edit: Miguel Cepero has responded to this post, and quite rightly points out that the above statement is not a nice thing to say, specifically when his and Shamus Young's project should not be judged on this basis as they have not been released. I would like to apologise for making this generalisation, which the article in Edge magazine points out is the big challenge that all these projects face.]

Does almost all procedural generation amount to, as John Carmack puts it, is "a really crappy form of data compression"?

My procedural spider senses tingle as soon as I see a procedural generation system that uses one of the following two approaches:

1. Mazes (and by extension BSP-trees)
2. Height maps

because I've yet to play a game where I've exclaimed 'Wow, what a great height map' (except Populous, but we'll get to that) and the pleasure of solving a maze isn't the same as the pain of having to play through one.

I've also seen a rise in recent suggestions and several implementations of Metroid-style procedural generation featuring gated lock-and-key puzzles to partition a map, on the assumption that being forced to traverse through a non-linear space looking for a key is some how interesting. This is putting the cart before the horse: Metroid (and Zelda) use this technique to force the player to explore an already interesting (and hand-designed) location, not because looking for a key is itself challenging. The lock-and-key puzzle is merely a dressed up fed ex quest where you're not told the location of the package you have to deliver (or worse, you stumble across the package without knowing its destination address).

When we talk about architecture in game play, we don't think of buildings and naves and antechambers: we refer to choke points, and cover, and objectives. The topology of the space is much more important than its aesthetic or fidelity. The most successful (and perhaps only successful) procedurally generated game spaces so far are all based on Rogue, with its simple room and corridor design.

With a room and corridor design we get four important features:

1. Corridors - which act as natural choke points at each end, and cover if you are in them
2. Convex shapes - spaces where you can see everything in the space from everywhere else
3. Concave shapes - spaces where some space is hidden from another (more cover)
4. Loops - which allow you a safe haven by traversing the loop to recover when chased by enemies of the same speed or slower

Elite, the other arguably successful procedurally generated game space, remains interesting because it is a procedural objective generator. Here you are searching for trade routes between high tech industrial and low tech agricultural worlds: the topology is interesting only because every edge is a potential goal.

Populous, Dwarf Fortress, Minecraft and Terraria all cheat procedural generation in two important ways: they allow you to modify the topology of the space and they encourage you to make interesting content in that space to which you become attached. An uninteresting dead end can be transformed into a useful corridor, or lit by a torch to mark that you've 'already been here' or mined for valuable ore. The procedural generation systems they use may make beautiful places, but it is the player's job to change them into interesting spaces.

It helps in the case of Minecraft and Terraria that much of the procedurally generated spaces mimic Rogue's room and corridor layout. Strategy games generally generate a mix of the Rogue-type (open areas, choke points defined by inaccessible terrain) and generation of objectives through resource scattering (call this Civilisation-type PCG).

Even with a room-and-corridor design, the architecture, or more correctly topology of a space is insufficient to lead to great procedurally generated games. As I discovered when working on Unangband dungeon generation, it is the contents of these generated spaces that is the most important part of procedural generation. And that is why it is so frustrating to see developer after developer get trapped in architecture, distracted by beautiful world building, and not concentrating from the start on the creating content.

And I'll be discussing content in part seven.

Policing procedural

I started the PCG wiki with the intention of cataloguing games that featured procedural generation, because, frankly, there weren't that many when I started, unless you counted things like procedural textures.

I've not put enough effort into the endeavour, because, frankly, you start a wiki so that other people can help you out, and there's not been enough contributors to keep me motivated (Although thanks to everyone who has contributed) and it became more interesting to describe all the different procedural algorithms out there, than compile a large list of games largely duplicating information already in Wikipedia.

The last few days of catching up on my RSS feeds reveals that pretty much every second game that gets mentioned now features procedural content generation. On one level, I think 'we've won' but I'm not entirely confident I'm sure what that means. Let me think about it for a little while and I'll get back to you with some further thoughts.

Blocked

An observation I just made over at Rock Paper Shotgun:

There’s a strong indie tradition of Super Mario Bros remixes. Notch wrote Infinite Mario Bros which is now used for AI and procedural generation research by a number of academics, and Andrew Spinks (developer of Terraria) also wrote Super Mario Bros X.

On the other hand, maybe it just creates a weird fascination with bashing in blocks…

Cool

Far from it for this blog to become merely a venue to rave about brilliant indie games featuring procedural content, but, yeah, Frozen Synapse...

Falling deeper in love: Terraria

The reason I say Terraria is a beautiful game isn't because of the glorious pixel art; although the combination of pixel art, procedural generation, and smart use of lighting and particle systems are beautiful, but because many of the design decisions are just precisely right. For a game developed over 5 months by 4 people, it shows an incredible level of maturity.

The user interface is elegantly understated. My chief problem with Spelunky is the large number of controls needed to move through the environments: Terraria uses WASD movement but up and down are not used to start with, along with a 2 button mouse, space to jump and ESC; but this limited control set sensibly handles a huge number of interactions and permutations of objects, terrain and furnishings. (For pedants, yes there are other controls but those are strictly optional, and all just faster ways of selecting which items to use).

The ESC menu is particularly instructive: it overlays the ability to organise your inventory, drop and equip objects, craft items and buy and sell from the shop, and interact with containers, as well as save and exit the game; which you can do simultaneously from the same screen without requiring you switch modes at all. So you can craft an item, sell it to the merchant, drop equipment from your inventory to make space for another purchase, and then wear a new combination of items without having to exit out of the single menu.

Similarly, left-clicking with mouse lets you build and destroy, select items to use, attack or shoot at enemies and decorate your house - while right-clicking is only rarely needed and never in a moment of duress, for opening and closing doors, interacting with NPCs and opening containers.

I'm listing this here, because one of the few things Terraria gets wrong is that it doesn't explain the most straight forward thing you need to learn: which is that the mouse cursor is how you primarily interact with the world, limited for the most part by the requirement that your avatar be in relatively close proximity. Of course, close proximity in a game of plunging chasms, flooded caverns and spawning monsters is itself a challenge, but there is no point which so far I've felt like the control scheme has been frustrating or unresponsive.

Like Minecraft, Terraria uses its procedurally generated backdrop as a palette for you to build and dig, but that's where many of the simalarities end. Minecraft remains (as far as I am aware) a toy sandbox (once the thrill and challenge of the first 30 minutes wears off), Terraria an open ended game. I've been meaning to write an article about the importance of that key verb 'dig': because it lets you throw off the shackles of required connectivity that makes much procedural content generation so frustrating (to design and to play in) and lets you generate glorious playgrounds which ultimately may be broken, but which the player has the tools to fix. Where Angband has gone wrong is digging is slow and unrewarding, Spelunky makes the mistake of limiting the level size, but here the maps are effectively limitless in size (in reality, just really huge - use the 3rd party mapping tool - just once - to display a map you've spent 3 or 4 hours exploring to see what I mean), and for the most part well-connected enough so that it is clear where you need to dig to hollow out a pathway or bring down a cascade of sand, but still big enough to make choosing a random direction and tunnelling an exercise in patience and frustration and occasional delight (as so it should be).

Terraria makes the same smart decision that Minecraft does (and where Love goes horribly wrong) by using its pixel art assets to make it really clear what everything is: here are blocks of dirt, sand and rock, this is tree, grass and flower, and not only are they clearly delineated, but the clever crafting system makes these differences important. I say everything is differentiated: but at the same time rock, and the various ores are similar enough so that you need one next to the other to distinguish the two, forcing you to be keenly observant when you explore underground. Many times, I've paused at a rocky outcrop on the surface that I've run over tens of times, and suddenly realised that it was a valuable iron deposit.

Exploring underground is as glorious as it could be: musically, rhythmically, the deep, but survivable drops from tunnel system to tunnel system, the splashes of unseen enemies in murky pools, the lighting system which limits your exploration by the torches you bring with you (or have wood and the foresight to be able to construct on the way), the frequent rewards of pots to smash (another Zelda touch to go with the swords swishing through glass and the slime enemy design), and the glorious highs of a single hidden reward which can make a whole trip worthwhile. What has ultimately limited my descents, as well as my overland trips, is water, which a clever take on swimming prevents you from moving quite as freely as you'd have hoped, not to mention limiting your breath. What makes this especially interesting is that it is often water that I've inadvertently let lose from an aquifer higher in the dungeon, which has sunk to the bottomost depths of the level preventing me progressing.

I've begun exploring the [redacted] you can find on the surface, destroying my first [redacted] with some clever [redacted] placement, and I've found enough [redacted] that the first boss monster has noticed my presence. The surface [redacted] is enough of a challenge in its own right, taking away much of your usual toolset as well as more dangerous enemies, environment and geography; and I'm pausing for air before attempting what, given my equipment (copper and iron, and a nifty magical ranged weapon), sounds like it will be a challenge. Beyond that, I've got more bosses to fight and biomes to explore, and many more magical items to find.

But I'm worried that I may have already spoiled too much of the game for you. I strongly urge you to stay as spoiler free as possible when you play. Three things that have stood out for me as quirks, worth highlighting, plus one recommendation:

1. Once you build a room that satisfies the Guide, keep building rooms this big or bigger (use the original as a template) and make sure that you furnish and light it. I've missed valuable NPCs because my rooms weren't quite built correctly, or because I hadn't built a room at all, but had met the requirements for a new visitor.

2. Doors in particular can be fiddly, they are 3 units high, and have to have a top and bottom 'frame' of walls above and below, and remember when placing furniture you want to click on the bottomost grid that the furniture occupies (1 up from the floor).

3. Acorns have been weirdly hard to plant, for some reason. I've had to dig a hole 1 deep and a 3 wide to plant an acorn, and bizarrely had only one tree successfully grow.

4. Exploring the surface at night, once you can survive the enemies, is rewarding, and sometimes even worth it if you can't.

Falling in love

Terraria is a beautiful game.

(And this is coming from someone who hates platformers).

Expedition: The New World

I should also apologise at this point for not promoting Slashie's Expedition: The New World the same way. But he's become the first project to successfully raise the targeted funds on a similar, game centric site 8 bit Funding, so he probably didn't need me promoting it :)

I'm guessing additional contributions are always welcome though...

In Profundis

John Harris, who for readers of this blog should need no introduction, is raising funds via Kickstarter for a project In Profundis. From his development blog:

IN PROFUNDIS is a 2D cave exploration game in a very random world. Not only is the cave highly unpredictable, but it also has dynamic, flowing water, falling boulders, dangerous gases with random properties, and many other dangers besides. It is somewhat realistic; your character's abilities are modest, more like what a real person could accomplish, but you can use equipment brought from base to help you get around: pitons, hammers, ropes, air guns, and more.

His previous game Mayflight, also uses procedural content generation in some very smart ways.

I'm a huge fan of Kickstarter, because it does something incredibly useful: allows me to give you money based on how much I value your work. I've given John $25, and I encourage you to make a contribution as well.

Procedural voyeurs

In lieu of anything interesting to say[1], I'll just point you in the direction of a couple of PCG blogs I have been enjoying: nullpointer, and Procedural World. Feel free to mention more in the comments.

[1] The closest I've come to being 'interesting' of late is realizing my fractured schedule was ideal for Facebook gaming, and signing up for Brenda Braithwaite's Ravenwood Fair. I got as close as opening the game once - but was luckily saved at the last minute by the fact it refused to sync correctly. Close call.

Proceduralism: Part Five (Perspectives)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three and four of this series.]

It is easy to conflate procedural content generation with sandbox play and emergence where these should be seen as three separate properties which often coincide in games which feature procedural content generation. If you consider an actual sandbox by way of analogy, a game without procedural content generation is like coming to a sandbox every day that has been raked over and smoothed out. With procedural content generation, you instead find the sand furloughed and heaped in piles in a way that may or may not be randomly distributed but is different every day. (Emergence in this example is having the castles you build fall over when they get too high).

In this procedural sandbox, you may choose to ignore what you find and start over, ascribe the distribution of sand to a preexisting external agency (the actions of the last kid to play in the box yesterday, an earthquake overnight) or invest in an imaginative world building exercise to justify what you find. The concept of repeated play is also important: the first time you come to the sandbox, it is not clear whether the sand is heaped just so because someone intended it that way, or from a process with no underlying intent.

It is the storytelling component of this example which highlights for me the importance of perspective in procedural content generation. When we tell stories, we do so most effectively when we put ourselves in the shoes of someone in that story, which is why games with a single avatar feel more procedural than games with multiple units. The concept of authorship could also explain the procedural uncanny effect I noted: we are building up the concept of a single author providing this story, and in the high fidelity example, anything that dispels your suspension of disbelief also damages your construction of the author behind the story.

The authorship conceit is not the only explanation for the uncanny valley effect: it may be low fidelity play engages us on a more childish level, but high fidelity play corresponds to our inner adult. It would be interesting to rerun this Neverwinter Nights scenario with a child playing the game rather than an adult and see if the reactions are similar.

But I don't think the attraction of procedural generation is solely about forcing us to make up stories. Stories also have a function which is to present a series of what-ifs. And you don't have to invest in an underlying narrative to react to what-ifs in game play. You have to engage your inner explorer.

In part six, I look at building worlds to explore.

Proceduralism: Part Four (What is Interesting?)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two and three of this series.]

There are four different strategies for discovering interesting procedural content. These are not exclusive - I can see solutions which blend several approaches being viable.

1. Simulation

We know the real world is interesting - or at least that we are adapted to finding the interesting bits of it. Therefore, by making our procedural generation processes have higher fidelity to real world processes, we guarantee that we'll make more interesting content. Game example: Dwarf Fortress

2. AI Directed

We create a process that determines whether content qualifies as interesting - ideally by simulating human intelligence in some way. We then generate or cull the content using this simulation to ensure it qualifies as interesting. Game example: AI Director in Left4Dead

3. Human Computing

We already have a process that determines whether content is interesting: the player. We therefore harness the player to allow them to choose which content is interesting. This encapsulates a range of strategies: from allowing the player to progress faster through uninteresting content and slowing their progress through interesting content (Game examples: Angband, Crawl), by allowing labeling of interesting content for other players (Game example: Noctis) or by using procedurally powered tools to let the player create user generated content (UGC) for other players (Game example: Spore).

4. Intuitive

We are not very good at distinguishing truly interesting content from random content which fulfills certain criteria (bright lights, loud noises, random rewards). As long as we create content which is sufficiently interesting, perhaps mixed with some complete randomness, we will not be able to distinguish it from content which is more interesting - there is a threshold above which differences in 'interesting-ness' is not perceptible. Therefore it is sufficient for a game designer to choose one or more procedural content generation techniques to use, and tune the parameters by 'staring at the screen saver' and finding values which define consistently interesting content. This is currently the most common form of PCG development.

All four approaches rely on the unproven assumption that there is a level of complexity beyond which people cannot distinguish a procedurally generated system from a human designed system. This is a frequent criticism of procedural content generation: that it is too easy to find something in a procedurally generated system which would clearly not exist if a human had created it. This differs from the intuitive threshold, above, in that it is possible to have interesting, but clearly not human designed content.

Note this is only a problem if computer created content is valued less than content with direct human authorship. I believe there are two approaches to procedural content generation which can help address this: low fidelity and high fidelity. These both come from the idea that people dislike computer generated content for much the same reason that they dislike facsimiles of people - the uncanny valley, but for all procedural content, not just people.

Low fidelity content is content which is clearly distinguishable as artificial: chip tunes, Minecraft maps and pixel and ASCII art. Low fidelity content doesn't trigger the procedural uncanny valley because it is so dissimilar to anything in nature and therefore non-threatening.

High fidelity content on the other hand needs to be indistinguishable from human authored content. High fidelity content doesn't necessarily have to be realistic: it just has to match the conventions of the genre and form - which for games are luckily much lower than other media.

Aside from the expense and complexity of developing it, one significant problem with high fidelity content is that if it is revealed as having artificial origins, the content consumer is likely to experience a significant shift in their perception in how the content functions. The recent criticism of Starcraft 2's narrative highlights the concerns of manipulation of the world to match narrative in a similar way. More importantly, the problems getting high fidelity procedurally generated music accepted in a field dominated by real people point to a longer term resistance to high fidelity solutions. In short, if it looks like a person wrote it, and it turns out a procedural algorithm did instead, a significant percentage of people will feel somehow betrayed.

There is one other significant pay off with the combination of testing for interesting procedural content: it doesn't just allow us to develop better content, it also allows you to determine with high precision what exactly 'interesting' is. This is the most exciting area of research for procedural content generation: once you have a procedural system set up, you can can vary the parameters and measure how this variation affects your test candidates, be they humans or AI programs. Julian Togelius has used the AI directed approach to try to evolve new games, by testing them against a fitness function which evaluated how interesting the rule sets are; equally by randomly varying the rules of a similar set of games and seeing how human players evaluate them, you can determine what the most interesting rules are.

And unlike real world psychology experiments, procedural content generation allows you to vary experimental parameters at very low cost. I can see the potential of procedural content generation is to rapidly refine a model of the mind by both allowing both extensive randomized trials of real people, and testing of multiple differing models against procedurally generated scenarios.

I take a brief second look perspectives in part five.

Proceduralism: Part Three (What is Procedural?)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one and two of this series.]

Alongside the attempt to define a taxonomy of procedural content, my other main goal for the PCG wiki was to list what games featured procedural content - expanding on the inadequate wikipedia entry to create a definitive go to guide if you were looking for a procedural fix. But this building this list has stumbled for two main reasons: a lack of time and contributors - which results in the majority of articles being stubs, with more polished entries where someone else has taken an interest, and a more fundamental problem with deciding whether a game is procedural or not.

But surely it should be clear whether a game is procedural? Take Elite - the canonical example of a procedural game, with an infinitely explorable universe generated from a starting seed. Elite is clearly procedural because of this infinite sandbox. Or is it?

It turns out the universe of Elite is in fact finite enough that it was possible for the founders to check the name of every planet to ensure that there were no curse words included in the final release. And if you are willing to accept a seeded universe but constant content as a starting definition for procedural, then is Eve Online procedural? What about Star Wars: Galaxies? Darwinia? Far Cry 2? Far Cry?

Well if Elite is not a good model to follow, then how about Rogue? Infinite, accessible dungeons - which implies accessibility to newly content is a prime requisite for procedurally generated games. But strategy games like Civilisation have had random maps almost as long as the strategy genre has been played on a computer, and listing every strategy game with a random map generator as a procedural game will be an enormous and potentially futile project.

So it's not simply a matter of random map generation, then how about other content like randomly varying the loot that you find. But that makes World of Warcraft as procedural as Borderlands and Left4Dead procedural because it dynamically mixes and matches zombie bodies to ensure variety in the horde.

But Left4Dead is procedural: because of the AI director, in the same way that Far Cry 2, but not the original Far Cry, is procedural because it has dynamic fire propagation. It's the emergence of interesting properties that makes a game procedural.

But this makes any game with a half-way adequate AI procedural, which is again not a useful definition from the point of view of building a wiki listing procedural games. And does a game like Deus Ex qualify as procedural because of the emergent property of using limpet mines to climb buildings? Maybe it is but Warren Spector didn't intend it that way.

We are left with two possible definitions which seem more robust but neither of which are ultimately satisfying: did the developer intend the game to be procedural, which leads to the problems of divining authorial intent, or is it procedural because I know procedural when I see it?

(I'll return to the matter of perspective later in this article series, but it is worthwhile noting that Minecraft feels more procedural than Populous because of the perspective the player sees the game from, in the same way that a first person shooter or platformer with random maps and AI feels more procedural than a top down strategy game with the same features. It is for this reason I've added a perspective category to games on the PCG wiki).

I want to avoid an argument about definitions for the moment, and try to look at some minimal examples of what we can mean by procedural. Take the following BASIC code:

10 PRINT HELLO WORLD
20 GOTO 10

Which if you run it, results as follows:

HELLO WORLD
HELLO WORLD
HELLO WORLD
...

The output of this code results in infinite content, and the code itself clearly defines a procedure for generating this content. But you and I both would have extreme difficulty in describing this as procedural content, because it is not very interesting.

What do I mean by interesting? That is the heart of whether a piece of content can be adequately described as procedural or not. If we just consider the output of an infinite number of HELLO WORLDS, we can see the content is not very interesting, because the underlying code required to generate this content is not particularly complex, and the result completely predictable.

But at the other extreme, apparently complete randomness isn't terribly complicated an algorithm either, such as this Python implementation of a multiple with carry random number generator shows. The output of this algorithm is too random for any human to detect the underlying pattern, while the pattern itself is compressible in a sense that true random numbers, such as thermal noise, are not.

The fact that a less than one page long algorithm can generate 'random' output as far as a person is concerned implies there is a not terribly complicated threshold past which someone is incapable of distinguishing an algorithm from random noise.

What fascinates me about procedural content is my belief that there another useful boundary between trivially predictable output and effectively random output - what I've called elsewhere biased randomness - that is randomness produced by an underlying discoverable rule set. That is not to say that randomness is uninteresting - given sufficient incentives, we can become horribly addicted to random output - but I think there is more value in exploring biased randomness than coming up with better ways to package completely random content in a compelling format.

You may be thinking here of the mathematical concept of 'chaos' - but while this may be a useful analogy, don't confuse the two. There are plenty of chaotic systems which can be easily comprehended by a person (the outcome just can't be predicted), and just as there are plenty of ordered systems which are similarly incomprehensible. Even the predictable behaviour of two body planetary motion was unknown until the recent past in terms of the overall human evolution of thought.

It is also likely the case that compelling biased randomness is even more complex than the algorithm required to implement effective randomly content - just in the same way that the real world is more complex a place than an aggregation of random elements. This will also be a challenge for biased randomness: justifying the additional time and expense above strictly random content.

So my answer to the question 'what is a procedural game?' is that the game presents a biased randomness where discovering the underlying rules is a necessary part of play. That doesn't help much when it comes to deciding what games should be in the wiki, but at least I have a set of criteria which feels more objective than those I outlined at the start of this article.

Whether the biased randomness in a game is interesting is a subjective exercise: one person's discoverable rule set is another person's fiat from the gods. But I don't believe this is an unsolvable problem: there are definite strategies to discovering whether something is interesting, and ways of dealing with the most common criticisms of procedural content generation. And the question of what people find interesting isn't just an issue for game design; with procedural content, it allows us to build a more precise model of the mind.

And I'll be talking about that in part four.

Because procedural developers are lazy

The meme of a procedural Zelda is a compelling concept when thinking about procedural generation. The classic Zelda design could be reduced to a the lock and key maze, of which EaS is an excellent example. A lock and key maze requires that every key is placed somewhere in the maze before the lock that opens it, which ensures that the maze is solvable. The puzzle is exploration based, rather than requiring particular problem solving skills, but I would qualify it as a puzzle nonetheless.

The question I have is what other puzzle designs are suited to procedural generation techniques? (With a particular focus on those that produce interesting level design).

Is it possible to procedurally generate Sokoban levels? Explorable match 3 puzzles?

Rather than answer the question myself, I'd like to throw the floor open to suggestions from the readers...

The Problem with Pretty Damn Quick

The agony and the ecstasy of Valve is they don't release until they're ready. When this goes badly, it could be a recipe for timid over-design that boils out the essential flavours, but when it goes well, such as the recent Engineer update, it makes genius games. In fact, Valve at the moment feel like they are on a whole different level of game design from other companies and Team Fortress 2 is the boiler room in which they sweat out their best work.

Take one design which has been simmering in beta for over a year - the Pretty Damn Quick. This is the engineering wrench which allows you to build buildings faster, at the cost of not being able to upgrade them. It is an 'obvious' design, in that it makes a net improvement to one parameter, while removing another. And there is no hint of the PDQ in the actual release.

Or is there?

Surprisingly, there is the reverse: the Gunslinger. The Gunslinger allows you to build and upgrade all buildings normally - except the sentry, where it allows you to quickly build a sentry which cannot be repaired or upgraded at all. The inversion in this design is that it is the building that cannot be upgraded, rather than the ability to upgrade which is removed. The reason why is obvious in retrospect: an engineer with a Gunslinger is still able to upgrade the buildings of engineers he works with, but an engineer with the PDQ is not able to assist his team mates - and the Team in Team Fortress 2 highlights why the Gunslinger design is the better choice.

(As for why it is only the sentry which is modified by the Gunslinger design: the tf2 blog post about the Repair Node is a lessons learned on why the teleporter and dispenser should not be messed with).

If you look at the other class updates in this light, the balance of unlockable weapons favour team play over individual prowess: the Jarate and Huntsman allow the sniper to move up alongside his team to assist, bleeding weapons highlight enemy Spies to other team mates instead of improving instant kill chances, the poorly received Scout update improving the ability to distract and harass instead of assassinate, the Scottish Resistance providing superior area denial abilities.

So what next?

If you've missed the analysis on the forums, the Polycount update will include community weapons with new abilities and the underlying message is don't worry about the game design - Valve have got that covered. Despite the forums being filled with back seat game designers, like myself, none of them are at a stage where we can conduct wide spread testing and analysis of games to the same depth that Valve is capable of. I find this a little surprising: play testing is something that should be easy to crowd source by distributing a server side mod, but the combination of community organisation and technical ability appears to be beyond most forum members. I suspect this is because game design is ultimately dictatorial - which is why the variant model used by Angband development (a gateway drug which is easy to edit leading open access to the clean source code combined with lots of bad game design) works so well. In order to organise external testing for Team Fortress 2 of the sort required to match Valve's game design abilities, you'd need to find the group organisation, game design and reverse engineering skills in the same individual or tight knit team, virtually fully formed.

But it turns out what is next is actually Alien Swarm, the free to play source mod released with source code, a tile based generation tool set which includes procedural level creation tools and access to the AI director. Alien Swarm is an entirely different kind of boiler room, and seen in the light of the misdirection of the PDQ beta I believe Valve are putting a number of free tools out there to see what the community can do with them.

We know that Valve are experimenting with procedural content generation, because Gabe has told us so, in an editorial written for Edge Magazine in December 2008. At the time, everyone assumed he was talking simply about the AI director in Left4Dead, but he must also had in mind Alien Swarm - the team of which Valve had hired the previous year - and was 'thinking aloud' about whether procedural content generation was possible for level design as well as pacing.

The procedural generation in Alien Swarm is about as simple and generic as you can make 3D generated levels - so simple at the moment it doesn't necessarily guarantee connectivity. It is template-based, much in the same way Torchlight builds it's levels, although at a lower level of detail, and the view angle deliberately prevents more complex 3D geometry such as bridges and subways which would complicate the level generation algorithms. It does do some clever design with tags for various room templates to allow the random levels to be closed correctly to avoid players being able to fall off the edge of the world - an issue which 2D level designs don't face.

What it does give you is source code, the Source engine tool set and a design vocabulary to build on - and I believe Valve wants to see what is possible with that combination. What won't be possible with Alien Swarm is more complex 3D geometry - and you should ignore the temptation to port your favourite 2D roguelike level generator to the Alien Swarm source code. But, as Mad Tinkerer points out, there is real scope for creating a procedural Zelda-like - go here, destroy these things, get this door key, then go here - something that no one has tried to build using a roguelike engine. The tag system appears ideal for procedural puzzle building, there is enough of an in-game vocabulary of gates and triggers, and the possibility of using Source engine physics should be enough scope to (procedurally) build something beautiful.

Procedural swarm

You've undoubtedly seen on the interwebs that Valve have released Alien Swarm, a Source engine based top down four person coop shooter for free.

What you won't have seen - and what is really exciting - is that you can enable both the Source AI director and tile-based procedural generation of levels from the console.

Now that is game changing.

I'll write more about this later.