Contents  Introduction  If You Bring  Them...  Game or Players?  Communication  Protection  What to Have  Conclusion  Printable version

What should you have in your game?

All of this is well and good, you say, but how much of this do you need to support in your game? Obviously, games such as Quake have been and continue to be incredibly popular with little more than a mechanism for swapping pre-recorded insults. So it should be pointed out that not every game requires every communication option.

Use of a Lobby

A "lobby" for the online portion of your game can carry the weight of the inter-player communication burden. This leaves the actual game free to provide only the bare essential communication options, such as taunting and team chatter.

The lobby can likely devote as much screen real estate as necessary to any and all of the different communication types: general chatter, small groups, person-to-person, and so on. After all, that's what the lobby is for: bringing players together.

Teams Having Their Own Forums

If your game supports teams of players, you should definitely consider including specialized team-only forums. Primarily this will mean giving the team its own "small group chat" forum and, possibly, a note system that is specific to team.

A separate note system for teams might be a bit of a luxury, depending on the game in question, but a dedicated team chat forum should be mandatory.

Scrolling Text Considerations

An important consideration is how much screen real-estate should be devoted to the display. The number of visible lines depends on the number of people in the forum who are attempting to maintain a conversation. The more people talking at once, the more lines must be visible so that the player can see what he's interested in and be able to read it before it scrolls off the top of the screen.

For a general chat forum, the entire screen might be necessary simply from sheer volume. On the flip-side of that, a two-person private chat could probably get away with only 2 or 3 visible lines. Or maybe even adopt the ICQ format and use small pop-up windows with each message.

It's possible that your game simply cannot afford to allocate space exclusively to displaying in-game chatter. In that instance, consider where the text could be combined with some other on-screen element. For instance in Quake, the text overlays the main display for 4 lines of text at the top of the screen. In our game, Artifact, we built in the option for game messages and player chatter to overlay the main map. Both of these allow for a more "heads up" interface. The player can read the chat immediately and respond at his leisure.

Another consideration is the range of characters to allow in the text. The standard ASCII character set is probably sufficient (character values 32 to 127), but it might prove interesting to allow characters outside this range. Earlier versions of Quake allowed players to use non-standard characters in their names and in their chat. The players found creative uses for the different "block characters" to create text "banners" that would scroll by. Unfortunately, however, they also used them in their player names making it difficult for system administrators to kick them off when they became disruptive.

"Buddy" Lists

When the potential number of players online at any time is large (more than 100 or so), it can be difficult for players to see if the other player or players they wish to talk to are also online. Allowing the player to setup a "buddy list" can alleviate this problem. The player immediately knows if her "buddies" are online or offline and can easily talk to one or more of them if she wants.

Since the buddy list applies only within the game, the implementation can be kept simple. It's feasible to limit the functionality to simply displaying online/offline with an option to open up a person-to-person chat session and/or send simple messages. The feature list doesn't need to compete with ICQ to be extremely useful within the game.

Voice Communication

While voice communication is becoming more and more viable, it's bandwidth requirements are still quite high and the nature of voice communication limits it to only a small number of participants. If you have more than 4 or 5 people in a group talking at the same time, it essentially ceases to be a conversation and becomes a cacophony. In a scrolling text scenario, however, it's not uncommon to have hundreds of people conversing on a variety of topics and even engaging in semi-private side conversations.

Voice communication provides an excellent in-game team-coordination feature, as shown by the success of the Roger Wilco product (http://www.resounding.com) and Multitude's online game, Fireteam.

Arguably the best small-team communication option possible, voice communication is, unfortunately, not a method of meeting and interacting with a lot of new people. So voice communication can augment an online community, it does not create it.

Next : Conclusion