Sponsored By

Giles Schildt, most recently director of game development at Austin-based Steve Jackson Games, took the podium at Austin Community College to explain why video game prototyping is important and how it can be done using basic, low-tech, old-school methods.

John Henderson, Blogger

May 14, 2006

8 Min Read


Giles Schildt

The horror stories from game development land cry out: two months until ship, and several key portions of the game aren't any fun. Of course, it took this long to implement the system as designed. Was there no chance to find this out sooner? Could “finding the fun” have been expedited somehow? The answer, prototyping, isn't a new subject to video game developers, but those attending the May 3 lecture at Austin Community College got an explanation about why prototyping is important along with how it can be done using basic, low-tech, old-school methods.

Giles Schildt, recently departed as director of game development at Austin-based Steve Jackson Games, publisher of games and rulesets such as GURPS and Munchkin, defined change as a necessary part of game design, and argued that the earlier the changes are made in the design process, the easier and cheaper they are to make. “So if we wait until a game is already in beta, and then find out the combat system doesn't work, the game's never going to ship.” A paper prototype costs “effectively nothing,” he said, and if it's done before specialized art or programming (including paying those employees to do the art and code,) it can shave off the final cost of the project, and whether the project is even worth pursuing as a digital product. The paper version of the game will never ship, of course, but the two to 12 hours Schildt used as an example for how much time a low-skill intern would have to spend documenting the “analog” game will cost the same as about 15 minutes of a programmer's time in terms of salary.

Paper prototypes also help expose the eventual game's core mechanics in a way that everyone can understand, including testers, who can be easily left in the dark about how the “real” game is supposed to work. Testing, Schildt said, is a lot like playing a “black box” game, where the outcome is obvious, but what's inside the “box” is not. “Most testers, when they look at a beta, they're really good at finding code bugs, because the code bugs will jump out at them and that's what they're trained to find.” Design is often buried under graphics and other abstractions that obscure the intended design. Instead of playing hundreds of times to learn game mechanics by brute force, having the analog prototype would open the box for testers who often can't be bothered to read design documents, he said.

Understanding the rules of the game can be the difference between finding problems and imbalances by trying to finish the game according to the rules (or trying to break them,) rather than by randomly poking around. “All you have to do is watch them,” he said. Most players and indeed, most testers won't try and reverse-engineer a design, that is, they won't play with the “black box.” Having in-depth feedback on the core of the game before it ships is far more valuable than seeing it on a hardcore player's web site, he said.


Schildt points to the "black box."

Analog prototypes have their limitations, Schildt warned. No computer will be available to crunch high-level numbers, so the kind of prototype designers should seek out are the kinds that players can learn from without needing a computer. Specifically, whether the game is balanced, whether it makes sense to those playing, and whether it's fun. Predicting balance with a prototype can be tricky, he said, unless the planned digital game is turn-based. Functions of time, such as how long a resource takes to harvest or how fast a bullet travels, are impossible to model with paper. Movement and “flow” is also hard to model with a prototype for much the same reasons – time and computing power can't be easily factored into turns -- and Schildt warned against the temptation.

Finding out whether a game is fun is far more interesting, Schildt said, but the important question to ask along with “Is the game fun?” is “Why is it fun?” Answering that question, and the arguments among the design team it implies, would be too much for one talk, he said, but once “the fun” and “the why” are discovered, it will need to be preserved from the prototype to the digital version. To that end, Schildt brought up examples of commercial game conversions, from digital to analog and the other way around. Those conversions have a range, from literal at one extreme, to merely stylistic at the other. A purely literal conversion would be one of the early computer chess games, where the only addition would be rulesets and an artificially-intelligent computer opponent, or maybe networked play. A more stylistic conversion would be Autoduel, the Origin Systems role-playing game set in the universe of Steve Jackson Games' Car Wars. The games didn't have much in common otherwise, so the gameplay of one couldn't teach much about how the other worked.

Most conversions, Schildt said, fall somewhere in the middle – appearing literal, but employing very different gameplay. Bioware's Neverwinter Nights is a faithful adaptation of the classic d20 board-game system typified by Dungeons & Dragons, but all the monsters are scripted by the game engine, instead of called out and described by the dungeon master over a game table. The Doom board game, for example, employs different “rooms” that are revealed by the gamemaster by putting differently-shaped cards in play as the “doors” are opened by players. While there's no twitching or aiming at monsters, the board game still features the sudden ambushes. These are the sorts of differences in overall experience that game designers should be watchful for, he said.


Schildt uses the Doom board game as an example.

Schildt offered a short list of pitfalls to avoid when moving from analog prototype to digital production:

  • Interface design. Don't make it too hard to follow what's going on during a digital game, or too cumbersome to do what the player wants to do.

  • Fun might be dependent on the medium. Parlor games like Werewolf are fun when players see each other face to face and can hear each other's voices, but try and play it in an Internet chat room.

  • Complexity is a killer. Again, analog games don't need computing, so any complexity in the digital game will have to be handled independently of what the analog prototype reveals.

  • Don't worry about time balance. That's something only testing the digital product can reveal.

Schildt said prototype materials are easy to find. Scour garage sales for old board games for boards and tokens. There's also several stores, online and otherwise, that specialize in reselling loose game parts. Once a prototype is built, test early and test often. He suggested starting with people working at the game company, and then go to gaming conventions. (sjgames.com routinely puts up news about the three to five such “cons” every year in the Austin area.) Then, it wouldn't hurt to use sites like boardgamegeek.com that have online “opponent finders.”

Finally, Schildt advised the following about how to run the tests:

  • Know your market. Don't put a hardcore wargame in front of casual roleplayers, for example.

  • Take careful notes about what happens.

  • Don't get emotionally attached to the mechanics. Designers, swallow your pride.

  • Don't be afraid to make changes, especially on the fly.

  • Don't argue with your testers.

  • Have goals, that is, what the team wants to accomplish, in mind for each phase of testing.

  • Listen for “first-person” comments such as “I think” or “I like,” and pay special attention to those who say “I'm confused.” Testers that make categorical statements about what third parties might think (i.e., “someone might be confused by this”) are less useful.

The lecture was one of the series featuring Austin-area game industry professionals, offered the first Wednesday of every month at the Highland Business Center campus of Austin Community College, courtesy of ACC's Video Game Development program and coordinator Robert McGoldrick. For more information on the program and the lecture series, visit the web site.



Read more about:


About the Author(s)

John Henderson


John "J. the Yellow" Henderson is a writer and journalist living in Central Texas and on the fringes of the game industry. Most recently a staff writer for the Ultima V: Lazarus RPG mod project, he co-authored (with Danielle "Sachant" Vanderlip) the official Shadowbane strategy guide for BradyGames. He keeps a blog at www.damnedvulpine.com.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like