At the Games For Health conference, a team consisting of the president of developer ArchImage, Richard Buday, professor at Baylor College, Tom Baranowski, Ph.D, and USDA/ARS Scientist/Nutritionist, Debbe Thompson, Ph.D., discussed their collaboration on six different health and wellness video games, and how the expectations of researchers and game developers differ during the process of creating these projects.
Communication Is Essential, But Difficult
Communication, of course, is the key element. According to the speakers, game developers and researchers have very different expectations for ongoing projects. For example, game developers often want to test games with players early to find out whether players will like them, but researchers do not expect to present anything until it's 100% complete.
According to Buday, both sides use the term "alpha test" interchangeably but have different ideas of what it means. Baranowski said, "We don't understand each other's language" - which Thompson said leads to "pretty heated discussions." But she also feels that this is part of the natural creative process.
Scheduling problems were rampant, with researchers not adequately aware of the scope of game development; game development can't fit neatly into the schedule for many clinical trials. Buday explained that ArchImage's current game project is taking five years, despite initial estimates of three years.
Buday posits that the notoriously hazy science of scheduling game projects is complicated by the fact that research is not an issue for traditional developers, which can start projects with ideas as simple as "GTA4 is selling, let's copy it." Scientific researchers begin with more fundamental questions such as "What is a game?" or "What is play?"
Cost is also a major factor. While the research might expect that half of a $1M grant goes to the university while the other half is earmarked for the entire trial, a game developer would expect costs of $1M just for the game. According to Buday, in research, one third of the money is spent up front, while two-thirds is used in the trial. But in game development, the biggest part is the up-front cost of the game itself. This arrangement is not natural for those who work in research.
Buday further explained that ArchImage will engineer a game within a given budget, though it might not be everything researcher wants. Thompson cautions care with scientific content, however. In one project, goals had to be reworked three times; as with all game development, it costs a lot to redo things.
Part of the problem is that developers and researchers aren't familiar with each others' disciplines. Buday noted that researchers aren't familiar with programming/game design decisions, while developers are not familiar with how decisions are made in science. They have to be for things to get done. Things can get confused, leading to the question, "Who's running this show?"
Science Versus Fun
The question of science vs. fun is an important facet of this. The perspectives can be summed up this way: "This is about a serious disease. Fun has nothing to do with grant!" vs. "No fun means no game."
Buday demoed a game to a group of 200 doctors at an NIH conference; one doctor's reaction was, "Diabetes is a very serious disease. These kids are going to play this game whether they like it or not. They're gonna learn, gosh darnit!" Buday maintains that kids have a pretty sensitive "baloney meter" - they're going to know when they're being manipulated. This led to a major argument.
Thompson said, "as scientists, we just assumed 'it's a video game, it's going to be fun.'" When Buday explained that the researchers were leeching the fun out of the game, they had no idea. After a few years, however, the team learned. Thompson believes that when you work with kids, the project has to be fun - you increase the program dose by keeping them there longer.
Buday believes that doctors have a tendency to believe, "I know children... I can guarantee you that they'll find this interesting," despite kids saying it's not fun.
As game developers know, emotional, visceral, button mashing, thumb twitching, sweat on the brow - that's fun. Learning didactically... that's not fun, and there's nothing inherent in the material that makes it fun. However, this perspective can be difficult to sell to a researcher who makes this his life.
Communication is essential. Each side has to understand what is to be achieved. The developers and researchers had a series of discussions on roles, responsibilities, goals, expectations, and timeline. Some got quite heated, especially budget discussions - the budget constraints didn't allow for 3D characters.
The way to ensure communication is to make sure you're on the same page up front, before you get into design and development. Eventually they hired someone who's been both a scientist and a programmer. At every meeting, she understands potential miscommunications - and knows when the other side might think they understand, but don't really.
Flexibility is crucial. Researchers have the science and theory, but developers have the game design expertise in a way a researcher doesn't understand.
Thompson's advice for researchers? Don't be offended if you're told, "This isn't going to work." Buday added that researchers, shouldn't hand over large documents - "my programmers can't read." This works well in academia, as researchers love data and references - but game artists don't.