Technology Inspires Creativity: Indie Game Jam Inverts Dogma 2001!

A little over a year ago, I wrote a tongue-in-cheek column called "Dogma 2001: A Challenge to Game Designers." In that column I introduced a three-word manifesto: Technology Stifles Creativity (at least for a while). My basis for saying this was the plethora of cookie-cutter games that get published with the introduction of every new console machine: the new hardware takes so much time to learn that game design creativity goes out the window while all the developers are busily trying to outdo one another in technological splendiferousness. Most of them are simply old games with new display engines. The result is like watching movies filmed entirely for the sake of their special effects: spectacular, but shallow.

That was the gist of my argument, and I think it's still valid in the world of commercial computer gaming, where competition for shelf space is so fierce and market forces conspire to stifle creativity even more efficiently than new technology does. The point of Dogma 2001 was to take technology - specifically, graphics hardware - away from designers, and challenge them to devise new games without making reference to it.

But what if we inverted Dogma 2001? Suppose we took a technology and told designers explicitly to think of new kinds of games we could make with it, without regard for their commercial viability? What if we took a technology, and instead of letting it stifle us, we let it inspire us?

From March 15th to 18th 2002, a group of 14 designer-programmers did exactly that. They got together in a barn in Oakland, California, worked insanely hard for four days, and developed 12 new games, all based on a single piece of technology. It was called the "0th Indie Game Jam."

0th Indie Game Jam.

The origin for the Indie Game Jam was simple: Chris Hecker and Sean Barrett, two of its organizers, were brainstorming game ideas one day and they asked themselves a question: How many sprites can you put on a PC screen with modern display hardware these days? Even fairly aggressive games like Shogun: Total War never display more than about 1000 units at a time. What's the real upper limit? They did some research and came up with an answer: about 100,000.
"But," I hear you cry, "who in the world wants a hundred thousand sprites? Sprites are dead, aren't they? An outmoded technique, old news."

No. If that's what you think, you don't really understand technology. Technology isn't subject to the whims of fashion. To an engineer, technical methods are not hip or dead, tired or wired; they are simply more or less suitable for a particular purpose. All techniques, no matter how ancient, have their use. Every now and then a long-abandoned practice turns out to have modern applications, as when doctors recently discovered a new use for leeches in medicine. On the flip side, NASA has lost most of the engineering drawings for the Saturn V rocket, and the engineers themselves have retired. If we wanted to go back to the moon for some reason, we'd have to start from scratch - inexcusable short-sightedness.

Sprites were superseded not because they were useless, but because 3D models were better suited to the particular purpose that everyone was interested in at the time: rendering 3D spaces and objects. But suppose instead of rendering a 3D space filled with complicated models, you had 100,000 sprites and a simple landscape. What kind of games could you make?

That was the question that the Indie Game Jam sought to answer. Hecker, Barrett, and three other friends - Doug Church, Casey Muratori, and Jonathan Blow - spent several weeks developing a simple engine and one sample game to use as a springboard. Then they invited a small group of designer-programmers to come and work with it for four days straight. The results were weird, funny, gruesome, thought-provoking, and, yes, spectacular. This is what they came up with:

Angry God Bowling

Angry God Bowling, by Doug Church. This was the sample game. You roll a ball and crush the flocking people, who flock to a prophet when they get scared.

Red Rover, by Doug Chuch & Chris Hecker. There are two huge armies on either side of a map, moving towards each other. You control one by either telling them to run away from a point laterally, or "try harder" by concentrating in an area. The first army with a soldier to hit the opposite map border wins.

Firefighter, by Doug Church & Chris Hecker. Fly a helicopter around and fight forest fires; water is a resource you have to go fill up. I've wanted to do a game about forest fires for nearly 15 years, and even did a design for EA, but it never got funded. The big problem was displaying all the trees. This game uses the sprites to show the trees, and as a result it has the best-looking 3D forest I've ever seen.

Flow

Flow, by Charles Bloom. The object is to guide a liquid through various puzzles by changing the terrain. Each sprite represents a small volume of the liquid. It responds to gravity and can only get so near to another sprite, so the whole collectively flows downhill and occupies space just like a real fluid. By comparison to the other games with their huge landscapes, Flow has a small, intimate feel to it, a puzzle you can hold in your hand.

Charles Copter, by Charles Bloom. A four-player networked game where you scoop up people of your color and try to rescue them. Vaguely based on the arcade classic Choplifter, but with lot more people.

Dueling Machine

Duelling Machine, by Thatcher Ulrich, inspired by a book called The Duelling Machine by Ben Bova. The game looks like a first-person shooter, but with a twist. You are in a city full of pedestrians (thousands of them!), you have exactly one bullet, and you have to find and kill a single unique fugitive. You have a sonar that will help you locate him, but he can also hear it when you use it. This game is also 2-player networked. Except for the sonar, it's completely silent, creating an extremely creepy, tense experience.

Troopers, by Art Min & Sean Barrett. You command nine super-powered ground troopers, but you are stuck in the command center, and hordes of aliens start pouring over the ridges around you.

Total Age of Doomcraft & Conquer: Romero Alert, by Robin Walker & Brian Jacobson. A super-RTS, with an innovative gestural command interface and thousands of units. The game is hilariously chaotic to watch. Instead of producing units slowly, one at a time as in ordinary RTS's, the factories spew them forth in a fountain all over the nearby area.

Very Serious RoboDOOM

Very Serious RoboDOOM, by Sean Barrett. It works a bit like the old Robotron 2084 arcade game, but this is more an artistic statement on the futility of the one-against-all power fantasy combat game. You start with a closeup view of your avatar in a landscape, shooting at what appears to be a small number of nearby enemies who are all converging on you. As you do so, you collect a group of people who follow behind you à la Robotron. However, the camera zooms out slowly in proportion to the number of enemies you've shot, revealing more and more of the map. It becomes increasingly clear that the situation is hopeless. There are actually 75,000 enemies, but you don't know that at the beginning. The transition from seemingly normal game to satiric commentary takes place very smoothly and is actually quite funny to watch as realization dawns.

Worship, by Ken Demarest & Zack Simpson. A Missile Command style game, with hordes of demons trying to capture instantiations of Jesus, crucify them, and take them away while you're trying to protect them. Another game that won't win us any friends in Congress, but still highly imaginative. Contains the code #define MAX_CHRISTS 5.

Dueling Machine

Wrath, by Brian Sharp & Chris Carollo. Two gods compete for followers, but they only get the credit when the followers die believing in them. As a result, the most successful strategy is "convert, then kill." However, the followers are so small that it's really impossible to see them as individuals. Rather, they look like seas of color, with areas of influence flowing around.

Spotlight, by Marc LeBlanc. He couldn't attend the whole Jam, so this game was only worked on for a few hours. You shine a spotlight over a sea of people, and see color shifts that indicate infections. One type of person flows to light, one away, and you have to try to save vulnerable creatures. If that sounds incomprehensible, it's because I only got a very quick look at it and I don't know what LeBlanc had in mind for the longer term. It's definitely an interesting start.

Now, these are not finished games by any means, and like so many games designed by programmers, many of them an edgy, somewhat juvenile, sense of humor. Nevertheless, they're all imaginative and very different. When they were demonstrated at the Experimental Gameplay Workshop session at the 2002 Game Developers' Conference, the response was prolonged cheering. I asked Chris Hecker to give me some more information on the Indie Game Jam.

Why sprites, particularly? As opposed to some other challenge?

Well, it was sort of accidental. It was definitely "technology driven" in the sense that we thought up an interesting and different technology, realized the concept led to a bunch of wacky game designs, and then got the idea for the Jam from that.

I think the game industry is not experimental enough. We're too risk averse. Games cost a lot of money, and publishers want to have a reasonable chance of making that money back, so that leads to conservative and incremental designs. I don't think that's healthy for the medium in the long term, even though it's brought us lots of revenue in the short term. If you look at other art forms, there are built-in mechanisms for experimentation and exploiting experimentation, whether it's garage bands getting their sound ripped off or getting a record deal, or an experimental film-festival hit getting distributed by a big studio. Games, as an art form, have hardly scratched the surface of their potential, but we've already calcified and gotten conservative.

The Indie Game Jam was an effort to encourage experimentation. Get a bunch of smart designer-programmers in a room with a focused and mostly-finished technology and see what happens. It's like a jazz jam session with professional musicians riffing off a single tune, or a writing workshop where there's a theme for the weekend.

The second thing we hope to accomplish is to inspire other developers to do their own Jams with their friends. We've already heard that Eric Zimmerman is going to run something similar internally at his company to encourage innovation. We're going to put all the games and their source code on the web for free under the GPL, as well, so hopefully more people will play with the concepts.

First, the participants had to be great programmers. There's just no way to get anything done in four days with a big pile of code you've never seen before unless you can program really well.

But they also had to be designers. We choose people who are what I call "Looking Glass-school designer-programmers." Looking Glass Technologies bred a certain kind of "algorithmically-aware designer" and "design-aware programmer," and I think that is the future of our art form. You can tell by playing Looking Glass' games that the LG aesthetic was one of embracing interactivity and exploiting it in new ways. I just wrote a Soapbox column for Game Developer magazine on the topic, but in short: game design is about interactivity, and interactivity is about algorithms.

So, to do innovative and experimental game design, you have to be able to design algorithms, and if you only have four days, you also have to be able to code them up yourself, and quick!

We actually invited a single non-programming designer (Austin Grossman, still an LG-school designer) as an experiment to see what would happen. Unfortunately there were some schedule problems and he couldn't spend as much time at the barn to really gather data for the experiment. We'll definitely try again with non-programming designers next year.

I also invited a journalist friend, Justin Hall. He ended up doing art for the various games.

Definitely.

Do you think next time you'll bring some artists along?

We could have used as many artists as would fit in the barn. We had a ton of prepared content ready, ripped out of Doom-era WAD files [most of the games feature sprites "borrowed" from Doom and Doom mods on the Internet], but people also wanted custom content once their game design solidified.

Did they cooperate, or was it just a bunch of programmers engaged in technological chest-thumping?

That was the most amazing thing: there was absolutely no competition and there was complete cooperation. We tried from the beginning to avoid competition, so that was somewhat expected, but the level of cooperation was incredible. People shared code routinely, helped with each others designs, fixed bugs for each other, brainstormed together, etc. The sonar feature in Duelling Machine was actually Marc LeBlanc's idea, developed while he was helping Thatcher playtest it -- a good example of cross-pollination.

The time was all donated. The biggest problem with the entire event was that it sucked up an immense amount of time for the core people when developing the engine. It was enough time that we'll have to figure out a way of limiting it next time.

Intel loaned us the machines (16 1.8 Ghz Pentium 4 PC's with GeForce 4 Ti4600 video cards and 256MB of RAM). I contacted Kim Pallister at Intel and he was into the concept from the beginning.

Copyright © 2003 CMP Media Inc. All rights reserved.