[MUD-Dev] The Root of the Tree (was NEWS: Why Virtual Worlds ...)

[David Kennerly]

Raph Koster wrote:
> David Kennerly [mailto:kennerly at finegamedesign.com] wrote:
>> Raph Koster wrote:

>>> To me, the term "computer mediated community" has a very literal
>>> meaning and requires only "communication." Everything else you
>>> describe is emergent given the communications medium--we've seen
>>> most all of that list show up in IRC, for example.

>> I think that community includes trade, whereas communication (by
>> itself) does not.  But perhaps I'm injecting too much of my own
>> opinions into the common meaning of "community."

> Based on the dictionary definitions, I suspect most would agree
> with me that you are bringing more to it than the bare
> necessities, certainly. I think #1 (as regards locality) and #2
> (as regards shared interests) are the most likely touchstone for
> us as regards muds.

[Definition snipped]

Yes, you're right.

It is relevant that only one of these definitions of "community" is
for a non-physical community.  The definitions commonly cite members
who interact with each other.  Physical interaction implies, though,
more substantial interaction than /just/ communication, such as
talking or typing.  In a physical community, sex and violence cannot
go unmentioned.  In a computer-mediated community, I believe that
trade is a reasonable requirement to signify that substantial
interaction is occurring.  I don't devalue communication, but I
don't think communication alone indicates as much of a community as
more substantial interactions plus communication do.

>>> - a representation of space (the key factor that distinguishes
>>> text muds from other hypertextual systems)

>> One could order the systems along an axis: a text MUD has more
>> representation of space than hypertext does, but a graphical MUD
>> (usually) has a more consistent representation of space than a
>> text MUD does.  I'm not sure that a text MUD sufficiently
>> represents physical space, unless you mean that any undirected
>> graph suffices.

> No, muds have the peculiarity of being an undirected graph wherein
> a spatial metaphor is employed. I grant you that there is no
> technical reason why the spatial metaphor is present, in the more
> robust systems, but nonetheless, it is present and common to
> virtually all mud systems.

> Even in more flexible codebases than the Diku family, when exits
> are given arbitrary labels, they are almost always coded for users
> in terms of spatiality. "Inside the TV" to use a famous LambdaMOO
> example, is still recognizably a location.

I think we're crossing signals.  It sounds like you mean that the
users chat about location.  Whereas, I mean that the data structures
in a text MUD server do not adequately represent physical space.

There is, for example, no consistent use of a vector.  Granted,
graphic MUDs are not fully consistent either.  For examples: portals
in Asheron's Call or dreams in Furcadia.  These are examples of
non-spatial transportation.  These are, for all intents and
purposes, examples of "teleportation."  There is no relationship
between objects either side of the portal.  In a text MUD, every
room transferral in is isomorphic to such a teleportation.  Thus,
the room graph of a text MUD does not represent a vector space.
Sure, room-to-room portals, but for the most part deserts and broom
closets are both rooms in a text MUD.

>> I agree that there should be an organized and navigable place,
>> and that space suffices.  But I'm not certain that space is
>> necessary for a text MUD.

> It is not technically necessary, and yet I would argue that were
> you to connect to a text mud that did not employ a spatial
> metaphor (eg, the "rooms" were not "places"), you would most
> likely mistake it for a gopher server or perhaps browsing under
> lynx. In other words, the spatial metaphor is intrinsic to our
> understanding of what a mud IS even if the technical capabilities
> of the code do not enforce the restriction.

Again, it sounds like you mean users chatting about location,
whereas I mean locations existing with physically consistent spatial
relationships.

>> At least for text, the space is not necessarily analogous to
>> physical space. The text MUD is isomorphic to an undirected graph
>> whose vertices may possess varying degrees of connectivity.
>> These edges may result in an inconsistent spatial arrangement.  A
>> discrete representation of space, as a graph, would likely have a
>> consistent arrangement of edges between its vertices, such as in
>> a system of coordinates.

> I don't make any claims about this space being in any way
> Euclidean. The edges between vertices are by convention
> bidirectional, but many muds have been made with directed
> graphs. Many muds do not fit nicely onto graph paper because there
> are no assumptions made about scale.  Nonetheless, the spatial
> metaphor is employed.

Again, metaphors are what users talk about.  I mean the data
structures that represent space not in the user's head, but in the
server's computations.  Text MUD servers do not represent any kind
of vector space (Euclidean or not).  If you mean that the servers do
represent a space (besides the topological space, which is trivial,
since even hypertext and plain text are topological spaces), what
kind of space is it?

Well, I don't mean to disparage or contradict.  I am certainly not
an opposing advocate to the thesis that a designer should maintain
the illusion of space.  I agree with you about how users think about
their experiences in a text MUD.  They think of it as if there were
a space there--even though there's no adequate representation of
space in the text MUD's data or algorithms.

I guess users think as if there were space because all animal brains
are adapted to navigating physical environments.  Perhaps for this
reason users employ spatial metaphors.

Anyway, I'm sorry to side track us into a cul-de-sac of pointless
topics, but I'm happy to spot your thoughtful remarks along the way.

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