[vworld-tech] Ultimate MMO Platform
Dave
fear at planetquake.com
Sun Apr 11 16:00:50 PDT 2004
I've been reading the archives and I've only just joined the mailing
list so I'll just reply with a collection of some of the points I want
to make.
For the Ultimate MMO Platform scalability is a must. Scalability is near
impossible to achieve in a generic way. It can not be achieved without
understanding the runtime nature of the application running on the
platform. For example, what if everyone trys to go to the same place?
What if they all join the same chat channel? Scalability can only be
engineered for the specific set of interactions. Unfortunately even the
ultimate MMO is face with this same problem. The only way I can see the
solution is to separate the interactions. So one network for chat
channels, another for spatial interactions, another for file
distribution and so on. Alternatively some way of providing a best
compromise between the various services, for example sacrificing latency
to maintain scalability or limits to the numbers of agents replicated.
Peer to peer systems provide (relatively) low latency data delivery with
excellent load balancing. In the case of content distribution this is
the ideal solution. Its even seeing real world uses, World of Warcraft
(WoW) is using bit torrent to distribute its content for the beta.
Why would you want to be a peer of a virtual world? Apart from the
physical service of hosting, I believe to create content or more
specifically, to act in some way not constrained by the existing rules.
For the vast majority they don't need to be a peer.
I dont believe the idea of a "consensual reality" will work in the
context of an MMO. The real world has constraints. There are physical
laws such as gravity, limits on resources and so on. To create a world
you do need a set of constrains and something to enforce them. Players
need security if you expect them to invest any time in a system. If you
cant provide this stability you won't get the players. In fact all
distributed systems have these constraints. Just look at file sharing.
Most file sharing networks are polluted with fakes, poor quality files
Trojans and worms. What is required is a trusted source, such as bit
torrent tracker, a file hash website and so on, you find the file that
you want and then download it. Of course in these systems you can choose
to ignore these constraints, at your own risk.
The Ultimate MMO Platform should share this quality, as should all
distributed systems. You should be able to choose who you trust. Whether
that be a cluster of nodes, that you pay to provide this reliability
(E.g. traditional MMORPGs, i tunes, etc), or to the other extreme a
free, free-for-all (gnutella, kazaa, etc).
Of course, for the vast majority of users people do not want to be a
peer and you cant really force them to be. Just look at the web. You
dont have to host a web page to read it. You can provide users with
incentives for becoming a peer, such as increased bandwidth as in file
sharing system like bit torrent.
Most of the research (and for that matter most of the systems) in p2p
applications are about identifying and distributing resources. This is
not the case in MMOs. An MMO is about interactions between players,
whether that be chatting or killing goblins. The topology can not be the
same as traditional file sharing networks. The ultimate MMO will have a
topology which self organises to provide the required connectivity with
the minimum of latency.
Distributed systems are difficult to design, write, reason about, debug,
and tune. The ultimate MMO should try to alleviate this problems. Any
normal language construct on shared data must be handled differently,
which to me implies that, at a low level, special abstractions are
required for shared data or methods (both synchronous and asynchronous)
You could write books on all the things I've talked about if you really
wanted to produce the ultimate platform. However the best approach, as
with all software development, is to produce only whats necessary and
make it as re-usable as possible and to re-write the parts that you need to.
Dave
More information about the vworld-tech
mailing list