On Tue, 5 Feb 2008, Eugen Leitl wrote:
> On Tue, Feb 05, 2008 at 09:53:10AM -0500, Robert G. Brown wrote:
>>> And they may well do this. There are a lot of problems in provisioning
>> online MMRPGs with "Universes" that are shared with HPC clusters and
>> with HA clusters. Most of the sane ones spin off the actual rendering
>> onto the clients, but they are still responsible for managing a huge
>> inventory of objects as well as all the NPCs, in realtime interaction
>> with PCs, in a large distributed "space". In some cases e.g. WoW the
>> The Second Life does the physics server-side. With the given technology,
> a region (one virtual server) will become sluggish (and soon herafter
> crash) after some 60-70 avatars frolick in the area.
>> There's definitely potential for better interconnects and game
> clusters (deja vu, we must have discussed this some 5-8 years ago).
Yeah, and my experiences with 2ndL are highly negatory as a consequence.
It is a bad cluster design. It does not scale.
>> space has some fairly obvious boundaries -- different continents are
>> plausibly on different servers in a realm cluster, ditto instances,
>> SL islands are rectangular boxes (the client used to crash spectacularly
> when altitude exceeded a signed short int). The world tesselates trivially
> on a 2d or 3rd grid/torus.
SL needs to adopt some of the technologies of other MMRPGs -- the ones
that work. It makes the result more complex on the client side -- one
has to update WoW every six months or so with new textures, maps, and
display side bugfixes -- but it scales much, much better on the server
side and is much less bottlenecked at the client side network (which may
be "only" DSL). SL is a resource hog all around.
I note that people are most impressed with it if they've never hung out
in one of the well-designed, scalable worlds of WoW. Any player of WoW
would laugh and cry to see how primitive, slow, clumsy it is. It has a
good idea -- the ability of users to create objects and add them to the
environment -- but it needs a much better algorithm for managing the
construction process and an object-oriented look-ahead synchronization
process that reduces the bottlenecks to something endurable.
rgb
--
Robert G. Brown Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977