Find the building here!

If you need to contact me, grab me on Twitter or email me mike@gamesbyangelina.org

Most procedural generators have it pretty easy. Generation techniques for content like dungeon layouts or 3D worlds can’t really fail – they proceed very steadily, laying down content as they go, and if the occasional tree ends up floating in mid-air it’s not going to break the game. This attitude won’t cut it for more critical game content like puzzles or narratives, however. One small mistake might shortcut half of the plot or render a game trivially easy. How can you tell if a puzzle is solvable in the right way, though? This week on The Saturday Paper we look at how procedural generators can intelligently design puzzles with just the features you want – no more, no less.

We’re reading Quantifying over Play: Constraining Undesirable Solutions in Puzzle Design by Adam Smith, Eric Butler and Zoran Popovic. The paper describes their work investigating AI and game design when building a puzzle designer for the game Refraction 2 (you can play the original for free here), an educational maths puzzle game, and the steps they took to make sure the procedural puzzle generator would not only generate puzzles with particular solutions, but puzzles which didn’t inadvertently have additional, unwanted solutions either. The result is a clever procedural design system that can precisely ensure certain goals are met in its output – something that is completely reusable, and could come in handy in all manner of game design projects.

We’re back in the realm of constraint solving here, which we saw recently when reading about populating dungeons with monsters and items a few weeks back. There’s a longer overview there as well as some links to good tutorials, but the upshot is this: constraint solving lets you describe the results you want from a program, rather than writing the instructions to get there like you would with normal ‘imperative’ programming. If you can find a good representation for your problem – which can be tricky at first – then constraint solvers can rapidly build a solution, making and undoing possible design choices as it tries to match the criteria you give it.

Refraction is a game about understanding fractions. Players place pieces in the path of laser beams to redirect, split, combine or change the beams in some way, in order to provide a particular amount of power to some target spaceships. By allowing the player to split up and combine laser streams the game can test fractional arithmetic and other concepts by designing puzzles that require certain kinds of solution – like merging two 1/16 lasers to power up a spaceship needing 1/8 of power. The authors have already written a paper on a system using constraint solving to design puzzles for this purpose, in fact. So what was their next step?

If you look at the picture above, you can see a nice puzzle solution on the left, demonstrating splitting and joining laser beams (with some rather elegantly symmetrical puzzle design to boot), and on the right you can see a nasty shortcut that completely bypasses the whole point of the puzzle. One way to avoid these shortcuts is to generate a puzzle, and then exhaustively test every possible solution to make sure there are no solutions that break the rules you had in mind for this level (such as teaching the player about splitting lasers, as above). This isn’t great for a number of reasons pointed out in the paper – for one thing, this might take ages, especially if the constraints can’t actually be satisfied. Equally importantly, such a system can’t use information about failed designs to stop trying the same idea out for a particular constraint problem.

What if we could express the idea of shortcuts as constraints, just like the rest of the puzzle design system? This would be a huge improvement, because answer set programming (or ASP, the special type of constraint solving used in the paper) improve dramatically over time by using failed solutions to avoid bad designs in future attempts. How do we encode something like that into an ASP, though? The solution uncovered in the paper is initially mind-bending, particularly if you’ve not used ASP before. I’m going to try and give a brief idea here, but I highly recommend reading the paper and contacting the authors to find out more details.

Some puzzles made by the improved solver. Notice how the one on the right doesn’t need rocks at all! It’s all in the elegant placement of the lasers and spaceships.

First, imagine that before we run our solver we give it two things: first, a definition of what we want every solution to include (call it the concept); second, a list of level design features that the solver can define to describe a level. A level design feature might be “Spaceship A needs 1/2 Power” or “There’s a rock at (2,2)”, while a concept might be “The player had to add 1/4 and 1/4 together”. Now suppose our solver comes up with a puzzle-and-solution pair, and through testing it knows it embodies that key concept we want the player to practice. The question is, how do we know if this puzzle has other solutions that pair with it – ones that shortcut our concept?

What we’re looking for (or rather, hoping we don’t find!) is any puzzle-and-solution pair which has exactly the same set of level design features, but that doesn’t have our concept satisfied. If you look at what that means, here’s our initial outcome:

{“Ship needs 1/2 power”, feature2…, featureX, “The player had to add 1/4 and 1/4 together to win”}

And here’s the dastardly shortcut, in which the concept we hoped was required is actually missing:

{“Ship needs 1/2 power”, feature2…, featureX}

In mathematics, the bottom list is a subset of the top list. What Adam and co. do, in just a few lines of ASP, is tell their solver to forbid subsets like this, meaning that if they find them then they know that something about that level design has to change. It’s a little more involved and a lot more clever than I’ve made out, but the principle is the same. And because of the way ASP works, these failures help make the search faster and faster, until a puzzle design is found.

The beauty of this subset checking is that the idea is completely general, and so is the code that Adam and co. have written. As long as you can write down what it means for a concept to be broken or shortcutted for a particular puzzle-and-solution pair, you can use the system developed for Refraction 2 in your own procedural content generator. The paper itself suggests this might be used not just for puzzles, but everything from interactive stories to crafting systems. In essence, it gives developers of procedural generators access to modeling the trickiest problems possible in ASP while staying anchored on the same design task: level design choices and a target concept you wish to see in all player solutions.

Another screen from Gunpoint

The system can produce some really elegant puzzles. As the authors point out, while human designs use things like impassable rocks to block off shortcut solutions (making it much simpler to check the puzzle over visually), the ASP solver is so rigorous it can often satisfy conceptual constraints just by cleverly placing the lasers and their spaceships on the level – and still have a huge diversity of output. I’m really excited to see where this goes next – given that Refraction is a game with education in mind, this could lead to tailored puzzles that teach specific mathematical ideas to people.

I’ve been playing Gunpoint a whole lot since it came out last Monday. In the developer commentary, designer Tom Francis says:

“…if I made the puzzles too open-ended, people found them too easy… then I tried a more restricted version where there was generally only one solution, but people complained it was restrictive … [I ended up with] a puzzle nested within an open-ended level. I found that balance worked much better.”

One of the things I really like about this research – and it’s not exclusive to constraint solving but it’s illustrated so well here – is that with a bit of intelligence in our procedural generators, we could feasibly design puzzles that are perfectly open-ended but where all solutions pass through the same point – exactly as Tom describes his process for Gunpoint worked. Or puzzles where all solutions seem equally feasible (for some definition of ‘feasible’, of course). Or we could design puzzles that explicitly require gadgets the player hasn’t been using very much.

The barrier for many will probably be getting into answer set programming in the first place. The authors here are keen on building better tools, systems and languages that might help developers use the power of ASP without learning a lot of complex new programming ideas though. I originally wrote here, “It’s a barrier worth getting over”, but instead I’ll leave you with a quote from Adam Smith on this very topic, in an email to me about today’s post:

I appreciate your effort in saying “it’s a barrier worth getting over”, but I think I shouldn’t be asking people to cross that particular barrier when I know of not-so-difficult ways to build tunnels through it.

As you can see from the work in their paper, there are some very enticing lights to be seen down the end of this tunnel. I’m looking forward to seeing more of it.

Where To Find More

Adam Smith is currently at the University of Washington in Seattle. He’s extremely friendly and always enthusiastic about getting people thinking in terms of design spaces, just like we did today. If you’re interested in the ideas and technology behind today’s paper, do get in touch with him! Eric Butler is a PhD student at the University of Washington, making games and doing some exciting-sounding research at the same time. Zoran Popovic is at the same university, too – you might recognise his name from the ludicrously impressive Foldit project (which Eric also had a hand in).

In the UK? Come and see Adam Smith talk about his research!

Adam is currently on a trip to the UK, during which time he’s speaking at a few venues. I was lucky enough to be able to invite him to talk at Goldsmiths University on Monday June 17th at 11am, in the New Academic Building (number 2 on this map). All are welcome! The title of Adam’s talk is Mechanizing Exploratory Game Design. Adam is a really inventive and interesting chap and it should be a fantastic talk. Let me know if you’re coming by pinging me on Twitter, where you can also let me know what you thought of this week’s column!

On that note: thanks for reading and for sharing these columns on forums, social media, Reddit and so on. It’s making me really happy to see them being linked to from far and wide, and to see it generating interest and inspiration!

Thanks especially to Darren Grey for once again giving great feedback on the piece, and Adam Smith for helping communicate his work best (he made some great additions to this piece). I’m off to Australia this week for the International Conference on Computational Creativity – when I get back I’m going to do a special roundup episode of The Saturday Paper covering some of the most interesting creative research and how it could be used inside games.

Puzzles in videogames, especially point-and-click adventures, are strange things^[1]. Mysteries and puzzles in movies are all about ingenuity, wits and thinking outside of the box. In games, though, they’re about working out what the designer thought was the right solution and finding whatever combination of items is hardcoded to unlock the next Plot Door. Not only does it suck to find your perfectly reasonable solution wasn’t the one the developers put in, but having one route to the goal kills any hope of replayability, too. This week on the Saturday Paper, we look at a system that aims to fix both problems at once, by generating puzzles based on real world ideas of cause and effect.

We’re reading Smart Terrain Causality Chains for Adventure-Game Puzzle Generation by Isaac Dart and Mark Nelson. The paper describes a new way of generating puzzles for point-and-click adventure games by simulating real-world systems like combustion and carefully planning which items to give the player. The best part is the idea has already been implemented by the authors in a Unity game that you can play for yourself, and the paper even includes some experiments and discussion for how procedural puzzles might be best used. Let’s dive in!

Let’s start with that title; what is smart terrain and what are causality chains? The former is a phrase that’s older than this paper by some margin. Popularised by Will Wright, the term is used to describe items with an awareness of their functionality, like most things in Wright’s series The Sims. Objects that make up a smart terrain – like everything in The Sims from the TV to the neighbours – know what actions they can perform, or what actions can be performed on them, like being switched off, used to prepare a meal, or greeted. In your average point-and-click adventure, items aren’t very smart at all. Instead they normally have a few specific use-cases in mind that are part of a tightly-designed route through a game. Even if you can use a crowbar to open one door, you might find it magically doesn’t work on the next one you find.

If you’ve played a lot of games like this, you might have wondered if it would be possible to just define the sorts of actions you can perform with a particular item, and let the player figure a solution out themselves. This is precisely what smart terrain causality chains add – they describe chains of actions that can be performed to turn a starting set of items into a solution to a puzzle. For the work in this paper, the kinds of cause and effect involved is often related to physical properties, such as turning ice into water by applying heat to it. As you’ll see, though, the technique is general enough to apply to just about any kind of cause and effect you can think of.

Here’s how the system works: you start off with a list of actions that can be performed on particular objects. Each action has a cause and an effect. Here are two examples from the paper:

You can probably work out what each one says. A sprinkler has an ‘activate’ action that is caused by smoke and has the effect of producing water. Paper has a ‘burn’ action that is caused by fire and produces smoke. You can also begin to see how chains can be built up, by linking the effects of one action to the cause of another. If the player needs water, they can find a way to burn a piece of paper near a sprinkler system. Because there’s no complex judgement needed here – just matching fields up in a database – we can easily use an AI planner to find chains of cause and effect, even in reverse.

This is exactly what Isaac and Mark’s system does. It starts with an objective, and works backwards to find chains of actions that lead to the objective being satisfied. In their demo game, the primary puzzle objective is to disable an electronic lock^[2]. The system looks at what things can cause the disable action on a lock – such as water – and then moves backwards looking for actions that cause water to appear. Once it finds a chain of items of a particular length, it places the objects in the game world and the puzzle is ready.

One particularly nice aspect of the paper was the evaluation performed on their demo game, Space Dust. The authors realised that one of the consequences of their new system was that it could produce puzzles with multiple solutions, but would that make things easier or more confusing for the player? They offered both types of puzzle to a collection of players and got their feedback. Most people found that having more solutions was easier, which I think makes sense to me. I like the idea of a game detecting that someone is having trouble solving a puzzle, and your sidekick suddenly “discovering” an item behind a rock somewhere that opens up a new solution chain to make things easier.

George, look what I found! Goat repellent!

You might have played Symon, an experimental game from MIT’s GAMBIT lab, which played with similar ideas. I like both projects because they’re developing new ways of approaching something that is about as genre-defining as it gets. A lot of the time, procedural content generation is a way of performing tasks that humans can already do, but this is more about using technology to rethink design decisions that have been accepted for years and years.

This more flexible approach to puzzle design has lots of potential applications, not least because it’s not just point-and-clickers that use item chain puzzles – in fact I’ve been playing Arkham City this week and realising how much games like this rely on items to defeat bosses or traverse game worlds. I also can’t help but think back to last week’s post on constraint solvers and see a connection here too. Constraint solvers could use information about the causality chains involved in solving a puzzle, and arrange the items in sensible orders and locations, as well as satisfying constraints like “food items must be found in kitchens or dining rooms”.

Above all else, you should be excited about this work because it’s a step towards allowing us to design games that would be difficult to do by hand. Having multiple solutions to a puzzle opens the possibility for the player to be carrying leftover items further into the game – which might inadvertently solve a puzzle in a way a human designer might not be expecting or just have not considered. The opposite is even worse – if a player burns an important bit of paper before they’ve used the secret message that was written on it, for instance. But using constraint solvers and planners, we can build tools that can give the player lots of choice and pathways through the game, while still making sure that nothing undesirable happens and certain crucial puzzles aren’t skipped. Often we see procedural generation as ‘putting people out or jobs’, tongue-in-cheek or not. On the contrary, this work shows how new technology can help us work smarter.

Where To Find More

You can read the original paper here as well as an expanded version here, thanks to Isaac.  Mark also wrote up a web-friendly condensed version here, which I really like the style of. I know I say this a lot, but this paper is readable! You can really skim through it and learn a lot more about the system than I could fit into this post. And of course you can download the Unity game that the paper was based on right here. The objective is to find your way to an entrance on the ship, but to do so you’ll need multiple tries – hence needing to escape from the brig over and over again, with a different puzzle each time. I think it’s a great demonstration for the tech.

Isaac went on to co-found Preliminal Games, a London startup working on an unannounced title that apparently uses his work on smart terrain causality chains! I’m very excited to see what comes of that. Mark Nelson is Assistant Professor at ITU Copenhagen, alongside Julian Togelius whose Mario work we saw a few weeks back.

Thanks to Mark and Isaac for helping me write this piece this week, and to Rob (@MGPNightShift) of the Mature Gamer Podcast community forums and Darren Grey for taking the time to proofread it too. Don’t forget to drop in on our Reddit thread in /r/gamedev, and catch me on Twitter to tell me what you think of the piece.

Other Stuff

AIIDE is a really great conference every October, and this year it’s in Boston. There’s a bunch of great workshops being organised that you can find here, but I want to mention a couple in particular that I know a little about. The first is AI & Game Aesthetics, a workshop I’m co-organising with Antonios Liapis and Cameron Browne. We’re looking for relatively short submissions (just 4 pages) about interesting work relating to intelligent systems and all manner of aesthetic and subjective issues in game development. Check out the topics here and please submit if you’ve made a game, a tool or performed an experiment that might be relevant!

Another workshop is the 2nd Workshop on Intelligence in the Design Process. This is being organised by Adam Smith and Gillian Smith, two great researchers from the US, as well as Mark Nelson – the co-author of today’s Saturday Paper! Be sure to check out their list of topics here, too, and consider submitting something.

1. ^[1] This is a link to Abstract Adventure, a very neat shortform game by a friend of mine. If you’ve ever played point-and-click games you’ll enjoy it, I think. ↩
2. ^[2] The real objective is to escape a prison cell, but most ways of doing this involve disabling the lock. ↩

Level design is a tricky business. As you creep around Dunwall or drive through Liberty City, you’re influenced by the architecture, the passageways, the placement of other characters and the location of treasure. Handcrafted levels benefit from the attention and refinement of many human designers, while procedural systems sacrifice human intuition in exchange for limitless content and unpredictable outcome. It’s only natural to ask – can we have both? This week The Saturday Paper is about building procedural level designers that can work to the kinds of intelligent, flexible constraints that designers use every day.

We’re reading Fast Procedural Level Population With Playability Constraints, by Ian Horswill and Leif Foged. The paper describes a way of placing objects like enemies, items and treasure inside a level procedurally, using some clever programming and maths tricks to make sure certain rules are always followed. It lets you add quite loose rules like “make sure the player has to fight at least three monsters before they find any treasure”, and still get randomised, unpredictable level outputs. It deals with a few concepts that might be new to you, but stick with it – it’s got some great ideas.

First, a little background on constraint solving. Most of the time in programming you’re asking the computer to do things for you quite specifically – for instance, you might set the player’s health to be currentHealth + 20 if they pick up a health potion. There’s no ambiguity there. Sometimes it’s easier to describe what your answer looks like instead of writing it explicitly though. So you might say that when a player opens a chest, they receive an item, and that item is worth less than 100 gold. That’s a constraint. You’re not saying exactly what the item is, but you’re specifying something you want to be true about it. Special constraint solvers can take rules like this and find you all the results that satisfy them (maybe you have a list of possible items and values in this case). I wrote a post on something related (but not quite the same) a while back.

Constraints are interesting for procedural generation, because they let the designer very elegantly state rules (“This map need a waterfall.” “This village needs a graveyard next to a mine.”) and suddenly all the other details are left to randomly vary. It’s even been used to great effect in automated game design – but that’s a paper for another day.

Ian and Leif’s paper shows a system they built for describing a dungeon in a way that, given a dungeon map, allows constraint solvers to place objects and enemies and finish the dungeon design for them. With a few simple definitions their solver can look through the dungeon, work out the possible paths from start to finish, and make conclusions about which layouts would fit the rules the designer set for it. It’s really customisable, too. To show you how it works, let’s take a very simple example. Here’s our starting dungeon:

To simplify things, let’s assume each room has one thing in it – either a monster, some treasure, or a health pack. How do we want the dungeon to be laid out? A simple example (straight out of the paper) might be “Make sure the player can survive the dungeon.” It’s the first level, after all. To check this, the system will check every path that makes progress of some kind through the dungeon (so no doubling-back or going in circles), and score it based on however we define ‘survive’ mathematically. First, you define a way of scoring each possible room. Since we’re looking at survivability, we could score the rooms based on how much health you gain or lose by being in the room. So if the room has a monster in it, the score is -15. If the room has a health potion in it, the score is +20.

Now we can say what it means for the player to survive the dungeon. It means that for any path from the start to the finish, if you add up the score of each room in the path going along, you should never have a negative score. So the dungeon layout below works because the health potion bumps the player’s health up again before they fight the next monster:

It might seem obvious with my terrible example, but this can get quite tricky quite quickly. Here’s a non-linear example from a talk Ian and Leif gave (click to make it bigger):

You can see each room has many possible exits, with different strengths of monster (meaning there are even more choices for the constraint solver to place in each room). What’s great about this approach is that the constraints are very customisable. In my simple example, I said the entire level must be survivable. But we can ask for levels where only half of the paths through the level are survivable. Or levels that aren’t survivable at all (with maybe an additional constraint that says the player has to go into another level to find an item that makes them strong enough to get through).

If you can find a way to represent your constraint, the system can solve for it, so it’s not restricted to a few measly health points. In the paper there’s a great example about locks and keys – you can write constraints that make sure the keys are behind rooms with boss monsters in, or write ‘safety conditions’ that make sure the keys are never behind their own locked doors.

The idea of using constraints on paths through a dungeon – or any world where the play areas are cleanly arranged, like Metroidvania games – is really nice indeed. Approaching procedural content generation by specifying some starting blocks and letting a machine do the rest gives a great compromise between developer control and machine generation. It has scope to expand far beyond level design, too. I could see the same ideas being used to procedurally generate narratives, where paths are checked to ensure that the critical plot events occur in sequence, leaving the rest to be autogenerated. Or point-and-click adventures where the important plot items are guaranteed to be picked up by certain points in the game, but the puzzles in-between those points are selected from a database at random.

Constraint solving is a great tool that hasn’t yet caught on in a big way in procedural generation circles, but there are a lot of great researchers out there, like Ian and Leif, working to make it happen. It’s not just about offering easy customisation for game developers, though. It’s about providing easier ways for non-programmers to customise procedural systems. If you can work out how to express a simple rule or two, you can completely change the way a constraint-based procedural generator works. That’s exciting, and it could mean a lot for people trying to get into game development for the first time.

Where To Find More

Ian and Leif are really friendly people and hugely enthusiastic about their research. Leif developed the tool alongside a tech demo where the tool designed layouts for a proto-roguelike. They’ve given a GDC talk about the work, and been interviewed on Roguelike Radio and AIGameDev. In short – they’re very approachable, and they really want people to use their ideas! Constraint solving isn’t something you come across very often in game development, but if people are willing to take the plunge I think they’ll be excited by what they find. If you want to know more, but aren’t sure where to start, I really suggest getting in touch with them.

There are some finer details that really make the paper technically interesting that I don’t have the space to go into now – how do you deal with looping paths, for instance, or dead ends where the player doubles back on themselves? If you want to know more about constraint solving generally, I really like Adam Smith’s Map Generation Speedrun. Leif himself wrote a tutorial on how to build a constraint propagator in a weekend. Constraint solving isn’t the easiest jump to make if you’re used to everyday programming stuff, but it can be great fun, and the simplicity of the programs at least means there’s not too much to read (Adam writes engagingly too).

Thanks to Ian and Leif for their support this week, and Darren Grey for proofreading this article too. As ever, let me know what you think – @mtrc on Twitter or email mike@gamesbyangelina.org. And please so share this around if there are game developers you know who might be interested! It’s great to get research further out there to people who might not normally come across it. Thanks for reading.

Addendum I – Procedurally Generated Narratives

I first heard about The Kingsport Cases over on Reddit’s /r/gamedev, and I’ve been following it ever since. It’s a horror game with a procedurally generated cast and plot, using a really nice approach that I desperately want to see get implemented and released. If you’re a fan of cool ideas being developed into real games, you should take a look at their Kickstarter they recently put up and seriously consider funding them!

Addendum II – Play Games, Help Science

If you follow me on Twitter you’ll already know about Alex Zook’s experiment in adaptive games. If not, check this post I made earlier in the week for two links to some 2D shooter games. Playing them for ten minutes will help Alex’s research into adaptive games, and make some great science even more awesome by providing lots of lovely data to crunch and make pretty graphs out of. As we all know, graphs are the best bit of science, so if you’ve got some spare time this weekend do go and give it a play.

Doing science with videogames is all well and good, but the only way to know if you’re doing it right is to get real people in front of what you’ve made, and get them playing. Alex Zook is one of Mark Riedl‘s students at Georgia Tech University, and does really cool research into games that adapt themselves to better suit the player. He’s running an experiment right now and needs some help – if you’re interested in being a guinea pig and want to play a game that’s full of exciting research, read on and see how you can contribute:

 Good evaluations with lots of participants can make good research into amazing research – and for game work especially, having people play with your output is key. Thanks to everyone who takes part – I’ll have a new Saturday Paper up for you this weekend.

Procedural content generation is a popular piece of technology, to say the least. From Minecraft’s rolling hills to Dwarf Fortress’ intricate world histories, we love games that can generate parts of themselves each time we play them. But other than tweaking the sea level in Civilization V, we don’t tend to think of content generators as things that can change much. What kind of Spelunky levels would Minecraft’s worldgen make? Do Dwarf Fortress’ histories share a literary style? This week The Saturday Paper is about generating the content generators – and the world of possibilities that opens up beyond.

We’re reading A Procedural Procedural Level Generator Generator, a paper by Manuel Kerssemakers, Jeppe Tuxen, Julian Togelius and Georgios Yannakakis. In it, they describe a system they built for interactively designing level generators for Infinite Super Mario Bros. – and it offers up some interesting insights and ideas about how we use content generation in the games we make today. Users of the tool can view level generators abstractly, look at them in detail, see sample levels, and combine generators they like to make new ones – similar to the way the evolutionary system we saw two weeks ago worked. The authors very kindly uploaded the tool for us (more on that later), which you can download here.

How do you ‘look’ at a level generator, though? The image above shows how – the tool generates lots of levels from a single generator, and then lays them on top of each other, averaging out all the colours representing each type of tile. It’s surprisingly effective – you can see generators that repeat particular patterns (such as rising and falling sections of blocks) as well as see which level generators are more chaotic, or that feature lots of detail at different parts of a level.

If you select one of these level generators, you can see a generated level in more detail – even playing one out yourself to see what kind of output it provides. You can also select two generators to combine together, to try and mix features that you like into a single generator. To understand why this works, and how these weird patterns you can see in the image above come out, let’s look at how these level generators are described.

The procedural procedural tool uses agents to generate their levels. Each agent is like a robot with a particular set of instructions attached to it. Before generation, the level is a blank white canvas, and the agents are set out at different times to lay tiles into the level – in this case, things like coins, platforms or breakable blocks. The agents have lots of parameters that describe their behaviour, such as how often they act on the level, an area they randomly spawn in, how they move across the level, and what tiles they drop^[1]. With just a dozen or so of these agents you can describe a wide variety of level generators.

When you choose two level generators you’d like to see combined, the tool chooses a random grab of agents from each generator, and combines them into a new one. The different rules will all interact in different ways (some of the agent rules also allow them to react to tile placement, offering up even more interesting combinations). You can then view these new generators in the composite view we looked at above, drill down and play levels from each one, or go on to combine them further if you see something you like.

Sample levels from a single generator – you can see similar patterns or themes in placement.

The tool has some mixed but undoubtedly interesting results. Some generators show great diversity, while others produce variations on the same level over and over (both of which I can see being useful for different types of game). What’s encouraging about the tool is that it’s fast and robust –  it can generate an average-sized playable level in an impressively nippy 1/20 of a second, and using Robin Baumgarten’s Infinite Mario AI it can test the initial set of level generators to ensure they tend to generate playable levels. This means that the tool is in excellent shape for further development to explore other genres, or look at different ways of representing level generators.

What’s most interesting to me is this little quote in the evaluation section:

…[some generators] generate levels that look completely different from each other in the game view, while retaining a common “theme” or “style”.

 ’Theme’ and ‘Style’ are not words you associate with procedural content generators very often, but I think it should be. Instead of thinking of Minecraft’s world generator as the only possible generator that could appear in such a game, we should think of it as just one possibility in a huge space of generators. There are generators that favour dramatic mountain ridges, ones that place villages in valley passes, and run rivers through deserts. This research helps us think of generators as things that we might also one day generate – perhaps automatically, even.

This is something I hope we can explore more in the research world, but it also has a place in game development too. Can my dungeon generator have a personality? Could Dwarf Fortress’ world generator develop a taste for romantic subterfuge one day, and shift to preferring political intrigue the next? This paper is an excellent example of how to build simple abstractions of content generators, and explore a whole new exciting space through this.

At the start, I also mentioned the idea of Minecraft’s world generator making levels for Spelunky. The authors of the paper talk at the end about their hope to build a generic level generator generator – one that could create level generators for roguelikes as well as for platformers, simply by a designer sitting down and selecting the right combinations  of generator until something they like comes out. The idea of generalising content generation across games and genres really appeals to me, too. Of course, this all requires people to spend the time generalising their games so that they share common inputs or interfaces, something that many developers can’t afford to do. Perhaps the research in this paper will lead to some Tiled-esque middleware that might take care of this for them, though. I certainly hope so.

Where To Find More

The paper is freely available on Julian Togelius’s site here. The authors are all very approachable too, and I’ve met a few of them in person too. Manuel is currently part of Abbey Games, who are developing the exciting-looking Reus, but plans to return to finish his Masters’ degree after release in May. Jeppe is currently hard at work at ITU Copenhagen on his project “A Framework for Real-time Collaborative Game Design in Digital Environments“, where he’s working on tools that let designers sketch games out while the player is playtesting them. Julian is heading up games research at ITU Copenhagen, and Georgios recently moved to the Institute of Digital Games at the University of Malta.

All are very enthusiastic about their work and I highly recommend getting in touch with them to learn more about the work and its current status. We’ll also have comment threads on Reddit’s /r/gamedev and Gamasutra’s blog section too – I’ll link them here once they’re online. The authors of the paper may be popping into those threads to answer questions and discuss the work, so be sure to join in if you want to chat!

Aside from reading the paper, you can also interact with the tool itself! The authors have very kindly packaged up the tool and uploaded it to coincide with The Saturday Paper – the first time it’s been made available to the public. I’m incredibly grateful for this, and I know many of you will be excited to take a look. Download it here. It has some GUI issues on some Macs, but Windows users should be just fine.

As ever, don’t forget to let me know what you thought of the column this week. Let me know by emailing me – mike@gamesbyangelina.org – or getting in touch @mtrc on Twitter. Thanks for reading!

1. ^[1] If you want to see a complete description of the agents, there’s a very clear breakdown in the paper itself. ↩

I was fortunate enough to be one of the guests on the latest season of Joe Martin and Harriet Jones’ podcast, Unlimited Hyperbole. The episode has just gone up, and is perfect coffee break listening-size. In it, I talk about how the games industry is missing out on a future it could still have, if only we could get academia to work a bit closer with industry. I might be sounding like a broken record lately – I said the same thing when I launched The Saturday Paper just a few weeks ago. But it’s something that plays on my mind a lot, because it’s so easily fixed, and because there’s so much exciting research going on out of people’s reach.

Research that people would be interested in, too. The first Saturday Paper, which went up a fortnight ago almost, has had 1500 readers on this site, as well as an unknown number over on Gamasutra (where it was crossposted). So far I’ve had 80 clickthroughs from the site, and conversion rates are generally quite low, so I’m hoping that means there were a few hundred readers over there, too. Potentially a couple of thousand people decided to read about an experimental research project – with over 130 people downloading the paper itself (again, not including Gamasutra). I’m hoping the next paper, due up this saturday, will get a similar reception.

In the Unlimited Hyperbole episode I come across as quite harsh on the industry, but as I’ve mentioned since I know that these things go both ways – hence my attempt to reach out with The Saturday Paper, and spread the word about things I think are interesting, exciting or relevant to the games industry right now. Everyone needs to work at getting closer and collaborating more.

Another thing crops up at the very end of the podcast, where I say this:

[Gamers] have lost their belief in what computers can do, and we’ve all become very cautious in what we dream about and what we wish we could have in our games. Everything is non-traditional unless we have this culture of experimentation and investigation.

I really believe that. When I see wishlists, or people asking developers to add things to their next game, it’s really just more of things – broader scopes or elements from other games. Yet this is the same demographic that is supposed to love science fiction and the promise of the future. In recording the podcast with Joe and Harriet (the same Harriet who did the amazing promotional art for A Puzzling Present) we talked more about this, I think – because getting people to dream, to ask for crazy things, is a great way to power research forwards. I like talking to people about AI, because wheedling weird ideas out of them is a great way to get new ideas to work on and think about. I’m still pondering the idea of an AI as a political representative, thanks to a school student in I’m A Scientist.

In games this is even more important. Games are wish fulfilment. Even simulators, or ‘realistic’ games are about experiencing things differently, or things we couldn’t experience ourselves. That means you get to ask for whatever you want. So don’t be afraid – because someone out there crazy enough to try is probably listening^[1].

Attendees of CIG 2011 – my first academic conference! The crowd includes (to mention a few) Mike Preuss and Noor Shaker, who both run successful AI competitions as well as being full-time researchers; Julian Togelius, whose huge breadth of experiments in PCG inspired ANGELINA; Dan Ashlock, an amazing mathematician with a love of roguelikes; Alex Zook, a member of the terrifyingly interesting Intelligent Narrative Computing group; and Giel van Lankweld, who showed that the way we play RPGs can reflect who we are as well as a personality test.

1. ^[1] Apologies to those I didn’t link to – I’m proud that there are too many names to fit in. ↩

If you’ve ever played a role-playing game, from Final Fantasy V to Skyrim, you’ll know that the genre loves its tropes. From orcs and goblins to swords and sorcery, the same themes come up time and time again. Sometimes this is exactly what you want, but often – particularly when it comes to the classes players choose to be, and the skills they have available – we want to have something new to challenge us. This week The Saturday Paper is about getting the game itself to come up with new abilities and class ideas for RPGs, with a little guidance from the player.

We’re reading Alex Pantaleev’s 2012 paper, In Search of Patterns: Disrupting RPG Classes through Procedural Content Generation. It describes a game he built for two players who fight each other in simple RPG-style battles. It’s a prototype game in order to prove the idea’s worth, so Alex’s RPG system doesn’t let the characters move (they can all reach each other, like a Final Fantasy fight) and has a really simple combat system that uses eight statistics – things like health points, armor, speed and so on. Each player controls a party of characters who take turns (according to their speed statistic) to fight until one party is defeated.

The experiment’s RPG system reminds me a bit of Final Fantasy-style combat. In a good way!

Instead of picking a ready-made player class with its own skill tree, players begin by choosing abilities for each character from a list generated by the game. Each ability is defined by a few pieces of information – a negative effect (the cost of the ability) and a positive effect (the benefit). For instance, a magic spell might lower an enemy’s health points while reducing an ally’s magic points. This makes abilities very easy to represent and generate through code – you just need two statistics to target (like health and magic points) and two numbers to add or subtract from them. Abilities also have information like a duration (the number of turns they affect things for) and a cooldown (the number of turns you have to wait before using it again).

Of course, if the abilities were just randomly generated forever this wouldn’t be much use. Instead, Alex’s system tries to improve the abilities over time by using computational evolution. Like biological evolution, computational evolution is about combining good examples of something in the hope of making even better examples (in the same way that fit animals survive to reproduce and make fitter children). Computational evolution works in much the same way – if you’re interested in reading more (and like baking analogies) I wrote a quick explanation of how computational evolution works in this post here.

A (very) simple example of how two abilities could be recombined. Alex’s are a little bit more interesting, and detailed better in his paper.

Recombining can be a tricky thing to define when you’re making an evolutionary system, but it’s easily experimented with over time. Maybe initially you create a child that takes the benefit from one ability and the cost from the other (like the illustrated example above). Or maybe you vary the values a bit. Maybe you swap the statistics over. Different methods will have different results – Alex uses a method where any number of elements (statistics or values) are chosen from one of two parent abilities, and included in their children.

Just like evolution in the real world, Alex’s RPG abilities need a way of being sorted so only the fittest can reproduce. What do ‘fit’ abilities look like? His solution is elegant and simple – let the player decide. At the end of each battle, the abilities that were used the most by players are the ones that get chosen to recombine into the next set of abilities for players to choose from. The player might choose some, all or none of this new set – whatever happens, the process continues into the next battle.

Results

So, what do you think? Could such a simple system – giving a player random abilities and slowly mixing together the ones they like best – produce cool new ideas for RPGs? My favourite thing about this system is that it absolutely did, and I want to go over some of the interesting ideas that came out of this (very preliminary) experiment.

Remember that each ability has a cooldown and a duration of effect? In one game, a player evolved a set of abilities that had durations slightly longer than their cooldowns. These abilities were often not individually very powerful, because Alex’s generation system tries to avoid generating abilities that have a high benefit and a low cost. Because they could be stacked multiple times, however, they could be used to create huge damage in very long battles.

Goblin Techies from DOTA

Another example had a player evolve highly damaging, long-duration abilities that also hugely damaged the person casting them. This meant that some party members could sacrifice themselves to inflict large amounts of damage on the enemy team. This is a really unusual ability – the only example that springs to mind is the weird Goblin Techies character in DOTA, whose ultimate abilities kills the player and deals huge damage around them.

Other interesting patterns emerged from unforeseen uses of game mechanics. If a player’s magic points dropped to zero, any active spells they had cast immediately vanished. This led to abilities that attacked magic points and magic point generation as a way of stopping suicidal or long-term strategies like the ones above. It’s interesting to see such variety coming from such a simple system – included alongside these more unusual examples were also the expected range of healing, damage and buff/debuff spells.

So What?

Where might this research apply to the games industry today? Even just considering its core idea – that there are more RPG classes out there than just Warrior, Mage and Thief – I think there’s plenty to be excited about here. Ideas like this could be used in the development of a game – to explore new ideas that you might not have thought of yourself – or even built in as procedural generators to games for players to explore themselves.

It also has promise outside the boundaries of RPGs. What about a roguelike whose item drops were designed based on which ones the player picked up and which ones they threw away? What about an RTS where the tech tree redesigned itself each week based on what skills players were picking most or picking least? Perhaps a game like Minecraft could help players specialise and co-operate better by changing its crafting recipes or inventing new ones as players find things they want to do more of? Player-guided creation of content, that goes beyond the ordinary things that games try to generate, is an exciting prospect.

Where To Find More

I’ve been in touch with Alex since deciding to write about his paper, and he’s very kindly put the PDF online for everyone to download and read. He was extremely friendly and excited about the idea of people finding out about his work:

I’m glad that the community is starting to look at the intersection between academia and industry, which has long been a pet peeve of mine. I’d be very happy to talk to indie game developers and other smart people with my goal, which is “make cool stuff that works and is useful”.

Alex can be contacted via his academic site – please drop him an email if you liked the work or want to know more about it, I’m sure he’d be delighted to talk to interested developers and gamers! There are lots of details to be found in the paper that Alex can expand on that I didn’t have time to go into here. Hopefully I’ve piqued your interest and you can find out more through the paper itself.

Don’t forget to let me know what you thought of the column this week. I’m working on the format and I want to know what people want more of, less of, or just plain love/hate. Let me know by emailing me – mike@gamesbyangelina.org – or getting in touch @mtrc on Twitter. Thanks for reading!

With many thanks to Craig, Joel, Mark, Mike and Azalea for feedback and suggestions.

I wrote code to do A* today, for the first time since I was in college. Long time!

— Jonathan Blow (@Jonathan_Blow) April 6, 2013

In other news, this puts me pretty close to the state of the art in video game AI research…

— Jonathan Blow (@Jonathan_Blow) April 6, 2013

This has driven me to finally start doing something I meant to begin a long time ago. I’d really like your help, too!

My first thought when reading Jonathan’s tweets were that he meant one of two things – AI in games generally, and AI for NPCs (which is what people often mean when they say ‘game AI’). For the former case, well, there are too many examples of great, vibrant, exciting research to mention. Even in the latter case, research into pathfinding and planning has made huge surges in recent years, with Monte Carlo Tree Search cracking every search domain known to man, and even Jonathan’s plain old A* having new life squeezed out of it – by researchers working on AAA games, no less.^[1]

However, it’s easy to point the finger. I am upset by Jonathan’s tweets – because I believe very passionately in building bridges between scientists and independent developers, moreso than ties with the mainstream industry. But instead of moaning, I’m going to try and do something about it. As I tweeted myself:

Perhaps Jonathan Blow’s comments reflect a failing on our side to communicate our work though. Maybe we can change that!

— Michael Cook (@mtrc) April 6, 2013

What can I do? Something I wanted to do ages ago! Every fortnight from now on, on a Saturday, I will post The Saturday Paper – a blog post where I highlight a cool paper from or related to videogame development, with a summary written by me that cuts through the density of the paper itself. I’ll try and provide pictures and video where possible, and links to the paper if I can gain permission (or if it’s not open access already – many conferences, including CIG and AIIDE already are!)

What do I need for help? For one thing I need criticism. It’s been a while since I wrote regularly, and I’m new at science communication. I’ll value any feedback or comments you can give me – feed them through to the usual address, mike@gamesbyangelina.org. The other thing you can do, of course, is spread the word – Twitter, Facebook, Reddit and more. Show gamedevs, get the knowledge spread, and maybe next time an indie mentions game research on Twitter it’ll be because she’s just adapted it to make her awesome game even better.

1. ^[1] I should probably say – I did say I was learning about science communication! – that A* is a very popular algorithm used to find the shortest route between two points. As you might imagine, it’s used a lot in videogames for getting NPCs places, among other things! ↩

Over on Gamasutra, Joe Martin and I discuss the criticisms, valid and open, of ANGELINA and computational creativity. We talk about the advantages of being human, where ANGELINA might manage to one day go, and where humans will (and should) have the upper hand.

Meanwhile at Eurogamer, Chris Donlan sits down with me to discuss why ANGELINA and computational creativity at large is the beginning of something separate, something beyond traditional creativity and maybe a chance to look at things in a new way.

I spoke to both Chris and Joe at Imperial over the last few months, and both conversations were absolutely brilliant. I can’t thank them enough. Both links will of course make it over to the Press page of the site too. EvoGames kicks off in earnest tomorrow, which I might tweet a little about. Normal work service resumes next week!