John Hopson has a very clever column in Gamasutra entitled "We're Not Listening: An Open Letter to Academic Game Researchers". It mainly deals with the gap between academic research about video games and the practitioners (who, as a matter of fact "never read this work nor attend these conferences"). He only observe that "individual designers, producers, and developers listen, but the industry as a whole has ignored an entire field of study dedicated to studying it" which is entirely true from my experience. The author explains how for practioners, the average academic pieces of work concerning games "just doesn’t get the job done". The article is hence for researchers who want to "transfer" some ideas and concepts. He then gives tome tips for bridging the gap:
Rule #1: Return on Investment: In order to convince the audience to spend that time and money, the researcher has to show clearly how that investment is going to pay off. This needs to be something beyond “this will help players identify more strongly with the main character”. (...) if the research doesn’t include specific practical recommendations or a measurable impact on the final product, don’t bother trying to sell it to the industry. From the average industry professional’s perspective, there are only two things of value being said in a research presentation: the recommendations and their predicted effects.
Rule #2: Speak The Language: The goal here is to convey information clearly and easily to specific types of game industry readers. They’re already going out of their way to read it, so make it as easy as possible for them to assimilate your proposal. (...) Think of it like grant writing. (...) Don’t write a research paper, write a business proposal. Start fresh ( Start a new slide deck and add every slide with a view towards the new audience and what it needs to know.) Lean and Mean. Think one page. (...) Use examples from bestsellers. A good example from a popular game is more effective than a great example from something they’ve never heard of.(...) Look forward, not backwards. Lose the lit review. Don’t quote references. Don’t worry about background material. This is about specific, concrete recommendations and the impact on their game
Rule #3: Smaller, Faster, Cheaper: 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 best recommendations should be: Feasible for one person to implement. (...) scalable (...) modular (...) parametric.
Rule #4: Prescriptive, Not Descriptive: 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 (...) Descriptive statistics is another research area where it’s important to take the leap to prescriptive recommendation (...) The specific recommendation that grows out of the statistics needs to be the point of the article/presentation
Rule #5: Prove It: The best way to do this is to provide an active, working example of your recommendations, with numbers to back it up. Pick a currently popular game and put your idea to work
Rule #6: The Customer is Always Right: A lot of research being done on games simply isn’t relevant to the day to day work of the industry. It’s not bad research; it’s just focused on things that the industry doesn’t particularly care about. Fortunately, there’s a really straightforward technique for ensuring that your work is relevant to industry game developers: Ask them. Ask them before you do the work.
Why do I blog this? this is of interest to me because I am an academic (completing a PhD about CSCW and games + doing some user experience projects about video games) who work with game companies. Judging from my experience, I fully acknowledge this observation. However, this does not mean that nothing can be done.
From my experience, some of the issues can be discussed. Sometime it could be even worse than what the author described. For instance, in lots of cases, game research (for a company) cannot be applied to the project that's currently being developed but for the next ones (because the production process is soooooo tight). In that case I find it interesting to use the results to elaborate more with game designers about the consequences of the study (used hence as food for thoughts for future design and gameplays). When I started doing game research for private clients, I was slightly disappointed by the difficulty in applying results and recommendations to production but then I understood that (1) the prescriptions could be applied for next projects (2) all of this could be of interest to create a "user-centered" culture in the game design area.
I also acknowledge the presentation format, there is no point of giving game designers huge reports. Of course, some are interested by the academic work and presentation but in terms of pragmatic communication I usually do short half-an-hour seminar to present study results with simple handouts. This does not prevent the publication of researchers papers afterwards (if it's possible in terms of disclosure9.
I was also interested in this idea of foreshadowing and how it can improve player's self-awareness in space and how it can affect the decision making process:
