How can I make a peer-to-peer multiplayer game? [closed]

Question

How can I make a p2p multiplayer game? I would like to have a server-less multiplayer game. But then, how all the clients know each other?

Why the p2p-protocol is so famous in file transfer but not in multiplayer games?

Answer 1

Peer to peer games generally still have a game host. Its the game host that posts the game to the master games list and accepts new connections. Whenever the game host accepts a new client to the game it notifies all existing clients about the new client so that they can ensure they connect to the new client.

The simplest way to implement p2p is with a lobby. All clients connect to the host in a lobby (or chat room). When the host is ready the player presses start and they all enter the game at the same time (commonly used in strategy games). A more complex approach is to use "drop-in drop-out" where players can join and leave mid game, however this is a lot more complex to implement in a p2p game and requires a feature called host-migration.

A good number of games use peer to peer networking, including most strategy, sports and driving titles. Just about all Xbox360 and PS3 games use p2p networking. The client-server architecture is mostly used in first person shooter or MMO games.

Client-Server is generally easier to implement as only 1 machine has not know the entire game state, the clients are basically just renderers with some prediction to make things look smooth.

When you build a p2p engine, all clients need a full state of the game world and they all are required to stay in sync.

For more details on p2p and client-server architectures I suggest you read the following article: What Every Programmer Needs To Know About Game Networking.

And if you're new to networking in general checkout the other great articles on that site. Glenn is a networking genius.

Answer 2

There are some interesting aspects about peer-to-peer systems and action games. I tried to post them as a comment on Glenn Fiedler's blog, but apparently he doesn't like to be proved wrong and pulled the whole article instead. It's on Internet Archive, in case you want to read it.

He didn't let the comment go online, so I'll quote it here:

The Peer-to-Peer suggestion from the first post is actually an interesting starting point, even though it's a bit naive at times: The first possibility would be to combine the system with a standard client/server model with prediction as outlined in your post about game networking. The lower P2P ping would dramatically reduce the prediction lag between players depending on their location: The effect probably wouldn't be visible for most US gamers, but here in Europe pings of 200+ are normal on most servers and a direct connection would reduce the prediction lag to that of a European server.

A true P2P approach without server is a bit more complex: A main concern with decentralized networks is ensuring consistency, especially if the simulation could suffer from butterfly effects because of slightly different timing of commands sent over the network or floating point issues. This is possible by networking the state of each object (players, NPCs, ...) at least periodically. It wouldn't even be necessary to do it for all objects at once, and each client could take possession of certain objects. Networking enough objects in a certain time should damp the difference that builds up between each synchronization of an object enough to become irrelevant even for sync-intervals of a second or more.

The second problem with P2P systems is security, but that can be solved with a relatively small fix in this case: The clients can use their physics simulations to collect information about the error level on each physics object. Manipulated physics always result in a larger error, so the clients would simply "vote" to disconnect from the peer controlling a suspicious object. Additionally, control messages for non-physics objects are forwarded between clients based on their importance: Player updates can be forwarded randomly, important and infrequent updates should always be sent, but still to a random player. This way a player would have to control a large share of the connected clients to be able to cheat in any noticeable way.

[...]

You can find the thread I'm referencing at http://www.devmaster.net/forums/showthread.php?t=14640.

I think someone mentioned the firewall problems peer-to-peer has in one of the threads from the article. A possible solution would be a NAT-Punchthrough:
- NAT Punchthrough overview
- Peer-to-Peer Communication Across Network Address Translators

There is no 100% success rate, so you should tell the players to open a port anyway.

Answer 3

There are many reasons p2p is not popular in games, mostly due to lag. Everyone is as slow as the slowest player. We're not talking about bandwidth here, but ping time.

p2p can transfer tons of data, but it does so with a quite high ping, games need to transmit very small amounts of data, with minimal ping time.

Answer 4

A good example of 'true peer-to-peer' gameplay would be a real-time-strategy game such as Starcraft.

In a game with hundreds of units/projectiles in motion, it's not practical to repeatedly send unit positions/states over the network to all other players, so one solution here is for all players to run the (exact same) simulation in sync.

When one player performs an action, the command/order ('move zergling to X,Y') can be sent to all other players, to be executed by all instances of the simulation a fraction of a second later.

In this situation, if any player disconnects, the game can continue - as there's no need for a server/host to be running the game, the remaining players can carry on.

However, keeping the games in sync is non-trivial, you have to use a fixed timestep for the game logic updates, and must be very careful with use and seeding of random number generators, to ensure that the simulations will not diverge!

Answer 5

It would be a bit disingenuous to claim that it's not famous for games when most Real Time Strategy games (Star Craft series, Command and Conquer Series) and many FPS games (Call of Duty: Modern Warfare 2) use it.

That said how one learns about the game is up to the matchmaking / lobbying service that you use or create. But even once one learns about the game, there still may be one or more peers that are more equal than others. Consider the case of 3 clients wishing to play, one behind an open nat, 2 behind strict (Closed) nats. The open nat peer can take connections from the other two. But the 2 strict can not connect directly to each other, they will require the open nat to relay the packets. If the open nat peer drops from the game, then either another relay would need to be found or the game will be disrupted.

Answer 6

you may also want to check out Badumna (www.badumna.com) which claims to be a peer-to-peer networking solution for online games. It seems to do the game state synchronisation in a distributed manner and according to their website there is a Flash version coming.

Answer 7

You probably want to run with one player(We'll call him/her the "Host") as a non authoritative server. You'll have all the other players communicate what they are doing on their end with our host, and the host will relay the messages to the other players.

You probably also want to pass a list of what computers are connected to the hosting player so that if they drop a new host can be chosen somehow and start communicating with the remaining players.

The documentation for smartfoxserver may help you out and/or you may end up wanting to use it for your game as well. You'd just embed it into your client game instead of having a separate client and server program.

Answer 8

I'm a little bit interested on this matter. You are saying there are a lots of problems with making a game p2p instead of a classic client-server model. But i'm pretty sure that p2p is like client-server but every peer has the chance to become a server. About the LAG if u add one more machine as a server there are more probabilities that many clients are further from the server, but using p2p there are no extra machines in the lobby u can manage the latency tests and create groups with minimal ping. About the traffic generating, as i've learned you must ask the clients to transmit lesser than less i mean the clients have to figure all the other clients are willing to mean.

Answer 9

If you're making a relatively simple looking mmorpg with low system requirements, I'd suggest creating an internal program that creates a "frequency" based on the contents of the game's folder and what the files consist of. This will make people with the same "frequency" play on the same channels. Modded, manipulated or normal clients will be separated. This will only work for native hacks or mods, but I'm sure this covers all of the "dumb" cheaters. Combined with the error checking method that one person mentioned means little to no moderation required. As far as ports go, just have it cover port 52225 with a background process that keeps it plugged on routers without trigger-ports.