he stole my wooby! - design goals for a multiplayer game service

Invisible targets don't get hit, except by chance. -- Tom Gilb 

(note: i wrote this in 1996)

QUESTIONS I'M ASKING

Q. What sort of multiplayer games are cool?  
A. Humans against humans, in two teams. Like sports, but with less grunting.  

Not humans against the software. Not humans against both humans and the software. Not four teams of humans all against each other. One gamer team against one gamer team. The software's job is to provide the playground, then get out of the way. 

For the purposes of talking about groups of humans, Studies Have Shown that there are four group sizes - one human, two to eight humans, less than one hundred humans, and more than one hundred humans. One human playing a multiplayer game is confused. Any team in the order of one hundred members is chaotic, albeit interesting. I like the idea of two to eight humans. It's enough to be interesting, but small enough to enable a sense of teamness. The more players, the more money, so let's choose eight players a side.

Q. Why haven't we seen multiplayer games in video arcades? 
A. The cost of real estate. 

If an eight player game only works if you've got eight gaming stations, most of the time there won't be eight interested people around at the same time, and this means those eight gaming stations aren't paying for their real estate footprint. If an eight player game works equally well with any number of players up to eight, where's the value in having multiple gaming stations? An example of this is one of the car racing games, where you have four, six or eight car stations side by side. This is gamers against the software and against gamers, but it's not a gamer team against a gamer team.  

Another approach is to have multiple players at one station, like Gauntlet, which is four players. What I like about Gauntlet is that you play in a gamer team. This works, but it's still a gamer team against the software, instead of a gamer team against a gamer team. 

Another approach that is a gamer team against a gamer team is location-based BattleTech, where you go and sit in a pod and you can talk with your team members while you're bashing the other team. But it's too expensive, since sixteen pods in half a warehouse is a lot of overhead. And as a business, it doesn't scale very well to hundreds of thousands of locations.

Q. Who are the multiplayer game customers and what do they want?  
A. Gamers and game providers. Gamers want fun and game providers want profit. 

Gamers (I'm one!) want no-excuses, affordable, convenient, ubiquitous, multiplayer fun. Game providers want hassle-free, gamer-attracting software that they can charge dollars for.

Q. Who are the game providers?  
A. The people with the online equivalent of real estate, which is managed-latency, inter-human connectivity. 

Inter-human connectivity exists on the net, but the latency isn't managed. The latency is managed on the gaming services like Catapult, Engage (Interplay), DWANGO, MPath, and TEN. The online services like MSN and AOL want to be in the multiplayer game business as well. I think there's a big opportunity for cable TV and local loop telephony providers. These loops are connecting many humans from the same geographical area together, so it's likely I'll find my buddies easily, and the data pipe might not go through too many routers. There's money to be made for BBS operators too. Those sixteen or thirty-two telephone lines lying idle since everyone discovered the net and switched to ISPs are a golden opportunity, because those lines have the complete attention of the computer(s) serving them. Cheap managed latency. Regional internet service providers and local internet service providers probably want to get into the game too, and then there are services like TCI's @Home and Time Warner's Full Service Network. 

There's one major trap that all of the above potential game providers may fall into (and I think some of them have already fallen). This is the trap of confusing the road with the car, the pipe with the water, the network with the traffic. If you're in the business of building roads, don't be in the business of building cars, and vice versa. You can't afford the split in focus. Different criteria for success, different risks, different business models, different revenue streams, different cost structures, different customer groups. 

Different. 

Hardware manufacturers shouldn't directly build content. Are you in the hardware business, or are you in the entertainment business? Game builders shouldn't build developer tools. Are you in the entertainment business, or are you in the developer tool business? Content providers shouldn't build the network. Are you in the entertainment business, or are you in the infrastructure business? 

Different. 

Peter Drucker says we should continually ask ourselves "What is our business, and what should it be?". He's a wise human, Peter Drucker.

Q. So why do I care and what do I want?  
A. I love multiplayer games and I want to build them and create the online equivalent of a coin-op business.

QUESTIONS GAMERS ARE ASKING

Q. Can I get a game now?  
A. Design for availability.

Q. How many times has something interrupted a game I've been playing?  
A. Design for reliability.

Q. Can I get a game from my local ISP?  
A. Design for convenience.

Q. Where else can I get a game?  
A. Design for ubiquitous availability.

Q. Can I play through my existing 14.4kbps connection?  
A. Design for convenience.

Q. Can I play with my buddies?  
A. Design for finding buddies.

Q. Can I communicate with my buddies?  
A. Design for inter-player communication, including voice. Design for the not-too-distant future, when the casual gamer can afford realtime interplayer videoconferencing.

Q. Am I guaranteed not to be penalised for my connection latency or bandwidth?  
A. Design for fairness, in a world of unpredictably varying latency, and in a world where some gamers will have lower-latency connections than others. This means guaranteeing, to within some arbitrary number of milliseconds, that players are exposed to the same information at the same time. Call this the 'fairness delta'. The appropriate fairness delta will depend largely on the game. Ten hour strategy games don't need a fairness delta below a couple of seconds. Twitch games need fairness deltas in the tens of milliseconds. 

It's very likely that player clients will receive the same information at different times. This means we must design for exposing that information, say, on the screen, at a particular managed time. This probably means that some information will be kept hidden at the client until a certain time. This brings up the next issue.

Q. Am I guaranteed not to be playing against someone who has modified their client software for an in-game advantage?  
A. Design for prevention and/or automatic detection of tampering. 

This will become critical if we try to run any sort of sanctioned tournament. It will be extra critical if there are prizes.

Q. Am I guaranteed not to be frustrated by jerkiness or strange behaviour?  
A. Design for smoothness.

Q. What OS do I need to be running?  
A. Design for inter-OS client portability.

Q. Do I have a choice for client software?  
A. Design for intra-OS client personality.

QUESTIONS GAME PROVIDERS ARE ASKING

Q. What OS do I need to be running?  
A. (inter-OS server portability is not a design goal)

Q. Do I have a choice for server software?  
A. (intra-OS server personality is not a design goal)

Q. What sort of equipment will I need to be a provider?  
A. Per player and per game, design for server RAM, server CPU, server bandwidth, server disk, server support staff.

Q. If this service becomes popular, how much does it cost to add another game?  
A. Design for scalability - be able to predict the incremental cost of running another full game in 1) staff, 2) bandwidth, 3) RAM, 4) CPU, 5) disk.

Q. How many customer support queries can I expect a week?  
A. Design for reliability, design for usability.

Q. What sort of guarantee do I have that this game is not going to be a one week wonder?  
A. Design for repeated gameplay.

Q. How many new players can I attract per time period?  
A. How long does it take for a newbie to become effective?

Q. How does the billing work?  
A. Design for online transactions.

Q. What's a "wooby"?  
A. Dunno, but it would be real fun if you could steal them from your buddies in a multiplayer game.