The Universal Avatars Specification
Working Draft #2
Pre-release Revision 1-23-97
by
Moses Ma, iGame, Inc - moses@i-game.com
Dan Greening, Chaco Communications, Inc. - greening@chaco.com
Abbott Brush, IBM, Inc. - brush@vnet.ibm.com
Maclen Marvit, Worlds, Inc. - maclen@worlds.net
INTRODUCTION
Until now, avatars have been system and browser dependent, which meant that an avatar created for one virtual world wasn't necessarily compatible with other worlds. This specification, called Universal Avatars, proposes a way to standardize what avatars are and do. This new standard is an extension of VRML 2.0, and is intended to bring consistency and continuity to the world of virtual world exploration.
By using this proposed standard, avatars will be able to move from one world to another, keeping the same appearance and behavior. This means that users will be able to recognize other users' avatars that they met in other worlds. And their avatars will have individualized automatic actions, moods, and even pets. And they'll be able to tell how their friends, from around the world, are feeling today, just by the look on their avatar's faces.
Furthermore, users will be able to give their avatars personalities, hobbies, and interests. As a result, other users could search for people with similar interests, through an open, yet secure, system using standard Internet search engines. Plan a party for poetry lovers and invite people who like to chat in rhymes. Host a chat session for people interested in anime, orchid gardening or paleomagnetism, and you can meet like-minded individuals who are interested in these pursuits. All of could be possible because Universal Avatars is proposed as a standard across all systems and MUDs, intended to transcend the limitations of proprietary platforms and environments.
The initial goal of this proposal was to create an extension to the emerging VRML standard that would deal with the issue of standardizing avatar (graphical user representations) descriptions within 3D multi-user simulations. However, through the process of open dialogue between members of the industry through the Universal Avatars mailing list, it has become apparent that the Universal Avatars Specification can and should be about much, much more. Thus, this latest draft of our proposal now deals with a variety of issues, which begin with 3D models and behaviors, but now ventures forth to discuss other important issues, such as persistent identity, interworld communications, database concerns, and support for additional emerging standards such T-120, H-323 and Versit. We believe that this is an early basis for an emerging "operating system" for socialization.
Also, this draft will deal with a number of new issues and refinements of concepts introduced in the earlier draft, that include, for example, a proposed methodology for dealing with transitive behaviors, a proposal for managing issues of size and scale, proposals for handling authentication services, the inclusion of standardized 2D representations, and preferences for spoken language and navigation preferences.
Clearly, it would be useful to have a standardized avatar representation for the purpose of visiting all virtual worlds with a user's preferred avatar representation and openly tendered identity profile. This has many benefits, including the reduction of the workload on the user, the standardization of global search for other people through their public avatar presentation, and the ability to create new business opportunities for VR vendors. Thus, the Universal Avatar system could have a significant impact on the deployment, usage, and revenue generation possibilities of VR (Virtual Reality) space over the Internet.
We must keep in mind the categorical goal of cyberspace - which is to create a seamless distributed multi-user virtual experience. Any user, any browser, any server, anytime and anywhere. So how do we bring a compelling implementation of cyberspace to the broadest audience, helping people create business, entertainment, and social environments on the Internet? VRML has brought us closer to this dream, but does not help us build the complete bridge to persistent immersive multi-user social experiences of dramatic impact and consequence. To create the complete cyberspace vision, where a virtual experience has meaning, we must specify vital underlying open database protocols. This proposal addresses this requirement.
Complementary Efforts
A number of related, complementary standards efforts are currently underway. These include VRML, Open Community, Living Worlds, Java, as well as a number of security (Verisign, SET, etc.) and communication efforts (H-323, T-120, etc.).
For a complete discussion of these efforts, the reader is directed to view their on-line specifications. The following is a quick summary of these efforts and how they might work with Universal Avatars.
VRML 2.0 is a single-user animated 3D virtual environment specification, which can associate automated behaviors (such as a door opening when a user clicks on the doorknob) with a 3D object. This is sometimes referred to as "intransitive behaviors." Through a programming API, VRML 2.0 allows content developers to create cool animated environments.
Java is an object-oriented programming language supported by all major web browsers, and is clearly the emerging lingua franca of the Internet. It is currently used to add life to static web pages. However, through any of a number of proposed Java interfaces for VRML 2.0 viewers, Java can drive complex behaviors, communicate with server, and animate avatars.
Living Worlds is a proposed specification for multi-user virtual worlds. It builds on VRML 2.0 with a combination of standard and proprietary APIs. The portable VRML API of Living Worlds represents passive behaviors, and the unspecified proprietary APIs support interacting behaviors. A content developer can rely on Living Worlds to support interacting behaviors, but must build or license a proprietary multi-user API and server.
Open Community builds on a wealth of prior work, including VRML 2.0, Java, and Spline, a multi-user system developed by Mitsubishi Electric. The Open Community interface allows content developers to create fully portable, interconnected, multi-user interactive worlds which operate on any manufacturer's Open Community server. Since the Open Community API is completely open, content developers can choose servers based on added value-such as speed, robustness, standard compliance, and additional features
The spAvatarInfo and spAvatar classes in Open Community were designed to implement Universal Avatars concepts. Open Community will continue to reflect the needs of the avatar community, since it is closely aligned with the Universal Avatars initiative.
These different APIs - from VRML 2.0 to Living Worlds to Open Community - move us toward a seamless multi-user cyberspace on the Internet. However, none of these deal with the crucial issues like persistent identity. We need the ability for to navigate from world to world, running on a variety of servers and browsers, with the kind of seamless continuity that the World Wide Web currently allows. To succeed in this very ambitious goal, a convergence of various specifications for open networking between users, servers and client applications must be achieved. We believe that is possible through the convergence of these related efforts with Universal Avatars.
THE THINGS YOU'LL BE ABLE TO DO
Examples
The power of Universal Avatars can best be described by considering the following three examples, which are scenarios made possible through the use of Universal Avatars.
An Evening at Home
1. Moses is at home in his VRML living space. His house was designed by a famous virtual architect, his avatar was created using the Avatars 'R Us construction kit. He was able to easily purchase both products on-line, because his Universal Avatar had embedded financial transaction capabilities.
2. There is a knock at the door: Dan and Nina have come by for a visit. When the knock is delivered, Moses' client application prefetches the necessary 3D models for his visitor's avatars, so they are in memory when Moses opens the door and greets them. Even though Moses has never met Nina, much less her customized avatar, this data is available because their software vendors supported the Universal Avatars standard.
3. Moses shakes hands with Dan. To create compelling immersive virtual experiences, users and their avatars should be able to interact and have an impact on each other. They should be able to shake hands; one user should be able to tickle the other and see an automatic giggle; one user should be able to kick the other, and see the other begin to limp. This is all contained within a hierarchical object model that allows for new behaviors to be loaded dynamically, and concomitant responses located or generated to provide the best fit. This enables more compelling interactivity than simple chat.
4. Trust is interactive and commutative. After Nina and Moses are introduced by Dan, they can automatically exchange authentication keys and Universal Avatar ID's when they shake hands, simplifying the security process.
5. A intelligent virtual conversation ensues. Since the system allows for a variety of delay-mitigation strategies, a delay mitigated virtual conversation between the three could be performed. When Nina talks, even though Dan and Moses won't hear the digitized voice for half a second and be able to respond for three seconds, both of their avatars can lean forward and provide visual back-channel encouragement for Nina's communication, to provide a seamless virtual conversation.
6. They are able to exchange gifts. When Nina leaves, Moses presents her with one of his prized digital paintings that she admires, which is digitally signed and provided within a cryptolope. She, in turn, transfers to him her intelligent virtual pet cat to lounge around the house.
7. The gifts contain agents. The next day, Moses decides to call on Nina, and only has to right-button click on the virtual cat to ask it to take him to Nina. The virtual cat agent will then query the location server (an Open Community feature which allows agents to interact with 3D database in such a manner) and finds that Nina is at a virtual art gallery, getting the digitally signed painting appraised. The cat can automatically take Moses to wherever Nina is, at that moment, because the underlying architectures are intrinsically agent-enabled.
At a Virtual Mall
1. Abbott goes to Bernie's Discount Sportswear Virtual Mall. As he enters, his avatar server dispatches mobile agents to the various vendors listed on the mall's name-server, and announces to all the vendors "My master is entering this mall, and is willing to listen to two sales pitches, for a price of at least fifteen cents." Then the agent provides Abbott's purchasing history and buyer preferences without actually disclosing who Abbott is (thus spam proofing Abbott's email address). It then cheerfully provides his VAL (values, attitudes, and lifestyles) status to the qualifying vendors, with the fact that he purchased four pairs of basketball shoes in the last several months. People with more active VRML mall purchasing histories will obviously appeal more to vendors.
2. The advertisers and retailers like these kinds of one-to-one marketing models. The vendors in this virtual mall inspect the purchasing profile, and make bids for Abbott's attention with readership fees or discounts. A shoe store and an athletic supply company will pay 55 cents each for his time, and as Abbott walks around the mall, he is greeted by authorized bots (virtual robots) that invite him into their stores. This cuts down on the proliferation of unauthorized adbots hunting for unsuspecting customers. When Abbott enters the shoe store, the promotion counters are lined with appealing items at price points that would be most enticing to Abbott.
3. The payment system is entirely automated because of his Universal Avatar. If Joe makes a transaction, the vendor can query his avatar file for the payment systems supported by his digital wallet. Joe selects his preferred system, assisted by his personal financial agent who maintains the balance on his cards. The transaction completes transparently.
4. Everybody wins. A small commission generated for each direct marketing transaction is split between the avatar company and the virtual mall operator, and increases the profitability of operating virtual worlds. Virtual world operators must start thinking about revenue generation models, and this is a very strong model for future deployment.
At a Cyberspace Amusement Park
1. Maclen and Kate want to meet at Viacom/Paramount virtual arcade. When they arrive, they decide to play the Star Trek immersive game, which Maclen has played several times.
2. They enter the transporter and select the Borg encounter scenario, which Maclen has never played. In this scenario, Star Trek is not just a single game, but rather, a platform supported by a variety of game developers. The transporter or holodeck can load any one of a dozen scenarios written by different developers. However, since Maclen's Universal Avatar file contains portable profile information, the various vendors know his interface preferences and level of expertise from his other experiences, and can fit the difficulty level to provide maximal involvement.
3. Suddenly the Borg attack, and Maclen and Kate are on the away team. On the Borg ship, they are able to punch, kick, and shoot the Borg, and the Borg, played by other people, react by firing back. This is an interactive, transitive behaviors which are supported by Universal Avatars. It is not possible to implement such a simulation within a chat environment.
4. Maclen and Kate save the day and are awarded commendations. The system, since it supports persistence of identity, can record this information in the appropriate Universal Avatar files.
5. Maclen and Kate say goodnight. After this virtual date, Maclen runs his custom Java applet for a kissing animation, and Kate responds with stars spinning, fireworks and bells.
6. The developer who made this virtual adventure will have access to valuable marketing information. A month later, this developer ships a new title. This company can now request that Maclen's agent, which is authorized to accept compensated interactive advertisements, offer Maclen a "friends play free" coupon - because it notes that he usually brings a date. He accepts the offer, and this action demonstrates a powerful spam-proof, "informed consent" based, one-to-one marketing channel. Again, all of this is possible because of the support for the Universal Avatars standard.
These examples are meant to illustrate the power of universally accepted standards for multi-user worlds and avatars. But to do all of this, the UA spec has to be broad. The proposal has several areas of functionality -
- Through the use of the Universal Avatar specification, the user can describe a representation of his avatar within any VR virtual world client, and then transparently enter a second world built by a different vendor, using a different VR system, and still look the way he wants to look. VRML is an open standard for immersive 3D, and the addition of a Universal Avatar standard lets you keep your identity as you move from one implementation to another.
- The information contained within the Avatar can be an extension of the kinds of fun, expressive, multi-modal information a user might wish to include in a personal home page. This informational database about people and their avatars, which could contain many characteristics, could then be searched or filtered by other parties. For example, people throwing virtual parties about a certain subject of interest would have access to a large universe of potential participants who have registered Universal Avatars, through a reverse search facility. Users would be able to advertise and broadcast their interests in a safe manner.
- Extensions to the avatar could easily be created. For example, it would be then possible to create a 3D virtual pet, with behaviors, that could follow the user's avatar into any virtual world. These 3D virtual pets could be treated as persistent objects that other virtual participants could copy or download.
- The real power of Universal Avatars comes from the inclusion of other capabilities into the system. First, consider the implications of embedding a public key, or certificate, into the Universal Avatar file. By introducing secure communications, the avatar can instantaneous financial micro-transactions seamlessly in a virtual world. For example, an avatar could walk through a virtual mall and transparently purchase items. Since his/her profile is under the strict control of the user, s/he could declare an interest in modems. Virtual stores could then automate the process of discovering where the potential customer's interests lie. Finally, this capability will give virtual world operators a more powerful tool for running virtual environments that are safe for children.
- Additionally, virtual world developers will be able to more easily establish inter-world communications by defining certain capabilities into a Universal system. For example, we could establish a standard for connecting to a global directory service system, so that Internet telephony can be enabled between disparate virtual worlds created by a different vendor, using a different VR systems.
- Finally, user's profile provides a powerful secure, user-controlled marketing channel. The user could allow his/her secured transaction history to be accessible to commercial vendors through a trusted intermediary... for a price. A system of compensated direct mail marketing can then be created around Universal Avatars. This helps form a one-to-one marketing channel to the user, that provides purchasing histories, VAL segmentation data, and real-time probabilities of sales response rates. With compensated direct marketing, the consumer gets paid what direct mail companies otherwise spend per name on targeted lists and printing costs. The dis-intermediation of direct mail marketing will lead to compensated interactive marketing within a few years, and we could tie avatars into this movement to help create a user-controlled revenue generation model for VRML world builders and operators.
IMPLEMENTATION
We will now proceed to a discussion of how Universal Avatars should be implemented. The specification has six areas of functionality - profile, representation, authentication, communications, the management of personal agent applications, and vendor extensions. But before we delve into the details, let's start with basic conventions.
Naming standards for Universal Avatar files
A Universal Avatar file can be stored at either the user's computer, any web server, or at a secure third party's avatar storage system. However, we recommend that these files be stored at secure servers, managed by trusted avatar management companies, for three reasons - security, availability and bandwidth.
When an application or browser attempts to access a Universal Avatar, the first file it locates and reads is a master file that contains information for managing multiple avatar contexts. A master avatar file would be located at a URL like -
http://www.avatar.com/user3211/uamaster.wrl
This file would be a VRML 2.0 document, containing links to different avatar files. The user and application can then determine what type of avatar to load, by examining the context and rules of the virtual world requesting this information and the instructions of the user. For example, within a business context, your avatar may or may not choose to reveal the gender of his or her avatar. However, if the avatar is operating in a social context the revelation allowance for gender may be different. Another example has to do with virtual worlds for children, and kids who might wish to enter with a, shall we say, off-color avatar. The contexts of church, parties and work often inspire different kinds of dress, and we should respect that social standard.
Thus, the user can then set up a number of contexts, or states. We wish to receive additional input about the actual designations, but we recommend that the standardized contexts to be Social, Business, Gaming, Shopping, Anonymous, Mature and Other, but additional, hierarchical contexts can be defined by either the user or vendors. Thus, it will be the responsibility of the application to decide whether it recommends or requires a certain context. For example, a number of on-line churches could decide to create a context called Devotional, and their virtual churches could request the user to authorize the creation of that context for them to allow entry. Or, these churches could simply flag whether the visitor has a Mature context, and politely request a change in context before being allowed to enter.
The user could even customize these states as needed and use them whenever he/she desires, or as the situation dictates. Thus, the context Social could set gender and other fields public while state Anonymous may set them as private, etc. If they're private, they cannot be accessed by others and depending on the settings, different versions (visual representations) of the avatar may be displayed. This gives the user complete and flexible control over gender disclosure, an important social issue for virtual socialization. Also, the associated marketing agents could be turned off while in certain contexts.
A master context file would look like...
#VRML Draft #2 V2.0 utf8
WorldInfo {
info [ "Sample source for Universal Avatar Context
file" ]
title "Master Avatar Context Sample"
}
DEF ContextTypes AvatarContexts {
types [
AvatarContext {
type "social"
url "http://www.avatar.com/user3211/default.wrl"
}
AvatarOneType {
type "social/devotional"
url "http://www.avatar.com/user3211/sundaybest.wrl"
}
AvatarContext {
type "business"
url "http://www.avatar.com/user3211/armani.wrl"
}
AvatarContext {
type "gaming"
url "http://www.avatar.com/user3211/klingon.wrl"
}
AvatarContext {
type "shopping"
url "http://www.avatar.com/user3211/default.wrl"
}
AvatarContext {
type "anonymous"
url "http://www.avatar.com/user3211/lurker.wrl"
}
AvatarContext {
type "mature"
url "http://www.wonderland.com/users/alice.wrl"
}
AvatarContext {
type "other"
url "http://www.avatar.com/user3211/default.wrl"
}
]
}
These additional files, which describe the avatar, would be VRML 2.0 documents, containing links to the various components that the Universal Avatar file would require. This Universal Avatars file would be divided into six logical sections. We will now discuss each of these sections in turn.
Part 1: User Profile
The first portion of the Universal Avatars file would link to a file containing the user's profile information. It would be coded in HTML and would contain only that information the user wishes to share openly with the world, and is in effect, the avatar's (not the user's) home page. This file could contain fictional information, useful within a game this avatar is dedicated to, or it could be the truth about the user's identity, if that is what the user wishes. It's completely up to the user. The user's true identity would not be required, and with this avatar, this user could enter any world not requiring positive identification. This initial file would use standard HTML 2.0 assets extensively, such as text, JPEGs, and so forth. The only requirements for this file are the inclusion a few data fields, such as name, location, interests, etc., as well as that of an anonymous remailing mailto: tag that would link to the avatar management company so that requests for contact can be mediated by the company or the user's mailbot. For example, mail to pre-teen users could be first directed to parents for preview. These core data fields can be marked with special tags that will be transparent to any browser, and meaningful only to a Universal Avatars compliant application. Obviously, the user could create different profiles for each of the contexts used, or default to the same URL.
Thus, any application that supports Universal Avatars would know the screen name of any user, and upon right-clicking the avatar, the application could possibly load that avatar's home page or the browser could create a new window containing that profile.
Part 2: Models and Behaviors
The second portion of the file would contain basic information for the rendered avatar model, including 3D Model, Animation and Behaviors. We would like to allow users to maintain an identity that is as consistent as possible across several different platforms. Existing avatar representation technologies range from 2D sprites to 3D sprites to 3D non-hierarchical models to 3D hierarchical models to 3D voxel rendering. Each of these systems has its strengths and weaknesses. We wish to accommodate all of these technologies to insure universality.
So the first part of the avatar representation uses the specification of a major type and a minor type. An example of major type would be VRML1 or VRML2. An example of a minor type would be Live3D if one wanted to use proprietary extensions understood by that browser or generic to not use those extensions. The browser or application would have to know enough about its environment to determine which browser it was running, and choose the appropriate model based on that.
Thus, a typical avatar definition file might be -
AvatarType {
type "browser/vrml2/live3D"
url "http://www.avatar.com/user3211/model/alice.wrl"
}
Thus, this system allows a user to store multiple avatars, each tuned to the capability of the browser, with respect paid to the proprietary extensions that the browser would be free to produce. Generic VRML can also be created for strictly compliant browsers and applications. Also, since there is no current standard for generic 2D avatars, which are popular for systems operated by firms like (like Ubique/AOL and The Palace), we recommend that 64x64 pixel GIF and JPEG files be considered as the generic 2D standard. Also, we believe that scanning of realistic personal avatars is an emergent market, and that this standard supports Avatar Scan Booth technology sufficiently.
The models would be followed by descriptions of behaviors for the avatar. A typical behavior might be linked via -
AvatarBehavior {
type "vrml2/java/walk"
url "http://www.avatar.com/user3211/behaviors/walk.class"
}
There are many other issues that must be considered, and the following is only a beginning of these issues that should be included in the spec.
First, we have the issue of size and scale. Should there be a metric for how big an avatar should be. Should there be limits to the size allowed? Some worlds would prefer that no kids run around at 27 feet in height, stomping on the adults trying to have a quiet conversation. Converserly, an Alice in Wonderland world may require great variability in size and scale.
There may be a social issue to resolve as well. Virtual world vendors will want to make rendering easier by requiring both scale and complexity limitations (otherwise known as "one avatar hogging all the bandwidth or rendering cycles, quite marvelous and splendid to look at, but can bring any reasonably configured client to its knees, thus making the place no fun for anyone.") Others may feel that there's no need for a "Procrustean Bed" in a virtual world. The issue resolves to that of an individual's right to expression versus the needs of a community of users or the virtual world vendor, to produce its own standards. In simplest terms, the solution is to let the user make a request first, and then let the virtual world vendor decide.
Universal Avatars proposes to use BOTH absolute and relative sizes for the height metric. The application must then be intelligent to see if the absolute size makes sense first, and then use the relative size if necessary. The absolute size should be in meters, and the relative size should be a fractional value, with 1.0 set as the recommended or subjective mean height of avatars in this environment. Furthermore, we also propose to apply the same reasoning to rendering complexity, by describing the avatar's in polygons. For example, consider the following -
AvatarType {
type "browser/vrml2/live3D"
complexity 200
abs_size 1
rel_size 0.5
url "http://www.avatar.com/user3211/model/alice.wrl"
}
AvatarType {
type "browser/vrml2/live3D"
complexity 800
abs_size 1
rel_size 0.5
url "http://www.avatar.com/user3211/model/alice2.wrl"
}
And now, it's up to the virtual world to decide what would be appropriate, seeing that the user is using a pretty average PC at home. If it's a one-on-one VR conference call, then the rich, complex avatar would be used, but if it's a crowd scene in DisneylandVR, the less complex avatar model would be required. Furthermore, if it's Disneyland, and there's a height requirement that all visitors must be between 1.5 and 2.0 meters in height, the virtual world would look at the absolute size of 1 meter, see that it's too small to reach the many triggers, but would wish to satisfy the wish of the user to be smaller than everyone else. This virtual world would probably set the avatar whatever size they feel would satisfy the user, which in this case, would be about 1.6 meters.
The next design goal deals with behaviors. A simple classification system for behaviors is to separate behaviors that effect the world and possibly require a reaction from another avatar (which we will refer to as transitive behaviors) from those that effect solely one's own avatar (which we will refer to as intransitive behaviors). From an implementation standpoint, modifying solely one's own representation is more separable from the underlying server than behaviors that modify the world.
For behaviors dealing only with one's representation of self, intransitive behaviors, we propose the following system:
Alice decides to make her avatar smile, so she either hits the smile button on her browser if it has one, or she types "behave: smile". Fred is hitting on Alice, and his browser receives that text. His browser looks to its local cache to see if it knows about Alice's smile behavior. If so, it just applies that behavior to her avatar. If not, it goes to the URL where Alice's avatar came from and searches in the same place for a smile behavior (http://avatar.com/user3211/vrml2/behaviors/smile.class)
Also, the avatar file should have a list of possible behaviors supported by the avatar which can be queried by the browser. (/vrml2/behaviors/index.foo) That would allow Alice to pull down a menu to see what her behavioral choices were. The browser could even allow her to create emote-icons for her preferred behaviors for fast access.
For behaviors that require a reaction from another avatar, transitive behaviors, we propose the following system:
First, we believe that trying to contain all behaviors within a single avatar data structure will require too much data to be transmitted. On the other hand, limiting the standard to a subset of universal transitive behavior primitives will overly constrain the system, and not allow the growth of rich and dynamic gestures and behaviors. And finally, we are searching for a solution by which we can embed some MEANING for the actions into the system, so that the VRML simulation environment might be able to act upon the context as well, in some way. This would make great sense within a multi-user game, or a world which reacts to the meaning of behaviors.
We believe that the problem of avatar interactions is similar to that of natural language processing, in that two parties must understand the symbolic meaning of an action in order to hold a meaningful conversation. Just as the deeper structure of language can be made clear when using parse trees, we believe that we must do something similar for avatar actions. Transitive behaviors are essentially communication between actors, even if no linguistic activity is involved in them.
For example, consider the sentence -
I smile.
This is an intransitive verb, in that it requires no direct object. It maps well to the thing that we call a user-initiated, intransitive behavior.
However, consider the following sentence structure, using a transitive verb, like tickle -
I tickle Jenny.
This no longer maps easily. It can possibly invoke a very complex counter-behavior. In this case, I am the subject/actor, tickle is the verb/action, and Jenny is the object/recipient. There exists an unspoken conceptual framework that underlies transitive verb statements - that tickling with a feather usually yields this action called giggling. Language exists withing a conceptual framework, and so do avatar actions. Thus, a framework exists in which the action "tickle" requires a recipient's re-action called giggles. And we arrive at -
I tickle Jenny. Jenny giggles.
But how can we implement all of this within an object oriented framework? Our proposal is to create a methodology that integrates the current proposal for intransitive behaviors to use local server querying, but provide a framework for working with the meaning of the actions. By creating a symbolic system for handling actions, we can reduce meaning to a smaller system of fewer inference rules, yet preserve the freedom of a fully unconstrained system. A side benefit is that any virtual world operator can begin to create their own meaning frameworks, that would add to the standard framework.
To create an implementation of this, we must seek to define a hierarchical classification of action primitives. For example, walking and limping are derivatives of the primitive action locomote or translate. Throwing a ball or releasing a paper airplane are derivatives of the primitive propel. Eating, drinking and shoplifting are all derivatives of the primitive ingest. The power of the methodology comes from binding inference rules and parse structures to these primitives within action space. For example, tickle is clearly transitive and requires a direct object. On the other hand, eating requires an indirect object that is ingestible.
Another benefit comes from the ability to inherit properties of the objects we utilize. For example, the object known as a feather, could act as an instrumental, and thus contain a method for tickling and eliciting a giggle. This is better for interface design, as typing "tickle: Jenny" or accessing a pull down menu is never as transparent as simply grabbing and using a feather, which supplies the proper animation for using the feather and triggers a giggle reaction in the recipient avatar.
Here are our suggestions for primitives and their associated properties.
idle
- what you do when you're just standing around: foot tapping, breathing, boredom gestures
emote display an emotion locomote
- translate with the environment, as in walk, fly, dance, hobble, limp
ptransfer transfer of a physical object to either the world, another object or another avatar - such as a ball, a cup or a pen ctransfer transfer of a conceptual object to either the world, another object or another avatar - such as a recorded voice stream containing a puzzle clue, a virus that reduces the user's healthstate slowly propel to cause an object to translate through the environment, as throwing a baseball catch to receive an object that is either in motion or has been propelled ingest to absorb or consume an object, and hold it within the avatar storage system expel to release an object from a held status xhealth to increase or reduce the health state of an object, until the recipient exhausts its health points and enters the state of avatar expiration transform to grow or shrink or change the object definition of an object utilize to hold and use a tool object converse to hold a verbal dialogue other some other kind of action
Then we can form a hierarchical classification that uses these canonical primitives as roots. Thus all actions can be classified into, but not necessarily bound by, categories of actions. For example, locomote would be a root for run, walk, dance, skip, sneak, limp (injured), crawl. If the system needed to find a behavior for limping, for say, an injured avatar, but it couldn't, it could potentially replace it with a slowed walk cycle. In the same manner, the system would query the user's avatar file as to whether it had a preferred way to dance. If it could not locate the user's preferred dance animation, it could load a default dance. This is only possible if the system provides a symbolic meaning for the behavior so the target system could decide how to handle behaviors intelligently. Dance could fit within one of several primitives, namely locomote or idle, and the system seeking a replacement dance behavior would use this valuable information (whether it's a locomotion type dance, or a standing still dance) to select an appropriate dance behavior.
Furthermore, users and virtual world operators could create their own, new canonical primitives. Perhaps someone creates a virtual world for amoebas. In this world, you can use your pseudopod to move around, exchange DNA or wiggle. In this environment, the virtual world operator might wish to create a taxonomy of transitive action symbology. The world developer might extend our primitives with special case amoebas behaviors.
Here is an example. Let's talk about Alice again. Alice decides to make her avatar tickle Fred, so she either hits the tickle button on her browser if it has one, or better yet, she picks up a feather which has a tickle method embedded in it, that her avatar inherits. Specifically, when Alice picks up a feather, it loads a tickling behavior into Alice's browser's local cache. (And hopefully, the system is smart enough to force Fred's avatar to pre-cache a reflexive giggling behavior.) Anyway, Fred is flirting with Alice, and his browser receives a message that he should giggle, which has appended to it some text that implies that tickling is a derivative of say, the "emote" primitive, and that it is transitive, and further requires that he know how to "giggle". His browser looks to its local cache to see if it knows about Alice's tickling behavior or the requested giggle. If Fred's browser finds everything it needs, it applies the tickling animation to her avatar, and runs the giggling behavior on his. If not, it goes to the URL where Alice's avatar came from...
http://avatar.com/ alice-avatar /vrml2/Sony/avatar.wrl
and searches in the same place for a tickle behavior.
http://avatar.com/alice-avatar/vrml2/Sony/tickle.class
He finds the behavior, since she initiated it, and it applies it to Alice's avatar. Now here's the hard part. What if he has no giggle behavior? Then he has two choices. First, he goes to his avatar provider, which supports Universal Avatars, and sees if his provider has maintained the behavior list and created additional canonical behaviors to match up with the hot new tickle behavior.
http://othercompany.com/fred/vrml2/behaviors/MasterIndex.foo
If the index does not contain that behavior, then he knows from the tickle message that giggling has a primitive of emote. The index then says that giggle is very close to laugh in meaning, which it does have. It then loads and runs the laugh behavior. An equivalent process makes Fred's avatar giggle in Alice's world.
A few caveats. First, action descriptors and action primitives are not English. They are a shortcut for naming behaviors that have a conceptual meaning in a normal world. People use language describing actions in incredibly imprecise ways, especially compared to how computer systems that perform the actions needed to represent the activities. However, this system allows incredibly compact and effective action descriptions to be generated.
Another strength in using a hierarchical, formal representation for actions is that context-dependence gives the system the ability to monitor the actions taking place in your world and report on them to other people or processes. Suppose someone wants to write a game or comedic virtual world that forces the weather change whenever people are trying to wash their cars? Or be able to have the system launch a "Sh! Be quiet" bot when people are tickling and giggling in a library virtual world?
This proposal for managing interacting transitive behaviors is admittedly preliminary, and requires greater analysis by the community before adoption. Very powerful frameworks for similar systems can be found in research efforts in fields like MOOs, with include methods for handling prepositional objects and a richer set of action primitives. However, we felt that the proposed system would be sufficient for immediate implementation.
A number of other issues need to be discussed as well, but must be postponed until a later time. For example, the critical issue of accelerating display of VRML through spatial partitioning (e.g., binary sort partitioning) needs to be resolved by the VRML community before the issue of pre-sorting avatar model files (which is one method by which the game Quake achieves its infamous rendering speed), before the issue of accelerating avatar rendering by including pre-sort trees adjacent to our avatar models. Another issue that needs to be resolved is the latency issue. Transitive, reaction-required actions, such as throwing and catching a ball, are very difficult to do within a latency-prone simulation, which is the case on standard Internet multi-user simulations. Several solutions for latency mitigation have been developed by various companies, to address this issue. We believe the format we are proposing will fit with emerging distributed consistency solutions that provide just-in-time reaction capabilities rquired for distributed, delayed interacting behaviors, such as throwing and catching.
Before we close on this portion of the file, let's go through one more example. We now wish to discuss the issue of how virtual people "shake hands", as an example of how simple avatar behaviors could be empowered by the usage of Universal Avatars. [TBD]
Part 3: Trust and Transactions
The third portion of the Universal Avatar file would contain methods for establishing and using trust. This standard also propose the use of public keys or certificates to enable secure communications and transparent financial transactions. There might be several classes of transactions that could utilize avatar authentication. Each would use separate mechanisms, thus giving some insularity to each process.
The first class of transactions would deal with personal identification. In this sense, when an avatar is registered on a server, it will establish a positive digital identification verification if desired by the avatar owner. This personal identification can then be forwarded to the other local avatars as requested and agreed upon.
The second class of transactions would deal with copyright tracking. For tracking a hierarchy of intellectual property rights, it might be necessary to implement and extend public resources like the patent mechanism. Here we might envision lots of privately held applets that people like to use. If these applets are used as base processes for more complex applets, then each could agree to assign the tracking of the use of these processes to a common broker system within a trusted network. If some document or process used various elements from different copyrighted sources, they could agree on a broker structure that would handle the necessary use notifications to the copyright owners, then enable the use of the document or process.
The third class of transactions would deal with electronic funds transfer. If two avatars, say a user avatar and a corporate maketing avatar located at a site, wanted to transfer funds to cover the exchange of one of the applets mentioned above, the request for that might be handled in several different methods. One method would be that the avatar authentication would enable file transfer of ecash to the marketing vendor upon simultaneous receipt of the software. Another method would be to establish a one time encrypted transaction, based on checksum values of the client and vendor IDs. The second method allows for tracking of electronic funds, and recourse to the more general level of money allocation afforded by credit/debit cards and electronic data interchange transfers. In any case, these capabilities must rest upon industry accepted authentication technologies, such as Verisign's Digital Identification structure, etc. When there reaches a point that there is developed a system of trusted networks so that no one point controls verification, then we can approach true electronic marketplace.
This issue will be more completely addressed in the third draft.
Part 4: Communications
The fourth portion would contain information enabling inter-world communications. For example, imagine the power of enabling Internet telephony and IRC chat between users in disparate virtual worlds created by different vendors. To do so, we must rely on open standards such as H.323. H.323 provides for negotiating point to point and multipoint audio conferences in a variety of network topologies. As it stands it could form the core of a Virtual World audio system but is missing many features, such as 3D Positional Audio, Lip Sync, Background ambient audio and so on.
To be compliant, any H.323 client has to support the G.723 codec. It can optionally support other codecs e.g. VoxWare, OnLive!, Lucent. Two end points then negotiate to see if they have a codec in common - so if we both had VoxWare or OnLive then we could communicate and enjoy the benefits of our favorite codec, failing that we would default back to G.723. The problem with G.723 is that it doesn't really lend itself to multi-point communication. This issue will be addressed in the third draft.
Additional capabilities can also be standardized. For example, the steady migration of speech recognition hardware to the NT platform is now making it possible to embed high quality, speaker-dependent speech recognition into the multi-user server, so that users can rely on speech recognition processed on the server, rather than the client. Certain hurdles need to be overcome, but this will advance the development of voice driven agents within virtual worlds. One possibility is to place standardized speaker profiles into the Universal Avatar file to enable speaker-dependent quality speech recognition from any client - work PC, home set top box, all the way to the ATM machine on the corner.
Finally, inspired by our international mailing list contributors, we propose to include a preference field in the Universal Avatars field to enumerate the natural languages that a user can speak or comprehend or read and write. In real life, when two people meet, and one speaks Spanish and Chinese and the other speaks Russian and Chinese, there is a negotiation process to find out a common language for conversation. After this process, they both find Chinese is the common language between them. We propose including an "understandable languages" list, by which the language negotiation process will be speeded up in the digital worlds. When two avatars face each other, they will exchange greetings automatically. By knowing the understandable languages of the other user, you can tune your gestures to be appropriate to that user, e.g., a bow instead of a handshake.
This "understandable languages" list will be particularly useful in business situations. It will assure better business for the avatars or bots who wait for customers in their virtual shops. They can say "hello" in the mother languages of the customers. This is a very good idea.
Part 5: Personal Agent Management
We propose that the fifth section of the Universal Avatar file be reserved to provide links to user agents that can be invoked by the user or the application.
First, a prologue. Yes, agent technology has been overhyped. But significant advances are taking place in the area of agent technology. With the release of IBM's Aglet Workbench (Java-based mobile agent applets) and the imminent release of Mitsubishi's Concordia agent technology, a solid platform for Java-based agents is emerging, and agents are going to be the next hot emerging technology.
One obvious reason agents are hot is related to the form that information is available in. In the past, paper was the most frequently used media for information, and most useful data was stored in proprietary databases. Until recently the market for information was driven by supply, and it was fuelled by a relatively small group of suppliers that were easily identifiable. And as we all know, the World Wide Web has changed all that. Information is now slowly becoming demand-driven, and the number of suppliers has grown enormously.
There are four areas in which the use of agents will become vital.
First, users are becoming more mobile, and not only do they want to access network resources from any location, they want to access those resources despite computing and bandwidth limitations and underlying network volatility. Thus, intelligent agents which reside in the underlying network rather than on the users' personal computers, which are taxed by the requirements of high performance 3D computing, can address these needs by persistently carrying out user requests despite network disturbances. In addition, agents can process data at its source and ship only compressed answers to the user, rather than overwhelming the network with large amounts of unprocessed data.
Second, as business uses for virtual reality are slowly realized, we will probably find two recurring themes in that new form of usage. These are the constant need for information access and the superiority of the immersive 3D environment for management of too much data. In this case, intelligent agents could users not only with search and filtering, but also with categorization, prioritization, selective dissemination, annotation, and (collaborative) sharing of information and documents, for presentation through the VR interface. Again, this is possibly best done off the user's client PC, which should be reserved for 3D processing and voice compression, and other computationally intensive activities.
Third, electronic commerce is a growing area fuelled by the popularity of the Internet. Buyers need to find sellers, and they need to find product information that solve their problems. Sellers need to find buyers even more desperately. Both buyers and sellers need to automate the process. Intelligent agents can assist in electronic commerce in a number of ways, all of which apply within VRML shopping environments. Agents can help the user shop more effectively, taking requirements and returning with recommendations. They can act as sales robots, as well as agents for the buyer.
Fourth, computers will always be difficult to learn and use. As applications improve, the user interface usually increases in complexity. As user populations grow and diversify, computer interfaces need to learn user preferences and more importantly, to adapt to individuals. Intelligent interface agents, also known as tip wizards and genies, can help with both of these problems. Intelligent agent technology allows systems to monitor the user's actions, develop models of user abilities, and automatically help out when problems arise. When combined with speech technology, intelligent agents enable computer interfaces to become more human or more "social" when interacting with human users.
We propose that the fifth section of the Universal Avatar file be reserved to provide pointers to user agents that can be invoked by the user or the application. Let's see how we could manage agents within the Universal Avatar framework. Let's consider the example of electronic commerce, and in particular, our previously described example of compensated direct interactive marketing, in which sellers bid for the user's attention. In our example, we use the IBM Aglets framework to elucidate the process.
When the virtual reality buyer walks into a VRML mall, the mall server informs all of the store servers that a likely suspect has arrived (itself a mobile agent process) and provides the user's Universal Avatar URL to the store servers. Then mall servers would access the Universal Avatar file to look for a market agent. It would find something like...
AvatarMarketProfile {
type "buyer/compensated"
agent "atp://vwvendor.com/user3211/myagent.class"
}
At this point, the mall server would execute that agent applet and provide to that agent's itinerary class the locations of all interested store servers, which would invoke that agent and send it off to all the store servers to arrange for an auction at a single secure context (i.e., a uniform execution environment where the host system provides a meeting room for agents to negotiate). In this multi-agent system, the buyer's agent probably provide the rules of the auction, which in this case would probably be a Vickrey auction (based on work by the late Nobel Prize winner, William Vickrey). At the auction, the user's agent accesses the user's market profile, stored in a secure database and accessed via JDBC (Java Database Connectivity) and would provide the stores the required information about VAL segments, purchasing history medians and response rate probabilities based on the kind of products being offered at what kinds of price points. The store's agents would have enough to be able to make meaningful offers, and would also use their own databases of whether they can believe this agent, or would need to discount their offers. After the auction process, the winner of the auction, paying 15¢, is remarkably someone who knows the Universal ID of the user and has compiled a history about this person. That store is the only store allowed to send an adbot to greet the user. This effectively eliminates the possibility of spamming the VR user. In this scenario, everyone wins.
Next, let us consider the use of an intelligent interface agent within a VRML world. Again, these are agents which allows systems to monitor the user's actions, develop models of user abilities, and automatically help out when problems arise. Rather than simply storing a "favorite navigation method" within the Universal Avatars file, consider the possibility of having an interface agent which sticks with you throughout your navigation history. It would have to be quite intelligent, understanding the limitations and interface of every browser and every set top box, but that's a market opportunity, not a barrier. When you move to a new system, the agent could help ease the transition to the new interface in ways that are not possible today. Because of the use of multiple Universal Avatar contexts (which is quickly becoming an overused term), the user can put one different presentations which can accrue different kinds of value. The user can then cultivate a serious shopping context which would generate significant compensation.
Agents are a greatly overhyped technology, with its own history of misfires and broken promises. However, agents are now becoming a very real technology, primarily due to the success of Java and the Internet. Ultimately, it will be users that drive the success of agent technology, but that won't be possible unless some great applications are built first.
The Internet is an ideal environment for agents as they are well adapted to its complexity and extensiveness. Buthe convergence of VRML with agent technology has not been fully examined, and this is the right time and place to begin doing that.
To get to this stage, some important obstacles need to be tackled first. As evidenced by the Aglets and Concordia technologies, the problems of agent transport, persistence, security, and database connectivity are now being addressed, but the problems of intelligence and communication with other agents, applications and humans is still unsolved. However, the promise of agent technology is significant, and all we are doing within the spec is relying on emerging standards for agent technology.
Part 6: Vendor Extensions
The sixth portion would contain vendor specific extensions. For example, computer games producers could save information here that would be valuable to other game producers servicing the user. For example, a high experience level, e.g., wizard status, in one virtual world could indicate to another world producer that the user should be placed on a fast track to superuser status. This will be addressed in the third draft.
IMPLEMENTATION PROPOSAL
Protocols
This section describes the protocol elements required for Universal Avatars compliant servers and clients.
Definitions
· AvatarServer: This is the Universal Avatars server. Its responsibilities include storage and retrieval of information related to users and their avatar representations and behaviors.
· Client (Browser): This is the client side of the Universal Avatars specification. Typically, it will be the client side of a product like Worlds' AlphaWorlds or Chaco's Pueblo.
· UAServerURL: This is a registry entry on the client machine which contains the URL of the user's avatar on the AvatarServer. The registry entry is set by a compliant client (browser), and may be changed by browsers if they desire. On MS Windows, this is a registry entry. On other systems, it is the equivalent mechanism.
· MUServer: The MUServer is the Multi-User Server associated with the client. This is proprietary to the vendor, and is not strictly required (Universal Avatars could be used in a single-user environment with no server, or in a peer-to-peer environment). The MUServer is used for examples because server-based architectures are the most likely scenario for Universal Avatars compliant products.
All HTTP commands return standard HTTP status values. 200 for success, 401 for unauthorized request, etc.
UAServerURL commands
UAServerURL is presumed to be a CGI program which implements the following commands:
UAServerURL login <name> <security_level> <password> {where
name is the username on the Avatar server,
security_level has one of these values:
0. No security. Nothing appended to UAServerURL commands.
1. Signing (no purchasing). Key and password are appended to commands.
2. Full security (purchasing). Commands are encrypted, and include password.
password is the password associated with the name specified.
}
UAServerURL get identity {returns the list of identity names - Identity node}
UAServerURL put identity <name> {adds a name to the list of identities.}
UAServerURL del identity <name> {delete the specified name }
UAServerURL get profile <name> {returns Personal Profile node}
UAServerURL put profile <name> {overwrite the existing Personal Profile node }
UAServerURL get tech <name> {returns the list of supported technologies - Tech List node}
UAServerURL put tech <name> <major type> <minor type> {overwrite the specified Tech node}
UAServerURL del tech <name> <major type> <minor type> {delete the specified Tech node }
UAServerURL get tech <name> <major type> <minor type> {returns the specified Tech node }
Identity node = [[name][,name]*]
Tech node = [[AvatarURL] [Behavior node URL]]
Personal_Profile node = [[Body hints node] [User Readable text]]
Tech list node [[major type, minor type]+]
User_Readable_info = [{text}]
Body hints node = [{text}]
Behavior node = [[name], [graphic], [implementationURL], [{keywords for browser hinting}]
Scenarios
For these scenarios, each step is labeled in one of these ways:
· standard: This step is fully specified by Universal Avatars.
· prop: This step is proprietary to the client or MUServer vendor.
Scenario: Client logs in.
1. {standard} The client logs into the AvServer (which it knows from the registry)
2. {standard} The client calls UAServerURL get identity, which includes several identities.
3. {prop} The client picks one.
4. {standard} The client calls UAServerURL get tech <name> <major type> <minor type>.
5. {standard} The client parses the AvatarURL from the tech node.
6. {prop}The client connects to the MUserver.
7. {prop}The client passes the AvatarURL to the MUserver,
8. {prop}The MUserver may pass back an avatar, and a position in the world.
9. {prop}The browser may update the AvatarServer with UAServerURL put tech and UAServerURL put profile.
10. (standard} The client downloads its avatar.
11. (prop) The MUserver tells the client to display a scene.
12. (prop) The client wanders around sending its locations.
13. (prop) The MUserver discovers the client encounters client2.
14. (prop) The MUserver sends to client1 the AvatarURL for client2 and its position.
15. (standard) Client1 downloads client2's avatar.
Scenario: Client1 curtseys.
1. {standard} The client logs into the AvServer (which it knows from the registry)
2. {standard} The client calls UAServerURL get identity, which includes several identities.
3. {prop} The client picks an identity.
4. {standard} The client calls UAServerURL get tech <name> <major type> <minor type>.
5. {standard} Client1 calls UAServerURL get tech <major> <minor> to get Tech node
6. {standard} Client1 goes to BehaviorURL to get list of behaviors.
7. {prop} Client and MUServer can eliminate any unwanted behaviors.
8. {prop} Client1 builds emoticons on browser to enable calling of specific behaviors
9. {prop} Client1 calls a behavior from the newly enabled browser.
10. {prop} Client1 sends URL of behavior to MUServer
11. {prop} Client1 displays behavior locally.
12. {prop} Client2 recieves URL from the MUServer.
13. {prop} Client2 gets behavior (if not cached) and executes locally.
Scenario: Client enters a space using a totally new browser.
1. {standard} The client logs into the AvServer (which it knows from the registry)
2. {standard} The client calls UAServerURL get identity, which includes several identities.
3. {prop} The client picks an identity.
4. {standard} The client calls UAServerURL get tech <name> <major type> <minor type>.
5. {standard} AvServer returns failure.
6. {prop} The client may call UAServerURL get tech <name> to get the list of supported techs for this identity.
7. {prop} The client may fall back to <major type> <generic> if one exists.
8. {prop} The client may call UAServerURL get profile <name> to get body hints to generate the closest matching avatar
9. {prop} The client and the MUServer determine a URL for the new avatar.
10. {prop} The client and the MUServer determines a set of behaviors for the new avatar and places it in a URL.
11. {standard} The client calls UAServerURL put tech <name> to enter the avatar into the database.
12. {prop} The client may call UAServerURL put profile <name> to update the body hints.
Proceed as above after the client calling UAServerURL get tech succeeds.
Other Scenarios to Complete:
· Buying something.
· Identifying someone else from the browser.
· Establishing an internet phone call from the browser.
· Selling something.
· Releasing information to someone from the browser.
Sample Code
The following section contains an example of the source code for creating a universal avatar.
[[** This section is subject to massive re-writing **]]
#VRML Draft #2 V2.0 utf8
WorldInfo {
info [ "Sample source for Universal Avatar
Definition file" ]
title "Avatar Sample"
}
# --- Begin sample source for Universal Avatar Definition
File ---
# --- I. User Personal Profile ---
# All PROTOs in this sample file could be implemented
as
# EXTERNPROTO instead.
PROTO AvatarPersonalProfile [
exposedField SFString userPage ""
exposedField SFString userData "" ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
DEF MyPersonalProfile AvatarPersonalProfile
{
userPage "http://www.vwvendor.net/user3211/profile.html"
}
# --- II. Avatar Modeling and Behavior Information
---
PROTO AvatarTypes [ exposedField MFNode types [ ]
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneType [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
# --- Note: If the browser in use doesn't find a
match in the list ---
# --- of AvatarTypes, it should choose a default.
---
DEF MyTypes AvatarTypes {
types [
AvatarOneType {
type "browser/generic"
complexity 200
abs_size 2
rel_size 1.0
url "http://www.avatar.com/user3211/model/alice.wrl"
}
AvatarOneType {
type "2D/generic"
url "http://www.avatar.com/user3211/model/alice8.gif"
}
AvatarOneType {
type "browser/netscape.com/vrml2"
complexity 200
abs_size 2
rel_size 1.0
url "http://www.avatar.com/user3211/model/alice1.wrl"
}
AvatarOneType {
type "browser/worlds.net/vrml2"
complexity 300
abs_size 2
rel_size 1.0
url "http://www.avatar.com/user3211/model/alice2.wrl"
}
AvatarOneType {
type "browser/chaco.com/vrml2/pueblo2.02"
complexity 200
abs_size 2
rel_size 1.0
url "http://www.avatar.com/user3211/model/alice3.wrl"
}
]
}
PROTO AvatarBehaviors [ exposedField MFNode types
[ ] ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneBehavior[
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
DEF MyTypes AvatarAnimations {
types [
AvatarOneBehavior{
type "master"
url "http://www.vwvendor.net/user3211/vrml/MasterIndex.foo"
}
]
}
# --- III. The following are encrypted, encapsulated
trust and commerce systems ---
PROTO AvatarTrust [ exposedField MFNode certificates
[ ]
exposedField SFString parentalControl "no"
exposedField SFString access "full"
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneCertificate [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
DEF MyTrust AvatarTrust {
parentalControl "no"
access "full"
certificates [
AvatarOneCertificate {
type "certificate/pgp.com/"
url "http://www.vwvendor.com/user3211/pgp/mycert.crt"
}
]
}
# --- IV. The following are embedded communications
systems ---
PROTO AvatarCommunication [ exposedField MFNode communications
[ ] ]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
PROTO AvatarOneCommunication [
exposedField SFString type ""
exposedField SFString url ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarCommunication {
communications [
AvatarOneCommunication {
type "communications/voxware.com/vapi"
url "http://voxware.com/vapiserver"
}
AvatarOneCommunication {
type "communications/itu.ch/h.323"
url "http://itu.vwvendor.com/itu.h.323"
}
]
}
# --- V. The following are user agents ---
PROTO AvatarMarketProfile [
exposedField SFString agent ""
exposedField SFString access ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarUserGenie {
type "buyer"
access "compensated"
agent "atp://vwvendor.com/user3211/myagent.class"
}
PROTO AvatarGenie [
exposedField SFString agent ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarMarketProfile {
type "interface"
agent "atp://vwvendor.com/user3211/mywizard.class"
}
# --- VI. The following are vendor specific extensions
---
PROTO AvatarContact [
exposedField SFString address ""
exposedField SFString id ""
]
{
# Dummy node, required by VRML 2.0 spec
WorldInfo { }
}
AvatarContact {
address "anon_mailto:client34212@vwvendor.com"
id "3456545600003211"
}
# --- End sample source ---
CONCLUSION
All modifications and extensions should not interfere with the standard interpretation of VRML files, as they should merely complement a standard interpretation. All extensions developed should be presented to the VRML specification community for commentary and adoption into future VRML specifications.
To conclude, there is considerable amount of research that must be performed in the near future. It is of utmost importance that the virtual world community start to present avatar description concerns to the VRML community. This work adds value to other specifications under development, such as the Open Community API and Living Worlds, by providing a uniform model for persistent identity, a methodology for accommodating disparate avatar file formats, a flexible approach to implementing cross-application interacting behaviors between avatars, interworld communication mechanisms, and finally, a way to integrate agent technology.
By adopting the Universal Avatars specification, virtual world producers can realize many of the aspects of universal, seamless, persistent cyberspace: A virtual world 3D spaces, where avatars can be known for who they really are, will be able to shake hands to seal a deal, and where moving from world to world is a natural and meaningful process.
We look forward to working with the VRML 2.0 community to improve and extend the Universal Avatars standard.
This is a draft in progress. Not for release.
Early access provided to UA mailing list members only.
Please do not distribute to press.