Rafael Fajardo
Director, SWEAT collaborative
Associate Professor,
Emergent Digital Practices
University of Denver


Projects: Generic Game Engine

The Generic Game Engine is a product of the second generation of the SWEAT collaborative but had its seeds before this generation was convened. As I was working on the sketches and the proof of concept for Juan & the Beanstalk, in early 2003, I continued to look for alternative development environments.

In my search I found Konfabulator, a – then – Mac OS only infrastructure that harnessed JavaScript and extensible markup language (XML) in an open source model. It had some proprietary function calls that made it do some nice things. Konfabulator provided end-users a library of objects and functions that could be used to build a “widget”, a small but useful software application.

Konfabulator's creators provided a set of demonstration widgets and followed a non-proprietary open-source model. Among the first end-user contributions to their gallery was a work called TinyWorld by Andrew Wooldridge. Wooldridge advertised his work as a modifiable game engine, and I had hoped to use it to make a version of Juan & the Beanstalk. His code, however, did not work as advertised, he had inserted some code that would subvert attempts at creating an original game from his code.

I filed TinyWorld away for later investigation. Some of the ideas seemed like they might bear fruit. It served as a proof that Konfabulator would be a useful infrastructure. Konfabulator's deployment of XML and JavaScript, and TinyWorld's articulation of that code, hinted at the potential for the creation of a game engine that could exist solely inside of a browser – free distribution – and that the syntax would not be too arcane – empowering expression. For his part, Wooldridge did not continue developing his project until late in 2005, after Konfabulator had become cross-platform.

When the second generation of collabrative was convened, in the summer of 2004, I continued the search for alternative development environments that would allow for rapid prototyping and cross-platform deployment in an open-source model. The code-base also had to be relatively simple to learn, so that I could train this generation of collaborators quickly, since we would only be together for eight weeks. This second generation consisted of Glen Carlson, Larry Nguyen, Chad Schmidt, and of course, myself.

The Generic Game Engine is our first attempt to make a tool. We aspired to make an extensible, cross platform, open-source, freely distributable engine for the creation of games. We are attempting to create infrastructure as an art and design moment, and to empower others to express themselves through this emerging medium. I articulated this vision, and my collaborators, Chad in particular with this project, bought into the vision and helped me realize it.

Chad did the “heavy lifting” with the code. His is a gifted programmer. I set before him the task of making a comparative survey of several alternative development environments, including Stagecast Creator, Konfabulator, and Processing – then still in early alpha releases. I shied away from Flash and ActionScript because the publisher, Macromedia, has a history of charging developers a tithe for distributing products developed with its code. This is like France charging someone a tax for having a conversation in French. It rubs me the wrong way to have a toll-booth in front of my mouth.

Processing is an amazing project by Ben Fry and Casey Reas. My cursory inspection of its libraries early in 2004 gave me hope that we might be able to use it at some future time, but that its – then – current version didn't have the functionality we needed to develop an engine. Chad did a deep set of exeriments, attempting to adapt Wooldridge's ideas to Processing's syntax and libraries. He hit a wall. Processing couldn't handle variable names in a way that was important to the programming logic he and I were pursuing. He could have written the library that would enable Processing to parse out the variable names as data, but it would have taken him the rest of the summer, and the rest of us would have been twiddling thumbs.

Chad was as intrigued as I had been by Konfabulator and Wooldridge's TinyWorld. I asked him to see if I had missed something in my evaluation of TinyWorld's code, hoping his fresh eyes and gifts would succeed where I had failed. He tested the methods and processes provided by Mr. Wooldridge but to no avail. Finally, he and I read the code line by line where we found some function calls that I interpreted as sneaky, with no disrespect intended to Mr. Wooldridge. His code for TinyWorld promised to reference external data sets, this would make the engine modular and modifiable. It did not, in fact, do so. To make use of Wooldridges ideas the code would have to be rewritten from the ground up to make something behave in a modular and modifiable fashion.

With this discovery, I was ready to reshelve Konfabulator and recommit to StageCast Creator. Chad, however was only getting started. Forty-eight hours later he had written the bones of the Generic Game Engine, based on the DNA of Konfabulator and TinyWorld.

Differing Traditions
In the arts, it is acceptable to walk in someone's footsteps, to replicate and explore someone's process and methods because one will learn from the journey, and likely achieve totally different results. Contemporary literary criticism and musical practices lift and separate sources from their original contexts and re-mix and re-present them in new ones. In the sciences, experimental procedures are repeated with the intention of achieving, and therefore verifying, the same results. Some experiments are so thoroughly verified that the repetition is now used to teach about the experimental method, rather than to provide further evidence about the outcome. In academic scholarship, to use someone's sentences, word for word hovers between laziness and plagiarism, two unacceptable situations. In applied computer programming, using someone's code is standard practice. Re-inveting the wheel is seen as a waste of effort, and a fools errand. Write new stuff only if what you need hasn't been written before, or only if what does exist doesn't do what you need. The Generic Game Engine is situated in an uncomfortable intersection of these traditions.

Results to date
What we have created is a code base that works to interpret specially formatted ASCII texts as scenes. We are distributing the code base free of charge via the Konfabulator web site in the form of a demonstration widget. Included within the widget is an instruction manual, authored by Chad, for using the code base to make a game, and a set of visual interface development files, created by Glen, Larry and Myself. The manual, and the self-documenting code that Chad included demonstrate a core value of the SWEAT collaboration, and of open-source development in general. We choose to share resources in such a way as to empower each other and, further, to empower others outside of our collaboration to express themselves. This was reinforced by the inclusion of modular and modifiable visual interface components.

We were inspired by another Konfabulator widget called TinyWorld that made some exciting claims but which had been abandoned by its author before completion. When we attempted to make use of the TinyWorld source code, it didn't act as promised. So we took the code apart to figure out why. We ended up creating large chunks of new code that made it accept text files and art from outside the original code. We added capabilites that allow game states to be saved and actions to be performed. We also added significant amounts of commentary to the code so that others can more easily follow our footsteps. TinyWorld and its author are credited in the code, the “about” box, and the “read me” file that accompany our engine.

We are very excited by this first step. It suggested a direction for a more powerful critical tool we called the Generative Game Engine. This project, and my meditations on the development of Juan & the Beanstalk, began to suggest to me that game engines provide a syntax, a grammar that defines rules for what kinds of game can – and cannot – be expressed with those rules.

Generic Game Engine
Konfabulator widget, XML, Javascript, PNG, Adobe Photoshop
variable size, presented as greyscale but available 24 bit color
Project director: Rafael Fajardo
engine design: Chad Schmidt
character design: Glen Carlson, Larry Nguyen

Process Galleries
Interface bits
Source code
Sample data code