Our collaborative, SWEAT, has been working at making socially conscious video games that function as multi-level critiques. These critiques include analyzing the tools and methods of making digital art—and of games in particular—and we have been exploring how to adopt and adapt open source models to our working method. It is important to us to leverage our experience with abandonware and see if there is a way to create something even more democratic. This layer of SWEAT’s critique is a quiet and deliberate policy of resistance. Our aim is to promote diversity in game development to keep the market honest and choice alive.

In the process of exploring alternative game development tools, we discovered a piece of middleware called Konfabulator, a program intended to help the general public create its own games. Konfabulator is aptly named in that it allows a relatively novice programmer to harness the power of Mac OS X’s Unix core using XML and Javascript to handle events and define functions. The program uses straightforward ASCII text for its source files, which makes the code-base comparatively simple. In addition, the makers of Konfabulator offer a library of “widgets” for programmers to use in experimentation and remixing.

Fig. 1 A segment of the source code for the Generative Game Engine.

An early Konfabulator adopter claimed to have created a game engine called Tiny World. We attempted to use it to create our own game but to no avail. Careful reading of the code revealed that although the demo was functional, the properties that would have allowed us to make our own game from it were not. However, the map files for the Tiny World engine used a clever conceit, a table of alphabetic characters to stand in place for a tilebased map.

Even though that game engine didn’t work as advertised, the code demonstrated a variety of ideas and considerable potential. Specifically, Tiny World suggested that a tile-based game engine could be written entirely in XML and Javascript, and that the engine could draw on a substitution algorithm to use an ASCII text file to store map, boss, and power-up information. Chad Schmidt took that suggestion and did what Tiny World had promised to do: after two weeks of intense work, he published the Generic Game Engine 1.0 on the Konfabulator website (Schmidt).

This first version of the game engine is predisposed to the creation of role-playing and adventure genres. It includes code for a player-controlled protagonist and a programmer-definable set of paths, obstacles, traps, rewards, inventory items, and antagonists. Events are signaled to the engine by a single ASCII character, and the engine is meant as an infrastructure for others to adapt to their own narratives.

The Generic Game Engine made the programming of a particular kind of game easier, but SWEAT wanted to make it easier still. We had written text parsing routines in the past and realized that it would be a neat trick to (re)make the game engine to accept any (any!) ASCII text file. As long as there was a piece of artwork (a tile) that could represent a letter, the engine would generate a map. So, steeped in pomo decon lit crit, and faced with the first major debate between narratologists and ludologists in the game academy, we thought: Why not let the text define the universe of play? Why not map the text? What if one ran the text of Plato’s Republic through the generator? How would it play?

With this provocative thought, we began developing the Generative Game Engine. As of this writing, the Generative Game Engine sports a feature that allows a player to become a creator by dragging an ASCII text file of any length and dropping it over the generator icon. A game map is instantly generated, with the text file determining the location of bosses, paths and obstacles. To simplify the prototyping, upper-case letters are treated as lowercase. The space character, numerals and punctuation are currently ignored, but will eventually be programmed too. The alpha version of the Generative Game Engine has now been tested with work by both Plato and Aristotle, and at this point anything that can be rendered or expressed in ASCII can be used to create a game map. Whether or not the map is playable is an open question.

In theory, one could read a book with an eye for how it would look as a game, thinking for instance that two e’s in a row will create a pond in a game map. From this perspective, the process of “reading” is less about comprehending traditional definitions of words and more about mapping words to visual, audio, and gameplay components that play out in developers’ minds or on players’ screens. A person trained in this new kind of literacy would have a different experience of reading texts. She or he, in fact, would read radically different from people who read in the traditional way. Such a person would identify how groupings of characters on a page translate into situations in a consequent game, in effect “seeing” (rather than “reading”) connections between the imagery of the text (in a typographic sense) and the corresponding elements that the game engine would substitute for them.

Fig. 2 The Generative Game Engine parses a text into individual letters and
then replaces them with images.

Taking this to an extreme, authors could theoretically write books differently, in the “language” of the generative game engine. Whereas people make games now for consoles, handhelds, and personal computers, people could write games explicitly for the Generative Game Engine in extended texts that could be organized as books, altering the reader’s experience not just of one text, but all texts.

The implications of Generative Game Engine are almost endless. Because one’s genetic essence can be expressed in text, in theory, a person could play one’s (genetically-sequenced) self. Data from a CAT scan, Micro-CT scan or MRI could be fed into the engine and so gamers could play specific organs. Pictures can also be played by starting with a PNG-formatted image, uploading it to an image-to-ASCII converter, and dragging-and-dropping the resulting file onto the Generative Game Engine. The plasticity of this application is amazing, and we’ve already tried it with a representation of Magritte’s The Treachery Of Images (Ceci n’est pas une pipe). This, of course, opens the possibility of authoring game maps in Photoshop, one pixel at a time, translating them to ASCII, and then re-translating them into game maps. The Generative Game Engine is the ultimate funhouse mirror.

Fig. 3 Among the aspects of gameplay to be defined are the kinds of terrain
that the player will (or will not) be able to traverse. Pictured here are varying
densities of grass, dirt, rock, sand, and water. This image was generated from
the same text as figure 2.

One final application for the Generative Game Engine: because Konfabulator is good at receiving RSS feeds, a developer could dynamically generate a game map using this ever-changing content. Future gamers could simply log onto CNN every morning and play the latest headlines: “Man, did you hear about the revolt going on in the Republic of Congo?” To which the Generative Game Engine user might well respond: “Yeah, I just played it.”

Works Cited:

Fajardo, Rafael. “Pixels Politics & Play.” Intelligent Agent (Fall 2003). 3/25/2005 <http://www.intelligentagent.com/archive/Vol3_No2_gaming_fajardo. html>.
Schmidt, Chad. Konfafulator Generic Game Engine. Konfabulator Widget Gallery. 3/25/2005 <http://www.widgetgallery.com/view.php?widget=36182>.
Wooldrige, Andrew. “TinyWorld.” Konfabulator Widget Gallery. 3/25/2005 <http://www.widgetgallery.com/view.php?widget=30828>.