P2P Internet Multiplayer

Started by
28 comments, last by Wormhole 21 years, 7 months ago
I''ve seen lots of stuff about client/server multiplayer. Peer-to-peer looks interesting, tho. Would anyone know where I might be able to find resources about developing internet-based multiplayer games using P2P? Does anyone have any thoughts on P2P or what it could mean for gamers (besides downloading a free copy of the game off gnutella, cmon)? thanks ------======||||||EEEEEEE*<
------======||||||EEEEEEE*<
Advertisement
I should clarify that I''m intending to develop for the PC (Windows, maybe, possibly Linux), not wireless phones.

------======||||||EEEEEEE*<
------======||||||EEEEEEE*<
Do a search of this forum, this topic has been discussed a few times.

NAT, security, latency, and bandwidth will be your big problems using this model.
quote:Original post by Ixpah
Do a search of this forum, this topic has been discussed a few times.


The discussions are interesting, but they seem a little too specific or a little too much like arguments to be really useful at this point. I''m not necessarily talking about any specific kind of game being implemented with P2P. I''m talking very general here.

quote:Original post by Ixpah

NAT, security, latency, and bandwidth will be your big problems using this model.


Okay, maybe it''s just because I haven''t read too many books on networking just yet, but I have no idea what the hell NAT means. Please define and elaborate.

Security is always a concern - it doesn''t matter whether you''re using P2P, Client/Server, a genie in a bottle, or a bunch of hamsters to run something over the internet. I''m wondering what existing P2P networks like gnutella and limeware do about security?

Lag sucks. How do you get rid of it? It seems like it''s really tied in with bandwidth, am I right? you know, more bandwidth = less lag.


------======||||||EEEEEEE*<
------======||||||EEEEEEE*<
While its easy to see where you get the more bandwidth/less lag association this is not the case. It just happens to be that a higher bandwidth connection usually has less lag. A counter example of this would be a high speed sattelite connection. You can get download speeds that rival any other high speed connection, but because of the distance (and perhaps some other factors) you get horrible "lag".
Right, and as such, lag is much more commonly associated with stuff that''s not even related to the game itself.

Found a somewhat dated, but relevant rant on this:
http://www3.sympatico.ca/glacier/pf140398.htm


Technical nitpicking aside, a peer-to-peer network is very, very different from a client/server network and is going to be better at some things and worse at some others.

i.e. Imagine a game network that instantly gave you access to every custom map ever made for that game. P2P would be fantastic for something like this.

That''s just the beginning.

Using P2P to handle multiple real-time connections presents lots of problems. The lag issues discussed in the above mentioned article affect everyone else''s ability to operate instead of just the server''s. Good client-side connections are absolutely more important than ever in a real time P2P network.

------======||||||EEEEEEE*<
------======||||||EEEEEEE*<
Upstream bandwidth is a huge problem with this model. Instead of sending updates to one location (the server) each client has to send it''s updates to all the other clients.

When you couple that problem with the fact that clients typically have less upstream bandwidth than downstream, you start to realize why most network games these days are client-server...
NAT (Network Address Translation).
Often people connect through a proxy/NAT router. What this means is they don''t have a Internet usable IP address, so they can only initiate connections.

Bandwitdh/Lag
Even though ADSL/Cable has 500kB/250kB downstream/upstream bandwidth doesn''t mean that all of this is available 24/7. ADSL has contention ratios of 20:1 and 50:1 in the UK. This means that you are effectively sharing you bandwidth with 20 or 50 other poeple. Cable has similar but different restrictions.

Security
For a non-persistant world then things may not be to bad, but if its a MMORPG then you will get all sorts of hacking problems. This is due to the fact that they will get access to all of the code and data, instead of a limited subset of it in the case of a client/server system.
quote:Original post by Ixpah
NAT (Network Address Translation).
Often people connect through a proxy/NAT router. What this means is they don''t have a Internet usable IP address, so they can only initiate connections.

Bandwitdh/Lag
Even though ADSL/Cable has 500kB/250kB downstream/upstream bandwidth doesn''t mean that all of this is available 24/7. ADSL has contention ratios of 20:1 and 50:1 in the UK. This means that you are effectively sharing you bandwidth with 20 or 50 other poeple. Cable has similar but different restrictions.

Security
For a non-persistant world then things may not be to bad, but if its a MMORPG then you will get all sorts of hacking problems. This is due to the fact that they will get access to all of the code and data, instead of a limited subset of it in the case of a client/server system.


So far, based on what I''ve gathered from this and other discussions, is that an MMORPG is pretty much impossible to do using P2P under current technological conditions. That''s perfectly alright. I don''t want to beat a dead cat here. My goal for this discussion is to find out what kinds of games *are* possible and maybe identify a genre or two that could benefit with a P2P setup.

At this point, here''s what a P2P game might require (probably way off, so feel free to amend):
any non-player data must be static
each player must be responsible for sending updates to their state to all the other players
each player must be able to check updates from other players using the same set of rules for the entire duration of the game

------======||||||EEEEEEE*<
------======||||||EEEEEEE*<
I believe Battlezone 1 was a peer to peer game.

A given player sends updates for his tank and all the tanks and buldings under his direct control to all other machines.

For the most part, the client machine also decides if a weapon hits their own tanks, and guided weapons are implemented at the client level, which caused some interesting bugs:

A guided missile was fired at a tank during deathmatch.
The player evaded and passed in front of another player.
Both tanks exploded, because on both players' machines, the missile flew into and struck their tank.

Battlezone 2, however, was a client/server game. Even your own tank's position got corrected from time to time, and units you thought you blew up before would reappear because of a massive gamestate update from the server. That's part of the problem with real time 3D real time strategies. So much variation and possibility needs correction from time to time, and the false state could exist for 5 seconds or more before being corrected.

Point and click RTS's and simple FPS's generally do well online, because the RTS's are less randomized in the way they handle the units (less variation then real time 3D RTS) requiring only information about where they are going and what their target is, and FPS's don't transfer so much data across the wire.

And that's my little case study for the day.

[edited by - Waverider on August 16, 2002 3:35:07 PM]
It's not what you're taught, it's what you learn.

This topic is closed to new replies.

Advertisement