An Interview With Game Creator Tod Foley
by Gloria Stern
Tod Foley is a game designer, consultant and technical director. He has authored many role playing games, including CyberSpace, the RPG. You may know him as the editor of PIX-elation, or as the panelist at the Electronic Cafe or numerous other industry conferences and live events. He is the founder of As If Productions. Get the picture? Wait. He's active in IICS, the International Interactive Communications Society, and he devised the incredibly innovative LARP (Live Action Role Play) - Ghosts In the Machine.
GS: Tod, you function in so many capacities, just what is your job description?
TF: The term I use most often is "game designer," for two reasons. First, I define the word "game' very loosely, and second, that's enough for most people. If they're interested in genre or method that'll be their next question. But the terms I feel most comfortable with (semantically, anyway), are "Narrative Environment Designer" and "Narrative Systems Engineer."
The long answer: On the typical project I serve as a 3-way bridge between the producer (whose concept the piece usually is), the creative team (writers and artists, generally culled from Hollywood and advertising), and the programming team (who have different needs and speak a totally different language than the other teams). My hands-on job is specifying the design; that is, determining exactly what sorts of routines, objects and multimedia elements are required to make the whole thing work in a mechanical sense, in a narrative sense, and in a game sense. This means I make flowcharts, create throughlines, analyze narrative elements, design interfaces, build demos, create script formats, specify objects, and invent prototypical algorithms for their behavior.
The short answer is "I write game specs."
GS: You have such a wealth of knowledge and experience in the field of gamemaster designer extraordinaire, tell me, how did you get started designing games?
TF: As a fan. I've been playing RPGs (Role-Playing Games) since I was 14 years old, and I'm one of those guys who immediately became attracted to the GameMaster's role. The GM is the one with the hardest job, the one who doesn't really play. When you play an RPG you are in charge of every decision your character makes, but the GM does everything else. Everything. From acting the role of the random tavernkeeper to rolling the dice against you in lethal combat, from planning the possible paths of tonight's adventure to literally creating the entire world. The GM functions as a writer, an actor, a narrator, a guide, a referee, and a judge. He also draws the maps and diagrams of the world, and - in my case at least - occasionally writes a period song or invents an alien language along the way.
In 1985 I discovered a fabulous system called SPACE MASTER, published by Iron Crown Enterprises. My group had such a great time playing I decided to write a fan letter to the company, and since so many cool ideas were coming up in our games I asked if they ever accepted submissions from freelance writers. (NOTE: It's a good idea to hit a company with a proposition like this when they've just released a product that's going to need support modules.) Anyway, they wrote me back, which floored me at the time, and said they'd like to see some of my stuff. I ended up writing seven games for them (some complete systems, some adventure modules) over the next five years. In a way, everything I've done since then has been an attempt to fuse RPG design theory with other media forms.
GS: You have taken interactive fiction from gaming through RPG to online environments to interactive theater. Could you please describe each of these broad groups?
TF: Well, it was more like RPG to theater to online environments... For many years Role-Playing Games were my life. Literally: I would live for months at a time doing nothing but designing game worlds and adventures, supported by my players. It was a strange form of co-dependency: they wanted to play games, and I churned them out as long as I was reasonably fed! After a while I grew up, meaning that I got married (Torey), had a kid (Chelsea), and starting working on things which were demonstrably job-like.
Around 1990 I began noticing this cyber-revolution happening in certain subcultures of the artistic community (the Berkeley-Mondo2000 crowd). I had discovered an affinity for computers through my day job, and had been thinking about ways to use the computer to enhance the RPG experience. First I built a bunch of GM-aides and databases of narrative elements to assist in design and play. These were crude programs written in BASIC or Q&A Macros. "Multimedia" was a new word, and although I had a vision of a networked role-playing game, I didn't know enough about networked systems to know whether it was possible or not. Even if it was, there was no way I could have payed for all the hardware it would require. So, like any resourceful artist, I found a cheaper way to do it. I decided to use humans.
Theater people... are their own thing. I've always had a performing streak: I once aspired to be an actor (which didn't last long), and I fronted a couple of local bands during my teenage years. Once you get performing in your blood, you never quite forget the feel of it. The theater taught me some important lessons about group synergy and being open-minded. If it wasn't for the performing arts, I would have remained a nerd forever (grin). In many ways fusing RPGs with theater might seem revolutionary, but for me it was a pretty logical step.
In 1992 I presented my first hypertheater piece,Ghosts in the Machine, at the CyberArts International conference in Pasadena. It was at that conference -- which the industry sorely needs back, by the way -- that I first got in touch with people who were making things happen on the other side of the screen. It was so cool, not only were my dreams possible, there were other people dreaming the same things! Of course I got my ass on the Internet right away. Since then, everything's just gotten faster, easier, and cheaper!
GS: Ghosts in the Machine was an experiment in Live Action Role Playing. It is described as "semi-scripted". Just what was provided and what was spontaneous on the part of the participants?
TF: The idea was to use the co-actors as objects in an interactive environment. This meant that they had very specific character traits and roughly predictable responses to certain things or events, the same way anyone does once you get to know them a little. In addition, each hour-long "act" contained at least two "cutaways" (a term I stole from LucasFilms): these were scenes which had been loosely rehearsed with various twists, scenes which were dramatic and had a good chance of happening regardless of the players states. Except for a few "taglines" which had worked their way in during rehearsals, everything the co-actors said was improvised. Of course this doesn't mean there was no infrastructure: an eight-hour overarching plotform guided the entire event, and numerous "miniplots" were scattered over the course of the show.
Before entering the theater room, players/participants received props and motivators including play money, weapons, credit cards, clues, bank account numbers, net passwords, character histories, etc., and were encouraged to get involved with any plots they wanted. Once they entered the room, everything was considered "in character" for both us and them.
GS: Do you see applications for this type of event?
TF: Definitely. From escapist entertainment to immersive training and education; even in therapy. I personally enjoy considering the entertainment aspects most, but that's a blurry line anyway. In debriefings and follow-up interviews with participants from these hypertheater events, I often find that people have learned important business and personal lessons from the experience.
There are two reasons why this works. First, no matter who your character is, the way you approach your goals comes out of your own real persona. Second, no matter who their characters are, most people in the game world will respond to you in ways which do not contradict their actual feelings (people who are masking their real feelings tend to be easily identifiable by their lack of sublety). The result is proof that "Art imitates Life."
It turns out that no matter how weird or limited the game world is, as long as it's complex enough to support a fundamental set of human actions and assumptions, it will generate experiences and information which is applicable to the real world. In fact the players themselves are the ones "driving" the whole thing: during the performance of a hypertheater piece, my job is basically to keep the system working.
GS: In designing CD-ROM games, like Ocean Voyager or Area 51 for Judson Rosebush Company, how do you go about creating the game aspects of such programs? Do you write them at the >same time as the through line?
TF: Depends upon whether the piece is more "narrative" or "exploratory." If the narrative elements are fairly time-bound it definitely helps to have a throughline before beginning the spec, but if the piece is more abstract or diachronic it's easier to create a conceptual framework and then fill it in.
In either case, the process of writing an object spec goes continually back and forth between "top-down" and "bottom-up." Top-down: Get an overview of the thing so you can begin thinking about what types of objects are necessary, create your object classes and specify their properties and methods. Bottom-up: Write objects. Write more objects. Add new methods. Write more objects. Eventually you get to a point where you have enough objects to have a representative feel for the world, for the types of things that can happen in it. I call this the "operant space." You have to keep switching your point of view from macro to micro in order to have it all make sense. If you don't do this, the angles you failed to consider will stick out like sore thumbs.
GS: What is the process like developing a CD-ROM? Could you briefly give us a rundown the production schedule?
Well, every project is different; sometimes there's a wealth of art or audio to be exploited, sometimes a rough concept is all we have for a while. But like any software development project, my job goes through five steps: Definition, Analysis, Design, Construction, and Testing.
Definition is the Functional Spec. This is where I describe the interface, the game world, and the operant space in mostly layman's terms.
Analysis is the Object Spec. This document describes all object classes, properties and methods needed to pull off the piece as described in the Func Spec.
Design is the Mechanical Script. This complex document differs in format from job to job, but the idea is to describe the narrative structure while referencing all necessary art, audio, or whatever else. In the "Construction" phase the programmers are busy making all of this stuff real, while the creative team and I continue filling in blanks, writing dialog, and rearranging the order of things. By the time Testing occurs I'm pretty much out of the picture, but in a sense you have to go through each one of these steps within each step... The whole process takes from four to twelve months, depending upon the size of the game world.
GS: Your company, As If, has made presentations that adapt interactive fiction to corporate training needs. What objectives does that address and just how is that accomplished?
TF: Fiction Immersion Training (FIT) is a concept which grew out of the "PlayAct" system (the infrastructure upon which my hypertheater pieces are based), coupled with the feedback we've received from our players over the years that they underwent significant learning and growth experiences, etc. It's just a concept at this point, but the basic idea is to distill the most transmutative elements from these experiences, and to build a functional battery of techniques which can then be used to structure more deliberate "training experiences."
GS: You have a good deal of experience with role playing game design (RPG) and theory, how is the writer's role different from that in creating linear fiction?
TF: At first it's completely different because the system is everything.
Has to be. If you haven't got a robust, heuristic, and highly complex system there's no way you're ever going to get anything more advanced than branching paths. And if you don't have a hand in designing that system, then you're stuck with whatever elements the programmers say you can use. You want to create worlds, not haiku.
But. When you have a good system, and have a clear grasp of its capabilities, then it becomes fairly second-nature to you. At this point you can stop thinking about the system and start thinking in it. All of the sudden you're a "creative" again. You're just doing it in a different language.
GS: How much technical knowledge is required for screenwriters and producers to function effectively in interactive media?
TF: Well, there's technical and there's technical. A lot of what I've said might sound extremely technical compared to writing prose (which I've also done a lot of), but I'm always awed by the real techies who implement my systems in code. I'd say it's more an attitude of being "technologically fearless" that's important. You should have a good capability for logical analysis. You should be comfortable with algebra. You should be able to hold multiple eigenstates in mind simultaneously. These are basically "left-brained" traits, which artists seem to find abhorrent, but the fact of the matter is this: there's a deadline coming, and the programmers are going to take whatever you've written and run with it. The closer you can get to their understanding of the world, the more the finished product will resemble your design.
GS: How is writing for electronic media different from writing screenplays?
TF: As far as process goes, the main difference is that the interactive writer doesn't have the luxury of simply choosing the most dramatic plot through a storyspace. He has to consider all permutations as being equally likely. And when you move from CD-ROMs to online worlds, the complexity goes way up and the conceptual grainsize gets much finer... The only way to approach a structure that complex is to break it down into modular units of function, which is the basis of the "object-oriented" design approach. Notice how the technical stuff keeps creeping back in... You really have to think with both brains.
GS: How do you suggest a fiction writer begin to get involved in interactive fiction?
TF: By taking your course, of course! (grin)
I don't know how typical my experience has been; I suspect it's not very typical at all. Most writers are going to possess less technical capability and fewer design models coming in than I did. As a result they'll generally get their start by writing dialog, manuals, PR, etc. The important thing is just to get yourself associated with people or companies whose ideas you like, because when projects start rolling they'll take an idea from anywhere. You might have a brainstorm in a production meeting and end up getting assigned a team role with more responsibility. This'll also give you a chance to hang out with programmers and learn "by osmosis."
GS: What genres are most suitable?
TF: I don't think there are any unsuitable genres for interactive treatments. It's not like there's one thing called "interactivity." The trick is finding or inventing a system which can support those types of behaviors and elements which are prevalent in the genre you're trying to emulate.
That said, some genres can be emulated more easily than others, since they're fairly simplistic in a mechanical sense. Soap operas work very well. Comic-books. Whodunits. Straightforward good-vs-evil battles. Melodrama. The thing these genres have in common is that they're all pretty "pulpy" - they sacrifice verisimilitude for the sake of clarity. But that's cool. As much as I enjoy pushing the edge of system complexity, I also like a good piece of pulp fiction. In time we'll develop systems of greater complexity and subtlety, but pulp will always be the game designer's friend.
GS: How do you select a format for a game, puzzle, mystery or treasure hunt?
TF: Sometimes it comes to you pretty clearly, like a song that pops into your head complete with words. Other times you have to "feel it out." It's like having an idea and wondering, "Is this a poem? Is it a short story? A movie?" You have to imagine it in all these different formats - walking through it from the user's point-of-view, mostly - and hopefully you'll hit on one that "clicks."
Then there's the issue of the documentation; that's another type of formatting problem. Here the goal is to come up with a system which can specify every element in the game, but to do this in a way that's a crystal-clear as possible. Every project is different, but there are two important spectra here. The first is "One Massive Document vs. Various Departmental Documents," which has a lot to do with the physical distribution and technical homogeneity of the team. The more you work with the same people the more you can take for granted, since you have a common vocabulary. The other spectrum is "Story Order vs. Technical Order." I tend to veer toward a more technical spec, since I consider the programmers to be my most important audience, and this shows in my approach. Of course there's a tradeoff here - you can read the tech spec of an entire game and literally not see the story there but if your story is any more complex than a bunch of simple Y-branches, it was never going to read like a narrative anyway.
I tend to support the technical doc with limited examples, written in narrative fashion, which indicate how the elements work together. You should probably write at least one narrative example for every transaction type and high-level routine.
GS: Your company has designed "Narricon", a program for multilinear storytelling. How does it aid/support the creative process? Is it something a linear writer could use to advantage?
"Narricon" - a name coined from the words "Narrative Lexicon" is a proprietary set of codes and functions I began developing about five years ago, while working on Ghosts in the Machine. It's evolved a hell of a lot since then. Initially, it was a sort of algebraic notation for describing storyspaces - all weird symbols and arrows, that sort of thing - but it's developing into an object-oriented authoring tool for the creation and maintenance of graphical environments.
While such a tool might help a linear writer walk through all the various permutations of a story in the works, I don't think it would necessarily speed the process. After all, any writer worthy of the name should be able to do that fairly naturally.
It's the maintenance part that I see as being most important. In order for narrative worlds to be sustainable as businesses, we'll have to continually add new objects, new stories, new possibilities to these worlds. Without that they're just a bunch of reruns. But no company wants to hire a cadre of game designers to do maintenance on a full-time basis, at least not just yet.
The solution - as I see it - will be tools which allow designers to quickly put together "narrative sets" by modifying the properties of existing object classes using a standard set of protocols. Applying object technology to the narrative design process itself. "Narricon" is my entry in that arena. It's not doing Dostoevsky yet, but it's getting pretty good at pulp... which is fine with me!
GS: Sounds about as offbeat and original as everything else you've done: a mix of RPG, theater and online. Let us know when it's ready, Tod. We'll be waiting to see it in action.
© Gloria Stern 1997
Reprinted with the author's permission.