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 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."
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!
Your PW needs many methods for players to communicate, individually and in groups, and both in and out of the character of the game. Yes, this is a game that will allow tens of thousands to play simultaneously; players, however, will naturally segment themselves into smaller community groups (guilds, teams, towns, races) for their own ease and comfort.
If this communication is facilitated, the communities will be able to grow more easily and more quickly and the game will have a much greater chance of becoming the player's primary entertainment vehicle. This is done by ensuring that there are many easy and intuitive means for players to contact and communicate with each other, and making sure the community relations and player relations teams take advantage of those tools to communicate effectively with the players. This encompasses everything from instant messaging between individuals, to player-configurable in-game chat channels, to special message boards for guilds and teams, to in-game email between players and groups of players.
This sounds like a very common-sense element that every game should have. However, most online games have had only minimal communications tools at launch, and after a hue and cry from the players, were forced to build decent communication features into the games later.
Lack of these capabilities has also limited the ability of the live team to communicate effectively during their support missions for the players. The essence of supporting the player is being able to communicate effectively. Being limited to web posts or 80 characters of text at one time slows down support and makes it more difficult to communicate.
Band of Brothers
In the final analysis, players don't continue to play a game because it is cool; they continue to play because their buddies are there. Once they join some kind of guild or team organization, the emotional attachment to that group of friends, that band of brothers (to paraphrase Shakespeare and HBO), makes it very difficult for them to leave the game for a competing product.
To facilitate this, you'll need to build in full-featured "guild" functions, allowing players to set up, manage, and control the membership of teams. The team element is critical; it allows friends to congregate logically, easily, and within the context of the game.
They will do this whether you provide this service element or not; by providing it, however, you add to the acquisition and retention features of the game. Only UO and AC currently have easy and intuitive mechanisms for accomplishing this.
The community relations and player relations teams also need to understand how the "band of brothers" phenomenon can play into enhancing the retention of new subscribers by providing ready-made, player-run support mechanisms. Many guilds are willing to train new players and recruit them into the fold to increase their own size and power within the game. This is a powerful means of locking in loyalty.
However, many games pay no particular attention to the needs or desires of the teams within their product. Providing them with the tools to create their own content, such as team events, faction wars, or in-game parties and weddings, should be a top priority for the live team.
The Living Organism
A subscriber's play style will change over time. Some customers churn out and stop playing, others move in with new ideas about how the game should be played, and new content and features are added. The longer someone plays, the more likely it is that his/her goals within the game will change. Someone who started out as an explorer may transform into a socializer, or a socializer may transform into an achiever.
This type of change contributes to the dynamic nature of a PW, but it can also cause problems if the live team isn't changing pace and objectives along with the customers.
A responsive and flexible service philosophy takes into account the major playing styles and how they change over time, and then adds content and features that match.
Historically, the opposite has happened more often; live teams have watched how the players play and then made changes to try to force them back into a cloistered vision of how the game should be played. Considering that these are virtual worlds as much as anything else, this is like Ford telling Taurus owners the car was never built for Sunday afternoon drives in the country and the vehicles are not to be used that way.
Inflexibility such as this will tend to set a live team into conflict with the players, as designers try to shoehorn players into a particular style and players keep trying to break the chains and move on with their virtual lives. The service philosophy should take into account the changes that will happen and work with them, not against them.
Online games and other PW environments can initially be confusing for many users.
How many times have you entered a new online environment for the first time and wandered around aimlessly for hours, trying to figure out the simple basic mechanics of how to move, talk, and interact?
Our experience in online gaming over the past decade has shown that games that have a human greet the new player within a few minutes of logging in for the first time have an extraordinarily low churn rate (20% vs. 50% for the industry overall). In-game tutorials can take up some of this slack, but nothing beats having a human drop by and say, "Hi! Can I help you get started?"
To get the most bang for your buck, the game should have a staff of paid or volunteer helpers specifically to greet new players and help them get to know the world. With the proper backend tools to allow them to support the players and then ensure that new players have someone to talk to and help them get started, the churn rate will be lower than average. Supporting the GMs and new player greeters by giving them the proper administrative tools and some leeway and discretion to solve player problems on-the-fly will lower initial churn faster than almost any other feature.
For some strange reason, some developers and publishers who are banking their future on games accessible from the Internet and web are failing to use them fully for support. No game currently has dedicated chat and message assistance available on a 24/7 basis; at best, such assistance is available for a few hours each day.
This ignores the 24/7 nature of the web's subscribers, who exist in all time zones and geographic locations. The live team can solve this problem by implementing a root structure that includes the following elements:
- A dedicated message board for use by the game's subscribers. In-house and volunteer "sysops" to monitor the message board on a 24/7 basis and respond within two hours to all questions and inquiries
- A dedicated chat system capable of supporting a significant portion of the subscriber base
- In-house and volunteer chat hosts to facilitate the chat rooms and service the subscribers in them
- A complete and detailed knowledge base database dedicated to the game and available to both subscribers and volunteers on the web, and (perhaps) within the game as well
By implementing this structure, human beings will be available at all hours to assist your subscribers and direct them whenever possible and feasible to relevant portions of the web site and knowledge base.
Community Relations: Processes
"Less is more. What I mean by this is that communication with players should be clear, consistent, and focused. A larger quantity of unfocused communication is inferior to consistent delivery of focused messages. I'm a big believer in memorializing information in a single place that is easily accessible to the player base. Duplicated information is error-prone."
"Tell them less than you are initially inclined to, but never be dishonest. Treat them like adults. Reach out to people who will happily build community sites and be cheerleaders for you. Be sure you let them know when you change something due to their input. And, most of all, be sure that you never let them feel like your communication with them has grown stagnant."
Managing the expectations of players starts with and revolves around the community relations team. They have the primary responsibility to ensure that a consistent, focused, honest message is presented to the community, and that the concerns of the community are relayed back to the other members of the live team for comment and consideration.
However, they can't do that without the cooperation of the live development and player relations teams. In that sense, customer relations is a consensus-builder within the live team and between the live team and the player base. They drive the processes that keep information flowing.
The Three Principles
The processes of managing a game community start with the three principles discussed in the next three sections*.
Constantly Design for Growth and Change. If an online game is successful in building a subscriber base, participation in both the in-game and web communities will grow over time. Features and support not required at launch will be required months down the line. As much as possible, those features need to be planned at the outset to allow for a graceful, structured growth. It also means there have to be regular reviews of the community relations feature set and changes made to ensure that growth and change within the community are being met successfully.
This also means that there has to be open communication among the player relations team, community relations team, development team, and the publisher, so everyone knows about and buys into the plan developed to support the game over time.
Create and Maintain Feedback Loops. As discussed earlier, the communication among the players, community relations team, developers, and the publisher needs to be carefully managed to protect the reputation of the game and the company and to keep even small incidents or rumors from being blown out of proportion and creating a mess. At the same time, the players want unfettered access and input to the game developers.
Creating and effectively maintaining feedback loops between the players and community relations and between community relations and the developers and back again is vital to creating an atmosphere of contribution, while at the same time protecting the developers from having to answer every question or comment the players might make on message boards or in chat.
Empower the Players over Time. Players change their own roles over time. Some become leaders and need tools to help them lead their people; others become opinion-makers in the out-of-game community; while other players create roles they find interesting for themselves. Each requires different tools and capabilities; if they have them, they'll help you increase the size and role of your game community over time. It is necessary to ensure that this is tracked carefully and that players are empowered at the proper times.
*Excerpted from the Themis Group Online Services Overview, copyright 2001-2003 Themis Group, Inc., used with permission.
The Cult of Personality
The point person on these principles and processes is your community management, specifically the lead CRM.
If there is one thing players hate to see on message board postings, it is a communiqué from the developers or company signed "From the Live Team." Nothing is quite so impersonal or non-interactive as a faceless, human-less message. This whole industry is based on interactivity, with the game and between the people who play it, make it, and publish it. With the human touch so important a factor, why would anyone go out of his/her way to de-humanize the process?
Amazingly, that is exactly what many online game publishers and developers do, in spite of the abundance of publicly available evidence that it does not work and that the players dislike it. You need the human touch.
One effective way to keep the human touch is to set up one person as your contact point with the community and create a cult of personality around him/her. If you pick the right person as the lead, day-to-day CRM, this won't be a problem; it will happen naturally. For example, take Jonathan "Calandryl" Hanna. Jonathan began as a player of UO and, over time, became an influential opinion-maker in the forums. When Origin Systems began looking for someone to come in and take over community relations for their sloppy and disliked public face, he applied for and got the job.
Within weeks, he had the players eating out of his hand. Not only was he one of them, but he also made a concerted effort to take player questions, track down the answers, and post them. He also took the time to post chatty messages and dealt with the players with respect and humor.
This is the perfect type of community relations person - a gamer who knows the player base, likes them, and considers himself/herself their advocate to the live team, without losing sight of the fact that he/she still works for the company. This minor kind of cult of personality, when the right person experienced with the product is the center of the cult, serves a number of functions:
- It enhances player comfort and trust in the game and company. Having a real, live person interacting with the players, instead of a faceless corporation, creates the human connection that Internet game players live for.
- It makes insulating the rest of the live team from daily player pressure easier and more amenable to both sides. Developers worry about losing contact with the player community and understanding their issues, and players worry that they won't get the straight skinny from the developers. A trusted intermediary can negotiate these waters and satisfy both sides.
- It provides a control mechanism when problems develop. It is not unusual for the patching and publishing process to create temporary problems due to bugs or balancing issues. This also causes a temporary spike in complaints and a rising swell of player dissatisfaction, confusion, and anger. If not handled correctly and in a timely manner, this can quickly get out of hand. A trusted and effective CRM can ride the swell and control it, keeping the players appeased with a constant flow of information on the web, in message forums, and through "Letters from the Developers," and reining in the natural inclination of the developers to get out there and defend themselves (that is, argue with the players).
This takes a person of particular qualities. It isn't enough to just drag someone out of the community and throw them into place. All too often, the loudest supporter running a fan site is picked for this duty, in a modern-day demonstration of, "He who raises his hand first gets the job." While this is certain to get a loyal "wannabe" on the staff, one who will not often question the developers, it might or might not get you the person with the qualities you actually need.
The qualities you need include the following:
- A person who can see both sides of the issue and isn't afraid to challenge the developers-Live team developers tend to get too close to the game and forget that proposed changes won't just alter the game, but also affect the experience of the players. If the players are a vocal and not particularly complimentary lot, the developers may actually come to resent the players and unconsciously make changes designed to irritate them further.
- A good CRM knows the game inside and out and is willing to take a stand for or against changes that will affect gameplay, both publicly to the players and privately to the live team. This doesn't mean the CRM denigrates the live team to the players; it does mean the CRM is willing to be vocal privately about proposed changes and, if overruled, still "owns" the change publicly with the players.
- Someone who understands the unique sense of humor of online gamers-Players have a somewhat twisted and dark sense of humor, full of sarcasm and double innuendo. If your frontline CRM doesn't understand the humor, it will be impossible to make a connection with the players.
- Someone who understands the power of the word "us" - The players want to be involved in the game as members of the community, not just as anonymous players who send in $10 each month to get access. As such, they want inclusion, and responding to them with the word "we," meaning the live team, just draws a line in the sand that some of them are more than willing to cross. A CRM who can include the whole player base by making the whole into "us" already has half of the potential "bad actor" problems solved.
- A person who understands that you don't argue or get snappy with the players - Some players are barracks-house lawyers and will endlessly debate the fine points, if you let them. To them, this is just part of the game and part of the fun. Nothing pleases them more than trolling for a CRM on the message boards, getting the CRM to take the bait, and then making a fool out of him/her by frustrating him/her to the point where he/she snaps.
- The CRM should be a person who maintains an even keel, remains polite in the face of the most horrid or derogatory posts, and knows when and when not to continue a debate and how to close one off gracefully. This is someone who understands that expressing disappointment over a rude message and apologizing for not being able to satisfy the offender sends a far stronger message than lashing out and getting into a fight.
- Someone who understands the player bias on issues and can sort his/her player contacts accordingly-The vocal minority of any PW tends to come with built-in biases. Some are self-serving; everything they say or do will be focused on improving their personal role in the game. Others are subject matter experts; they know the subject (the game) in minute detail and will continually argue for more hard-core game mechanics and options at the expense of other players.
A CRM needs to be able to identify and track the bias in discussions and posts and weigh and respond to them accordingly.
Obviously, good CRMs don't fall off trees. Finding one and keeping him or her on your team is one of those vital necessities that developers often miss or ignore.
The daily activities of the community relations team will revolve around the message boards, email, and maintaining the community relations portion of the web site.
Message boards, often called forums, are a vital part of the community relations team's online presence. Much of the team's daily interaction with the players comes through this medium. There are pros and cons to offering open message boards to your subscriber base. On the pro side, having open forums gives the team access to a broad range of player opinions and affords them the opportunity to build compromises and consensus around sticky issues.
On the con side, fewer than 15% of a subscriber base ever posts on forums, and that <15% represents the vocal minority of the game. They have their own agenda and, by answering their concerns publicly, you tend to get more of the same, a sort of vicious positive feedback loop on the concerns of the biased few.
Even facing these potential pitfalls, if you don't have open forums, how can you expect to communicate effectively with the players or correctly manage their expectations? Even rude or uncomplimentary message posts can contain a grain of truth; it is important to acknowledge those and make certain they get into the right hands on the live team for consideration.
The community relations team's daily activity surrounding the message boards mainly consists of reading the new messages, responding to them, and collating and forwarding interesting or important threads to the various members of the team for answers to questions or clarifications.
At some point, the community relations team collates those answers from the live team and posts them in the proper message board threads. Unless you want the live development team spending a couple hours a day just responding to posts, you'll want to establish a regular routine of one or two days per week in which those answers to player inquiries are posted. If the response days are clearly noted, the players' expectations of answers will be managed to those days. It also makes sense to have a dedicated forum category or thread titled "Answers from the Team" or something similar, so players know where to go to get the responses.
The community relations team should not necessarily limit itself to just those message board activities. Players like to banter with team members and know that they are human and have senses of humor. Indulging in some of this goes a long way toward keeping the vocal minority under wraps.