Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Managing An Online Game Post-Launch
View All     RSS
April 4, 2020
arrowPress Releases
April 4, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Managing An Online Game Post-Launch

May 21, 2003 Article Start Previous Page 2 of 3 Next
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, 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:

  • 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 1. This is a good example of a player notification system.

Figure 1. 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 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:

  • 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.

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:

  • This isn't just a product; it is also a service. Just as much work goes into the game after the launch as before the launch.
  • The game itself is a vehicle that allows existing communities to congregate and socialize. Therefore, both acquisition and retention features have to be built into it, just like any other service.

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.

Article Start Previous Page 2 of 3 Next

Related Jobs

Visual Concepts
Visual Concepts — Agoura Hills, California, United States

Animation Engineer
Visual Concepts
Visual Concepts — Novato, California, United States

Senior Server Engineer
Visual Concepts
Visual Concepts — Novato, California, United States

Gameplay Software Engineer
Visual Concepts
Visual Concepts — Foothill Ranch, California, United States

Graphics Engineer

Loading Comments

loader image