cyberoid@milton.u.washington.edu (Robert Jacobson) (11/23/90)
Bernie Roehl, in a discussion of MUDs, has raised the very significant issue: How do we categorize virtual worlds? This issue has been raised in many fora -- here, on The WELL, at conferences innumerable, and in private discussions. Has anyone thoughts along the lines of how we might create a typology, based on the topology, of virtual worlds? This typology might include everything from the static "world" of the written page to the ultra- dynamic, interactive virtual worlds that we more often speak about here. With your permission, I would like to archive these ideas for possible inclusion in an invited proposal for a conference possibly to be sponsored by the U.S. National Science Foundation on the science of virtual worlds. Thanks. Bob Jacobson Moderator (You can also reply to me at cyberoid@milton.u.washington.edu if you prefer not to have your thoughts become public. However, I encourage public postings.)
Pezely@udel.edu (Cowboy Dan) (11/25/90)
cyberoid@milton.u.washington.edu (Robert Jacobson) writes: > >Has anyone thoughts along the lines of how we might create a typology, >based on the topology, of virtual worlds? This typology might include >everything from the static "world" of the written page to the ultra- >dynamic, interactive virtual worlds that we more often speak about >here. Looking at this issue before, we developed a Detail Level which provides a mechanism for allowing low-end cyberspace decks to be almost as functional, even if not as efficient, as the high-end ones when connecting to a world. This detail level does not have to be limited just to the graphical messages but can also be used for trimming bandwidth for dial-up connections, long distance transmissions, etc. So, with this, even the text based MUDs can be seen as a virtual world with very simple i/o. All that the current MUDs would need to connect to our systems would be a translator for the `go west' (or whatever; it's been a while since I've been in the mud) commands to the VEOS protocol for changing position or location. -Cowboy Dan <Pezely@udel.edu>
broehl@watserv1.waterloo.edu (Bernie Roehl) (11/25/90)
In article <11583@milton.u.washington.edu> cyberoid@milton.u.washington.edu (Rob ert Jacobson) writes: >Bernie Roehl, in a discussion of MUDs, has raised the very significant >issue: How do we categorize virtual worlds? Since I was the one who opened this particular can of worms, let me be the first to pull one out. I would suggest that we view all the various possible types of virtual worlds as coexisting in a kind of "multiverse". The different types are not connected, because they have different representations (different "laws" govern them, if you will). >Has anyone thoughts along the lines of how we might create a typology, >based on the topology, of virtual worlds? The typology might be based not so much on *topology* as on the representation scheme used (since that is what restricts a particular abstract "thing" to a particular type of VR). A character from a novel would not necessarily be found wandering around a Cyberspace building. (Or rather, if they *were* found there it would be a character with many similar attributes to, but disconnected from, the text version (i.e. changes to one don't affect the other)). >This typology might include >everything from the static "world" of the written page to the ultra- >dynamic, interactive virtual worlds that we more often speak about >here. I strongly feel that a VR must be interactive. To me, a book is not (strictly speaking) a VR, nor is television. Neither is a film or a recording. It should also be possible for multiple people to share in the virtual reality. (This does not mean that VRs must *always* be occupied by more than one person, but rather that the capability must be there). Beyond that, I believe a true VR should be malleable, in the sense that it changes over time as a result of the actions of people interacting with it. (Simply being able to fast-forward over commercials on a VCR does not make videotapes an example of VR, even though the user is interacting with it). Aside from that, very few restrictions apply. Furthermore, the list of attributes that characterize a VR is large and extensible. Let's consider two possible attributes... The virtual world that we're sharing right now (i.e. the one in which this discussion is taking place) is characterized by being text-based and non-synchronous (i.e. people post at random times in a random sequence, and the order of arrival of articles can vary from site to site). Internet Relay Chat is text-based but synchronous. A telephone "party line" is speech-based and synchronous. The particular flavor of VR that we often discuss in this newsgroup is visual and synchronous. MUDs are text-based and synchronous/asynchronous (i.e. people can interact in "real time", but can also leave each other virtual notes and in other ways modify the virtual environment in a way that affects other people at a later point in time). And so on. This is a first cut at a typology, and it's late and I'm tired, but I hope it provides a jumping-off point for discussion... -- Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl Voice: (519) 885-1211 x 2607 [work]
jwtlai@watcgl.waterloo.edu (Jim W Lai) (11/25/90)
In article <1990Nov25.040525.22232@watserv1.waterloo.edu> broehl@watserv1.waterloo.edu (Bernie Roehl) writes: >The virtual world that we're sharing right now (i.e. the one in which >this discussion is taking place) is characterized by being text-based >and non-synchronous (i.e. people post at random times in a random >sequence, and the order of arrival of articles can vary from site to >site). I prefer the term "asynchronous" to "non-synchronous". > >The particular flavor of VR that we often discuss in this newsgroup is >visual and synchronous. > >MUDs are text-based and synchronous/asynchronous (i.e. people can interact >in "real time", but can also leave each other virtual notes and in other >ways modify the virtual environment in a way that affects other people at >a later point in time). I propose the attributes of "persistence" and "transience". A VR is persistent is it has a "history" that can be accessed from within the VR. Usenet news and MUDs are persistent, but IRC and party-lines are transient. One can add noninteractive, asynchronous persistence to IRC and party-lines by means of text-logging and tape-recorders.
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/26/90)
To expand a bit upon a prior posting, one dimension along which to characterize a virtual world is mallability. I see three easy to identify cases: 1) The VR is user-immutable. The user moves through it as a ghost, walking through open doors only, sitting in chairs but not moving them, experiencing the VR but not manipulating it. This might be a suitable way to access an extremely fancy canned database. 2) The VR is user-mutable. The user moves through it opening doors, and they stay open, rearranging the furniture, and it stays put for the next access. 3) The VR is user-configurable. The user moves through it adding doors or designing furniture, and they are there for the next access. In game terms, 1) may be compared to solving a maze, 2) to playing rogue or a nethack without the bones files, and 3) to a user-configurable MUD. In addition, for shared VRs, one may partition between 1) VRs that exist as a separate reality with its own state space for each user, even though the data base on which the VR is first experienced may be common. 2) VRs that communicate changes to other users in a shared reality, by passing a modified state space after a session. 3) VRs that communicate changes to other users interactively by sharing changes to the state space in "real time". In game terms, 1) is Pacman, 2) is nethack's bones level, or a MUD design session change, and 3) is a MUD being played or a mazewar session. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
brucec%phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen;;50-662;LP=A;) (11/27/90)
In article <11583@milton.u.washington.edu> cyberoid@milton.u.washington.edu (Rob ert Jacobson) writes: > > Has anyone thoughts along the lines of how we might create a typology, > based on the topology, of virtual worlds? This typology might include > everything from the static "world" of the written page to the ultra- > dynamic, interactive virtual worlds that we more often speak about > here. There are several categorizations of virtual worlds which ought to be explored: 1) The quality of the interface: the typology which Bob Jackson refers to in the above posting. I can think of a number of axes you could use to distinguish interfaces: a) single vs. multiple users b) static vs. user-modifiable environments (can I pick up that wrench, and if I put it in the next room, will I find it there the next time I enter this world?) c) sensory modalities: a) visual - submodalities include color, stereo, coverage of field-of-vision, etc. b) auditory - submodalities include directionality, control of "presence" (reverb, differential attenuation of echoes, etc.) c) haptic (touch, temperature, texture) d) olfactory (anybody remember Smell-o-Vision?) e) kinesthetic (force-feedback, externally-imposed accelerations and orientations wrt gravity d) similarity to the "Real World" (lots of dimensions here!) It might be simplest to constrain this categorization to deal only with the question of fidelity, and open up the variations-of-reality worm-can separately. e) how are symbolic objects handled? (voice ouput, letters of fire in the air, etc.) Come to think of it that's a great idea for the system icon: a burning bush :-). 2) The application to which the interface is put. This will determine some of the requirements for the interface design, e.g., if you are limited to maintaining a known database, you'll need a less open (extensible, flexible, etc.) interface than if you are exploring databases whose format and content is initially unknown to you. Some application areas: a) games and interactive fiction b) database manipulation and maintenance c) database exploration d) data analysis and visualization (also process and system simulation) e) total system user interface (the Virtual WorkPlace (tm) :-)) f) teleoperation g) operator-training simulation h) "walk-throughs" 3) The extent to which the system is distributed geographically across host computers, sub-databases, etc. This categorization raises interesting design requirement and implementation questions like synchronization, interface latency, background processing, and replication of objects. > With your permission, I would like to archive these ideas for possible > inclusion in an invited proposal for a conference possibly to be > sponsored by the U.S. National Science Foundation on the science of > virtual worlds. > Permission gladly granted. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077
ksand@Apple.COM (Kent Sandvik) (11/27/90)
In article <11673@milton.u.washington.edu> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >3) The VR is user-configurable. The user moves through it adding doors >or designing furniture, and they are there for the next access. Which leads to design ideas such as aliases and macros in order to configure one's paths. Eventually a lot of the abstractions used in normal user interface design could be implemented as part of the VR navigation. The question is that is this user-friendly for the common VR user, with the exception of VR hackers? The general rule with plain 2 or 3-dimensional interface design is to imitate the real life. With VR the designer has the temptation to break all rules, good or bad. Eventually one strategy is to map everything from the non-virtual life 1:1, and the only addition is the speed of time, which could be controlled. I.e if the user wants to travel from VR point A to VR point B, he/she takes a bicycle, but the distance travelled seems to be short due to an increase in the TIMESPEED variable (selectable from the bicycle handle....). Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND Zippy says: "With C++ we now do have the possibilities to inherit dangling pointer problems"
erich@eecs.cs.pdx.edu (Erich Stefan Boleyn) (11/27/90)
Tossing in my $0.02... broehl@watserv1.waterloo.edu (Bernie Roehl) writes: >I would suggest that we view all the various possible types of virtual >worlds as coexisting in a kind of "multiverse". The different types are >not connected, because they have different representations (different >"laws" govern them, if you will). I assume this would allow for user definable representation methodologies that can interact with each other, perhaps even allowing for transferring (or not, as the user wishes) the representation of something with it to another user's environment. Different users would be more efficient working in perhaps completely different methodologies. >It should also be possible for multiple people to share >in the virtual reality. (This does not mean that VRs must *always* be >occupied by more than one person, but rather that the capability must be >there). This would be not unlike the idea of how we each have an internal model that corresponds in some manner to the world around us, yet they all map somewhat differently. The allowance would be for a *big* differece, though. >Beyond that, I believe a true VR should be malleable, in the sense >that it changes over time as a result of the actions of people interacting >with it... Changing the underlying data, of course (?). Erich "I haven't lost my mind; I know exactly where it is." / -- Erich Stefan Boleyn -- \ --=> *Mad Genius wanna-be* <=-- { Honorary Grad. Student (Math) }--> Internet E-mail: <erich@cs.pdx.edu> \ Portland State University / >%WARNING: INTERESTED AND EXCITABLE%<
ksand@Apple.COM (Kent Sandvik) (11/28/90)
In article <11743@milton.u.washington.edu> Pezely@udel.edu (Cowboy Dan) writes: >So, with this, even the text based MUDs can be seen as a virtual world >with very simple i/o. All that the current MUDs would need to connect >to our systems would be a translator for the `go west' (or whatever; >it's been a while since I've been in the mud) commands to the VEOS >protocol for changing position or location. I hope there's a general interest to define a common interface that a cyberdeck could make use of with the low i/o MUD systems that appear on the NET today. This would mean that there would be a nice evolution of cyberspace nodes. All we need is a concensus to create a defined text interface where 'go west' means go west. If not, one needs a knowledge interpreteter that tries to figure out all the needed/ working commands. I don't see any real problems to hack together the first 3D MUD cyberdecks, as long as the MUD databases would have a common set of commands - sort of VRSQL. Please keep ANSI away from this standardization effort, it would take 20 years to write the first alpha draft :-). regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND Zippy says: "With C++ we now do have the possibilities to inherit dangling pointer problems"
broehl@watserv1.waterloo.edu (Bernie Roehl) (11/30/90)
In article <11645@milton.u.washington.edu> jwtlai@watcgl.waterloo.edu (Jim W Lai ) writes: >I prefer the term "asynchronous" to "non-synchronous". So do I, but I was concerned people might confuse the medium with the mode (i.e. "asynchronous" communications lines). Actually, I'd like to avoid this "overloading of operators" and find a better pair of words that 'synchronous' and 'asynchronous'. Ideas? >I propose the attributes of "persistence" and "transience". A VR is >persistent is it has a "history" that can be accessed from within the VR. >Usenet news and MUDs are persistent, but IRC and party-lines are transient. Sounds very good to me. -- Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl Voice: (519) 885-1211 x 2607 [work]
jwtlai@watcgl.waterloo.edu (Jim W Lai) (11/30/90)
In article <1990Nov29.162751.6048@watserv1.waterloo.edu> broehl@watserv1.waterloo.edu (Bernie Roehl) writes: >In article <11645@milton.u.washington.edu> jwtlai@watcgl.waterloo.edu >(Jim W Lai) writes: >>I prefer the term "asynchronous" to "non-synchronous". > >So do I, but I was concerned people might confuse the medium with the mode >(i.e. "asynchronous" communications lines). Actually, I'd like to avoid >this "overloading of operators" and find a better pair of words that >'synchronous' and 'asynchronous'. Ideas? More intuitive VRs associate each event/interaction with a time based on when they were generated. Netnews based such events (articles) are associated with a time based on reception, which is not necessarily consistent with time of generation. How about time-consistent and time-inconsistent?
PLai@cup.portal.com (12/02/90)
Bob Jacobson says: >Has anyone thoughts along the lines of how we might create a typology, >based on the topology, of virtual worlds? This typology might include >everything from the static "world" of the written page to the ultra- >dynamic, interactive virtual worlds that we more often speak about >here. Well there is a problem that I have been workin on that is close to this: Lets say you have an ai that is reading the interactions of a group of people going through a text base MUG(multi-user game). This ai is suppose to simimulate NPC's (non-player characters) and needs to be smart enough to know what is in a room to interact with the PC's ( human player characters) in a way that it, the ai, appears like a human. The problem is how does the ai generate a local (local to the ai's mind) spatial database from reading the text? There are trivial ways of hard coding this kind of thing, but in order to do it in a general way, the ai needs to slowly generate relational connections between objects and chunked objects. Thus the cyberspace generated by the ai is a computational mapping of how objects are related in space, and associated textually. A few general principles stand out: 1. That the objects have only a spatial meaning in terms of other objects - i.e. a thumb is a inch away from the palm 2. Objects are spatially related by transforms, not through coordinate references. 3. Objects are chunked into groups at varying levels, each group able to have spatial transforms to other groups. 4. The layout and design of the cyberspace is done for benefit of the ai, for the human to see the ai's spatial reasoning requires another layer of logic. PLai
brucec%phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen;;50-662;LP=A;) (12/04/90)
In article <12157@milton.u.washington.edu> PLai@cup.portal.com writes: >... Thus the cyberspace > generated by the ai is a computational mapping of how objects are related > in space, and associated textually. A few general principles stand out: > > 1. That the objects have only a spatial meaning in terms of other > objects - i.e. a thumb is a inch away from the palm > 2. Objects are spatially related by transforms, not through coordinate > references. > 3. Objects are chunked into groups at varying levels, each group able > to have spatial transforms to other groups. Umm ... I'd be careful about making coordinate transformations your primary relationship. That's the way it's done in mechanical CAD and related fields, and I can tell you from bitter personal experience that it is very difficult to get data structures designed to handle coordinates to deal with things like forces applied to a moving linkage, or constraints propagating back through a a set of connections. A good example of this problem is animating a human or animal body: you want to describe the body based on the skeleton and its joints, and control the way it interacts with the body so that its feet don't go through the floor when it walks. It's almost impossible to get realistic motion without addressing these issues. The software used for this sort of animation is quite different from that used to simply move a hierarchicly-related group of spatial transforms around. > 4. The layout and design of the cyberspace is done for benefit of the ai, > for the human to see the ai's spatial reasoning requires another layer > of logic. Yes, that's clear, but I suspect that you will want to include that extra level, if only for testing. The case is similar to that of expert systems, where the designer often builds in an explanation facility even of the user will not be using it, just so that the designer can convince herself that the ai understands the test environment in the expected way. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077