Contents
Editorial: Two Years Before the Masthead
Chris Crawford
Games Women Play: Some Alternative Approaches
Brenda Laurel
Credit Assignment Revisited
Chris Crawford
Extending the Life Expectancy of Producers
Don Daglow
The Model Contract Committee
Elaine Dutton
The Emergence of the Software Director as the Creative Force in Games
Tom Maremaa
The Primacy of Interactivity
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), through the JCGD BBS, or via direct modem. No payments are made for articles. Authors are hereby notified that their submissions may be reprinted in Computer Gaming World.
Back Issues Back issues of the Journal are available. Volume 1 may be purchased only in its entirety; the price is $30. Individual numbers from Volume 2 cost $5 apiece.
Copyright The contents of this Journal are copyright © Chris Crawford 1989.
_________________________________________________________________________________________________________
Editorial: Two Years Before the Masthead
Chris Crawford
This issue marks the close of the second year of the Journal of Computer Game Design. It’s been a good year for the Journal. Here’s what has been accomplished:
Subscriptions
Subscriptions have continued to rise steadily (the current count is 262 paid subscriptions and 55 free.) About two-thirds of all first-year subscribers chose to renew their subscriptions, a strong vote of confidence in the Journal. The Journal now reaches most professionals in the industry.
Content
The transition to the new format went smoothly, increasing the quantity of editorial content and improving its overall appearance. I have ironed out a lot of the bugs in the publication process. With the exception of this issue, editorial submissions have been strong all year; I have even had the luxury of turning down several good submissions that weren’t quite good enough.
The BBS
The BBS was launched ten months ago; while it has not been as successful as I had hoped, it has still served a useful purpose. Over the last five months, it has averaged about ten calls per day, with an active user population of about fifty persons. However, about two-thirds of all JCGD subscribers have never logged onto the BBS, and this problem has caused us much consternation.
The Conference
The Computer Game Developers’ Conference was spawned by the Journal, but in the last twelve months it has grown into its own creature. We have had three successful conferences now. Plans are underway for the next conference, scheduled for April 1-2, 1990.
The Future
What does the future hold for the Journal? Aside from increasing circulation (I hope and expect), there are three developments in particular:
First and foremost is the migration of the BBS onto GEnie. Neil Harris of GEnie has generously offered to host the BBS, and the BBS advisory committee has voted to accept Neil’s offer. On September 1st, the JCGD BBS will move to GEnie. We will have a conferencing area with our own categories and our own library. Most of the categories will be private, accessible only to JCGD subscribers. However, there will be three categories open to the general public. The good news is, if you are a JCGD subscriber, your time in the JCGD section of GEnie will be absolutely free! You will need to set up a GEnie account under a special login number; at press time, details of this login number were not available from GEnie. Check the JCGD BBS for details on how to set up your GEnie account; more details will be published in the next issue of the Journal. Also, I cannot guarantee any of this, as the discussions with GEnie, while well advanced, have not yet yielded a formal written expression.
Another grand plan of mine is the creation of a master directory of entertainment software people. If you want to know who’s who and does what, this directory should do it for you. I had intended to do it sooner, but my own product deadlines have interfered. Look for the questionnaire to show up in your mailbox before the year is out.
_________________________________________________________________________________________________________
Games Women Play: Some Alternative Approaches
Brenda Laurel, Interactivist
It’s always fun to dust off an old conundrum. Amanda Goodenough’s article in last month’s Journal brought the issues of women as a potential market for computer games to our attention again. It’s a question that most of us have given up as unanswerable, or at least too complicated to debate. But with the decline in sales to our bread-and-butter segment of fourteen-year-old boys (give or take a month), it’s a question that we should all be revisiting. I’d like to summarize some of the possible answers.
When I was managing the software marketing group for the Atari Home Computer back in 1981-2, the president of the division got the idea that we should design some games just for the gals. Clyde Grossman (now at Epyx) and I came up with a list of titles, including Appliance Command, The Atari Home Pelvic Exam, Cyber-Pope (a rhythm-method spreadsheet), and of course, the Atari Stretch Mark Editor(TM). For those of you who are breathless with contempt, let me hasten to add that this list was to function as a rhetorical device. In those idealistic days, we felt quite strongly that a line of products “just for girls” would probably end up reinforcing the worst of gender stereotypes, just as the products pointed at the teen male market did (and do). We were more interested in answering the question, what kinds of games would appeal to humans of all flavors? — with the hidden agenda of doing a little positive cultural engineering as well.
We’re more pragmatic now, I suppose. But as I hope to demonstrate later in this article, cultural engineering can be a very sensible thing to do when you’re trying to grow a new market.
In an article entitled “Girls Just Want to Have Fun” in Adweek’s Marketing Computers Magazine (Vol. IX, No. 6, June 1989), author Patty Cignarella interviewed a variety of folks and presented some new quantitative data on the subject. In a survey of 170 women at Northwestern University, the vast majority said that they would play computer games — if games existed which interested them. The number one category on the women’s wish list was simulations of social situations. Sports came in second, but sports in which women more typically participate — volleyball, scuba diving, crew, bike racing, and tennis. “The big losers,” says Cignarella, were “pilot simulations, space battles and exercise games.” So much for the Stretch Mark Editor.
For some folks, these data probably came as a surprise. Bruce Davis (CEO of Mediagenic), for instance, was quoted as saying that women are not a viable market for either computer or video games due to “profound” differences in the sexes. (I would personally like to mud-wrestle with Bruce; a game that let me do it would be at the top of my Christmas list.) For others, it’s not new news. Roberta Williams, extensively interviewed in the article, believes that women are attracted to story-telling games that allow interaction with complex, lifelike characters. Her approach seems to be paying off: Sierra On-Line’s King’s Quest IV, for instance, has achieved 35-40% sales to women.
So that’s the first approach — ask women what they like and try to build it. Amanda takes a similar approach in identifying themes that would be attractive to women and then incorporating them into the plots of games. The caveat here is that bad hypotheses can lead to disaster. Infocom’s assumption that girls would thrill to harlequin romances, for instance, led to Plundered Hearts, a game that did not do well in the marketplace. But as EA’s Bing Gordon observed in Cignarella’s article, “Most women who use computers are not the type of women who read romance novels. . . . If they even have time for reading fiction, they don’t read cheap novels off the drug store rack.”
A second approach, also championed by Roberta, is one that takes a fresh approach to gender — by offering a female protagonist in a traditional adventure context (as in The Perils of Rosella). Certainly, this technique can produce some winning combinations. But it doesn’t address the fundamental issues of content and context — issues that have deeper implications than the sale of one title.
Joyce Hakansson, long-time designer of a plethora of interactive products for children and founder of the software operation at Children’s Television Workshop, has been observing kids using computers for over ten years. She notices that girls and boys are equally interested in and adept with the technology until pre-adolescence, when the participation of girls goes into a dramatic decline. She attributes this phenomenon to two interrelated variables: game content (subject matter) and cultural roles.
The content of mainstream computer games stresses combat, competition, and sports — themes drawn directly from the male cultural domain. Boys will be motivated by the appeal of that content to master the computer skills necessary to play the game. Girls lack such motivation. Girls’ difficulties are compounded by cultural stereotypes — delivered by film, television, Barbie dolls, and other aspects of popular culture — which suggest that “real” women don’t play with machines, don’t do math, and don’t slash up monsters with a broadsword. And because they aren’t motivated by the content, they don’t bother to overcome the heinous interface hurdles that most adventure games present. Thus girls are doubly discouraged, not only from buying mainstream computer games, but from becoming even potential consumers of computer products at all.
So it turns out that cultural engineering may not be just political activism or social altruism. It may be pragmatic as hell. By offering games with themes and activities that change girls’ notions of themselves in relation to the technology, we may be doing ourselves a very tangible favor.
Which leads me to the third approach — taking a feminist perspective. Amanda observed in her article that women traditionally define themselves in terms of men and their relationships to them. This cultural stereotype has robbed us of many things. It precludes, for instance, the kind of idyllic “best friend of the same sex” that the male myth allows, because other women (and girls) are first and foremost ourcompetitors in the search for Mr. Right. It precludes us from climbing trees and commanding starships. It makes us giggly and helpless when confronted with a computer. But most of all, it robs us of the kind of personal power that lets us be heroes in our own right.
Yes, women are “profoundly” different from men. Some of those differences are cultural garbage; some are real. I think that the best approach to making computer games that work for women is a combination of the three. First, ask women what kind of games they would like to see. Second, create new and different roles for female characters. And third, think about characters, plots, and themes that can empower the young girls in our culture and give them the confidence to get involved with technology.
What would I design as a computer game for women? A Central American adventure with a female peace worker as a central character, perhaps, or a space opera with a woman starship commander, or a coming-of-age tale about kids of both sexes (as once suggested by Tom Snyder and immediately incinerated by his potential publisher). What would I suggest as design themes for developers who want to address the female market? Yes, games of sexual conflict would be fun (especially in the style of Shaw or Austen). Games that offer young women healthy role models in contexts that are not traditionally “female”. Games about the moon-and-magic side of the female cultural icon, where intuition and connectedness to the earth are reformulated and celebrated. Games where women have relationships with other women as robust and trustful as those between men.
But the important point here is that I’m advocating unique, individual visions of what women are and can be. Ultimately, there is no template for women’s games that is not fraught with cultural (or counter-cultural) stereotypes. The only way to transcend them is for designers of both sexes to create strong new images of women that we can all try on for size. This is a challenge that devolves to the individual game designer and to the game design community.
The payoff can be bigger than selling your next game.
_________________________________________________________________________________________________________
Credit Assignment Revisited
Chris Crawford
Two years ago I published an article in the Journal presenting a survey I had carried out regarding author credits on game packaging. I attempted to quantify the amount of author credit that we receive by measuring the size of the author’s name on the front of the package. By “size”, I actually mean the height of the type in which the author’s name is printed. To make it more fair, I also measured the size of the publisher’s name. This allowed me to calculate a ratio of the author’s size to the publisher’s size. That ratio is a quick and dirty index of just how much credit we authors receive.
The ratio, averaged over ten computer games, came out to 0.75. That is, the average computer game box prints the author’s name in type that is 3/4 the size of the publisher’s name. How good is that? Well, I carried out similar measurements for books, compact disks, and videotapes, obtaining ratios of 4.0, 1.36, and 1.14 respectively. In other words, artists in those other fields receive better recognition than computer game designers. That’s not good.
So, how have things changed in the last two years? Have they gotten better or worse? Your roving reporter wandered into several software outlets in search of the answer. I went down the shelves, pulling boxes and measuring the size of the author’s name and the publisher’s name on each. I compiled a list of some three dozen different games, from all the major publishers, and the results are not heartening. The overall ratio has gone down to 0.53!
Here is the breakdown by publisher of the average ratios. Remember, a large value is good, and a small value is bad for authors:
Electronic Arts: 0.90
Mindscape: 0.79
Origin Systems: 0.41
Activision: 0.28
Broderbund: 0.20
Cinemaware: 0.16
Accolade: 0.04
Epyx: 0.00
Now, there are a number of special factors to complicate our considerations. For example, some publishers put their logo on the front of the box. Electronic Arts, for example, has a large logo, and their corporate name is printed in small type. I didn’t measure the logo, I measured the typesize. Thus, EA’s ratios are better than they deserve to be. Mindscape has a similar arrangement.
Then there’s Cinemaware. Cinemaware presents big, bold author credits. Unfortunately, Cinemaware dilutes the value of author credits by packing the credit list with lots of Cinemaware employees, including Bob and Phyllis Jacob, the owners of the company. The real authors are buried in the pile of other names.
Epyx boasts the astoundingly low ratio of zero. This is because they don’t include any author credits on the front of their boxes. There were some author credits buried in the fine print on the back of the box, but that doesn’t count in this survey.
Several major publishers, most notably Microprose and Sierra OnLine, are not included in this survey. They rely on internally developed software, and so do not provide author credit. I thought it unfair to include them.
Need for Remedies
This may strike some readers as much ado about nothing. After all, some might reason, financial considerations must remain paramount when so many developers must struggle to make a living. Worrying about credit assignment is just glorified ego-tripping.
This is short-sighted reasoning. Look at it this way: the goodwill that a superior game creates in the minds of consumers is an asset. It is an intangible asset, but a valuable one, for it will be a major factor in the consumers’ decision to purchase future games. To whom should that asset accrue? Right now, the publishers arrogate most of that asset to themselves, and authors acquiesce to the arrogation.
_________________________________________________________________________________________________________
Extending the Life Expectancy of Producers
Don Daglow
The job of a Computer Game Producer is not an easy one. Like anyone who manages a creative process that must turn a profit, producers are the oil that lubricates the point where the rough edges of art and money rub together.
There are some steps that authors and publishers can take that will make life a lot easier for their producers and ultimately for themselves as well. This article presents those steps.
The suggestions below are not intended to suggest that producers are perfect and that if only authors and publishers would get their act together everything would be fine. My point is that the job is tough and producers are fallible, so they can use all the support they can get from the people who, in the end, they’re trying to help.
Although I now run Beyond Software, a design and development group based in San Rafael, I spent the years 1980-88 working primarily as a producer. One prejudice I should note is that I had the good fortune during that time to work for two top companies blessed with stringent ethical standards: Electronic Arts and Broderbund. I have heard stories about publishers consciously cheating their authors; like all human beings EA and Broderbund might at times have made poor decisions that hurt authors, but both Trip Hawkins and Doug and Gary Carlston are real sticklers for ethical business practices. I trust them to drive a hard bargain, but I also trust them to live by it, and that’s a perspective I bring to our current clients and to this article. If you’re dealing with different kinds of people these principles may not apply.
I. How Authors Can Help Their Producers
Your producer is a split personality. 50% of the time s/he is representing the publisher to you. The other 50% of the time s/he is acting as an agent for you inside the publisher and trying to look out for your best interests. Good producers can balance this schizophrenic split, and always let you know which face you’re dealing with at any given moment. Here are things you can do to make that process easier.
1. Treat your producer like a person when negotiating the contract, and be reasonable with him/her.
As noted above, there’s no such thing as a perfect publisher but I’ve been lucky enough to work for two honest ones. I’m afraid I disagree with Cliff Johnson’s recent article about contract negotiation in which he suggested that a good strategy is to assume that publishers are out to screw you.
Since producers often negotiate the contracts for publishers, and since producers often are the staff members who best understand the issues important to authors, I would propose the following negotiation strategy:
• If you see evidence that the publisher does cheat people or seems like a snake-oil salesperson, forget the advice below. Go back and reread Cliff’s article, because for those types I agree with most of his points. Better yet, find yourself an honest publisher.
• As Cliff said, always have a lawyer look at the contract for you, preferably someone with a background in software law. Ask fellow authors for recommendations if you don’t know a good firm. This will probably cost you around $1,000 for the longer contracts, perhaps as little as $300 for short ones, but it’s well worth the cost. Reading the contract yourself first and highlighting areas with which you’re concerned will save you a lot of money, because the attorney can learn what aspects of the contract you already know should be changed and won’t spend time (and your money) telling you about them.
• I assume in all negotiations that the producer with whom I’m dealing is going to do a good job of representing the publisher’s interests, and is anxious to please me in any way he or she can that DOESN’T conflict with that goal. They aren’t out to screw me, but they are out to get the best deal for their company that can still be considered reasonable. If I ever CAN’T assume this, I must need the money awfully badly if I don’t break off the negotiations and look for a more honest publisher.
• Once you assume this, you have to do a good job of representing your own interests, and work to get the best fair deal you can. Give the producer all of your contract concerns at once, not in dribbles and pieces, so you build a list of disputed points you can gradually whittle down to nothing. Pleasantly insisting (as often as necessary) on points that are important to you is not going to hurt anyone or anything, and you’d be surprised how often your point of view will prevail. You don’t have to sign a contract you don’t like, and they don’t have to give you any money; in the end you’ll usually get enough of what you want to sign and they’ll be satisfied enough with the deal to give you money.
• Since neither party will get the contract to come out exactly the way they wanted it, forget about your differences once it’s signed. Unless an issue becomes pertinent to the project, nagging the producer about “You know I’m still pissed about that returns clause” once a week and telling all your friends how rotten the contract is doesn’t do anyone any good and will drive your producer nuts. Especially since they may secretly agree with you and wish the contract had come out your way.
How do all these things help your producer? He or she probably has the authority to make some contract changes directly; for most others your producer needs to get approval. If you’ve given them a reasonable set of issues, you’ve made it easy to go to their management and say “The royalty rate and paragraphs 2, 6 and 10 are what are really important to them, and they have a few other little fixes that are routine. I know we can’t change paragraph 10, but if we give them 2 and 6 and agree on the royalties I think they’ll sign. They have a good track record, so it isn’t like we’re leaving ourselves totally exposed on the acceptance and corrections issues.”
What do producers end up saying when authors aren’t reasonable? “He’s paranoid about the contract. He wants us to change 3, 4, 5, 6, 8, 9, 12, 14 and 15 and make it so we can’t terminate the contract even if he burns down the building and moves to Rio. He’s called me back three different times with new problems, and hasn’t conceded anything. And he wants a royalty rate that no publisher in his right mind would agree to.”
In the first case the author has allowed the producer to become his agent even before the contract was signed. The producer will often argue points on behalf of the author and try to win management approval.
In the second case the producer is trapped into the role of defending the company because the author is so demanding. And the question is inevitably asked, “Whose dumb idea was it to sign this author in the first place? Are they so good we have to put up with this crap?” The producer now has no allies at all: the author distrusts them as a company mouthpiece, the company distrusts them as being poor at selecting authors.
2. Treat your producer the way you’d like to be treated. This seems like an obvious variation on the Golden Rule; here are some concrete steps you can take that will help.
• Ask your producer what things you can do to make their job easier. Seems obvious, but authors rarely do it. Every producer has a different style, and every company has different systems. Some examples:
“Always give me two weeks’ notice of when you expect to have a milestone ready, even if you’re right on schedule, so I can have the check ready for you quickly and you won’t have to wait. But never EVER say that and then be off by more than a few days, because I’ll get my butt kicked for not being in touch with the project.”
“Please call me in the afternoons whenever you can; I try to do paperwork in the mornings and people work in the afternoons.”
Whenever you work to help the producer do their job better, you make both of your lives easier.
• Call often to report either progress or problems. The worst sound for any producer is silence — it usually means something’s wrong. Calling regularly to report progress or problems is a great way to build the relationship. You can’t get your producer to help you solve a problem until you share it with him or her, so don’t hesitate to kick around the tough issues and get their input.
• Return calls promptly. Not returning calls is one of the fastest ways to make your producer wonder whether things really are going OK.
• Give bad news sooner rather than later. Your project is scheduled to go Beta on July 1. On February 15 it’s OK to say, “The animations gobble 204K and I’m worried that we haven’t got enough RAM to make this thing work the way we planned. Let’s sit down and figure out what changes we need to make.” If you say the same thing on June 15, however, with only two weeks until Beta, it’s definitely NOT all right. With five months to go you have time to discuss the issues, reach decisions you both support and make changes; the producer reports the changes to management as a routine thing, no big deal. With two weeks to go the producer may have to tell management “It’ll take a complete rework. We’ve blown Christmas for sure.” And that can get your entire project terminated, your reputation damaged and your producer’s ass in a sling.
• It’s better to disappoint your producer with your promises than your product. Your producer says “When will the milestone be ready? Think you can have it by the first?” You’d been thinking it was going to be ready about that time, but you also know that RAM is tight and you may have to spend quite a bit of time moving stuff around to make it fit, which could cost two or three days. You say, “Yeah, I can have it for you by then. (I think.)” Well, we all know that Murphy’s Law now guarantees not only that you’ll have RAM problems but three more serious bugs as well, and you get the milestone in on the 8th. This undermines your credibility with your producer, and it also undermines THEIR credibility inside their organization, since they relayed your date to their management. It’s better to disappoint your producer with your promises (“I doubt it’ll be ready”) than your product (“I know I said it’d be ready, but it’s not.”).
II. How publishers Can Help Their Producers
Here are the ways in which I believe management at a software publishing company can help producers better do their jobs and generate more revenue with less risk.
1. Listen. Then listen. Then listen some more.
Most publishers know that their sales staff is their best source of information about the market-place, and continually poll the field sales people to see what they’re hearing about market trends.
I believe that to have good author relations and fewer surprises in their product development, publishers need to look at their producers as information-gatherers of the same kind. Knowing the state of mind of the creative people who are developing the products is as important as knowing the state of mind of those people who’ll be buying them.
The obvious part of this is that if a developer is starting to have trouble, the producer will be the first to know. If they try to tell you and you don’t listen, that’s bad, because it’s data you need to know and you missed it, and you’ve lost your producer’s respect in the process.
If the producer tells you a project has problems and you immediately terminate the project or relegate it to the back burner, that’s bad, too. If every project that showed early signs of trouble were terminated, Egghead would have about six games on its shelves, all of them variants of Wheel of Fortune. Overreacting discourages producers from sharing their suspicions of problems, weaknesses they’ve found in otherwise capable authors, and other information that is both useful and subtle. They learn to keep such things to themselves instead of sharing them, and the publishing company is the worse for not knowing.
Perhaps the worst thing of all that you can do is to make the producer feel like he/she is in trouble for bringing you this news. If you are trying to hire a producer who will never make a bad decision on a product and never have any project get into trouble you will never hire ANY producers. Shooting the messenger is also a good way to run out of messengers, then messages, then money.
A Side Note for producers: Just because they’re tight with cash and project approvals, don’t assume that your management is going to be too tough when you bring them the news that a project may have problems. After working in a big cartridge-game corporation where we had to protect the game designers from overreactive executives, I went to a disk-game publisher. There I made the mistake of not always passing through “danger signals” to my managers, and it took me longer than it should have to realize that they understood the development process and would react reasonably. Information is what a producer’s all about — it’s how you help everyone else do their jobs well. So give your management a chance to see the whole picture.
2. Producers are the Recruiting Officers who persuade your best authors to re-enlist. Do everything you can to make that job easy.
At the end of every project a publisher has a sense of how they feel about the authors:
• “Let’s sign them up for something while we’re still in Beta, so they don’t have a chance to start looking around and we don’t lose them.”
• “He’s an awesome programmer when he’s got his act together but he’s so unreliable it’s just not worth taking the chance. Let’s not use him again.”
• “If it’s something where animation speed isn’t an issue I think they’d do a good job, so take a look at the schedule and see if there’s anything that’s right for them.”
We as authors are responsible for how the publishers feel about us. If we do a good job that will almost always be recognized, and if we screw up that will ALWAYS be recognized as well. Our producer is the person who plays the primary role in molding that publishing company’s opinion, so helping the producer do their job well is of critical importance.
Authors have the same set of feelings about publishers:
• “I’d never work with that company again. They jerked me around making me wait forever for checks and made me late on two mortgage payments.”
• “They’re a pretty good bunch of people. There were a couple of times they developed strong feelings about features at the last minute that they should have thought about six months ago, but overall they were pretty good.”
• “They’ve gone way out of their way to help us and make things easier for us. I’d like our royalty to be higher, but they pay us for milestones fast and they actually boot the disks we send them and spend more than five minutes with the game and give intelligent feedback within a few days.”
The producer is primarily responsible for the author’s opinion of your company. When you think an author or author group is excellent, you can do many things to help — or hinder — the producer’s efforts to keep that author emotionally and financially attached to your company.
This doesn’t mean that every author must always get what he/she wants, nor that they have to agree with every decision you make as a publisher, nor that they must be pleased with every provision of your contract. What it does mean is that, in general, your authors must believe that they are being treated with reasonable fairness, consideration and, above all else, respect.
The kinds of things you can do to help your producers convey this to your authors are:
• Keep your promises. You tell a producer something’s OK, then they tell the author. You change your mind. You’ve now damaged the producer’s — and the company’s — credibility with that author, and made the producer feel like a fool.
• Ask questions. Keep in touch with what the producer is doing and give feedback. If you go along merrily for six months and then call them in and say, “Two of your projects are really late and you’ve screwed up!” it’s already too late for the producer to respond to your concerns in a constructive way. If you’ve been expressing that concern with gradually increasing loudness each week for three months they’re much more likely to be taking the actions you want.
• Don’t insist on contract provisions that gain you little but make the authors angry or distrustful. Many publishers’ contracts are hobbled by petty clauses. The producers keep telling their companies the issue is doing more harm than good; this is advice worth listening to.
• Don’t let bureaucratic slipups hurt authors. If someone messes up once in a blue moon and a check is very late to an author, call the author yourself to apologize and mention that the producer raised hell. (This tells the author that the producer is really representing them inside the company, which builds trust). If your procedures yield late checks more than once in a blue moon, fix them, because the best producer in the world can’t compensate for an author getting an eviction notice.
• Involve producers in tough decisions that affect their authors. When the Atari 800 stopped being a viable platform several years back, a number of projects at different publishers had to be cancelled mid-stream. The decision was necessary but it still hurt authors. Simply telling a producer their project is cancelled makes them feel attacked; inviting producers to a meeting reviewing the dismal state of Atari 800 sales and discussing what response the company should take makes it easier for the producer can buy into the fact that to continue development would be futile. Then...
• When a producer has to create problems for a good author, give them some solutions to go with the problems. The producer has to go to a good author and cancel an Atari 800 project. The problem is that the author will now starve because they have no project; if they’re good, they’ll move to another publisher and you’ll lose them. The solution: (a tradition for some publishers) pay them for one extra milestone so they aren’t suddenly left broke, and use the time that buys them to arrange an alternate project. Good authors understand that sometimes these things happen, and if you give your producer a chance to handle it in a professional way you can make the decision without destroying the relationship and damaging your producer.
Conclusions
You can see that the essential elements that are repeated in all the above formulae are 1) clear communication, 2) consideration, and 3) respect for everyone involved in a project. A producer who knows game design and both gives and receives those things is likely to be productive and do a good job.
Come to think of it, there are damn few things in this world that won’t run better given a generous dose of those very things.
Producers on the Move
It seems that the producer is an endangered species. In the last few years, producers have been departing publishers at an alarming rate. Some examples:
Dave Grady, a highly regarded producer at Electronic Arts, left and eventually settled at Next, Inc.
Carol Balkcom, one of Mindscape’s most talented producers, departed for NEC Home Electronics.
Shelley Day, cowinner of the 1989 Computer Game Developer’s Conference award for Best Producer, resigned from Accolade and moved to Taito America.
And, just before press time, Tom Maremaa left Epyx. See Tom’s article elsewhere in this issue.
On a related matter, Greg Riker, who was responsible for EA’s superb technical support program (for which EA has twice won the Computer Game Developer’s Conference award for Best Technical Support), has left EA for MicroSoft.
What is so disturbing is that the producer seems to be chewed up and spat out by this industry much more quickly than any other position. Software publisher executives stay on with little turnover. Marketing people change titles and offices but enjoy career stability. Even the freelance developers seem more stable in their relationships than the producers.
There is clearly something wrong with the industry in the matter of producers.
_________________________________________________________________________________________________________
The Model Contract Committee
Elaine Dutton
[Elaine is the CEO of Incredible Technologies, a software/hardware/whatever-you-need-ware operation in the Chicago area. Even though she is responsible for some 35 people, she still does some of the programming herself.]
At the Computer Game Developer's Conference in May, a committee was formed to create model contracts that could be used by game developers in their negotiations with publishers. The purpose of these model contracts is to educate all developers, new and old, to the terms and conditions about which they should be concerned.
Naturally, whenever somebody prepares a contract, that contract is going to primarily reflect their own view of things. In our business, it is usually the publisher who provides the contract. As a consequence, the developer is put into the position of needing to negotiate the contract towards a more even-handed position. In the past, there has been no unified standard for the developer. Each developer group has created their own standard without having general knowledge that could help them.
My major goal in this effort is to enhance the operation of the free enterprise system. I believe the most talented should get the most compensation. However, unless we developers cooperate in the gathering and dissemination of knowledge, the mean and median of the compensation bell curve could keep going down and penalty clauses could become a way of life.
Since the conference several people have sent me copies of various contracts from within our industry and related industries. Many people have offered their support and help for this worthy cause. I would like to make a general request to all developers, associates, and interested publishers to send me written information on the following topics.:
1. Send whole contracts or parts of contracts. Show which parts you liked or changed in your favor. Show which parts you didn’t like and were unable to change.
2. Have you ever been in a dispute or a lawsuit with a publisher? Where did the contract hurt? Where did it help?
3. Have you ever audited a publisher? Did you find a discrepancy? Did you have trouble collecting compensation?
4. Have you signed a contract with late fees or other types of penalty clauses? Did the publisher collect?
5. Have you kept or given over rights to the intellectual property?
6. What type of advances, royalty rates, international licenses, etc. for originals and conversions do you think is fair in today’s market?
7. Any other related issues.
Please indicate if I can publish your answers to these questions (names deleted of course) in future editions of the Journal. The contracts and comments will be used by Michael J. Hanson, Vice President and General Counsel at Incredible Technologies, to draft three standard contracts. One contract will address original design and development involving royalties, one will address converision work, and one will cover parties doing a section of a larger project. He will also write an additional document to interpret any legal terminology which is difficult to understand. These drafts will be reviewed by the contracts committee and other attorneys. After approval, it will be presented to the attorneys of the SPA for their comments. After this process, the contracts will be available to the developer community.
_________________________________________________________________________________________________________
The Emergence of the Software Director as the Creative Force in Games
Tom Maremaa
[Tom Maremaa, formerly a project manager/producer at Epyx, is expecting any day now to see the first software program from the Master Rubik.]
Software development, these days, is, largely, a mess.
I think most of us have been there, and know what I’m talking about. Projects are started, then stopped; contracts drag out, programmers pick up and move on. Who’s in charge? Who decides which bit of code to use or not to use? Which graphics are most aesthetically pleasing — and strong enough to excite the gameplayer in large numbers? When will the market bounce back, or are we doomed to repeat the crash of ’84?
Meanwhile, developers are late, missing their milestones because, as the litany is told, “software is never finished...” Is computer programming an art or a science? In the midst of all this chaos, publishers try everything under the sun: bringing creative projects in-house, where schedules can be tightened and programmers more carefully tasked; shuffling staff; moving resources around in an effort to put out one fire after another.... But still, not much changes....
In the last couple of years, as one possible solution, the majors have turned to “software producers,” at best a nebulous category, following something of the model established early on by Electronic Arts. Producers will follow a project through from start to finish, producers will save us. Or will they?
But the producer system is already hopelessly antiquated and ineffective. Where are the latest producer-created hits? Aren’t most producers caught in the cross-fire of protecting the interests of the companies they work for, and the creative interests of those working on a project? Typically, producers are stuck in a revolving door at most software companies. There is little continuity; some of the best burn out too soon, because the demands and conflicting pressures are just too overwhelming, even for the most talented and gifted....
(In the film industry, producers are broken into sub-categories: the executive producers are deal-makers who acquire “hot” properties, put the “elements” together, i.e., the director, stars, the basic material, and take it to the studio for financing. There are also line producers, who, as the name implies, stand on the sidelines and handle the nuts and bolts of production.)
To get out of this mess, I would argue for the emergence of another creative force in software development: The Director. Just as Truffaut, the great French filmmaker, argued for the auteur in filmmaking a quarter century ago in the obscure French film quarterly Cahiers du Cinema, I would argue that, in order to produce great software, you need strong personalities to direct its development and, once again, reach a broader base of gameplayers and end-users, whether on the PC, Mac, Amiga, IIgs, or ST.
The Director would, quite simply, own the vision of the game, or entertainment experience. He or she would truly “direct” its development. Doesn’t a producer or project manager, essentially, do this already? The answer is no. Producers tend to represent the interests (primarily, business and financial) of the publisher for whom they are working. Because of this, producers become studio executives, not creative forces committed to realizing a particular vision. Software producers tend to function in the same capacity as senior editors function at publishing houses: they acquire the properties, work with the authors, and contribute to the marketing plans.
I propose that the Director craft the work, and hire the artists, programmers, tech staff to execute the vision. The focus would be on all aspects of the game’s development. In the early days of much greater software simplicity, programmers were inevitably their own directors. They had a vision and found a way to see it through to completion, without excessive meddling from their publishers. Now the task of bringing high-quality entertainment software to market is far more complex, involving teams of artists, designers, programmers, sound engineers, testers, and marketeers.
The Software Director, then, must:
1) own the vision of the program, i.e., at all times “have the program in his head,” much as a film director does;
2) focus intensely on the visual “look and feel” of the product, and be prepared to cut where necessary;
3) know clearly what he or she is going for, what special effect or experience really works, and build accordingly;
4) have a keen understanding of the user’s needs and expectations from a particular work of entertainment software;
5) take risks and “sign” his work, claim authorship, with appropriate credits for the writers, producers, computer artists, and other contributors
When I built GrandSlam Tennis for the Macintosh and Amiga, I wore so many hats that I wasn’t quite sure how to characterize my role in the program’s development. But I had a particular vision (as a former tennis professional) of how to design and build a tennis game/simulation of the World Grand Prix Circuit. I also had a passion for the Macintosh, which everyone I knew had skoffed at as a games machine. In retrospect, I “directed” the project, integrating graphics, sound, and animation, so that it had the look and authentic feel I wanted (and got about 75% of that in the game).
Recently, on a trip to Hungary to meet with Novotrade, I went after a Rubik. People where I worked told me that Rubik wasn’t interested in any software projects. But I found a puzzle of his called “Tangle” (unpublished here), wanted to convert it into software, and ended up smoking Rubik out of his academic cube at the university. Now he’s working on his first software game ever, meeting with Novotrade programmers and working on a PC for the first time. Later, I realized that I played the role that any film director would play in getting a famous author to write a script.
The Director System will work, if and only if Software Directors:
a) build games and entertainment programs that they themselves would like to play; b) build for a particular consumer or gamer; c) take risks and break new ground rather than repeating the same old formulas.
What a Software Director can do is add “personality” to a work, or specific “touches,” just as the great film directors of the century have done. For the user, this has tremendous benefit, simply because the game comes alive; you have the sense that you’re in the presence of something magical, mythical — some force that transcends the moment.
Producers float from company to company, ever in search of the perfect deal or situation; programmers become disgruntled because they’re not being challenged; projects are late, or worse, never completed; marketing can’t plan adequately ahead to meet important release schedules. The software mess increases exponentially.
There may be no easy way around any of this. But the emergence of Software Directors, individually and as a separate creative class, is inevitable and certainly welcome. We need to spawn the next generation of Software Directors comparable to Stanley Kubrick, George Lucas, Steven Spielberg, Francis Coppola, Woody Allen, Martin Scorsese, Jonathan Demme, Phil Kaufman, Milos Forman, Barry Levinson, among others. This might go a long way toward revitalizing our industry.
The games market will most certainly explode and fragment this year, as well as next: some of the majors will fall into the artfully laid traps set for them by Nintendo and Sega, while others will hedge their bets and avoid any project that is perceived as in the slightest bit “risky.” The smaller, more enterprising players, however, will emerge with hits, and a new crop of Software Directors will be born. This will happen sooner rather than later.
_________________________________________________________________________________________________________
The Primacy of Interactivity
Chris Crawford
There exists within our community a school of thought that holds interactivity to be nothing more than a useful component in the design of entertainment software. According to this school, the computer is a wondrous tool offering a variety of capabilities, such as graphics, animation, and sound. Interactivity is seen as just another capability, to be used or neglected according to the tastes and intentions of the designer.
I reject this thinking, and I propose here to present the case for the primacy of interactivity.
Let us examine the various characteristics of the computer as an artistic medium. The computer is capable, for example, of displaying graphic images. Yet this capability is not its true strength. We possess many other technologies capable of displaying graphic images. These other technologies, moreover, can display superior graphic images at lower costs. For the cost of one computer game, I can buy a snazzy coffee-table book loaded with scores of high quality color images. I can buy posters or slides or postcards or reproductions of paintings, all offering higher quality at lower cost. To use the computer as a medium for displaying graphics is silly.
Now, some people argue that the use of graphics doesn’t hurt, and should be pursued because it is another avenue of artistic expression. “Why not make use of every avenue available to us?” they ask. This question directs our attention away from the real issue of the relative roles of the different avenues, instead focussing on their absolute roles. I do not question the desirability of using graphics; I instead challenge the notion that graphics should receive equal emphasis. Graphic displays are not the strength of the computer.
Suppose that I as an artist have something of artistic value that I wish to convey to an audience. If I choose the computer as my medium, I will have a variety of channels available to me. However, if I choose the graphics channel as the primary means for conveying my artistic goodies, then I have blundered in two ways: first, I have failed to use one of the many technologies that are superior at presenting graphic displays; and second, I have tried to use the computer to do something that it doesn’t do very well.
The same line of reasoning applies to many of the other commonly exalted features of the computer. Animation is nice, but movies do it better than computers, and a videotape can be rented or even purchased for less than a computer game. Sound is impressive, but a compact disk, LP, or cassette tape does the job better. And let’s not even talk about text.
The one thing that the computer can do better than anything else is interactivity. Indeed, the computer doesn’t just do it better; the computer is the only medium capable of providing interactivity. This is why interactivity should be the proper focus of effort of the entertainment software designer.
Perhaps all this talk about artistic values leaves you unimpressed. Very well, let me present the arguement in the language of business. Interactivity is the basis of competitive advantage of the computer. Sure, the computer can do a lot of things, but the one thing that it does better than any of the competing media is interactivity. And the wise businessman always throws his resources behind his basis of competitive advantage. IBM’s strength has always lain in the area of marketing, so IBM emphasizes marketing in all its efforts. Of course IBM pays attention to R&D and manufacturing and accounting and all the other tasks that a big business must perform, but primacy goes to marketing, because that is IBM’s basis of competitive advantage.
You still aren’t convinced? OK, how about military reasoning: fight on the ground of your own choosing. The wise general offers battle only on the terrain best suited to the strengths of his forces, and takes maximum advantage of the weaknesses of his opponent. If his best troops are cavalry, then he will choose to fight on flat open ground where the cavalry can do its job best. Sure, he’ll fight with his infantry and artillery, too, but the tactical primacy will go to the cavalry.
So too it must be with interactivity. Yes, the computer can do graphics and animation and sound, but these capabilities are not the primary strength of the computer. Interactivity is the real strength of the computer, and it must be given primacy in our designs.
None of this suggests that graphics, animation, and sound should be eliminated from our designs. These are necessary supporting elements in the overall design. The better we are able to marshal them to heighten interactivity, the more successful our designs will be. But necessity does not convey equality. The ability to use a keyboard is absolutely necessary to a programmer, but typing skill is nowhere near as important to good programming as clear thinking.
Is More Interactivity Better?
Now I turn to an even more difficult question: if interactivity is accorded primacy in entertainment software design, then is not more interactivity better than less interactivity? Put more baldly, is a more interactive product better than a less interactive product?
My answer to this question is, for once, qualified. In general, I would say that, yes, a more interactive product is better than a less interactive one, but I would hedge my claim.
My first arguement in favor of a preference for greater interactivity relies on the primacy of interactivity. Since interactivity is the basis of competitive advantage of the computer, it is only fit and proper that we should emphasize it. The more we emphasize interactivity in our designs, the more fully we utilize the true strength of the computer as an artistic medium.
Consider the cinema by way of example. Very roughly speaking, the more cinematic a movie is, the better the movie. We can argue long and hard over the precise definition of “cinematic”, but surely we can agree that it involves the special capabilities of the camera to capture motion, to pan, zoom, and move, to cut between scenes, and so forth. Surely a movie that fails to use these techniques will be inferior to a movie that does, other things being equal. Thus, we can say that a more cinematic movie is superior to a less cinematic movie. Of course, there are many exceptions to the general rule: a poorly executed more cinematic movie is not superior, and a movie whose artistic intent requires a less cinematic style could still be a superior work. There are other exceptions as well, but I think that the general rule holds true.
An additional arguement arises from the fact that the interactive arts are still in their infancy. We have just scratched the surface of this medium; we do not fully understand interactivity. Our ignorance is reflected in the body of work we have created. In the vast universe of potential computer games, the set of actual games that we have created lies crowded down in a small corner, huddled together in common low interactivity. Taking all of our computer games and entertainments as a group, the amount of interactivity that we offer is a faint and clumsy whisper of what should be possible.
Perhaps a mathematical approach might help. Imagine a scale of interactivity, running from 0 to 100 units of interactivity, with 100 representing interactivity so intense that it lies beyond human comprehension. Imagine all the games in the universe placed on this scale. Now, in an ideal world, these games would yield a bell curve, with a few high-interactivity games, a few low-interactivity games, and a great many games in the middle of the bell curve. But we have not attained this ideal bell curve. Our ignorance denies us the middle and upper portions of the bell curve, constraining us to the lower end of the curve. All of our work lies crowded down there.
This is why, for the moment, more interactivity is better than less interactivity. We need to move up that bell curve, to explore areas of interactivity that have previously been inaccessible. This is why I hold a more interactive game in higher esteem than a less interactive one. This is why I honor a designer who goes where no designer has gone before more than one who hews to more familiar territory.
Of course, when we have populated the bell curve more fully, the day will come when some genius creates a game that is too interactive. But that day is far distant.
There will always be a place for low-interactivity entertainments, such as puzzles and slightly interactive stories. These entertainments will not be pushed over the brink of extinction by the highly interactive products. I suspect that, as we move up the bell curve, their relative numbers will shrink.
_______________________________________________________________________________________________________