Hubbub has gone into hibernation.

Procedural Instruments Enable Powerful Ways of Making and Seeing Playable Systems

“No Man’s Sky is so big, the devel­op­ers built space probes to explore it for them.” That’s from a Poly­gon report on what is prob­a­bly the most hyped videogame of the moment. The main thing that seems to fas­ci­nate peo­ple about No Man’s Sky is its exten­sive use of pro­ce­dur­al con­tent gen­er­a­tion (PCG). Put sim­ply, PCG involves using soft­ware to gen­er­ate game con­tent in stead of cre­at­ing it by hand.

No Man's Sky

The game con­tent cre­at­ed in this way can be any­thing. Visu­als are the most com­mon thing, but it can also include stuff that play­ers inter­act with, such as the arti­fi­cial intel­li­gence of a com­put­er con­trolled oppo­nent or the place­ment of items in a level.

A few weeks ago I attend­ed a sym­po­sium organ­ised by the Ams­ter­dam Uni­ver­si­ty of Applied Sci­ences (HvA) on “auto­mat­ed game design”. Over the course of the day var­i­ous researchers and prac­ti­tion­ers pre­sent­ed their efforts relat­ed to this topic.

Anders Bouw­er of the HvA opened the sym­po­sium by talk­ing about how the aim of game design automa­tion is to speed things up. This can be achieved by accel­er­at­ing the tran­si­tion from design to soft­ware devel­op­ment, and by accel­er­at­ing the flow of feed­back from playtests back to design. The main way to do this is to cre­ate tools that sit between design and soft­ware development.

Two approach­es to game design automa­tion became appar­ent to me over the course of the day. The first and most obvi­ous approach is to use soft­ware to auto­mate work that a design­er would oth­er­wise have to do man­u­al­ly. This is part of the com­mon sto­ry told about No Man’s Sky. The game’s devel­op­er is a small inde­pen­dent com­pa­ny which does not have the resources to cre­ate the game’s huge galaxy by hand. So in stead, they have craft­ed soft­ware tools which gen­er­ate plan­ets, veg­e­ta­tion, ani­mals and so on.

The sec­ond approach is to pro­vide a design­er with what are essen­tial­ly tools for inspi­ra­tion. In stead of automat­ing things a human could also do by hand, a design­er is enabled to do things she could sim­ply not do with­out those tools. So it is not about speed and vol­ume, but about qual­i­ty. It is focused on process in stead of prod­uct. Such tools can poten­tial­ly sur­prise the design­er. Con­verse­ly, the stuff pro­duced by No Man’s Sky’s tools must adhere to rules which have been pre­de­ter­mined by designers.

In one of the sym­po­sium’s first talks Joris Dor­mans argued for the lat­ter approach.1 He argued for the use of pro­ce­dur­al con­tent gen­er­a­tion tools in the ser­vice of improv­ing the game design process. He wants them to be tools to think with.

Think­ing with a tool implies a kind of part­ner­ship. In stead of being the slave or mas­ter of a tech­nol­o­gy, we become col­lab­o­ra­tors. In pro­ce­dur­al con­tent gen­er­a­tion research, this approach is explored through mixed-ini­tia­tive tools. “Mixed-ini­tia­tive” refers to the fact that such tools allow for a con­tin­u­ous dia­logue between design­er and soft­ware. One exam­ple is Tana­gra, a lev­el design tool for 2D plat­form­ers. It gen­er­ates lev­els in real time while the design­er manip­u­lates geom­e­try or a more abstract rep­re­sen­ta­tion of the lev­el’s pacing.


Mixed-ini­tia­tive tools such as Tana­gra are excit­ing because they aug­ment a design­er’s capa­bil­i­ties beyond speed and vol­ume. Because of their flu­id nature they become some­thing like a musi­cal instru­ment. A design­er can per­form with these tools. They allow for some­thing sim­i­lar to sketch­ing. There is a real poten­tial for sur­prise here, and for dis­cov­ery. When mak­ing such tools the ques­tion is not what out­come it should reli­ably pro­duce, but what process it should reli­ably support.

In his talk, Joris described his ide­al tool as a thing which gives him a lot of vari­a­tions. He should then be able to tell it what he wants to see more of. In this way, a design­er can more eas­i­ly scan through a game’s pos­si­bil­i­ty space. But this way of work­ing does not enable her to see the full range of things a tool might gen­er­ate. The design­er in this case is a bit like the Hel­lo Games probe, scan­ning the pos­si­bil­i­ty space of No Man’s Sky, one ani­mat­ed gif at a time.

What if we could zoom out, though? At this year’s Game Devel­op­er Con­fer­ence, Tana­gra cre­ator Gillian Smith, accom­pa­nied by Julian Togelius, talked about “the pow­er and per­il of PCG”. Towards the end of this talk, they show work on under­stand­ing the range of out­comes afford­ed by pro­ce­dur­al con­tent gen­er­a­tion tools.

The approach is sim­ple: first, cri­te­ria are deter­mined by which out­comes are scored. In the case of Tana­gra, a num­ber of lev­els are gen­er­at­ed and scored on how hard they are, and on how lin­ear they are. Then, each lev­el is plot­ted on a heat map. The result allows us to see the shape of Tana­gra’s pos­si­bil­i­ty space. In this way the bias­es in a par­tic­u­lar con­fig­u­ra­tion is more eas­i­ly uncovered.

2D histograms visualizing generative space

Enabled with such visu­al­i­sa­tions of pos­si­bil­i­ty space, pro­ce­dur­al con­tent gen­er­a­tion tools become instru­ments in a sec­ond sense, name­ly that of sci­en­tif­ic instru­ments. They can be used like micro­scopes or macro­scopes. We can use them to “see inside of” games and the tools used to make games. They afford pow­er­ful new ways of seeing.

It is this promise of new ways of see­ing that I find most excit­ing about pro­ce­dur­al con­tent gen­er­a­tion tools of the mixed-ini­tia­tive type, or “pro­ce­dur­al instru­ments” as I pro­pose we call them from now on.

Games are just one kind of algo­rith­mic cul­ture, and more and more kinds of algo­rithms are used to gen­er­ate media. How­ev­er, in media crit­i­cism the term “algo­rithm” is often used rather naive­ly. What the study of pro­ce­dur­al con­tent gen­er­a­tion tools can teach us is that there is no such thing as a sin­gu­lar algo­rithm that gen­er­ates a piece of media. They are assem­blages of dif­fer­ent approach­es to com­pu­ta­tion, com­bined with dif­fer­ent design practices.

Attend­ing this sym­po­sium on auto­mat­ed game design has made me excit­ed about pro­ce­dur­al con­tent gen­er­a­tion tools aimed at aug­ment­ing the capa­bil­i­ties of design­ers. The big chal­lenge ahead is get­ting such tools out of the research labs and into the hands of prac­ti­tion­ers. This is a non-triv­ial task. Many of these tools are quite com­pli­cat­ed and expen­sive to get right.

A dis­sem­i­na­tion of such tools will only hap­pen if we recog­nise the pow­er they afford us. If we want to become bet­ter at mak­ing games and playable sys­tems more broad­ly, we need tools with which we can per­form bet­ter, and with which we can see bet­ter. We need pro­ce­dur­al instruments.

Addendum: Cases Presented During the Symposium

  • Loren Roosendaal (IC3D Media) talked about how they made earth­quake dis­as­ter relief train­ing soft­ware for the Indone­sian gov­ern­ment. They were on a tight bud­get, so they cre­at­ed a tool which col­laps­es build­ings. These col­lapsed build­ings were then used as a start­ing point for lev­el design. He also talked about nego­ti­a­tion train­ing soft­ware devel­oped for the Dutch Min­istry of Defence called Cul­tura. It mea­sures play­er per­for­mance. IC3D Media and the MoD use these mea­sure­ments as input for bet­ter lev­el design. They might in future do some­thing like A/B test­ing of dia­log options.
  • Thomas Bui­jten­weg (NHTV) demon­strat­ed a gen­er­a­tor he devel­oped for col­lectible card game (CCG) cards. The gen­er­a­tor pro­vides a design­er with a bunch of card options which they can then select from. It bal­ances all options using a for­mu­la for the card cost.
  • Daniel Kar­avo­los (HvA) pro­vid­ed sev­er­al exam­ples of how he used a tool called Ludo­scope to gen­er­ate videogame lev­els. It is based on graphs, grids and trans­for­ma­tion rules. The approach focus­es on mod­el­ing the process of cre­at­ing game con­tent. (PDF)
  • Rafael Bidar­ra (TU Delft) showed two projects. The first demon­strat­ed gen­er­a­tion of a mead­ow in real time based on a veg­e­ta­tion mod­el. The sec­ond showed how we they used gram­mar-based pop­u­la­tion gen­er­a­tion to con­nect gen­er­at­ed game geog­ra­phy with gen­er­at­ed game sto­ries. They gen­er­ate set­tle­ments in the geog­ra­phy and rela­tion­ships between those set­tle­ments based on resources and needs. These in turn give rise to “sto­ries” (inter­ac­tions between indi­vid­u­als in the set­tle­ments). The place­ment of set­tle­ments is done in a mixed-ini­tia­tive way.
  • Ste­fan Lei­j­nen (HvA) and Paul Brinkkem­per (Fire­brush Stu­dios) talked about Mon­ey­Mak­er Deluxe, a game about frac­tion­al reserve bank­ing. They used Machi­na­tions to describe mod­els, which were then used as a blue­print for the gen­er­a­tors in the game. (PDF)
  1. Joris is asso­ci­at­ed with Hub­bub. His research on engi­neer­ing emer­gence was instru­men­tal in start­ing the HvA’s work in this area. []
This entry was posted in Articles, Featured and tagged , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.