10/16/2008    |    Devlog    |    Misha    |    Discuss

Aether wanted me to share with you a bit about how the AvCom Revamp looks to me, the Producer. It looks like a bunch of work, is how it looks!

MMOs change all the time. Known fact. Almost the definition of an MMO. We buff/nerf outfitting for balance; we add new ships; we even add new features. We’re set up to deal with the fact that we’ve got a live game that could need a hotfix at a moment’s notice and possibly the next batch of changes up on Testbed but even so we’re working on the next batch of changes beyond that. (It’s been a learning experience to get efficient at that but we just about have it down now.)

How do we deal with a major change that touches almost every aspect of the game and needs multiple milestones to complete? New features, we just don’t give you access to until they’re ready to go. Balance changes, we try to push in batches so we can see how one set does before making another set of changes. For the AvCom Revamp, though, our usual process is insufficient. We couldn’t begin the process without breaking the entire game and having it stay broken for some unknown number of months.

We deal with having 1.8 on Live, 1.9 on Testbed, and 1.10 under development by having separate branches in our version control database. So the first step wasn’t too hard: just add another branch for the AvCom to work to go in. Even that wasn’t so easy. Some folks needed larger hard drives installed because having the retail copy of the game that you play plus multiple branches of code and debug files takes up a lot of space. But adding hard drives and merging changes between code branches is something we do regularly so we got that done in short order.

We can’t merge that branch into the main branch until we’re sure the AvCom Revamp will be ready to launch by the end of that milestone. So, at the beginning of each milestone we ask: “Do we think it’s less than a month from being done?” So far, the answer has been “LOL” so the AvCom team keeps trucking in that separate branch and we merge changes into it but not out of it regularly. But merging changes from it when the time comes will be quite the undertaking.

The next hurdle is personnel management. Most folks are working to a schedule – you must be doing new stuff this week; you must be fixing bugs that week; you must be pencils-down this date. The AvCom Strike Team isn’t entirely working on that schedule. And yet we do things in milestones for a reason to iterate the work and ensure it gets tested regularly and stays stable and not too far from “ready to ship.” And some of the folks on the AvCom Strike Team also have non-AvCom tasks assigned so they’re working against two different clocks. But we’ve managed all that before, too, with some of our new features so manage it we do.

The next challenge is the vastness of the effects of the change. Besides revamping every skill (which we’ve sort of done before on the ship side), we’ve changed every AvCom animation, every AvCom effect and, every AvCom mission. It has been a bit of a challenge to decide when to start on those missions. On the one hand, if you start too early, Isildur will suddenly turn left at Albuquerque and you’ll have to re-do it all. On the other hand, if you wait too late, Isildur and play-testers don’t have enough content to test with and can’t make decisions about what changes are needed. Also, there’s just a lot of missions so changing them and testing them all takes a lot of time and we want to start sooner so we can get done sooner.

New content is also needed: The AvCom tutorials need more than a simple revamp for balance and such – they need to be redone from the ground up. In-game help needs to be re-written. Plus we want to warn you that we’ve made this change and not everyone reads the forums so we want to do some additional player-education stuff.

The next challenge is getting player feedback and incorporating it. Dissatisfied with how we handled the Ad Hoc changes? Us too! Want us to avoid making those mistakes again? Us too! But did I mention this stuff is in a separate build and can’t be incorporated until we’re sure we have less than a month of work left? That means we can’t put it on Testbed. And we give you Testbed builds via SOE’s LaunchPad they basically have two installers for us: live and testbed. So we need a separate server and a separate distribution mechanism. Servers aren’t too hard: We know how to make servers. Distribution doesn’t have to be hard: We can put a zip on a torrent. But we want to actively engage the players and manage the feedback and that’s not so easy if anyone w/ a Pirates account can download from a torrent and play this completely broken thing. So we don’t want to just put up a server and just put up a zip on a torrent.

So we start with internal play-testing with local players only. Just a few of them. Then we get a few more. Then we set up a mechanism for acquiring feedback a little more formally than sitting and chatting or sending email. And with each test, we meet to discuss feedback, make changes, make a new build, decide how to do the next round of testing, and go from there. Fraxl will tell you more about all that.

Getting a regular build through QA, through Testbed, and on to Live is a multi-day, many-people-involved process. The logistics of managing the AvCom Revamp has been quite a bit more challenging and we’re not done yet. Wish us luck ;)

10/16/2008    |    Devlog    |    Misha    |    Discuss