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

Eric Random e_random at yahoo.com
Mon Jan 17 05:32:56 CET 2005


--- Ola Fosheim Grøstad <olag at ifi.uio.no> wrote:

> I want a set of terms that:

>   1. doesn't cause extra inter-disciplinary confusion

There is little inter-disciplinary confusion over the term "virtual
world". It is rather well-known as a general classifier, much like
the term "quantum physics". This argument is rather like arguing the
term "quantum physics" is particularly inefficient, in that it
effectively does not communicate that one may be solving
PT-Symmetric periodic potentials using Hill's Equation rather than
deriving an entanglement monotone from Grover's
algorithm. Certainly, there may be question as to what particular
type of virtual world is under discussion, but one must begin
somewhere. What is more interesting is the particular
characteristics of the virtual world(s) in question. For MUD-DEV,
though, as you have stated, we can continue to be particularly
focused.

>   2. includes a set of phenomena for which we can build a body of
>   knowledge about design, and exlude others

Ie. the set of defining characteristics. I, too, am interested in an
ever widening list of discussed characteristics in MUD-DEV.

>   3. makes it possible to discriminate between related systems

Yet, still more characteristics which differentiate typologies. I
see we agree.

>   4. which doesn't make to many assumptions about what is possible
>   based on the existing (I am not looking for a name for a genre)

> Testing the definitions against examples is of course necessary,
> but I am not so sure if deriving the definitions from examples is
> a good thing. In relation to design it would be a rather horrible
> idea. We want to know how to design new systems, right?

Since when does knowledge of existing systems limit the creation of
new ones? I would certainly agree one should not limit their
creativity to only that which has already been created. Clearly a
set of characteristics would not be assumed to be immutable. I'm
discussing taxonomy, not design documents. One would need several
design documents to generate a taxonomy, and be able to create
design templates from existing subsets of the taxonomy.

> My impression is that most that use the term "virtual worlds" for
> MMOs try to capture a genre, not a class based on
> characteristics. If you start with a set of examples you want to
> include... then you are most likely looking at a genre. Which of
> course is not defined by characteristics, but by a shared cultural
> understanding.

A genre is defined by characteristics, and is a form of
classification.  I find "virtual world" in our context more of a
medium than a genre, though. Genres are normally determined on more
internal qualitative characteristics of style, form, and
content. Virtual worlds can be mediums in which those exist. Given
that, worldy characteristics applied to a game, can make the term
"virtual world" a genre since such worldy characteristics can be
construed as style, form, and content within the classifier
"computer game" or "massive multiplayer online game".

>> As an example of classifying elements like MUD's, I refer you to
>> the 1997 paper by Manninen and Pirkola entitled "Comparative
>> Classification of Multi-User Virtual Worlds" which can be found
>> at http://citeseer.ist.psu.edu/487604.html.

> It isn't very helpful is it? "ideal worlds" related to interfacing
> technology? The ideal interface? Huh?

On the contrary, it is certainly a worthy model of study. Virtual
worlds are analyzed and assessed on a number of items in the
following categories: scalability, avatar features, realism, user
interface, and communication. Althought the terminology may be
lacking, the scope of the categorization is less so. This paper was
written 8 years ago, and these categories and items are surprisingly
relevant. Simply browsing the competence matrix of surveyed worlds
one can sort our daily MUD-DEV conversations right into them. It's
definately worth reviewing when considering a starting point.

> Because they are designed by a committee? You are likely to end up
> with something overly broad and fuzzy...

The function of such a committee is to discuss, update, manage,
maintain, and provide a binding authority for central
interaction. This could be contained within the confines of MUD-Dev,
and need be neither rigid nor broad. It simply provides a forum with
form and process on exactly what we are talking about.

>> One further aspect of classification is applied beyond simple
>> characteristics, but includes the common challenges faced by
>> developers of such concepts. Although particular implementations,
>> ie. attributes, may be different, the challenges which resulted
>> in such different implementations may be the same.

> I don't see how this is different. You cannot have a
> classification without a perspective. If you don't make the
> perspective clear first then the classification is some arbitrary
> partioning of the space (at best).

> The perspective might be use, design, technology, etc...

This is not a classification without a perspective. I don't quite
even see how one could have a classification without a perspective,
so in some sense, I agree with you. It doesn't seem different
because it isn't. It still uses characteristics and classification,
it just alters the ordering. For example, although two battle
systems may be different, they may share common challenges of
development. It is these challenges which most aid the design
process, and not necessarily, the particular implementations.
Understanding such challenges may result in new implementations.
Those other implementations need to be there, though, to be
understood, or improved, or dead-ended. Such knowledge could serve
the next designer by avoiding pitfalls or improving on success.
Ultimately, I think that's what your getting at as well (ie.  design
perspective).

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



More information about the mud-dev-archive mailing list