[MUD-Dev] MMORPG/MMOG P2P design

[Crosbie Fitch]

From: Mike Shaver

>> Think in terms of 2 million PCs, not just 2. Massive redundancy.

> How do you get that data to 2 million PCs?

Not everyone needs all the data all the time. Sure, if everone had
multi-terabyte harddrives, everyone could contain a copy of the
whole world (if it was a small one ;-) ). Even so, not everyone
needs all of the most recent data all the time.

Just like with file sharing programs, you connect to the PCs that
have the data you're interested in.

> When I break the case on the grail, are you broadcasting that data
> to everyone with a then-live server?  Even if we pretend that
> multicast actually exists for the majority of internet-connected
> people, it's an ugly amount of data.

Nodes communicate only with those who have an interest in that part
of the world. Communication is prioritised by interest, so if a node
is only 0.001% interested in part of the world, then probably only
0.001% of that node's communication will be concerned with that part
of the world.

A dynamic hierarchy of nodes helps ensure persistence, e.g. 'A'
reports to a parent, and 'B' reports to a parent (possibly the same
one). It is also likely that all actions performed by a node a
reported to several other nodes.

> The system being self-consistent is one thing; how do you keep the
> _players_ from getting their knickers in a twist?  If I traded my
> shop and wares to some player for the Grail, and now you roll it
> back to being in the case, what happens to my shop?  Sure, your
> distribution infrastructure ran through its quorum mechanisms
> again, and decided that Server B > Server A, but the idea that the
> results of my actions can disappear after I've been told they
> happened sucks.  Players hate rollback, and if it happens a lot --
> what do you expect the aggregate MTBF is for a system with 2
> million PCs? a few minutes? -- you're going to have a hard time
> getting them to stick around.

You get the same problem with a client/server setup. If C
disconnects from S you typically don't allow C's player to carry on
regardless, if upon reconnection S will discard anything C did in
the interim.

If A becomes completely isolated, then you've simply got to indicate
to the player that there's a problem, e.g. freezing time and
allowing them to 'ghost out' of their stationary avatar or
something. But, we're focussing on a small problem here, like an
eCommerce site owner complaining that something must be done in the
event that a customer's connection fails mid-purchase. Sorry, but
this happens and there ain't a solution. When someone is
incommunicado, there's nothing you can do. The important thing
though is not to believe that is a problem peculiar to distributed
systems, or that it hits them any harder.

>   (Or they'll figure out which servers are going to win an
>   argument, and only play on those, I guess.)

There ain't no servers. However, the system will automatically
self-organise to put those PCs that are most reliable, have most
availability, have most capability, in effectively similarly
important 'server like' positions in the node network. The players
don't have to do this - nor should they.

> Interesting games are about interesting choices and interesting
> consequences, IMO.  Unless your game-fiction goes _very_ far out
> of its way to make the idea of a flaky cause-effect chain
> reasonable to the players, the fact that the consequences of your
> actions may well not exist when you log in tomorrow makes for a
> pretty poor play experience.

I quite agree.

> And then you have to deal with the fact that when someone turns
> their computer back on, you have to do this quorum,
> validate-against-the-world dance.  How long does that take?

Well, yeah, there'd be a delay (but not a quorum thingy - once
you're offline, you have no say).

However, the idea is that you leave your PC on. The better
contribution you make to the distributed system, the better quality
your experience becomes (less laggy, richer textures, higher detail
geometry, etc.). Other players will make use of your PC even if you
aren't.

> How does the problem of "convince everyone else that Robin's socks
> are red and not blue" differ from "inform the other servers that
> Robin juust dyed his socks legally"?

In the one case you have a 100 hackers who've made a change to
Robin's properties directly and are pretending to own them (have the
authority of arbitration). In the other, Robin made the change
through legitimate ownership. You can check ownership simply by
going through the hierarchy. In a simple democratic voting system it
may be possible to surround someone with planted peers and if peers
are all you can check against then you may end up believing
anything. It's much more difficult to corrupt a hierarchy because it
takes time to get to the higher positions (difficult to put plants
in the right places).


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev