U.S. Pat. No. 9,403,090

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

State of the Art Systems

Turning toFIG. 1a, a large multiuser online game system100over a public network1050, such as the Internet, is shown. An example of such a game system100known in the art is League of Legends (www.leagueoflegends.com). League of Legends is a session-based, multiplayer online battle-arena game where rival teams compete against one another for victory on highly stylized battlefields and landscapes. Users can install a League of Legends game client on their personal computing device110to establish a game session over the public network1050with the game system's100datacenter130, which provides the real-time online game interaction with the plurality of users110.

Turning toFIG. 1b, an example game client110user interface is shown. In online games such as League of Legends, each user is generally represented by a personalized graphical avatar in the user interface, also referred to as “champion,” (shown as “X” in this example), and the game client110user interface may show the logical position of one user's avatar, X User 1, relative to another, X User 2 and X User 3 within a virtual landscape. The game client110user interface may also include a chat interface (“Chat Room”) that enables participating users to communicate with one another beyond interactions with the avatars (Xs).

The datacenter130(FIG. 1a) includes a plurality of server systems operating on a plurality of server machines communicatively coupled to each other via the public network1050and/or a secure virtual private network (not shown). The server machines each includes one or more processors, memory, an operating system, one or more input/output interfaces and one or more network interfaces all known in the art. According to an embodiment, the datacenter130includes, among other things, a game session server system140.

Turning toFIG. 1c, a more detailed diagram of a game session server system140known in the art is shown. The game session server system140provides the game interaction with the users' game client110via the game client interface143, which is generally an application interface known in the art accessible over the public network1050by the game client110, e.g., in a traditional client server model. A game engine142coupled to the game client interface143is included to manage the interaction among the plurality of users110, and between the plurality of users110and the game system100. As one of ordinary skill in the art can appreciate, highly stylized user interfaces often contain graphics requiring large amounts of data. Transmitting such graphics over the public network1050may cause slow performance due to the limited available bandwidth of the public network1050. One approach to address this is to have the graphics rendered by the game client on the user's computing device110. To account for movements and changes to players in the game, only certain information is transmitted over the public network1050between the game clients110and the game engine142, e.g., coordinates of various players within the landscape of the game.

Turning toFIG. 1d, such data can be transmitted efficiently in blocks of data packets collectively known as “chunks,” an example format of which is shown inFIG. 1d. A chunk150generally includes the latest coordinates within the virtual landscape of certain users, a time stamp to enable the game engine142to synchronize data among players, and additional game data to facilitate rendering, such as weapons and powers that have been added or removed or other information to reflect the latest state of a player's avatar. A game client110will use the data in the chunk to render, among other things, the appropriate graphics and visual representations of the positioning of the avatars within the virtual landscape. If a user makes a change to its avatar state on its client110, e.g., if the user moves its avatar or adds a power, one or more chunks150may be transmitted back to the game engine142to update the remaining players and to update rendering on the devices110of the remaining players. The chunk150enables responsive, high-performance real-time game play with highly stylized graphics over a public network1050of limited bandwidth since the graphics are rendered on the game client110and only limited data is transmitted for game interaction. In an embodiment, a chunk150for a particular user will not include all data for the game session but only data limited to the user's view. For example, turning toFIG. 1b, a rock or tree may hide another avatar in the virtual landscape from the first user's view. To maintain this context and competitive play, the hidden user's coordinates may not be included in the chunks sent to the first user until the hidden user is revealed during game play (e.g., the other user may move its hidden avatar into an opening unblocked by the rock or tree).

Turning back toFIG. 1c, the game session server system140further includes a chat engine144known in the art that enables the various users at game clients110participating in a particular game session to communicate with each other via text messages. Audio, pictures, and multimedia may also be exchanged with the chat engine144. Both the game engine142interactions as well as the chat messages exchanged can be recorded and stored in a game files database141. This enables, among other things, replay and history analysis by not only the users but also the administrator and other systems as will be described below.

Preferred Systems

Turning toFIG. 2, an online multi-user game system1000according to an embodiment of the present invention is shown. The system1000provides an enhanced player and spectator experience as will be described below. The system1000includes a datacenter130having a game session server system140as described above. The system1000also includes game clients110configured to access data center130over the public network as described above. According to an embodiment, the system1000further includes a spectator grid1100operatively coupled to the game session server system140that enables a user with a spectator client1200to access the data center130and select an active game session to view as a spectator. The spectator grid1100is also implemented as a server system. The spectator client1200includes a similar graphics rendering application as the game client110but with no ability to actively participate in the selected game.

Turning toFIG. 3, a detailed diagram of a spectator grid1100is shown. The spectator grid includes an in-game database1110that is configured to receive game data, e.g., game chunks150, from the game session server system140via a game session server interface1120. These game chunks150may include global data, e.g., positioning coordinates for avatars whether hidden or not, within the virtual landscape of a game session. The in-game database1110may utilize an in-memory coherence cache, thereby enabling faster querying of the database1110in real time. The spectator grid1100further includes a spectator engine1130configured to interface with spectator clients1200via a spectator interface1140and provide game data to the spectator clients1200from the in-game database1110.

Preferred Processes

Turning toFIG. 4, a process2000according to an embodiment is shown. As mentioned above, fans of certain multi-user online games may wish to be spectators of particular active games, as with any competitive game. To address this need, the game system1000enables a user to view active game sessions within the system1000. Turning toFIG. 5, an exemplary interface for a spectator client1200is shown. When a user connects to the data center130, one or more lists of active games are provided. They can be grouped into a variety of categories, including, active games having the most spectators, active games played by most requested players, i.e., players that most spectators have requested viewing of, e.g., players known as having exceptional skills. The data that enable these lists can be tracked and deduced by previous spectators' selections, which can be stored in the database1110of the spectator grid1100. Games can also be presented by specific game identification and/or player identification (regardless of whether such a player is well-known). Moreover, the game system1000, e.g., the spectator grid1100, can monitor certain activities within an active game. For example, the spectator grid1100can monitor for games having scores that are very competitive, for games that have a particularly high number of known or higher tiered champions, for players that are playing at a particularly high level, and/or for players that are demonstrating particularly unusual and/or entertainment techniques or moves. The spectator grid1100can identify such games as recommended games for potential spectators. Games can also be listed in random order. Games can also be listed by particular events, e.g., an organized tournament.

Turning back toFIG. 4, once a spectator has selected a particular active game to view, the spectator grid1100receives the request (Action Block2100) and establishes a data connection with the spectator's client1200(Action Block2200) to transmit game data to the client1200in streaming fashion (Action Block2600) to be rendered on the spectator client1200in real-time or near real-time to the selected active game. Turning toFIG. 6, an example format1500is shown for game data transmitted by the spectator grid1100to the spectator client1200. What is shown, in an embodiment, is that game chunks150are sent to the spectator client1200with similar structure and content to the game chunks150sent to game clients110. One difference in this embodiment is that the game chunks150sent to the spectator client1200includes complete data for the active game being viewed. For example, all player positions are provided, including the ones that are hidden, so that the spectator is provided an omnipresent view.

Once the chunks150are received, the spectator client1200can generate the same graphics and visual representations of the active game in real-time or near real time of the active game.

Also included in the data format1500are keyframes, which are effectively snapshots of a particular game at a particular point in time. A keyframe is aligned with a fixed group of chunks150, e.g., 3, to define a time interval using the time stamps in the chunks150. A keyframe can be generated by creating a chunk150that includes game data packets for all players that exist at a given time. When a keyframe is loaded onto a spectator client1200, then the latest game data, e.g. the latest scene, along with all of the entity data that are known by the spectator client1200at that time, e.g., avatar and computer controlled object data, are deleted. The keyframe can then be played back as a regular chunk150, which renders the entity data that exist at that point in time at their correct positions. The chunk150that corresponds to the keyframe's point in time is then loaded as the next chunk to render. From there, chunks150can be rendered in chronological order. The amount of game play time represented by a chunk150is configurable by the system's1000administrator, for example, approximately 30 seconds.

One aspect of the keyframes is the enablement of time-shifting features for the live game (Action Block2700). For instance, an active game session rendered from the chunks150at a previous point of time can be quickly simulated by jumping to specific keyframes instead of individual chunks150. In an embodiment, when jumping to specific keyframes, much of the game processing can be disabled, such as rendering and sound, to enable faster jumps. Once a keyframe is reached, then normal playback and rendering is enabled, as described above.

Turning toFIG. 7, to illustrate exemplary time shifting controls enabled by the system1000(Action Block2700), a user interface for a spectator client1200viewing an active game session is shown. As mentioned above, the chunks150enable the spectator client1200to render real-time, or in near real-time fashion, game play from an active game, but with an omnipresent view that enables the spectator to view all game play within the virtual landscape. Moreover, certain time-shifting controls can be enabled. The following are examples.

Jump Back1210—This button allows the spectator to jump back a fixed amount of time, similar to an “instant replay” feature. In this case, the spectator client1200can jump to the keyframe of the requested point in time, and render the associated game chunks150as described above.

Play/Pause1220—This button will pause the game if it is playing, or play the active game session from the specific point in time where it was last paused, if it is paused.

Playback Speed1230—The “+” and “−” buttons will increase and decrease the speed that the game is playing at, respectively, and the playback speed “1×” can be displayed. The use of keyframes may be particularly helpful in performance of this feature, as described above.

Time control scrubber bar1240—this area represents the time that is in the past for the game. It can be clicked on to set the time back to an earlier time. A tooltip that shows what time the user will jump to when hovering over this bar can be included (not shown).

Time control scrubber position1250—This is the current point in time that is being played.

Viewed time1260—This area of the bar indicates time that is in the future that is before the latest point in time that the user has already seen. It can be clicked on to jump to a point in time in the future.

Unviewed time1270—This area indicates the period of time that is available to jump to but that the user has not seen yet. This time can also be clicked.

Jump to latest1280—This button, when pressed, will jump to the latest point of time that the user has viewed, as indicated by the highlighted position at the end of1260. If the user is already playing back from this point, it will move the user to the latest point in time available, at the end of1270.

The display at1290indicates the current point in time that the user is watching and the maximum available time that the user can access, respectively.

In addition to the controls above, a spectator may select any area of the virtual landscape, which can be expansive, to view at any time, and can further select a particular player for the camera view to automatically follow. For instance, the spectator can mouse click on a particular player in the game, and the spectator's camera view can follow that player automatically. This can be achieved by having the spectator client1200focus on that player's data within the received chunks150, either real-time, or at a selected time. Further, the spectator can switch from player to player at any time.

Turning back toFIG. 4, because the spectator's view is omnipresent, a player may be able to use that spectator's view to its advantage to obtain additional information about other players in the game. To prevent this, a delay may be configured (Decision Block2300). If configured, then the spectator grid1100may buffer the chunks by a certain amount of time, e.g., 30 seconds, before transmitting such data to a spectator, thereby enabling a delay, which would remove the incentive for an active player to attempt to view the game in spectator mode.

Moreover, the delay enables the spectator grid1100and/or spectator client1200to analyze the most recent data and notify the spectator of upcoming events that may be of interest to the spectator. For instance, the virtual landscape of a game may be too large to view in detail in its entirety on a spectator client's1200screen, and the various avatars may be moving in any different direction. At any given moment, an event could occur, such as a special move or a special achievement outside the spectator's current camera view. Example events include champion defeats, champion damage, events that lead up to champion defeat and/or damage, and game specific events such as the completion of important team-based objectives, and status of key objects within the game, such as status of key computer controlled avatars or objects. To maintain focus on the key events, the spectator grid1100and/or spectator client1200can be configured to monitor for such activities within the buffer (which occur on the spectator's client1200at a configurable time later, e.g., 30 seconds) and cause the spectator's view to focus on those specific activities when they develop and/or occur on the spectator's client1200. This directed view (Action Block2500) will ensure that the spectator does not miss key events as they unfold.

Turning toFIG. 8, a more detailed illustration of a directed view process (Action Block2500) is shown. In general, one approach to ensure that a spectator's view (e.g., as shown inFIG. 7) is focused on key activities and events within an active game is to follow one or more champions that are associated with those events and activities. Which champion to follow can be dictated by a calculated “interest level” for each champion. Generally, a champion's interest level correlates with the distance between that champion and the key activities and events described above when they occur and/or as they develop. In League of Legends, factors used to calculate a champion's interest level include, for example: proximity of other champions within the virtual landscape; current health level; presence of debuffs (i.e., an effect given to a champion that decreases performance); participating in future events like damaging and/or defeating other champions or important team objectives; interaction with terrain elements, champion activities like stealthing and recalling to base, and so on.

In an embodiment, the buffered data from Action Block2400is monitored (e.g., in 10 second increments) for data, such as that described above, to calculate an interest level for each champion within an active game (Action Block2510). The spectator grid1100and/or spectator client1200then directs the spectator client's1200view to follow the champion having the highest interest level (Action Block2520). The view is adjusted to also encompass nearby champions as well, to provide as full view of the activities as possible. The spectator grid1100and/or spectator client1200then continues to monitor the most current buffer for data that affects the interest level calculations (Action Block2530).

If activities develop during the game that cause another champion to have a higher interest level, then the spectator grid1100and/or spectator client1200may shift the spectator client's1200view to the new champion. However, if the identity of the champion with the highest interest level shifts frequently, it may not be desirable to have the spectator client's view1200shift at the same frequency. To address this, hysteresis may be incorporated. For instance, if a new champion gains status as having the highest interest level (Decision Block2540), then additional thresholds are evaluated to assess whether to shift the spectator client's1200view (Decision Block2550).

A number of threshold values may be utilized. For instance, even if a new champion gains status as having highest interest level, a spectator client's1200view may not adjust until the new champion's interest level is a certain percentage higher over the interest level of the previous champion with the highest interest level (e.g., 20%). Another threshold is a fixed value that the interest level of the new champion must exceed. These thresholds may decay over time after each shift in view and eventually settle at a minimum value until the next shift in view.

These thresholds, in combination with the interest for important future events ramping up linearly, ensure that the camera will switch early and provide a lot of context to an event during periods of low interest elsewhere in the virtual landscape. When there are high levels of activity occurring in other locations, the shift may not occur until just a few seconds before the upcoming important event occurs to ensure that the spectator client's1200view captures all key events properly.

Turning toFIG. 9, another exemplary user interface3000for a spectator client1200viewing an active game session is shown. As described above, the chunks150enable the spectator client1200to render real-time, or in near real-time fashion, game play from an active game, but with an omnipresent view that enables the spectator to view all game play within the virtual landscape. Having the omnipresent view of the game session, the spectator client1200may display a team status (or team fight) bar3100. The ability to display the status bar3100may be configurable by an administrator of the system1000. For example, the administrator may enable viewing of the status bar3100only for the game broadcaster (or commentator), or for one or more game spectators (in the latter situation, the game broadcaster and other game spectators may see the same status bar3100. The description herein thus refers to spectator as both game broadcaster and game spectators, unless otherwise indicated). The administrator may also enable the status bar3100to be displayed automatically as a default, not to be displayed as a default, or to be displayed only during directed camera mode as a default. The status bar3100may be displayed with or without the shifting controls (shown inFIG. 7).

The status bar3100displays certain summary information of each champion of each team, e.g., of all 10 champions in a 5×5 game session, showing the champions of a team in a group (e.g., on the left) and the champions of the opposing team in another group (e.g., on the right). The status bar3100helps the spectator quickly follow and understand the game session, or helps the spectator understand certain information without the help of a game broadcaster, who (if present) may want to focus on other aspects of the game session. In an embodiment, the spectator may manually toggle, e.g., by pressing a key or combination of keys, the display of the status bar3100on or off. Or the spectator may disable and enable one or more information display in the status bar3110. The information displayed in the status bar3100may include, for example:

Team Health bars3110—This information helps the spectator see which team is winning and aggregates the health of the champions and/or units into a single representation. The team health bar3110may be calculated proportionally, i.e., high-health champions or units represent a greater proportion of the team health bar over low-health champions. Or the team health bar3110may be scaled so low and high health champions represent an equal proportion of the health bar3110. This will help the health bar fulfill its core role of communicating who is winning in team fights.

Death Timer3120—This information helps the spectator see which champion is dead and the associated death timer, which when reaches zero the champion is revived.

Pentakill Counter3130—This information helps the spectator see which champion or unit is making kills.

Loss of Control icon3140—This information helps the spectator see the stuns and other powerful hard-to-read effects on a champion or unit.

Ultimate/Summoner Spell Status3150—This information helps the spectator understand high-power, high-cooldown plays. The Spell status3150may pulse when the ultimate/summoner spell is activated.

Another example of information that may be displayed in the status bar include the aggregate number of units and/or the number of units that were in the spectator's field of view that have been destroyed within a predetermined period of time. For example, if there were 100 tank units in the spectator's field of view initially, then 10 units were destroyed in a predetermined time period, the loss of 10 of those units may be identified. If combinations of distinct unit types have unique abilities that are only available when the distinct unit types are within a predetermined proximity, the availability of these unique abilities may be displayed as well. For example, if a repair unit has a special “tank repair” ability that is only available when in proximity to a tank unit, such ability may be displayed when the repair unit and the tank unit are within the predetermined proximity.

Turning toFIG. 10, another exemplary user interface4000for a spectator client1200viewing an active game session is shown. In the user interface4000, the spectator client1200displays a team status (or laning status) bar4100. The status bar4100includes information as shown in the status bar3100above, for example, Death Timer3120, Spell Status3150, and so on. In addition, the Health bars4110further differentiates the health4111of champions that are nearer to the spectator client's1200view, and the health4112of champions that are farther from the spectator client's1200view, e.g., by showing brighter versus darker shades respectively. The threshold definition of near versus far may be configurable by the administrator of the system1000, or by the spectator, as will be described in more detail below. The display of each champion in the status bar4100also differentiates near champions and far champions. For example, a near champion4120has a brighter display and/or a different border, e.g., a silver border. The far champion4121has a darker display and/or border.

Turning toFIG. 11, another illustration of a directed view process (Action Block2500) is shown. The system1000may automatically set the conditions and criteria for information to be displayed by the spectator client1200. The conditions and criteria may also be configured by the administrator, and may also change during a game session. For example, certain conditions and/or criteria during a game session may trigger the spectator client1200to display the status bar3100,4100, e.g., changing from a global view to a view including the status bar3100,4100. The conditions include, for example, number of champions (e.g., 6 of 10) within a certain area of the virtual landscape, abilities used, champions being targeted, damage done to champions, and so on.

The system1000may also define conditions and/or criteria for including or excluding certain champions, or for including or excluding information of certain champions in the status bar3100,4100. These conditions and criteria include, but are not limited to, selection of multiple targets (e.g., champions) based on visibility, and de-selection of multiple targets (e.g., champions) based on visibility.

Selection of Multiple Targets Based on Visibility—

The system1000may select to display multiple entities, e.g., champions, based on visibility status (Action Block5100). This selection may produce a list of targets of interest. The criteria for such selection may include, but are not limited to:

The target is currently visible.Visibility+range: The target is visible or would be visible if it were moved a pre-determined distance towards the nearest point on the border of the visible range or a pre-determined distance from the center of the visual range.Visibility−range: The target is visible and would be visible if it were moved a pre-determined distance towards the nearest point on the border of the visible range or a pre-determined distance from the center of the visual range.Wounded: The targets are not at full health.In-Combat: Only targets that have caused damage to an enemy, or received damage from an enemy, within a recently defined time period.Attacking: Only targets that are currently considered to be attacking, for example, targets that have fired a shot or used an offensive ability that is targeted at an enemy.

Two or more of the above criteria may be simultaneously selected.

De-Selection of Multiple Targets Based on Visibility—

Having a list of selected targets for display (Action Block5300), the system1000may de-select one or more targets based on visibility (Decision Block5400). The criteria for such de-selection may include, but are not limited to:

The target is not currently visible.Visibility+range: The target is not visible and would not be visible if it were moved a pre-determined distance towards the nearest point on the border of the visible range.Visibility−range: The target is not visible or would not be visible if it were moved a pre-determined distance towards the nearest point on the border of the visible range.

In order to prevent rapid oscillation of targets between the selected and not-selected states, the system1000may provide buffering of targets' information (Action Block5200and5500). The buffering may be done at the spectator grid1100, the spectator client1200, or at both the spectator grid1100and the spectator client1200. The buffering may be based on, but are not limited to:

Buffering Selection Based on Time:

Buffering is triggered when a target that is not selected becomes selected by a selection algorithm (for example, an algorithm described above) (Action Block5200). Instead of selecting the target, the target is instead flagged with a timer stating it may be selected after a pre-determined period of time (e.g., 5 seconds). Periodically, the target is evaluated by the selection algorithm. If the algorithm does not select the target, the timer is cleared. When the timer expires, the target is selected.

Buffering De-Selection Based on Time:

Buffering is triggered when a target that is selected becomes de-selected by a de-selection algorithm (for example, an algorithm described above) (Action Block5500). Instead of de-selecting the target, the target is instead flagged with a timer stating it may be de-selected after a pre-determined period of time (e.g., 5 seconds). Periodically, the target is evaluated by the de-selection algorithm. If the algorithm does not de-select the target, the timer is cleared. When the timer expires, the target is de-selected.

Buffering Selection Based on Distance:

When selecting a target based on visibility and de-selecting a target based on visibility, as described above, range based buffering (Action Block5200) is achieved by using a smaller range for selection than is used for de-selection.

Buffering De-Selection Based on Distance:

When selecting a target based on visibility and de-selecting a target based on visibility, as described above, range based buffering (Action Block5500) is achieved by using a larger range for selection than is used for de-selection.

The above methods of buffering selection and/or de-selection may be combined to smooth the selection and/or de-selection.

When the system1000selects multiple targets for display, statistics may be displayed for all selected targets in aggregate. For example, the combined health of multiple selected targets may be displayed as a single number. Other methods for aggregation include, but not limited to:Summation: The numerical value of each target is added, and the total is displayed. The total may be displayed as a bar (e.g., health bar3110,4110), a numerical value, and so on.Proportional Summation Each target is evaluated separately, and its statistic is converted to a percentage based on a maximum allowable range. The percentages are then summed. The resulting percentage is then displayed as a bar (e.g., health bar3110,4110), a numerical value, and so on.

The system1000may present global and selected target information simultaneously. Global targets include all selected and un-selected targets. For example, turning back toFIG. 10, the health bar4111represents the health of the selected targets (e.g., nearby champions), the health bar4112represents the health of the un-selected targets (e.g., far champions). In the example ofFIG. 10, as shown inFIG. 10a, the global targets include both the selected (e.g., nearby) champions4130,4131, and the un-selected (e.g., far) champions4132,4133,4134. By superimposing the selected-target bar4111over the un-selected-target bar4112, the spectator client1200may visually display all three states in a single combined bar.

As described above, statistics for global targets may be displayed using the summation or proportional summation method substituting global targets for selected targets. In the same manner, statistics for un-selected targets can be displayed using the summation or proportional summation method substituting un-selected targets for selected targets. The difference in length between the global target bar (e.g., combination of health bar4111and health bar4112) and the selected-target bar (e.g., health bar4111) will be proportional to the length of the un-selected-target bar (e.g., health bar4112), when the same methods and scale are used for both sets of targets. For example, the selected-target bar4111represents the proportional total health of the selected team members; the un-selected-target bar4112represents the proportional total health of the un-selected team members; the global bar is the proportional total health of global team members.

Various combinations of the above described methods of selection, de-selection and buffering may be used by the system1000. For example, during a game session, the viewing area of the spectator's camera can be used for selection and de-selection with a time buffer for de-selection. A combined health bar for selected, de-selected, and global players can be displayed allowing for the overall health status of the team to be understood within the local (viewable), off-screen (unviewable) and global (aggregate total) contexts.

In an embodiment, the spectator client1200displays ceremony or celebration (not shown) when a big event occurs or is achieved in a game session. The big events include, for example:

Dragon Kill—This ceremony shows which team killed Dragon.

Baron Kill—This ceremony shows which team killed Baron.

Triumph—This ceremony shows which team won a fight, e.g., reduced the other team's health bar to zero.

Kill Streaks—This ceremony celebrates pentakills and possibly other kill streaks.

In another embodiment, the status bar3100and4100may be enabled for all players in a game session. In this embodiment, the spectator client may not display all information as that is displayed for spectator view because a player does not have an omnipresent view as a spectator does.

It is noted that the system1000may also be implemented in non-video game applications (e.g., online shopping system), or systems that can differentiate between visible and non-visible targets (e.g., augmented reality systems). For example, in a price checking system, when viewing products through an augmented reality device, products can be selected based on their visibility (using a selection method as described above, e.g., products cost less than $5, products on-sale, and so on) with a buffer to prevent quick selection (using a buffering method as described above). They can be de-selected when they are no longer visible (using a de-selection method as described above) with a buffer to prevent quick de-selection (using a buffering method as described above). The price of each individual item may be displayed up to a pre-defined limit. When too many items are selected, the aggregate price of all selected items may be displayed (using a combined statistics method as described above). This can be compared versus the aggregate price of all de-selected items.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. For example, the reader is to understand that the specific ordering and combination of process actions described herein is merely illustrative, and the invention may appropriately be performed using different or additional process actions, or a different combination or ordering of process actions. For example, this invention is particularly suited for online gaming systems; however, the invention can be used for any multi-user online system in general, online shopping system in general, or systems that can differentiate between visible and non-visible targets (i.e. augmented reality systems). Additionally and obviously, features may be added or subtracted as desired. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.