Table of Contents
Editorial: The Software Awards Mess
Chris Crawford
Modem Games
Rob Fulop
An Alternative to Copy Protection
Jeff Johannigman
Process Intensity
Chris Crawford
Negotiating Notes
Steve Axelrod
Similarities with Other Media
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: The Software Awards Mess
Chris Crawford
This is the time of year for annual awards. The pundits gather their wits, their votes, and their courage, and they select the best products of 1987. There’s nothing intrinsically wrong with the idea; nowadays, so many products are released that an annual review of the best products provides needed perspective. Sadly, though, the execution falls short of the ideal.
Consider the annual awards of MacUser magazine. I noticed in their 1986 awards an apparent bias in favor of products that appeared late in the year. I therefore compiled data on the products that won awards and compared it with the review dates of those products. I then carried out a statistical test of the hypothe sis that awards are given with no regard for release date. The hypothesis was rejected at better than the .5% confidence level. For you non-statisticians, it means that the awards were grossly biased in favor of recently released products.
Then there is the awards system sponsored by the Software Publisher’s Association. The problem with the SPA awards arises from the fact that the software industry executives who vote for the awards don’t play many games themselves, and so they have no independent basis for making a decision. Determined publishers will send free copies of their games to every elector to jog their memories. It’s not quite the same thing as buying the election, but more than one publisher has mentioned to me the high cost of winning an SPA award.
I don’t mean to pick on MacUser or the SPA — they’re both solid organizations working to improve their systems. I could have picked apart any of the awards systems. These were the most convenient targets. My point is that none of the various awards can stand up to close inspection.
There is a fundamental reason why awards systems are such a mess: there are just too many games coming out each year for any one person to make a fair determination. Consider this: each year, several dozen games companies release several hundred games to the mar ketplace. It takes at least five hours of playtime to evaluate a game well enough to determine its worthiness for an award. It would therefore require nearly a full-time worker just to play all the games. Who’s got that kind of time to throw around?
The brutal truth is this: most of the people who cast votes for the “best game of the year” have played only a fraction of the hundreds of games out there. Few of them have spent much time with the games for which they vote. In short, it’s a crock. Most of the electors for the Academy Awards have seen the movies for which they vote. Most of the electors for book awards have read the books under consideration. Is it too much to ask the same for games? Apparently it is.
So what should we game designers do about it? We certainly should not institute our own system of awards. Let’s face it, we’re not much better equipped to select the best games of the year. We probably spend more time playing games than most people, but I doubt that any of us are catholic enough in our game-playing to do justice to an annual award.
So I suppose the best we can do is behave graciously when we hear that we have received an award (or, more pre cisely, our publisher has received the award), thank everybody in sight, take the plaque or doodad home, mount it on the wall, and forget about it. Lord help us all if we start taking these things seriously.
_________________________________________________________________________________________________________
Modem Games
Rob Fulop
[Rob has been a professional game designer for ten years now — he started at Atari in 1978. He has designed coin-op games, games for the Atari VCS, the Atari Home Computers, interactive video games, and telecommunications games for QuantumLink. He worked at Atari, helped found Imagic, and now runs his own company. He has seven published games to his credit.]
It was over two years ago that I decided to quit the conventional computer game business. It was driving me crazy. As I struggled to implement the elusive demands of publishers, i.e., “Make it easy to learn, difficult to master!” or, “Remember...simple, hot and deep!”, I realized that I wasn’t having any fun. After suffering through the endless civi lized battles with newly appointed Marketeers, I realized that nobody was making any money or having any fun!
At that point I left to pursue an idea I’d been kicking around since my days at Atari. I wanted to make entertainment software that people would access via their modems, personal computers and a telecommunications network. The concept was interesting, and the work would be challenging. I knew the idea was not completely original, we’ve all discussed it at length. However, I decided it was time for me to jump in and do it!
Well, I tested the waters, and they were just fine. Since founding Interactive Productions we have created several telecom products, including Rabbit Jack’s Casino for QuantumLink. We are now producing several other telecommunica tion entertainment products.
Rabbit Jack’s Casino has generated some enthusiastic responses from estab lished game designers, as well as new-comers to the industry. I have reviewed over 50 proposals for new online games in the last year alone. The problem with many of these proposals is that although the ideas are very clever, they often have little basis in reality. While the game may sound good, we know that it will be nearly impossible to produce. In this article and the ones that will follow, I hope to pass along some of the realities that have become apparent to us since we ventured into this new field.
Modem Game Environments
There are two basic environments for the modem game: direct connect and networked.
A direct connect game requires that an individual first know another player who also owns the game and has a modem. They arrange a time, call each other, and (if all goes well) establish a modem connec tion and play the game. A typical example of this type of game would be Battleship. It is my opinion that this environment is doomed due to the hassles involved in making all the arrangements to play it.
A better environment for the modem game is the network. A phone call to a 24-hour service offers a large supply of game partners, all ready, willing and able to play at a moment’s notice. This is the environment for which I prefer to design.
Economic Factors
Easy access is not the only benefit of the network game — there is a definite economic advantage for the player. The games industry is currently oriented around the outright purchase of game soft-ware. But purchasing a game is still an act of trust and hope. The player plunks down money and hopes for the best. He may love the game and play it over and over again, or he may play it once and hate it. Either way, he’s still out the purchase price of the game.
On the other hand, a network game such as Rabbit Jack’s Casino can be sampled for a minimal investment. Once a player has subscribed to a telecommunica-tion network like Quantum Link, he can play the game for 15 minutes and decide how he feels about it. The cost to him is about a dollar. If he loves the game, he can play for several hours a night, three nights a week, and his total cost for all that fun is still only about $20!
The other advantage of the network game is that sales are more directly tied to quality than to sales hype. Since game authors receive compensation for their work in direct proportion to the time people spend playing it, the entertainment quality is a careful consideration in the design stage. The result is a much more enjoyable experience for the players. It had better be, or we (the game designers) don’t make any money!
Categories of network modem games
Now let us examine the different categories of games and to what degree they can be successfully translated into a networked game. So far, most of the games I’ve considered, and the majority of the proposals I’ve received, fall into one of three categories, namely, Point-to-Point, Stand-Alone, and Multi-Player.
Point-to-Point
Games like Checkers, Chess and Battleship have been historically popular for a number of reasons. Mainly, the game design is complete. Of course, these games had time on their side. The precepts were continuously refined, evolving to accom-modate countless variations. The emergent set of rules displays an elegance that is obvious (although perhaps not fully understood) to the new player, and allows for a richness of interaction that has made them universal favorites.
Since this category of games already commands public interest, it is an important one and should not be ignored. Luckily these Point-to-Point games lend themselves well to being implemented on a network such as QuantumLink or CompuServe. They require very few system resources as the target PC’s do all the work (more on this later). The system computer merely provides a framework for finding opponents and transfers the information between terminals. And don’t forget, the service providers also handle customer service and billing — a very important point for the game author.
Stand-Alone
Another category of product is the Stand-Alone type of game. These games allow the player to call in for additional software or support. For example, a Stand-Alone version of Wizardry could be created such that it relied upon special data files to implement certain aspects of the game. These files could set up caverns or control characteristics of computer opponents. The player would play offline, with only occasional links to the central system in order to download the next level of play.
Software publishers are probably much more willing to explore these types of products since they do not require a modem to play the game. I expect there will be a number of these types of game products emerging from the major software publishers in the next few years.
Multi-Player
Multi-Player games typically involve utilizing the host computer to provide the framework and the system rules of a game. In a card game, for instance, this would mean dealing each hand and monitoring the interaction among players. A maze combat game, on the other hand, needs an overall maze and opponent generation algorithm, as well as system-wide scorekeeping.
Multi-Player modem games probably offer the greatest opportunity for innovation. The question you must ask yourself is, “What is a good game that can be played by as few as two people , or as many as 5,000?” It’s not an easy question to answer. Here is where I must remind you again that the old standards should not be written off.
One answer to the question posed above is as simple as the name itself: Bingo. This game, played online, with real prizes for the winners, and the opportunity to chat with fellow players at the same time, is addictive, and has been for decades. Designers can learn a lot from studying these games, from asking, “Why is this popular?”, and then using the computer to add unique value to a proven entertainment experience.
O.K., now I can just hear some of you whining “Bingo, is this guy kidding? I want to design a thousand player dungeon-quest game with infinite levels, and countless characters, and millions of...” Well you can try, and you may succeed, but you can also get yourself into something that is just too big to handle effectively.
Problems with modem game proposals
Most proposals I have read share a number of similar problems:
Design is too ambitious
A common problem with concepts from new developers is that the proposals are overly ambitious. This indus-try is young, so don’t try to overdo things on your first attempt. Make your first product simple! You should be able to explain the basic concept to someone in one sentence. This is especially important if you are trying to convince someone else to put up the money to make it.
Support issues are not addressed
How much support is needed to keep your game going on a daily basis.? We discovered the importance of this question early on. We were halfway through the design of a multi-player trivia type game when we hit a road block. It became apparent that the game would require hundreds of new questions each week in order to remain interesting. The cost of creating and maintaining this huge reserve of questions was prohibitive. Don’t make this mistake — it can be very frustrating and expensive! Think carefully about the support questions ahead of time.
No realistic budget is attached
Modem game products require longer development times than most computer games, especially in the alpha test phase. It is critical to have a realistic sense of what is actually involved in creating the product. Most of the proposals I’ve seen appear to be weakest in this area. I realize that preparing a budget isn’t the most thrilling of exercises, but the process of creating it will greatly improve your understanding of the scope of your project. It forces you to think through your design in a critical manner. You might discover some big gaps. You know, little things like allowing for the time needed to create the system-level programs!
_________________________________________________________________________________________________________
An Apology from the Editor
I’m sorry that this issue of the JCGD is late. On Wednesday, January13th, my DataFrame XP20 hard disk failed, taking with it all my files. I did have a backup, of course, and when I got a new disk drive, I was able to restore it from my floppy backups. Unfortunately, the backup program was not able to successfully restore four files. Three were unimportant; the fourth was the mailing list for the JCGD. Being a careful guy, I of course had a direct backup of such an important file. Don’t ask me how, but the direct backup, when restored to the hard disk, would not load properly in MicroSoft File. Curses! Of course, I’m a really careful guy, so I also had a hardcopy of the mailing list, and I also keep every subscription letter sent to me, so I was still able to create a new mailing list for the JCGD, by hand if necessary. Luckily for me, SuperMac was able to restore the data from my old hard disk and provide me with a restored subscription list, but not soon enough to allow me to make my February 1 deadline.
_________________________________________________________________________________________________________
An Alternative to Copy Protection
Jeff Johannigman
[Jeff published his first games with the Atari Program Exchange back in 1981. He has worked for Broderbund, Synapse, and Epyx, doing a variety of ports and original products. He is now an associate producer at Electronic Arts.]
How much of your potential income is lost to piracy? Estimates say that, for every copy of a game sold, two to ten copies are given away. More than once, I have run into somebody who said, “That was a great game you wrote”, but after my heartfelt thanks for the royalty income they provided, they sheepishly admitted, “Well, uh, I didn’t really buy it. Someone, uh, gave me a copy.”
Copy protection used to be a solution to this problem. That was back in the days when we understood Apple II+ drives better than your average teen hacker, and before there were commercial utilities like Fast Hack ’Em, Copy II Plus, and Marauder. The MS-DOS machines (today’s largest market for games) have widely incompatible drives; it’s impossible to create an effective copy-protection scheme that works on all clones. More users now own hard disks and wish to store their game libraries on them. Thus, conventional copy protection is less effec tive and more onerous to customers.
Some designers are trying an alterna tive — tying their programs to the packages they come in. The advantages of package-based theft protection are many:
+ It allows users to back up their disks, especially onto hard drives, so they feel less vulnerable about having a copy-protected disk crash on them.
+ It doesn’t require knowledge of obscure arcana about the way your machine’s disk drive operates, making the protection code easier to implement, hide, and encrypt.
+ It can be a creative extension to your game’s fantasy, giving the user the feeling that he’s gotten more for his money than just a disk.
I’d like to share with you some guidelines on how to incorporate package-based software theft protection (STP) into your games. Hopefully, your publisher can work with you to implement a cost-effective scheme into the packaging and slow down the rate of piracy.
Package-based STP plans should be set as early as possible. Give your publisher plenty of time to research, design, and implement the physical components needed. Most importantly, it is still early enough in the program design for the next consideration.
Package-based STP should be an intrinsic part of the game design. It should add to the fantasy of the game, instead of feeling tacked on. Good examples of this are the item cards in Robot Rascals, the cross-street reference and map in Amnesia, or the decoder wheel in Broderbund’s Captain Goodnight. A bad example is the STP of the type “what is the x-th word on the y-th line of page z of your manual?”; it adds nothing to the fantasy of the game or the perceived value of the package. However, even that obnoxious a form of STP is preferred to copy-protection by almost all consumers.
It should cost less than 50 cents per package. There’s no sense in buying a $500 lock to protect a $3 investment. This objective runs into direct conflict with the idea of using the STP to increase the perceived value of the overall package. However, the key word in that phrase is “perceived” value. Origin Systems spent a lot of money adding miniature tool kits to Auto Duel and laminated radiation badges to Ogre, but those trinkets had little practical usefulness, added only marginally to the fantasy, and were not needed at all for game play. Fold out maps, on the other hand, are nothing more than ink on paper.
Its information should be difficult to replicate. Pirates can easily disseminate text files of vital information via bulletin boards. Graphically based STP is more effective than text-based. Maps are preferable to code words, for instance. Remember: a picture is worth a thousand words.
It should make use of color, since it is more difficult to find color copiers than black & white. Non-repro blue is particularly effective, as is the use of colors with nearly identical grey levels. I have also heard of a scheme that uses the cellophane gels from 3-D glasses to view blue information printed in a jumbled red background.
It should be physically difficult to copy. Code wheels must be torn apart before you can make a xerox copy of one. Sheets larger than 8.5“ x 11” usually need to be copied in parts and taped together. Some manual bindings do not fold open on a flat surface.
Its implementation should be user-friendly, but should not give too much feedback. A good example of this is in the implementation of Starflight’s security wheel. If you give the wrong code once, it asks you to double-check. On the second time, it gives no further feedback. If we gave no feedback at all, legitimate but clumsy users would be offended when we erroneously branded them thieves. If we always gave feedback, patient pirates could guess until they got the answer the program wanted.
It should give illegitimate users encouragement to purchase the software. Let the user get a taste of the program, by placing the security check (or the results thereof) a few minutes into the game. Make certain that he knows why he can go no further. Otherwise, he’ll just get frustrated and bad-mouth the game itself.
Using Starflight again as an example, the user is asked to input a security code upon leaving spaceport. If the correct code is not given, the user is still allowed to leave port and begin exploration. However, after approximately 30 minutes of play, he is pulled over by the Inter-stellar Police on charges of software theft, and is “terminated” unless he can produce the proper security code from the wheel. The illegal user has gotten 30 minutes of enjoyment out of the program, is hooked, and knows he has to buy a copy to get any farther.
Make the program’s implementation of security checks as difficult for a pirate to crack as if it were copy protection. Encrypt message strings, have the routines leave “footprints” throughout memory, have other code checksum the security code, etc.. The Achilles’ heel of disk-based protection is that the pirate needs to look at just the parts of the program that access the disk drive, usually in the loader. Package-based STP code has no such weakness.
Now for some more concrete ideas:
Adventure games, mystery games, games with any sort of puzzle to solve: move clues offline and into packaging. Infocom has set a great example in the past. For example, Infocom’s Witness came with a matchbook with an important phone number in it and a fictitious newspaper with other clues.
Games involving movement over a large area: maps are useful, cheap, and colorful. Heart of Africa, ArcticFox, Ultima, Starflight, and Amnesia make good use of maps. Try to include some important element that requires the map. For example, let the headquarters of the Thieves’ Guild be unlabeled in the game, but marked on the map.
Games involving intrigue, espionage, and security as their themes: Decoder wheels fit the theme well. Games like Captain Goodnight and Starflight fit code wheels effectively and seamlessly into their design. Code wheels are difficult to replicate, easy to accomodate in the program, and inexpensive for a publisher to produce. Numbers on a code wheel can be generated by any bizarre formula you can imagine, so very little data needs to actually be stored in the program.
Games with lots of reference information: move some reference material offline. Even if it does not directly work as STP, it does add value and ease of use to the package. Sports games with player stats, wargames with unit information, and resource allocation games with price lists can benefit by having physical references nicely laid out at hand.
Others: think of what facets of the design AREN’T improved by being on a computer, and move them into the packaging. An upcoming Electronic Arts release, Wasteland, will have descriptive passages of text in the manual. When users get to certain points in the game, they will be told to “read paragraph 47”, for background and story information. Of course, that text could have been stored on disk and displayed, but putting it into the manual added STP value, eliminated virtually any limitation on the length of the prose, AND freed up disk space for more code and graphics data.
In short, the secret to doing effective package-based STP is to adopt a more global approach to your design. Just because we produce software doesn’t mean that everything of value has to be on the disk. Make it a complete package, with the software as the focal point. We are selling a fantasy, not just a bunch of bytes.
_________________________________________________________________________________________________________
An Opinion Poll on Copy Protection
If you are a subscriber, you received a self-addressed postcard with this issue. Please answer the following questions using this numerical rating system:1: Absolutely not.2: Probably not, weak disagreement 3: I’ll sit on the fence on this one.4: Probably so, weak agreement.5: Absolutely, strong agreement.For simplicity, I have worded them so that an anti-protection person will always enter high values, and a pro-protection person will always enter low values. These questions refer to conventional (disk-based) copy protection systems only, not the alternatives presented in Jeff’s article. A. Copy protection systems are easily broken by a variety of methods and commercial products. Nevertheless, they do stop some people from copying. Do you believe that conventional copy protec-tion is ineffective?B. Copy protection also imposes some inconveniences upon the user, making it difficult to make backups or to use the program from a hard disk. Do you believe that copy protection systems impose an unacceptably harsh penalty on the user? C. We would expect that, after all these years of preaching, users would have a greater sense of respect for our intellectual property and resist the temptation to steal our work if we removed copy protection. Do you believe that most users can now be trusted to refrain from pirating games?D. Putting it all together, do you believe that conventional copy protection is an undesirable practice that should not be continued?Please enter your responses on the postcard. Note the letter of the question and your response value. For example, a fence-sitter would enter these marks:A:3B: 3C: 3D: 3I will compile the results and report them in the next issue of the JCGD.
_________________________________________________________________________________________________________
Process Intensity
Chris Crawford
I have in previous issues of the JCGD referred to process intensity ; I propose in this essay to describe this most useful concept.
Process intensity is the degree to which a program emphasizes processes instead of data. All programs use a mix of process and data. Process is reflected in algorithms equations, and branches. Data is reflected in data tables, images, sounds, and text. A process-intensive program spends a lot of time crunching numbers; a data-intensive program spends a lot of time moving bytes around.
The difference between process and data is profound. Process is abstract where data is tangible. Data is direct, where process is indirect. The difference between data and process is the difference between numbers and equations, between facts and principles, between events and forces, between knowledge and ideas.
Processing data is the very essence of what a computer does. There are many technologies that can store data: magnetic tape, punched cards, punched tape, paper and ink, microfilm, microfiche, and optical disk, to name just a few. But there is only one technology that can process data: the computer. This is its single source of supe riority over the other technologies. Using the computer in a data-intensive mode wastes its greatest strength.
Because process intensity is so close to the essence of “computeriness”, it provides us with a useful criterion for eval uating the value of any piece of soft ware. That criterion is a vague quantifica tion of the desirability of process intensity. It uses the ratio of operations per datum, which I call the crunch per bit ratio. I intend here that an operation is any process applied to a datum, such as an addition, subtraction, logical operation, or a simple boolean inclusion or exclusion. A datum in this scheme can be a bit, a byte, a character, or a floating-point number; it is a small piece of information.
To demonstrate its utility, I shall apply this criterion to word processing software. Suppose that you are going to write a book on your word processor. Suppose further that you are omniscient in the subject matter of the book, impeccably organized, and a perfect typist. You simply sit down at the keyboard and start typing as you compose, making not a sin gle mistake. When you are finished, you will have misused your word processor, for you could have done the same thing on a typewriter. In short, the word processor had zero utility for this project. And what was the crunch per bit ratio? It was zero, because not a single word or character was actually crunched by the program. The words moved directly from your keyboard to the printer with no significant intervening processing.
Now suppose that you discover that your omniscience was less omni than you thought, and there are a few little mistakes that you need to clean up. You go back to the word processor, make a few minor changes, and print out the new manuscript. Now the word processor has a minor advantage over the typewriter, but not a stupendous advantage — you could probably have managed with a little cutting and pasting, and perhaps retyping a few pages. Note that the crunch per bit ratio has gone up from zero to a small value because you have manipulated some of the data in the file.
Now suppose that you are older and wiser and you realize that your manuscript is riddled with errors. You need to change the spellings of many words, you must completely reorganize the book and most of its chapters, and change its layout while you’re at it. You’ll be doing intensive reprocessing of the data as you move things around, execute massive global search and replacements, and in general crunch the hell out of your manuscript. Here we have a case of very high crunch per bit, and (not coincidentally) one in which the word processor shines its brightest.
The same analysis works with other applications. Spreadsheets show their greatest value when you recalculate the same data many times with many different variations. Database managers earn their price only when you have them sort, search, report on, and otherwise munch the data in many different ways.
The same is true with games: the higher the crunch per bit ratio, the more “computery” the game is and the more likely the game will be entertaining. Indeed, games in general boast the highest crunch per bit ratios in the computing world. Consider how little data a player enters into a flight simulator and how extensive are the computations that this data triggers.
The crunch per bit criterion also works well as an exposer of bad software ideas. For example, you old hands might recall the early days of the personal computing era and the ill-famed “checkbook balancing program”. This piece of soft ware was universally cited whenever anybody was boorish enough to question the value of personal computers. It wasn’t vaporware, either; there were lots of these checkbook balancing programs floating around. The thing was, nobody ever seemed to use them. Why not? Nobody seemed to be able to say just why, but they just weren’t practical. Let’s apply the notion of process intensity to the problem. These programs have a low crunch per bit ratio because they perform very little processing on each datum. Every number is either added to or subtracted from the checkbook balance, and that’s just about all. That’s one operation per datum — not very good.
The same reasoning works just as well against that other bugaboo from the early days: the kitchen recipe program. This was a piece of vaporware (actually, “bullshitware” would be a better cog nomen) frequently cited by husbands seeking to obtain their wives’ acquiescence to the purchase of one of these toys. It sounded great but in practice it never worked. Low process intensity was the reason.
We can even apply the process intensity principle to bad games. Does anybody remember that smash hit arcade game of summer 1983, Dragon’s Lair? This was the first videodisk game, and its glorious cartoon graphics created an instant sensation. The press rushed to write stories about this latest grand break through; consumers threw bushelfuls of quarters at the machines; and Atari franti cally initiated half a dozen videodisk game projects. Amid all the hubbub, one solitary figure stood unimpressed in his ivory tower, nose held high in contemptuous dismissal, disappointing reporters with comments that this was merely a fad. How was I able to correctly perceive that the videodisk game was doomed to failure once its fad value was exhausted? Simple: its crunch per bit ratio stank. All that data came roaring in off the disk and went straight on to the screen with barely a whisper of processing from the computer. The player’s actions did little more than select animation sequences from the disk. Not much processing there.
Objections to Process Intensity
The “process intensity principle” is grand in implications and global in sweep. Like any such all-encompassing notion, it is subject to a variety of minor-league objec tions and compromising truths.
Experienced programmers know that data can often be substituted for process. Many algorithms can be replaced by tables of data. This is a common trick for expending RAM to speed up processing. Because of this, many programmers see process and data as interchangeable. This misconception arises from applying low-level considerations to the higher levels of software design. Sure, you can cook up a table of sine values with little trouble — but can you imagine a table specifying every possible behavioral result in a complex game such as Balance of Power?
A more serious challenge comes from the evolution of personal computing tech nology. In the last ten years, we have moved from an eight-bit 6502 running at 1 MHz to a 16-bit 68000 running at 8 MHz. This represents about a hundredfold increase in processing power. At the same time, though, RAM sizes have increased from a typical 4 kilobytes of RAM to perhaps 4 megabytes of RAM — a thousandfold increase. Mass storage has increased from casettes holding, say, 4K, to hard disks holding 20 megabytes — a five thousandfold increase. Thus, data storage capacity is increasing faster than processing capacity. Under these circum stances, we would be foolish to fail to shift some of our emphasis to data intensity. But this consideration, while perfectly valid, is secondary in nature; it is a matter of adjustment rather than fundamental stance.
Then there is the arguement that process and data are both necessary to good computing. Proponents of this school note that an algorithm without data to crunch is useless; they therefore claim that a good program establishes a balance between process and data. While the arguement is fundamentally sound, it does not suggest anything about the proper mix between process and data. It merely establishes that some small amount of data is necessary. It does not in any way suggest that data deserves emphasis equal to that accorded to process.
The importance of process intensity does not mean that data has intrinsic nega tive value. Data endows a game with useful color and texture. An excessively process-intensive game will be so devoid of data that it will take on an almost mathematical feel. Consider, for example, this sequence of games: checkers - chess - Diplomacy - Balance of Power. As we move along this sequence, the amount of data about the world integrated into the game increases. Checkers is very pure, very clean; chess adds a little more data in the different capabilities of the pieces. Diplomacy brings in more data about the nature of military power and the geographical relationships in Europe. Balance of Power throws in a mountain of data about the world. Even though the absolute amount of data increases, the crunch per bit ratio remains high (perhaps it even increases) across this sequence. My point here is that data is not intrinsically evil; the amount of data can be increased if the amount of process is concomitantly raised.
The most powerful resistance to process intensity, though, is unstated. It is a mental laziness that afflicts all of us. Process intensity is so very hard to imple ment. Data intensity is easy to put into a program. Just get that artwork into a file and read it onto the screen; store that sound effect on the disk and pump it out to the speaker. There’s instant gratifica tion in these data-intensive approaches. It looks and sounds great immediately. Process intensity requires all those hours mucking around with equations. Because it’s so indirect, you’re never certain how it will behave. The results always look so primitive next to the data-intensive stuff. So we follow the path of least resistance right down to data intensity.
Conclusions
Process intensity is a powerful theoretical concept for designing all kinds of software, not just games. It is highly theoretical, and so it is difficult to under stand and implement, and there are numerous exceptions and compromising considerations that arise when applying the notion. Nevertheless, it remains a useful theoretical tool in game design.
_________________________________________________________________________________________________________
The Symposium is On!
The First Conference of Computer Game Designers will take place at my house near San Jose on Monday, April 11th, from 9:00 AM to 5:00 PM. There is still room for a few more attendees, so if you’re interested, please contact me. Those of you who committed to the symposium earlier should have gotten a confirmation from me by now; if you haven’t, please contact me immediately.
_________________________________________________________________________________________________________
Negotiating Notes
Steven Axelrod
[Steve has worked as a book agent for ten years, and as a software agent for five. As my agent, he has negotiated the contracts for Balance of Power, Patton Versus Rommel, and Trust & Betrayal.]
Copyright 1988 by Steven Axelrod
A complete treatise on negotiating would take up more space than is available in the Journal, so instead I shall offer assorted notes on negotiating with soft-ware publishers.
Even if you’re selling someone a finished product, always remember that at the end of the negotiation, you’re going to have to work with your opponent. Don’t push him so hard that he can’t bear to hear the sound of your voice. On the other hand, if you fail to defend your own interests in a firm but professional manner, not only will you end up with a unfavorable contract, but the publisher might well assume that you will be equally compliant on technical and editorial matters.
Don’t let the negotiating issues become personal crusades. Every point may well be important, but do all you can to keep your emotions out of it. If the publisher concedes a point, that doesn’t mean that he’s your friend. If they won’t give you something, don’t act as if you’re dealing with an enemy.
Professional negotiators are tremen-dously matter-of-fact about their work. The best ones are excellent actors, though, and can turn emotions on and off like a faucet to suit their needs.
You also always want to leave a little something — or at least the illusion of something — on the table at the end of the negotiation. No matter how careful you are there will always comes a point in the project’s life when you’re going to need a favor from your publisher. If you’ve drained them of every drop of blood in the deal-making phase, you’re leaving yourself defenseless when the inevitable happens.
The best deals are deals that work for both sides. Everyone’s in business and everyone needs to show a profit. No matter how great a deal looks at the outset, if you haven’t allowed your opponent a fair profit, don’t close it — it’s a bad deal. Bad deals are the ones that get broken, cancelled or re-negotiated. Remember what happened to VisiCalc? The developers were getting a royalty of 35% (if memory serves), which gave VisiCorp, the publisher, no breathing room. VisiCorp started to develop replacement products, VisiCalc sales started to suffer, everyone hired lawyers, sued each other, and Lotus came out of nowhere to eat everyone’s lunch.
Take scrupulous notes of every conversation. Don’t trust it to memory. Record every point discussed and every change in either side’s position. Knowing it’s all on paper allows you to focus your concentration of the negotiation itself. In addition, if your opponent knows you are keeping a careful record, he’ll frequently defer to you on disputed points later on.
Avoid lies, but to the greatest degree possible, avoid unpleasant truths, as well. If the publisher asks a direct question which you can’t answer truthfully without weakening your negotiating position, don’t answer it. Answer another question: try to discern the underlying issue that’s concerning him and speak to that. If asked, “Have you ever done work on the Amiga before?” the publisher’s real concern is probably whether you can bring this in on time and on budget. If you’ve never done a job on the Amiga, tell him about the analysis you did on the technical issues involved in the job, the portions of the program your staff can write using familiar programming tools, the consultants you plan to bring in to handle the work on the proprietary Amiga chips and your success on a past job that presented significantly greater technical complications. Dazzle him with your brilliance and professionalism; in the final analysis, that’s what you’re really selling and what he really wants to buy.
Practice negotiating every chance you get. It’s the only way you’ll ever get any better at it. Read all the negotiating books you can find (mostly they repeat themselves, but each one contains a few new tips). Sit in on other people’s negotiations and, with an objective eye, study the ebb and flow of the negotiation. Forget about what’s actually being bought or sold and watch how its being done, the technique (for better or worse) of each participant. Watch how people handle concessions or setbacks, when they back away from a contested issue or when they wait it out, how they re-raise an issue that’s already been shot down. You’ll learn the most from watching good negotiators, but there’s a lot to be learned by watching bad negotiators, as well.
Never talk when you have nothing to say. Nervous chatter might keep the conversation moving along, but it betrays your uncertainty or lack of confidence and you might accidently let slip information best kept to yourself. A professional negotiation isn’t like a teenage date. Long silences don’t mean you’re not cool; they just mean that you’ve stated your position and are waiting for a response.
If you’ve reached an impasse on a specific issue, put it aside and go on. Resolve all the issues that you can and then take a look at the problem issues and see if there are tradeoffs to be made to settle them. If issues still remain, get as much information as you can about the reasoning and business needs that underlie the issue. Is your request reasonable but against policy? Find out the history of the policy and the real purpose it serves. Is it possible to restate the policy or define it more narrowly so that everyone can live with it? Can the policy be changed and whose decision is that? Has the policy been waived in the past and under what circumstances? Explain what your needs are and ask how they can be met. Admittedly the publisher needs to protect himself, but he also must recognize your need to protect yourself. What can he suggest?
If all else fails, decide if you can live with the deal you’ve worked out. If you can’t, walk away. Don’t waste any more of your time or theirs. Never accept a deal you know you won’t be able to live with over the long run no matter how many short term needs it meets. Watching you walk away also sobers up the other side. They’ve invested a lot of time and emotion in the negotiations as well and the fear of losing it all might (just might) cause them to concede some crucial points to save the deal.
_________________________________________________________________________________________________________
Women’s Lib, circa 500 AD
“When he saw this, King Chilperic sent to ask for the hand of Galswinth, although he already had a number of wives. He promised to dismiss all the others, if only he were considered worthy of marrying a king’s daughter...Galswinth’s father believed what he said and sent his daughter to him with a large dowry. When she reached the court of King Chilperic, he welcomed her with great honor and made her his wife. He loved her very dearly, for she had brought a large dowry with her. A great quarrel soon ensued between them, because he also loved Fredegund, whom he had married before he married Galswinth...she never stopped complaining to the King about the insults which she had to endure. According to her, he showed no respect for her at all, and begged that she might be permitted to go back home, even if it meant leaving behind all the treasures she had brought with her. Chilperic did his best to pacify her with smooth excuses and by denying the truth as convincingly as he could. In the end he had her garroted by one of his servants.” —History of the Franks, by Gregory of Tours.
_________________________________________________________________________________________________________
Similarities with Other Media
Chris Crawford
The medium of the computer game is only a decade old. We have not yet figured out just how this medium works. Everything is still experimental. In our blundering attempts to understand the medium, we grasp at what is familiar and try to apply it to computer games. It is therefore useful to compare the computer game with the other media, seeking illumination from whatever analogies we can draw. In this essay I shall examine analogies with cinema and literature.
Cinema
The immature state of computer games makes a comparison with the movies a humiliating exercise. Who can forget the ghastly case of the Atari E.T. game, a game so bad that even its associa tion with a hit movie could not save it from becoming landfill? Any useful comparison between games and movies must go back to the early days of the movies, when moviemakers were in a position similar to ours. What can we learn from their efforts?
Early Movies
The earliest movies, popular during the 1890’s, had more in common with arcade games than with movies. The nickleodeon was fundamentally similar to the arcade game — a machine placed in a public loca tion, activated by the insertion of a coin, that dispensed a few minutes of enter tainment. The subject matter was similar in its emphasis on sensationalism. Where we have spaceships blasting each other, they had locomotives crashing into each other.
It is especially significant that the arcade-style movie of the 1890’s encoun tered a crisis right at the turn of the century. People grew bored with the same old stuff and turned away from it, causing some observers to suggest that movies were a fad that would soon die. The parallel with the experience of computer games in 1983-84 is striking.
The Narrative Element
The movies didn’t die, but they went through major changes. The discovery that you could tell a story in cinema (most attributable to Georges Melies) opened up a universe of creative opportunities and revived the dying industry. It took some time to figure out just how to tell such a story.
One of the early mistakes was the overuse of an existing model. Just as we game designers grope for comparisons with the movies to understand our medium, the early moviemakers looked to the theater. Some of them took the com parison too seriously. They placed a camera in the front row of the theater and put on a play with the camera rolling. These “photoplays” worked, but they did not take advantage of the special capabili ties of the camera, and they did nothing to correct its weaknesses. After all, a real play had sound, but a photoplay didn’t. A real play had the impact of real actors right in front of the audience, but a photo play didn’t. There were several well-funded efforts engaging some of the finest theater actors of the day, but they were miserable failures.
History repeats itself; today we have several publishers making explicit refer ence to the movies in their editorial strategies. They try to make games in the image of movies, and the results are just as lame as the early movies made in the image of plays.
The Development of True Cinema
Fortunately, there were creative people in the movie business who experimented with the medium and learned how to put together a real movie. The Great Train Robbery (1903), by Edwin S. Porter, intro duced revolutionary innovations such as the parallel story line and a more mobile camera. A few years later, D. W. Griffith gathered up the various techniques that others had stumbled upon and integrated them into a stylistic whole, in the process all but defining the basic elements of film-making. He zeroed in on and defined the use of such techniques as the close-up, cutting, and special lighting. The important observation here is that Griffith’s contribution lay in areas that differentiated movies from plays. The culmination of his work, Birth of a Nation, can safely be called the first true expression of the cinema as an art form.
We have to admit to ourselves that we have, as yet, no D. W. Griffith of games. We have not yet hit upon the fundamental techniques of our craft. We have yet to produce a game rivalling Birth of a Nation. The best of our work might be compared with The Great Train Robbery or Melies’ A Trip to the Moon. We have a long way to go.
Business Issues
Another striking parallel is provided by the Motion Picture Patents Company. Using monopolistic techniques, this firm quickly established itself as the dominant force in the American film industry. It then laid down two dicta that hobbled the growth of film. The first was that no film could be longer than ten minutes. The marketing experts at the Motion Picture Patents Company were adamant that the American viewing audience was too dumb, too impatient to sit through any movie longer than ten minutes. So certain were they that they shelved Judith of Bethulia for a year, losing D. W. Griffith in the process. How many times have I heard publishers lecture me that people just don’t want to play long games, that three minutes is the maximum attention span of the computer game player, etc, etc?
The second dictum of the Motion Picture Patents Company was that actors’ names were to be kept secret. They wanted to reserve the intangible assets to themselves, but they failed. Eventually, somebody stole away a talented and popular actress with promises of name attribution, and the dam cracked wide open. Thus was the star system born. The Motion Picture Patents Company, which had utterly dominated the American film industry from 1909 to 1912, plummeted in importance and was dissolved in 1917.
As an ex-employee of Atari, I feel a sense of deja vu when reading about the Motion Picture Patents Company. Atari shot into a dominant position in the indus try; it was the premier games company. Atari lived and died as an arcade-game company, certain to the end that what the public really wanted was fast-paced, short-duration games. Atari steadfastly refused to grant name attribution to its designers, grudgingly conceding only a few minor exceptions long after the rest of the industry had adopted the practice. And Atari died even more quickly than the Motion Picture Patents Company. Only the name remains today, pasted onto a completely different company.
Lexicon Development
One of the interesting problems in the early days of the movies was lexicon development. A movie is a medium of communication, and like any medium it has its conventions, those techniques or symbols that everybody under stands. Initially, nobody knew what the conven-tions were, so there was much con fusion. The first attempts at facial close-ups led the audience to think that the actor had been decapitated. Similarly, the early attempts at cutting from scene to scene encountered resistance from audiences who couldn’t understand the novel tech nique, but once they had been educated in the convention, the problems disappeared.
We in the computer games industry face a similar problem of lexicon develop ment. We have to re-invent the user interface with each new game, imposing new assumptions on our audience with each new product. We cannot, as yet, standardize our approaches because the situation is too dynamic to accept standardization. Revolutionary times are exciting, yes, but they are also confusing.
Overdoing It
There are dangers in making compar isons with the movies. The greatest of these arise from an oversimplified com-parison. If movies are visual presenta tions of stories, then are not computer games just like movies, only interactive? The danger in this line of thinking is that interactivity is not some extra feature that can be tacked onto a visual presentation. Interactivity is so utterly fundamental to the gaming experi ence that all design must flow outward from the interaction, rather than having the interaction follow from the images. To start with a collection of images and attempt to breathe interaction into them is as wrongheaded as the Frankensteinian notion that life could be created by stitching together parts of bodies. You have to start with the fundamentals.
Interactive Fiction
Another entertainment medium to which games are frequently compared is literature. The buzzword here is “inter-active fiction”, and it represents much the same kind of lazy thinking that goes into the phrase “interactive movies”. The initiating observation here is that computer screens have lots of text on them, and literature is composed of text, so why can’t computer games somehow do the same thing that literature does, only with interaction tacked on? Right.
I find it difficult to draw useful conclusions from any comparison of games with literature. There are some broad conclusions that can be drawn in comparison with stories in general. A game, like any story, must have conflict, for conflict is the goad of interaction between characters. A game must also have interesting characters (right now, we should be happy with any characters). But I can see no lessons that can be drawn from literature specifically. I think that the problem is that literature is an artistically mature field that has long since forgotten its youth. Perhaps one of you readers might wish to write an article revealing what I cannot see.
I will make a negative observation that the analogy to fiction can lead to serious mistakes. Fiction creates a storyline, a sequence of events arranged in an order that suggests meaning. This makes for great fiction and lousy games, because a game, to be interactive, must have not a storyline but a storynet. That is, the player must be able to make choices at crucial points in the course of the entertainment, and those choices, to be significant, must take the player to different territory. Many games crafted as interactive fiction have a hidden storyline inside a pseudo-storynet; this deprives the player of the opportunity to explore the territory he wants to explore, and consequently robs the entertainment of interaction.
Conclusions
Plato’s admonition applies to our efforts to understand games: we must proceed from the more knowable to the less knowable. Games are still in the “less knowable” category, but the cinema and literature are definitely “more knowable”. Both fields offer useful analogies from which we can draw proscriptive and prescriptive conclusions. But we must remember that games are not movies and they are not fiction. The terms “interactive movie” and “interactive fiction” only indicate the magnitude of our failure to figure out the true nature of games.