One Problem: The Designers

"You need a visionary who can dream up fantastic gameplay. A visionary who can write and talk like few. A person who is charming, committed, and efficient. A visionary who understands enough technology to include this aspect when he or she creates designs of fantastic worlds and gameplay functionalities. And very important: This person's greatest talent should be the ability to listen. To the development team, to marketing, management, and most important, to the players."

” Thomas Howalt , Funcom AS Oslo

Yes, it sounds strange . These guys ”and they are overwhelmingly guys; very few women actually get to be one of the "Chosen" ”are your bread and butter, the people who decide the background story, how the game mechanics will work, what features will be in the game, even how your client interface will look and work. You'll have anywhere from two to six on your development team, and their productivity is the first link in the chain that determines whether or not you'll actually hit your milestone dates.

If you have an experienced lead designer ( experienced in the commercial, for-pay side of the industry), one with a level head who understands that paying customers have much different expectations and needs from free-play MUD habitu s, that person is worth his/her weight in platinum . He/she will be your best friend because he/she won't waste a lot of time trying to throw every imaginable feature into the design, spend months designing intricate and ultimately doomed player-administered justice systems, or argue the virtues of consenting versus non-consenting PvP combat with other hard- core players who happen to be on the design team. He/she will get to the point, design an overall environment that contains the features most loved by the greatest number of players, and go on from there with innovation.

Unfortunately for you, there aren't that many experienced for-pay online game designers around. In all likelihood , you'll start out with designers who got their experience as implementers (imps) on a MUD. If you are in development on a PW and this is the case for you, now is the time to get very scared.

Why? Simply because MUD imps, as they are called, no matter how clever they are with code or design, do not have experience with paying customers. Being a MUD imp does not give you any clues about what paying customers want or about what works/ does not work in a for-pay online game. MUD imps have never had to concern themselves with these issues, and most of them don't care to do so. Their whole experience and training with online design has been with experimentation and playing around. So what if the MUDders howl and scream if a new game mechanism installed with no notice goes horribly wrong? The whole purpose of a MUD is, really, to experiment and learn. If a player doesn't like it, well, the price is free; let him/her go somewhere else and moan.

That works fine in a university atmosphere, where many MUD imps get their first taste of being game gods. There is absolutely nothing wrong with this attitude in a non-pay situation. It is a problem, however, at the for-pay level, and for obvious reasons.

If you're ramrodding an online game, then you need to be aware of some of the hidden dangers designers bring to the table and what you can do to ameliorate them.

"The Vision Thing"

A tall hurdle you'll have to leap with your designers, and the development team in general, is "The Vision Thing," as in, "Hey, this is The Vision and we will stick to it, dammit!" Designers normally have a tremendous amount of pride of ownership in what they are doing. Many of them consider themselves on a par with movie directors and novel writers, delivering a story to an audience and expecting everyone in the audience to get the same thing out of the experience.

Unfortunately, that does not take into account the dynamic and ever-changing nature of play in a PW. The overriding problem with The Vision Thing is this: It does not normally allow for flexibility or change based on the actual play styles of for-pay gamers. No de signer or team of designers could possibly hope to close all the holes or find and fix all the flaws in a PW design; the collective intelligence of a player base in the thousands or tens of thousands dictates that any design hole or flaw will be found and exploited. On top of that, the collective intelligence of the players also dictates that they will find ways to play your design within the rules you have set and coded, but in ways you never expected.

The Vision Thing has caused more problems for existing online games than just about any other issue. Overadherence to The Vision can allow concepts that are not appropriate for online games to be inflexibly locked in during the early design stage, and it can also breed inflexibility in the post-launch stage. While a moderate sense of inflexibility toward basic concepts can be a good thing ”what designer would be worth having if he/she weren't passionate about the work? ”complete inflexibility of view is rarely a good thing: In a PW, it can be disastrous.

You rarely see this problem in designers who have at least one commercial MMOG under their belts; once you've experienced the problems The Vision Thing creates, you tend to accept the lessons and learn from your mistakes. For example, note the recent improvement in flexibility on Verant's EQ live team, now that some highly experienced online game veterans such as Scott Hartsman, Rod Humble, Robert Pfister, and Rich Waters are part of the process. This is just one more example of how critical experienced MMOG people are to a successful and smoothly running post-post-launch stage.

If your team is lacking in this experience, the time to nip this in the bud is during the initial game design document process, when you can exercise more control over the process and before anything is set in stone. If something seems suspicious or just not appropriate to an MMOG, we've found it a helpful exercise to require the designers to write an analysis and justification for the suspicious design feature or concept, explaining why it would be good for the game and players. This tends to focus a designer on the immediate issue: Will this have a reasonable chance of being fun, interesting, or entertaining, or is this just a cool-sounding idea that would be fun to work on?

After launch, strict adherence to The Vision Thing has the tendency to cause ossification, especially if the live team doesn't take ownership of the decision-making process right away. There is no doubt you'll have to make some changes to the gameplay over time; getting past the legacy of the development can be a block, especially if the developers are still around and working on the next game. Developers tend to become emotionally attached to the game during the development process; proposing to make changes to their "baby" can cause howls and anguish.

The MUD Imp Syndrome, Also Known as Cowboy Programming

The MUD imp syndrome, or cowboy programming, is a serious problem. Paying customers expect a certain amount of consideration and consistency; that's hard to achieve if the designers are experimenting with the design after launch. The development or live team member can call it "innovation," "refreshing the game," or anything else they like; if it isn't in the design document and it hasn't been vetted by the change control process (CCP), it is experimentation and who knows what it can screw up?

Cowboy programming usually takes the form of one developer coming up with an idea for a new feature or a fix for a problem and implementing it on-the-fly with no documentation or notification to the team. This also means little or no testing, and changing any moving part in one of these products requires complete testing to ensure you haven't thrown a monkey wrench into the gears of some other mechanism. No matter how easy or uncomplicated a change may seem, something as simple as changing a weapon from a +4 modifier to a +5 can completely upset the balance between classes of players, creating an uber-class when the weapon is wielded. Doing the reverse ”taking away a capability ”is seen as wasting hundreds of player hours; it tends to tick off the player base.

This is bad enough during development and testing, but cowboy programming on a live product can ruin your reputation because it almost always causes problems. Even if a change doesn't unbalance the game, the players will find out about it (you wouldn't believe how many players test everything after a patch), and your community relations staff will be immediately beset with charges of nerfing ("nerf" is a generic term used by the community to describe the act of changing an ability or feature in such a manner that it takes away power from players) and arbitrarily penalizing players. Nothing irritates the players more than having their time wasted , and cowboy programming usually results in that happening to a significant portion of the player base. This causes huge problems for customer relations; even one undocumented change can result in dozens of hours used by the customer relations team to try to control and manage the situation.

Even if you have a four-step program in place during the live phase to notify players of upcoming changes, as discussed in Chapter 12, "The Live Development Team," it has been our experience that every team has a cowboy who believes it is his/her right to bypass the CCP as a time- waster or not regard it as necessary for "small" changes. You'd be amazed at how many of these "small" changes are coded right into the live production servers, bypassing the test server altogether. You'd also be amazed at how many cowboys continue to make the same mistake over and over again, regardless of the cost in pain and frustration to other members of the team.

The best place to curb cowboy programming is during development and initial Alpha testing by rigidly enforcing version control and the CCP. The development team leader has to make a point of it, consistently and constantly, emphasizing how being a cowboy affects the other members of the team. It might be necessary to rein in a developer who consistently goes rogue by having his/her version patch addition privileges revoked , making him/her go through a supervisor to document and demonstrate changes before they are placed on the test server. At some point, it may even be necessary to remove a repeat offender from the team, just to drive the point home.

The important thing to note is that cowboy programmers are rarely malicious just enthusiastic and very goal-driven to fix or add as many things as possible. You just can't ignore the fact that maverick coders will cause you unending grief if allowed to exist on the team.

The Player Must Die!

For some reason, designers as a class love to punish the players. They spend inordinate amounts of time devising clever and fiendish methods of penalizing players for straying outside the boundaries of The Vision. This is not necessarily a bad thing, as long as there is a concomitant system of rewards. Unfortunately, for too many designers, a good reward for the player means not inflicting punishment , so a vicious cycle develops in which the design continually punishes players for straying outside The Vision and the main rewards are for playing exactly as the designer wants you to play and no more. This tremendously limits flexibility and freedom in a medium that professes to emphasize these attributes.

An example of this attitude is the whole consenting versus non-consenting PvP controversy that is currently raging within the community. Non-consenting PvP basically means that anytime you are playing, you're subject to being attacked and killed by other human players. There are three main sides to the controversy:

• There are the adherents of non-consenting PvP, who believe that being open to attack without warning by other players creates the drama of conflict and brings communities of like-minded players together to battle the fiends. They believe the only reason non-consenting PvP hasn't worked in 30 years is that no one has done it "right" yet. This is the "non-consenting PvP is good" approach.

• There are those who oppose non-consenting PvP on the grounds that, historically, it has never worked and tends to drive a large number of players away from the game, as in UO 's early days. This is the "non-consenting PvP is bad" approach.

• There are those who think non-consenting PvP can work, as long as there are plenty of ways for players to advance without placing their characters in danger and as long as PvP regions of the game are clearly marked . This is the "opt-in" approach to non-consenting PvP; you opt into it by crossing some boundary or voluntarily tripping a flag; thereafter, you're fair game. In a sense, it is both consenting and non-consenting.

Currently, there are several major games due out in 2002 and 2003 that feature PvP as a major component of the game, including Wolfpack's Shadowbane , Verant's Star Wars Galaxies , and EA/Maxis The Sims Online . The Sims Online is slated to be a more mass-market online game, so the opportunities for PvP will be extremely limited. Star Wars Galaxies ' creative director, Ralph Koster, was also the lead designer of UO and learned many lessons with that game, so Star Wars Galaxies will be using the opt-in approach.

Shadowbane , on the other hand, seems to be leaning toward the "non-consenting PvP is good" approach, at least at the time of this writing in late 2002. This should not surprise anyone , considering that their motto since 1999 has been: "I don't play to bake bread, I play to crush!" They have since claimed that the motto was only a joke and public relations stunt , but online chats with development personnel over the past few months seem to indicate that the non-consenting PvP mentality is alive and well at Wolfpack.

Note also that of the three projects listed, Shadowbane is the one team with no real-world experience in designing and developing PWs. What the team sees is its own vision, not the vision of the bulk of the players. Thus, players who don't want non-consenting PvP are presented with a hard choice: Live with it or leave. It seems likely that the inexperience of the Shadowbane team, combined with their own bias toward non-consenting PvP, is about to teach them a hard lesson about the number of players willing to indulge them. As it states in their frequently asked questions (FAQ), "On the other hand, we expect large areas of the world map to basically become a 'No Man's Land.' If you decide to travel in the Badlands, do so at your own risk." ^[2]

^[2] See http://Shadowbane.ubisoft.com/gameinfo/strategyfaq.shtml for more information.

This is exactly what happened to UO in 1997, and there is no reason to assume that the result will be different in Shadowbane . It is also an example of punishing players who don't conform to the developers' bias of how the game should be played . The result for Shadowbane is likely to be the same as it was for UO : a mass exodus of the estimated 80% of the player base that doesn't like or want non-consenting PvP.

Other general examples of "The Player Must Die!" include loading a world with large monster spawns to make the world "exciting" for the player (read: dangerous) and consistent nerfing to take away power and capabilities from specific player classes.

The best way to handle this problem is to ensure that team leaders act as a brake on the designers and ensure that there is something to do in the game besides fight and die. This problem usually starts with an incomplete design, or one not completely thought out or considered . After all, these games are supposed to be PWs, and that means more than persistent death.

The Neat Stuff Syndrome

The neat stuff syndrome (NSS for short, and also known by a more scatological term than "stuff" inside the industry) occurs most often after the game design documents are completed and development has begun. It starts when someone on the team says, "Hey, wouldn't it be neat if " and goes on to expound on some feature or mechanic the team didn't think of during design meetings. More often than not, there follows a half- hour of, "Oh, yeah, that would be so cool!" followed by a designer making a notation to add it to the design as soon as possible.

If this happened only every once in a while, it wouldn't be an overwhelming problem; however, with developers being creative types, it happens a lot . You can hardly go to lunch with the team without hearing some variation on the theme. Even worse , there are some leaders and senior management folks who just love to pop their heads into a lead designer's or producer's office and say, "You know, I was thinking about your project, and wouldn't it be neat if ." When senior execs start pulling this trick, their subordinates generally feel obliged to at least study the issue, and the deadly spiral begins.

This is a major contributor to "feature creep," the tendency of software designers to keep adding features under the rationalization that new features are needed or will enhance the finished design. The problem is that adding features adds moving parts to an already complex mechanism and usually occurs without full thought being given to the ramifications on the design, individual features, and game mechanics.

During the design stage, team leaders have to be sensitive to the NSS and remind the design team that a mistake everyone else has made has been to overreach in the design. As an interesting exercise, you can ask the team at various stages to pick 5 or 10 features to cut immediately, whether you actually intend to cut them or not. This will give you a good indication of how focused the team really is.

If you institute a CCP, controlling the NSS after the design process begins is easily accomplished by simply insisting that the CCP be used to request any change.

Okay, What Can You Do?

It isn't that hard to fix these things; all it takes is some research, logic, and analysis. The research comes from playing competing products as a paying customer and noting what does and does not work, reading as much literature and as many Internet postings from experienced designers, producers , and executives as possible, and making notes about what they say. The logic and analysis come in when you then review your own game's design based on your research and point out any discovered flaws to your team. Most designers and producers aren't stupid; if you point out a problem, they'll generally understand.

Consider this: If you laid out $5 million for a house, would you just turn the contractor loose and tell him/her to come see you when the house was done? Of course not ”you would check in periodically to see for yourself how construction was coming along. If you had any doubts at all about the progress or quality of the work, you'd hire a second contractor to come in and inspect the work. After all, if you're committing $5 million, what's another few thousand dollars to increase your comfort level?

Amazingly, in the past 15 years, I have yet to see this happen during the development of a large PW project ”and those projects now routinely cost more than our mythical $5 million house. Call it the "not invented here syndrome," or cheapness in the front office. The fact is, all that money is being spent without a second opinion from an uninvolved outsider. This is where most teams get into trouble, in not having an independent analysis done and depending on the designers to be perfect. This is a bit like letting the fox guard the hen house (or like letting the inmates run the asylum ). That kind of administrative approach doesn't work in many situations. The Founding Fathers worked checks and balances into the Constitution of the US, most newspapers have fact-checkers and editors to backstop writers, and doctors insist on second opinions for critical, life- threatening diagnoses.

The point is, your designers need "fact-checking" and an oversight committee, too. If no one on the team or in the company is qualified to do it, hire an independent designer to do it. In fact, you're probably better off hiring a designer on a short-term consulting basis to do this, if only to avoid political divisions within your own team and get an honest opinion from an uninvolved third party.