However, the flip side of this is that, since they are such hard-core gamers who are so
into gaming that they are willing to play a buggy and unfinished product, these testers
do not necessarily represent the views of more casual players. Therefore the feedback
you get from them will not necessarily match what you will see when the game finally
comes out. Furthermore, sometimes these testers may be tempted not to report all the
bugs they uncover if they are able to exploit them to their own benefit; they may hope
to continue to reap the rewards from these oversights in the final game. There is little
that can be done to remedy this, but it is important that designers recognize it and know
there is surely more balancing work to be done once the game goes live.
Even with an open beta, when your game is unleashed on the masses, issues will
come up that you failed to anticipate. This is true for smaller scale multi-player games
(such as death-match games) and these problems are often addressed in patches that
come out shortly after the game is released. Patches are so common that gamers have
come to expect them. If you do not actively try to track what problems people are hav-
ing, both with the networking code and with the play mechanics, and fail to tweak the
game to fix at least the most glaring problems (and there will be glaring problems), play-
ers will quickly abandon your game in favor of another game whose developers take
better care of their end users.
In the world of massively multi-player persistent games, the duty of maintaining
the game after it ships is even more important. With these games, players are typically
paying a monthly subscription fee and, in addition to adjustments to the player mechan-
ics and balancing, expect a steady stream of new content to keep them challenged and a
certain level of customer service to fix their problems. Indeed, most of the developers
of these games consider reaching launch as only about half of the work, with the game
needing constant care and tweaking on a day-to-day basis, much as a theater troupe that
just launched a new play will refine and rewrite it based on how it goes over with each
night’s audience. Richard Garriott has gone so far as to encourage developers of MMPs
to ship “feature thin” and then add features to the game that players have shown inter-
est in or even demanded.
Adjusting the game in any significant way after it has shipped can be a delicate pro-
cess. First and foremost, before starting to make any adjustments you need to do your
best to understand the current state of your game and what players are enjoying and
what they are not. It is easy to guess at what you should fix only to break a feature that
players love. One obvious way to track what players enjoy in your game is to listen to
their direct feedback, but this can be problematic for a few reasons. First of all, the play-
ers who do provide feedback may not be representative of the average person playing
your game, and may be part of an outspoken minority. One saying goes, “The happy
ones are playing the game, the unhappy ones are on the boards.” Also, players are not
game designers, and as such do not understand the ramifications of some of the fea-
tures they are demanding. Indeed, designers are often much better served by looking at
the root problem that is causing players to suggest a feature. In the end, the designer
may be better off coming up with his own solution to that problem. Art Min, project
leader on the online tactical strategy gameFireTeam, stated that the project became
derailed when they spent too much time listening to the participants of their open beta
test. Min pointed out that the members of an open beta test are most frequently youn-
ger gamers with massive amounts of time on their hands. Developers, who have actual
254 Chapter 13: Multi-Player