Managing the Expectations of the Players

"What it means is that they (the developers) are planning ahead to set expectations with consumers such that they can meet or beat the implied contract present with them. If you don't set player expectations, they still have them, and often beyond the level of your ability to deliver."

” Gordon Walton

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, 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 :

• In Concept (Long Range) ” This web page is used to list additions or changes that are under consideration for implementation in the coming months, but have not yet been decided on. These are presented as concepts only for player comment, with links to a message board topic dedicated to the specific concepts or changes mentioned.

  There is no timetable given for possible implementation; these are simply discussion subjects. It should be made clear to the reader that any line item in this section that is subsequently cleared for development work is weeks or months out from implementation, and that some, none, or all of them might be cleared for development at some time.

  Any concept previously discussed but later junked by the live team should also be noted in this section.

• In Development (Long Range) ” After the live team has made a decision to begin work on a concept, change, or feature addition, it is noted here, along with some minimal explanation of how it is expected to function in the game and what the overall effects of the change will be.

  Again, no timetables for release are given.

• In Testing (Short to Mid-Range) ” Listed on this page are line items from the "In Development" section that have been added to the internal and/or public test server and are now being run through the QA testing process. Each line item should have a detailed explanation of the functionality and use of the change, feature, or addition.

• In the Next Patch (Short Range) ” Here you'll find line items from the "In Testing" section that have cleared the QA process and will be installed in the next scheduled patch, with a date and time given for that patch. The text describing the functionality and use of each line item should be reproduced here, along with any changes made to the line item during the test process.

  There are several variations on this process that can be used; for example, the "Update Center" web page from UO is shown in Figure 11.2. ^[2]

  ^[2] This is a good example of a player notification system. Note the four-step process at the top of the page, along with a fifth link for "General" testing issues as they occur. Note also that the UO live team expands on the concept by posting regular update letters from various internal departments.

  Figure 11.2. UO 's "Update Center" web page.

  

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 play 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:

• Always be 100% honest in all communications you choose to make with your players. Don't "hide" nerfs or anything that will be seen by the players as taking away capabilities or features from them. The players will discover them and feel betrayed. Discuss any takeaway, or any change that could be perceived as a takeaway, openly and at length before it is actually installed in the game.

• Never promise a feature or create an action item you can't deliver or which hasn't been 100% cleared for addition to the game by the live team.

• Never promise or even speculate about game mechanics, features, or anything without discussing it with your own people first.

• Enforce a policy of an integrated, "single official voice," so that only designated community relations individuals may post freely on the web or in a chat and others may post only with prior approval or by following the rules and guidelines that community relations sets down and under their supervision.

• Ensure that the live team producer and head of community relations review all official postings and communications before they are made available to the public.

• Keep the player base continually informed of what the live development team is currently working on by means of the web and message boards .

• Never promise a "due date" for a fix, feature, or other content until it has been thoroughly tested and is scheduled for a specific patch.

• Insulate your developers from nonofficial communications with the players. Knowing when to come down on development team members for breaking the "single voice" rule is a key ”and they will break it; you can bank on that. Developers love to communicate with players because the players make a point of conferring the status of gods on them. It is an almost irresistible temptation for them to get out there and bask in the glow. What they don't realize is that the players are playing them, in hopes of gaining favors down the road. This is one of the toughest problems the community relations team will face in the live phase of the game because developers love to gab with the players.

• Know when to sit on the marketing/public relations folks and keep them from getting too far out in front of development's actual feature additions and other content enhancement efforts.

• Remember: You can't win an argument with a paying customer. Even when you win on points, you lose in the court of public opinion. The lesson to be learned is not to argue. When you have something to say, say it and don't get drawn into a long argument about the supposed merits.

Figures 11.3 ^[3] and 11.4 ^[4] demonstrate how community relations managers (CRMs) can create an " in-depth defense" that insulates the developers from direct contact with the players on a daily basis, yet allows for the free flow of information between the two groups when needed or desired. Following these rules will allow you to avoid most of the heartache your colleagues have already experienced .

^[3] To insulate the developers from nonofficial "chats" with the players, the information and communication flow must work from the development team in the center out toward the players. The direct link between the players and the organization is community relations, which passes information back inside the target to customer support and the development team.

^[4] All information flows into and through the overall head of the live team. The three departments of the live team also communicate with each other, while keeping the head of the live team fully informed.

Figure 11.3. Post-launch communication loops .

Figure 11.4. The live team's communications flow.