Virtual objects for building a community in a virtual world6476830Abstract 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. Claims We claim: Description APPENDIX A
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 Split is followed by an ellipsis. The ellipsis signals to on-line user 225-1 that a dialogue is associated with the menu item. Thus, when on-line user 225-1 selects menu item Split, a signal is generated that launches a token split prompt command method as a client process on computer 200-1. The token split prompt command method generates dialogue box 721 (FIG. 7C). The number one is put in dialogue box 721 by the method. The user can enter the number of the 35 tokens to retain in the hand of avatar 100 in dialogue box 721. When on-line user points at OK button 722 and operates the button of mouse 202-1, a signal is generated that launches a token split OK command method 800. Clear dialogue operation 801 removes dialogue box 721 from display screen 250 and transfers processing to amount valid check 802. Amount valid check 802 determines whether: (i) the amount entered is a number; (ii) the amount entered is less than one; (iii) the amount is greater than the denomination of held token 110; and the denomination of held token 110 is less than or equal to zero. If any one of this conditions is true, check transfer processing to failure message operations 804 and otherwise to token split command operation 805. Failure message operation 804 prints a message on display screen of "Sorry, you can't split your tokens like that. Please try again.", and transfers to end method 805. Token split command operation 803 issues a token split command message with the entered amount as an argument and also transfers to end method 805. End method 805 terminates method 800. In response to the token split command message, a token split command method 830 is launched as a client process on computer 200-1. In initialize operation 810, an amount is set to the amount specified in the token split command message, and hand tokens is set to the number identification for the object, e.g., token 110 in the hand of avatar 100. Initialize operation 810 transfers processing to holding tokens check 811. If avatar 100 is holding a token, processing transfers to request put tokens in pocket process 812, and otherwise to amount check 813. Process 812 issues a standard put in pocket command message request to place token 110 in the hand of avatar 100 into pocket 105. This request launches a tokens put in pocket command method that is a client process on computer 200-1. Table 35 is pseudo code for the tokens put in pocket command method.
TABLE 35
Pseudo Code for Tokens Put in Pocket Command Method
Play animation of avatar putting hand in pocket.
Issue put in pocket request message to server
computer and wait for tokens put in pocket
reply message.
Wait for reply message from server.
If reply message indicates success
if pocket tokens exist
destroy instance of pocket tokens; and
update tokens to new denomination
returned in reply message;
put tokens in pocket;
play metal jingle sound;
play animation of avatar removing hand
from pocket and end method;
else
play animation of avatar removing hand from
pocket;
handle failure and end method.
In response to the put in pocket request message from tokens put in pocket command method, server computer 260 launches a tokens put in pocket perform method. Table 36 is pseudo code for the put in pocket perform method.
TABLE 36
Pseudo Code for Tokens Put in Pocket Perform Method
If avatar is a ghost, or avatar is not holding the
object, send failure reply message and
terminate;
If tokens in pocket,
Update in pocket by adding tokens in hand to
tokens in pocket;
Set pocket tokens field in reply message to
number identification of server pocket
tokens;
Else
Set pocket tokens field in reply message to
invalid number identification
Set denomination field to denomination of tokens
in pocket on server.
Move tokens into pocket and if i | ||||||