Spaces or rooms? (Re: [MUD-Dev] Information sharing (was: Re: Where are we now?))

Koster Koster
Thu May 10 21:15:27 CEST 2001


> -----Original Message-----
> From:Ola Fosheim Gr=F8stad
> Sent: Wednesday, May 09, 2001 1:56 PM
> To: mud-dev at kanga.nu
> Subject: Re: Spaces or rooms? (Re: [MUD-Dev] Information sharing =
> (was: Re:Where are we now?))

> "Koster, Raph" wrote:

>> Let me rephrase; "for game design purposes." There's been quite a
>> lot of academic analysis of the subject.

> I don't see why "academic" should be unsuitable for design.  It
> would be rather sad if that was the case... Maybe I got you wrong.

What I meant was that often the analysis doesn't provide an assessment
of the merit of each model specifically for game design purposes. It's
often a theoretical analysis, rather than a practical one.

>> I don't really understand the logical grouping of "non-spatial" and
>> "generated"--they don't seem to have anything to do with one
>> another.

> ?

> Think of something resembling shoot'em ups like Galaxy or whatever,
> but less linear. They are spatial on screen, but not structured as
> such.  Think of it as "spawn space" or "generator space" maybe. You
> may say that the player is in the same room all the time but the
> room itself is going through some kind of metamorphosis.

OK--that seems like a very specific case, rather than a class of
spatial structure. It's certainly a very interesting case--I've been
toying with the notion of a storytelling multiplayer game that uses
exactly that spatial model, actually.

>> For that matter, I defined online worlds as using a spatial
>> metaphor, so non-spatial in my terminology doesn't even exist. :)

> Missed that... (Not sure if current designs are experienced as
> strictly spatial, with teleports, zones, chat channels,
> inconsistencies and all, maps help I guess.)

Zones are usually set in spatial relationship to one another. Chat
channels, teleports, inconsistencies, etc, players seem to relate to
as being layered on top of the basic spatial metaphor. We do speak of
chat rooms, but channel is really a more proper term given the absence
of a spatial metaphor. My definition of online worlds does leave out
stuff like IRC for that reason; the presence of the spatial metaphor,
of the sense of *place*, is to my mind sui generis.

>> Methods of culling what is displayed seemed to be distinct from the
>> map structure; in the case of a room-based system the cull
>> mechanism and the map structure happen to be coincident, but in a
>> continuous map structure is is not the case. And when you get into
>> continuous maps embedded in rooms, or vice versa, attaching
>> significance to the method of culling starts getting
>> silly. Consider that in a 3d environment, there's actually two
>> kinds of culling going on--network traffic, which is NOT culled to
>> the "room" created by the view frustrum; and visual culling, which
>> is.  Anyway, I don't see thinking of that as a room as being very
>> fruitful.

> Perhaps because you don't strictly focus on what is experienced.

Correct; the terms I am using are all very much server-centric, not
client-centric. There's a whole other ball of wax involved in analysis
of modes of representation, certainly.

> There are all kinds of possible designstructures and
> implementations, thus I'd argue that if you're going to build a
> vocabulary for design it is a good idea to focus on what is
> experienced.

The thing is that the client can't really subvert whatever structure
the server uses. Therefore the server's structure largely defines what
the client representation can be. In addition, i am focusing ont he
design of online worlds, not on the design of clients to access them;
one can have many different client implementations for a single world
design, and the output is manifestly shaped by the world's design. The
reverse is not true; change servers and the game changes
completely. Change clients, and the game may change in its output,
which may affect the experience, but the game remains unchanged. Rules
remain intact, physics and logic intact, etc.

This is not to say that you can entirely divorce client and server;
but it does seem to me that server is where the world is.

> I somehow doubt that most players really experience the map. What
> hits their screen matters, I think? Then again, maybe designers
> prefer to talk about what is implemented.

Hurm, my sense is that players have an overwhelming sense of place,
that place is intrinsic to muds. That's why I felt that codifying the
ways in which we represented it was worthwhile. Whether they
experience the continuous map via text, overhead tile graphics, full
3d 1st person, or whatever, feels irrelevant at the level that I was
talking; the issues with continuous maps still apply regardless of
interface.

> In Alphaworld the sliding window has, in my opinion, a serious
> impact on how the world is experienced. It is very apparent that you
> are staying inside some kind of magic bubble. And because there is
> user building it has not been minimized through design
> either... Various types of "rooms/viewpoints" provide different
> degrees of freedom and control. Yep, I think it is fruitful.  I
> don't expect you to agree, but that's ok too!

> In fact, when I tried to figure out "what a room is" it turned out
> to be incredibly complex, provides all kinds of functionality and
> come in all kinds of shapes when you just open up for the idea.
> Designers should think about such issues, I think. Then we would see
> novel designs...  Maybe.

I'm certainly not minimizing the importance of the interface. But
Alphaworld is still a continuous map system. ;)

>> On the spheres... I am not entirely sure what you are defining.

> Just an abstraction of room.  Sloppy: "set of objects which are
> somehow perceived as related/close and may have a high degree of
> interaction and sense each other"

*nod* A useful abstraction.

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



More information about the mud-dev-archive mailing list