Multiplayer Design Issues

by Gordon Walton

Paraphrasing an old retail adage, the most important element of multi-player game design is community, community, community. It's a different medium altogether. Never add a multi-player capability without facilitating inter-player communication, and remember to keep it easy, integral, natural, and ideally invisible. While community is not a big part of computer entertainment in the standalone game world, it is everything in the multiplayer realm. Players want human interaction. It's more convenient to play solitaire than get a group together for poker, so don't just use humans substitutes for artificial intelligence.

Think about how players can communicate and thereby form teams and community. In a military game: Make a hierarchical structure, cool-named units, incentives for experienced players to recruit and train newbies. For more free form milieus: Insert areas to attract people with like interests; the corner pub, dance club, surfboard shop, library, bathhouse.

We often think about hours of game-play; typically 40-100 are in a well-built standalone game. Multiplayer games are just getting started after 40 hours. Kesmai customers typically play for hundreds if not thousands. The people they play with keep them coming back, along with their perceived identity within communities.

Other elements are key to multiplayer design - and often to standalone games. Note how all these elements meet fundamental human desires.

Ownership

Some want their ranking impossible to ignore, some to own items or places, others to join military units they can make famous (infamous). In Multiplayer BattleTech, experienced players recruited and trained new players in their units. In most Kesmai games, we also ensure players have access to their statistics, possessions, and personal "handle" online. Consider economic issues as well: one Sword of Power can be as big a problem as every player having one.

Discovery

In most successful games, players uncover new elements as they progress; people want to find new depths at their own pace. This is easy to do online where you literally add to the host any time, as long as the architecture you have built allows it. Special scenarios can be organized by the company or by players themselves.

Persistence

Players want to have a permanent effect on the world, and this illusion helps suspend disbelief. The difficulty is in making an environment consistent yet not cluttered by debris from previous play, and/or hostile to players entering for the first time. Most Kesmai games have a continuous world environment with "Resets" occurring at regularly scheduled real world times.

Contributing Content

Naming a character, owning a room, telling the story of a recent triumph (tragedy): all satisfy deep needs. Scenario editors and game engine hacks currently extend the life of standalone games. They also enable a subset of customers to create yet more content. You still have to review and approve anything before adding it, but let players create as much world as possible. Remember there are more of them (players) than us (developers), so even a small percentage can create far more content than any development shop. Players contributing content also tap into a whole new level of perceived ownership, becoming de facto co-designers of an environment they will defend to their dying breath. Kesmai players since the mid eighties have organized conventions, built hundreds of web pages dedicated to the games, and posted thousands of stories of their adventures.

Three technical issues should be discussed.

Architecture

There are two fundamental models of multiplayer architecture.

Peer-to-peer. In most small-scale and LAN-adapted games, each player broadcasts information to all other players. This is fundamentally unscalable, breaking down when 4-8 or more players are dependent on the bandwidth a game requires.
Client/server. More popular for large-scale games is the client/server model, where the majority of the game resides on a host computer(s) and each player computer has a client front-end. Partitioning and selecting which updates to send to each player allows games of hundreds or even thousands. One player can be the host computer, but this raises many issues. The host must be fast enough to serve all players, and a player-computer host must also run that player's front-end without giving him an advantage (disadvantage). Connection quality and bandwidth also affect all players.

The preferred solution in our experience is a separate host with high band-width, T1 or better. Our hosts at Kesmai, primarily HP class computers, support 400 to 1200 simultaneous players, depending on the computational complexity of the game. We have also run Pentium servers using LINUX with loads up to 40% of what the HP computers handle.

Spanning Hosts

Most games have to partition people in some form across multiple host computers. A poker lobby may have dozens of people in it, for example, but your goal is seat tables with only seven people, and that is where they will spend their time. Our Air Warrior hosts support up to 200 players in the same game world, but we limit arenas to 110 people for gamc play purposes. Any higher, and players congregate in massive dogfights, which actually degrades their entertainment experience. Using such an arena construct, we can support thousands of players simultaneously; we have actually seen over 1,500 at a single time. Another idea is to have different geographical areas on different computers, and move players from computer to computer as they cross boundaries within the game.

Latency

Packets of data take time to get to the host or another player. Latency is high: 500 milliseconds is pretty common, and 1000 milliseconds-one whole second-happens often. Latency also is often inconsistent; a great connection now could get bad for several seconds and then get better - or worse.

You are doomed to disappoint customers if you design for a minimum latency or assume consistency within a connection, for any games not naturally played in turns or at a slow pace. The best adaptation is to minimize latency's impact. Design from network restrictions outward; accept limitations and work within them, rather than trying to force-fit games to the medium. If you want a Street Fighter-like fighting game, for example, to work with real-world latency, you have a couple of choices. You would have to make it more abstract, perhaps controlling player characters through training, planning, or coaching and directly during combat. Or you might only let players fight enemies which are controlled by their local front end software; the computer controls their split-second reactions and not another human several hundred milliseconds away in time.

We will look back at the 1977-199? period as an anomaly. We only built standalone games because we lacked the technology for meaningful multiplayer ones. Sure, we built some wonderfully entertaining solitaires over the last 20 years, but as the world gets connected they look more and more like buggy whips in an age of automobiles. Don't think how to entertain a single customer. Think how to make each player a member of a group, and then entertain groups of players.

My next article is on business models for online games.

[Panel]

Gordon Walton has been writing games since 1977. He has personally developed over two dozen games, primarily in the simulation and strategy categories. He has had his own development company (twice), been Development Manager for Three-Sixty Pacific and Konami America, VP of Development for GameTek and is currently Sr. VP of Entertainment Products for Kesmai Corporation, the leading developer and distributor of multiplayer online games.
gordon@kesmai.com

Richard A. Bartle (richard@mud.co.uk)
21^st January 1999: mpdi.htm