ONLINE GAME SERVER ARCHITECTURE USING SHARED

RENDERING

Field of the Invention

The invention relates to a server arrangement for controlling a video game, such as an online video game, using a shared-rendering engine. The invention also relates to a method for performing shared rendering of graphical scenes in a video game.

Background of the Invention

Online video games are becoming increasingly popular. An online video game infrastructure uses a server arrangement that controls the video game and which is connected by a data network, such as the Internet, to multiple terminals. Game participants interact with the video game through the terminals.

The server arrangement requires significant computational resources, especially when the number of players involved in the game is large. The traditional server architecture allocates to each player the resources necessary to run the game logic and perform image rendering. In this fashion, image rendering is performed separately for each player.

An image rendering operation, especially when high image quality is desired, is computationally intensive. When hundreds, and even thousands, of players are involved, massive resources need to be allocated to satisfy those needs. There is, therefore, a need in the industry to develop new server arrangement architectures that can perform the image rendering operation more efficiently.

Summary of the Invention

As embodied and broadly described herein, the invention provides a server arrangement for controlling a video game viewable by game participants at a plurality of respective terminals. The server arrangement has a game engine to generate source graphics data that convey graphical scenes, collectively representing a virtual world with game characters, each graphical scene describing at least a portion of the virtual world. The server arrangement also has a shared- rendering engine, linking game participants with relevant graphical scenes and performing a shared-rendering operation to generate a moving-image data stream, the shared-rendering operation being common for the game participants that are linked by the shared- rendering engine to a particular graphical scene.

As embodied and broadly described herein, the invention also provides a method for performing shared-rendering of source graphics data in a video game viewable by game participants at a plurality of respective terminals. The method includes generating with a game engine source graphics data that convey graphical scenes collectively representing a virtual world with game characters, each graphical scene describing at least a portion of the virtual world. The method further includes linking game participants with respective graphical scenes and performing a shared-rendering operation to generate a moving-image data stream, the shared-rendering operation being common for game participants that are linked by the shared-rendering engine with a particular graphical scene.

Brief Description of the Drawings

Figure 1 is a block diagram of an online video game infrastructure;

Figure 2 is a more detailed block diagram of the server arrangement shown in Figure 1 ;

Figure 3 shows a layout of a virtual world of an online video game, depicting various game scenes and game characters;

Figure 4 is a block diagram illustrating the architecture of the shared- rendering engine used in the server arrangement shown in Figures 1 and 2;

Figure 5 is a flowchart of a process implemented by the shared- rendering engine for determining an association between a game participant and a graphical scene; and

Figure 6 is a flowchart of yet another process implemented by the shared-rendering engine for determining the association between a game participant and a graphical scene, by taking into account viewing preferences. Detailed Description

In a specific and non-limiting example of implementation, the invention provides a server arrangement for controlling an online video game. Figure 1 illustrates the data communication infrastructure for implementing the online video game. The infrastructure includes a server arrangement 10 that connects over a data network 12 to individual game terminals 14. The data network 12 can be the Internet.

Participants interact with the game through the terminals 14. The expression "game participant" or "participant" for short refers to a game player or to a spectator. A game player is an individual that is associated with a game character in the virtual world the game depicts. Typically, the player can control movements and other actions of the game character in order to compete with other game players or against game characters that are controlled by the game logic. A spectator on the other hand does not have a game character in the virtual world. A spectator observes the video game, over a terminal 14 that is played by game players. Note that it is also possible for a game player to spectate, although this would not typically occur at the same time. For instance, if the player dies and can re-spawn only after a predetermined amount of time has elapsed after the death event, the player might be a spectator during that idle time period. After re-spawning the individual ceases to be a spectator and takes again a player role. However, during all that time the individual continues to be a game participant. The general structure of the server arrangement 10 is shown in greater detail in Figure 2. The server arrangement 10 is essentially a computer-based platform to execute program code managing the video game and includes the necessary hardware resources to perform image rendering. At this end, the server arrangement 10 includes a machine-readable storage (not shown) in which is stored the program code and also the various parameters on which the program code operates in order to manage the game. The machine- readable storage refers to all the hardware resources for storing data and does not imply that those resources are at a single location or configured in any specific way. In most likely form of implementation, the machine-readable storage would be of distributed nature, including remote databases connected to a central unit by a communication link.

The program code stored in the machine-readable storage is executed by a single or multiple Central Processing Units (CPUs). The number of CPUs involved, their type and configuration can vary without departing from the spirit of the invention. The server arrangement 10 would also include the necessary image-rendering resources for converting the source graphics data into a moving-image data stream. Such image-rendering resources include specialized processors, such as Graphics Processing Units (GPUs) to make the operation more efficient.

From a functional perspective, the server arrangement 10 includes a game engine 16 that provides the overall game control function. The game engine 16 that collectively refers to the software elements and hardware elements necessary to embody this function, creates a dynamically evolving virtual world and controls the movements and actions of game characters in that virtual world, based on inputs provided by the game players.

The game engine 16 outputs source graphics data. The source graphics data constitutes a mathematical representation of the virtual world that is to be presented to the game participants. Since the virtual world can be extensive, the source graphics data conveys multiple graphical scenes or views that collectively provide a complete representation of the virtual world. Typically, each graphical scene is associated with a certain portion of the virtual world. Thus, different graphical scenes are essentially different views of the virtual world. As a game character moves from one location to another in the virtual world, the graphical scenes presented to that game player will change. For instance, if a game player is in a room of a dwelling and moves to an adjacent room, the graphical scene the player sees will change as the player crosses the boundary between the two rooms such as to provide the illusion of movement.

The source graphics data generated by the game engine 16 describe the virtual world of the game which is to be displayed to the player. The source graphics is the information that is supplied to the shared- rendering engine 18 and processed to generate individual pixel values expressed in terms of color and intensity, that compose the image the player is to see. Generally, the source graphics has two main components. The first is primitives data that constitutes a mathematical description of the various components of the image. An example of primitives data is vertex coordinates that define the location of the vertices making up the image mesh. Another example of primitives data is the linking of the individual vertices into geometric structures such as triangles, polygons and lines, among others.

The primitives data may also convey information such as intensity of lighting, origin of the light source, shading and texturing and also three-dimensional image information such as a relative location of the various image components in the Z direction.

In addition to the primitives data, the source graphics also includes rendering instructions. The rendering instructions are essentially commands that tell the shared-rendering engine 18 how to handle or manipulate the primitives data. An example of a rendering command, could be to create a certain visual effect or to move a certain image component in the image frame from one location to the other, cause it to rotate along a certain axis, etc.

The source graphics data is converted into a moving image data stream by the shared-rendering engine 18 in order to be displayed to the game participants. As discussed above, the rendering operation is essentially a translation of the graphical information from the mathematical space into an image, such as a 2D image, defined in terms of pixel values. The engine 18 is referred to as "shared" because at least some of the rendering operation is re-used amongst players, thus avoiding a fully independent rendering process for each player. The shared-rendering engine 18 outputs a moving-image data stream that is sent to the respective participant terminals 14. In practice, since different players are located in different places of the virtual world, a series of moving-image data streams are generated by the shared- rendering engine 18 according to the number of players involved in the game, their viewpoint, etc.

The moving-image data stream is encoded in any suitable format for convenient decoding at the participant terminals 14. MPEG-4 is an example of an encoding format that can be used.

The output of the shared-rendering engine 18 is directed to the respective participant terminals 14 by way of the input/output interface 20. The input/output interface 20 designates the various functions of the server arrangement 10 allowing data to be sent to external devices, such as the terminals 14, or received from such external devices.

Figure 3 depicts an example of a virtual world in which the online game evolves. The virtual world may represent a battlefield, a dwelling, a garden or any other venue depending on the style and type of game. The virtual world is defined by boundaries that appear to the game players as limits within which the game characters evolve. For instance, the boundaries may be depicted as walls of a dwelling. The virtual world 22 is subdivided into smaller areas 22a, 22b, 22c, 22d and 22e. The game characters 24 remain always within the boundaries of the virtual world 22 and would typically move from one of those smaller areas to another. The areas 22a, 22b, 22c, 22d and 22e are represented by individual graphical scenes. For example, the area of the virtual world 22a is represented by a corresponding graphical scene that is rendered on the remote terminals 14 of the game players that have a game character in that area or to spectators that are interested to view the action in that area.

The way the virtual world 22 is subdivided into smaller areas that are represented by respective graphical scenes is a matter of design choice and will greatly vary from one game to another. In one example of implementation, the subdivision can be made such that the smaller areas are mutually exclusive, in other words they do not overlap. In the example shown in Figure 3, the areas 22c, 22d and 22e do not overlap. Another possibility is to allow the smaller areas to overlap to some extent. This is the case of areas 22b and 22a. The area 22a has a first portion 26 and a second portion 28, the second portion 28 being shared with the area 22b. The area 22b also has portion 30 that is exclusive to area 22b, in other words it is not shared by any other smaller area.

The shared portion 28, which is cross-hatched in Figure 3, represents a zone of the virtual world that can be represented by a graphical scene associated to anyone of the areas 22a and 22b. In other words, if a game character is located in zone 28, the game action can be depicted to the game player associated with that game character by rendering on the corresponding remote terminal 14 either the graphical scene that is associated with the area 22b or the graphical scene associated with the area 22a.

The logic for determining which graphical scene is rendered for a particular game player can be determined based on a number of different parameters. One such parameter is the location of the game character in the virtual world. For instance, if the game character is located in the area 22e, the graphical scene associated with that area is rendered on his/her terminal 14. So, when the game character moves around, the overall graphical scene will not change, except to reflect the game character movement, to the extent the game character remains within the boundaries of the area 22e. However, when the game character crosses the boundary and enters an adjacent area, such as the area 22d, the graphical scene rendered on the terminal 14 changes and is replaced by the one that is associated with the area 22d.

In this instance, the trigger for switching from one graphical scene to another is based on the character movement, in particular when the game character crosses the threshold between two adjacent areas of the virtual world.

A difference may arise when the game character is located in a zone that is shared by two adjacent areas, such as the portion 28 that belongs to both the area 22a and 22b. In such case, a first possible strategy is to switch graphical scenes when the game character enters into the portion 28. For instance, if the game character is within portion 30 and moves to enter the portion 28, the graphical scene is switched to the one associated with the area 22a. The other possible strategy is to switch the graphical scene only when the game character moves from the common portion 28 into a portion that is no longer shared by any other adjacent area. For instance, if the game character moves from portion 28 into portion 26, then a graphical scene switch is performed.

Alternatively, the graphical scenes may be views of the virtual world from perspectives that change based on logic other than the location of the player relative to certain coordinates in the virtual world. For example, the views may progressively shift as the game evolves. Another example is to associate a view with a certain player such that the view moves along with the player.

Figure 4 is a block diagram that illustrates the functions performed by the shared-rendering engine 18. The shared-rendering engine 18 has a main logic module 32 that manages the overall rendering operation. The logic module 32 receives by way of input 34 information about game parameters on the basis of which the logic 32 will associate game participants with corresponding graphical scenes or views.

This operation is performed by maintaining in the machine-readable storage of the server arrangement 10 a series of lists linking game participants to graphical scenes. In a specific example of implementation, there are as many lists as graphical scenes. In Figure 4, N graphical scenes are shown. List 36 is associated with graphical scene 1 , list 38 is associated with graphical scene 2 and list 40 is associated with graphical scene N.

Each list holds the identifiers of the participants that will receive the moving-image data stream generated on the basis of the corresponding graphical scene. The participants are those for whom the graphical scene is relevant, such as game players that have game characters appearing in the graphical scene or spectators that have selected to watch the game action in that graphical scene.

The identifier of a participant can be any piece of data that uniquely identifies the participant. The identifier can thus be associated with the participant itself, such as the IP address of the terminal 14 on which the participant interacts with the game and the identifier of the virtual character associated with the participant, among others.

The logic 32 dynamically associates participants with graphical scenes and arranges the lists 36, 38 and 40, accordingly. The dynamic association is performed by analyzing the game parameters that are received by way of the input 34.

A first possible parameter is a virtual world map which is a representation of the virtual world 22, defining a structured layout in which the areas corresponding to the various graphical scenes can be set. Typically, the first parameter will not change during the game as in most type of games, the virtual world remains the same as the game unfolds. W

However, it is possible to provide a game where the virtual world can change based on action dynamics. In such case, the parameters received by way of the input 34 will reflect this change.

A second possible parameter is the location of the game characters in the virtual world 22. The location information allows the logic 32 to determine in which area of the virtual world 22 the various game characters reside and associate the game characters with the respective graphical scenes. For example, if a particular game character is located in an area corresponding to graphical scene 1 , then the identifier of the participant associated with that game character is loaded in the list 36. The same operation is performed for each game character such that each game character is associated with a graphical scene.

The association between game characters and graphical scenes is dynamic in nature and changes according to the game action dynamics. As the game characters move within the virtual world 22, the logic 32 changes the association between a particular game participant and a graphical scene when the game character associated with that participant moves in an area of the virtual world 22 that corresponds to a different graphical scene. In practical terms, such change of association implies that the identifier of the game participant will be removed from one list and placed in a different list.

Yet another parameter that can be used for determining the association between participants and graphical scenes, is viewing preferences supplied by the participant itself. Viewing preferences include information W

provided by the participant specifying certain viewing options allowed by the system. Spectators, by the nature of their interaction with the game, would have more viewing options than game players. Since a game player controls a virtual game character, the graphical scene that the game player would see on its terminal 14 would normally be the one in which the game character is found. Spectators, on the other hand, are not tied to a particular game character and have more freedom to choose what part of the action they can view.

In the case of a spectator, the viewing preferences can include a selection of a particular game character to track. This means that the spectator will see the graphical scenes in which the selected game character is located. As a practical matter, the spectator will be paired with the game player associated with that particular game character and will be placed in the same list as the game player.

Another possible viewing preference for a spectator is a selection of a particular graphical scene. The spectator can select a graphical scene among the set of available graphical scenes and the logic 32 will place the spectator in the list of game participants that are associated with that particular graphical scene.

Yet another possible viewing preference the spectator may specify is to see graphical scenes based on action dynamics. In the case of a war game, the spectator may want to see the graphical scenes that contain most of the action. The action can be defined by a number of game characters being killed per unit of time, numbers of explosions per unit of time, rate of ordnance expenditure per unit of time and number of game characters per unit area into the virtual world 22, among others.

All of the parameters specified above exist in the game engine 16 since they constitute metrics on the basis of which the game is being managed. Those parameters are passed to the logic 32 that will process them in conjunction with the viewing preference information supplied by the game participant to determine which graphical scene meets the game participant requirements. Once the desired graphical scene is identified by the logic 32, the game participant is linked to that graphical scene.

In the case of game players, the viewing preferences may include options that become effective for game events during which the game character is temporary inactive. An example is a situation when the game character has died and will re-spawn only when a predetermined amount of time has elapsed or when the game round terminates. This is the case of game rounds which are based on elimination, where once a game character dies, it does not return in the game. When a game character becomes inactive, the game participant is effectively a spectator and has broader options in terms of viewing preferences, such as to continue watching another game participant, remain in a particular location of the virtual world 22 or watch a location selected on the basis of action dynamics.

The reader will appreciate that the examples of viewing preferences discussed above are not exhaustive and many other viewing options are possible, both for a spectator and for a game player, without departing from the spirit of the invention.

The viewing preferences for a spectator and for a game player are input at the respective terminals 14. This input operation is enabled by creating on the respective terminals 14 a Graphical User Interface (GUI) that displays to the game participant the various viewing options available and provides tools for the game participant to make the appropriate selection.

The GUI is generated by the server arrangement 10 and sent to the respective terminals 14 to be displayed. An example of a graphical user interface allowing a spectator to track or tag along a particular game character is to provide on the terminal 14 of the spectator display a list of the game characters currently involved in the game, such that the spectator can make a selection. The selection can be made by using a pointing device. When the number of game characters in the game is large, which makes it impractical to list them all, the graphical user interface can be designed to allow the spectator to select a game character while the spectator is watching the game. For instance, the spectator uses a pointing device to specify a game character displayed on a terminal while the game action is underway.

In selecting a particular graphical scene to watch, the GUI displays to the game participant a map of the virtual world, which identifies the available graphical scenes. The game participant can then select a graphical scene among those presented. For instance, the view presented to the participant can be similar to what Figure 3 depicts. In that figure, the virtual world is shown and the boundaries of the various graphical scenes are also presented. The participant selects the graphical scene by "clicking" with the pointing device anywhere in the scene boundary.

When the viewing preferences are based on action dynamics, the GUI displays to the game participant the list of action dynamics available for selection.

The GUI that receives the input of the game participant will send information back to the server arrangement 10 which will then be processed by the logic 32 to link the game participant with the appropriate graphical scene.

A shared-rendering operation is performed for each graphical scene. The shared-rendering operation is common to the game participants in the dynamic list associated with that graphical scene. In a specific example of implementation, a single rendering operation is performed for the graphical scene and the results of that shared-rendering operation are sent to each participant in the list of participants linked with that particular graphical scene. Taking the example of graphical scene 1 , the shared- rendering operation 42 is performed only once and the results of the rendering operation are sent to the terminals 14 of the game participants in the list 36.

The same operation is performed for all the graphical scenes to be rendered. The rendering engine used to perform the rendering operation is not critical as long as it can adequately convert the source graphics data representing the different graphical scenes into a moving-image data stream. Since the rendering operation needs to be performed in real time, a hardware accelerator using dedicated GPU's would be beneficial.

Note that the expression "shared rendering" does not imply that all the image elements in the graphical scene model are necessarily rendered. The expression simply means that the majority of the image elements in the graphical scene are rendered and shared among the various participants linked to that graphical scene, but not necessarily all of them.

The shared rendering can thus be a partial rendering operation, performing rendering on a number of image elements in the graphical scene, but not necessarily all of them. The image elements which are not rendered can be rendered in a subsequent operation by the server arrangement 10 or the rendering operation can be completed at the terminal 14 location.

The output of the shared-rendering operation is a moving-image data stream that is sent to the terminals 14 for display to the game participants. The moving-image data stream is encoded under any suitable format, such as the MPEG-4 format and played at the participant terminals 14. When the shared-rendering operation is partial, leaving some of the image elements in a graphical scene not rendered, for rendering at the participant terminal 14, those objects would need to be suitably encoded for transmission and subsequent processing by a rendering module at the respective terminals 14.

Figure 5 is a flowchart that summarizes the above-described process implemented by the logic module 32 for linking participants with graphical scenes. This process is mostly suitable for game players that control a virtual game character. At step 44, the logic 32 determines the location of the game character associated with a particular game player in the virtual world. It is to be understood that this process is repeated constantly, allowing to continuously track the position of the game character in order to send to the game player the correct graphical scene that contains its game character. At step 46, the corresponding graphical scene is derived on the basis of the location information determined in the previous step. Finally, at step 48, the game player is linked with that graphical scene by entering its identifier in the list associated therewith.

Figure 6 is a flowchart summarizing the process described earlier that factors in viewing preferences in selecting the graphical scene to which the game participant is to be linked.

At step 50, the logic 32 retrieves the viewing preference information input by the game participant. This information is entered at the respective terminal 14 and it is sent back to the server arrangement 10. At step 52, the viewing preference information is processed and at step 54, the graphical scene that matches the viewing preference information is identified. Note that in addition to the viewing preference information, other parameters can be used to determine the graphical scene with which the participant should be linked. For example, the determination can take into account, in addition to the viewing preference information, location information of a game character in the virtual world.

The reader skilled in the art will appreciate that additional factors can also be taken into account in performing the graphical scene selection.