WO2002097616A1

WO2002097616A1 - Collaborative virtual enivonment system and method

Info

Publication number: WO2002097616A1
Application number: PCT/SG2001/000097
Authority: WO
Inventors: Lin Quingping; Weihua Wang
Original assignee: Nanyang University
Priority date: 2001-05-22
Filing date: 2001-05-22
Publication date: 2002-12-05

Abstract

A mechanism for managing the collaborative interactions among the distributed users in a Collaborative Virtual Environment (CVE) system is disclosed, in which the message routing in the system is adaptive to the application and to the user's runtine interaction. This is achieved by providing a collaboration management files package along with a 3D environment for every individual CVE application. The collaboration management files provide functional roles selectable by the users of the application, as well as behaviors for every role. It also provides definitions for the roles and behaviors of shared interactive objects within the 3D environment. When the interactive entities (either users or interactive objects) interact with each other in the CVE, the required message for coordinating the interaction and maintaining consistency between the various users' worlds is generated according to the specific behavior definition of the interactive entity's functional role, and the message is routed among the affected interactive entities in the CVE according to the constraint fields of the message. After the message arrives, the interactive entities respond with corresponding behavior based on a message definition given in the collaboration management files. The message definition forms part of a scene description file which is included in the collaboration management files package.

Description

Collaborative Virtual Environment System and Method

FIELD OF THE INVENTION

The present invention relates to networked computer systems that provide three-dimensional interactive virtual environments for concurrent distributed users to interact with interactive objects inside the shared 3D virtual environment and with other users. It further relates to a programmable interaction management and a smart message flow control within a collaborative virtual environment system.

BACKGROUND OF THE INVENTION

A Collaborative Virtual Environment (CVE) is a computer generated 3D virtual world. It is a networked multi-user system that allows more than one user to simultaneously navigate the virtual world in an immersive or non-immersive way. In a content enriched CVE, the system is extended to embed multimedia content, e.g. 2D/3D images, 2D/3D text, 3D geometry objects and sound, in the virtual environment to improve the information presentation of the virtual world to the users. The system is built to allow the users to interact with the interactive entities inside the virtual world during the navigation. The interactive entities include the simultaneous users and the interactive objects defined in the virtual world. Interactions among the users may include an awareness of the co-existence of other users inside the virtual environment, and the carrying out of collaborative work through supported multimedia input methods. The result of the collaborative work could be to change the status of the virtual world or to fulfill more complicated team tasks. The awareness of others is achieved by presenting 3D virtual embodiments (avatars) of the users inside the virtual environment and their corresponding behaviors if any. These behaviors may include navigation, gestures of the users, and other supported interacting actions. The interactive objects normally have trigger points by which the users can interact with them. Alternatively, conditioned event routings may be defined as the behavior of the interactive objects. The users' behavior is input through an interface with a mouse, joystick, and/or keyboard.

The Virtual Reality Modeling Language (VRML 97) (the international standard for delivering 3D objects over the Internet) can be used in the CVE applications as the 3D file format. It constructs the 3D environment with geometry, appearance, and other nodes. It also provides an interface to define the dynamic part of the virtual world. Sensor nodes observe status changes of specified conditions and generate an event to trigger an event/animation waterfall through the VRML's event routing mechanism. It does not however provide a standard collaborative behavior control interface and mechanism for CVE applications. The authors of such applications must manage the interactions among the interactive entities by themselves.

The conventional approach to maintain status consistency of a shared virtual world for the distributed users is via server control. In a client/server networked CVE system, the user logs in as a client and downloads the 3D virtual world data files, for example VRML files, from the server. When the user interacts with the virtual world an interaction message is sent to the server from the client to report the interaction of the user. The server propagates the interaction messages to other users in the CVE about the interaction event. Then the receivers of these messages update their local presentation of the virtual world accordingly. The basic interaction management and message routing mechanism used by the CVE systems is server broadcasting. In server broadcasting, all of the status changing information about the users' positions, rotations, gestures and interactions with interactive objects, are populated to all of the other users in the CVE. In such systems not much consideration is given to routing efficiency or to system scalability issues.

To cope with more complex and efficient interaction management requirements, several new approaches have been developed. Typical methods spatially divide the virtual space into connected zones, and constrain a user's awareness, and the ability of the interactive entities to interact, by the bounds of these zones. To some extent, this approach can limit the destination of the environment status updating messages, and reduce consumption of network resources. Its performance is, however, not very satisfactory, as it divides the virtual space statically, and interruptions may occur when a user navigates near the bounds of a zone. To avoid such problems, some systems set the zone bounds as non-transparent walls, but this can destroy the continuity of large virtual environments. Other approaches use aura-based interaction models to manage interactions in CVEs. An interactive entity's aura defines its overall region or scope of interest in a medium, and the collision of two entities' auras enable interactions between them. The aura is attached to the user and moves with the user's navigation steps. In this way, interruptions caused by the bounds of an interaction region are overcome, because the region becomes dynamic and moves with the user. This approach is, however, still based on a spatial relationship among the interactive entities. The interaction management achieved by this approach is very limited. Many collaborative interactions require more intelligent controls, and it would be better if the interaction management mechanism were to be adaptive instead of requiring special development for different CVE applications. Thus, there is a need to provide a method to control interactions intelligently according to different conditions and different optimization algorithms. Thus, there is also a need to allow the author to define the controls through a standard programming interface. The present invention provides a framework that employs a role behavior based interaction management and adaptive message routing mechanism to meet the above needs.

SUMMARY OF THE INVENTION

The present invention provides a mechanism for managing the collaborative interactions among the distributed users in a CVE system. In the present invention, the message routing in the system becomes adaptive to the application and the user's runtime input. This is achieved by providing a collaborative behavior description along with a 3D environment definition for every CVE application. The description provides selectable roles for the users of the application, as well as behaviors for each role. The description also provides definitions for the roles and behaviors of shared interactive objects within the 3D environment. When the interactive entities (users and interactive objects) interact with each other in the CVE, the required message for coordinating the interaction and maintaining a consistent world among the users is generated according to the specific behavior definition of the roles of the interactive entities. The message is routed to the interactive entities that satisfy constraint fields in the messages. After such a message is received by the entities that satisfy the constraint fields, the interactive entities identify the message format, respond to it according to a message definition given in collaboration management files, and present the result of the interaction to the users.

There are three main advantages of the present invention. Firstly, a system that supports the invented role behavior based interaction management mechanism will be adaptive to different CVE applications with different collaborative interaction requirements, and authors do not need to re-develop the system for their particular collaborative behavior controls. Instead, they need only give a collaboration management files package to define their requirements, and the system will generate the collaborative behavior controls accordingly. Secondly, the constraint fields of the interaction message can not only define the spatial awareness/affected fields of the interactive entities, but also define other more complex control factors like logical zones, interaction paths and so on. Thus, the system is more intelligent and adaptive to the runtime input of the users. Thirdly, the system is based on an interactive entity's functional role abstraction, and the roles' behaviors are also abstracted and defined as an interface (parameter list) and function (the process sequence). The system uses the concepts of Object-Oriented software methods, and has strong reusability when developing different CVE applications. The present invention is the basis for a flexible and adaptive framework for developing CVE applications. BRIEF DESCRIPTION OF THE DRAWINGS

Fig.1 is a block diagram depicting the overall server program;

Fig.2 is a block diagram depicting the overall client program;

Fig.3 is a flow chart of the server process;

Fig. 4 is a flow chart of the client process;

Fig. 5 is a flow chart for the parser's working process;

Fig.6 is a flow chart for a new user's functional role selection process;

Fig.7 is a flow chart for a client registering process;

Fig.8 is a flow chart for an interaction observer's working process;

Fig.9 is a flow chart for a message router's working process; and

Fig.10 is a flow chart for a message processor's working process.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

The present invention will now be described in detail hereafter with reference to the accompanying drawings that depict a preferred embodiment of the present invention. It is to be understood that the present invention is described in an illustrative manner and that the terminology used is intended to be in the nature of words of description rather than of limitation. Many modifications and variations of the present invention are possible in the light of the following teachings. Therefore, it is also to be understood that, within the scope of the claims in this document, the present invention may be embodied in many different forms and should not be limited to the embodiments that are provided for the purpose of enabling those skilled in the art to practice the present invention.

It is also to be understood that each block of the flow charts and combinations of blocks in the flow charts can be implemented by computer program instructions that can be loaded onto a computer or other programmable apparatus to produce a computer implementation process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Furthermore, blocks of the flowcharts support combinations of means for performing the specified functions and combinations of steps for performing the specified functions. Thus, it is also to be understood that each block of the flowcharts, and combinations of blocks in the flowcharts, can be implemented by special purpose hardware based computer systems that perform the specified functions or steps, or by combinations of the special purpose hardware and computer instructions.

Fig. 1 illustrates the overall architecture of the server program of an embodiment of the present invention. The server program consists of a Status Storage Module 104, a Parser Module 106, a Message Router Module 110 and a Client Connection Module 112. Interaction management information is stored in the memory as block 108. The Parser Module 106 reads the collaboration management files package provided by the author of a CVE application in block 102, and creates the interaction management memory storage 108 from this. The collaboration management files package includes a scene description file and role definition files. The parser's working process is depicted iin detail in Fig. 5. The parser generates message routing rules for the Message Router Module 110 and status storing rules for the Status Storage Module 104. The Client Connection Module 112 is in charge of the Server/Client communication. In the user's role selection and registering process, the Client Connection Module 112 reads from the Interaction Management Memory Storage 108 and sends the interaction management information to the client. It also listens for interaction messages from the users and passes the messages to the Message Router Module 110. The Message Router Module 110 checks the Status Storage Module 104 for the runtime status of the CVE and resolves the destinations for the interaction messages. After the destinations of the interaction messages are resolved, the Message Router Module 110 passes the messages to the Client Connection Module 112, and the Client Connection Module 112 sends out the messages to the resolved destinations.

Fig. 2 illustrates the overall architecture of the client program for use with the server program of Fig. 1. The client program consists of a Local Info Storage Module 204, an Interaction Observer Module 206, a Message Processor Module 208 and a Communication Manager Module 210. Before entering the CVE, the user selects a functional role and registers with the server. In the client registering process, the Communication Manager Module 210 gets the interaction management information from the server. The client program initializes the Interaction Observer Module 206, the Local Info Storage Module 204, and rules for the Message Processor Module 208 according to the interaction management information. The Interaction Observer Module 206 monitors the local user's runtime input and the triggering of interactions. It informs the Communications Manager Module 210 of any interaction status changes. Once it gets the information from the Interaction Observer Module 206, the Communication Manager Module 210 generates the interaction messages and sends the interaction messages to the server. The Communication Manager Module 210 also listens for interaction messages from the server. When such a message arrives, it passes the interaction message to the Message Processor Module 208. In accordance with the interaction message, the Message Processor Module 208 reads and writes the Local Info Storage, and displays the result of the interaction in the Local Virtual Environment 202.

Fig. 3 is a flowchart illustrating the server process. The process begins with the running of the Parser Program in step 304, the Message Router program in step 310 and the Client Connection Program in step 312. The parser program's working mechanism is depicted in Fig. 5. After the parser program is run, the Interaction Management Memory Storage and the Status Storage are initialized in steps 306 and 308. Also, the status storage rules and message rules are created. The client connection program monitors for a user's connection request in step 314. When such a request is received, the client connection program goes into the User Role Selection Process in step 318 that is depicted in detail in Fig. 6. After this, the client connection program goes into the Client Registration process in step 320 that is depicted in detail in Fig.7. After the client registration process, the server runs the session manager in step 322. The session manager's task is to manage multi-user sharing in the CVE. The session manager establishes the network connection with the client and sends/receives the interaction messages through the connection to keep a consistent CVE for the users. The session manager monitors for user log-out requests. When such a request is received, the status storage is updated for the user's leaving and the connection with the client is closed. The detailed working mechanism of the session manager is documented in Fig. 6B in related International (PCT) patent application PCT/SG01/00032, filed on 15 March 2001 and entitled "System and method for constructing user-interest based dynamic virtual environment".

Fig. 4 is a flowchart illustrating the client process. The process begins with the running of the communication manager program in block 424. The communication manager program processes a user's requests to login to the CVE in step 404. It then waits to receive the information of the Role/Avatars options from the server in step 406. The user will select the Role/Avatar and send the selection to the server in step 408. The client communication manager program then gets the collaborative behavior control information from the server in step 410. Next, the client process displays the CVE in the user's computer in step 412, initializes the local info storage in step 426, and initializes the message processor in step 428. It also creates the interaction observers according to the received collaboration behavior control information from the server. After step 412, the client process runs the interaction observer program in step 414 that is depicted in detail in Fig. 8. The interaction observer program monitors the user's interaction in the CVE while the communication manager program communicates with the server by sending/receiving interaction messages in step 418. In the meantime, the client process also listens for the user's request to leave the CVE in the step 420. When such a request is received, the client program conducts the client logout clearance in step 422. The client logout clearance includes stopping the interaction observer program, deleting the local info storage, stopping the message processor program, and closing the network connection with the server.

Fig. 5 is a flowchart illustrating the Parser's working process. The process begins by reading the scene description file in step 504. It then looks for a new client role definition in the scene description file in step 506. If no new client role definition is found, it then searches for a new object role definition in step 508. Whenever a client role or an object role is found, in step 510, the parser opens the role definition file of that role. It reads from the role definition file for the role attributes and the role behaviors in step 514 and 518. After reaching the end of the role definition file, the parser stores the newly created role in the memory storage and closes the role definition file in step 522. After parsing the role definition files, the parser reads from the scene description file the names of the selectable virtual embodiments, avatars, used for representing the users in the virtual environment. The parser stores the names of the avatars in the memory storage, and will send them to newly logged on clients for avatar selection. The parser continues to read the scene description file and looks for new object initiators (that is the definitions of the interactive objects in the virtual environment) in step 524. When an object initiator is found, the parser creates and stores the new object initiator according to its name, eventln and eventOut in step 526. The parser then stores the newly created object initiator into the memory storage in step 528. After storing all of the new object initiators in memory, the parser continues to read the scene description file to look for message definitions. When such a definition is found, the parser creates a new message definition and stores it in the memory in steps 532 and 534 respectively. The parser closes the scene description file when it reaches the end of the file in step 538. The parser process then terminates. The scene description file defines:

a) Selectable functional roles for the users (e.g. ClientRole Manager; // defines a ClientRole named Manager); b) The object roles for the interactive objects included in the scene, which are involved in the interaction management (e.g. ObjectRole CDPlayer; // defines an ObjectRole named CDPlayer); c) The selectable virtual embodiments, avatars, for the users (e.g. AVATAR Manager; // defines a selectable Avatar type: Manager); d) Scene initialization information that defines the initial values for scene attributes:

(e.g. Zone CDShop -200 100, -50 100, -200 0, -50 0;

Zone InstrumentShop 200 100, -50 100, 200 0, 50 0; // defines two Zones in the CVE and gives the coordinates of the // bounds for the zones); e) The interactive objects' initialization information that defines the names of the handlers for the interactive entities:

(e.g. New CD(Classic0,"Classic_TouchS_0", "CDControler.classic_0JsActive"); // defines a CD interactive object and gives the node name, eventln name and // eventOut name, i.e. it defines an instance of the CD object role with the parameters // giving the name of the interactive object, relevant interaction-trigger's name and the // information to register this interactive object name in the system); and f) Message definitions: Sequential processing on incoming interaction messages with specified formats (e.g. onMessage("Manager",SelectCD",CUENT_NAME_JSTRING_VALUE,STRING_OBJECT_NAME)

{

MessageDisplay 'Manager, SelectCD"+" ^M+CLIENT_NAME+" GROUP NAME:"

+STRING_VALUE+ " "+STRING_OBJECT_NAME); CLIENT.SelectedCDName=STRING_OBJECT_NAME;

OBJECT_TABLE.index("CD",STRlNG_OBJECT_NAME).ACTIVE();

^' }

// defines the processing for a "manager selectCD" message. The processing

// includes displaying the message in the message_display text field; setting the // SelectedCDName attribute value for the client; and triggering the interactive // object (CD)'s behavior in the CVE);

A role definition file defines: the name of the role; key attributes for the role; and the behaviors of the role.

(e.g. ClientRole Manager{ // the name of a ClientRole Type

String Name; // attributes for the role

Position p; Orientation o;

String GroupName;

String SelectedCDName;

ViewField MAX_GRID;

PositionListener pi; OrientationListener ol; PrivateChatListener prcl;

PublicChatListener pu ; CommandListener cl;

SelectCD(String CDName) //a behavior of the role {

SelectedCDName=CDName; new Message("Manager","SelectCD",Name,GroupName,SelectedCDName);

} PlayCD() //a behavior of the role

{ new MessagefManager", "PlayCD", Name.GroupName, NULL);

} )

The attributes of a role define the possible characteristics and statuses of the role. Changing a parameter of an attribute may for example move the position of the user's avatar.

Each behavior of the role includes the name of the behavior and the actions to be carried out on activation of the behavior, e.g. the changing of attribute values, the sending out of a message in accordance with a specified format, and the calling of another behavior. It should be noted that the status storing rules of the server status storage module are derived from parsing the role attributes, and are used to determine which statuses of a virtual entity need to be stored at runtime.

Further, the message routing rules are defined by parsing the message formats in the behavior definition portions of the role definition files. The definitions for the constraint field of each message format are recorded in the Message Router Module 110, so that on receipt of a message, the Router can identify the message type and so the constraints it will hold, and can route the message accordingly.

Fig. 6 is a flowchart illustrating the New User Functional Role Selection process. The process begins by retrieving the user selectable client role list from the interaction management memory storage in step 604, and then sends the role list to the client in step 606. It then retrieves the user selectable avatar list from the interaction management memory storage in step 608. The process sends the avatar list to the user in step 610. After that, the process waits for the client's reply for the user's selection of the client role and the avatar in step 614. If no role/avatar is selected by the user, a default role/avatar is used in step 616. In step 618 the process updates the status info storage about the new client's joining and stops in step 620.

Fig. 7 is a flowchart illustrating the Client Registering process. The process begins by reading the interaction management memory storage in step 704. When a new object role's definition is found, it sends the object role's definition to the client in step 712. When a new object initiator is found, it sends the object initialization information to the client in step 714, and when an interaction message's definition is found, it sends the interaction message's definition to the client in step 716. The process then reads the user-selected role's behavior definition from the interaction management memory storage in step 718, and, in step 720, the process sends the client- selected role's attributes and behaviors to the client before stopping in step 722. Fig. 8 is a flowchart illustrating the Interaction Observer's working process. It should be noted that the Interaction observer module 206 in the client process is responsible for generating interaction observers using the listeners defined amongst the attributes of the role definition file for the client's chosen role. All listeners have their corresponding interaction observers, and the client process will generate the corresponding interaction observers. For example, if a shopper role owns the four listeners:

PositionListener pi; OrientationListener ol;

PrivateChatListener prcl; CommandListener cl;

Then, when a user selects a shopper role and logs onto the system, the client side software of the user will generate interaction observers to monitor the user's position change, orientation change, private chat input, and command input.

The Interaction Observer's process monitors the local user's runtime interactions in step 804. When an interaction is detected, the observer invokes the behavior processing for the relevant behavior from those behaviors defined for the interactive entity in the entity's role definition file. If the behavior processing includes setting values for the entity's attributes, the process updates the attribute value in the local info storage in step 814. If the behavior processing includes creating new interaction messages, the process creates the interaction messages and passes them to the communication manager program to send out to the server in step 818. If the behavior processing includes more behavior calls, the process goes to an embedded step 810 to invoke the relevant entity's behaviors and processes it accordingly.

An interactive message generated by an interaction may take the form:

<Sender_role_name, behaviorjiame, senderJD, constraint, message_value>. It may include more than one constraint parameter, which may be given in the format: <constraint 1 , constraint 2, constraint 3, ..., constraint n>. These constraint parameters may be used for different control methods. For example, constraint 1 may be used for the user's group, constraint 2 may be used for the user's field of view, and constraint 3 may be used for the zone where the user is, as discussed later. The formats may be different for different behaviors, as long as the parser is notified of the formats.

The message_value corresponds to the behavior given in the message. In a "Manager/Move/..." message, the message value may be the translation of the sender's avatar; in a "Manager/Turn/... message, the message value may be the rotation value for the sender's avatar; and in a "Manager/TalkTo/..." message, the message value may be the string format chat message from the sender to others.

The message package may be divided into two parts: a message header and a message body part. The header may include the sender_role_name, behavior_name, senderJD, and constraint field. The message body part may be the message value field.

Fig. 9 is a flowchart illustrating the Message Router's working process. The process begins with a message arriving from the client connection program in step 904. Then, in step 906, the process parses the message and gets the Sender Role, Sender Behavior, Sender ID, Constraints, and Message Value from the message. The process checks the stored interaction message definition list in the interaction management memory storage in step 908. If a matched message type is found, the process acts in accordance with the message definition for that message format, and updates the status info storage with the message value in step 912. If the constraint field of the message is not empty and has a valid value, the process then reads the status info storage and resolves the destinations for the interaction message according to its constraint field in step 920. The constraint parameters may be used one by one in the destination resolving. If the constraint field is NULL, then the message is passed to all of the users.

The router may filter out the receivers for the message using the constraint parameters in for example a logical AND manner, so that for example if there are two constraints, the server will find all users that satisfy the first constraint, and of these will send the message only to those also satisfying the second constraint. After that, the process passes the message to the client connection program which sends out the message to the destinations.

The message constraints may include: a user's group, a user's field of view, a user's view distance, a physical zone, a logical zone, the user's runtime interests, and other CVE specific constraints (e.g. in a war game CVE, the explosive power of a warhead/missile will determine the range of the affected virtual entities and who may be able to hear the explosion, etc).

The "user group" may be any grouping of the users, and may be based on their interests. For example, the users in a Virtual Music Shop scene may belong to the groups: classic music, pop music, and the like.

A "logical zone" may be a logical grouping of the users according to some constraints other than only by their physical locations. A user's runtime interests may be derived intelligently from an "interaction path" of the history of a user's interaction in a CVE. The interaction path may record the name or groupname of the virtual entities with which the user interacts at runtime. For example, if an interaction path record shows the last 10 interactive entities with which the user interacts, and amongst which eight are Classic Music CDs and 2 are Pop Music CDs, then the system may derive the user's runtime interest value as 0.8 to Classical Music and 0.2 to Pop Music. Other control factors may include the duration and frequency of the interactions which can also be used as parameters when designing constraints on the messages.

Fig. 10 is a flowchart illustrating the Message Processor's working process. The process begins by reading a message from the communication manager program in step 1004. If the message is recognizable, the process activates the relevant interaction message processing in step 1008. If the message processing includes setting attribute values, the process updates the local info storage with the new attribute values in step 1012. If the message processing includes setting a group mark for the client, the process updates the group mark accordingly in step 1016. If the message processing includes setting a value for an interaction handler, the process triggers an animation according to the interaction handler, as in step 1020. If the message processing includes setting a valid value for a public chat content, the process displays the message value as a new public chat message in step 1024. If the message processing includes setting a valid value for a private chat content, the process displays the message value as a new private chat message in step 1028.

The "group mark" is the name of a logical group the user belongs to. It can be treated as a Group ID. "Public and Private Chat Content" are the user's key-in string messages for communicating with others in the same scene. In a Virtual Music Shop scene for example, a public chat message may be routed to all the other users, and may for example only be available to a Manager role, and a private chat message may be routed to only others in the same interest group (with the same group mark).

As an example of an interaction (and the processes which follow it), in a

Virtual Music Shop scene, a PlayCD behavior for a Shopper client role may read as follows:

PlayCDO

{ new Message("Shopper","PlayCD",Name,GroupName,NULL);

}

When a user (whose name is "Tom", and who plays a Shopper role and is included in an interest Group named Classic) clicks on a CDPlayer trigger which is observed by the client side interaction observer, the above behavior would be called in accordance with the definition of the object initiator for the CDPlayer trigger, and the message packet:

would be generated. The message will be sent to the server, which would recognise the message format, and so the constraint, and would use the appropriate message routing rule to propagate the message to others in the same Classic Group.

As well as generating the message, when the user Tom triggers the CDPlayer, the music clip corresponding to the selected CD will be played locally, and when the other clients receive the interaction message generated as described above, they will note the message format, and from the message processing definition file in their message processors, will run:

OnMessage("Shopper", PlayCD", CLIENT_NAME, STRING_VALUE,NULL)

{

OBJECT_TABLE.index("CDPIayer",NULL).ACTlVE(): }

and the registered interactive object CDPlayer will be triggered by the client side software of these other clients and the music clip corresponding to the selected CD will also be played on the local computers of the other clients.

Another example message is:

<Manager/SelectCD/Tom/Classic/ClassicCDO>.

It is a message created by the Manager's SelectCD behavior after a user (Tom, a Manager in the Classic Music Group) selected the ClassicCDO through the user interface. It will be routed to other users in the same group (the Classic Music Group, whose GroupMark is Classic). After the message is received, the client software using the information in the message definition will for example update the receiver's SelectCDName attribute to ClassicCDO, and trigger the animation handler corresponding to this interactive object (the ClassicCDO).

In another example, a message and message definition may take the forms:

' <"Manager","Move",CLlENT_NAME,NULL,POSITION_VALUE>

OnMessage("Manager","Move",CLIENT_NAME,NULL,POSITlON_VALUE) {

AVATAR_TABLE.index(CLIENT_NAME).p=POSITION_VALUE;

}

In this case, the message is passed to all users, as there is no constraint value, and the users client side software will update the avatar position of the message sender (CLIENT_NAME) in the locally displayed virtual environment of the receivers.

As a further example, when a user (a shopper named "Tom" in a group "Classic") wants to say "Hello" to others in the same interest group, he will key in the message in the private chat input text field in the client side user interface. The observer in the client side software corresponding to the privatechat listener will capture the input message and invoke the TalkTo behavior of the Shopper role. According to the TalkTo behavior's definition in the "Shopper" role definition file as follows:

TalkTo(Event prcl.valueChanged)

{ new MessagefShopper'V'TalkTo", Name, GroupName.prcl. value); }

a new message will be generated and sent to the server. The message package will be:

<Shopper/TalkTo/Tom/Classic/Hello>. After the server receives the message, the message router in the server side software will route the message according to its constraint field. As the constraint field's value is Classic, the message will be routed to other users who are in the same interest group (have a groupmark as "Classic"). When the other client computers receive this message, according to the message definition received from the server during the client registration process as follows:

On Message("S opper",TalkTo",CUENT_NAME,STRING_VALUE,STRING_MESSAGE_VALUE)

{

PRIVATE_CHAT_Display(STRING_MESSAGE_VALUE);

}

the message processor will display a "Hello" in the private chat box message on the receiving clients' user interfaces.

It should be noted that in the prior art, a similar interaction would have to have been statically programmed in the CVE application software. Thus, there would be no flexibility in the programming of different controls for this type of interaction. With the present invention, different control strategies can be defined in the message constraint field and the messages can be routed accordingly. The system is thus adaptive to different application with the present behavior programmable script interface.

Claims

1. A collaborative virtual environment system including: a server computer and one or more client computers; wherein said server computer includes a group of files describing a plurality of roles that may be assigned to users of the virtual environment, said roles each having a set of defined behaviors associated with them; and wherein, in order to enter the collaborative virtual environment, a user assumes one of said roles, and said server computer sends to the client computer of said user a role definition file including behaviour information for said selected role.

2. The collaborative virtual environment system of claim 1 , wherein when a user interacts in the collaborative virtual environment, a message is transmitted to the server to advise of the interaction, said message having a format determined by the behaviour activated by the interacting user's role.

3. The collaborative virtual environment system of claim 2, wherein behaviors of the user's role have message formatting information associated with them in the role definition file.

4. The collaborative virtual environment system of claim 2 or 3, wherein the server includes means for identifying the format of the message and means for processing the message in accordance with the message format.

5. The collaborative virtual environment system of claim 2, 3 or 4, wherein the message includes a constraint field therein, and wherein the server routes the message to other users based on the constraint field and on the current status of the collaborative virtual environment.

6. The collaborative virtual environment system of any of claims 2 to 5, wherein, on receiving an interaction message, the client computers determine responses of the user's role or other interactive entities in said collaborative virtual environment in accordance with a message definition that defines actions to be taken for a message of a set format.

7. The collaborative virtual environment system of any preceding claim, wherein the collaborative virtual environment includes interactive objects therein, and wherein each interactive object has a role definition file including one or more behaviours associated therewith.

8. The collaborative virtual environment system of any preceding claim, wherein a collaborative virtual environment application is defined by a set of collaboration management files which define the user selectable roles and behaviors, the roles and behaviors of interactive objects within the environment, and message processing rules, and wherein said server parses said collaboration management files and constructs the selectable roles, and the rules for message processing, from said collaboration management files.

9. The collaborative virtual environment system of any preceding claim, wherein the role definition file includes the name of the role, attributes of the role, and the behaviors of the role.

10. The system of any preceding claim, wherein a behavior of the role definition file defines the behavior's name, a parameter list for calling the behavior, and instructions for actions to be taken on calling the behavior.

11. The system of claim 10, wherein said instructions include one or more of: the setting of attribute values for the local environment in the client computer, the calling of other role/behavior pairs, and the generation of interaction messages to the server computer.

12. The system of claim 11 , wherein the format of the behavior generated interaction message includes the fields of: sender_role_name, behavior_name, senderJD, constraint, and message value.

13. The system of claim 5 or 12, wherein the constraint field comprises more than one constraint.

14. The system of claim 12, wherein the constraints are processed in accordance with a logical rule.

15. A collaborative virtual environment (CVE) system comprising a server and one or more client computers, in which a CVE application is generated by supplying the server with files for defining a three dimensional environment, and files that define the behaviour of the interactive entities within the CVE and that define rules to manage the interactions amongst the entities, said entities being categorised in accordance with their functional roles.

16. A collaborative virtual environment system comprising a server and one or more client computers, in which a CVE application is generated by supplying the server with a plurality of collaboration management files; wherein the server generates interaction management information, message routing rules and status storing rules from said collaboration management files; and wherein the client computers generate interaction observers, a local information storage, and rules for processing messages from said interaction management information in said server.

17. A collaborative virtual environment system including: a) a server computer and one or more client computers; b) a set of files defining a three dimensional environment and interactive objects within the environment; c) a set of collaboration management files including a scene description file that defines a set of roles selectable by interactive entities and provides message definitions for the processing of messages, and role definition files for the selectable roles which define the behaviors of the entities; d) a server program running on said server computer, which includes: a parser module that interprets the collaboration management files, and creates a memory storage of interaction management information and role definition files for all of the selectable roles described in the files; a status information storage module for keeping the current status of the collaborative virtual environment; and a message router for processing incoming messages from the client computer according to the interaction management information, said router writing new status information into the status information storage module, and resolving the destinations for interactive messages from the users in accordance with the interaction management information and the status information in the status information storage module; and e) a client communications program running on each client computer, which includes: a communications manager module for downloading a three dimensional virtual environment from the server, for sending a user's role selection to the server, and for retrieving a corresponding role definition from the server; an interaction observer module for monitoring the interactions of the user and processing the interactions according to the role definition received form the server; a local virtual environment information storage module for keeping the runtime status for the virtual environment; and a message processor module for listening for messages from the server computer and for processing the messages according to message definition information received from the server.

18. A method for generating a collaborative virtual environment, including the step of supplying a server computer with a package of files defining a pluraltiy of roles, a plurality of behaviors for said roles including information on the format of interactive messages, and a plurality of message definitions including information on how to process said interactive messages; wherein said server computer stores said roles, behaviors and message definitions therein, and generates message routing rules for said interactive messages from said message formats; wherein a client computer receives a role and associated behaviors from the server computer, together with said message definitions, when the client computer logs onto the environment; wherein a client computer generates messages in accordance with the message formats of the behavoirs and acts on messages received from the server in accordance with said message definitions; and wherein said server computer routes said messages to one or more appropriate client computers according to said message routing rules.

19. The method of claim 18, wherein said interactive messages include therein one or more constraints, and wherein said server computer generates said message routing rules in accordance with said constraints.