Contents
Guest Editorial: Conference Lessons
Dave Menconi
Software Reliability Testing
Cem Kamer
What is a Computer?
Chris Crawford
Bringing Characters To Life
David Graves
A Mickey Mouse Approach to Game Design
Jeff Johannigman
Real Life in a Box or, How to Design and Implement a Computer Vehicle Simulator
Gordon Walton, John Polasek, and Karen Hunter — Digital Illusions, Inc.
Editor Chris Crawford
Subscriptions The Journal of Computer Game Design is published six times a year. To subscribe to The Journal, send a check or money order for $30 to:
The Journal of Computer Game Design
5251 Sierra Road
San Jose, CA 95132
Submissions Material for this Journal is solicited from the readership. Articles should address artistic or technical aspects of computer game design at a level suitable for professionals in the industry. Reviews of games are not published by this Journal. All articles must be submitted electronically, either on Macintosh disk , through MCI Mail (my username is CCRAWFORD), through the JCGD BBS, or via direct modem. No payments are made for articles. Authors are hereby notified that their submissions may be reprinted in Computer Gaming World.
Back Issues Back issues of the Journal are available. Volume 1 may be purchased only in its entirety; the price is $30. Individual numbers from Volume 2 cost $5 apiece.
Copyright The contents of this Journal are copyright © Chris Crawford 1988.
_________________________________________________________________________________________________________
Guest Editorial: Conference Lessons
Dave Menconi
[Dave is a member of the Conference Committee.]
Now that Computer Game Developer’s Conference II is over, it is time to sort out its lesssons .
I noticed that a large number of lecture attendees seemed intent on giving a mini-lecture from the audience. In a number of lectures, the lecturer lost control of the information flow.
If you have something that adds to the lecture, say your piece briefly. It is inappropriate to prattle on. Once the speaker gives you the floor, it is hard for him to cut you off. So you will have to be the one to cut yourself off.
I saw one case of audience digression in which a member of the audience took strong exception to the points made by the speaker and spoke passionately about his own point of view. The speaker listened attentively and then, after a few brief comments, gave the floor back to the challenger! This happened near the end of the lecture period and so the organized lecture disintegrated into a jumble of ideas.
In another incident, it was the speaker who wandered far afield. An employee of a publisher, he took us through the first half of the speech right on track. But then he wandered off into a fifteen-minute commercial for one of his products! He later claimed that he was trying to use this product to illustrate a point. This thinly-veiled excuse would have been tolerable if the product had some relation to the topic, but this was simply not the case.
This is the risk we take in granting publishers a platform to speak at our conferences: they may spend a lot of time — our time — patting themselves on the back. In all fairness, this was the only case of back-patting I saw.
There were numerous positive incidents that I won’t go into because they indicate that we already understand appropriate behavior. One event worthy of note occurred when a lecturer, with only a few minutes left, offered to take some questions from the audience. Earlier there had been some off-topic squabbles between members of the audience and it might have been these that prompted someone to say, “Please don’t call on someone. I’d rather hear from you.” This is a case of someone taking responsibility for making sure that he hears what he came to hear.
This brings me to something I noticed in my own panel. Someone asked if other developers used several playtesters. None of the panelists knew, so we found out. I asked for a show of hands, gauged the response, and declared, “Yes, other developers do.” This got a hearty laugh, but it wasn’t intended as comic relief. The point is that the conference is not for the purpose of hearing from the industry greats. We had lecturers as a focus for communication, not as the end purpose of the conference. The real wealth of information is in the audience!
So, how do we solve some of these problems? What could we have done to prevent diatribes, to curb over-zealous publishers, and to support timid speakers? We need to police ourselves and, to some degree, police each other.
Personally, I am more willing to speak up and politely interrupt diatribes and attempt to get the talk back on track. After all, I came to hear the views of the speaker on the topic, not the ideas of some hothead. And as for publishers letting me pay so that they can brag about their products... let’s just say that I won’t stand mute again!
Each person at the conference must be responsible for seeing that everything goes smoothly and that the conference works for everyone. But we must be careful how we effect this solution. If everyone feels that this responsibility gives him the right to interrupt, shout down, and hassle speakers, then the cure is worse than the disease. So take responsibility for yourself as well.
If your only reason for coming to the conference is to find out what other people have to say please: STAY HOME! We need people at these conferences who will take an active part, both in communicating their thoughts and in making sure that the thoughts of others are communicated. I am pleased to say that we had people like that at this conference and that this is what made the conference a success!
See you again in May!
_________________________________________________________________________________________________________
Software Reliability Testing
Cem Kaner, Ph. D.
Software Testing Manager, Creativity Division, Electronic Arts
[This paper is based on the talk that Cem gave at the Computer Game Developer’s Conference.]
Frequently, discussions of testing focus on the recruiting and use of playtesters. These are important people but their function is limited: playtesters’ function is to improve playability.
In line with that, we’ve heard that it pays to hire people (or use volunteers) who are computer naive or who are inexperienced with the program. I agree. We’ve also heard that a paid expert who has a strong grounding in the user interfaces of games is also valuable. I strongly agree.
But many developers also rely on their playtesters for reliability testing — finding the bugs in the product. Are the playtesters adequate for this?
Yes: if the program is relatively simple and most users will follow similar paths through it. The playtesters will follow the same paths and find the same bugs as the market would, so all is well.
No: if the game is rich and complex. The customer base will explore many more paths than a few playtesters can.
So if you’re developing a complex game, how do you go to get the bugs out? Here are three alternatives:
The Traditional QA Group
I don’t know why we call these people “Quality Assurance.” They do no such thing. You do the quality assurance. You design the game, you decide how to structure the code, you decide how much sweat and time to put into the graphics, how the story will go, what level of humor there will be, all that stuff. Your standards go inside the box and your name goes on it. The tester helps you posish the user interface and s/he helps you find bugs. This is important assistance in a small, but very important, aspect of quality. It is not quality assurance.
A common model for software QA testing, called the “waterfall model,” is often presented a something serious. It doesn’t work, and most of us know that, but the professional literature in Software Engineering constantly tells quality assurance staffs to hold us to the waterfall.
QA staff try to do good jobs. They read professional standards and try to follow them. Those standards tell them to become very conservative, and very paperwork-oriented. Standards followers need detailed specifications from you and they spend vast amounts of time creating their own. They discourage latestage innovation. Realize that you’ve set these people up: you’ve told them to do “QA” but you only let them do 5% of a true QA job. On the inside, that makes them insecure. On the outside (depending on how you treat them), they can be arrogant, frustrating, and nitpicking.
Hire a Flock of Playtesters
You can pay $6 or $8 or $10 per hour and hire a playtester or a flock of them. Playtesters will work for the pleasure of it, but in reliability testing you get the skill set you hire for, at the level you pay for. It’s hard work, and the fun of working whith a new game goes away after they’ve hammered at this part of the game for the umpty-fifth time.
Playtesters who don’t understand the methodology of software testing are not effective bug finders.
Use Software Testers
This is the right approach.
You might find software testers easily or you may have to train them yourself. Some playtesters become excellent reliability testers. You may use the same people for playtesting during early development and for reliability testing later. However you find them, it’s important for you to clarify your objectives for their work, to yourself and to them.
Reliability tester’s key task is to find and report bugs. You want them to do this quickly, to report the problems reproducibly, and to cover the program thoroughly.
The first problem that reliability testers face is that you’ve already tested the program pretty thoroughly. We hear estimates of the number of bugs in a program when it’s passed to a tester: industry average is about 1 bug per 100 lines of code. These are called public bugs, the bugs that are still there when you show the program to someone else. There are also private bugs, which you find before showing the program. The few small, informal studies of private bugs suggest theat the average private bug rates are about one bug per line of code.
After making a mistake in every line of the program, you proofread it, fix it, compile it, fix it, LINT it, fix it, test it, fix it, analyze it, fix it, and finally you give it to testers with one mistake per hundred lines.
No wonder you think you’ve tested this code thoroughly! You’ve fixed 99% of the bugs!
The reliability tester has to find the remaining 1%. S/he has to look where you haven’t looked, or to find test cases that you haven’t tried. This is a highly personal, psychological challenge. Of course, there are methods for testing the game “completely,” but if the tester follows those blindly, s/he can hold your game up for months or years.
A good tester understands standard testing methodology well, so well that s/he understands how to take shortcuts, how to prioritize the tasks, how to guess what can be skipped or postponed, and how to go for the throat quickly, so s/he can find the important bugs as early as possible. A producer at EA complains of a senior tester who reminds him of a neighborhood bully, picking on this poor defenseless little program. The poor little bugs just don’t have a chance. This is what you want.
Programmers are trained to do “path and branch” testing. Your testing is based on a listing of the code. You make sure that you execute every statement, and try every branch in the program. Some books and even some software testing consulting companies call this “complete testing.” It is not.
These are some of the holes you’re leaving for testers to find bugs in:
WHAT CODE PATHS DON’T TELL YOU
1. Timing-related bugs
2. Unanticipated error conditions
3. Special data conditions
4. Validity of displayed stuff
5. User interface consistency
6. User interface everything-else
7. Interaction with background tasks
8. Configuration/compatibility
9. Volume, load, hardware fault
What you have to find in a reliability tester is someone who can quickly abstract the internal limits of variables in the program, and test the program at those limits, and who can find the kinds of bugs listed above. You need someone who can do it quickly and thoroughly, and report bad results compellingly.
There are lots of ways to find these people, or to find people who have potential and can be trained, but it’s up to you to find them. For complex software, for reliability testing, voluntary playtesters and untrained, underpaid amateurs just don’t cut it.
_________________________________________________________________________________________________________
What is a Computer?
Chris Crawford
It is often instructive to ask simple, fundamental questions, and so I propose to address this most fundamental question. Just what is a computer?
The most obvious approach is to provide a conventional engineering definition. A computer is a device with a CPU, some RAM, an address bus, data bus, and so forth. We could construct an elaborate definition or a simple one. But any such definition is easily shattered. I could readily build an absurd machine to meet any such specification. I could bollix up the ALU with inverted arithmetic relations, or scramble the address lines so that it could not retrieve data reliably. I could create an Alice in Wonderland operating system (I once did just that for the Atari 800) that defies all reason — and it would probably still meet a technical definition of a computer.
A conventional engineering definition is bound to fail because the computer is first and foremost a tool, not an object. That is, it is defined not by what it is but by what it does. Like any tool, the computer is best described by its function rather than its construction.
So what is the function of the computer? We don’t know. This really shouldn’t bother us — after all, any new technology takes a while to seep into the consciousness of a civilization. Gutenberg saw the printing press as a better way to make Bibles. The early automobile was seen as a touring vehicle for the well-to-do. How could Otto Daimler have foreseen naked lady hood ornaments?
Actually, in the early days we thought we knew what a computer was. A computer, back then, was a machine used to carry out elaborate mathematical calculations. You programmed it to perform the desired calculations, submitted the program to the computer, and waited. The computer crunched your numbers and vomited the results onto several reams of wide green-striped paper. The computer, in short, was a batch-oriented number-cruncher.
But then came the revolution. At first they were called microcomputers, and the term seemed apt. They were, after all, tiny versions of the big mainframes, so we treated them that way. The software we wrote in those days felt like micro-versions of the stuff the Big Boys played with.
It is a universal law of revolutions that they never work out the way the revolutionaries intend, and we were no exception. What we thought was the Microcomputer Revolution turned out to be the Personal Computer Revolution. The shift was not the work of any individual or company — we just bumbled into it. Once we had machines with a modicum of power, we began to stumble into their real uses. Visicalc was the first such discovery. Bricklin offered it to Apple Computer and was politely told that nobody could see any use for the thing. After all, nothing like it existed in the “real world” of mainframe computing. But users, real people not prejudiced by mainframe-think, got their hands on the product and realized its immense utility.
Why was VisiCalc so successful? I attribute its phenomenal success to a single factor: interactivity. It is one thing to submit a pile of numbers to a mainframe and wait for it to pass judgment. It is entirely another matter to put in your numbers, see a result, and then play with them in real time. The user could change a number and see the effect of the change instantly. The responsiveness of the system encouraged the user to play with the numbers, to explore the behavior of the financial system in the spreadsheet, and to find the best solution.
There were other areas of experimentation with personal computers. Word processing was an early success borrowed from the mainframe world, but it rapidly evolved away from the mainframe approach. While WordStar with its mainframe-style embedded control characters enjoyed great initial success, it represented an evolutionary dead end. What really caught on was the WYSIWYG style. The first hardware-software combination to get it right was MacWrite on the Macintosh. The WYSIWYG style of word processing has never been challenged on the Macintosh and is making inroads into the IBM world.
Why has WYSIWYG word processing enjoyed such success? Again, I attribute it to the interactivity offered by WYSIWYG systems. The mainframe-style word processor requires the user to print out the document before seeing the results of his work. The WYSIWYG word processor shows it directly, so that when the user makes a change to the document, the effects of the change are immediately apparent. This encourages the user to experiment more freely, to try variations, to play with the wording. This is the source of WYSIWYG’s superiority.
Another field in which personal computers are used is simple programming. The dominant language during the early days was BASIC. Everybody knew that BASIC was a naughty language, but it remained the most popular language for personal computers. So de rigeur was BASIC that the Macintosh was initially castigated for failing to include the language in ROM.
Why did BASIC maintain such a firm grip on the personal computer, despite its many flaws? The answer is the same as with spreadsheets and word processors: interactivity. BASIC was the only available interpretive language. All of the righteous languages (Pascal, C, etc) were compiled, and the additional step of compilation obviated interactivity. Only BASIC allowed the user to enter a line of code and immediately see its effect. Only BASIC allowed the user to play with the program’s structure and content. BASIC retained its popularity until the advent of fast compilers such as Turbo Pascal restored interactivity to the programming process.
I could go on with other examples but I think my point is clear: the central focus of the personal computer revolution is interactivity. The very essence of personal computing has a human using a computer to explore a messy problem. The human uses his creativity and values to propose a variation on the existing scheme. The computer uses its computational resources to work out the ramifications of the variation and presents the resultant order of things to the human. The computer’s response is so fast that the human is encouraged to try again with another variation, to explore all the possibilities, to play with the situation.
There’s that verb again: play. Did you notice that it cropped up in the discussion of each of the three major applications? Spreadsheet users play with the numbers; word processor users play with the words; and BASIC users play with the programs. Play and interaction are closely coupled concepts. Rich, deep interaction is indistinguishable from play. Is joyous lovemaking a form of play or interaction? Is a child’s first encounter with a kitten play, or is it interaction? When humanity lofts one of its own into space, are we playing with the universe, or interacting with it?
The notion of play brings us to games, the fourth great application area of personal computers. Sadly, it is an area some would deny. Last week there was a computer show in Anaheim proudly proclaiming “No Games Here!” Most computer magazines would rather not talk about computer games. Apple Computer seems to wish that they didn’t exist (‘not on our computers, you don’t!’)
What is so perverted about this attitude is its denial of the fundamentals of the personal computer revolution. For games are not merely a valid part of the revolution; no, I claim that computer games come closer to the very essence of computing than anything else we have created.
To make this case, we need not appeal only to the intrinsic playfulness of games and some mystical connection between play and good computing. No, the connection is closer and tighter than that. Go back and reread the paragraph presenting “the very essence of personal computing”. Does it not describe the process of playing a computer game? Indeed, does not the playing of a computer game carry out this process better — more richly, more deeply, more intensely — than any spreadsheet, word processor, or programming language? Will not the user of these latter three progams pause at times to wait for the computer? Will he not occasionally break the interaction to look up some obscure command or capability? Will his attention not drift away from the tedious task at hand?
Not so the user of the game. Look at him: he sits entranced, locked in deep interaction with the computer. No pauses or daydreams compromise the intensity of his thinking. Nor does the computer waste millions of cycles in idle wait loops; it rushes to process the most recent keypress or mouseclick, to update the screen or move a sound to the speaker.
I am not talking here about action games. My arguement does not require that all good games be frantic exercises in sub-cerebellar function. What I am talking about here is not the velocity of interaction but its intensity. Action games move tiny amounts of information through the interaction circuit at high speeds. The same result can be obtained by moving larger amounts of information at lower speeds, and many good games do just that. The crucial observation is that the total flow of information — volume times speed — remains higher for games than for other applications. Games offer more interaction than spreadsheets or word processors.
That is why games come closer to the essence of computing than any other field of software.
_________________________________________________________________________________________________________
Bringing Characters to Life
David Graves
[David is an engineer at Hewlett-Packard working on a new game system that emphasizes characterization.]
Intelligence and Goals
In order for characters to act intelligently they must be able to interpret the state of their environment and apply appropriate behaviors. James Meehan, who developed the story generating system TALESPIN as part of his PhD work, states, “A problem domain contains: (1) a set of representational primitives, (2) a set of problems which are expressed in terms of those primitives, and (3) a set of problem-solving procedures.” Meehan’s characters applied their knowledge to solve problems, creating a story by their actions.
While applying a problem-solving procedure to achieve some goal, however, complications may arise. In traditional interactive fiction, we pass all these problems to the player. Instead of troubling the player character with minor complications, the game software could automatically resolve them. For example, given the command “Drink the beer”, rather than having a character complain “The beer isn’t open”, it could recognize “Open the beer” as an implied subgoal. Any given goal could give rise to a number of subgoals, which may create subgoals of their own. When a character is able to handle low level logistics without being given explicit instructions, he appears much more intelligent. This technique also provides a mechanism for handling tedious logistical details on behalf of the player, who is then free to think at higher levels. The topics of handling subgoals and representing the physical environment are covered in detail in “Second Generation Adventure Games” by Graves, JCGD V1, #2.
Meehan points out that “This isn’t the stuff that stories are made of. It may be coherent, but it isn’t normally interesting”. However, a certain level of intelligent behavior is required in any simulated character, else the illusion of lifelikeness is too easily shattered. Further, this software layer makes a platform for simulating motivated behavior, an important “fuel for plot”.
Motivation and Drama
No organism’s behavior is ever unmotivated. Thus, in order for characters to display behaviors that appear reasonable and believable, they must have their own motivations. These motivations help stimulate the generation of plot. However, without guidance for the plot, chaos is a likely result. To ensure that the generated plot is interesting, the system could have some concept of drama and apply it to the currently unfolding story. Laurel’s dissertation gives an outline of an expert system to do just that. “Understanding a story in its totality is a task that integrates natural language understanding and the understanding of characters’ goals, plans, traits, and emotions, and utilizes still other techniques for identifying larger patterns of action.” This computerized playwright would recognize opportunities for new plot twists and act on them. Clearly, this is a lofty vision, requiring vast resources to implement.
Several projects have been successful in creating small expert systems that focus on character behavior and interaction, rather than attempting to recognize and generate plot units. Crawford employed a set of over 70 rules that defined the specific behaviors for character interaction, plus rules dictating the unseen internal reactions of the characters. Instead of focusing on generating a storyline, the game focused on interesting associations between characters, via dialog and deal-making.
Meehan demonstrated a simple (although powerful) technique for driving the plot in TALESPIN. The plot unfolds simply from the goals of the characters, their relationships to each other, and their individual traits. Thus, using Meehan’s model the author exerts indirect influence on the plot, through the definition of the characters. Changing the initial state of the characters would result in the generation of a different story.
Of course, an author could also “cheat” by defining additional goals or feelings that may be inserted in a character’s head at certain times critical to plot development, or in response to some external stimulus. This forms the basis of the Artificial Personality research currently in progress by Tim Brengle and myself. We use code fragments called “affectors” (which may be attached to various locations, objects, or actors) to influence an actor’s behavior by giving him additional goals or by modifying his emotional state.
Using this model, each character’s emotional state and current goals drive the selection of a specific behavior from a large set of possible behaviors. The intensity of the appropriate emotion values is then used to determine the intensity of the expression of the behavior. The description of the behavior may be embellished with adverbs or modifying phrases based on additional emotional state, providing “color” to the text. Even when performing simple actions, a character’s hidden emotional state may “leak out”. The internal emotional states and displayed behaviors form a feedback loop: one character’s display may poke the affectors of another character.
Thus, the way in which a character attempts to accomplish his goals may be influenced by his own emotions and those of the other characters. Due to the complexity of the emotional state of the char-acters, the sub-plot twists are unpredictable. The author can control the overall plot coherence and pace through the goals inserted at plot-critical times.
A Wider Domain for Discourse
In most interactive fiction products, characters are treated as objects. Most interactions with other characters are limited to making imperative statements to them (giving commands). True interaction with characters is impossible in these worlds because the representation of the world is void of any “interactive media”. You cannot talk with them because there is nothing to talk about. In worlds containing only objects, the only topic of discourse is the “object economy” (physical objects that may be manipulated). In order to produce interaction on more human terms, a system must have (1) a rich representation for emotions, knowledge, and beliefs (an “emotion economy” and an “information economy”, terms coined by Crawford); (2) a rich set of behaviors that are driven by these new economies; and (3) a rich grammar for communication of knowledge, events, beliefs, and emotions. These subsystems must be fully integrated with each other. One would not want to design-in emotions that cannot influence behavior, or that cannot be expressed using the input grammar.
To support the economy of knowledge and beliefs, a rich knowledge database must be constructed. It must contain both static initial data (the state of the world’s knowledge before the start of the game), and dynamic data on events or information flow as the game proceeds. Each character should have pointers into this database to reflect the state of his own knowledge and beliefs. This database may be inconsistent, as some characters may hold beliefs that contradict the knowledge or beliefs of others.
At the center of any Artificial Personality system is an emulation of human emotions. Besides providing new motivation for believable behavior, emotions give the characters a new domain for discourse. They may interact on the levels of physical state, information state, and emotional state.
In designing an interactive story, the designer must keep in mind the interlocking dimensions of physical state, emotions, character beliefs, behavior, and communication. One must also keep sight of the vision: characters displaying believable original behavior and engaging in interesting, dramatic interaction.
References
All three PhD dissertations may be obtained from University Microfilms, (800) 521-0600, at about $50 each. Look up “Poetics” in your library.
Brenda Laurel: “Towards the Design of a Computer-based Interative Fantasy System” (1986). Defines the vision and the technologies requred to implement it. Read this first.
James Meehan, “The Metanovel: Writing Stories by Computer” (1976). An AI classic, with implementation details.
Mary Ann Buckles, “Interactive Fiction: The Computer Storygae ’Adventure’” (1985). Has its moments, even though the game is a decade old.
Michael Lebowitz, “Creating Characters in a Story-Telling Universe” Poetics, 13, 171-194. (1984)
_________________________________________________________________________________________________________
A Mickey Mouse Approach to Game Design
Jeff Johannigman
[Jeff has worked at many of the major publishers and now runs Sorcerer’s Apprentice, an entertainment software development house. He is also a member of the Computer Game Developer’s Conference committee.]
“Here you leave today, and enter the world of yesterday, tomorrow, and fantasy.”
— inscription above the entrance to Disneyland.
Disneyland is a multi-million dollar enterprise dedicated to interactive entertainment, to transporting thousands of people each day into fantasy worlds. While we game designers have been struggling with this goal for slightly over a decade, Disneyland has been doing it profitably for over a third of a century. In a recent trip there, I made a few observations on what has made Disneyland the success it is, and how we can apply it to our craft.
First and foremost, Disneyland is dedicated to recreating the fantasies of the mass population. Here, people get to live in the future, travel to the wild west, take a jungle cruise, and meet their favorite storybook characters. Every attraction at Disneyland is built with one question in mind, “What do people dream of doing?”
In designing games, start with the same basic question. I call it “The Disneyland Test”. Namely, were technology not a limit, would this game be a popular attraction at Disneyland? If so, I think it stands a good chance of becoming a hit product.
Let’s test this theory against some hit games. Chuck Yeager’s AFT, Falcon, Flight Simulator, Skyfox, and several other flying games qualify; indeed, most amusement park thrill rides, especially roller coasters, are designed to give people the sensation of flight. Microprose’s Pirates is already in Disneyland, as “The Pirates of the Caribbean”. So are submarine hits like Gato and Silent Service (Submarine Voyage), space games like Starflight and Star Raiders (Star Tours, Mission to Mars), and driving games like Test Drive (Autopia).
Stretching the technology, most sports games pass the test. Uncounted armchair athletes would eagerly buy “E” tickets to go one-on-one with Dr. J or Larry Bird, especially if they could win. They also dream of “going for the gold” in the Summer and Winter Games, or playing Hardball in the big leagues. However, we may have to wait for Star Trek’s holodeck technology before we could install these at Disneyland.
But take a look at some misses as well, software that failed to capture the buying public’s imagination. The classic example is a program many game designers have called the best computer game ever written: M.U.L.E. While M.U.L.E. is very addictive, has an intuitive interface, and years of replayability, it lacks the kind of fantasy that most people dream of participating in. It is also difficult to imagine Little Computer People, Timothy Leary’s Mind Mirror, Ports of Call or Trust & Betrayal becoming Disneyland attractions.
Disneyland builds many of its attractions around already established creations. Indeed, the Disney empire was founded on characters from storybook tradition: Snow White, Pinnochio, Cinderella, Sleeping Beauty, Peter Pan, Alice in Wonderland, etc. Disneyland guests seem generally more eager to see an attraction built around Michael Jackson or Star Wars than one created from scratch, such as Thunder Ranch.
Admittedly, many computer games based on licenses have become dismal failures. Such failures have usually been caused by relying on the license alone, while producing a mediocre game (E.T., Transformers), or by pre-buying a license that flopped (Howard the Duck, Willow). However, using a license or famous figure as a hook for a good game has produced Julius Erving and Larry Bird Go One on One, Ghostbusters, and Chuck Yeager’s Advanced Flight Trainer. Even my G.I. Joe game is still selling well, and it’s almost four years old.
What is important is that Disney does not stop with just a good concept. The name Disney has become synonymous with quality and attention to detail in implementation. Every facet of Disneyland is designed to convince the guest of the completeness of the fantasy world.
While waiting in line for Star Tours, I wondered what had cost more time and money: the ride itself, or the lobby I stood in. I was surrounded by alien flight controllers, droids doing repair work, and huge screens hyping tour packages to scenic Tatooine and Dagobah. Alien passengers were being paged in their own languages, and the driver of a speeder with license “THX-1138” was informed that he was in a “No Hover” zone. By the time I boarded the actual ride, I was convinced that I was in a real starport.
Throughout the park, it appears that almost every different attraction has clothing tailored specifically for its “cast members”. Even the trash cans are designed to blend into the background of each different area. For instance, Frontierland’s trash cans look like tree trunks.
Entertainment software should show the same completeness. Remember that a game does not exist solely on the disk; the entire package must be designed to convince the user of the fantasy. Open a copy of Ultima IV. It comes with an ancient-looking cloth map, imprinted with a runic alphabet. The user manuals, “The History of Brittania, as told by Kyle the Younger” and “The Book of Mystic Wisdom, as told by Philpop the Weary”, are written as mystic tomes and printed on parchment-like paper. Indeed, by just opening a box, I have begun my venture to Brittania.
One of the most common mistakes made in creating computer games is placing the cart before the horse — namely, developing some whiz-bang technology and then saying, “Can we make a game out of this?” In the history of Disneyland, there have also been occasions when the technology, not the fantasy, begat an attraction. “Great Moments with Mr. Lincoln” was designed as a showcase for a new technology called “Audio-Animatronics”. At its unveiling in 1965, in spite of its mechanical miracles, it was ridiculed by the press as “the winkin’, blinkin’ Lincoln”. Mr. Lincoln has been playing to nearly empty houses ever since. People began lining up only when Audio-Animatronics was applied as a means to create such fantasies as “The Pirates of the Caribbean” and “The Haunted Mansion”.
On my way out of the park, I saw several cast members stopping guests to ask what they liked and disliked about their visit. Customer feedback is very important to Disney. The story is told that Walt Disney forbade the landscapers from fencing in the lawns until he first saw where the guests wanted to go. If they often cut across a particular grass area then he read it as a sign that sidewalks needed to be poured in that section.
The intuitive interface and satisfying play of Ozark Softscape’s games can be attributed to the same strategy. Dan Bunten recruits dozens of different playtesters at every stage of game development. He sits them down at the computer, watches them play, listens to their reactions, refines the game, and repeats the process over and over again. It shows in the end result.
Exciting fantasies, familiar concepts, completeness, attention to detail, and listening to the customer have all helped make Disneyland the success it is today. We can strive for those same goals, and perhaps reach the same heights. After all, Walt started with just one mouse.
_______________________________________________________________________________________________________
A Warning for Developers
I have received a disturbing report suggesting that we have some security problems with at least one major publisher. It seems that a software developer sent a working version of his game to four publishers, all majors, looking to make a deal. This was a good program and he had no problem finding a publisher. However, some time later, but before the product was released to the public, the sample version of the game that he had sent to the publishers appeared on CompuServe and on several pirate boards. He asked each of the suspect publishers to investigate, but none ever bothered to respond.There is no doubt that the breach of security was in one of the publishers, as the developer had maintained tight security. We can only conclude that one of the publishers has failed to institute proper security procedures. Prudent developers will tag their software with internal labels that will enable identification of parties leaking software to pirates. If anybody has solid information on this problem, please relay it to me.
_______________________________________________________________________________________________________
How to Get a Game Published, One Publisher's View
Ken Williams
President, Sierra On-Line
Every week dozens of software products and game ideas are submitted to Sierra On-Line and every week dozens of “We are sorry to inform you that. . .” letters go out. In the last five years, Sierra has accepted only one product submitted by an outside developer. Why? Are we too picky or is the quality of the products submitted really that low?
I’ve yet to meet a successful software publisher who isn’t constantly seeking to add to their product line. I visit software retailers every week and have done so for many years. My first question is always the same: “What are your newest and hottest games?” Except around Christmas time, I rarely hear about a hot new game. In general, the answer always appears to be, “Nothing’s come out for awhile.” Hundreds of new games ship every year, but only a handful (perhaps 15 to 20 games), really have hit potential. This industry is a long way from being glutted with high quality product. The publishers want it and the retailers want it. So what’s the problem?
There seems to be a belief among developers that it’s hard to get a game published. As a publisher, I don’t see it that way. Software publishers want to publish product just as much as you want them to. There are only two questions a software publisher asks before accepting or rejecting your product: “Does it fit my product line?” and “How many copies do I think I can sell?” If the answer to these questions is “yes” and “over 100,000,” respectively, your product will be published. Otherwise, expect a letter that begins, “We are sorry to inform you that...”
Before submitting your product to a publisher, give some thought to whether or not the product even fits the publisher’s product line. Visit a software store, such as Egghead, Software Etc., Electronic Boutique or Babbages. Study the products on their shelves. Pick a set of publishers who seem to be publishing your kind of product and are strong on the machine on which your product runs. Make sure the cover letter accompanying your submission explains why your product perfectly complements their product line.
Strangely enough (and contradicting what I previously said), you shouldn’t always assume that publishers will remain within their established markets. The one product we acquired from an outside developer was the 3-D Helicopter Simulator. Those who know Sierra’s products recognize this to be a radical departure for a company known primarily for adventure games. 3-D Helicopter Simulator was, and continues to be, a major hit for us and opened a whole new category of revenue to us. I had been looking for a way to expand into this category for years, but needed just the right product. Joe Wofford sent his submission at just the right time and both of us have profited greatly from the result. So, I guess the moral to this story is that there’s not a heck of a lot you can do personally to answer the publisher’s first question: “Does it fit my product line?” When in doubt, submit your product and let the publisher decide.
On to the publisher’s second question: “How many copies will the product sell?” There are two factors that determine the marketability of a product: design and execution. Learn to design great products and to execute them well and you will own the world. Publishers will beg you to let them publish your products. You will be able to buy a new car and start feeding your dog the high-priced dog food. Unfortunately, this is easier said than done.
First, I’ll tackle design. In fact, I’ll split design in half and look at each half independently. Design has two elements: what I call “curb appeal” and playability.
As unique and as great as your product may be, it will wind up in a box sitting on a shelf next to hundreds of similar products. Every week I spend hours standing in software retail stores studying how software is bought. I don’t have any dummies among my competitors; every box on every shelf looks great and has well-written box copy. What a product needs is some feature(s) that make it uniquely appealing. This is what I call “curb appeal.” The product has to sell itself to the potential customer without the box being opened. This can take the form of the product concerning a high profile topic, e.g., Police Quest (designed by a real policeman) or Leisure Suit Larry in the Land of the Lounge Lizards (even the name makes you laugh). The screen shots on the back of the box need to convey a sense of excitement and depth that makes people want to buy the product. Many times I have been told by a potential author, “Just wait until you play it, you’ll love it!” If I have to wait until I play it to love it, I most likely don’t want to publish it.
Playability is the second component of design. Sometimes a product can sound great in concept, but then be boring when you sit down to play it. The most important component of playability is depth. Depth in a game means always surprising the player. Never over-estimate the attention span of most gamers. Make sure each level is truly unique, not just more aliens coming faster. At Sierra, we try to think of our products as interactive movies. We put in depth by making sure that each character you encounter has a complete, unique personality. We add interesting subplots that the player can explore. This concept can apply to other game genres as well. If you’re doing a fantasy role-playing game, think about ways to add depth to the game. The characters should have personalities and the monsters should behave like monsters. Killing monsters and gathering treasure is an important element of the game, but it can’t be everything.
The most important thing in creating computer games is execution. I have seen more successful products with great execution and poor design than the other way around. Simply put, this means great graphics and great sound, although it also extends to hundreds of little details, such as the method the player uses to interact with the game and even to the font used in messages. Many publishers believe they can work with an author who has a great concept for a game (lots of curb appeal) and has polished it well, even though it might lack depth of play.
Execution can also take the form of taking full advantage of the machine the product is running on. Several computers, notably the Amiga, have special graphics hardware. Computer owners get very excited when you show off their hardware. One publisher earns a living by selling games that are unsurpassed in execution, containing speech and magnificent graphics, but are (in my opinion) of poor playability. You just can’t lose when you execute a game well.
So, what do you do if you believe you have a well-designed game with great execution that isn’t getting the attention it deserves? There is nothing like a face-to-face meeting. Call the publisher and ask for the president of the company. If you get his/her secretary, ask who examines software submissions. Quite often products are submitted to multiple publishers for consideration. Many of the products that I’ve rejected have gone on to become the industry’s biggest hits because a competitor of mine had the patience to work with an author. Claim you’re going to be in town anyway to show the game to a competitor and, before you sign the contract, you want to make certain they in fact aren’t interested. We all live in fear of losing products to competitors; if you sound convincing you’ll get your meeting. If you can’t get a personal meeting, send a one-page letter explaining the product along with some color slides or photos from the game. Call the publisher a week later to see what he thought.
To summarize, software publishers are desperate for product. Your product must be able to be sold based on the back of the box alone. The product’s design is important, but how well the product is executed is the single most important item.
The software industry has expanded and matured a great deal since I wrote my first game in 1979. At that time, I did the programming and my wife Roberta did the design and art. We didn’t bother with music. We started our company for approximately $1,200. I’m not sure this is possible today; the rules seem to be changing every year. One thing I am absolutely positive of: the state of the art in gaming is improving every year. Each year more quality and depth from a game is required for it to be competitive.
Product development for games is evolving from an individual enterprise to a team effort. While we still see some great games done by individuals, as time marches on games developed by a programmer working alone will become less and less competitive.
I’ve become a bit of a cynic in my old age (33 years old and 15 of those years spent in software). I am convinced that the days of game development happening at home are numbered. A finished product contains great design, professional quality art and a professional score. Ninety-nine percent of the products I see do not contain good art, music, sound effects or programming. Creativity alone is hard to stick in a box and market.
I believe that the entertainment software industry is now competitive enough that development budgets have exceeded what the average person ican afford. For instance, over $300,000 has been spent on direct costs of King’s Quest IV, and that’s in addition to $3 million in underlying technology.
Most of the major entertainment software companies have development support groups for working with inside and outside developers. For instance, we have a group of people whose only job is to write run-time environments for various computers and to develop device drivers for the never-ending stream of new add-on cards. We also have a large group of artists and animators, plus an on-staff composer.
Sierra does use some freelance designers and developers who work closely with our internal support staffs to develop a product. However, the designers we use are people we’ve been working with for years. I’m not sure how someone gets to be a game designer here — no one new has managed it in years.
This all brings us to a “Catch-22.” I’m convinced that budgets for best-selling entertainment products will rival those for major motion pictures within a few years. No one person working alone will be able to generate the industry’s next big hit. You feel that you’re the next Spielberg of this industry, yet publishers want to see you do something great before they’ll give you the support you need in order to do something great in the first place.
This is something I foresee as an industry problem and not something unique to Sierra. The simplest solution is to team up with other professionals before you start your game. Recognize up front that developing a game is a major effort. Good luck!
_______________________________________________________________________________________________________
Real Life in a Box or, How to Design and Implement a Computer Vehicle Simulator
Gordon Walton, John Polasek, and Karen Hunter — Digital Illusions, Inc.
[Part One of this series appeared in Volume 1, Number 8.]
Introduction
This is the second of a three-part series of articles describing how to design and implement a computer vehicle Ssmulator. In this segment we will cover how to move objects in your “world” and how to display objects in a 3-dimensional perspective. The final portion of this article will cover enemy and friendly “Intelligence” and Testing.
Moving objects in the world
Moving objects within your “world” is really quite simple, providing that you ignore any altitude and/or depth changes. To move an object you must know its present position in game coordinates, heading, speed and the current delta time since the last update of the object’s position. In addition, you will need sine and cosine routines.
In our last article, we created a 2-dimensional map, in which coordinates are expressed as a combination of “pixel coordinates” and “within-the-pixel coordinates”. We will therefore calculate the new position as follows:
theObjects.withinX = theObjects.withinX + theObjects.speed * deltaTime * Cosine(theObjects.heading);
theObjects.withinY = theObjects.withinY + theObjects.speed * deltaTime * Sine(theObjects.heading);
Now that we have updated the “within pixel” we must check for valid ranges, which will indicate if we have crossed a pixel boundary. Given that each pixel (i.e. the pixels in the bitmap that represent our 2-dimensional map of our world) is 16,384 units square, we do this as follows:
if ( theObjects.withinY < 0)
{
theObjects.withinY = theObjects.withinY - 16,384;
theObjects.pixelY = theObjects.pixelY - 1;
}
if ( theObjects.withinX < 0)
{
theObjects.withinX = theObjects.withinX - 16,384;
theObjects.pixelX = theObjects.pixelX - 1;
}
if ( theObjects.withinY >= 16,384)
{
theObjects.withinY = theObjects.withinY - 16,384;
theObjects.pixelY = theObjects.pixelY + 1;
}
if ( theObjects.withinX >= 16,384)
{
theObjects.withinX = theObjects.withinX - 16,384;
theObjects.pixelX = theObjects.pixelX + 1;
}
Of course we would have to do this for each object active within the simulation, including the object we are commanding. To improve the speed of the simulation, you can create integer Sine and Cosine routines.
We will also need the distance and heading to each object, in relationship to our current location. To get these values, we use the following technique:
First get the X and Y differences from your object to the object you are processing.
YDiff = ( theObjects.Y - YourObjectY ) + ((theObjects.MapPixelY - YourObjectMapPixelY ) * 16,384);
XDiff = ( theObjects.X - YourObjectX ) + (( theObjects.MapPixelX - YourObjectMapPixelX ) * 16,384);
theObjects.HeadingToYou = FindHeading( YDiff , XDiff );
theObjects.DistanceToYou = FindDist ( YDiff , XDiff ,theObjects.HeadingToYou );
Using these techniques, you can move objects around within your 2-dimensional map.
Drawing in 3D perspective
To translate our 2-dmensional locations into a 3-dimensional view we need to determine the following items:
1) The width of our view port in degrees and pixels
2) The height of our view port in degrees and pixels
3) The height of the horizon line from the bottom of the screen in pixels
For our purposes we will have a square viewing area, 60 x 60 degrees and 128 x 128 pixels. We will also have the horizon line centered in the view at 64 pixels from the bottom of the view port.
To determine an object’s 3-dimensional position within the view port, we need the following information:
1) The absolute angle we are facing
2) The heading from us to the object. (theObjects.HeadingToYou)
3) The distance from us to the object. (theObjects.DistanceToYou)
First we take the angle from us to the object, subtract the angle we are facing, then convert it to + or - 180 degrees as shown below:
AngleDiff = ViewAngle-theObjects.HeadingToYou;
while ( AngleDiff >= 360 )
AngleDiff = AngleDiff - 360;
while ( AngleDiff < -360 )
AngleDiff = AngleDiff + 360;
Since our view port is 60 degrees wide, we will only see objects that are + or - 30 degrees from the center. Since an object may be fairly large and overlap the window even though the center of the object is outside the window, we will draw all objects which are + or - 45 degrees. To determine the pixel location of the center of the object, we take the half the size of the screen in pixels, 64 pixels in our case, multiply it by the angle, then divide it by 30 degrees to get the location from the center of the screen in the horizontal axis.
if ( abs( AngleDiff ) < 45 )
{
XCenterLoc = 64 + (( AngleDiff * 64 ) / 30);
}
After testing to ensure the midpoint is within our acceptable range, we need to determine how far off the horizon the object will appear. We can either do this using a linear scale (i.e. each vertical pixel will represent a specific distance, or a sliding scale where vertical pixels closer to the horizon represent larger distances and those closer to the top and bottom of the window represent smaller distances). We will use a sliding scale as it represents our actual depth perception more accurately.
If the distance is greater than 16,384 units we will consider the object as being on the horizon. The next 4 pixels, will represent from 12,288 to 16,383 units (or 1 pixel for each 1,024 units). The next 8 pixels will represent from 8,192 to 12,287 units (or 1 pixel for each 512 units). The next 16 pixels will represent from 4,096 to 8,191 units (or 1 pixel for each 256 units). The remaining 32 pixels will represent from 0 to 4,095 units (or 1 pixel for each 128 units). We will not let objects go lower than 60 units, accounting for the final 4 pixels. In addition, we can use this scale for objects not on the water, such as planes, only they will be this amount above the water. A code example of this is:
if ( theObjects.DistanceToYou >= 16,384 )
{
YCenterLoc = Horizon;
}
else if ( theObjects.DistanceToYou >= 12,288 )
{
YCenterLoc = Horizon + ( theObjects.DistanceToYou / 1024 );
}
if ( theObjects.DistanceToYou >= 8,192 )
{
YCenterLoc = Horizon + 4 + ( theObjects.DistanceToYou / 512 ) ;
}
if ( theObjects.DistanceToYou >= 4096)
{
YCenterLoc = Horizon + 12 + ( theObjects.DistanceToYou / 256 );
}
else
{
/* this object is < 4096 units from you */
YCenterLoc = Horizon + 28 + ( theObjects.DistanceToYou /128 );
}
Should this scaling not feel correct, we can easily make changes to the ratios and break points.
Now we can draw the object, which may either be a scaled bitmap or a series of scaled polygons, and consider XCenterLoc to be the center point of the object horizontally on the screen, and YCenterLoc the base of the object on the screen.
Summary
By using these techniques, you can move objects around within the world defined by your 2-dimensional map. You can also take these objects’ locations, relative to your vehicle, and draw a 3-dimensional representation of the other vehicles out of a 2-dimensional view port. In the next and final section of this article, we will cover the use of computerized rules for the enemy and friendly vehicles and how to effectively test your application.