Patent Publication Number: US-8126985-B1

Title: Prioritizing virtual object downloads in a distributed virtual environment

Description:
FIELD OF THE INVENTION 
     The present invention relates to virtual environments, and in particular to prioritizing virtual object downloads in a distributed virtual environment. 
     BACKGROUND OF THE INVENTION 
     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&#39; 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. 
     SUMMARY OF THE INVENTION 
     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. 
    
    
     
       BRIEF DESCRIPTION OF THE 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. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     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&#39;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.