Table of Contents
Editorial: A Successful First Year
Chris Crawford
Culture Hacking
Brenda Laurel
Real Life in a Box
Gordon Walton et al.
The Conversion Malaise
Mark Baldwin
Graphic Realism
Kellyn Beeck
Scribes Versus Authors
Chris Crawford
Endpage: Triumph and Failure
Chris Crawford
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), or via modem. No payments are made for articles. Authors are hereby notified that their submissions may be reprinted in Computer Gaming World.
Copyright The contents of this Journal are copyright © Chris Crawford 1988.
_________________________________________________________________________________________________________
Editorial: A Successful First Year
Chris Crawford
This issue marks the end of the first subscription year of the Journal of Computer Game Design. When I undertook to create this Journal, my greatest concern was that it would fail from lack of interest. My fears were unfounded; the Journal has been a great success in almost every way.
Impact
Subscriptions were the first concern. I set a goal of 100 paid subscriptions by the end of the first year. The actual count right now is 166 paid subscriptions. There are also 57 free subscriptions sent to publishers, members of the press, influential people, and special cases. This was accomplished with no formal advertising; the Journal’s reputation has spread primarily through word of mouth.
More important than the raw numbers are the identities of the people reading the Journal. With a few striking exceptions, all the top game designers subscribe to the JCGD. It is read at every major publisher and most of the minor ones. It is also read at many of the magazines that cover the industry. I am confident that these freebie subscriptions that go to publishers and press are indeed read, partially because publishers often comment on the Journal when I encounter them, and partially because almost every single such subscription goes to a person who went out of his way to request it from me.
Finances
Another concern was financial; I had no desire to make a profit on the effort, but my wife insisted that we would not lose money on it. The financial state of the Journal is excellent. My direct cost to fulfill a single subscription comes to about $10.00. By charging $30.00 per subscription, it would seem that I make a tidy profit. In truth, there are a number of other costs. I spent a chunk of money getting the Journal off the ground, sending free issues to everybody on my mailing list for the first two issues. There are also the free subscriptions that must be paid for. There was the symposium in April that was paid for by JCGD money. The JCGD is also bankrolling the Game Developers’ Conference in September, and a BBS (more on this later). There was one perk for me — I used JCGD money to buy the laser printer on which the JCGD is prepared. Even with all this, the Journal is well in the black.
Editorial Content
This has been the one undeniable weakness of the Journal. I have had great difficulty wringing articles out of people. Many promised articles have failed to materialize. At no time have I ever been able to kill an article submission because I had something better. I have printed almost everything I have received. This will continue to be a problem in the future. As always, I entreat you to submit an article!
Broader Goals
I did not create the JCGD merely to reach a lot of important people, or to make money. The broadest goal of the Journal is to foster the development of the art of computer game design. That lofty goal requires far more than can be accomplished with 16 pages of material every other month. Hence I am using the Journal as a springboard for a variety of other activities. The first step was the Game Design Symposium held in April at my home. The second step is the Computer Game Developers’s Conference scheduled for September 18/19. The third step is the creation of a bulletin board system for subscribers.
The JCGD BBS
This is a service that will be available only to subscribers of the JCGD. This Journal is, sadly, not an interactive medium of expression. Its formal style demands some talent for writing from its authors, a demand that has, I’m sure, discouraged submissions. Its infrequent publishing schedule robs it of immediacy. And it is certainly not the venue for shop talk, idle gossip, or other fun communications. It therefore seems that a BBS dedicated to the needs of computer game designers would be the perfect compliment to the JCGD.
The JCGD BBS will go into operation on October 1. A committee of public-spirited volunteers has been working at it for two months, developing the concept and fine-tuning the software. Sean Barger has performed yeoman’s service getting the software in shape. The JCGD paid for the equipment, and although we’re still having some teething problems, we’ll be ready for you. Those who resubscribe to the JCGD will receive (eventually) a password and instructions for how to log on to the JCGD BBS. It’s a service that comes as part of your subscription.
Sales Pitch
So where do you fit into all this? I want five things from you.
First, I want you to resubscribe. Every single subscription to this Journal expires with this issue. If you are a regular subscriber, your mailing label will have the magic words, “Expires 8/88” on it. If you are a freebie subscriber, your mailing label will say “Expires 9/99”. In either case, you must resubscribe or you will be dropped from the mailing list. If you are a regular subscriber, then you must send me a check for $30.00, payable to The Journal of Computer Game Design. If you are a freebie subscriber, then you must send me a letter or postcard saying, “Yes, I want to continue receiving the Journal.”
Second, I want you to sell the Journal to your business acquaintances. There remain some stubborn holdouts who refuse to subscribe. It’s important that the Journal be read by everybody in this industry. I ask that, during the month of August, you ask each professional colleague you encounter, “Do you subscribe to the JCGD?” If they don’t, tell ’em that they’d better, give them the address, and leave it at that.
Third, I want you to come to the Game Developer’s Conference in September. It now appears that the conference will be a big success. As of July 23rd, we have received 45 paid registrations and have confirmed some 20 speakers. We project from this that the conference will have about 125 attendees. Be warned, though, that if attendance exceeds 200 we may have to turn away late registrants. So send in your registration soon! Registrations postmarked before September 1 cost $125 without a room, $250 with a room for two nights. If your registration is postmarked after September 1, both prices are $25 higher. Make your check payable to The Journal of Computer Game Design.
Fourth, I want you to participate in the JCGD BBS. Log on frequently, read what other people have to say, and put in your two cents’ worth.
And lastly, I WANT YOU TO SUBMIT ARTICLES FOR PUBLICATION!
_________________________________________________________________________________________________________
The 1988 JCGD Publishers Awards
If you are a paid subscriber, you found included with this issue a ballot for the 1988 JCGD Publishers Awards. These awards will be presented at the Computer Game Developer’s Conference. The award categories are:
Most Innovative Publisher
Best QA Department
Best Technical Support
Best Producer/Editor
Best Publisher
We ask you to fill out the ballot and mail it back to us. Note that you must sign the ballot; unsigned ballots will be discarded. Rest assured, however, that the ballots will be seen only by the members of the conference committee, and will remain confidential.
_________________________________________________________________________________________________________
Culture Hacking
Brenda Laurel
[Brenda Laurel is on the fifth of an unknown number of lives in the computer software business. She is currently acting as a techno-yenta for Epyx and editing a book, Inventing the Interface , with support from Apple.]
I was remembering the other day what it used to feel like to be in the computer software biz. When Joe Miller first showed me a computer late one night in 1976, I had the major conversion experience of my young life. There were virtual playthings straight out of some crazy hacker’s mind roiling around on the screen, opening a portal to a vast new terrain of imagination.
My first thoughts were theatrical—I animated Goldilocks , lip-synched Hangman , made little fishies swim across the screen. My second thoughts were political. In 1980 at Atari I was installed in an office with no desk and a telephone on the floor in the embryonic Home Computer Division, with a charter to plan and design a line of learning games for kids. I met Crawford and we alternately argued and rhapsodized about the potential for cultural and political change that was embodied in this bold new medium. Chris tackled the energy crisis with Energy Czar and nuclear power with SCRAM , games that were so playable that nobody called them educational (hence sparing their lives). I designed a line of learning products that never saw the light of day and ended up managing the software marketing group instead, muttering in the dead of night and secretly writing papers for educational journals on subjects like the role of ethics in simulations. When HCD began to come apart I found a new savior in Alan Kay, with whom I began my interactive fantasy research.
As time and politics marched on, it became clear that the learning software business was hopelessly polluted by the drill-and-practice drek that poured out of and into the educational establishment. When I met Jim Levy at Activision and heard him talk about the potential of learning products in the home market with an evangelical glint in his eye, I was already tired and skeptical. I gave it a shot anyway, bringing up a line of learning products that was exterminated the moment Levy lost control. There were no math games in that batch, but stuff about tornadoes and dreaming, poetry and utopia.
But learning doesn’t sell.
Never mind that our whole brains are wired to do it with a passion from the day our little light bulbs turn on in the womb. Never mind that kids will learn acres of useless trivia to defeat little dwarves with axes. Never mind that almost everyone is dismayed by nearly every aspect of the world situation and aware on some nightmare level that the solutions to our problems will not come from the breed of dimwitted ad-men that we know as politicians.
It’s getting so that I know the scenario by heart. Somebody who’s still idealistic gets into a position of power in a software company and decides to inject a little life force back into the business. People start talking and discover that they still have those haunting fantasies of interactive experiences that have the power to change minds and hearts. Brainstorming sessions are held, developers are evangelized, and maybe even products are built. But somehow, they never get out the door.
There are multiple endings to the scenario. There’s the IT WON’T SELL ending, which is usually acted out in a marketing off-site or during the post-mortem of a focus test. There’s the IT’S TOO HARD ending, where grand ideas are trivialized out of existence in cop-out products. There’s even the S/HE GOT FIRED ending where the champion is kicked out and the little orphaned ideas wander off into the night.
But the worst ending is the FAILURE OF VISION ending. That’s where we all just sort of forget about it. Nobody’s done it right and so it can’t be done; nobody will buy it and so it can’t be sold; people don’t care and so it’s no use trying to make them.
Hackers are change agents. At Hackers 3.0 last year, the Hacker Philosophy was articulated once again: We hack to gain access, we hack to have power, we hack because we sense that computer technology as we know it is somehow not feeding us as individuals, citizens, souls. Hackers still smell like hope to me.
And it seems such a simple step to move from hacking one’s own experience with the technology to hacking the culture of which it is a part. To dance instead of sneak. To lead instead of serve. To empower more than oneself.
Reality has always been too small for human imagination. The impulse to create virtual interactive worlds is only the most recent manifestation of the age-old desire to make our imaginings palpable—our insatiable need to exercise our creativity, judgment, and spirit in worlds, situations, and personae that are different from those of our everday lives. When a person considers how to design a building or fly to the moon, imagination serves as a laboratory for virtual experiments in physics or mathematics or engineering. In matters of justice, philosophy, or art, imagination is the laboratory of the spirit.
Hackers are the creators and guardians of a world where imagination has a new kind of power. How you shape the means and ends of technology can change the world.
Thinking about it that way might make the computer game business a lot more interesting. a
_________________________________________________________________________________________________________
Thoughts on the Holodeck
Chris CrawfordA fascinating aspect of the television show Star Trek, The Next Generation is a technology called “the holodeck”. This is a large room with futuristic projectors that can create fully animated 3-dimensional images. The entire arrangement is operated by a computer of breathtaking power. The user of the holodeck, before entering, tells the computer what type of environment the user wishes to exper-ience. The computer then creates and projects the environment.The holodeck was not particularly interesting at first. The show’s writers presented it as primarily an environment simulator, a place where trees, birds, and babbling brooks could soothe the tired space traveller. But midway into the season, something changed, and the holodeck took on a new life. In so doing, it offers we game designers much food for thought.The most striking thing about the new holodeck is its emphasis on characters. Yes, there are still exotic places and things, but they now function more as backdrops. The emphasis is on the characters created by the computer. In one episode we see Captain Picard going back to Paris to confront an old flame. In another, Commander Reiker creates and romances a sultry woman in a New Orleans jazz bar. And one episode is built almost entirely around the holodeck. Picard and friends travel to 1930’s San Francisco to play out a pulp detective story populated by an entire cast of exotic characters.This transformation — from environment simulator to character generator — is profoundly satisfying to me. I have always maintained that characters were the key to the future of computer games, and this seems to buttress my beliefs. It seems perfectly natural and reasonable that this is the way that adults in the future will entertain themselves. It certainly makes more sense than the thought of Captain Picard playing Space Invaders.
_________________________________________________________________________________________________________
Real Life in a Box
or
How to Design and Implement a Computer Vehicle Simulator
Gordon Walton, John Polasek, and Karen Hunter of Digital Illusions, Inc.
Part 1 - Design Goals and Mapping
Introduction
Simulators are one of the most popular areas of computer gaming. The ability of the computer to simulate a reality you would never otherwise experience is truly astounding. Flight Simulator™, probably the most successful game product to date, is a vehicle simulator. Our company has focused primarily on non-flight, war vehicle simulators.
In this series of articles, we plan to take you through the process of creating a vehicle simulator, demonstrating both the algorithms involved and the design methodology underlying the product. Our focus will be on the implementation process, as the specific design issues are closely tied to the topic of the simulation. We are presenting this as a 3-part series of articles subtitled 1) Design Goals and Mapping, 2) Moving Objects & 3-Dimensional Perspective and finally 3) Enemy & Friendly Intelligence and Testing.
Design Goals
Design Goals can be broken up into two main categories. First we have our “look & feel” or experiential design goals, then our interface design goals. We will cover our “look & feel” goals in depth, since it is the key element of the product, while the interface is just the means to our experiential end.
Our primary “look & feel” design goal is to give the player an entertaining experience that is as close to the perceived reality of the experience being simulated. For example, if we were doing a WWII Submarine simulator we want to reactivate the images planted in our players’ minds by movies such as Run Silent, Run Deep or Das Boot. If we can create an effect which is reminiscent of the terror of being depth charged, the thrill of a great torpedo shot, or the cleverness of a night attack, the primary design goal will be met. Note that the players perception is more important to the design than actual reality. True verisimilitude is desirable but secondary to perceived verisimilitude. We also want to provide sufficient depth to keep the player coming back for more. In our designs we always shoot for a minimum of 100 hours of play value, (i.e. a player would have to invest at least 100 hours to exhaust the available options/ missions/ scenarios). Finally, we want the product to grow with the player, unfolding more in-depth/realistic experiences as his/her proficiency with the product improves.
Our primary interface goal is to make the product as intuitive on the particular target machine as possible. The ideal interface would be completely intuitive and thus not be an impediment to the playing of the product. This means that for a mouse-based computer, all primary controls should cue the player visually and should be operated by the mouse. Keyboard commands should only be used for shortcuts (i.e., in addition to the mouse control) or for advanced features which are not a part of moment to moment play. For keyboard-based computers, mnemonics should be used wherever possible to make the learning of the primary control keys as intuitive as possible (e.g., use the “T” key to shoot a torpedo). After ensuring that our interface matches the target computer, we order our controls and indicators according to frequency of use. Frequently utilized options and those most important to the enjoyment for the player receive priority in screen size and placement. Next, we decide how much detail to provide versus how complex the product will be to operate. Finally, consistency within the interface is important. For example, the RETURN, ESCAPE, and other special keys should be used in the same way throughout the program.
Implementation
Our steps in designing and implementing a vehicle simulator are as follows:
1) Choose the Topic and Context
2) Define the Geography
3) Implement the Map view(s)
4) Simulation for all Vehicle Movement
5) Implement the 3-Dimensional View(s)
6) Create all Mission Scenarios
7) Create all Enemy Intelligence
8) Playtest
9) Finish & Ship It
1) Choose the Topic and Context
Our first step is to choose a topic (i.e. vehicle to simulate). For the purposes of this article, we will call our topic a “Nuclear Submarine Simulator”, though the underlying process could be applied to any vehicle simulator. This will be an American Los Angeles class nuclear attack submarine simulator. In addition, we will limit our operations to the North Atlantic operating out of Scotland and the U.S., and have most of the action take place in GIUK Gap (Greenland-Iceland-United Kingdom Gap) and have the time be 1989. We would now watch all the movies and read as much about the topic as is available to discover the key elements of the control of and missions of such a vehicle. Also, if possible get at least one technical guru involved. This technical expert should be someone with significant technical knowledge of the weapon system and/or an actual (retired) commander.
2) Define the Geography
1. What is the maximum area we can represent? Specifically, how far can the actor/vehicle travel realistically within the game based on fuel, time, natural barriers or a combination of all these?
2. What is the minimum area we can represent?
3. Now strike a balance between the maximum and the minimum, using rules to prevent the actor/vehicle from leaving the mapped area.
Since a modern nuclear submarine can travel around the world without refueling or surfacing, we will limit the area to the North Atlantic and have all our missions/scenarios take place completely within this area. Since we are using the North Atlantic as an operations area, we can limit our map to the area:
75° N to 30° N
82° W to 13° E
This area is approximately 10,500 km wide by 9,000 km high
Note that this is arbitrary and done so that we will not have to keep the entire world map in memory or on our diskette. Our rule for preventing the player from leaving the mapped area will be simple. The mission/scenario orders will be specific, and if the player attempts to leave the mapped area we will have the Executive Officer relieve the player of command (per the appropriate Navy Regulation) and end the game at that point.
3) Implement the Map view(s)
So now we have our gross geography, now we have to decide how to represent this in the computer using the following methodology:
Choose a basic unit of measure based on minimum speed and minimum time rate. Minimum unit of measure is related to minimum time rate and minimum speed of travel. (i.e. if the minimum time rate is 2 seconds each game cycle will represent at least 2 seconds and our minimum speed is 2 knots, then our units must be approximately 5.87 feet in size so that all movement is recorded, regardless of speed and time rate settings, calculated by 6017.2 ft / 3600 seconds x 2 seconds x 2 knots = 6.69)
Map representation
a) Maps can be represented easily by creating a bitmap where each pixel or byte represents a given square area. The size of this area is chosen based on the level of detail desired and the amount of disk and memory storage available.
If our minimum unit size is 6.69 feet, we could arbitrarily choose our pixel or byte size to be approximately 6000 meters on a side.
To simplify our calculations, we could say that each pixel or byte is 16,384 of our minimum unit ( 6.69 feet * 16,384 = 109608.96 feet ≈ 33725.83 meters)
b) If single pixels are used, the map will be flat (i.e. have no elevations). If a full byte is used for each square we can now have 256 distinct elevations or terrain types for each square within the map.
c) If the map is for a naval only product, it is much simpler to use a flat map technique, doing water depth as a function of distance from land, particularly since terrain may not be a factor (ships and subs cannot drive on land and most of the ocean is too deep for a sub to dive to the bottom). For our illustration the flat map is what we will utilize.
d) If the map is for a land-based product, elevation and terrain information will probably be needed, so a byte-oriented map should be used.
e) Elevations can be directly related to the byte value (i.e. 0=sea level, 1=10 feet above, 2=20 feet above...) or related on a sliding scale using an array where the map byte is an index (i.e. 0=sea level, 1=15 feet above, 2=50 feet above, 3=70 feet above...). For a naval product we could indicate both the depth and water conditions using these bits.
f) To represent the area we choose above, our map will require 312 (width) x 267 (height) pixels. This is calculated by taking our width and height of the total map in kilometers and dividing it by our number of kilometers per pixel (i.e. 10,500 kilometers divided by 33.72583 kilometers yields 311.33 which we make 312 to include slightly more information, but makes it divisible by a factor of 8)
This gives us a bitmap with 352 x 267 or 93,984 pixels. Since each byte can contain 8 pixels in a flat map we divide the number of pixels by 8 to give us our map size in bytes which is 11,748.
To get this map into the computer we would use a paint package (probably on Macintosh since it is a flat map with white being water and black being land) and an appropriate scale map and enter it point by point. This is a time-consuming and onerous process, but you only have to do it once for all computer versions of the product.
We will now be able to take this flat map and display it at various zoom levels in either absolute mode or relative to any position within the map. At the higher levels, where great distances are shown on the screen map window, simple squares or pixels can be used to display the land on the map, while at the lower or more detailed levels of the map, we may substitute fractalized polygons to represent a land pixel.
Concluding Remarks
At this point you should have some idea of how to start the design of a computer-based vehicle simulator. In the next article we will show how to move vehicles around in our world and then how to draw them from a given 3-Dimensional perspective (including the design issues involved).
_________________________________________________________________________________________________________
The Conversion Malaise
Mark Baldwin
[Mark is the author of Empire and Star Fleet II.]
There is a malaise out there, one which is destroying our industry and art yet no one seems at all concerned about it. Since I need an example to catch your attention, I’m going to use Chris as my scapegoat to describe the malaise (aren’t you lucky Chris?).
A couple of years ago, Chris designed a nice wargame for the Macintosh called Patton Vs Rommel It’s a tactical game of Patton’s breakout from Normandy during WWII. It has some innovative ideas in game and interface design. From what I’ve seen of the Mac version, a great deal of time was spent on design of the interface between the game (computer) and the game player (myself). I don’t know what the numbers are exactly, but I would assume that half the man hours put into Patton Vs Rommel were in interface design. That is all well and good, but I don’t happen to own a Mac. I currently own 5 computers, and somehow I just can’t justify forking out my scarce cash for a sixth. However, there appeared on the market an IBM version of the game which I snatched up immediately.
I took this latest work of art from Chris Crawford and booted it up on my IBM box. As soon as the title screen came up, I saw a nice little arrow in the middle of the picture with a button box labelled ‘Start’. Now let me point out to you that the only permissible action from this screen is selection of the ‘Start’ button. If I had been driving a Mac, an Amiga or a ST, it would have taken me no effort and less time to select the ‘Start’ button and get on with the game. However, this was not a Mac, it was not an Amiga and it was not a ST. It was an IBM without a mouse. It took me nearly a minute and many different keystrokes to take the only action possible from that screen. Even after I got the hang of maneuvering the game mouse, it still took me at least 2 seconds, and at minimum two keys to tell the computer the only piece of information it was capable of accepting. THIS IS A USER FRIENDLY INTERFACE?
What I ended up buying was a Macintosh game on a non-Macintosh computer. This same sickness pervaded the entire game. It made what was a joy to play on a Mac, a pain to play on an IBM (and I do mean physical pain, my fingers kill me after a game of Patton Vs Rommel). For what Chris probably spent hundreds of creative hours developing on the Mac, zero hours were spent on the IBM.
Now that I’m done criticizing a potentially great product, I’ll get to my point. For all the great artistic achieve-ments being produced in the computer world, many if not most are being corrupted in conversion to machines other than the one for which the product was originally designed. Patton Vs Rommel is not the exception, it’s more the rule. Time after time, conversions for excellent products are released with second rate interface and second rate quality control. At least in the case of IBM Patton Vs Rommel, the game is bug-free — many conversions can’t even claim that much.
One of the most important aspects of computer software design is how the software interacts with the user and how the user interacts with the software. This is not a small matter, and it requires both technical and artistic skill to develop this interface. I would guess on average, half the time spent on development of a good product is in the interface. However, whether we like it or not, a large portion of the interface is machine dependent. Each machine has its strengths and weaknesses. The port artist must redesign the interface to take best advantage of the target machine’s strengths while somehow sidestepping its weaknesses. The strengths and weaknesses express themselves in three major areas:
The first and most obvious is the hardware. The standard Macintosh displays in black and white while an Amiga displays in color. Therefore, a piece of software moving to the Amiga has a whole new dimension of communication available which was not available on the Mac. However, at the same time, there may be a loss of screen resolution. Both the gain and the loss must be addressed if the software is going to communicate. Likewise, a piece of software from a 48K machine should not carry the limitations forced upon the software due to memory restriction and speed when moving to a faster 500K machine. I’ve seen software that continually accesses a disk when the entire disk could have been loaded into memory with space to spare.
The second difference lies in the operating system. Back in the old days, there weren’t such animals (or at least we could ignore them). But operating systems have become larger, more complex, and, most importantly, apparent to the user. As such, the converter must recognize the system interface for the machine and adapt to it. If he ignores it and uses his/her own, or the system interface from another machine, he is likely to confuse the user. Also, as in the case of Patton Vs Rommel, he could actually produce a bad interface. I’ve seen many conversions that junk the operating system to make things easier for the programmer.
The final difference is how the users expect software to react. Standards of communication develop for each machine that go beyond the interface enforced by the operating system. For example, both the Amiga and Atari ST operating systems support buttons and menus. However, buttons are more common in Amiga software, while menus are more readily accepted by ST users. This is a subtle, subjective difference, but the converter must have a feel for the audience of the target machine to understand and adapt to these subtleties.
Strategies
The poor quality of port work is a great malaise in our industry. I am seeing works of art destroyed in the process of conversion from machine to machine. How do we stop this? Each of us has a role to play:
Software developers: These are your creative babies. Do not wash your hands of them once you deliver them to your publisher. Insist on the right to control and approve any conversions of your work. My own solution has been to set up my own software conversion house and insure that I have first right to convert any of my own works.
Converters: These are idiosyncratic products. You cannot set up a turn-the-crank operation to convert entertainment software. It requires artistic skill and a good feel for the interface of the target machine to maintain the quality in the original work.
Publishers: Make sure there is a good line of communication between the converter and the original author. Select converters who will redesign the work for the target machine. A conversion demands artistic skills just as the original work did. There is no such thing as a good turn-the-crank conversion house.
Consumers: Do not assume that a converted product has maintained the quality of the original work. Look for review of the work on your own machine. Learn which publishers maintain their quality and which do not. If you do get burned, let the publisher know your dissatisfaction by long and bulky letters written with brightly color pens.
All right, now that I’ve said my piece, you can write long nasty letters to me by USPS at ‘7711 S Curtice Way #E, Littleton Colorado 80120’; Genie at ‘MB’ or CIS at ‘73637,3032’. I will even read the ones written with brightly colored pens!
_________________________________________________________________________________________________________
Graphic Realism
Kellyn Beeck
[Kellyn is the designer of Defender of the Crown and Rocket Rangers.]
What is the role of graphics in computer game design? More than once, I’ve heard publishers repeat the axiom “graphics sell games.” The longer and more accurate version of this time-honored software principle might be worded a little differently: “great graphics can move products off the shelf, but great depth and complexity will give them staying power.” Because of their stunning graphics (or even sound effects), many products have achieved spectacular short-term success, then disappeared after only a few months on the market. Nobody missed them. They were boring games. Unfortunately, this has happened often enough in the short history of the entertainment software industry that we have come to associate pretty graphics with shallow, uninteresting games.
Further strengthening this perception is the fact that games with the greatest depth frequently have the least attractive graphics. The limited capabilities of most home computers have made it almost impossible to do both things well, and committing additional development time and computing power to graphics usually compromises the quality of the game. Not surprisingly, many software developers have come to view graphics enhancement as an expensive frill which adds little to a game’s intrinsic merit. But the improving graphics capabilities of personal computers are making it both possible and desirable to design complex, interesting games with graphic realism.
Widening Your Audience
The first and most obvious reason to devote precious time and money to graphics — and the one we hear most often — is to reach a wider audience. Yes, good-looking graphics do help sell computer games. If you could upgrade the graphics without compromising your game’s depth or complexity (or your ability to pay the rent), the heightened prospects of commercial success would be incentive enough to make the commitment to graphic realism. Unfortunately, in the real world it’s hard to spend time and money on graphics without making sacrifices somewhere. But graphic realism will expand the audience for computer games.
Computer games are an entertainment medium, and as such, compete with motion pictures and television for the public’s attention. Years of exposure to the mass media have trained people to expect the technical quality that is characteristic of film and video. But the visual images in computer games are not yet able to deliver that level of quality, and they fail to be as compelling as the imagery in movies and television. To the vast majority of the American public the computer is a Foreign Object, partly because the things people see on a computer screen look nothing like Mel Gibson, R2D2 and Alf. Most people would probably prefer to watch a great movie and play a great computer game. People care about their favorite actor, actresses and aliens — but they find it harder to develop emotional attachments for a bunch of blocky pixels.
For the present, the imagery of computer games still falls short of Star Wars, but it’s catching up. Technology is narrowing the gap. The improving graphics and expanded memory of home computers are making it possible to incorporate dramatic, realistic images into games without sacrificing game play. But how does graphic realism improve a computer game? And how do you incor-porate graphics into games in useful ways?
Filters
The field of interpersonal commun-ications offers potential insight in an intriguing concept called “filtering”. In any act of communication, the sender’s message passes through one or more “filters” before it reaches the receiver. Filters can include the message’s emotional content, the listener’s state of mind, the skill with which the message is delivered, or even language barriers. By the time it has passed through these filters, the message’s intent may not equal its impact. The concept or picture in the speaker’s mind is altered by the filters and reaches the listener in diluted form.
Let’s say someone walks up to you on the street and asks you for money to feed children who are starving in Africa. The speaker has seen photographs of these children. He pictures those photographs in his mind and tries to describe their plight as best he can. Perhaps he even draws a sketch to show you how skinny and undernourished these children are. You form a picture in your mind, but it doesn’t match the picture in his mind. The impact of the message would have been greater if he had shown you the heart-rending photographs. The message would reach you without going through the filter.
In much the same way, the computer screen is a filter between you and your audience. When you design a game, you determine the nature of that filter. During the course of your game, the program constantly is sending messages to the player about events that are taking place. How good is the filter? Here is an example. In Defender of the Crown your character’s face is shown on the screen after every turn of play, and his expression changes to reflect events in the game — after losing in battle, he looks dirty, disheveled and mean; after the love scene, he is grinning from ear to ear. His expression changes according to the value of a variable called SOUL. It would have been easier to display the value of SOUL numerically, or use words like “happy” or “dejected”. But the expression on the knight’s face grabs the player’s emotions more directly The message reaches its audience with far greater impact.
Process Intensity
If you spend too much time and effort trying to achieve graphic realism, you risk overlooking one of the most crucial aspects of good design: “process intensity”. This topic has been explored in previous issues of the JCGD, and is at the heart of every computer game. For an excellent discussion, see Chris Crawford’s essay in the February issue. Process intensity is defined there as “the degree to which a program emphasizes processes instead of data.” A process-intensive game is one which spends a lot of time crunching numbers; examples include flight simulators and computer chess games. Data-intensive games are more likely to spend their time moving graphics data around — arcade games with plenty of animation are a good example.
The tradeoffs between process and data intensity can pose tough design problems. Poor graphics and animation can damage a game’s potential for success as surely as it can suffer from a lack of process intensity. We want a game to look good, but isn’t it more important to give it depth, balance and play value? An ongoing debate among game designers revolves around the question, “How should we divide our resources between game play and graphics in designing games?”
In an ideal world, your game would have an environment (and a budget) large enough to fulfill both considerations adequately. But let’s say your resources of time, money and computing power allow only a limited commitment to graphics development. You don’t want to throw your pictures at the game indiscriminately, just for the sake of having them. It is easy to throw attractive art into a game for show, but difficult to use non-interactive graphics in a way that enhances a game. What are some of the useful ways to incorporate artwork into a game?
Make Them Comfortable
To begin with, try thinking of the computer screen as a TV set. That’s what it looks like to people, and people’s expectations are disappointed when they don’t see TV-quality graphic realism on a television monitor. Even when it’s connected to a computer. Give people familiar images to look at. Beautiful images. Things of beauty make people feel good, and we want more people to feel comfortable when they look at computers. Personal computers have existed for over ten years, but only about one out of every ten households in America has a computer.
Opening and Closing Scenes
Graphics can be used in the opening sequence of a game to create emotional buildup. You can set the scene of your game by telling a story that creates anticipation for the action that follows. At the beginning of Defender of the Crown, I used a series of realistic scenes to establish the story of the king’s death, tell of the outbreak of war between the Normans and Saxons, and then bring in Robin Hood to charge the player with reuniting the kingdom. In Rocket Ranger, I created emotional buildup in the opening sequence of the game with a series of documentary-style scenes depicting the Nazi onslaught in Europe. Graphic realism can be a powerful storytelling tool.
Establishing Shots
As the term itself suggests, establishing shots help establish an image of your game’s settings in the player’s mind. Show closeups of the characters, display scene-setting images, help the player imagine the world of the game as vividly as you imagine it. Defender of the Crown uses dramatic closeups of people and panoramic long shots of settings to create color and texture, a sense of place and atmosphere.
Selection screens are a form of establishing shot. When the player is selecting game components — characters, vehicles, countries, etc. — show detailed pictures of the people or objects. This can make them seem real in the player’s mind. Graphic realism in selection screens gives the player a strong mental image of key objects or characters, and the image will remain in his mind when he views the smaller scale animation that follows in the game itself.
Love Scenes, Hate Scenes
Graphics can also be used to make the player care about the characters in your game. You may wish to use one of the staples of motion pictures — the love scene. Can you imagine a better way to involve the player emotionally? Another Hollywood trick is the use of imagery that makes you hate the villain, often in a movie’s opening scene. Filmmakers hook your emotions by making you watch the bad guy kill an innocent, defenseless victim in technicolor. The use of graphic realism as a storytelling vehicle can make players love your good guys and hate your bad guys.
Suspension of Disbelief
Finally, the use of realistic-looking images aids in suspension of disbelief. The more realistic the image, the more people who will be able to suspend disbelief and be drawn into your game (and we need more people to be drawn into computer games). The spaceships in Star Wars are much more convincing than the flying saucers in sci-fi movies of the 50’s. Few people would have been able to suspend disbelief if Luke Skywalker was flying around in a frisbee suspended from a fishing pole. But graphic realism can make people believe in almost anything.
Conclusion
Graphic realism is a goal worth achieving in computer games. If you can add graphics that will improve the impact of your message, make your audience care more about the setting and characters, or help attract a larger audience to the world of your game, then the expenditure of time and money is worth considering.
_________________________________________________________________________________________________________
Scribes Versus Authors
Chris Crawford
At first glance, scribes and authors appear to be similar. They are both writers; each one sits at a table and writes things on paper. But there is a profound difference between the two. A scribe puts words down on paper; an author puts ideas down on paper. The scribe’s energies are directed towards the technology with which he works. The scribe worries about the craft of writing: the pen strokes that form the letters, the arrangement of words on the page, and so forth. The author lives in the world of ideas. The author creates, develops, organizes, expresses, and writes ideas. The author worries little about the quality of his scribery. Mark Twain’s penmanship is almost unreadable, yet he is generally regarded as the greatest American author. Thus, while both workers produce writing as the concrete result of their efforts, they concentrate on very different things.
I use the terms “scribe” and “author” as ideals rather than realities, as poles on a spectrum rather than discrete categories into which I place people. Throughout history, most writers were some mixture of the two. There was a statistical distribution of writers, lopsided toward the scribe end of the scale.
A similar situation exists with program-mers. The population of programmers occupies a spectrum with scribery at one extreme and authorship at the other extreme. As with writers, this distribution is lopsided towards the scribery end of the scale. In other words, most programmers are more concerned with the technology than with the ideas. They take greater pride in memorizing technical aracana than expressing profound ideas.
In the early days of the computer games industry, the scribes reigned supreme. The first successful games platform, the Atari 2600 VCS, was a weak machine needing a strong programmer. With 128 bytes of RAM and 2K bytes of ROM, there wasn’t much resource for programming. Worse, the display was written to the screen by software rather than hardware, meaning that the program had to change graphics register in real time, just in front of the electron beam scanning across the television screen. Thus, impressive graphics displays required program timings that were excruciatingly tight. The programmers who could make the VCS display interesting things were a special breed, intensely involved in the technology, scribes through and through. The tight-ness of the programming environment left little room for authorship. All the brilliant ideas in the world were of no value in an environment that afforded little opportunity to express those ideas. Authors held no status in the games community of 1980; scribes dominated.
All that has changed in just eight years. The most lucrative target machine is now an IBM PC clone with 512K of RAM, a 16-bit 8088 running at 5 MHz, and 330K of disk capacity. This machine is about two orders of magnitude more powerful than the Atari 2600.
The greater power of this environment has changed the priorities of the community. No longer is it necessary to sweat bricks just to get a decent display on the screen; it is now almost easy to get good graphics up. In fact, the days when designers would gasp at the graphics stunts created by their competitors are over. Any graphic trick produced by a given designer can probably be replicated by almost any other competent designer. The phrase “graphics guru” is seldom heard these days.
Similarly, the emphasis on tightness of coding has almost disappeared. I still remember the great pride I felt over the tightness of the coding of Eastern Front (1941). Here was an entire wargame that fit into 16K of space! Perhaps my proudest achievement was the code that changed the color of the trees with the passage of the seasons, from bright green in spring to green in summer to red in fall and brown in winter. The entire feature, code plus data, cost me sixteen bytes of space. Those were the days.
Today, however, I just don’t give a damn about how much space I use. My last project, Trust & Betrayal, marked a major milestone in my career: it was the first game in which I failed to use all the RAM available to me. I targeted the game for 512K of RAM, and when it was all done, it only consumed about 380K. In my current project, I treat RAM the way Genghis Khan treated prisoners. Instead of painstakingly writing one subroutine to cleverly handle 25 different but related situations, I just set up a huge CASE-statement with 25 instances. Why bother?
The same logic applies to execution time. I once knew the timing requirements of every instruction in the 6502 instruction set — by heart. I knew all sorts of great tricks for shuffling stuff around the index registers to obtain extra speed. Nowadays, I have one simple trick that always works: if it runs too slowly, precompute the results and stuff them into a huge table. Why bother?
In just eight years I have seen my scribish skills lose their power. Once I could impress the ignorant natives with a few simple tricks, a flashlight or a box of matches. Now the damn natives have VCRs and ghetto blasters; my tricks don’t get me very far.
We’ve seen the effects of this change in the social makeup of our industry. Where are all the hot scribes of yesteryear? Whatever happened to Bob Bishop and Rick Maurer, Carol Shaw, Tod Frye, and so many others? The answer, sadly, is that these great scribes have been abandoned by the computer games industry (although they would say that it was they who abandoned it). However you see it, their skills are no longer needed by the industry, and they and the industry have parted ways. In the span of a decade, the scribe has gone from nerd to wizard to washed-up old tramp.
Authorial skills are now the talent that this industry prizes. The ability to create, develop, organize, and express a fun idea through the medium of the computer is rapidly becoming the dominant factor in the eyes of many publishers who must choose between competing proposals.
The process is not yet complete. We continue to see games hit the market that are clearly the work of scribes. More embarrassing, some of these games become great commercial successes! But the advances in hardware that have so dramatically changed the situation in just eight years are still at work. An IBM PC clone with 512K of RAM is not the last word in home computers. In eight more years, we’ll be working with 32-bit machines with megabytes of RAM. Talent in scribery will be even less important.
I recently met an aspiring young game designer bursting with talent and possessed of that lean and hungry look so indicative of future success. This woman has no training in computer programming; indeed, she has never taken a single college course in technical, scientific, or mathematical subjects. Just a few years ago I would have gently steered her away from computer games. But the times have changed. She has learned to program in HyperTalk. Sure, we all know that her HyperTalk scripts won’t be as fast as our high-performance C code. But if our hot stuff takes 1 millisecond to execute, and hers takes ten milliseconds, what difference will the user perceive? And if our elegant subroutine fits inside 1K of RAM, and hers needs 10K, what difference will that make on a one-megabyte machine? With each passing month, the machines get bigger and faster, and HyperTalk gets better, and my untrained, techno-wimp young friend grows more powerful.
Game designers, take heed. The times, they are a-changing. If you are a scribe, you’d better start changing, too.
_________________________________________________________________________________________________________
Endpage: Triumph and Failure
Chris Crawford
In my short career as a computer game designer, I have known both the dizzying heights of triumph and black pit of failure. Let me tell you about them.
Triumph is a social experience. It is something that other people heap upon you. There is, I know, a strictly solitary kind of triumph, the triumph that comes when you know that you have shaped something grand and great, and it doesn’t matter whether others even know about it. But that internal sense of triumph is always attenuated by the skepticism of one who knows the deceptive powers of one’s own ego. You can never be sure. Only when the triumph is thrust upon you by a mass of people can you take joy in its certainty.
When triumph does come, it is a powerful experience. People treat you with such adulation, such awe. They seem to treat you as if there were a gap between you and them, as if you are one of the Immortals and they are hardly worthy of your attention. For one possessed of so towering an ego as I am, this objective confirmation of my most extravagent private fantasies is heady stuff indeed.
But it is the excesses of triumph that give me cause to worry. People assume that, because I wrote Balance of Power, I must be blessed with omniscience. Programmers think that I am some kind of Macintosh guru, possessed of a super-natural understanding of this inscrutable machine. Academics think that I must have some special knowledge of geopolitical theory, some direct line to Truth. I have received offers to consult with specialists in the field of international relations. One reporter asked me to comment on a developing crisis in a foreign country.
The danger is that I might start to take these people seriously. In a reversal of the tale of the Emperor With No Clothes, I might begin to believe the image that all these people think they see. Like Ray Bradbury’s Martian-chameleon, I act like a Famous Person in front of user groups, like a Sagacious Mentor in the company of younger designers, or a Creative Genius in the presence of the press. And the dangers are all the greater because I want to believe these people, to be the unreal creature of their fantasies.
Failure is a lonely experience. People cluster close to you in triumph and avoid you in failure. They treat your failure with either accusatory silence or sympathies that only confirm the magnitude of the disaster. Left to yourself, you ponder the single question over and over: Why?
Failure is an eye whose penetrating stare cuts through every rationalization. No amount of explanation, no mature self-analysis can dispell the simple truth of failure. It stands like a monument to your unworthiness; nothing can topple it, nothing can cover it.
Failure rides with two companions, Cynicism and Bitterness. How many times have I cursed the obtuseness of the critics and the public for failing to recognize the beauty and nobility of Siboot? In my bitterness I have found blame in the public, the press, the critics, the publisher, the retailers — anybody and everybody associated with the game.
And I have found blame in myself, too. By failing, I have betrayed and discredited my own ideals. My best and finest effort has only served to reveal the bankruptcy of my most deeply held values.
Failure is a poison whose only antidote is a strong dose of egotism. Only powerful fantasies can overcome such bitter, undeniable reality. Fear not for me, friends — my egotism is certainly adequate to the task. Cherish and nurture your egotism, for it will protect your ideals from the icy fingers of failure.