Gamasutra.com - We're Not Listening: An Open Letter to Academic Game Researchers
It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

By John Hopson
[Author's Bio]
Gamasutra
November 10, 2006

We're Not Listening: An Open Letter to Academic Game Researchers

arrowrightPage One
arrowrightPage Two
arrowrightPage Three
arrowrightPage Four

 



Latest Letters to the Editor:
Perpetual Layoffs by Alexander Brandon [09.21.2007]

Casual friendliness in MMO's by Colby Poulson [09.20.2007]

Scrum deals and 'What is Scrum?' by Tom Plunket [08.29.2007]


[Submit Letter]

[View All...]
  


Features

We're Not Listening: An Open Letter to Academic Game Researchers


Rule #3: Smaller, Faster, Cheaper

Working in the games industry can be brutal, involving fast-paced schedules and eighty-hour work-weeks at times. The people listening to your talk already have a full workload. They’ve already been cutting features to make their production milestones, often features that represent some of their best ideas and strongest held beliefs about games. And then there’s this academic who’s never shipped a game standing up there telling them to rip out weeks of work in order to implement some pet theory. Give us a break!

Furthermore, games work on a multi-year development cycle. For a given article or conference presentation, the audience members will be spread across all possible phases of development. Some will be working on games still in the prototype phase, some will be in full production, and some will be in the final crunch to release. If the recommendations involve major changes to the design, the odds are that the majority of the audience has already passed the point where those sorts of changes can be made on its current project.

All recommendations are not created equal. Some are going to be easier to implement than others. Making a change, any change, to a game that’s already in production is akin to doing auto repairs on a car going 60 mph down the highway. The very fact that your audience is even listening to your recommendations, even considering making any kind of change, is a major concession. It’s up to the researcher to choose recommendations that make it easy for the developer to say “yes.”

The best recommendations should be…

  • Feasible for one person to implement. It’s much easier to convince one person than ten. If a suggestion can be taken to heart by one designer who can then turn around and implement it in just his own area of responsibility, that’s a lot more likely to happen than a change that requires the entire design team to agree.
  • Scalable. A good change is one that can be quickly implemented on a small scale for trial purposes, and then expanded if testing shows that it’s working. Make the required leap of faith as small as possible.
  • Modular. The fewer aspects of the game that need to be changed, the better. The more a suggestion cuts across boundaries (art, design, UI, etc.) the more likely it is to be ignored. Changing either the appearance or behavior of a character is easier than changing both together, for example.
  • Parametric. The easiest things to change in a game are things that can be represented by single numbers. Changing what a gun looks like is hard. Changing the damage it does by 10% is easier. Whenever possible, pick recommendations that can be implemented by changing individual game parameters.

Rule #4: Prescriptive, Not Descriptive

One major difference between academia and industry is that academic work can be purely descriptive and still be successful. Discovering and describing a new phenomenon can be a genuine academic victory in itself. However, while understanding games is a research discipline, actually making games is an engineering discipline. There needs to be a clear and explicit path from the imagined beauty of research ideas to the ugly reality of implementation.

One particular area where understanding falls short of implementation is in the realm of nomenclatures and classification systems. In academia, developing a way to classify players into specific defined types can be a very real and present help to future research on the topic.

However, to make that research useful to developers, it’s important to take the next step and give concrete examples of how classifying one’s players helps to make a better game. Ok, so we now know that 10% of our players are “Type 3a explorer-monkeys.” Now what? Does that mean 10% of our content should be exploration-focused?

Descriptive statistics is another research area where it’s important to take the leap to prescriptive recommendations. Knowing that most players on an MMO have at least five characters is nice, but not everyone is going to make the leap to the idea that players should have a universal alias that lets them talk to their friends regardless of what characters they’re playing at the moment. (A very nice feature found in City of Heroes/Villains) The specific recommendation that grows out of the statistics needs to be the point of the article/presentation, not left to the reader or tacked on at the end.




join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2006 CMP Media LLC

privacy policy
| terms of service