Multiplayer and networking

[AJ Infinity]

I'm totally new to multiplayer programming (in C++, I've had experience in Flash/Java). How do I do it? With a GameRanger plugin? Please, help. I'm completely lost.

I've figured out sockets, but I want full multiplayer.

[Sta7ic]

Multiplayer requires that determine if you have a server-client or game machine setup (handles workload vs. broadcast action msgs), construct a packet structure, and determine how things can go wrong and rig exceptions/error handling (if != 0), at the very SWAGing least.

Ref gamedev.net and/or _Game Programming Gems [1]_, 1.11 A Network Protocol for Online Games, by Andrew Kirmse. There's a link he cites, but it's dead.

Other resources will help, m'thinks.

-Sta7ic

EDIT: Had link, checked, removed.

[FCCovett]

Man, multiplayer games is a very complex subject. Connecting the clients to the host is going to be the least of your worries.

Some important messages have to be distributed via TCP protocol while player position is broadcast via UDP. On top of all that, you need to decide how the application is going to handle all messages, from username/password combos to things like player roster, which player has just connected and is waiting in the lobby, chat messages (for team-only, public, lobby-only, or in-game-only), and the list goes on.

Also, you have to worry about bandwidth budget, which changes drastically with the quality of the connection of the players, cheating and aimbots, and a lot of issues that come with latency and bad pings to avoid "warping".

I made a multiplayer game just to have more than 60% of the current players requesting a single-player mode because they have little interest in playing online. As much as I want to make more multiplayer games, my next title will be single-player only.

Anyway, there are some great articles on www.gamasutra.com that talk about a lot of those issues, but you won't find any code examples. Check the one about the making of "X-Wing" as it's a great article on all the problems that can go wrong in multiplayer games.

[quillbit]

Games are like any other distributed computing application, only more so.

That is to say, games have perhaps the smallest tolerance for lag, insecurity, and synchronization failures within the set of non-critical software. Because of this, you have to design your distributed computing (DC) environment to fit your application's requirements; there is no one-size-fits-all solution.

The technical tools are well-known and straightforward, ranging from rolling your own protocol over UDP at one end to using PDO, RPC, or even (shudder) CORBA at the extreme other. But you'll have to develop and code things such as prediction and synchronization algorithms to deal with uncertainties between distributed nodes (a perennial problem with high-speed games like the Quake series), slicing methods to reduce sent data to minimal amounts, and security measures ranging from trusted-server (most games) to trusted clients (such as the Netrek client hash) all the way up to cryptographic protocols (e.g., mental poker games). You also have to gracefully handle a large number of special cases: network quality-of-service changes, vanishing clients, and garbled or malicious injected data.

Needless to say, there's also a huge difference in requirements between different types of games: consider AoE's peudo-random synchronizations (and the attendant out-of-synch issues) compared with LS:Nemesis' server-managed PBEM approach or the entirely server-oriented architecture of FreeCiv -- and those are only RTS or turn-based games, not even approaching the various ways to manage FP shooters!

I don't mean to scare you off -- obviously, multiplayer is a tractable problem, or it wouldn't be so common across a wide swath of games -- but you'll need to develop from the ground up for it. Keep in mind that the easiest way to prepare the ground for MP capability is to logically separate your code into client and server components; you want your rendering, display and input code to be reused no matter if it's connecting to a local server (for singleplayer) or remote (for multiplayer). But that doesn't even address the design aspects of the game -- there's a world of difference between a rules-bound game like a Q3 or UT*, and an event-driven game like an Oni or Max Payne.

I'd suggest starting with some of the academic research in the field; in addition to the usual network and protocol optimization research, try using Citeseer to look for articles on (for example) distributed computing, mental poker, and the consensus problem.

[Feanor]

Originally posted by quillbit
...But that doesn't even address the design aspects of the game -- there's a world of difference between a rules-bound game like a Q3 or UT*, and an event-driven game like an Oni or Max Payne.

<OT> This is not a distinction I have heard made before. Can you point me to some information about the difference between these two systems?

Thanks</OT>

[kelvin]

I'm learning Cocoa's NSConnection stuff. You can pass ObjC message directly between applications and threads, on the local host or over the network. I'm not sure, if it's good for gaming, but it seems to have a lot of promise.

I just have to dig my claws into Rendezvous now...

[quillbit]

Originally posted by Feanor
<OT> This is not a distinction I have heard made before. Can you point me to some information about the difference between these two systems?

Thanks</OT>

It's really a competitive balance, not a technical, issue. It comes down to the idea that there are really two kinds of games: the kind that is managed by rules, like soccer or Quake 3; and the kind that is managed by the triggering of events, like Final Fantasy or Max Payne. Most games are, of course, some amalgam of the two -- StarCraft, for example, is primarily a rules-based game with some event elements used to advance the plot, while Oni is heavily event-based, but has a strong rules foundation. (See also the difference between Myth and the ill-fated Myth III.)

Games that are developed primarily around their ruleset tend to have less complex plotting, but are more easily ported to multiplayer, since more time has been spent on ensuring competitive balance. Event-based games, however, spend less development time worrying about balancing all units, and spend more time on narrative and managing difficulty through the plot.

While above I characterized StarCraft as a rules-based game with limited narrative triggers, Blizzard's Warcraft 3 to me seems more of an event-based game, which is why I believe its multiplayer popularity suffers so much, especially in relation to its older cousin. By all accounts, the Frozen Throne expansion is the result of expanded work done on competitive balance issues, so perhaps the MP experience there will improve.

The moral is: budget your design time wisely. Most of us can't afford to be all things to all players, so if you're developing a narrative-heavy game, maybe multiplayer isn't a good route to take.

This is, of course, just my $0.02. Take it only as seriously as you'd like to. ;)

[AJ Infinity]

Originally posted by FCCovett
Man, multiplayer games is a very complex subject. Connecting the clients to the host is going to be the least of your worries.

Some important messages have to be distributed via TCP protocol while player position is broadcast via UDP. On top of all that, you need to decide how the application is going to handle all messages, from username/password combos to things like player roster, which player has just connected and is waiting in the lobby, chat messages (for team-only, public, lobby-only, or in-game-only), and the list goes on.

Also, you have to worry about bandwidth budget, which changes drastically with the quality of the connection of the players, cheating and aimbots, and a lot of issues that come with latency and bad pings to avoid "warping".

I made a multiplayer game just to have more than 60% of the current players requesting a single-player mode because they have little interest in playing online. As much as I want to make more multiplayer games, my next title will be single-player only.

Anyway, there are some great articles on www.gamasutra.com that talk about a lot of those issues, but you won't find any code examples. Check the one about the making of "X-Wing" as it's a great article on all the problems that can go wrong in multiplayer games.
Well, Rageflight is kinda like StarFox 64. You just wanna beat another player up in battle mode. :D Anyway, I'll just use CoreFoundation's CFSocket for head-to-head play and leave network play for Rageflight 2. I'm already working on some cutscenes and an intro in LightWave (and I'm really starting to wish I had a faster Mac. The scenes take too long to render)


The moral is: budget your design time wisely. Most of us can't afford to be all things to all players, so if you're developing a narrative-heavy game, maybe multiplayer isn't a good route to take.


Right. CFSocket will do considering one person won't want to get beat by 7 other people on his AirPort network. :) Oh wait, I guess RF won't go to Linux and Windows if I use CFSocket (oh well :D...I was going to take it)