(first post) Hi, I''ve ben having some ideas buzzing round my head about how you could have architecture for a open source p2p MMOG. Before I take some time to write them down - Has anyone been giving it thought or began this? Skill level: I am a professional web app developer. However, I don''t intend to pretend that I would try to do this, as I''m sure it would require many tools that don''t exist yet :D In brief, I''ve been thinking along the lines of game state distributed amongst peers acting as servers on a player-by-player basis, using a lightweight encryption/signing method to prevent tampering. Any interest in talking about this further?

A linked-list of players?


Any new coming player connects to a server which connects the player to the next player which connects the player to the next player..... until they''re at the end?


I think that would be pretty slow. How would p2p work with an MMORPG?


- Rob Loach
Current Project: Upgrade to .NET and DirectX 9

"Do or do not. There is no try."
- Yoda

The problem lies in the issue of persistence and environmental conditions, I think. Even in a limited scale multiplayer game, like an RTS or FPS, you have to have one computer keeping track of where everything is in the game environment so that it can broadcast that info to the other machines. With a massively multiplayer online game, you have the added problem of the persistent world.

A MMOG *must* have a dedicated server to keep track of these variables, even if the same machine that runs the server is also running a client (although this would be very slow with any significant number of players).

Its an interesting idea, but I just don''t see how it would be possible, at least without incredible overhead in resources available on each client.

****************************************

Brian Lacy
ForeverDream Studios

Comments? Questions? Curious?
brian@foreverdreamstudios.com

"I create. Therefore I am."

I''ve had some thoughts along similar lines - you definitely don''t need a single physical server - you can create a "virtual server" but I haven''t come up with a sufficiently convincing implementation to be sure it''s feasible.

The hard parts are: security - having to have every machine trusted rather than just one trusted server; assigning tasks (there may have to be a central server after all that just farms out processes to other machines); redundancy - making sure that if a player loses connection for whatever reason it doesn''t do terrible things to the rest of the players; and storage - how to keep track of game world data when no-one''s online.

There''s probably also slowdown issues when there''re only a few people present trying to divide the entire game-world between their machines or when there''re a lot of people present trying to maintain updated game-state.

As a side-note, the best possible propogation for a global message (assuming each machine can only pass the message on to a single target at once, can only send when not recieving and the time for the message to go from one machine to another is the same as the time for one machine to transmit the message) is O(log N) where N is the number of machines and assumes each time step each machine that knows the message sends it to a machine that doesn''t,

So are we talking something similar to file sharing? If so, and you have 100s or 1000s of PCs broadcasting you going to be slowed down in real time to an unbearable rate and since some of those files are going to be lost then this adds problems as well. I''m not sure I see that the benefits would be anywhere near enough to outweigh the cons.

Let''s make this simple by answering the topic question:

NO

Problems: Bandwidth.

any online games require a packet a second to be sent, not necessarily a 2k packet, but at least around a 512 byte packet, maybe a bit smaller, but not much. that means that your limit on # of clients means that MASSIVELY Multiplayer is impossible.

Turn the "no" into a question instead; How can I limit the number of clients that need to be reached from a particular client every second, in order to fit in available bandwidth?

You may not be able to build P2P EQ, but certainly creations of "Massive" scale. Probably bigger than EQ (or any other existing live MMO) in terms of inhabitants at runtime. It just depends on what limitations on architecture you''re willing to live with.

Latency issues/reliability seem more of a problem to me than bandwidth. What do you do if one client on the chain is lagging to hell ?

Y.

Voxed:
I also played with this idea... it would be great! , but you first need to design a game that lives inside the limitations this give, for eksample: a full 3D world with thousands of players and gigantic combats could be a problem... :-)

instead of focusing about being many players, focus on that all players are human....

If you have a 8 connections system, and 3 p2p layers of connections... (posible to talk to a player via 2 other players)
you should be able to interact with 8*8*8 = 512 other players, witch i think would be great for a smal game!

Try to make a game design that dont have a problem with internett lag... then you are half the way! (more like 0.001% if you count in hours :-) )

The problem is the map! How can i test if there is someone at landsquere 34,859... well, you cant... :-) But who needs a map?
we need some other sort of world!
I would also go for smal data transfers... keep it simple!


To the rest of you:
A MMOG dont need to be a RPG or a RTS or anything like that... try to think in new ways!
What if Kazaa was a "gather files" game... its MMO and p2p!!!

quote: Original post by Ysaneya
What do you do if one client on the chain is lagging to hell ?

Redundant routes, reroutes.
Has a price in bandwidth of course, but I''d guess both are necessary.