     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Managing An Online Game Post-Launch Managing the Expectations of the Players
Now that you have the right people in place and everyone knows who is supposed to be doing what, just how do you manage this thing, anyway? The first step is getting a handle on just what you're doing and relaying that to the players. This is one of the critical issues facing any online game post-launch, and it involves an arcane black art known as "managing the expectations of the customers," otherwise known as your players. It's very easy for your Marketing and Public Relations departments and player relations, community relations, and development teams to speak separately to the player base or online press and promise or imply different features, fixes, and changes. There is one cardinal rule to always remember when communicating with your players: Anything and everything posted or mentioned in public by a member of the team, no matter how amorphous, will be taken as gospel. Everything said by any employee will be immediately taken by your subscribers as being set in stone and in the development track pipeline. Take, for example, Ultima Online (UO). At the game's launch, there was no coherent policy or procedure for communicating with the players. For the most part, the developers and designers posted what they wanted to post, whenever they wanted to. The various members all frequented different player-run fan sites and engaged in "theoretical" discussions on features and changes to the game and almost never relayed these discussions in whole to the rest of the live team. When these discussions didn't result in changes to the game, this led to charges of unfulfilled promises and gave a black eye to the game. Once, one of the designers on the live team was asked by a player online if necromancy and alchemy could be added to this medieval fantasy RPG. The designer, before consulting others on the team, said he liked the idea and would bring it up with his associates. Within 24 hours, the UO fan sites were abuzz with the news that necromancy and alchemy were coming to the game. The designer tried to stem the tide by saying, "Hey, we're just thinking about it," but it was already too late. Soon, it was announced that the features were on the development list and there they sat for years. The designer wrote a check that Origin Systems had to cash, gave another black eye to the reputation of the game, and incidentally, created a running joke at UO's expense that still exists today. The Four-Step Notification Program So, what is a poor live team to do? You can't not talk to the players; open communication is a necessity in this market, not an optional exercise. It looks a lot like a "damned if you do and damned if you don't" situation, doesn't it? It's actually much easier than it looks from our examples. What you need is a cohesive internal organization that controls the flow of information from your own people on the live team to the players and back, and a process that allows the controlled and managed flow of information to the players. What the players want to know is: What is broken, what is being fixed, and what cool, new stuff will be added, and when? They want to get inside the heads of the live development team and understand what they are thinking and planning, so they can plan their own in-game time and strategies accordingly. In other words, they want to feel like they are a part of the process. That means they want current information, they want to know that their opinions are being delivered and considered by the development team, and they want some advance notice regarding major changes. Delivering this kind of coherent short-, mid-, and long-term information and coordinating player responses starts with a four-step process managed by community relations on the web site and in the message forums. The following process has proven successful in helping to manage player expectations in several games:
There are several variations on this process that can be used; for example, the "Update Center" web page from UO is shown in Figure 1. This is a good example of a player notification system.
Using the basics of the four-step process, the community relations team for UO coordinates with the producer and other team members to get information and post it on the correct web page. Then, on the message board forums, they coordinate the discussions concerning these posts and relay the critical discussions. Thus, they expanded on the minimal four-step process. Instituting such a player notification process right from launch day will save the live team from plenty of grief down the road. However, there is a major caveat: All members of the live team have to buy into the process, and that means instituting a general prohibition or restrictions on which team members can post, when they can post, and on what subjects. In other words, team members have to be willing to gag themselves and clear all communications with the players through community relations. This can be as drastic as requiring all team members to refrain from posting without first clearing it with the community relations team or as loose as community relations establishing strict rules and guidelines to be followed when posting and working with the team members over time to refine the process. Whatever is instituted, it must be acknowledged that community relations is in charge of this aspect of player expectation management and that what they say goes. The Rules of Managing Player Expectations PW gamers have a wild and wooly streak to them and are quite capable of being caustic and rude in posts. This most often happens when they perceive that a live team has treated them, as a class, with disrespect and dishonesty. Nothing will inflame players more than an unannounced change in a game mechanic or character ability that erases dozens or hundreds of hours of playing time. Lying or being evasive about it before or afterwards only compounds the problem. The whole concept of unannounced and/or hidden changes is considered disrespectful, as if the time a player puts into a game means nothing to the company and can be wasted at a whim. For some reason, many developers feel the need to hide takeaway changes. Much of this is probably to avoid predictable player outrage before the change takes effect. They'd much rather just face one huge blast of pain than have to discuss it for several days or weeks with the players. The problem with this method of making changes is that each instance causes the players to lose some trust in the game and the developers, and that trust is the most important asset any team has. Building trust means building loyalty, and loyal players become loyal subscribers for months and years. It builds patience, and patient players will work with you on just about any change you want to make. It is a karma bank; the more good karma you deposit, the more you can pull out when you need to make really drastic changes. In that sense, building trust by managing player expectations simply means following these rules:
Not all these rules will work in all situations. In general, however, they are a good baseline for helping to manage the players' expectations. The Service Philosophy: Acquiring and Retaining Subscribers Nearly every online game developed by a retail computer game publisher to date has made one error during design and launch: They have treated the game as if it were any other computer game. That has been their experience and forte: building a game, launching it, patching it a couple times, and then moving on to the next project. This is akin to Safeway or Albertson's opening a new grocery store, stocking the shelves once or twice, and then ignoring the store and moving on to the next town. Eventually, the shelves will become empty and shoppers will stop going there. Unlike other computer entertainment products, however, massively multiplayer role-playing games (MMRPGs) require more forethought during design and more work after launch. Knowing this now, your game has (we hope) been designed and developed with two cardinal rules in mind:
Most MMRPG developers don't build out their game following these rules and end up paying for it later on. For example, take volunteer organizations. Until recently, these were a standard part of every PW and most games launched with a volunteer group in place. However, three of the top four MMRPGs - EverQuest, UO, and Asheron's Call - all launched without adequate tools or organizations built for recruiting, training, and monitoring/logging the actions of their volunteer support corps, which are good retention tools. They have paid for this error in sometimes very slow response times to player help requests. Players can wait hours for a request to be attended to. They are all playing catch-up in this regard. Understanding from the start that you are providing a service, you need to keep in mind both acquisition and retention features, you need to build the tools and features necessary to support the five critical elements necessary for the success of any online PW, and post-launch, the team needs to pay attention to these tools and use them. The following elements are interlinked necessities for any MMRPG. They can each be built separately, but they work best when all are built into a game and inter-react with each other.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|