Lessons Learned

Scott Brown and Hermann Peterscheck share the moral of the Auto Assault story

Net Devil President Scott Brown and Producer Hermann Peterscheck were on hand at OGDC to deliver a powerful talk centered on what they’ve learned from developing their flagship MMORPG Auto Assault. The talk was less a critique or post-mortem than it was a mentoring session for aspiring developers of grand-scale computer games like MMORPGs, focusing on development best practices and how to foster a strong and trusting relationship with a publisher.

While considered by many to be highly innovative, Auto Assault was commercially unsuccessful. When the game launched in April 2006, rumors sprang up of a disappointing online population of less than a few thousand players, reportedly by players using the /who command to count server populations. Peterscheck pointed out that one big reason for Auto Assault’s poor reception was the lack of familiarity. For example, with the fantasy genre, the bread and butter of the MMORPG industry, it’s easy to know from experience that leather armor is less durable and lighter than plate mail. But in Auto Assault, is hardened nanoplasteel armor better or worse than xeno alloy armor? We all know that the ability “maul” probably causes a damaging melee attack or that “taunt” will probably draw an enemy’s ire, but what does “hazardous cleansing” mean? (With a smile, Peterscheck noted that even the dev team didn’t know what “hazardous cleansing” means.) These disconnects, while subtle, steepen the learning curve of a futuristic game.

Scott Brown (left) and Hermann Peterscheck

Much of the talk centered on NetDevil’s relationship with Auto Assault publisher NCSoft. Scott Brown was careful to note how supportive NCSoft was during the development and launch of Auto Assault; NetDevil set their own milestones, for example. Still, there were lessons to be learned on developer / publisher relations, even in the enviable relationship NetDevil enjoyed with NCSoft.

Brown mentioned the “dread of cancellation” numerous times, and how injurious this spectre was to the creative process of designing a game. “As a small developer, getting cancelled could mean closing your doors,” he noted. Brown surmised that while meeting milestones is no walk in the park, it’s easy to get tunnel vision and meet your deliverables at the expense of the primary goal: creating a great game that makes lots of money.

Cancellation is a publisher’s prerogative, however, and Brown mentioned a few strategies to counteract the seeming threat and facilitate the development of a great game:

A “constant streaming build” - NetDevil now has a pipeline by which a constant streaming build is delivered to the decision-makers at a click. Everyone is on the same page with regards to where the project is at, what still needs done, etc. and the development team is far more careful about “checking in” a deliverable when the project is live for all to see.

- NetDevil now has a pipeline by which a constant streaming build is delivered to the decision-makers at a click. Everyone is on the same page with regards to where the project is at, what still needs done, etc. and the development team is far more careful about “checking in” a deliverable when the project is live for all to see. The “thin slice” or “one great level” approach – Rather than iterating for map, lighting, objects, characters, animations, etc., NetDevil now tries to build one great character (instead of 12 mediocre ones) with one great skill tree (instead of 4 half-baked) ones in one great map - you get the idea – but the idea is to have a full-fledged play experience as soon as possible and build from it in small steps. This approach has its design advantages and hype disadvantages, but it insures a developer against cancellation in that a developer can always release a product if cancelled.

– Rather than iterating for map, lighting, objects, characters, animations, etc., NetDevil now tries to build one great character (instead of 12 mediocre ones) with one great skill tree (instead of 4 half-baked) ones in one great map - you get the idea – but the idea is to have a full-fledged play experience as soon as possible and build from it in small steps. This approach has its design advantages and hype disadvantages, but it insures a developer against cancellation in that a developer can always release a product if cancelled. Change control – This is something that NetDevil seeks to build into every contract; reason being that when a contract is signed, developers don’t know exactly what they’ll be doing in 2 months (let alone 2 years!) and that it’s a pity to have to get the lawyers involved to change the game for the better. Rather, a developer and publisher should seek middle ground between accountability and creative freedom. Brown noted that moving to a scrum approach to software development rather than the traditional waterfall method improved

Delay at the beginning, not at the end – While money has a way of growing expectations, in the long run it’s far cheaper to take your time building a solid concept than fix everything you created and push back launch 6 months (as with Auto Assault). Launch delays also pop the bubble of momentum and hype that builds up in a gaming community, making it harder to sell the game when it finally arrives.

Brown and Peterscheck also discussed some of the best practices they’ve put together for the design team:

Force your team to play the game – It sounds harsh, but Peterscheck pointed out that if your team isn’t playing, why should you expect the public to play? If your game isn’t fun, your team should be discovering and taking note of why it isn’t fun. People in general are far more likely to fix things that bug them personally rather than fix things others are complaining about.

– It sounds harsh, but Peterscheck pointed out that if your team isn’t playing, why should you expect the public to play? If your game isn’t fun, your team should be discovering and taking note of why it isn’t fun. People in general are far more likely to fix things that bug them personally rather than fix things others are complaining about. “There’s no such thing as a good game with a bad frame rate” and “No crashes, ever.” - Technical and programming considerations are paramount; nothing is more frustrating for MMO players than to play for 8 hours and watch it all disappear due to a rollback. Players may complain about design, but they won’t forgive instability.

and - Technical and programming considerations are paramount; nothing is more frustrating for MMO players than to play for 8 hours and watch it all disappear due to a rollback. Players may complain about design, but they won’t forgive instability. Tools are top-priority. – Brown got a chuckle out of the room when he suggested that you place your most cantankerous dev on design tools, since that programmer would fix problems quickly; he doesn’t like to be nagged, in other words. Both devs encouraged the use of third-party tools to decrease expensive design time, and put the best programmers in charge of designing and adapting tools for the team’s use.

– Brown got a chuckle out of the room when he suggested that you place your most cantankerous dev on design tools, since that programmer would fix problems quickly; he doesn’t like to be nagged, in other words. Both devs encouraged the use of third-party tools to decrease expensive design time, and put the best programmers in charge of designing and adapting tools for the team’s use. Polish as you go, don’t wait for the end. – Brown pointed out that “two hours of bad content equates to no hours of content.” This approach ties into the “thin slice” approach mentioned above.

– Brown pointed out that “two hours of bad content equates to no hours of content.” This approach ties into the “thin slice” approach mentioned above. Beta testing is marketing, not testing. – While certain things like stress testing can only be done during beta, a dev team shouldn’t rely on the beta test to point out non-technical flaws .

– While certain things like stress testing can only be done during beta, a dev team shouldn’t rely on the beta test to point out non-technical flaws . Manage expectations, “don’t drop bombs” on the community – It almost goes without saying: developers should only discuss what they’re 100% sure will be in the game. Indulging speculation and the over-promise / under-deliver approach only leads to disappointment.

While Scott Brown and Hermann Peterscheck’s talk was more didactic than deductive, it was exciting to see developers working across company lines to share their challenges and lessons learned. For more from NetDevil (including the latest on their most exciting project, the Lego MMO) please check out Cody Bye’s interview with Scott Brown and Hermann Peterscheck at OGDC 2007.

Return to the OGDC Portal Page