Prioritizing virtual object downloads in a distributed virtual environment

The present invention relates to virtual environments, and in particular to prioritizing virtual object downloads in a distributed virtual environment.

Computer simulations, such as video games, that feature a virtual environment are increasingly popular. Such simulations typically feature a computer-generated landscape made up of content virtual objects that may represent an actual or an imaginary location in a past, present, or future time. Users are represented in the virtual environment by avatar virtual objects. Users control the avatars on the landscape through client software that runs on a computing device. An avatar can typically roam the landscape and interact with other users' avatars and with other computer-generated virtual objects. Different host computers control respective regions in the virtual environment. Interactions between avatars and other virtual objects result in message traffic between the client software controlling the avatar and a host that controls the respective region in which the interactions are occurring. As the avatar moves from one region to another, the responsibility for handling message traffic associated with the avatar may move from one host to another host. The existence of regions and the transitioning of client-host interactions may be transparent to the user.

A single entity typically creates the landscape virtual objects that define the landscape associated with a virtual environment. The landscape may be very detailed, and the graphics required to depict the landscape may be very large. The landscape virtual objects are usually downloaded and stored on the client computer as part of an installation process of the respective simulation before the user can participate in the virtual environment. While participating in the virtual environment, the landscape is rendered by client software and presented to the user on a display device. Preloading the landscape of the virtual environment on the client computer prior to game play allows the landscape to be rendered and presented to the user quickly, which would be difficult or impossible if the landscape virtual objects were being transferred over a network during game play.

Distributed virtual environments executing on hosts that are not under the control of a single entity are being considered. In such a virtual environment, entities that have no relationship with one another may host adjacent regions in the virtual environment. One problem with such a distributed virtual environment is that it will be difficult or impossible to preload the landscape of the entire virtual environment on the client computer prior to participating in the virtual environment because the landscape itself can change as hosts come online or go offline. Consequently, the landscape will typically be downloaded on an ad-hoc basis. Downloading the landscape virtual objects, which may be sizable, will compete with downloading other virtual environment information, such as messages and other types of virtual objects that are necessary to provide the user a realistic experience. Merely halting movement of an avatar until the landscape associated with a host has been transferred over the network to the client computer would result in significant delays for the user and would not lead to a satisfactory virtual environment experience. However, failure to provide sufficient landscape detail while enabling the avatar to interact with other virtual objects would likewise not provide a realistic virtual environment experience. Moreover, the order of providing virtual objects must be consistent from a realism perspective. For example, it would be unrealistic to display a bird virtual object sitting in a tree prior to displaying the tree virtual object. Thus, there is a need for a virtual object prioritization process for downloading virtual objects in a distributed virtual environment that properly balances available bandwidth with competing virtual object download requirements to provide a realistic virtual environment experience.

The present invention relates to prioritizing virtual object downloads in a distributed virtual environment. A peer hosts a region in the distributed virtual environment that may include a plurality of virtual objects, including content virtual objects, computer-generated virtual objects exhibiting artificial intelligence, and avatar virtual objects. A client associated with an avatar connects to the peer. An area of interest associated with the avatar is determined, and a plurality of virtual objects within or proximate to the area of interest are identified. A list of identified virtual objects is created and prioritized, and the peer initiates a download of at least two of the virtual objects to the client according to the prioritized list. The client renders the virtual objects for display on a display device associated with a user.

Criteria for prioritizing the virtual objects can include, for example, a type of virtual object, a distance of each of the plurality of virtual objects from the avatar, a significance of the plurality of virtual objects to the avatar, an area of interest associated with the plurality of virtual objects, and an estimated time of visibility of the plurality of virtual objects by the avatar. Prioritizing the download of the identified virtual objects ensures that the virtual environment is rendered in an order that provides a realistic experience for the user. The list of prioritized virtual objects can be prioritized by the client, by the peer, or by the client based on input provided by the peer. If the area of interest of the avatar associated with the client includes regions hosted by more than one peer, one peer may communicate with other peers to determine virtual objects within the area of interest and provide a consolidated list of virtual objects to the client. Alternately, the client can connect to the multiple peers, receive a list of virtual objects based on the area of interest from each peer, and consolidate the lists into a consolidated list.

A client has a finite network bandwidth. According to one embodiment of the present invention, an available download rate associated with the client is determined, a minimum transfer rate for each virtual object is determined, and relatively concurrent downloads for virtual objects are initiated so long as the cumulative minimum transfer rate of the virtual objects being downloaded remains less than the available download rate of the client.

Those skilled in the art will appreciate the scope of the present invention and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the invention, and together with the description serve to explain the principles of the invention.

FIG. 1 is a schematic diagram illustrating a relationship between regions and peers in a virtual environment according to one embodiment of the present invention;

FIG. 2 is a schematic diagram illustrating a portion of the virtual environment illustrated in FIG. 1 in greater detail;

FIG. 3 is a message flow diagram illustrating message flows suitable for prioritizing virtual object downloads according to one embodiment of the present invention;

FIG. 4 is a message flow diagram illustrating certain aspects of the message flow diagram shown in FIG. 3 in greater detail;

FIG. 5 is a download plan table according to one embodiment of the present invention;

FIG. 6 is a download queue table according to one embodiment of the present invention;

FIG. 7 is a block diagram illustrating components of a peer according to one embodiment of the present invention; and

FIG. 8 is a block diagram illustrating components of a client according to one embodiment of the present invention.

The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

FIG. 1 is a schematic diagram illustrating a relationship between regions and peers in a virtual environment according to one embodiment of the present invention. A virtual environment 10 includes a plurality of regions 12 A- 12 G. For the sake of brevity, the regions 12 A- 12 G may be referred to herein singularly as the region 12 or collectively as the regions 12 where the discussion is not related to a specific region 12 A- 12 G. Each of the regions 12 depicts a particular area within the virtual environment 10 . While FIG. 1 shows eight regions 12 for purposes of illustration, the present invention is not limited to a particular number of regions 12 . Likewise, while the regions 12 illustrated in FIG. 1 have a relatively uniform and hexagonal shape for purposes of illustration, the regions 12 according to the present invention can have any size or shape, and each region 12 can have a different size and shape from the other regions 12 . Each region 12 is preferably contiguous with at least one other region 12 , and thus shares a border 14 with an adjacent region 12 . A two or three-dimensional landscape, or terrain, associated with each region 12 is made up of a plurality of content virtual objects. As is understood by those skilled in the art, a virtual object may comprise graphical content only, or may comprise graphical content as well as data and code that defines one or more behaviors associated with the virtual object.

One or more avatar virtual objects, such as avatars 16 A- 16 C, roam the virtual environment 10 . The avatars 16 A- 16 C may be referred to herein singularly as an avatar 16 or collectively as avatars 16 where the discussion is not related to a specific avatar 16 A- 16 C. An avatar 16 is a representation of a user and is controlled, via client software, by a respective user. Each region 12 A- 12 G is hosted by a respective peer 18 A- 18 G. The peers 18 A- 18 G may be referred to herein singularly as a peer 18 or collectively as peers 18 where the discussion is not related to a specific peer 18 A- 18 G. Each peer 18 is typically connected to another peer 18 hosting an adjacent region 12 via a peer connection 20 . The peer connections 20 can comprise any suitable communications path suitable for enabling communications between the peers 18 , including, for example, wired or wireless connections, and can be implemented in any combination of local area networks, wide area networks, or other types of networks. The peers 18 can use any suitable messaging protocol to communicate over the peer connections 20 including, for example, Transmission Control Protocol/Internet Protocol (TCP/IP). The peers 18 can comprise any suitable processing device sufficient to handle the functionality described herein. The peers 18 can comprise, for example, a general purpose computer, a cell phone, or a mobile gaming device running a Microsoft Windows or Linux operating system, and the functionality required to implement the peer 18 can comprise one or more software programs using a proprietary or conventional programming language, such as C, C++, or Java, for example.

Users control the avatars 16 A- 16 C via client software, referred to herein as clients, such as clients 22 A- 22 C. The clients 22 A- 22 C may be referred to herein singularly as a client 22 or collectively as clients 22 where the discussion is not related to a specific client 22 A- 22 C. The clients 22 have various responsibilities, including rendering the virtual objects in the virtual environment 10 for display to a respective user, manipulating an associated avatar 16 in accordance with the user's requests, initiating and terminating connections with one or more peers 18 as the respective avatar 16 moves from one region 12 to another region 12 , and handling messages generated by virtual activity occurring in the virtual environment 10 . The clients 22 can be implemented via a software program using a proprietary or conventional programming language that executes on a special or general purpose computing device, including a handheld gaming platform or a general purpose personal computer. Alternately, a portion or all of the functionality of the clients 22 can be implemented in an application-specific integrated circuit (ASIC) or firmware, as appropriate.

The clients 22 may have one or more connections, such as an event stream connection 24 , with one or more peers 18 to which they are currently connected. The event stream connection 24 can be used to communicate messages relating to events from the client 22 to the respective peer 18 , or vice versa. The peer 18 to which a client 22 is connected is typically determined by the location of the respective avatar 16 . For example, as the avatar 16 C approaches or crosses the border 14 separating the region 12 G from the region 12 C, the client 22 C may initiate a connection with the peer 18 G.

In conventional virtual environments, the content virtual objects that make up the landscape of the virtual environment are preloaded or pre-cached to a client, such as the client 22 C, so that the client 22 C has knowledge of the landscape associated with the region 12 C. Assuming appropriate processing power of the underlying computing device, the client 22 C is able to render the landscape of the region 12 C relatively quickly for the respective user. However, the client 22 C may not have knowledge of other virtual objects associated with the region 12 C, including other avatars 16 in the region 12 C, if any, and other computer-generated virtual objects in the region 12 C. Thus, when the client 22 C connects to the peer 18 C, the peer 18 C communicates, via messages, information to the client 22 C and transfers to the client 22 C virtual object data relating to avatars 16 and other virtual objects that may currently be in the region 12 C. This information is in turn received by the client 22 C and rendered for display to the respective user. All of this activity and the existence of the border 14 may be transparent to the respective user because the separation of the regions 12 may not be known to the user.

According to one embodiment of the present invention, the virtual environment 10 is a distributed virtual environment 10 and the peers 18 are not controlled by a single entity. The content virtual objects that make up the landscape of the regions 12 are not preloaded or pre-cached to the clients 22 . Each peer 18 may be permitted to implement a respective region 12 as desired, so long as the peers 18 do so in compliance with certain specifications that may include network, messaging, or other requirements associated with the virtual environment 10 to ensure compatibility with other peers 18 and to ensure a client 22 can reliably connect and communicate with a peer 18 as necessary. In such a distributed virtual environment 10 , it may be impossible to preload the content virtual objects on a client 22 because new peers 18 hosting newly created regions 12 may enter the virtual environment 10 at any time. Thus, the content virtual objects may be downloaded to the client 22 during game play. The phrase ‘game play’ will be used herein to describe the activity of a user participating in the virtual environment 10 , whether the virtual environment 10 is associated with a game or other type of simulation.

Unfortunately, content virtual objects may be quite large depending on the detail and resolution of the respective region 12 with which the content virtual objects are associated. In addition, not only are the content virtual objects downloaded to the client 22 , but other virtual objects, such as avatars 16 or computer-generated virtual objects, are also downloaded to the client 22 so such virtual objects can be rendered for the user. Depending on the bandwidth of the event stream connection 24 between the client 22 and the respective peer 18 , downloading the content and other virtual objects associated with a region 12 may take a relatively long period of time. However, it is unsatisfactory to a user if there is a significant delay in game play each time a respective avatar 16 approaches or crosses a border 14 .

FIG. 2 is a schematic diagram illustrating a portion of the virtual environment 10 illustrated in FIG. 1 . The avatars 16 A and 16 B are located in the region 12 G, and the avatar 16 C is located in the region 12 C. A plurality of other virtual objects 26 A- 26 F is present in the regions 12 G and 12 C. The virtual objects 26 A- 26 F may be referred to herein singularly as a virtual object 26 or collectively as virtual objects 26 where the discussion is not related to a specific virtual object 26 A- 26 F. Some of the virtual objects, such as the virtual objects 26 C and 26 D, are content virtual objects, and other virtual objects, such as the virtual objects 26 A, 26 B, 26 E, and 26 F, are computer-generated virtual objects that have dynamic behavior implemented via artificial intelligence modules executing on the respective peer 18 . An area of interest 28 associated with the avatar 16 B defines an area, or volume, about the avatar 16 B that defines the extent to which a perception of the avatar 16 B, such as sight, extends. More than one area of interest 28 may be associated with the avatar 16 B. For purposes of illustration, the area of interest 28 is shown as a radius about the avatar 16 B, but the area of interest 28 may be any size and shape, and is typically three dimensional. The shape and extent of the area of interest 28 may be based on any suitable factors, including sensory capabilities of the respective avatar 16 B. Moreover, the precise boundaries of the area of interest 28 may change depending on the circumstances and location of the avatar 16 B. The virtual environment 10 may use the area of interest 28 to determine which messages or virtual objects 26 within the virtual environment 10 are relevant to the client 22 B. For example, the avatar 16 B may not be able to view the dragon virtual object 26 E due to the distance of the dragon virtual object 26 E from the avatar 16 B. Since the dragon virtual object 26 E is outside of the area of interest 28 of the avatar 16 B, the peer 18 G may not provide the dragon virtual object 26 E or any messages associated with the dragon virtual object 26 E to the client 22 B.

The area of interest 28 may be determined by the client 22 B or by the peer 18 G to which the client 22 B is connected. Alternately, the determination of the area of interest 28 could be the result of a collaborative message exchange between the client 22 B and the peer 18 G. The area of interest 28 , as shown in FIG. 2 , overlaps the regions 12 G and 12 C. Content virtual objects can be provided from the respective peers 18 G and 18 C to the client 22 B over respective content stream connections 30 G and 30 C. Each of the clients 22 A- 22 C also has a respective event stream connection 24 with the respective peer 18 hosting the region 12 in which the respective avatar 16 is located. The separation of event stream traffic from content stream traffic is optional and is not necessary to practice the present invention. All data may be sent over the same connection. Where multiple connections are used, each connection is likely a separate logical channel that shares the same physical connection with all other logical connections. According to one embodiment of the present invention, when the client 22 B connects to the peer 18 G, a prioritized list of virtual objects 26 is created and virtual objects 26 are downloaded to the client 22 B in accordance with a download plan generated as a function of the prioritized list. The prioritized list is generally limited to the virtual objects 26 that are within or proximate to the area of interest 28 of the avatar 16 B associated with the client 22 B; however, depending on a significance or other criteria, one or more virtual objects 26 outside the area of interest 28 of the avatar 16 B may be downloaded to the client 22 B, if appropriate.

The client 22 B may provide the area of interest 28 of the avatar 16 B to the peer 18 G upon connection with the peer 18 G. For purposes of illustration, assume the client 22 B has never connected to the peer 18 G before, and thus has no information about the region 12 G. The peer 18 G can determine that the virtual objects 26 B and 26 C and the avatar 16 A are within the area of interest 28 of the avatar 16 B. The peer 18 G can provide a list of the virtual objects 26 B and 26 C and the avatar 16 A to the client 22 B, as well as virtual objects 26 that are not within the area of interest 28 of the avatar 16 B but that may be relevant to the avatar 16 B because of their significance. The peer 18 G can also provide information relevant to prioritizing the download of the virtual objects 26 identified in the list. Such prioritization information can include one or more of the following prioritization criteria:

1. visibility or distance of the respective virtual object 26 to the avatar 16 B; 2. estimated time when the respective virtual object 26 will be within the area of interest 28 of the avatar 16 B, based on one or both of the current movement path of the respective virtual object 26 and the current movement path of the avatar 16 B; 3. a significance criteria of the respective virtual object 26 to the avatar 16 B (dangerous or highly valuable objects may have a higher priority); 4. recommendations by the peer 18 G based on a past history of interactions between the respective virtual object 26 and other avatars 16 ; 5. an area of interest 28 of the respective virtual object 26 (for example, where the avatar 16 B is within the area of interest 28 of the virtual object 26 even though the virtual object 26 is not within the area of interest 28 of the avatar 16 B); 6. if the peer 18 G is aware that the client 22 B has given a particular type of virtual object 26 a higher priority in the past; 7. a number of instances of a respective virtual object 26 (more instances of a respective virtual object 26 , such as the three butterflies associated with the virtual object 26 F, may be given a higher priority); 8. a fixed significance criteria (for example, certain virtual objects 26 , such as the content virtual objects 26 C and 26 D, may have a high or maximum priority, since it may be nonsensical to render a non-content virtual object 26 until at least a portion of the landscape has been rendered); or 9. a differentiated priority can be assigned to a composite virtual object 26 (for example, a virtual object 26 consisting of other component virtual objects 26 ). For example, a house virtual object 26 may consist of multiple virtual objects 26 depicting the outside and the inside of the house. However, unless an avatar 16 enters the house virtual object 26 , the virtual objects 26 that depict the interior of the house need not be downloaded.

The prioritization criteria referenced herein are examples only, and the present invention is not limited to those mentioned. The client 22 B determines that the area of interest 28 of the avatar 16 B also overlaps the region 12 C. The client 22 B connects to the peer 18 C and provides the area of interest 28 to the peer 18 C. The peer 18 C determines that the avatar 16 C, and the virtual objects 26 D and 26 F, are within the area of interest 28 of the avatar 16 B. The peer 18 C also determines that a dragon virtual object 26 E is located just outside of but proximate to the area of interest 28 of the avatar 16 B and, due to the potential significance of the dragon virtual object 26 E to the avatar 16 B, the peer 18 C includes the dragon virtual object 26 E in the list of virtual objects 26 provided to the client 22 B.

The client 22 B receives the list of virtual objects 26 from the peers 18 C and 18 G and prioritizes the list based on one or more of the prioritization criteria described above. The client 22 B may generate a prioritization download plan table that includes data such as an identification of the virtual objects 26 , a priority of the virtual objects 26 , and a time by which the respective virtual object 26 should be completely downloaded to the client 22 B. The client 22 B may also generate a download queue table that includes similar information, but on a peer-by-peer basis. The client 22 B can initiate the download of multiple virtual objects 26 from the peers 18 C and 18 G, and can render the virtual objects 26 for the user associated with the client 22 B.

For example, a prioritized list of the virtual objects 26 to download may be in the following order according to one embodiment of the present invention:

1. the content virtual object 26 C (priority 100 ), because a content virtual object 26 relates to the landscape associated with the region 12 G and has a maximum priority of 100; 2. the virtual object 26 B (priority 95 ), because of its proximity to the avatar 16 B; 3. the avatar 16 A (priority 90 ), because the avatar 16 A is the closest avatar 16 to the avatar 16 B; 4. the avatar 16 C (priority 90 ), because the avatar 16 C coincidentally is in the same social network as the avatar 16 B; 5. the virtual object 26 D (priority 80 ), because the avatar 16 B is near the region 12 C; 6. the virtual object 26 F (priority 75 ), because the virtual object 26 F has multiple instances; and 7. the virtual object 26 E (priority 50 ), because, while distant, the virtual object 26 E is potentially dangerous to the avatar 16 B.

FIG. 3 is a message flow diagram illustrating message flows suitable for prioritizing virtual object downloads according to one embodiment of the present invention. The client 22 B determines that an area of interest 28 of the avatar 16 B associated with the client 22 B encompasses the peers 18 G and 18 C, and provides the area of interest 28 to the peer 18 G and to the peer 18 C (steps 100 and 102 ). The peer 18 G uses the area of interest 28 to determine which virtual objects 26 in the region 12 G are within or proximate to the area of interest 28 . The peer 18 G generates a list identifying such virtual objects 26 and provides prioritization criteria for each virtual object 26 in the list (step 104 A). The peer 18 C follows a similar process with respect to virtual objects 26 in the region 12 C in or proximate to the area of interest 28 (step 104 B). The peer 18 G communicates to the client 22 B the virtual object list (VO_LIST) associated with the peer 18 G (step 106 ), and the peer 18 C communicates to the client 22 B the virtual object list associated with the peer 18 C (step 108 ). The client 22 B can consolidate the virtual object lists from the peers 18 G and 18 C, use the prioritization criteria provided by the peers 18 G and 18 C and any other prioritization criteria known to the client 22 B, and generate a prioritized list of virtual objects 26 for downloading to the client 22 B (step 110 ). In an alternate embodiment, the peers 18 G and 18 C can prioritize the virtual object lists, and provide the prioritized virtual object lists to the client 22 B. In yet another embodiment, in a situation where, as described herein, the area of interest 28 overlaps multiple peers 18 , one peer 18 can receive prioritized virtual object lists, consolidate the lists into a single prioritized virtual object list, and provide the consolidated list to the client 22 B.

The client 22 B calculates an available bandwidth associated with the client 22 B, and reserves a portion of the available bandwidth for event traffic (step 112 ). The available bandwidth is typically determined as a function of bandwidth of the network to which the client 22 B is connected. Mechanisms for determining available bandwidth are known to those skilled in the art and will not be discussed in detail herein. The client 22 B can generate a download plan table containing the consolidated list of virtual objects 26 in a prioritized order (step 114 ). The client 22 B can use the download plan table to determine which virtual objects 26 should be transferred from which peers 18 and in what order. The client 22 B initiates a download virtual object request (DOWNLOAD_VO_REQUEST) to the peers 18 G and 18 C (steps 116 and 118 ). The peers 18 G and 18 C then initiate downloads of the requested virtual objects 26 (VO_DOWNLOAD) to the client 22 B (steps 120 and 122 ). The client 22 B monitors the download progress of the virtual objects 26 (step 124 ), and periodically provides download status messages (VO_DOWNLOAD_STATUS) to the peers 18 G and 18 C (steps 126 and 128 ). The peers 18 G and 18 C can use the download status messages to alter the transfer rate of the virtual objects 26 as appropriate.

FIG. 4 is a message flow diagram illustrating certain aspects of the message flow diagram shown in FIG. 3 in greater detail, and specifically illustrates in greater detail functionality associated with the peer 18 G upon receiving a request to download a virtual object 26 . The client 22 B sends a download virtual object request to the peer 18 G (step 200 ). The download virtual object request can include a virtual object identifier (VO_ID) and additional information, such as a required download rate (REQ_DOWNLOAD_RATE), or a required time of arrival of the virtual object 26 associated with the virtual object identifier associated with the client 22 B. The peer 18 G can determine the bandwidth associated with the client 22 B and, using one or both of the provided download rate and the required time of arrival, can determine an optimal schedule for downloading the virtual object 26 to the client 22 B (step 202 ). The schedule can include information including size and frequency of packets to ensure that the virtual object 26 arrives at the client 22 B ahead of the required time of arrival. The peer 18 G begins the virtual object 26 download (step 204 ). The client 22 B can periodically provide a virtual object 26 download status to the peer 18 G (step 206 ). The peer 18 G obtains the virtual object 26 download status and can determine if the progress of the virtual object 26 download is consistent with providing the virtual object 26 in advance of the time that the virtual object 26 is required to be downloaded to the client 22 B. If it is determined that the progress is not consistent with providing the virtual object 26 in advance of the time that the virtual object 26 is required to be downloaded to the client 22 B, then the peer 18 G can change the download schedule to increase the packet size or the number of messages transferred within a given period of time as required to ensure that the virtual object 26 will be downloaded to the client 22 B in the appropriate time frame (step 208 ).

FIG. 5 is a download plan table 40 according to one embodiment of the present invention. The download plan table 40 is typically assembled by a client 22 but, according to another embodiment of the present invention, the download plan table 40 can be assembled by a peer 18 and provided to the client 22 . The download plan table 40 can include data fields such as a Virtual Object ID field 42 identifying virtual objects 26 by internal identifiers known to the virtual environment 10 . A Hosting Peer ID field 44 can identify the respective peer 18 that contains the respective virtual object 26 . A Total Size field 46 can indicate the size of the respective virtual object 26 . A Remaining Size field 48 can indicate the amount of the respective virtual object 26 that remains to be downloaded to the client 22 . A Required Time of Arrival (RTA) field 50 can indicate a time by which the respective virtual object 26 must be downloaded to the client 22 . The RTA field 50 can be determined by mechanisms known to those skilled in the art including, for example, dead reckoning. A Priority field 52 can indicate the prioritization assigned to the respective virtual object 26 . A Transfer Rate Progress field 54 can include subfields such as an Available field 56 indicating a total upload bandwidth available from the respective peer 18 for the respective client 22 . A Required field 58 indicates a bandwidth determined by the client 22 that is necessary to meet the time of arrival value in the RTA field 50 . An Observed field 60 indicates that actual observed transfer rate.

FIG. 6 is a download queue table 70 that may be generated by a client 22 according to one embodiment of the present invention. The download queue table 70 contains many of the same fields as the download plan table 40 illustrated in FIG. 5 . However, the download queue table 70 contains a single row for each separate peer 18 that has a virtual object 26 that needs to be downloaded to the client 22 . In addition to the fields discussed above with respect to the download plan table 40 , the download queue table 70 can include a Total Bandwidth field 72 . The Total Bandwidth field 72 identifies the total client 22 bandwidth being used for the concurrent download of virtual objects 26 from the peers 18 that are downloading virtual objects 26 to the client 22 . The download queue table 70 can also include a Total Download Bandwidth Available field 74 indicating the total download bandwidth available to the client 22 . An Event Traffic Bandwidth Required field 76 identifies the amount of bandwidth that must be reserved for event traffic. A Content Download Bandwidth Available field 78 can indicate a difference between the Total Download Bandwidth Available field 74 and the Event Traffic Bandwidth Required field 76 , identifying that bandwidth which is available for downloads of virtual objects 26 . According to one embodiment of the present invention, the client 22 preferably initiates concurrent downloads so long as the cumulative rate of the individual virtual object 26 downloads remains less than the content download bandwidth available. As will be appreciated by those skilled in the art, the apportionment of total download bandwidth between the Event Traffic Bandwidth Required field 76 and the Content Download Bandwidth Available field 78 can change as appropriate depending on the circumstances of the avatar 16 associated with the client 22 . For example, if the avatar 16 is in a region 12 of the virtual environment 10 where there are few or no other virtual objects 26 , it may be appropriate to reduce the amount of bandwidth apportioned to the Event Traffic Bandwidth Required field 76 and increase the amount of bandwidth apportioned to the Content Download Bandwidth Available field 78 .

FIG. 7 is a block diagram illustrating components of a peer 18 according to one embodiment of the present invention. A control system 80 includes a memory 82 that contains software 84 suitable for implementing the functionality described herein. An interface 86 is capable of communicating over a network with other peers 18 and clients 22 , as appropriate.

FIG. 8 is a block diagram illustrating components of a client 22 according to one embodiment of the present invention. A control system 88 includes a memory 90 that contains software 92 suitable for implementing the functionality described herein. An interface 94 is adapted to communicate with peers 18 and clients 22 over a network, as appropriate.

While for purposes of illustration the invention has been described herein with reference to prioritizing downloads based on an area of interest 28 associated with an avatar 16 , it will be apparent to those skilled in the art that the prioritization of virtual objects can also apply to other types of virtual objects that may have associated areas of interest, such as virtual objects that are controlled by artificial intelligence modules of one or more peers 18 , such as virtual object cats, or horses, as may be appropriate for a particular virtual environment.

Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.