The main challenge is cheating/security.

Another of the challenges is: if I am far away from you, and thus we're not currently sending information to each other, and I then move close enough to you that we should "discover" each other, then how does your peer and my peer find each other? Doing this entirely peer-to-peer is not yet a solved problem; there's always some seeding server that starts up the process in the architectures I've seen.

A third is that of efficiency: when you use client/server communication, then you send only your data to the server, and you receive a consolidated packet with the N closest entities from the server. Header overhead is small, and upload bandwidth use is small. In P2P, you have to send your data to each of the N nearby peers, which means your upstream is suddenly multiplied by N; further, you'll receive updates from the N closest peers as individual packets, instead of consolidated packets, for much less efficient usage of your network link. This is extra bad because most consumer broadband connections are asymmetric -- there are cable connections with 4.0 Mbit down, and 48 kbit up!

If you really want to look into P2P MMOGs, then I suggest you google for the "VAST" project; it's an academic research project and open source effort on the subject.

Hey everyone. This topic comes up often enough. Suffice it to say, this is a more diffilcult problem than the OP recognizes, but not as difficult as everyone else has been saying. It is not impossible to fix at least some of the problems mentioned here.

Possibly the easiest to fix is "having to send positions to everyone". Instead of considering your network distributed clients, consider them distributed servers. Instead of each "client" holding their own info, they are responsible for some other set of information. For example, one client could be a set of shops, another NPCs, and another player positions within a zone. On top of all this put a server that knows who has what. The server just needs to distribute that info as needed, and then the clients can talk ot each other to actually play.

Security is a more difficult beast, but steps can be taken. Redundant data across clients is one possibility, where the server checks data veracity every once in a while or only checks when clients disagree with each other. By intelligently copying data across clients you make it so that a cheater has to control a large percentage of clients to cheat (at which point you could even instance a new world just for the cheaters).

Of course, every possibility also raises questions of bandwidth. Creating data redunandancy also means increasing the required bandwidth for each client. Doubling redundancy can also mean doubling bandwidth. You also have to deal with the normal connection issues like lag, except with someone elses computer playing the server.

Sadly, it isn't as simple as assigning each client a small load of the world(shops, npc's, etc). On the other hand, if you "packed" your server objects, you could assign, let's say, a pack of 5 npc's from the graveyard to 2 clients. This would cause the server to have a backup type system incase one player drops, bringing us to the question: What happens if the 2 clients drop from a power outage in their area and they were assigned the same pack? The npc's in the graveyard would have no interaction with the game world? They would disappear until re-assigned?

Before you say that redundancy is a solution, I encourage you to actually try implementing it, and trying to avoid world splits and keeping everything consistent. Let us all know when you've succeeded ;-) It's a really hard problem, that's not yet been solved in this context.

I have also tought about this, and what i found out is that you
have to redesign your game :-)

For example, you could be an iseland in an iseland world,
Iselands dont move, so P2P communication with nearby islands
would be possible, and would benefit your server. Your world could consist of simulation objects, like a bullit from A to B, and then maybe 3 peers could precalculate the result, and then compare the different results?

Slow changes could be a keyword here :-)

The free roaming open world MMO, with high speed action isnt benefitial
to do P2P as i see it.

Interesting, but I imagine the processing involved to keep track of which tasks are to be sent to which clients, which are in progress and so on would be as complicated as just doing the tasks, unless there's some really complex algorithms being run.

Quote:

have the data processing be sufficiently mystified and encrypted

That doesn't actually work, because no matter how encrypted or mystified something is, it can be reverse engineered, and the data snatched out of the memory as the CPU is working on it. A secure or trusted computing system must be built on algorithms, not voodoo.

Regarding farming out "batches of work" to clients: the reason we have servers is that games require low latency responses. Servers can have context for all questions they need to answer, and thus arrive at a low latency answer. If you "farm out" "batches" to peers, without those peers having sufficient context, your latencies will skyrocket, and the game will not be responsive.

Quote:

One of the other advantages of such a 'peer' system might also be the communications bandwidth costs can be distributed (versus the usual large pipe into a central server) to go along with the lower cost of fewer company run servers.

In a peer-to-peer system, I need to send my data to N other people, and I need to receive data from N other people, and I need to send data about more than just me, for redundancy, error resiliency, and security auditing.

In a client-server system, I send data to one place, and receive data from one place.

Clearly, the client-server system uses significantly less bandwidth. If the price of bandwidth is a marginal cost (which, in aggregate, it is for society at large), then client/server solutions are actually more economically efficient, and deliver better experiences for cheaper aggregate cost than peer-to-peer.

To view it another way: You would need, say, a 4 megabit peer-to-peer connection to get similar network fidelity as you'd get from a 1 megabit client-server connection. If the client/server costs less than the price difference between those two connection types, it's actually a win, even for the user.

Quote:

Combine that with having the task program's code mutate (new differently compiled resent every day -- or even more frequently) to make it nearly impossible to reverse engineer fast enough

In my opinion, no organization could QA code that mutates several times a day. There are only a finite number of scrambling techniques, after all. The best you can do is change parameters of a known algorithm, such as keys. There are simple attacks that run deltas on diffs (because you need to distribute these changes to all players, right?) and determine what the change is. If you think the user machine can be trusted at all, you probably shouldn't spend your time on trying to frustrate the untrustworthy users; your time is better spent on designing game mechanics that don't benefit from client cheating.

Take a look at my thesis I have several examples of P2P MMORPG models as well as anti-cheating measures. The thesis deals with RTS games but the model can easily be used for MMORPGs


www.p2pgamenetwork.com


Middy

A trusted peer methodology is really no different to the cluster architecture. Practical differences do apply (a far more unreliable infrastructure), as well as security considerations - actually letting players have a trusted peer is probably a bad idea, without some definite method of ensuring the peer is behaving correctly (which places load on your private 'seed' servers).

Really, it's a business risk - assuming your game is free, and no-one stands to gain anything in particular from hacking your peers, the risk to yourselves and your players is greatly reduced. A robust messaging system at the client end (the client knows what to expect) would allow compromised peers to be reported and removed from the heirarchy of servers.

If you were thinking of actually taking subscriptions, then your need for security is that much greater - if someone is paying you for a service then you have to do your best to ensure that service is provided.

A centralised private cluster is far less susceptible to attack than a distributed one on a basically insecure network. Another method of promoting trust might be that the 'server-enabled' versions of the game are tracked - by unique ID per installation - so you can permanently disable them from cooperating in the game if they are compromised. This would be through your standard copy-protection key code, same way as Gamespy and many other cenral-server lobbies do it.