Managing An Online Game Post-Launch

An often-missed element of persistent-world online games is the necessity to understand and communicate effectively with players during the lead-up to the game launch. This article explains how to acquiring and retain subscribers, manage player expectations, and build a thriving online community that supports the game. Excerpted from the book Developing Online Games: An Insider's Guide.

Now the real work begins.

Okay, you've launched; now what? It may surprise you to learn that, if you're to be a success, 90% of the work to be done on this game is still ahead of you. Anyone can build a persistent world (PW); maintaining technical stability and managing it effectively are the hard tasks. Just ask any developer who has launched a game since 1996 which was harder - development or post-launch management.

If you ask most developers with experience on an online game about launch and game management scenarios, you're likely to hear about a scenario similar to the following:

  • Millions of dollars of development money have been flowing out of the company coffers for two, three, or four years.
  • The announced launch date has come and gone between one and three times meaning the game is already six months to a year overdue.
  • The people who write the checks and would like to see a return on their money are putting pressure on the development team to get the damn thing out the door already.
  • The developers decide to cut a bunch of features that have been promised to the players, including features already listed on the back or inside cover of the retail box.
  • Even by cutting a bunch of features, there are hundreds of bugs still to be fixed, but the money guys order the box shipped and the game launched.
  • The game is hugely unstable, the servers and client crash constantly, features are missing or don't work as promised, and the team is working 20-hour days to try to catch up.
  • The players are up in arms and ready to hand the developers in effigy.
  • Bad word of mouth circulates about the game, killing subscriptions and sales.
  • The development team members start printing resumes on the company printers and faxing them to the competition on the company fax machines.

Once the launch period has come and gone, it is time to settle in for the long haul of managing the game. That starts with understanding the players.

Barbarians, Tribesmen, and Citizens

One of the biggest issues you'll have to contend with is the players or, rather your relationship with them. This issue is unavoidable. You must manage player expectations, have respect for your players, and listen to them as well. You can and should care deeply about them, too. After all, these are your customers. Every time they log into your game, they make a decision. With a few clicks of the mouse, they choose to continue supporting you.

The player issue will cause an unsuspecting developer more grief than anything else he or she can imagine. This is definitely not for the faint of heart. You may pay for, design, and create a world, but at the end of the day, if you want people to pay you their dollars, yen, and francs to play in it, sear this fact into your brain:

It isn't your game; it's the player's game.

Developers spend years focused on making a game. If they're not careful, this will breed certain assumptions, such as the world they created will remain their world and the players will play the game the way the creators want it played.

That will not happen. Players have their own motivations and objectives. We're talking about hundreds of thousands of people with different personalities-yet there are only 30 or so people who make a game. When a game goes live, the developers have to view it as a new game and a partnership with the players to make that world thrive. To do this, the developers need to understand who the players are, why they show up, and what makes them stay.

Who Am I?

The psychological makeup of hundreds of thousands of players could be broken down into any number of groupings and categories to help explain behavior and objectives.
For the purposes of this book, we'll simplify and break it into three broad categories.

Players who don't fall into one of these three areas are usually considered "general" players. General players are fairly neutral. They obey the rules, play the game, and might help out when they see someone who needs help. They aren't nasty and they aren't pillars of your community. They're regular "Joes." It's important to note that there is gray area between these types. The categories that follow are generalizations. Please don't expect all your players to neatly line up into the areas we've listed. It won't happen that neatly, we promise.


The barbarians are the "problem children" of online gaming. Their objectives vary, but one thing is consistent: They don't care what you or anyone else thinks.

Barbarians don't care about your intricately conceived game mechanics or your well thought-out player justice and accountability systems, or whether or not exploiting a bug is cheating. These are the "griefers," players who love the anonymity of the Internet and whose main enjoyment comes from ruining other players' experiences.

They are the bug exploiters who don't care if duplicating gold, weapons, armor, or whatever requires them to flood attack your routers and crash a server. It doesn't bother them that thousands of others have their game interrupted.

Barbarians are the cheaters, script kiddies, account hackers, client hackers, and "k&wl d00ds," whose objectives are not socialization with friends in a game, but making sure they and their small group of other social misfits can giggle behind their hands as they stare at the monitor, happy to have caused heartache and pain to someone else.

Identifying barbarians is a critical task, one easier said than done. PWs, or those with servers under company control, have the advantage of logging activity. Problems can be verified and dealt with at a later time. In free-play peer-to-peer games, such as Diablo II or Age of Empires, it is almost impossible. The collective intelligence of client hackers and the anonymity of the Internet make it difficult for a developer to take action. This is why peer-to-peer games have such poor attendance online compared to sales; when the client hacks show up, the honest players give up in disgust. The same is true for PWs when bad behavior goes unchecked.

For some, the raw intensity of the "virtual psychopath" that many barbarians represent can be refreshing in its novelty. At first, some who encounter them react as though they are cute online versions of Hannibal Lecter. Soon after meeting barbarians, they notice what is missing from the comparison: education, erudition, and the ability to function in society. In fiction, Dr. Lecter's victims had some reason for becoming his entrees. Barbarians will eat your customers without any provocation or remorse. They are more akin to the mass murderer in the Richard Pryor movie who, when asked why he murdered all those people, replied, "They was home." Barbarians are a statistically small group. However, they do a lot of damage to games.

Reroute them or get them out of the game. It's that simple. The only players who will shed a tear at the banishment of griefers are other griefers.

The bottom line: Barbarians will drive customers away faster than Attila could jump on his horse.


The objective of the tribesmen is to ensure that they and their personal micro-community (guild, team, squadron, clan, or Saturday morning coffee and killing club) have a great time. They are very team-oriented; it is not unusual for them to call each other in the early morning hours to get the tribe online for some objective. They help each other out, and at times, are pillars of the community, helping new players and generally trying to be a resource.

They can still cause problems in-game. For example, tribesmen have no trouble organizing "camping" parties. This is much like the big kids staking out the basketball court and not letting anyone else play. They put groups of players in an area and prevent others from utilizing it. This way, only the tribe reaps the benefits.

If another tribe or player annoys them, they can organize quickly and for long periods to attempt to drive that tribe or player out of the game. The tribe may use a variety of intimidation tactics. The goal: Make the game unplayable for the group or person they are angry with; in other words, drive them out.

Group dynamics can cause people to view rules differently. What players might not think is acceptable as individuals can change when it's for the good of the tribe. There can be a bit of mob mentality. If something is seen as an affront to the tribe, you could wind up with an entire group retaliating against the game, breaking rules as a way of fighting back, or the whole group may decide to pack up and move to another game.

There is beneficial power to the tribe as well. When happy, the entire tribe stays where it is. Listen to your tribes. Give them tools to facilitate group management and communication.

Keep in mind that your tribe leaders are your political lifeblood in the game. They influence large groups. If you disrespect them, you can turn entire tribes into barbarians.


The citizen is the crown jewel of any online game. Think of these players as the good people you know in the real world. In a game setting, these are the people most likely to take new players under their wing, take part in role-playing events, lend their in-game cash and resources to a greater cause, and always have a civil word for passersby.

Moreover, they are willing to obey the rules and play the game "realistically" (according to your vision) and in-character and encourage others to do so as well. Their objectives are to create a legend for themselves, but not at the expense of the game or other players. They want the whole game and all the players to survive and thrive within the world you've created.

The citizen usually strives to become a community leader. If there is no political or diplomatic portion to the game, they'll create one from whole cloth and convince others to participate. They become player advocates, game advocates, and at times, can create around themselves a cult of personality that becomes more vibrant and important than the game itself.

Citizens are pure gold. They keep others in the game. Please remember that the citizens deserve your attention. They aren't your squeaky wheels (like your problem children), and it's easy to overlook them. Attention given to the citizens has a huge impact on the world. It benefits the entire community. Do not fall into the trap we've faced before where you spend so much time responding to the fires caused by your problem players that your good players feel neglected. Over time, the neglected good players become barbarians themselves.

We've been there and we've done it. It hurts the game. Learn from our mistakes.

Now What?

Now that you know the three broad categories, what do you do about them? When it comes to barbarians and upstart tribes, two words are key: logs and reports.

Create logs for everything you can. Log player transactions and transfers above a certain size, character traveling speeds, player inventories, you name it. This is the best method you have for catching cheaters, dupers, speed hackers, and other exploiters.

As an illustration of how this can save you plenty of time and heartache, Damion Schubert, former lead designer for the groundbreaking M59, tells this story from his 1996 experiences:

"I had coded guilds into M59 over the weekend, shortly before we were supposed to go gold. It was a rush job, but I took uncommon care and felt pretty confident that I had implemented something that was fairly bug-free. So imagine my consternation when a group of players told me something was totally broken."

"One aspect of guilds was the guild halls. Players could conquer another player's guild hall by sneaking into the guild hall and flipping a switch. If it wasn't unflipped inside of 10 minutes, that guild hall was considered conquered. The key - the only way to sneak in was if you snuck in the front door behind a player who belonged to the guild. Once inside, it was trivial to open the door, allowing the rest of your guild in. This simple design was such to ensure that players could only conquer guild halls while the defenders were actually online."

"Except that the guild members yelling at me were swearing up and down that no one was online when their hall was taken over."

"The way they figured it, the math was simple. They had 10 members; all 10 of them swore up and down that they hadn't entered the hall in the last day, nor had they gotten the ominous "Your guild hall is being raided!" message. I began to crack open code, pore over logs, and try to calm them down. Unfortunately, none of them showed me anything wrong."

"Until one of the guild members, one who had been quiet up until this point, took pity on me. She sent me a private message saying, "It's not broken." She went on to explain that she had waited until the rest of the guild was offline, then she opened the door for another guild. I understand she got 30 pieces of silver for her trouble."

"With that news, I coughed and told the assembled angry mob that I had explored all available information and discerned that the takeover was in fact legal and that there was no bug. I refused to give more information than that. I never found out if they discovered the Judas in their ranks."

"As for me, I learned my lesson: LOG EVERYTHING, and offer a robust system for reviewing the logs. When hunting down bugs and/or reviewing player cries of foul, nothing makes the job of the GM easier than knowing that he/she has perfect information and can state with 100% accuracy when a player isn't telling the whole truth."

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.

The Five Elements Necessary for Success

The five elements are talk soup, band of brothers, the living organism, welcome wagon, and help me!

Talk Soup

Your PW needs many methods for players to communicate, individually and in groups, and both in and out of the character

Latest Jobs

Sucker Punch Productions

Bellevue, Washington
Combat Designer

Xbox Graphics

Redmond, Washington
Senior Software Engineer: GPU Compilers

Insomniac Games

Burbank, California
Systems Designer

Deep Silver Volition

Champaign, Illinois
Senior Environment Artist
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more