Gamasutra: The Art & Business of Making Gamesspacer
The Saturday Paper - Dicey Puzzles
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 23, 2014
arrowPress Releases
April 23, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:

The Saturday Paper - Dicey Puzzles
by Michael Cook on 09/14/13 10:32:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.



When it comes to actually designing games, rather than just talking about doing it (as we often do in The Saturday Papers) simplicity is key. Although there are many weird and wonderful pieces of research out there to read, enjoy and think about, many of them are tricky to implement yourself in a game you might be making solo, or on a tight schedule. But we still look for ways to add a technical twist to our games, whether through procedural generation or some unusual new interaction method. This week on the Saturday Paper: how to generate simple puzzles by just throwing a few dice. Sort of.

We're reading Procedural Generation of Narrative Puzzles in Adventure Games: The Puzzle-Dice System by Clara Fernandez-Vara and Alec Thomson. It describes a puzzle generator that was iterated upon and used in two games: Symon and Stranded in Singapore. By breaking puzzles up into small components with simple connectors the system can easily construct new puzzles for the player, and templates are simple enough that anyone can add new ones - potentially opening up a cool new avenue for user-generated content.

Screen Shot 2013-09-12 at 14.00.19

Before we go on, take a look at either Symon or Stranded in Singapore to get a feel for the kind of puzzle output the system was capable of producing. Symon is earlier work than Stranded, and you'll be able to see this probably in the variation of puzzles on offer (although Symon is secretly my favourite of the two games). If you've played many adventure games you might have noticed that the same structure of puzzle tends to crop up a lot. The Puzzle Dice system, at work in both of these games in different forms, uses this template-based nature of puzzles to its advantage, by specifying templates for puzzles that can vary in their main details to recreate a puzzle multiple different ways. Here's an example of a template, from the earlier version of Puzzle Dice used in Symon:

NPC [state1] wants item1 [state2] to change NPC to [state3] -> player gets [item2]

The square brackets are attached to the word before them, and describe some property of that object. To give an example, here's a concrete version of the above template, as it (can) appear in Symon:

children [asleep] want music box [raspy] to make children [awake] -> get [family photo]

Here you can see the children have a property of being asleep or not, which the music box object is capable of changing, granting the player a new object. The objects, as well as the properties they have, are described in a big object database that a game designer can easily edit. We'll get on to how the system fills in these templates later: first I want to talk about how you go from a single small template to a fully-fledged puzzle adventure game.

Screen Shot 2013-09-12 at 14.21.06







In Stranded In Singapore these puzzles are expressed as lists of events that happen in chronological order. This lets us refer between puzzles to link them together. For example, instead of having a puzzle template simply be getting an object and swapping it for another one, we can link the reward object (the one the player gets for solving the puzzle) to a condition for a later puzzle. Here's an example from the paper that shows what I mean (this is a template that has already been filled in):

Librarian is in the quad → Librarian wants a banana [green] → player gets key to the Library → Professor is in the library → Professor wants a book [old] → player receives a good grade.

The important bit here is the key to the library. It's both the reward for the first puzzle (finding the banana) and the prerequisite for starting the second puzzle (finding an old book for the professor). When you look at this, it seems very simple and obvious - locking a player out of a location until they make progress is Adventure Games 101. But finding a way to describe it neatly so that a computer can reuse it is really important.

So our puzzle games are now sequences of action templates, with some simple parameters that let us vary objects, people, locations and so on. We've got a database with information stored in it that relate to these templates. How do we combine the two to generate fresh puzzles for our players to solve?

Screen Shot 2013-09-12 at 19.19.05

Puzzle Dice starts from the ending, and works backwards. You give it what you want the output of this particular section of puzzles to be, along with any properties it might have, and it searches the database to find matching objects and relationships. Relationships are the way that Puzzle Dice links objects together, through things like actions (combining two items) or interacting with characters (requesting or exchanging items). Once the system finds the required output, it will then work backwards to produce a chain of relationships.

Let's go back to the Professor example above: we start off wanting the output of a good grade. The system then works backwards - what kind of inputs might result in us getting an object in this way, with these properties? Puzzle Dice can look at the puzzle types that it knows of (request puzzles, for instance, which exchange one item for another) and the database of items it has, and fill in the blanks to produce a request puzzle where a Professor character can exchange a book for a good grade. This is then translated to a relationship, linking the Professor, the book and the reward of a good grade in the resulting game. Note that at this point we don't know that the Professor is in the library, or that the library is locked, or anything else - this will all be generated later, as we continue to step backwards along the timeline.

Screen Shot 2013-09-12 at 19.22.39

Clara and Alec developed tools that allowed designed to work directly with these types of data - editing the object database to add new objects with certain properties in, for instance, or describing new puzzle templates that have certain requirements and outputs. But I think the basic idea works well without these tools, and I can imagine implementing it in my own games for a quick and effective solution to puzzle generation. One of their objectives was to separate the act of describing puzzles from programming the game, which meant that game designers could work on puzzles without having to talk to the programmers, which is time consuming in some cases, and impossible in others. But it's a really elegant idea, no matter which way you look at it.

The other interesting side effect of avoiding programming is that the system is a good candidate for user-generated content as well. Objects and properties are relatively simple to define, and given enough basic building blocks to construct puzzle templates out of, you could definitely imagine a sort of Sleep Is Death-style adventure game generator that could help players design a puzzle game by taking descriptions of game worlds and the objects that populate them. If you supply enough basic building blocks in advance, and the right definitions for properties that objects can have, a user could easily tap in their own theme for a game, and filter puzzles themselves to find ones they like.

Where To Find More

Don't forget to check out Symon and Stranded in Singapore on the MIT Gambit site. Clara is currently an Associate Arts Professor at the NYU Game Center in New York City, while Alec is recently graduated from MIT Gambit, and is now a grad student there. Both are very active game developers themselves, as well as producing cool research, and I think of them as having really practical approaches to problems like this. Don't hesistate to approach them to find out more about the work!

Announcement - Meetup in Boston, October 14th!

I'm going to Boston for this year's AIIDE Conference, where I'm also co-organising a workshop. On the evening of the day of the workshop there's going to be an event called DAGGER where there'll be games to play from academia and the local gamedev scene, some snack food to have, and lots of people from both the conference and Boston gamedev to chat to and get to know. It's going to be great!

Click here to grab a free ticket from Eventbrite

Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Production Coordinator (temporary) - Treyarch
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States

Senior Software Engineer-Vicarious Visions
Chukong Technologies
Chukong Technologies — Menlo Park, California, United States

Developer Relations Engineer


Pallav Nawani
profile image
I don't think creating puzzles is a problem in the need of a solution. That's one of the fun parts of designing an adventure game. If they could come up with a program that could make the art for, let us say, 'a book' once the puzzle is fed into it, then that would be really impressive.

Luke Meeken
profile image
I don't think creating art is a problem in the need of a solution. That's one of the fun parts of designing an adventure game...

Jacek Wesolowski
profile image
Are you sure this is the kind of discussion you want to keep having on Gamasutra?

I'm always interested in automation tools, because, rather than replacing creativity (or fun), they make new kinds of creation possible. In this case, being able to create puzzles procedurally, at run time, means your manual input moves one step up the abstraction ladder: now you're specifying the rules for creating puzzles. To me, this sounds like a good starting point for creating redundant interaction systems, i.e. games where you can open the proverbial door by finding a key, OR breaking the door with a hammer, OR asking someone to let you in, etc. In a traditional, hand-crafted adventure game, the cost of making this possible is usually prohibitive. In fact, many unsolved problems of creativity in games boil down to redundant interactive systems being unfeasible.

Jakub Majewski
profile image
Well, that's very true, Jacek, but I would argue it has a lot to do with games being designed to be several times longer than they should really be, and then being filled with dozens and dozens of inane "filler" material.

When you're aiming for twenty-thirty hours of gameplay, you inevitably wind up having lots of one-solution puzzles (unless you're Warren Spector making Deus Ex, of course...) in adventure games, or an insane number of near-identical boring battles in FPS games, simply because in most cases, the game's plot is in violent opposition to the game's length. The plot usually has barely enough material for three-four hours, but has to be spread over twenty hours (note: the obvious exception to this are episodic games, which take their storytelling inspiration from TV series).

I agree that tools which give us help in procedurally generating alternate solutions to puzzles and so on are one way to help deal with this problem. Don't think for a moment I'm dismissing this solution. Nonetheless, I would argue that it's the wrong solution, because it doesn't address the real problem - which is simply that no matter how interesting your puzzles are, if you're cramming them into the game to artificially extend gameplay length to some arbitrary number of hours that your producer says absolutely *must* be there, or else the players will complain the game is too short - then you've got a problem, no matter how creative and non-linear those puzzles wind up.

I encountered something like this during Dogfight 1942 (not an adventure game, obviously :) ). Having played Heroes Over Europe just prior to starting work on Dogfight, I knew exactly what I wanted to avoid - that is to say, I did not want thirty-minute long missions that keep throwing more stuff at you, to the point where the core gameplay (dogfighting) simply becomes boring and frustrating. In Heroes, on most missions, by the time I finally manage to complete the last section, all you want to do is quit the game. Would it have helped had the game allowed a less linear approach, where I can choose to do my objectives in a different order, achieve them in different ways, and so on? Yes, it would have. Would it have made the game fundamentally better? I would say: no.

So, my solution was to keep missions in Dogfight short and focussed: no 30-minute long marathons, 5-10 minutes is enough. Wherever I succeeded in pushing this through, missions were generally exciting (in spite of all the numerous flaws the game had). But a lot of the time, no amount of persuasion on my part was enough to achieve this - level designers kept trying to make their particular missions the star of the game by extending it and cramming it with additional events, and when I tried to persuade (occasionally: ordered) them to remove the fluff, they would go to the producers and complain that "the game is already short enough, and he wants to remove more...". Invariably, the producers agreed with the level designers, because they had in their head an arbitrary number of hours that a game supposedly absolutely must have. The notion of the game having the right *flow*, the right timing, and simply *feeling* right to the players was irrelevant - no, the game has to have x hours, or the reviewers will kill us.

And by the way, I'm not really complaining about the producers, who were in fact doing what they thought was best for the game. The fact is, they were right, the reviewers would kill us if the game got too short - as they actually did in the end (...though not because of my short missions, but because literally 50% of the game had to be cut from the release when we switched from boxed distribution to digital, and faced the Live Arcade's 2GB limit).

That's the *really* crazy part, then. When do book or film reviews complain about length? Well, they do complain, either when the product feels too short, or when it feels too long. And this is reasonable. In the games industry, our reviewers look at length only from the perspective of "value for money". Is this game long enough that I feel I got my money's worth? This approach has been forcing us to create overlengthy, ultimately dull games for decades, and looks set to continue. In this context, having tools to enable us to more easily create redundant interaction is no solution to the problem at all, it'll just make our failures a little more interesting.

Paul Laroquod
profile image
Puzzles in most Adventure games are so simplistic that yes, I could see how their creation could be easily automated. But that doesn't mean that puzzles in Adventure games SHOULD be so simplistic that their creation can be easily automated. Without intending this as commentary on the specific games mentioned, which I haven't played, it strikes me as a method of enshrining mediocrity in algorithmic form.