Pirates of the Burning Sea: A Post-Partum

Joe Ludwig (Chief Technical Officer, Divide By Zero Games)

Pirates of the Burning Sea is a game that includes 4 nations, 5 careers, 3 sword fighting schools, a player-driven economy and tactical ship combat (one of its main highlights among fans). It began in October 2002 with 4 people planning on a 6-12 month development schedule. It was launched January 22nd, 2008 after accruing 66 additional development team members – and oh yea, over 5 years had passed too. D’oh!

Here are some lessons that the team learned over the years.

Lesson #1: Know how big your game is when you start

For five years, the team was constantly only 12 months away from being done, increasing the scope of the game a little bit each month. This scope creep also led to several downsides:

• Shoddy tools – development of new features constantly had tools being tossed out and new ones being created. There were never any well-polished and useful tools
• Never a good time to hire – bringing a new programmer to the team brought many months of training along with him to get him up to speed and keep him up to speed with the constantly increasing scope.
• Never good time to fire – once a programmer was trained up, letting him go became an insanely expensive proposition.

Lesson #2: Figure out what game you’re making as quickly as possible

Four separate visions of the game led to conflicting ideas as to what the game should be.

• The lead designer wanted deep combat simulation and a realistic, historic setting (this became the core vision eventually)
• The executive producer wanted an MMO, but with good graphics, foundation in naval traditions, and Starfleet Command-style combat.
• The content lead wanted rich single-player style content and an emphasis on storytelling
• The lead programmer (Joe) said “no” to everything and wanted a 6-month project, a minimal feature set to grow after launch and keeping the costs low so a tiny player base could pay for the team

The team is still paying for the decisions made. Good graphics caused higher system specs and needlessly complex ship models; naval traditions caused a decrease emphasis on the Pirate flavor; single-player content caused lack of focus on group play.

Lesson #3: Don’t make scheduling harder than it has to be

The team over-thought many of their scheduling issues, using Excel for simple task lists, which was easy to track but did not support dependencies and were only able to focus on one milestone at a time for 2-3 months. It did not scale well past 15 people. They also tried critical chain using Project, which worked well from 20-50 people and tracks dependencies, but it carried a high overhead. When the team grew even larger to 60-70 people they started using task lists in email and agile development in 1 month sprints, which shoved more scheduling work onto leads and required some QA time after sprint (3wks developing, 2wks fixing bugs).

Lesson #4: Don’t save polish for the end

The game launched with thousands of known bugs, which the testers were good at finding but the programmers had no time to fix because the service was now live. Only critical bugs ended up being fixed in the last 6 months. Programmers would leave uncommon bugs for later and never return to them, but with thousands of players, uncommon bugs become common. Because mission designers always had new missions to create, basic playability problems existed in many.

Lesson #5: Don’t abandon content quality in pursuit of content quantity

At some point they decided it would be a great idea to have 1000+ missions, but ended up instead with cookie-cutter missions and a lot of repeated content between nations.

Lesson #6: Deal with client performance at the start

Make sure you target the minimum spec for your game from the start. It’s easier to scale up than down so make it as low as possible. Make the game look great on the minimum spec and test it there constantly. Define art budgets based on the minimum spec.

Lesson #7: Make sure everyone is on the same side

Mission designer were throwing incomplete missions over to QA which was reporting back a lot of legitimate bugs but also a lot of spurious bugs. Both sides developed an antagonistic relationship with each other rather than learning to work together. One tester even posted countless unimportant issues just to try to draw attention to himself as a diligent tester – make sure only bugs that need fixing are the ones getting reported.

Lesson #8: Don’t be afraid to get rid of people who aren’t working out

The team let go 5 people in 5 years – make firings strategic. If a person fights constantly against the team or makes all the people they come in contact with unhappy, they are simply not worth keeping. Period.

Lesson #9: Take care of your company culture

Make sure your team is happy. People enjoyed working on the project (good-natured ribbing and photoshopping, afternoon coffee trains). There was an open door policy and only minor crunch time at the end of some sprints. The CEO was quite the cheerleader, motivating people, and there was a very low turnover.

Lesson #10: Closed beta shouldn’t take two years

2 years of beta burned out valuable community members and distracted the team from implementing core systems. It also didn’t provide much actionable feedback as the game was constantly in too much flux and the population was too low for too long.

Lesson #11: Hire some experienced people for key positions

Only three team members had previous experience launching an MMO title, and only two of them were in lead positions. The art department was staffed mostly by former interns, who were not entirely reliable at first. The content department was mostly entry-level people. Contracters were never very well implemented thanks to the projects shaky schedule. Some more veteran team members could have avoided problems.

Lesson #12: Build more tools

One of the biggest regrets was not having the proper tools to make many tasks easier. Don’t just build them, make sure they become an integral part of the development process and are not tossed out with each iteration.

Lesson #13: Hire a great art director

But do it at the beginning of the project instead of halfway through

Lesson #14: Players love character customization

17 slots with a dozen different pieces per slot and two colors per piece equals millions of combinations, almost all of it available at initial character creation. Data showed that players were spending 45-60 minutes creating their characters – not out of frustration or difficulty, but just playing with all the options, including peg legs of course. Unique clothing could be unlocked by missions and appearance didn’t depend on stats.

Lesson #15: Unique combat systems are a blessing and a curse

Combat system hailed as best aspect of gameplay, with simulation of armor faces, gun recharge (up to 5 batteries), crew status, sail status, position of ship to enemy, land and wind. Very polished and well tuned after 7 major iterations, places great value on player skill.

Unlike any other forms of MMO player combat, which makes it hard to teach, and is slower-paced than many other game’s combat systems. Also requires much more attention that standard MMO combat as well as more skill at the high-end.

Lesson #16: Don’t try to cram and entire new combat system in a year

Team attempted to implement avatar PvP combat, but did not come out nearly as clean as ship-to-ship combat, was added too late to have time to iterate.

Lesson #17: Love your community and they’ll love you back

Everyone on the launch team writes dev blogs and posts to the forums. When they screw up, they own up to it immediately. The team listens to players and often makes changes to the game based in their feedback. Community relations are considered every employee’s job.

Even negative game reviews have pointed out how active the team is. Players ended up being more likely to give team the benefit of the doubt. Forums matured much more than many other games’. Team cites use of a dedicated community director for success of forums and community as a whole

Coverage by Drew Sikora

Page 3