Development Issues

Beyond the unique design considerations that are raised by multi-player games, there are also a number of development issues that teams need to be aware of. First and foremost, development teams need to decide what type of game they are making: multi-player or single-player. With an online-only game such as a massively multi-player RPG, the answer to this question is obvious. But for an action game that includes a single-player level-progression based game, adding a multi-player component can be approached in several ways. Many games have suffered when they opted to add multi-player support midway through development. This is a decision that may seem like it is not that big a deal, but in the end it may necessitate rewriting large chunks of the code or reworking the game mechanics themselves to be more appropriate for multi-player games . If the single-player game is significantly under way when this change happens, this may result in redoing a lot of work that was perfectly fine when the game was single-player only. On Centipede 3D , we were encouraged to add multi-player fairly late in development, but beyond the programming required to get it working, we did not have the art or design resources to make it fun. Since it was not a major priority for us, we ended up adding a cooperative mode and doing nothing to tweak or balance it. We specifically decided not to compromise the single-player experience, either through changing the mechanics or taking our time away from working on that primary part of the game. Interestingly, the multi-player in Centipede 3D did actually function and was not a complete failure froma creative standpoint; it worked as an amusing diversion for a short period of time. But it was not a great enhancement to the title since the game had never been planned for it and we lacked the design time it would have required to make it a truly worthwhile experience.

Some games that have added multi-player midway through development have ended up with mechanics that are significantly different in the multi-player and single-player games. This is unfortunate, since the idea of having a game with both modes is that players who are fans of the single-player experience can easily switch over to the multi-player game to continue playing the game they already enjoy. If the game is extremely different they may become frustrated and give up. Of course, some differences are certainly fine, such as slight variations in how the inventory functions or how long a given power-up lasts. But players should feel like they are playing largely the same game.

When developing Halo , Bungie concentrated on developing the multiplayer game first, before moving on to the singleplayer levels.

Thankfully, tacking multi-player gaming onto an existing single-player game is no longer acceptable to critics or gamers. In Chapter 15, Getting the Gameplay Working, I encourage designers to keep the game development process as organic as possible for as long as they can. But for the above reasons, it is very important to decide from the very start if your game will include multi-player. This is important not just so your code can be architected correctly and your game mechanics can be designed to work for both types of games, but also because you can use the multi-player game to actually greatly aid you in development. Assuming your networking code is working early enough, you can actually get your development team playing the multi-player game and start iterating on your game mechanics early to get them as tight and fun as possible. Assuming you keep making progress and the multi-player game is fun, this can be great for team morale and help people see how the game they are working on is coming together. And once your mechanics are a known quantity, building a fun single-player experience will be much simpler. Also, personally I feel that developing a fun multi-player game is a much bigger challenge than building a single-player game, since you as a designer have so much less control over the experience. Thereby, developing a fun multi-player experience fundamentally takes longer than an equally fun single-player experience. In some ways, designing a good multi-player game is all about realizing what players will attempt to do after playing your game for a while and how you can better support that with deep game mechanics. The longer you have players playing your game, the more you can balance the play experience. Thus, focusing on your multi-player experience early on will give you a better fighting chance of developing a solid game at the end of the day. Both Ensemble with the Age of the Empires series and Bungie with Halo are known to have deliberately focused on getting their multi-player experience right from the start, before working on the single-player experience. Thereby, they have both managed to deliver titles that have very well-balanced multi-player experiences while also including peerless single-player games.

Playtesting and User Feedback

As you develop your multi-player game and observe people playing it, you will quickly find that you never can anticipate what players will attempt to do. Anticipating what players in a solo play game will do is hard enough; doing the same thing for a multi-player game is all but impossible . For example, in Centipede 3D we saw the multi-player experience as strictly collaborative, where players would be able to play through the various levels together. Thus the two players the game allowed were immune to each other s weapons fire. But as soon as we got the multi-player code working and started playing the game, the first thing players tried to do was shove each other into the water, since the water is deadly to the players shooter ships. Due to the game s light but robust physics, pushing the other player around was an enjoyable experience made even more amusing when it led to the other player s death. I had certainly never imagined this outcome, but it is hardly surprising given players tendencies to take a cooperative experience and make it adversarial as quickly as they can. Another interesting emergent behavior that players quickly discovered was the ability for one player to jump on top of the other and ride him around, rotating whichever direction he wanted and acting as a turret . As I mentioned, on Centipede 3D there was literally no time dedicated to designing the multi-player gaming experience so there was nothing we could do to fix, adjust, or even encourage these interesting behaviors since we only discovered them a week before we were scheduled to ship.

Even more so than in single-player games, playtesting your multi-player game for as long as possible before it is released to the general public is essential. However, that testing can only tell you so much. For this reason nearly every massively multi-player game has included an open beta as part of its development. During this period, the developers take a large though still limited number of the general public and let them play the not-quite-finished game for free. The number of people attracted during such a test is much greater than the number of players that can possibly play as part of an in-house testing effort, and thereby provides a much closer simulation of what the game will be like when it is finally released to the world. The players who sign up for such open betas are typically particularly dedicated and mischievous gamers, and as a result will push your game s systems to the limit. Obviously, this is a good thing.

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 having, 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), players 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 mechanics 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 ofMMPs to ship feature thin and then add features to the game that players have shown interest in or even demanded.

Adjusting the game in any significant way after it has shipped can be a delicate process. 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 players 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 features 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 game FireTeam , 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 younger gamers with massive amounts of time on their hands. Developers, who have actual work to do, do not have time to deal with all of their suggestions or demands, and if they devote too much time to placating everyone they are liable to lose track of their own design vision. For this reason, many online games hire community managers whose sole job is to listen to and communicate with the players and synthesize their feedback into useful information that the development team can then use to refine the game.

After The Sims Online had launched, the team at Maxis used player metrics to uncover player exploits.

The fact remains that, though invaluable, the feedback offered by players, whether in a beta test or after the game has launched, is problematic at best. A more reliable technique is to look at player metrics, though this data can be quite challenging to understand. Sometimes referred to as data mining, analyzing player metrics is the process of tracking what players are actually doing in the game and using that data to adjust the play experience. So if you find that 90 percent of your players are using one particular type of object, it might suggest you should make more objects of that type. Similarly, if players are never using a certain feature you put in, it might be worth your time to try to determine why players are never using it and then address their issues. If it turns out the feature simply is something they do not need, it may be wise to cut that feature instead of maintaining it. Furthermore, you can learn from this mistake by avoiding similar unwanted features in the future. The value of player metrics is that the data cannot lie or exaggerate and it is a fair representation of what all of the players are doing, not just the ones who take the time to talk to the developers. Just as surveys in general can be colored by people s desire to make themselves look good in various ways, so too can feedback from players about their game experience. On The Sims Online , the developers used player metrics to uncover player exploits, since shortly after one player found an exploit, soon the whole world would know and everyone would be using a particular object for their own benefit. Analyzing player metrics is essential to assessing the true state of the world before making any changes and adjustments to your game.