Serious Games Summit DC 2006
The Developer’s Keeper “I’m not just telling you how to find developers, I’m also telling you how to be a games producer,” Sloper says of his own advice. Finding developers is the easy part, he notes, mentioning web sites such as Gamasutra.com, Wikipedia.org, IGN.com, and Neoseeker.com as a very accessible and well-populated resource. Part of managing that contractual relationship between the serious games person and the video game developer requires money. Developers typically expect to receive some money up front upon signing, says Sloper, as they don’t necessarily have coffers to fall back on. “You pay on signing because the developer needs money to operate. It’s also a sign that you’re serious,” Sloper says. “They need enough to hold them over until the time that they’re going to be receiving the next check. For example, if the first milestone is going to be two months of designing the document ... between all that time that elapses, they need to have enough money between this check and that check.” And developers should be upfront about how much money they need and how often. “A really good developer will tell you [their burn rate] as part of their bid,” Sloper says. “Monitor, but don’t micromanage. It’s really important for you to trust them to be reliable and professional. ... You don’t really need to know all the ins and all the outs of how they’re making the thing that they’re making.” Feature Creep It’s easy to know when a developer is late in delivering a milestone, but it’s not easy to know when expectations aren’t being met. Those expectations, Sloper reminds people who are new to game development, should be 100 percent clear from the beginning. Documentation may need to be lengthy in order for the expectations to be totally clear. Feature creep, a term familiar to those already in the business of making video games, occurs when one or both parties want to add more to the game in development. What happens, typically, is that all the planning done in preproduction suddenly becomes upended. For business, financial, and time-management reasons, Sloper highly recommends rejecting almost all requests made for new features in the game, once production begins. “Once the specifications have been defined, don’t request new features and ideas. And once the specifications have been defined, don’t accept new features and ideas from the developer either,” Sloper advises. One exception, he says, is “when money is no object and it doesn’t matter when it’s finished; or if the whole thing is an exploratory venture.” And if changes are permitted, Sloper suggests using a formal change request process so that all facets of the new features can be tracked and managed. “Even the [change request process] should be formalized in the initial contract.” “What can happen is you’ll get an idea, and it’s a fairly significant change to the product, and it shouldn’t change the cost... or maybe you’re having a disagreement with your developer on some philosophical issue... it’s rare that two parties are going to see things the same way, and it’s rare that you’re going to change his thoughts. ... At least promise to think over his ideas, or suggest your ideas in such a way to make them sound like his ideas,” Sloper says. Mo Money “Make payments when due. Hopefully, payment is not his only motivation for working for you, but he has to get paid because we all have to get paid,” says Sloper of developers. He adds that people in the business of making games need not damage an otherwise beneficial relationship by not paying what’s rightfully owed. Even when things seem to be going right, something can go wrong. Sloper once produced a Nintendo DS game (Top Gun, Mastiff), for which he was the voice actor. He had an issue working with some people from Poland who had created some of the dialogue for the game because they were nonnative English speakers. Sloper edited a text document they had created for the dialogue, sent it back to the developers, and asked them to input the text back into the code. However, when the game was shown again to Sloper after the changes were made, he noticed that not all the edits were in the updated product. He discovered that the developers in Poland had not actually kept the text list separate from the code, so they were cutting and pasting the dialogue lines into and out of the code, which explains how they managed to not make all of Sloper’s edits. “That’s game design 101,” Sloper says of the amateur mistake. “‘All your base are belong to us,’” he jokes. From both a game producer’s perspective and a business management one, Sloper offers this list of books to help serious games makers find their sea legs. - Chandler, Heather M. Game Production Handbook.: Charles River Media, 2006. - Rabin, Steve. Introduction to Game Development:: Charles River Media, 2005. - Brooks, Frederick P. The Mythical Man-Month: Essays on Software Engineering: Addison-Wesley, 1975. - Peter, Dr. Laurence J. The Peter Principle: Why Things Always Go Wrong: Pan Books, 1970. - Parkinson, Cyril Northcote. Parkinson's Law: Buccaneer Books, 1993.
|
