Disaster Control

Technology can be a perverse creature. Most PWs experience a few bumps during the first couple of weeks of the launch period. If it isn't a piece of hardware failing catastrophically at exactly the wrong moment, it is a hole in the design that no one caught during testing that plays havoc with the player base, or a hidden bug that decides to pop up the day after launch and start crashing the client or servers. Even if you have an incredibly stable game service at the end of open Beta and it is apparent to you that there will be no huge problems with the code or service on launch, it just makes sense to have contingency plans in case disaster does decide to strike. You have to consider weird and unlikely scenarios, as some things are completely out of your control. What if your Internet access provider goes down for an extended period on launch day, as happened to one launch in 2001? Or, what if one or more key team members become unavailable for some reason, or your test server cluster refuses to boot at exactly the wrong moment because someone on the cleaning crew was messing with it the night before? What if something as simple and uncontrollable as the weather suddenly turns nasty and the power in the building goes out?

These situations may be out of your control to stop, but that won't be the way the players will see it. If the Internet access into the game servers goes black, it is going to be your fault, plain and simple. It's your game, isn't it? Fix it! What am I paying you chumps money for, anyway? How you handle these problems internally and with the player base as they crop up is going to be a key factor in the retention rate ”that is, converting trial players into paying subscribers. Therefore, it makes sense to do some contingency planning on how disasters will be controlled.

Internal Disaster Control

The producer, network operations manager, manager of player relations, and manager of community relations should form the core of the disaster planning team and start meeting well before the launch to construct a disaster control plan. The plan should include the following elements:

• A notification process that puts everyone on the various teams on full alert for a possible all-hands drill for 16 “24 hours on launch day.

• A meeting or publication schedule that informs everyone in the organization that, if the worst happens, all teams may have to provide round-the-clock staffing until the crisis is over.

• Bug lists ”Understand just what bugs remain and publish that list internally to be prepared to deal with them.

• Customer support ramp-up ”Make sure the CS staff is fully staffed and trained and ready to pull double shifts if necessary.

  The policies, procedures, FAQ sheets, and problem-response answers that player relations will be using should be double-checked. A series of meetings with the staff should be held to go over them one more time.

• Communications plan ”Have the community relations team create a communications plan for linking with the producers , getting updates from them, and constructing timely public messages to inform the players of the problem, what is being done to fix it, and a general estimate of the time when the fix is expected to be completed.

As launch day approaches, the disaster planning team should meet regularly with development, player relations, and community relations to go over the plan, make or note any necessary changes, and discuss the plan in-depth with the teams. There should be a final all-hands briefing on the disaster control plan the day before the launch is scheduled to take place.