Dissecting our Baby: Auto Assault Post Mortem - The Good, the Bad and all the Ugly
Carolyn Koh files her second report from the recent Online Game Developers conference. This time, she sat in on a talk with Scott Brown and Hermann Peterscheck from NetDevil, the company responsible for Auto Assault. In this talk, Brown and Peterscheck discuss their missteps while brining Auto Assault to market.
Day two of the ODGC saw me at the Auto Assault Post Mortem - a lecture presented by Scott Brown, the President of Net Devil and Hermann Peterscheck, the game's Producer, as they shared with conference attendees their missteps while brining Auto Assault to market.
"Want to make a great game?" asked Scott Brown, "Don't make a deal with milestones. There are better ways to do a game deal."
What Scott meant was that when it came to game design and delivering an MMOG, there are better measurables out there than milestones as contracted payment deliverables. Per the normal business models, a detailed time and progress schedule is tied to payment. However, with games development, planning out what you will be doing a year from now (or two, or three) is impossible beyond the most basic set of features. Without a dynamic and reasonably simple change process, developers will spend an enormous amount of time doing the wrong things at the wrong time or in the wrong order to meet the milestone schedule in order to be paid.
Most developers are unable to cover the costs of teams, in the event of missing a milestone. This puts incredible pressure on the publisher to pay for milestones they felt were not met, or cancel the project.
;)
"My house has been mortgaged and re-mortgaged too many times to count," quipped Scott, as Hermann elaborated on the problems they faced.
He gave much kudos to NCSoft for their role as their publisher for their understanding and their direction and advice, as the two companies kept in close touch throughout the development process.
Scott could not stress the need for communication enough. "Don't give the publisher the same build list you are delivering to the public," he urged. "Give them two lists. The work you've done and the one for public consumption." From that, they went onto Auto-Assault itself, peppering their talk with anecdotes drawn from their development experience, sharing unashamedly their trials and tribulations, and the lessons learned along the way.
The Good - Auto Assault was an original idea. It avoided competing in an already flooded "fantasy" market, and targeted a large underserved market, those who liked the idea of playing in a post-apocalyptic world, one that was not a fantasy world of dwarves and elves. The idea of interacting with the physical environment was cool. Blowing things up into pieces was cool. "Auto Duel / Diablo on Wheels" was a cool idea.
The Ugly - The main problems were the flip side of the good. Players had difficulty identifying with vehicles and asked for avatars. There were difficulties with driving controls. Game concepts were unfamiliar. "Everyone knows what a Fireball does," said Hermann, "even I'm not sure what Hazardous Cleansing does."
They admitted that Auto Assault went into beta too early. Beta too early = bad press and players trashing your game. "Getting everything crappy and calling it alpha, a little bit better and calling it beta is just plain wrong," Scott said. "It's great for stress testing, but it's not for testing functionality. Like it or not, beta is marketing. It's when the public is playing your game and you want to put your best foot forward."
;)
"Polish as you go," Hermann exhorted. "Optimize now. Bad frame rate = bad game."
Scott was candid talking what went wrong with Auto-Assault. "Performance," he said. "We had bad frame rates. Our specs were too high. It's too complex. Only our hard-core players are still playing it. They dig the complexity."
"We threw too much at the players," Hermann agreed. "It was too much, too soon. Entry should have been easy. We should have been playing our game ourselves. The question you should ask yourself is 'If your own Devs aren't playing the game... who will?' Play your own game early and often. If people in your office are not playing your game, people outside will not either."
That exhortation segued into their current focus on testing.
"One of the best ways to test is to bring an outside group in. Video tape them playing and show that video to your team," said Scott, elaborating on the methods available these days, where the reactions of players can be caught by cameras that are focused on them as they play.
Their main point is: Performance + Easy + Pretty = Fun! This is, of course, an over-simplification of the entire process, but in general, if a game looks good, plays well and is easy to learn, people will have fun. Don't start off alienating your player base by killing them, delivering crappy frame rate or not telling them what to do.
;)
The lessons learned from Auto Assault:
- Maintaining a good publisher/developer relationship is important.
- Treat innovation with caution.
- Play your game early and often.
- Polish as you go.
- Avoid complexity.
- Expect change and plan for it.
- Focus on one good instance first, and then add content.
The one caveat they left the audience with is the one we have heard over and over again... "You only launch once."
