Ten Ton Hammer - Taking MMO Gamers to the Next Level!

Grab steel, ye scurvy scoundrel!

A Pirates of the Burning Sea Q&A with Flying Labs Software’s Lead Designer, Kevin 'Isildur' Maginn

Questions by Cody Bye

When you work in the MMOG industry long enough, you get used to announcements. Developers and publishing houses are often picking up new licenses or buying up smaller studios, desperately trying to generate a media frenzy around their games and software library. Some announcements you just shrug away, considering them to be simple PR fodder.

Every few months, an announcement lands in your email inbox that takes your breath away. That was the situation when I was directed towards a recent dev journal entry on the Pirates of the Burning Sea main site. The news was enormous: Flying Labs Software had partnered with Sony Online Entertainment’s Platform Publishing label in an attempt to get Pirates of the Burning Sea on retail store shelves across the globe.

Coincidentally, a Q&A from Flying Labs Software’s lead designer, Kevin Maginn, had recently appeared in my email inbox, and in the contents he hints at the big announcement that arrived this week. However, the majority of the interview covers functions of PotBS gameplay issues, and I hope you find the Q&A informative and entertaining!

Avatar combat is going to be discussed in detail in the near future.

Ten Ton Hammer: First off, thanks for taking the time to talk with us!

You just released two very informative developer logs almost back-to-back, one on June 6 and the other on June 7. Why the sudden amount of info coming down the pipeline? Have you begun the “ramp up to release” marketing phase?

Kevin: Honestly, I think Aether’s just getting better at hassling us for updates on what we’re doing.  But it’s true that as we get closer to launch, we’re more comfortable giving out the details of our systems and content – we’re not as worried that it’s going to change, because we don’t have time to change it now even if we wanted to.

We’ve got some more pretty in-depth developer logs coming up soon, as well.  You’ve probably seen David’s detailed look at the ships; we’re going to be talking about avatar combat and the auction house in the near future, as well.

Ten Ton Hammer: Speaking of the developer logs, the one titled “Funderdome” discusses how your team had to cut down the number of features implemented into the game (via the “Thunderdome” meeting), separating those elements that can be accomplished between those that can’t. This seems like a very efficient way to insure that tasks get accomplished; who first thought of the idea and how were the initial design features determined to be worth putting into the game? What if a feature was so important to a “pirates” game that you determined to implement it, no matter the cost?

Kevin: To address your last question first: if it’s so important we cannot ship without it, then we do it.  That’s why we ended up including avatar combat.  We’re realistic about what we can and can’t do, but we’re determined to release a great game, and as we’ve demonstrated, we’re willing to make sacrifices to make the game match our expectations.

The Thunderdome grew out of the necessity to cut down on certain features that the design team couldn't implement in a finite amount of time.

Thunderdome really grew organically out of necessity.  We have a laundry list a mile long of ‘neat stuff’ we’d like to have in the game, and we have a finite amount of time left to do it in.  Some of the ‘neat stuff’ turns out to be not optional; other stuff turns out to be cheap in terms of development time, relative to its impact on the game.  So we get together to talk about what we can and can’t do, and more importantly what we absolutely have to do versus what we can ship without.  At some point, Paul, our Executive Producer, or John, our Producer, started calling it Thunderdome (you know, ‘two ideas enter, one idea leaves!’) and the name stuck.

Our criteria are pretty straightforward: First, is the feature non-optional?  If a game system is broken without the feature, or gameplay is terrible without the feature, it’s probably not optional, so it gets prioritized to the top of the list.  Second, does the feature have a large impact?  We could add a dozen tiny features that wouldn’t have much effect on the game at all, but that’s probably not a good use of our time.  We’re looking for features that improve gameplay for as many players as possible – a kind of ‘Design Utilitarianism.’  Third, is the feature cheap?  We have a very limited amount of content design time, and an even more limited amount of programmer time.  The best features to be considering this late in the project are the ones that don’t require any programmer time at all; they’re still not ‘free’, because QA still has to test them, but they’re at least possible.

So a feature survives Thunderdome based on how it performs on those three metrics – and even then, we always stop to ask ourselves: ‘Can we ship a fun game without this?’  The truth is, it’s very late in the process to be adding anything new to the game, so to justify doing so, we have to be very focused and very confident in the feature.