[MUD-Dev] NEWS: Why Virtual Worlds are Designed By Newbies - No, Really (By R. Bartle)

[Morris Cox]

On Sat, 27 Nov 2004 10:33:47 -0800, J C Lawrence <claw at kanga.nu> wrote:
> On Fri, 26 Nov 2004 09:25:48 -0700
> Morris Cox <morriscox at gmail.com> wrote:

>> What if games were interconnected in a way (via some standard
>> that used XML and compression, for example)...

> cf InterMUD

I3? That's pretty much for chat, finger, and mail between
participating MUDs. I'm going more for being able to transfer
characters between. I would prefer real-time (or close to it), but
even a delay of a few hours or (longer) might be doable if described
as "traveling the long distances between realms".

>> that allowed players to travel among them?

> cf UberMUD portals and NWN.

I've heard the term UverMUD before, but never played any. Are you
referring to the original NWN? Never played that one (the original)
either.

> I love the idea, always have, but I doubt we'll ever see much
> support for it.  From a marketing perspective this creates
> problems.  First up it becomes far more difficult to create value
> differentiation when you're operating merely a node in a mesh, and
> that's exacerbated by the ease with which any value you do create
> will be aped and copied by surrounding nodes attempting their own
> value grab.  These factors in turn make establishing any sort of
> identity, let alone a recognisable brand even more difficult.
> And, worse, both these problems would seem to apply equally to
> both the $FREE and commercial services.  The $Free services have
> the exact problems above, and the commercials are forced to
> attempt to curtail and constrain the problem through tight
> partnership agreements -- but that only works while those services
> are the underdogs.  As soon as one becomes particularly successful
> the partnership contract becomes more of a drain and a burden than
> a benefit to them.

With very different themes it might be possible. Or themes that
compliment, not compete. I did think of mutual agreements, but
you're right on that. Maybe contracts for a limited amount of time?
And having a standard for moving game items/characters between games
doesn't necessarily mean that games need to know how the other games
do things. I did envision the game data being stored as nodes on the
item or character (useful if they are completely independent of the
game) with different 'facets' being available depending on criteria.
However, there are other possibilities.

As an aside, something like this could be used for virtual malls or
simulations of cities and towns.  Not game related, I know. It's
that this technology has so many potential uses that are not being
used.

> Getting object portability right among competing and frequently
> unfriendly systems without fundamentally breaking those systems is
> Very Hard (tm).  There have been numerous attempts ranging from
> the simple callback schema in CoolMUD on up to full object
> brokering implementations.  The only success has been in migration
> among tightly bound systems.  The problem: what prevents the
> world-breaking objects being imported?  Logically inconsistent
> systems are, well, just that, and even more especially when
> neither side can trust the other.

Good points. As I recall, this is one of the reasons that XML came
about. For this to work, the objects must be totally independent of
whatever game they're in or it doesn't matter if a schema gets
changed (that is, changing or updating a schema doesn't break the
system). The thing with XML systems is that the server (or client)
can choose to display content that's loosely bound to the
data. Seperation of content and presentation. An object can change
its look and feel and still be the same object inside. A lightsaber
can become a magical sword and still possess the ability to become a
lightsaber again.

--
Morris Cox
http://www.legran.com/sitereview
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev