Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
6476830
Farmer , ; et al.
November 5, 2002
Title
Virtual objects for building a community in a virtual world
Abstract
A virtual world computer process includes portable virtual token objects that can be used by on-line users of the virtual world to facilitate exchange of goods and services within the virtual world. In particular, client-server computer processes are provided for the virtual world that allow on-line users to conduct activities within the virtual world including getting, putting, giving, and receiving portable virtual token objects as well as other portable virtual objects. Each on-line user is represented in the graphic user interface by a virtual avatar object. Token objects are put into circulation by virtual ATM objects. A virtual ATM object allows a user to obtain a balance, deposit tokens, and withdraw tokens. A vendroid object is an object that sells portable virtual items in exchange for tokens deposited by avatars. Different virtual items have different values, and vendroids do not all have the same virtual items for sale. In the virtual world, a lurker is represented in a locale by a ghost object. An icon is present, i.e, an eye-the-sky, in a locale, whenever a ghost object, or ghost objects are present. Ghost objects have anonymity, i.e. their names are not known to avatars of the locale, and have limited interaction choices. A ghost object cannot talk or think to other avatars. A ghost object retains the ability to transmit private "ESP" messages to other avatars.
Inventors:
Farmer; Randy
(Cupertino,
CA
)
, Morningstar; Chris
(Cupertino,
CA
)
, Onusko; John E.
(San Francisco,
CA
)
, Morse; Norman
(Oakland,
CA
)
Assignee:
Fujitsu Software Corporation
(Santa Clara,
CA
)
Appl. No.:
699698
Filed:
August 2, 1996
Current U.S. Class:
715/769
715/977
705/26
715/706
715/751
715/753
715/758
715/759
Current International Class:
G06N 3/00 (20060101)
Field of Search:
345/330-332,335,339,348-349,355,962,976-977,706,744,751,753,757,758,759,763 395/200.34,200.65 705/26,39,41,43-44 709/204,205
U.S. Patent Documents
5347306
September 1994
Nitta
5491743
February 1996
Shiio et al.
5649118
July 1997
Carlisle et al.
5687323
November 1997
Hodroff
5729594
March 1998
Klingman
5732232
March 1998
Brush, II et al.
5838316
November 1998
Arruza
5852812
December 1998
Reeder
5880731
March 1999
Liles et al.
5918213
June 1999
Bernard et al.
5956038
September 1999
Rekimoto
Other References
Gary Brickman, "I'll Be Seeing You--When words are not enough, animated chat enters the picture", Netguide, 1995, n208, PG73, Aug. 1995.
Primary Examiner:
Cabeca; John
Assistant Examiner:
Bautista; X. L.
Attorney, Agent or Firm:
Skjerven Morrill LLP Klivans; Norman R.
Claims
We claim:
1. A graphic user interface adapted for interacting with a server, said server interacting with a second graphic user interface, comprising: (a) a virtual avatar object existing in a virtual environment, comprising an instance of an avatar class stored in a computer memory having: a plurality of gestures stored in said computer memory; and a gesture change command method stored in said computer memory; and (b) a virtual medium of exchange object comprising: an instance of a medium of exchange class caused to be created by said server, accrued according to a metric relating to participation in said virtual environment and stored in said computer memory having: a denomination; and a plurality of methods for utilizing said virtual medium of exchange object stored in said computer memory, each method being mediated by said server to effectuate a transaction involving said instance of said medium of exchange between said virtual avatar object of said graphic user interface and another virtual avatar object associated with said another graphic user interface.
2. A graphic user interface as in claim 1 wherein said instance of said avatar class further comprises: a plurality of storage slots.
3. A graphic user interface as in claim 2 wherein said plurality of storage slots includes a hand of said virtual avatar object.
4. A graphic user interface as in claim 3 wherein all of said plurality of storage slots except said hand are in a pocket of said virtual avatar object.
5. A graphic user interface in claim 2 wherein said plurality of storage slots includes slots in a pocket of said virtual avatar object.
6. A graphic user interface as in claim 5 wherein one of said slots in said pocket is reserved for a virtual token object.
7. A graphic user interface as in claim 5 wherein one of said slots in said pocket is reserved for a virtual head object.
8. A graphic user interface as in claim 1 wherein a set of said plurality of gestures are a plurality of moods.
9. A graphic user interface as in claim 1 wherein said instance of said medium of exchange object is a virtual token object that is an instance of a token class.
10. A graphic user interface as in claim 9 wherein said plurality of methods for utilizing said virtual medium of exchange object include token split methods.
11. A graphic user interface as in claim 9 wherein said plurality of methods for utilizing said virtual medium of exchange object include token get from container methods.
12. A graphic user interface as in claim 9 wherein said plurality of methods for utilizing said virtual medium of exchange object include token put in container methods.
13. A graphic user interface as in claim 9 wherein said plurality of methods for utilizing said virtual medium of exchange object include token put in pocket methods.
14. A graphic user interface as in claim 9 wherein said plurality of methods for utilizing said virtual medium of exchange object include token get from pocket methods.
15. A graphic user interface as in claim 1 further comprising: a virtual ATM object further comprising: an instance of an ATM class stored in a computer memory having: a plurality of methods for utilizing said virtual ATM object stored in said computer memory.
16. A graphic user interface as in claim 15 wherein said plurality of methods for utilizing said virtual ATM object include request balance methods.
17. A graphic user interface as in claim 15 wherein said plurality of methods for utilizing said virtual ATM object include deposit methods.
18. A graphic user interface as in claim 15 wherein said plurality of methods for utilizing said virtual ATM object include withdrawal methods.
19. A graphic user interface as in claim 1 further comprising: a virtual vendroid object further comprising: an instance of a vendroid class stored in a computer memory having: a plurality of virtual objects for sale; and a plurality of methods for operating said vendroid object stored in said computer memory.
20. A graphic user interface as in claim 1, wherein said metric comprises a length of time for which said virtual avatar object exists in said virtual enviroment.
21. A graphic user interface computer process for facilitating interactions among on-line users of a virtual world comprising: representing an on-line user of said virtual world with a virtual avatar object; including a plurality of gestures in said virtual avatar object; performing a gesture by said virtual avatar object upon selection of said gesture from a plurality of gestures by said on-line user; and providing a virtual medium of exchange object having: an instance of a medium of exchange class caused to be created by said graphic user interface computer process, accrued according to a metric relating to participation in said virtual world, and stored in a memory accessible by said graphic user interface computer process, said instance of a medium of exchange class having: a denomination; and a plurality of methods for utilizing said medium of exchange object stored in said memory, each method being mediated by a server computer process to effectuate a transaction involving said instance of said medium of exchange between said virtual avatar object and another virtual avatar object associated with another graphic user interface computer process.
22. A graphic user interface computer process for facilitating interactions among on-line users of a virtual world as in claim 21 further comprising: including a pocket having a plurality of slots in said virtual as in avatar object.
23. A graphic user interface computer process for facilitating interactions among on-line users of a virtual world as in claim 22 further comprising: representing said instance of said medium of exchange in of said virtual world by a virtual token object.
24. A graphic user interface computer process for facilitating interactions among on-line users of a virtual world as in claim 23 further comprising: representing a virtual machine object for dispensing said virtual token objects as a virtual ATM.
25. A graphic user interface computer process for facilitating interactions among on-line users of a virtual world as in claim 21, wherein said metric comprises a length
Description
APPENDIX A
Appendix A, which is a part of the present disclosure and is incorporated herein by reference in its entirety, is a listing of computer programs and related data for the client and server processes of this invention.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to communications between persons using computers and more particularly to communications and interactions among persons within a virtual community implemented on a computer network.
2. Description of Related Art
One of the more interesting things that people do is form communities, e.g., form collections of people with common interests and activities. The creation of computer mediated communication has created the potential for people to come together in new ways. Where before, humans met face to face in a common physical space, they now can congregate in cyberspace--the conceptual place created by on-line communication. Until recently, on-line communities were limited to relatively sparse, text only communications. Common activities were limited to discussion, or simple games that could handled by what in effect was an extension of the postal service.
Previous on-line services have been creation points for communities. In some cases, communities have developed despite the inherent difficulties of the medium. Other, more interesting activities that contribute to community building, were severely limited or difficult to conduct.
To enhance the community building process, more diverse activities must be enabled. One thing that has brought humans together in communities from the earliest times has been the market, a place to exchange goods and services, and also an excuse to get together for other activities. It may be argued that without an economic component, any community will be severely limited in its potential growth and complexity. Commerce is also enjoyable and contributes to perceived quality of life.
How can an on-line service provide a medium of exchange for a virtual community that is acceptable to all users of the service? How can an on-line service provide a medium of exchange that is easy to use so as to promote transactions between individuals in a spontaneous manner, but secure from counterfeiting or fraud? Further, how can a virtual community support transactions between individuals that are not subject to scrutiny or review by third parties?.
While credit cards have been used to conduct business on-line, credit cards are not appropriate for simple commerce between individuals. Few private individuals have bank accounts set up to accept credit card deposits. Further, when you do not know exactly who you are dealing with, you would hesitate to give your credit card number for a purchase.
Also, actual cash transactions may not be appropriate when the goods being purchased have no reality outside of the common virtual world. With the growth of on-line communities across national boundaries, how do individuals even agree on the medium of exchange? To the best knowledge of the inventors there is not an medium of exchange available in an on-line virtual world to promote the interesting activities that surround trade, and add to the potential complexity and interest of community activities. A solution to the many complexities associated with a medium of exchange has yet to found for on-line virtual worlds.
SUMMARY OF THE INVENTION
According to the principles of this invention, a graphic user interface is utilized to represent instances of various classes, that are virtual objects, which in turn provide users of the graphic user interface with a new dimension in communication. In the virtual world of this invention, an avatar object is a virtual container that includes a plurality of other containers, e.g., avatar hands and a pocket. Herein, a virtual container object, as its name suggests, can hold one or more other virtual objects.
The avatar object is not only a container, but also includes other characteristics that allow the avatar object to express moods and perform gestures. The avatar object is represented in the graphic user interface as a computer based animation that has a body and a removable head. The avatar object can move,
e.g., walk, through the various locales in the virtual world with or without a head.
One avatar can talk to the other avatars in the same locale. In this case, the on-line user represented by the avatar enters a message, and the message in displayed in a balloon that is visible to each of the other avatars in the locale. Thus, any other avatar in the locale can read the message. Alternatively, for a private communication, the on-line user, represented by the avatar, can use ESP to communicate privately with another avatar in the same locale, or in any other locale in the virtual world.
Portable virtual objects that can be stored in either the hands or the pocket of the avatar include spare heads for avatar, a token object that represents one or more tokens, and other portable virtual objects that are available within the virtual world. These portable virtual objects include portable virtual container objects that in turn can store other portable virtual objects.
Herein, all of the objects and avatars are virtual which means that they exist only in terms of the computer processes used to generate the virtual world. Thus, even though the word virtual is not always used in describing an object or avatar, it is understood that the object or avatar is always virtual.
An avatar is controlled through use of data input devices, e.g., a keyboard and mouse, for an on-line user's computer in combination with information and actions presented on the computer display screen. The on-line user's computer executes client processes associated with the on-line user that in turn send and receive messages from other client processes on that on-line user's computer as well as from server processes executing on a server computer of a service provider over a network such as the Internet.
In this embodiment, the various actions that an on-line user can take through her avatar, are presented in the graphic user interface via pop-up menus. When the on-line user selects an object displayed in the graphic user interface using one or more of the computer's data input devices, a pop-menu for the selected object is displayed.
Each virtual object is aware of its surroundings and changes its behavior to suit the situation. For example, selecting a floor object of a locale presents a pop-up menu with choices such as Walk to here; Go this way; and Go that way, if the avatar is not holding a portable virtual object in his hand. However, if the avatar is holding a portable virtual object in his hand, there is an additional menu choice of Put here. This is because the floor object checks to see if the avatar is holding a portable virtual object that can placed, e.g., put or dropped, at the selected point on the floor object.
Token objects in the graphic user interface are a medium of exchange within the virtual world of this invention. The value of a token object is determined by the denomination of the token object. While each token object is shown as a single object, each token object can represent one or more tokens based on the denomination.
Token objects can be exchanged freely while in the virtual world, but token objects are not tied to any real world currency. To prevent counterfeiting, all token object creation is controlled by a one of the server processes executing on the server computer maintained by the service provider. On-line users cannot freely create new tokens.
A token object can be carried, deposited in a virtual ATM object, deposited in virtual vending machine, used to purchase portable virtual objects from machines or shops, or given to other avatars. A token can also be dropped, taken, or stored in a container. When tokens are paid, the client process performs an internal operation called "split" where the value of the token in the hand of the avatar, or in the pocket of the avatar is divided between what to pay and what goes back into his hand, or pocket. The split operation typically leaves a token of the denomination required for the transaction in the hand of avatar.
In one embodiment of the split operation, the avatar places the token in his pocket. A client process and server process communicate and determine whether there are sufficient tokens in the pocket to complete the transaction. If there are sufficient tokens, the avatar withdraws his hand from his pocket holding a token of the required denomination. In this case, the server process notifies a client process in each of the other on-line users that are in the same locale, and that client process plays an animation that shows the split being made. If there are insufficient tokens, a message is displayed informing the avatar and the avatar's hand is removed from his pocket.
Exchange of token objects or any other portable virtual objects can be mediated by one of the server processes, and so theft or fraud are difficult. However, approval for transactions between avatars is not controlled by the server processes, or by service provider. On-line users are free to transact exchanges of either tokens or other portable virtual objects through their respective avatars without needing the approval or intervention of the service provider.
Token objects can be exchanged for other portable virtual objects using virtual vending machine objects. Virtual vending machine objects are another unique feature of the graphic user interface of this invention. Each of these virtual vending machines displays portable virtual objects for sale.
When an avatar chooses a purchase from a virtual vending machine by selecting an entry in a pop-up menu of the graphical user interface using the data input devices, the virtual vending machine, in one embodiment, takes a token object directly from the avatar's hand and places the purchase directly into the avatar's hand. Virtual vending machine objects perform any required token splits, if the denomination of the token object in the avatar's hand is more than the purchase price, and puts a token object for the outstanding balance into avatar's pocket when delivering the purchased object. The token is put in the avatar's pocket, because at any instant only one virtual portable object can be in the avatar's hands.
At all times, the avatar has direct control over the portable virtual object in his hand, or on his head. Thus, theft by grabbing from the hand of avatar or head is not possible.
Token objects are placed in circulation by virtual ATM objects, that is an instance of an ATM class. A token object is an instance of a token class. A virtual ATM object, another novel feature of the graphic user interface of this invention, allows a user to obtain a balance, deposit tokens, and withdraw tokens.
When an avatar interacts with a virtual ATM object, the bank balance of the avatar is updated. When the avatar requests a withdrawal, the ATM object gives the avatar a token object valued at the withdrawal amount selected by the avatar.
Prior to a deposit, or at any time the avatar has a token in his hand, the token object can be split into two token objects whose total value equal the value of the original token object, as described above. All token object creation or splits are mediated by a server process on the server computer to prevent creation of fake token objects.
Token objects can be exchanged with other on-line users for goods or services, given as gifts, or left lying around, like dropped cash. Unlike cash, token objects can not be taken by another avatar without the consent of the avatar holding the token object. However, any avatar is free to get a token object lying on the ground.
In general, one avatar can not take a portable virtual object from a hand of another avatar. However, if one avatar can convince another avatar to place the portable object on the ground, for example, the avatar can get the object from the ground without the consent of the other avatar. Thus, like the real world, thievery and/or cons are possible in the virtual world of this invention, with the exception that a virtual object can not be take from the hand of an avatar.
The avatars, virtual token objects, virtual ATMs, and virtual vending machines, as indicated above are implemented using object-orientated concepts, in this embodiment. Thus, each object is an instance of a class and typically is stored in a structure within a memory of the on-line user's computer for access by client processes, and within a memory of the server computer for access by server processes. Each instance of the class is represented by its own structure in the computer memory that contains data for the virtual object in the virtual world.
The token structures, ATM structures, vendroid structures, and the avatar structure with a pocket and a hand container create unique features in the virtual world that make the virtual world a more realistic and enjoyable place for on-line users to communicate. The ability to trade, purchase, get, and put the portable virtual objects stored in these structures allows an economic component, i.e., a new dimension of communication to exist in the virtual world that was not previously available.
As indicated above an avatar can walk, communicate with another avatar via talk, think, and ESP processes, and can also pick up, put down and use certain objects, use machines, and change its appearance. The avatar also has different moods and gestures. The mood of the avatar is selectable by the user at any time. The avatar starts in the world in the neutral mood, e.g., a happy mood. The mood changes are modal--the selected mood remains on the avatar's face until the mood is changed by the user. In this embodiment, the plurality of moods includes neutral, mad, sad, and glad.
As explained above, each locale in the virtual world can accommodate a predefined number of avatars. However, in addition to the avatars in a locale, a locale can support essentially an unlimited number of lurkers. Lurkers, while they do not actively contribute to the discussion in real time, do change the dynamic of on-line communities by causing the simplest exchanges between individuals to exist in a public space. While participants can choose to take any discussion to a private venue, such as in e-mail or off-line, the relative invisibility of lurking can cause it to be forgotten.
One opportunity that the graphical user interface of this invention provides is to visually represent lurkers to provide a reminder that participants other than the active ones are "listening in". In the virtual world of this invention, a lurker is represented in a locale by a ghost object. An icon is present, i.e, an eye-the-sky, in a locale, whenever a ghost object, or ghost objects are present.
Ghost objects have anonymity, i.e. their names are not known to avatars of the locale, and have limited interaction choices. A ghost object cannot talk or think to other avatars. A ghost object retains the ability to transmit private "ESP" messages to other avatars.
A ghost object also enables other important capabilities. To promote personal, one-on-one type relationships which encourage a sense of community, most locales have limits to the number of avatars that can be physically present at one time. This also prevents over-crowding of the visual interface. In addition, limiting the number of active avatars in a locale assures that the performance of the client computers is not slowed down by having to receive notice messages to update the status of more than a reasonable number of active avatars. Thus, the ghost object permits any number of on-line users in a locale without degrading either the visual interface, or the computer performance.
While this limitation is important to the social dynamic, and necessary to prevent a mob scene from overloading the visual interface, it would be frustrating to completely prevent new users from entering a full locale, i.e., a locale that contained the maximum number allowed of physical avatar objects. An avatar entering a full locale automatically becomes a ghost in the locale, and may then choose to remain and observe the activity occurring. When the number of materialized avatars drops below the limit, a ghost may choose to join in as a materialized, physical avatar in the locale, or to remain as a ghost and continue to lurk.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a graphic user interface of one locale in the virtual world that includes a vendroid object of this invention, and an avatar holding a token object of this invention.
FIG. 2 is a diagram of the apparatus used by the on-line users to execute the client processes that generate the memory structures and graphic user interfaces of this invention, and to select options presented in the graphic user interface, as well as the network over which the client processes send and receive messages from a server computer executing the server processes of this invention.
FIG. 3A is a graphic user interface of another locale in the virtual world that includes an ATM object of this invention, and an avatar of this invention.
FIG. 3B show the graphic user interface of FIG. 3A when the avatar has dematerialized into a ghost icon.
FIG. 4A illustrates a pop-up menu in the graphic user interface when the on-line user points at the avatar.
FIG. 4B illustrates a right pull menu in the graphic user interface when the on-line user points at menu item Gesture in the pop-up menu of FIG. 4A.
FIG. 4C illustrates a right pull menu in the graphic user interface when the on-line user points at menu item Turn in the pop-up menu of FIG. 4A.
FIG. 4D illustrates a right pull menu in the graphic user interface when the on-line user points at menu item Get from Pocket in the pop-up menu of FIG. 4A.
FIG. 4E illustrates a right pull menu in the graphic user interface when the on-line user points at menu item Status in the pop-up menu of FIG. 4A.
FIG. 4F illustrates a right pull menu in the graphic user interface when the on-line user points at menu item Become a Ghost in the pop-up menu of FIG. 4A.
FIG. 4G illustrates an avatar, in yet another locale, that is not adjacent to a container object.
FIG. 4H illustrates a pop-up menu that is generated when the avatar is not adjacent to a container object and the container object is pointed at by the on-line user.
FIG. 4I illustrates the position of the avatar after the on-line user selects menu item Walk to in the pop-up menu of 4H after the animation used to move the avatar is completed.
FIG. 4J illustrates a pop-up menu that is generated when the avatar is adjacent to an open container object and the open container object is pointed at by the on-line user.
FIG. 4K illustrates the graphic user interface after the user selects tokens in the menu of FIG. 4J and the operations to get the tokens from the container have been completed.
FIG. 5A is process flow diagram for one embodiment of a client mood change command method of this invention.
FIG. 5B is process flow diagram for one embodiment of a server mood change perform method of this invention.
FIG. 6A is a process flow diagram for one embodiment of a client pocket get command method of this invention.
FIG. 6B is a process flow diagram for one embodiment of a server get object command method of this invention.
FIG. 7A is the graphic user interface of FIG. 3A with the avatar holding a token object of this invention.
FIG. 7B is illustrates a pop-up menu that is generated in the graphic user interface of FIG. 7A when the token object is pointed at.
FIG. 7C is a dialogue box that is displayed when the user selects menu item Split in the pop-up menu of FIG. 7B.
FIG. 7D illustrates a menu that is generated in the graphic user interface of FIG. 7A after the token split operations are completed and the token object is pointed at.
FIG. 8 are client and server process flow diagrams for one embodiment of the token split operation of this invention.
FIG. 9A is an illustration of a pop-up menu in the graphic user interface of FIG. 3A that is generated when the avatar is not adjacent to the ATM and the on-line user points at the ATM object.
FIG. 9B illustrates the on-line user pointing at menu item Request Balance in the pop-up menu of FIG. 9A.
FIG. 9C illustrates the position of the avatar after the selection of the menu item in FIG. 9B and the avatar has walked to and faced the ATM object.
FIG. 9D illustrates the position of the avatar and the message provided when the request balance operations are completed.
FIG. 9E illustrates the on-line user pointing at menu item Withdraw Tokens in the pop-up menu of FIG. 9A and the resulting right-pull pop-up menu that is generated.
FIG. 9F illustrates the graphic user interface after avatar has withdrawn tokens and so is holding a token, and the on-line user points at menu item Deposit in the pop-up menu of FIG. 9A.
FIG. 9G illustrates the dialogue box that appears in the graphic user interface after selection of menu item Deposit in the pop-up menu of FIG. 9A.
FIG. 9H illustrates the graphic user interface after avatar has turned deposited the token and then returned to the original position, and the message showing the number of tokens deposited.
FIG. 10 illustrates a pop-up menu that is generated in the graphic user interface of FIG. 1, when the on-line user points at the vendroid object.
FIG. 11A is an illustration of one locale in the graphic user interface when the avatar enters as a ghost.
FIG. 11B is an illustration of a pop-up menu that is generated in the graphic user interface of FIG. 11A when the avatar of the on-line user is a ghost.
FIG. 11C illustrates pointing at menu item Tell me about in the pop-up menu of FIG. 11B.
FIG. 11D illustrates the graphic user interface and the message generated by selection of menu item Tell me about in the pop-up menu of FIG. 11B.
FIG. 11E illustrates pointing at menu item Become an Avatar in the pop-up menu of FIG. 11B.
FIG. 11F illustrates the graphic user interface following selection of menu item Become an Avatar in the pop-up menu of FIG. 11B after the operations are completed.
FIG. 11G illustrates the pop-up menu that is generated in the graphic user interface when the avatar is pointed at.
FIG. 11H illustrates the right pull menu that is generated in the graphic user interface when the on-line user is pointing at menu item Status in the pop-up menu of FIG. 11B and is a ghost.
FIG. 11I illustrates a pop-up menu that is generated in the graphic user interface when the on-line user is pointing at loose object in the locale and the avatar of the on-line user is a ghost.
FIG. 11J illustrates a pop-up menu that is generated in the graphic user interface when the on-line user is pointing at a feature in the locale and the avatar of the on-line user is a ghost.
FIG. 11K illustrates that a ghost can go to another locale by using the menu item Go this way in the pop-up menu of FIG. 11I.
FIGS. 12A to 12D illustrate the different types of communication in the graphical user interface of this invention. FIG. 12A illustrates an avatar talking. FIG. 12B illustrates an avatar thinking. FIGS. 12C and 12D illustrate an avatar using ESP (extrasensory perception).
DETAILED DESCRIPTION
The on-line community of this invention, i.e, a virtual world computer process, herein after referred to as "the virtual world", includes portable virtual token objects that can be used by on-line users of the world to facilitate exchange of goods and services within the virtual world. In particular, client-server computer processes are provided for the virtual world that allow on-line users to conduct activities within the virtual world including getting, putting, giving, and receiving portable virtual token objects as well as other portable virtual objects. These operations facilitate development of commerce that is enjoyable and contributes to perceived quality of life within the virtual world relative to the prior art virtual worlds that limited the on-line users to discussion or playing simple games.
In this embodiment, each on-line user is represented in the graphic user interface of this invention by an avatar object, such as avatar 100 (FIG. 1). FIG. 1 is representation of a screen display for locale V-Mart 150 of the virtual world of this invention. For clarity, only a single avatar object 100 is illustrated in FIG. 1. However, each locale in the virtual world can accommodate a maximum predefined number of avatars that are physically present in the locale.
Herein, while only a single avatar object 100 is illustrated in the Figures for convenience, interactions between two or more avatar objects within a locale are also described. The addition of one or more avatars to a Figure is not required to understand the principles of this invention and the operation of the graphic user interface.
One avatar can talk to the other avatars in the same locale in the graphic user interface. In this case, the on-line user represented by avatar 100 enters a message, and the message in displayed in region 140 in a balloon that is visible to each of the other avatars in the locale. Thus, any other avatar in the locale can read the message. Alternatively, for a private communication, the on-line user, represented by avatar 100, can use ESP to communicate privately with another avatar in the same locale, or in any other locale in the virtual world and in this instance, only the graphic user interface for the other avatar displays the message.
Avatar object 100, usually called avatar 100, is a computer-based animation and is an instance of an avatar class. Avatar 100 of this invention includes a pocket 105 to store portable virtual objects owned by avatar 100. The portable virtual objects that can be stored in pocket 105 include spare heads for avatar 100, a token object 110 that represents one or more tokens, and other portable virtual objects that are available within the virtual world. These portable virtual objects include container objects that in turn can store other portable virtual objects.
Herein, all of the objects and avatars are virtual which means that they exist only in terms of the computer processes used to generate the virtual world. Thus, even though the word virtual is not always used in describing an object or an avatar, it is understood that the object or avatar is virtual.
Avatar 100 is controlled through use of data input devices, e.g., keyboard 201-1 and mouse 202-1, for an on-line user's computer 200-1 in combination with information and actions presented in display screen 250 of display device 210-1. Computer
200-1 executes client processes 220-1 associated with the on-line user that in turn send and receive messages from other client processes on computer 200-1 as well as from server processes 250 executing on a server computer 260 of a service provider 270
over a network 280.
The client side components of a virtual object are stored as resources. Each resource can be updated by a download from server computer 260, when service provider 270 changes or adds resources for a virtual object. Resources are organized and maintained by a resource manager on client computer 200-i, that acts as a database for the client. The resource manager is not an essential feature of this invention and is not needed to understand the virtual objects described more completely herein that are a novel features of the graphic user interface. Also, as those of skill in the art will appreciate, there is an engine on client computer 200-i that coordinates the interactions between the various methods described herein, and the signals required by, and received from the hardware of client computer 200-i.
As explained more completely below, typically, an on-line user 225-1 moves a cursor(not shown) on display screen 250-1 using mouse 202-1. Alternatively, arrow keys, or some combination of keys on keyboard 201-1 could be used. In either case, the data input device generates a signal representing an x-y coordinate position. A process executing on computer 220-1 captures the x-y coordinate position signal and translates the signal to a position on display screen 250-1 where the cursor is displayed, or alternatively a menu item is highlighted. Through manipulation of the data input device, the user points at avatar 100 or another object in locale 150 such as vending machine object 120, door object 151, or perhaps floor object 152 by placing the cursor on the object.
Typically, a user selects an object by placing a cursor on the virtual object, and then depressing a key on mouse 202-2, or alternatively, depressing a key or combination of keys on keyboard 201-2. Typically, when a virtual object is selected, information associated with that virtual object is displayed on display screen 250-1. In most cases, the information is a menu of options or actions associated with the object. The use of a mouse, a keyboard, or other data input device to point at an object, to select an object, to make menu selections, or to enter data is well-known to those of skill in the art and so is not described further.
As illustrated in FIG. 2, a plurality of n on-line users communicate with server computer 260 over network 280. Server computer 260 maintains an object data base that stores values that determine the state and location of a particular virtual object instance.
The particular configuration of network 280 and the physical transfer of messages of over network 280 are not an essential feature of this invention. In view of this invention, the various processes and object classes can be implemented in a wide variety of client-server configurations over a variety of different network configurations. For an IBM PC compatible computer with an Intel 80486 microprocessor, an Intel Pentium microprocessor, or an equivalent microprocessor, the client software of this invention typically runs under one of the Microsoft Windows interfaces, e.g., Windows 3.11 or Windows 95, in combination with the DOS operating system. A typical server computer is a Sun MicroSystems of Mountain View, Ca, Sun SparcCenter 2000 or equivalent running with a Sun Microsystems Sun Solaris 2.4 or later operating system, that is sometimes called the Sun OS 5.4 operating system.
The virtual world is made up of a collection of objects that are instances of programming code, images, sounds or other data that are packaged and presented to on-line users 225-1 to 225-n as a single virtual world. On-line user 225-1, where i represents any one of 1, 2, . . . , n, through her avatar can pick up, carry, and manipulate the portable virtual objects in the virtual world. Virtual objects are persistent, i.e., the objects stay in the virtual world between on-line sessions, and have consistent behavior.
Each virtual object is aware of its surroundings and changes its behavior to suit the situation. For example, selecting floor object 130 of V-Mart locale 150 presents a pop-up menu with choices such as Walk to here; Go this way; and Go that way, if avatar 100 is not holding a portable virtual object in his hand. However, if avatar 100 is holding a portable virtual object in his hand, there is an additional menu choice of Put here. This is because floor object 130 checks to see if avatar 100 is holding a portable virtual object that can placed, i.e., put, at the selected point on floor object 130.
Token objects, e.g., token object 110, are a medium of exchange within the virtual world of this invention, as explained more completely below. The value of token object 110 is determined by the denomination of token object 110. While each token object is shown as a single object, each token object can represent one or more tokens based on the denomination.
Token objects can be exchanged freely while in the virtual world, but token objects are not tied to any real world currency. To prevent counterfeiting, all token object creation is controlled by a one of server processes 250 (FIG. 2) executing on server computer 260 maintained by service provider 270. On-line users 225-1 to 225-n cannot freely create new tokens.
Token object 110, sometimes referred to as token 110 or tokens 110, can be carried, deposited in virtual ATM object 320 (FIG. 3A), deposited in virtual vending machine 120 (FIG. 1), used to purchase portable virtual objects from machines or shops, or given to other avatars. Token 110 can also be dropped, taken, or stored in a container. When tokens are paid, the client process performs an internal operation called "split" where the value of token 110 in the hand of avatar 100, or in pocket 105 of avatar is divided between what to pay and what goes back into his hand, or pocket 105. The split operation typically leaves a token of the denomination required for the transaction in the hand of avatar 100.
Exchange of token objects or any other portable virtual objects can be mediated by one of server processes 250, and so theft or fraud are difficult. However, approval for transactions between avatars is not controlled by server processes 250 or by service provider 270. On-line users 225-1 to 225-n are free to transact exchanges of either tokens or other portable virtual objects through their respective avatars without needing the approval or intervention of service provider 270.
Token object 110 can be exchanged for other portable virtual objects using virtual vending machine objects. Each of these virtual vending machines display portable virtual objects for sale. For example, gift virtual vending machine object 120
is an instance of a vendroid class of this invention. Gift virtual vending machine object 120 distributes a virtual gift object, e.g., virtual gift object 121 in exchange for deposit of a token object of a specified denomination.
As explained more completely below, when avatar 100 chooses a purchase from virtual gift vending machine 120 using the data input devices, virtual gift vending machine 120 takes a token object 105 directly from the avatar's hand and places the purchase directly into the avatar's hand. Virtual vending machine objects perform any required token splits, if the denomination of token object 110 in the avatar's hand is more than the purchase price, and puts a taken object for the outstanding balance into avatar's pocket 105 when delivering the purchased object. At all times, avatar 100 has direct control over the portable virtual object in his hand, and so theft by grabbing from the hand of avatar 100 is not possible.
One of server processes 250 maintains a bank balance for avatar 100, and for all other avatars in the virtual world. The back balance for avatar 100 is stored only on server computer 260 and is only available to avatar 100.
Token objects are removed from the bank and put into circulation by virtual ATM object 320, that is an instance of an ATM class. A token object is an instance of a token class. Virtual ATM object 320 allows a user to obtain a balance, deposit tokens, and withdraw tokens, as explained more completely below. When avatar 100 interacts with virtual ATM object 320, the bank balance of avatar 100 is updated. When avatar 100 requests a withdrawal, ATM object 320 gives avatar 100 a token object valued at the withdrawal amount selected by avatar 100.
Prior to a deposit, or at any time avatar has a token in his hand, token object 110 can be split into two token objects whose total value equal the value of the original token object. In the embodiment, described more completely below, to split a token, avatar 100 places the token in pocket 105, and subsequently retrieves a token of the desired denomination from pocket 105. All token object creation or splits are mediated by a server process on computer 260 to prevent creation of fake token objects.
Token objects can be exchanged with other on-line users for goods or services, given as gifts, or left lying around, like dropped cash. Unlike cash, token objects can not be taken by another avatar without the consent of the avatar holding the token object. However, any avatar is free to get a token object lying on the ground.
In general, one avatar object can not take a portable virtual object from a hand of another avatar object. However, if one avatar object can convince another avatar object to place the portable object on floor 130 (FIG. 1), for example, the avatar can get the object from the floor without the consent of the other avatar. Thus, like the real world, thievery and/or cons are possible in the virtual world of this invention, with the exception that a virtual object can not be take from the hand of an avatar.
In this embodiment, avatar 100 accrues tokens according to on-line connect time of on-line user 225-1, i.e. the on-line user 225-1 is paid to be in the virtual world. This use of connect time to generate base income promotes community building by giving on-line user 225-1 an incentive to be in the virtual world. While in the virtual world, interaction with the other avatars helps to create community. By providing token objects, the richness and complexity of interaction is enhanced.
When on-line user 225-1 enters the virtual world of this invention, the time of initial connection is recorded in the instance of the user's avatar data on server computer 260. As indicated above, the bank balance of avatar 100 is queried by using an ATM object 320 in a virtual world west fountain locale 350 (FIG. 3A). In response to the query by avatar 100, an ATM balance client process in client processes 220-1 sends an ATM balance request message to a server process in server processes
250.
In response to the request message, the server process calculates the number of tokens to add to the bank balance of avatar 100 by subtracting the time of initial connection from the current time and giving one token per defined unit, e.g., five minutes, of the connect time. The new bank balance is stored on the server, and the initial connect time information is changed to the balance request time so that only new connect time is included in future transactions.
The server process sends the updated balance in a reply message to the client process, that in turn displays the bank balance to avatar 100. The server process also sends a notice message to any other on-line user that has an avatar in the same locale as avatar 100. The notice message launches a client notify process on the computer of the other on-line users that shows avatar 100 using ATM object 320. However, these client processes do not receive the bank balance of avatar 100.
The bank balance is also updated at the time the on-line user disconnects from server computer 260 to add tokens accumulated during the preceding connect session. When the user returns to the world, this updated bank balance is available for query.
The avatars, virtual token objects, virtual ATMs, and virtual vending machines, as indicated above are implemented using object-orientated concepts, in this embodiment. Thus, each object is an instance of a class and typically is stored in a memory of the on-line user's computer 200-i for access by client processes, and in a server computer 250 for access by server processes. The specific embodiment of these objects that is described more completely below is illustrative only and is not intended to limit the invention to classes that include the particular attributes and methods described below.
In the virtual word computer process of this invention, an avatar 100 is an animated two-dimensional graphical character that represents an on-line user. Avatar 100 can walk, communicate with another avatar via talk, think, and ESP processes, pick up, put down and use certain objects, use machines, and change its appearance. Avatar 100 also has different moods and gestures.
The interactions between avatars includes the ability to conduct economic transactions. In this embodiment, avatar 100 communicates via a communication bubble on screen display 150. However, as audio communications improve over networks such as the Internet, some level of audio communications could be added.
Avatar 100 can also change or enhance its appearance by using a body changer machine to transform the body of avatar 100 to another one of the available body types. At any given instant, avatar 100 can have only a single body. In contrast, avatar 100 can possess any number of heads, but only one head at a time can be mounted on the body, i.e., worn. Avatar 100 must purchase the heads from a virtual head vending machine object, or obtain the head from another avatar. In this embodiment, an avatar starts in the virtual world with a female gender and a neutral mood. However, on-line user 225-1 selects a gender of avatar 100 and one of three body styles, average, athletic, and chubby, for that gender. The body style can be changed at any time by using the body changer machine.
The mood of the avatar is selectable by the user at any time. The avatar starts in the world in the neutral mood, e.g., a happy mood. The mood changes are modal--the selected mood remains on the avatar's face until the mood is changed by the user. In this embodiment, the plurality of moods includes neutral, mad, sad, and glad.
In general, the computer processes used to implement this invention are independent from the pictures retrieved by the computer processes for the animations associated with the various gestures and actions of avatar, and associated with other objects in the virtual world. This permits changing the visual characteristics displayed in the graphic user interface without making changes to the computer methods described herein.
As explained above, each locale in the virtual world can accommodate a predefined number of avatars. However, in addition to the avatars in a locale, a locale can support essentially an unlimited number of lurkers.
One aspect of text-based on-line community environments, such as newsgroups or chatrooms, is the potential for some participants to `listen` to the discussion, without contributing. This phenomena is so prevalent, it has been given its own term--"lurking". Lurkers, while they do not actively contribute to the discussion in real time, do change the dynamic of on-line communities by causing the simplest exchanges between individuals to exist in a public space. While participants can choose to take any discussion to a private venue, such as in e-mail or off-line, the relative invisibility of lurking can cause it to be forgotten;
One opportunity that the graphical user interface of this invention provides is to visually represent lurkers to provide a reminder that participants other than the active ones are "listening in". In the virtual world of this invention, a lurker is represented in a locale by a ghost object. An icon is present, i.e, an eye-the-sky 380 (FIG. 3B), in a locale, such as locale 350, whenever a ghost object, or ghost objects are present.
Ghost objects have anonymity, i.e. their names are not known to avatars of the locale, and have limited interaction choices. A ghost object cannot talk or think to other avatars. A ghost object retains the ability to transmit private "ESP" messages to other avatars.
Ghost object 380 also enables other important capabilities. To promote personal, one on one type relationships which encourage a sense of community, most locales have limits to the number of avatars that can be physically present at one time. This also prevents over-crowding of the visual interface. While this limitation is important to the social dynamic, and necessary to prevent a mob scene from overloading the visual interface, it would be frustrating to completely prevent new users from entering a full locale, i.e., a locale that contained the maximum number allowed of physical avatar objects. An avatar entering a full locale automatically becomes a ghost in the locale, and may then choose to remain and observe the activity occurring. When the number of materialized avatars drops below the limit, a ghost may choose to join in as a materialized, physical avatar in the locale, or to remain as a ghost and continue to lurk.
Another aspect of interpersonal relationships in the virtual world community is that one participant may become uncomfortable with the attention another person is giving them. Harassing behavior should not force the target of the harassment to abandon or flee the locale for relief. By allowing an avatar to become a ghost, the on-line user may continue to participate, albeit in a limited way, while using ESP to request aid in dealing with the harassment. A ghost may also move from locale to locale while maintaining anonymity, so as to "lose" the harasser. The characteristics of ghost object 380 are described more completely below.
In this embodiment, when on-line user 225-1 points at avatar 100 (FIG. 4A) using mouse 202-1, and then depresses the left mouse button, a signal is generated by mouse 202-1 that is interpreted by a client process executing in computer 200-1 that builds menu 401. In this embodiment, menu 401 lists seven options that are available to on-line user 225-1. The options are given in Table 1.
TABLE 1 Menu When Pointing at Avatar with Hands Empty <Avatar Name> Gesture > Turn > Get From Pocket > Remove Status > Become a Ghost Tell Me About. . .
Thus, in the embodiment of FIG. 4A, the name of avatar 100 is yahooooo. Menu items Gesture, Turn, Get From Pocket, and Status each include a right pointing marker, which mean that if on-line user 225-1 points at the menu item, a menu is generated to the right of menu 401, that is called a pull right menu.
In menu 401, menu item Get From Pocket is displayed only when avatar 100 has one or more objects in pocket 105 and nothing in his hand. If avatar 100 has an object in his hand, menu item Get From Pocket is replaced with menu item Put In(not shown). Menu item Put in also has a right pointing marker. Upon pointing at selection of menu item Put In, a right-pull menu is generated that lists pocket 105 and any containers stored in pocket 105 in which avatar 100 can place the object in his hand. Menu item Remove is displayed only when avatar 100 is wearing a head.
When on-line user 225-1 moves the mouse to point at menu item Gesture with the mouse button depressed, a second menu 402 is displayed, as illustrated in FIG. 4B, that was generated by the client menu process. If the on-line user 225-1 releases the mouse button while the cursor is pointing at menu item Gesture, no action is taken and the pop-up menu is dismissed. Conversely if on-line user 225-1 points at one of the items in menu 402 and releases the mouse button, the selected gesture is implemented, as described more completely below.
Menu 402 includes ten options as listed in Table 2.
TABLE 2 Gesture Pull-Right Menu Normal Happy Sad Mad Wave Bow Shrug Present Jump React
Notice that each menu item in menu 402 also includes an icon that graphically represents the gesture for that icon. In this embodiment, on-line user 225-1 selects a particular gesture by either selecting the corresponding menu item, or by pressing the function key of keyboard 201-1 that is listed at the right of the menu item. Thus, gestures are actions that are initiated by the user via a function key or the gesture pull-right menu. The purpose of gestures is to allow avatar 100 to express feelings and emotions in a graphical manner that is visible to other avatars in the locale.
Thus, in this embodiment, to change the mood of avatar 100, on-line user 225-1, points at avatar 100 and manipulates mouse 202-1 so that menus 401 and 402 are displayed. On-line user 225-1 selects a menu item, or alternatively points at avatar
100 and presses one of function keys F3 to F5.
Computer 220-1 interprets the signal generated by the menu selection, and provides an signal to the client menu process that generated menu 402 to indicate the menu item selected. In response to the signal, the client menu process launches a client mood change method 500 (FIG. 5A) with the selected mood as an argument. A similar operation is performed when the function key is pressed.
In client mood change method 500 (FIG. 5A), set mood process 501 initializes mood to the mood specified as the argument in the command. Set mood process 501 transfers processing to transmit request process 502.
Transmit request process 502 sends an avatar change mood request message to server computer 260 for avatar 100, and requests a standard reply message. The avatar change mood request message includes mood as an argument. Process 502 transfers processing to reply message check 503 that in turn waits for a reply message from server computer 260.
In response to the avatar change mood request message from method 500, that is executing as a client process on computer 200-1, server computer 260 launches avatar change mood perform method 550 (FIG. 5B) as a server process. In initialize reply message operation 551, a success field in the reply message is set to failure. Operation 551 transfers to ghost check 552.
If avatar 100 is currently a ghost, as explained more completely below, ghost check 552 transfers to send reply process 563 because ghosts can not change moods, and otherwise to object is actor check 553. If the object pointed at is not avatar
100, i.e, the avatar representing the on-line user, check 553 transfer processing transfer to send reply process 563 and otherwise to avatar frozen check 554. Check 553 assures that only on-line user 225-1 can change the mode of avatar 100.
In this embodiment, the instance of avatar 100 on server computer 260 includes a permission flags field (perm.sub.13 flags in Table 33). One embodiment of the permission flags is defined in Table 3.
TABLE 3 Avatar Permission Flags Flag Permission when flag is set. AVATAR_PERM_FIDDLE Use fiddle wand. AVATAR_PERM_PROMOTE Promote/demote other avatars. AVATAR_PERM_MUTE Forbidden to speak, think, or ESP. AVATAR_PERM_FREEZE Forbidden to move, gesture, exit, etc.
Avatar frozen check 554 determines the state of avatar permission flag AVATAR_PERM_FREEZE in the permission flags field for the instance of avatar 100 on server computer 260. If avatar permission flag AVATAR_PERM_FREEZE is set, check 554
transfers to freeze period over check 555, and otherwise to valid mood check 560.
Freeze period over check 555 determines whether the current date and time is greater than the entry in field freeze_until_date (See Table 33.) in the instance of avatar 100 on server computer 260. If the current date and time is less than, or equal to the entry in field freeze_until_date, check 555 transfers processing to generate frozen reply message process 556, and otherwise to unfreeze avatar process 557.
If avatar 100 is still frozen, generate frozen reply message process 556 fills a character message buffer with a message indicating how much longer avatar 100 will remain frozen. Process 556 then sets the success field in the reply message to FAILURE_MESSAGE to indicate that the reply message includes a failure message, and sets the failure message field in the rely message to the character message buffer. Process 556 transfers processing to send reply process 563.
If the current time is after the time specified for avatar 100 to remain frozen, unfreeze operation 557 generates a notice message that avatar 100 is unfrozen, sets field freeze_until_date to zero, and clears avatar permission flag AVATAR_PERM_FREEZE. Unfreeze operation 557 sends a message to server 260, to on-line user computer 220-1 and to each other on-line computer that includes an instance of avatar 100, i.e., is displaying avatar 100, so that the instance of avatar 100 is updated on each of the computers to indicate that avatar 100 is no longer frozen. Unfreeze operation transfers processing to valid mood check 560.
Herein, checks 554 and 555, and operations 556 and 557 are a specific embodiment of a gesture prohibited check 558. In general, a check equivalent to gesture prohibited check 558 is performed by a server method of avatar object 100 for each gesture controlled by avatar permission flag AVATAR_PERM_FREEZE prior to the server method determining whether the avatar gesture perform command is valid.
Valid mood check 560 determines whether the mood sent to method 550 is any one of the plurality of moods HAPPY, GLAD, SAD, and MAD. If the mood is one of the allowed moods, check 560 transfers to generate success message operation 562 and otherwise to generate failure message operation 561.
Generate success message operation 562 sets the success field in the reply message to SUCCESS. Operation 562 also sets an actor activity to the mood sent to method 550, and transfers to send reply message process 563. Generate failure message operation 561 sets the success field in the reply message to FAILURE and transfers to send reply message process 563.
Send reply message 563 transmits the reply message to client mood change method 500 and transfers processing to success check 564. Success check 564 determines whether the success field in the reply message was set to SUCCESS. If the success field was set to SUCCESS, check 563 transfers to update neighbors operations 565 and otherwise to done operation 566.
Update neighbors operations 565 first declares a avatar change mood notice message as a notice message and then initiates generation of the notice message. The mood field of the notice message is set to mood and the message is sent to each on-line user that has an avatar in the same locale as avatar 100 with the identification number of the avatar for which the notice message applies. Operation 565 transfers to done operation 556.
In response to the notice message from server computer 260, each notified on-line computer 200-i that is displaying avatar 100 launches an avatar change mood notify method. This method first changes the animation of the specified avatar to the appropriate mood in a buffer and then uses the data in the buffer to redraw avatar 100 on the display screen for on-line computer. Thus, this method includes a change mood process and a redraw process.
When reply check 503 (FIG. 5A) in method 500 receives the reply message from server method 550, reply check 503 determines whether the success field in the reply message is set to SUCCESS. If the success field is set to SUCCESS, processing transfers from check 503 to change mood operation 504 and otherwise to failure message check 507.
Change mood operation 504 changes the animation of the specified avatar, e.g., avatar 100 to the appropriate mood in a buffer memory for display 250-1, and transfers processing to redraw operation 505. Redraw operation 505 redraws the screen display so that the mood of avatar 100 in this example is changed. Operation 505 transfers to end method operation 506 which cleans up and closes method 500.
When processing transfers to failure message check 507, check 507 determines whether the success field of the reply message is set to FAILURE_MESSAGE. If check 507 is true, processing transfers to error handle frozen message operation 508 and otherwise to handle error operation 509. Operation 508 writes the message in the reply message and then terminates 500 method in an error mode. Similarly handle error operation 509 terminates method 500 in an error mode.
One embodiment of methods that allow an on-line user to change the mood of an avatar is presented in Appendix A, and is incorporated herein by reference. Table 4 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 4 Avatar Class Specific Methods for Changing Avatar Mood Process Location Name client method avatarBuildMenus_command client method avatarChangeMood_command client method avatarChangeMood_notify server method avatarChangeMood_perform
If on-line user 225-1 selects a gesture from menu 403 instead of a particular mood, a command is generated that launches an avatar gesture command method as a client process on on-line user computer 200-1. This method is similar to method 500
except the requested gesture replaces the requested mood in method 500. The avatar gesture command method sends a avatar gesture request message to server computer 260 with the gesture and the direction the avatar is facing as parameters.
In response to the avatar gesture request message, server computer 260 launches an avatar gesture perform method. This server process is substantially similar to method 550 with a gesture replacing the mood. Avatar gesture perform method first performs the same frozen check process as in method 550, and if the avatar is not frozen, checks whether the requested gesture is a valid gesture. If the gesture is valid, a reply message is sent to the client process, and the neighbor on-line users are subsequently sent a avatar gesture notice message that in turn launches an avatar gesture notify method on each neighbor on-line computer 200-i displaying the avatar. The avatar gesture notify method plays an appropriate gesture animation and redraws the screen display.
When the client computer receives the reply message, if the reply message indicates SUCCESS, avatar gesture command method plays an animation for the gesture and then redraws the screen to present animation. One embodiment of methods used to implement gestures is presented in Appendix A, and is incorporated herein by reference. Table 5 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 5 Avatar Class Specific Methods for Gestures by an Avatar Process Location Name client method avatarBuildMenus_command client method avatarGesture_command client method avatarGesture_notify server method avatarGesture_perform
The choreography for one embodiment of the various gestures is defined in Table 6.
TABLE 6 Gesture Choreography Specification Gesture Actions Wave begin wave waving end wave Bow bow bow return Shrug shrug shrug return Present (Arm Out) extend-arm out, hand closed extend-arm out, hand closed return extend-arm out, hand flat extend-arm hand flat return Jump jump up React (Stomp) stomp external leg stomp internal leg
To change the direction avatar 100 is facing, on-line user 225-1 points at menu item Turn and a third pop-up menu 403, as illustrated in FIG. 4C, is generated. Menu 402 includes three options as listed in Table 7.
The action of avatar 100, when one of these actions is selected, is to turn the direction selected. Turning around means a 180.degree. turn in this embodiment. The sequence of interaction between client and server processes is similar to that described above for a mood change with the action modified to a turn. One embodiment of methods used to implement turns is presented in Appendix A, and is incorporated herein by reference. Table 8 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 8 Avatar Class Specific Methods for Turns by an Avatar Process Location Name client method avatarBuildMenus_command client method avatarFacing_command client method avatarFacing_notify server method avatarFacing_perform
To retrieve an virtual object from pocket 105 of avatar 100 when there is nothing in the hands of avatar 100, on-line user 225-1 selects menu item Get from pocket. When on-line user 225-1 selects menu item Get from pocket by pointing at menu item Get from pocket a fourth pop-up menu 404, as illustrated in FIG. 4D, is generated. Menu 404 lists the virtual objects stored in pocket 105.
Pocket 105 includes a plurality of slots to hold virtual objects. In the embodiment of class avatar in Appendix A, avatar 100 has a total of ten storage locations. The first storage location is in the hands of avatar 100 and the remainder are in pocket 105. The first storage location in pocket 105 is reserved for an avatar head. The second storage location is reserved for a virtual pad document object, and the third storage location is reserved for tokens. The remaining storage locations are for virtual objects owned by avatar 100. A number identification, sometimes referred to as noid, for the virtual object is stored in the storage location, i.e., the slot in pocket 105.
At this time, as shown in FIG. 4D, avatar 100 has six virtual objects in pocket 105. The virtual objects are a token object, a box object, and four spray paint can objects for which the colors are listed. An avatar can change its skin color, the color of the clothes on its upper torso, and the color of the clothes on its lower torso using a spray paint can object. If the box object in pocket 105 contained other virtual objects, avatar 100 could store more than the six virtual objects in his pocket.
When on-line user 225-1 releases the mouse button while pointing at one of the entries in menu 404, computer 220-1 interprets the signal generated by the menu selection, and provides an signal to the client menu process that generated menu 404 to indicate the menu item selected. In response to the signal, the client menu process issues a standard get command message with the selected object, the avatar, and any object in the avatar's hand as arguments. A similar operation is performed when the function key is pressed.
In response to the standard get message, an avatar pocket get from command method 600 is launched on computer 200-1 as a client process. In avatar pocket get from method 600 (FIG. 6A), initializing operation 601 sets the actor to the avatar and transfers to transmit request operation 602.
Transmit request operation 602 sends an avatar get object request message to server computer 260 for avatar 100, and requests a standard reply message. The avatar get object request message includes the virtual object selected as an argument, and the action required to get the virtual object, i.e., FROM_POCKET. Process 602 transfers processing to reply message check 603 that in turn waits for a reply message from server computer 260.
In response to the avatar get object request message from method 600, that is executing as a client process on computer 200-1, server computer 260 launches avatar get object perform method 650 as a server process. In this embodiment, get object perform method 650 (FIG. 6B) is executed for a variety of virtual objects, i.e., each time an avatar gets a virtual object. Consequently, method 650 considers actions other than just those associated with getting an object from pocket 105.
In general, server method 650 is called when a virtual object is being pointed at, and a get action is specified for the avatar representing the on-line user. Possible get actions include not only a get from pocket, but also a get from shoulders, a get from ground, a get from a shelf and a get from a table. For a get action to be successful, the virtual object being pointed at can not be held by another avatar, and the actor avatar, i.e., the avatar issuing the get action, cannot have a virtual object in his hands.
Thus, valid get check 651 determines whether the requested virtual object is a valid object; the requested virtual object is immobile; the hands of avatar 100 are full, and avatar 100 is a ghost. If any one of this checks is true, check 651
transfers to set message operation 652 and otherwise to open container check 653. Set message operation 652 sets the success field of the reply message to FAILURE and transfers to send reply operation 663. Notice that a ghost can not get an object.
In open container check 653, a check is first made to determine whether the class of the requested object is container. If this check is false, processing transfers to container operation 655, and otherwise a second check is made to determine whether the container is open. If check for an open container is false, processing transfers to container operation 655 and otherwise to set message operation 654. Set message operation 654 sets the success field of the reply message to FAILURE and transfers to send reply operation 663. Here, an important aspect is to assure that a container is closed before that container is moved to another container, such as the avatar's hands.
In container operation 655, a pointer to the object holding the object to get is obtained and processing transfers to head check 656. Check 656 determines whether the holding object is a head, and if so transfers to container operation 657 and otherwise to get from avatar check 658. In container operation 656, it is determined whether head is attached to avatar 100, and processing transfers to get from avatar check 657.
If the object to get is on the head of avatar 100 or on a loose head, avatar 100 can get the object. However, if the object is on the head of another avatar, avatar 100 can not get the object. In get from avatar check 658, if the virtual object to get is in possession of another avatar, processing transfers to set message operation 659, and otherwise to adjacent check 660. Set message operation 659 sets the success field of the reply message to FAILURE_OBJECT_NOT_ACCESSIBLE, and transfers to send reply operation 663.
If the container for the requested object is not another avatar and the avatar is not adjacent to the requested object, check 660 transfers to set message operation 661 and otherwise to change container operation 662. Set message operation 661
sets the success field of the reply message to FAILURE_NOT_ADJACENT, and transfers to send reply operation 662.
Throughout this disclosure, adjacent is a true or false description of the distance relationship between two objects. Typically, when an object is pointed to and an avatar is not adjacent to the object and the position of the object is within the boundaries allowed for movement within the locale, the avatar is given the option of walking to the object.
In change container operation 662, the requested object is placed in the hands of the avatar for the instance of the avatar on server computer 260, and if the placement is successful, the success field of the reply message is set to SUCCESS. Operation 662 transfers to send reply operation 663.
Send reply message 663 transmits the reply message to client pocket get command method 600 and transfers processing to success check 663. Success check 663 determines whether the success field in the reply message was set to SUCCESS. If the success field was set to SUCCESS, check 663 transfers to update neighbors operations 664 and otherwise to done operation 665.
Update neighbors operations 664 first declares a avatar get object notice as a notice message and then initiates generation of the notice message. The object and the action to be taken with the object are placed in the notice message and the message is sent to each on-line user 225-i that has an avatar in the same locale as avatar 100 with the identification number for which the notice message applies. Operation 664 transfers to done operation 665.
In response to the notice message from server computer 260, each notified on-line computer 200-i that is displaying avatar 100 launches an avatar get object notify method. This method plays a sound representing the action directed and places the specified object in the hands of the specified avatar.
When reply check 603 in method 600 (FIG. 6A) receives the reply message from server method 650, reply check 603 determines whether the success field in the reply message is set to SUCCESS. If the success field is set to SUCCESS, processing transfers from check 603 to play sound operation 605 and otherwise to handle error operations 604.
Play sound operation 605 plays a get from pocket sound and transfers to change container operation 606. Change container operation 606 places the specified object in the hands of avatar 100 and transfers to end method operation 607 which cleans up and closes method 600.
When processing transfers to handle error operation 604, method 600 is terminated mode and provides the on-line user an appropriate message.
One embodiment of methods used to get an object from pocket 105 is presented in Appendix A, and is incorporated herein by reference. Table 9 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 9 Avatar Class Specific Methods for a Get from Pocket Process Location Name client method avatarBuildMenus_command client method avatarPocketGet_command client method avatarGetObject_notify server method avatarGetObject_perform
Avatar--Remove
When menu item remove in menu 401 (FIG. 4A) is selected, a command is generated in computer 200-1 that launches an avatar remove command method as a client process on computer 200-1. Table 10 is pseudo code for the operations performed in this method.
TABLE 10 Pseudo code for Avatar Remove Command Save facing orientation of avatar. If facing orientation of avatar is FRONTSIDE, change facing orientation to RIGHTSIDE. Play animation for avatar moving arms to head. Send avatar get object request message with requested object as head and requested action as REMOVE-HEAD. Play animation for avatar returning arms from head. Restore original facing orientation of avatar, Wait for reply message from server. If reply is success, place head in avatar hands and play head remove sound. Else handle Failure. End method
The operations of the server in response to the avatar get object request message were described above with respect to FIG. 6B, and are incorporated herein by reference.
One embodiment of methods used to remove a head from the body of avatar 100 is presented in Appendix A, and is incorporated herein by reference. Table 11 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 11 Avatar Class Specific Methods To Remove Head Process Location Name client method avatarBuildMenus_command client method avatarRemove_command client method avatarGetObject_notify server method avatarGetObject_perform
Avatar--Status
When on-line user 225-1 points at menu item Status in menu 401 (FIG. 4A), a status pull-right menu 405 (See FIG. 4E) is generated on display screen 250-1. One embodiment of the menu items in the status pull-right menu is presented in Table 12. Also, included in Table 12 is the response to each menu item that is written in dialogue area 140 (FIG. 1) when that menu item is selected.
TABLE 12 Status Pull-Right Menu Who's in here? Presents the names of the other avatars in the locale. How healthy am I? Gives a state of the avatar's general health. What time is it? Gives the time relative to Pacific Time. Tokens in pocket? Reports the amount of tokens in avatar's pocket. Turn ESP off<or ON> Allows the avatar to not receive ESP messages from others. Disallow Following If avatar is allowing other avatars to follow. Note: Disallow following generates a server message to any other avatars following the avatar that the avatar has chosen the "disallow" command. The message "The avatar you are following has decided to stop leading you." is presented Allow Following If avatar is not allowing other avatars to follow.
One embodiment of methods used to handle status inquires for avatar 100 is presented in Appendix A, and is incorporated herein by reference. Table 13 identifies the methods in Appendix A that are general methods used by class avatar for status operations.
TABLE 13 Avatar Class General Methods For Status Process Location Name method build StatusMenu_procedure; method playerStatus_command; method playerStatus_perform;
When on-line user 225-1 selects menu item Become a Ghost in menu 401 (FIG. 4F), the mouse signal is converted to a signal that results in a avatar to ghost command method being launched on computer 200-1 as a client process with avatar 100 as the target. Notice that the menu associated with avatar 100 is the same in locale 150 and in locale 350. Table 14 is pseudo code for one embodiment of the avatar to ghost command method.
TABLE 14 Pseudo Code for Avatar to Ghost Command Method Set target to argument passed in message command. Set seat to container number ID for target. If avatar is seated, have avatar stand. (Optional) Send an avatar to ghost request message to server with target as an argument. Wait for reply message from server. If success field of reply message is not SUCCESS, Handle failure. End Method
In response to the avatar to ghost request message, an avatar to ghost perform method is launched on server computer 260 as a server process. Table 15 is pseudo code for one embodiment of the avatar to ghost perform method.
TABLE 15 Pseudo Code for Avatar to Ghost Perform Method Generate an instance of ghost class. Save number id for target. Initialize reply message by setting success field of reply message to FAILURE, and failure message field to a nullity. If target cannot become a ghost, or is already a ghost, go to send reply message. If actor is ghosting himself, If actor is frozen (See avatar frozen check 554 (FIG. 5B)) If freeze period is over, ( See Check 555 (FIG. 5B)) Unfreeze avatar (See operation 557 (FIG. 5B)); Else Frozen reply message; Go to send reply message. Else, If actor ghosting the avatar is not at least an Acolyte, go to send reply message. Change avatar to ghost. If error code for change is no error, Stop everybody from following ghost; If this is first ghost in locale, Set show ghost field of reply message to true; Set coordinates field of reply message to location in screen display of ghost. Else, Set show ghost field of reply message to false. Set success field of reply message to SUCCESS. Else, Set success field of reply message to failure. Set failure message field of reply message to error code. Send reply message. If success field of reply message is SUCCESS, Declare an avatar to ghost notice message Initiate the notice message Set target field of notice message to old number ID. If this is first ghost in locale, Set show ghost field of notice message to true; Set coordinates field of notice message to location in screen display of ghost. Else, Set show ghost field of notice message to false. Send notice message to all users displaying target.
Notice that the notice message is sent not only to neighbors, but also to the on-line user that caused the avatar to ghost perform method to be launched on server computer 260. Also, the virtual world includes acolyte and oracles that have special powers to control features of the world. However, acolytes and oracles are not an essential aspect of this invention and so are not considered further.
In response to the notice message from server computer 260, an avatar to ghost notify method is launched as a client process on computers 200-i to which the notice message is sent. Table 16 is pseudo code for one embodiment of the avatar to ghost notify method.
TABLE 16 Pseudo Code for Avatar to Ghost Notify Method Set actor to on-line user. Set target to target field in notice message. Play dematerialize sound. Destroy instance of avatar being ghosted, and visual display of avatar. If target is actor, assign global characteristics for actor to ghost If show ghost field of notice message is set to true, draw ghost object in screen display at coordinate given in notice message. (See FIG. 3B) End method
Thus, when on-line user 225-1 becomes a ghost, avatar 100 (FIG. 4F) is removed from the graphic user interface, and a ghost icon 380 (FIG. 3B), e.g., an eye in the sky, replaces avatar 100. If ghost icon 380 was already present in locale 350
when avatar 100 becomes a ghost, the count of the number of ghosts in locale 350 is increased, and avatar 100 is removed from the graphic user interface.
One embodiment of methods used to change avatar 100 to a ghost is presented in Appendix A, and is incorporated herein by reference. Table 17 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 17 Avatar Class Specific Methods For Avatar to Ghost Process Location Name client method avatarToGhost_command client method avatarToGhost_notify server method avatarToGhost_perform
Avatar--Tell Me About
When the user selects menu item tell me about in menu 401 (FIG. 4A), an informational menu about avatar 100 is displayed. In general, a tell me about action is present on the main pop-up menu for every object, but not on any submenus.
Menu 401 (FIG. 4A) is generated when avatar 100 points at himself and his hands are empty. However, if avatar 100 points at himself and has something in his hand, some of the menu items in menu 401 change as indicated above. Specifically, menu item Get from pocket becomes Put in. Menu item Remove is not presented because there is no room in the avatar's hands for the head. If a head is in the avatar's hands and the avatar is not wearing a head, a menu item Wear is presented.
Avatar--Put In
When menu item Put in pocket is selected, in one embodiment, a standard put in pocket command method is launched as a client process on computer 200-1 for the portable object in the hands of avatar 100. In another embodiment, methods specific to the object being placed in the avatar's pocket could be used. These methods would likely be similar to those described below, except the methods would be streamlined and include checks for the specific object being place in the pocket.
In the standard method, the object in the hand of the avatar is first checked to determine whether the object is an open container. If the object is an open container, the method is terminated and a message is supplied to on-line user 225-1
requesting that the object be closed.
If the object in the avatar's hand is closed, a check of the slots in pocket 105 is made to find an empty slot. If an empty slot is not found, the method is terminated and a message "Your pocket is already full" is provided to on-line user
225-1. If a slot is available, a standard put in pocket request message is sent to server computer 260, and an animation is started.
In response to the standard put in pocket request message, server computer 260 launches a put in pocket perform method. In this method, illegal conditions such as the avatar is a ghost, the avatar is not holding the object, the object is open, or a slot in the pocket is not available, are checked. If any one of these conditions is true, a failure reply message is sent back to the client process. Next, a change container operation moves the object in the avatar's hands into an empty slot. If this operation is successful, a success flag and an empty slot number are returned in the reply message. Otherwise, the reply message indicates an internal failure. If the change container operation was successful, a notice message is sent to each of the avatar's neighbors to have the avatar place the object in his pocket.
When a reply message is received, the client process terminates the animation and checks whether the reply message indicates success. If success is not indicated, the method is terminated and an error message provided. Conversely, if success is indicated, a change container operation moves the object in the hand of avatar 100 into pocket 105 and a put in pocket sound is played. This ends the method.
Table 18 is pseudo code for one embodiment of the
standard put in pocket command method.
TABLE 18 Pseudo Code for Put In Pocket Command Method If object is open container, then present failure message "Please close the container before placing in pocket," and terminate. If object is not assigned a reserved slot in pocket, and avatar pocket is full, then present failure message "Your pocket is already full," and terminate. Start Put in Pocket animation Issue standard put in pocket request message with no argument to server computer. Wait for standard put in pocket reply from server computer. Finish animation upon receipt of reply. If reply is success, move object from hand to pocket and play put in put pocket sound, else handle failure End method
Table 19 is pseudo code for one embodiment of the standard put in pocket perform method.
TABLE 19 Pseudo Code for Standard Put in Pocket Perform Method If avatar is a ghost or avatar is not holding the object or the object is open, or a slot in the pocket is not available, send failure reply message and terminate; Moves the object in the avatar's hands into an empty slot. If move operation is successful, return a success flag and an empty slot number in the reply message, else return a reply message indicating an internal failure and terminate. If move operation was successful, send a notice message to each of the avatar's neighbors to have the avatar place the object in his pocket.
One embodiment of methods used to put objects in pocket 105 of avatar 100 is presented in Appendix A, and is incorporated herein by reference. Table 20 identifies the methods in Appendix A that are general methods and a specific method used by class avatar for put in pocket operations.
TABLE 20 Avatar Class General Methods For Put In Pocket Process Location Name client method avatarBuildMenus_command (specific) client method putInPocket_command (general) client method putInPocket_notify (general) server method putInPocket_perform (general)
Avatar--Wear
When menu item Wear is selected, a command is generated in computer 200-1 that launches an avatar wear command method as a client process. Table 21 is pseudo code for the operations performed in this method.
TABLE 21 Pseudo code for Avatar Wear Command Save facing orientation of avatar If facing orientation of avatar is FRONTSIDE then change facing orientation to RIGHTSIDE Play animation for avatar moving arms to head Send avatar exchange object request message with exchanged object as head and requested actions as wear head Play animation for avatar returning arms from head Restore original facing orientation of avatar Wait for reply message from server If reply is success, place head on avatar body and play head wear sound else handle Failure End method
The operations of the server in response to the avatar exchange object request message are to check the validity of the request and that only a head is placed on the shoulders of the avatar. If all of the conditions are satisfied, a successful reply message is sent, and neighbors of the avatar are notified to update the screen display to show the avatar wearing the head.
One embodiment of methods used to wear a head on the body of avatar 100 is presented in Appendix A, and is incorporated herein by reference. Table 22 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 22 Avatar Class Specific Methods To Wear Head Process Location Name client method avatarBuildMenus_command client method avatarWear_command client method avatarExchange_notify server method avatarExchange_perform
In one embodiment, when on-line user 225-1 points at a object other than avatar 100 using mouse 202-1, e.g., container 430 in locale 450 (FIG. 4G) and then depresses the left mouse button when the hands of avatar 100 are empty, a signal is generated by mouse 202-1 that is interpreted by a client process executing in computer 200-1 that builds a pop-up menu 406 (FIG. 4H) for the object pointed at. The options are given in Table 23A.
TABLE 23A Menu When Pointing At a Container Object other than Avatar with Hands Empty <Object Name> Walk to Get Open Lock Tell Me About . . .
Here, the assumption is that the pointed at object is a loose portable container object, such as object 430. The menu items that are the same as those in menu 401 perform as described above. Menu item Get appears only if avatar 100 can get the object pointed at, e.g, the object is a portable object that is not in the hands of another avatar. When menu item Get is selected, if avatar 100 is not adjacent to the object, avatar 100 walks to the object and places the object in his hands. Thus, the methods used to implement Get result in the avatar picking up the object.
In this example, on-line user 225-1 first selects menu item Walk to, and a client process on computer 200-1 moves avatar 100 adjacent to container 430 and pop-up menu 406 is killed, as shown in FIG. 4I.
When on-line user 225-1 points at container 430, while adjacent to the container 430, and then depresses the left mouse button when the hands of avatar 100 are empty, a signal is generated by mouse 202-1 that is interpreted by a client process executing in computer 200-1 that builds a pop-up menu with the options given in Table 23B.
TABLE 23B Menu When Pointing At a Container Object other than Avatar with Hands Empty <Object Name> Get Open Lock Tell Me About . . .
Notice that in FIG. 4G, container 430 is closed. After avatar 100 walked to container 430, and on-line user 225-1 pointed at container 430, the pop-up menu of Table 23B was displayed on display screen 250-1. On-line user 225-1 selected menu item Open, and the pop-up menu disappeared and container 430 was opened as shown in FIG. 4J.
When on-line user 225-1 points at open container 430, while adjacent to the container 430, and then depresses the left mouse button when the hands of avatar 100 are empty, a signal is generated by mouse 202-1 that is interpreted by a client process executing in computer 200-1 that builds a pop-up menu 407 (FIG. 4J) for the object pointed at. The options are given in Table 23C.
TABLE 23C Menu When Pointing At an Open Container Object other than Avatar with Hands Empty <Object Name> Get From > Get Close Lock Tell Me About . . .
Notice that pop-up menu 407 is similar to pop-up menu 406, except menu item Walk to has been replaced by Get from. Also menu item Open has been replaced by menu item Close.
When on line user 225-1 uses mouse 202-1 to select menu item Get from, a right pull menu 408 is displayed that lists the objects contained in the container. Each container has a predefined number of slots and each slot can be used to store one portable virtual object.
In this example, on-line user selects menu item Tokens, in response to this selection a client process is launched to get the tokens from container 430. One embodiment of methods used to get tokens from a container are described more completely below. FIG. 4K illustrates the user interface after the get token from container operations are complete. Notice that avatar 100 is not holding a token.
One embodiment of methods used for a get of an object, e.g., container 430 itself, by avatar 100 is presented in Appendix A, and is incorporated herein by reference. Table 24 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 24 Avatar Class Methods For Get Process Location Name client method goToAndGet_command client method avatarGetObject_notify server method avatarGetObject_perform
When on-line user 225-1 points at an object other than avatar 100 using mouse 202-1 and then depresses the left mouse button when the hands of avatar 100 are full, a signal is generated by mouse 202-1 that is interpreted by a client process executing in computer 200-1 that builds a pop-up menu for the object pointed at. The options are given in Table 25.
TABLE 25 Menu When Pointing At an Object other than Avatar with Hands Full <avatar name> walk to here put touch >
Menu item Put appears only if avatar 100 can place the object in his hands on, or in the object pointed at. The action taken in response to selection of menu item Put depends upon the action selected. In general, this action is available, when there is an object in the avatar's hands, and the pointed at object is a container that is not another avatar, and that has an open slot that can hold the object in the avatar's hands. To perform the put operation for a container, in one embodiment, the methods listed in Table 26 and presented in Appendix A, which are incorporated herein by reference, are used.
TABLE 26 Avatar Class Methods For Put When Selected Object is a Container Process Location Name client method PutInContainer_command client method PutInContainer_notify server method PutInContainer_perform
These methods are similar to those described above for put in pocket and so are not considered in further detail.
An avatar can also put a portable object in a locale, e.g, on the floor. In this case, the object belongs to the locale, rather than an avatar or a container and so is considered a loose object. See for example FIG. 11A that includes several loose objects including a book 1161 and a head 1162.
If the object is a floor, for example, the methods used are listed in Table 27 and presented in Appendix A, and incorporated herein by reference.
TABLE 27 Avatar Class Methods For Put When Selected Object is not a Container Process Location Name client method dropAtPosition_command client method avatarDropAt_notify server method avatarDropAt_perform
In each case, if avatar 100 is not adjacent the pointed at object, the methods implementing this action walk the avatar to the object and then place the object in the avatar's hands on, or in the pointed at object. Thus, the methods used to implement Put result in the avatar putting down the object.
If the object pointed at is another avatar, the menu item Put is replaced by menu item Give to. In this case, the object in the first avatar's hand is placed in the second avatar's hand, if the second avatar is not holding an object, and a notice is sent to the second avatar of the transaction.
When menu item Give to is selected, a message is generated that launches an avatar give to command method as a client process. The giving avatar and the object being given are arguments in the call to the method. Table 28 is pseudo code for one embodiment of the avatar give to command.
TABLE 28 Pseudo Code for Avatar Give To Command Method Set giver to avatar in call to method. Set item to item in call to method. (Walk giver adjacent to recipient. -- optional) If recipient is holding an object, Handle failure "You cannot give an item to someone who is holding something." If item has a valid id, Play animation for giver to give object. Send avatar give to request message to server. Wait for reply message from server. If success field of reply message is success, If item is a token, play coin give sound, Redraw item in buffer Move item from hand of giver to hand of recipient. Redraw item in buffer, Else, Handle failure. End Method,
In response to the avatar give to request message, an avatar give to perform method is launched on server computer 260 as a server process. Table 29 is pseudo code for one embodiment of the avatar give to perform method.
TABLE 29 Pseudo Code for Avatar Give to Perform Method Initialize reply message by setting success field to failure, If giver is a ghost, go to send reply message If hands of giver are empty, or hands of recipient are full, go to send reply message Set item to instance of class of object in hands of giver If item is not a valid object, go to send reply message If item successfully transfers from giver to recipient, set success field of reply message to success Send reply message If success field of reply message is success. Declare an avatar give to notice message Initiate avatar give to notice message Set giver field of notice message to giver Set item field of notice message to number ID of item Set givee field of notice message to number Id of recipient. Send notice message to neighbors with number ID of giver
In response to the notice message from server computer 260, an avatar give to notify method is launched as a client process on computers 200-i to which the notice message is sent. Table 30 is pseudo code for one embodiment of the avatar give to notify method.
TABLE 30 Pseudo Code for Avatar Give to Notify Method Set item to item field of notice message. Redraw item. Move item from giver to recipient Redraw. Set giver to giver field in notice message. Set givee to givee field in notice message. Read identification for on-line user. If notice item is a token, play coin give sound. If identification for on-line user is Identification of givee, write a message to givee "You've received [item name] from [giver name]." End Method.
One embodiment of methods used to implement give to is presented in Appendix A, and is incorporated herein by reference. Table 31 identifies the methods in Appendix A that are class specific methods used by class avatar.
TABLE 31 Avatar Class Specific Methods For Give To Process Location Name client method avatarGiveTo_command client method avatarGiveTo_notify server method avatarGiveTo_perform
Menu item Touch appears only if the object pointed at is another avatar. When menu item Touch is pointed at, the pull right menu in Table 32 is generated on display screen 250-1.
TABLE 32 Touch Pull Right Menu Poke Shake Hands Hug
In one embodiment, each of actions Poke, Shake Hands, and Hug of avatar 100 are choreographed so that the on-line users view realistic motions for the action.
For the embodiment described above, an avatar class is defined and an instance of the avatar class generated for each on-line user. A definition of the avatar class is given in Table 33. The various fields and methods defined in the avatar class have names that correspond to the name of the data represented by the field and the operations performed by the method, respectively.
TABLE 33 A Definition for Class Avatar define LONG 0; /* step sizes */ define MEDIUM 1; define SHORT 2; define DRIFT_RATIO 15; /* how big an X/Y difference before you don't drift */ /* turn directions */ define RIGHT_DIR 1; define LEFT_DIR 2; define AROUND_DIR 3; define AVATAR_CAPACITY 10; define AVATAR_HANDS 0; required define AVATAR_HEAD 1; define AVATAR_RESERVED_START 2; define AVATAR_TOKENS 2; define AVATAR_PAD 3; define AVATAR_POCKET_START 4; required define AVATAR_HAPPY 0; define AVATAR_GLAD 1; define AVATAR_SAD 2; define AVATAR_MAD 3; define WEAR_HEAD 0; define REMOVE_HEAD 1; define FROM_POCKET 2; /* Multi-Part Animations */ define GET_FROM_POCKET 0xF001; define GET_FROM_SHOULDERS 0xF002; define GET_FROM_GROUND 0xF003; define GET_FROM_TABLE 0xF004; define GET_FROM_SHELF 0xF005; define OPERATE_MACHINE 0xF006; define TURN_NOB 0xF007; define SQUAT_FIDDLE 0xF009; define FIDDLE_STAND 0xF00A; define WAVE_COMPLETE 0xF00B; define BOW_COMPLETE
0xF00C; define SHRUG_COMPLETE 0xF00D; define PAY 0xF00E; define SHOW 0xF00F; define FIDDLE_WHOLE 0xF010; define WEAR_COMPLETE 0xF011; /* Added for security checks */ define JUMP_UP 0x0022; define STOMP 0x00C4; /* Define some permission flags */ define AVATAR_PERM_FIDDLE 0x0001; /* use fiddle wand */ define AVATAR_PERM_PROMOTE 0x0002; /* promote/demote other avatars */ define AVATAR_PERM_MUTE 0x0004; /* Forbidden to speak, think, or ESP */ define AVATAR_PERM_FREEZE 0x0008; /* Forbidden to move, gesture, exit, etc */ required class avatar { info { classNumber thisClass(); version thisVersion(); name "Avatar"; capacity AVATAR_CAPACITY; reserved AVATAR_RESERVED_START; pickFrom AVATAR_POCKET_START; helpResourceID DEFAULT HELP; } instance { include "instance. cld"; include "instcont.cld"; /* class specific data */ common: uint8 activity; uint8 action; uint8 nameChanges; uint8 aFiller; uint16 health; uint16 following; uint32 perm_flags; uint16 home_areaCode; server: char system_name [MAX_NAME_SIZE]; char prev_name1 [MAX_NAME_SIZE]; uint32 last_use_date1; char prev_name2 [MAX_NAMESIZE]; uint32 last_use_date2; char acct_name [MAX_ACCT_SIZE]; char password [MAX_PASSWD_SIZE]; uint32 banished_until_date; uint32
last_login_date; uint32 login_region_num; uint32 create_date; uint32 leader_woid; uint32 bankAccountBalance; uint32 curse_type; uint32 avatar_time; uint32 ghost_time; uint16 avatar_state; uint16 save_style; uint8
save_colorMap[COLOR_TABLE_SIZE]; uint32 mail_textid; uint32 doc_id; uint32 index_id; uint32 doc_bits; uint32 home_region_num; uint16 home_region_zone; uint32 mute_until_date; uint32 freeze_until_date; client: uint16 walkDestination[3]; uint32
walkingFrameNumber; } /* ** Resources used by class avatar. */ verb allowfollow; verb disallowfollow; verb follow; verb gesture; verb ghost; verb giveTo; verb happy; verb help; verb mad; verb pocketget; verb pocketput; verb remove; verb stopfollow; verb touch; verb unfollow; verb walkTo; verb wear; verb sad; verb glad; verb jump; verb wave; sound getFromPocket1; sound wearHead; sound removeHead; sound dematerialize; sound putInPocket1; sound bagClosing; sound safeClose; sound chestClose; sound bagOpening; sound safeOpen; sound chestOpen; image genericAvatar; image femaleAvatar; image maleAvatar; image oracleAvatar; /* ** Standard methods used by class avatar. */ method buildStatusMenu_procedure; method goToObject_command; method help_command; method playerStatus_command; method playerStatus_perform; method setName_command; method speak_command; method speak_notify; method speak_perform; /* ** Class specific methods used by class avatar. */ client method avatarAnimate_procedure client method avatarBodyChange_command client method avatarBodyChange_notify server method avatarBodyChange_perform client method avatarBuildMenus_command client method avatarChangeMood_command client method avatarChangeMood_notify server method avatarChangeMood_perform client method avatarCloseContainer_notify server method avatarCloseContainer_perform client method avatarDestroy_notify client method avatarDropAt_notify server method avatarDropAt_perform client method avatarExchange_notify server method avatarExchange_perform client method avatarFacing_command client method avatarFacing_notify server method avatarFacing_perform client method avatarFollow_command client method avatarFollow_notify server method avatarFollow_perform server method avatarForceExit_perform client method avatarFreeze_notify server method avatarFreeze_perform client method avatarGesture_command client method avatarGesture_notify server method avatarGesture_perform client method avatarGetObject_notify server method avatarGetObject_perform client method avatarGiveTo_command client method avatarGiveTo_notify server method avatarGiveTo_perform client method avatarGoToConnection_command client method avatarGoToConnection_notify server method avatarGoToConnection_perform client method avatarGoToPosition_notify server method avatarGoToPosition_perform server method avatarHelp_perform server method avatarJoin_perform client method avatarMute_notify server method avatarMute_perform client method avatarOpenContainer_notify server method avatarOpenContainer_perform server method avatarOwner_perform client method avatarPocketGet_command client method avatarRemove_command server method avatarSend_perform client method avatarSetPermissions_notify server method avatarSetPermissions_perform client method avatarToGhost_command client method avatarToGhost_notify server method avatarToGhost_perform client method avatarTouch_command client method avatarTouch_notify server method avatarTouch_perform client method avatarUnfollow_command client method avatarUnfollow_notify server method avatarUnfollow_perform client method avatarWear_command }
Table 33 demonstrates the general class organization of all the classes of this invention. According to the principles of this invention, a class includes a class descriptor, a class instance structure, and a collection of resources. The class descriptor contains various pieces of information about the class as a whole. The class instance structure describes the instance variables of objects of the class. The collection of resources contains the class's methods, images, sounds, and so forth. In this embodiment, class avatar is a subclass of a base class and a subclass of a container class that are described more completely below. Appendix A includes a specific embodiment for each of the methods in Table 33.
In Table 33, the following definitions are used:
include used to incorporate the contents of other files define used to declare symbolic names for expression values message used to declare messages method used to declare methods definfo used to declare the class descriptor struct resourcetype used to declare resource types resource used to declare resources class used to declare classes
The primitive data types are:
sint8 sint16 sint32 uint8 uint16 uint32 char string bool objref
where sintxx and uintxx represent signed and unsigned integers (respectively) of the indicated precision, char represents a single character, string represents a NUL-terminated character string, bool represents a boolean flag type (represented by a byte that may take only the values 0 or 1), and objref represents a run-time pointer to another object.
For methods, server and client identify the site where the method is executed. The methods are stored in an executable format in the memory of the site indicated. The marker common indicates fields visible to everyone. The marker server indicates fields visible only on the server. The marker client indicates fields visible only on the client. By default, if no marker keyword is given initially, fields are common.
TOKENS
As described above, a token object 110, sometimes simply referred to as token 110 is a medium of exchange in the virtual world. Thus, a token object is an example of a medium of exchange object that is an instance of a medium of exchange class. In this embodiment, there is only one style of token that is a golden colored round coin with a profile of a face. Token object 110 can have a value one or greater. There is no token value of zero.
When on-line user 225-1 points at token object 110 (FIG. 7A) in the hand of avatar 100 using mouse 202-1 and then depresses the left mouse button, a signal is generated by mouse 202-1 that is interpreted by a client process executing in computer
200-1 that builds pop-up menu 701 (FIG. 7B). The options are given in Table 34.
TABLE 34 Menu When Pointing At Token Object in Hand of Avatar <Token Value> Tokens Split . . . Gesture > Turn > Put into > Status > Become a ghost Tell Me About . . .
The menu items that are the same as those in menu 401 perform as described above. The two new menu items Split and Put into are described below. Notice that menu item Sp