US20060135258A1

US20060135258A1 - System, network entity, client and method for facilitating fairness in a multiplayer game

Info

Publication number: US20060135258A1
Application number: US11/015,253
Authority: US
Inventors: Shashikant Maheshwari; Giridhar Mandyam
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2004-12-17
Filing date: 2004-12-17
Publication date: 2006-06-22

Abstract

A system for facilitating fairness in a multiplayer game includes a network entity (e.g., game server) capable of operating a game application that can operate a multiplayer game. A plurality of clients is associated with a network latency, and can communicate with the network entity across at least one network. The system further includes a time-delay module disposed between the clients and the game application. The time-delay module can receive a data packet associated with a particular client during play of the multiplayer game, and delaying the data packet for at least a portion of delay time associated with the particular client before passing the delayed packet to the game application or the particular client for processing. In this regard, the delay time is based upon the network latency of the first client and an effective network latency set based upon the network latencies of the plurality of clients.

Description

FIELD OF THE INVENTION

The present invention generally relates to systems and methods of operating a multiplayer game and, more particularly, relates to systems and methods of facilitating fairness in a game operated by a plurality of clients experiencing differing network latencies.

BACKGROUND OF THE INVENTION

Multiplayer gaming poses an interesting application for wireless networks. Particularly, the so-called “first-person shooter” games are some of the most challenging interactive games to implement in a wireless network. These kinds of games, which generally involve one or more players taking some form of action against other players in the game, are not usually turn-based. As a result, game play is affected by latencies in the network in that players with low latency can actually have an advantage over players exhibiting high latency in the network.
In wireless networks, the likelihood of large discrepancies between gamers compounds the issue of different players experiencing different levels of network latencies. This discrepancy results from the fact that gamers, particularly in cellular networks, can exhibit a wide variance of latencies that depends on a number of different parameters including, for example, wireless channel conditions, mobile class and system load. For instance, a gamer located near the center of a network cell may experience much higher throughput, and thus lower latency, than a user at the edge of a cell.
Thus, the concept of “fairness” enters into the picture in multiplayer games. Intuitively, one can arrive at some simple examples to illustrate the problem that occurs with two gamers exhibiting dramatically different latencies. Assume a first gamer and a second gamer are playing a shootout game, where the second gamer is experiencing far less network latencies than the first gamer. During the course of play, consider that the first gamer fires a shot at the second gamer at time t1, and the second gamer fires a shot at the first gamer at time t₂(t₂>t₁). But because the second gamer is experiencing far less latency than the first gamer, the shot fired by the second gamer could be processed before the shot fired by the first gamer, although the shot from the second gamer shot actually occurred after the shot from the first gamer.
A number of different gaming architectures have been developed with varying degrees of network latency of the gamers operating such architectures. In this regard, three exemplary gaming architectures with varying measures to ensure fairness are described in Martin Mauve et al., A Generic Proxy System for Networked Computer Games, T HE FIRST WORKSHOP ON NETWORK AND SYSTEM SUPPORT FOR GAMES 25-28 (2002). In the first architecture, referred to as the centralized client-server architecture, all of the gamers communicate with a centralized game server that operates a game and maintains the game state. In this architecture, gamers operate game clients on computers that communicate with the game server. The computers, and thus the game clients and gamers, receive information regarding the game state from the centralized server, and may attempt to effectuate a change of the game state by communicating local actions to the centralized server. To prevent cheating in the centralized client-server architecture, data packets sent from the gamers' computers to the centralized server may be time stamped to determine an ordering of actions by the respective gamers. Such time-stamping of the data packets, however, often occurs on the server-side of the architecture, and as such, unwittingly serves to facilitate the advantage provided to those gamers with lower network latency in data packets reaching the centralized server.
In another conventional architecture, referred to as a decentralized architecture, the computers of the clients communicate with one another to maintain the game state without a centralized server. Although fairness is easier to achieve in the decentralized architecture, management of the game environment becomes very difficult (maybe even impossible for functions such as authentication and billing). Moreover, bottlenecks often occur for gamers who do not have sufficient resources to handle the processing otherwise executed by a centralized server in the centralized client-server architecture.
The third conventional architecture described in the Mauve paper is referred to as the proxy architecture. The proxy architecture is similar to the centralized client-server architecture in that a central architecture maintains game state. Unlike the centralized client-server architecture, however, proxy servers may be coupled between the centralized server and one or more computers of the gamers, the proxy servers typically being located close to clusters of remote gamers. The proxy servers, then, can communicate with one another and the central server to provide at least a portion of the functionality of the centralized server. The proxy architecture has the advantage of decentralizing game play to ensure fairness, but centralizing necessary functions for game play such as authentication. In the proxy architecture, the proxies provide time-stamping functionality to prevent cheating. And while this may ensure fairness between gamers of different proxies, it does not necessarily account for fairness of gamers communicating with the same proxy for the same reason explained above with respect to the centralized client-server architecture.

SUMMARY OF THE INVENTION

In light of the foregoing background, embodiments of the present invention provide an improved system, network entity, client and method for facilitating fairness in a multiplayer game. In accordance with embodiments of the present invention, data packets to and/or from a game server during play of a multiplayer game may be artificially delayed such that the clients playing the game communicate with the game server, and thus play the game, with the same perceived network latency. More particularly, data packets received from clients across one or more networks may be artificially delayed before being passed to the game server for processing. Additionally or alternatively, data packets received from the game server may be artificially delayed before being passed to respective clients across one or more networks, the data packets being passed to the clients for processing by the clients. The data packets may be delayed such that all of the clients playing the game experience substantially the same effective network latency. Further, the effective network latency may, for example, substantially equal the highest network latency of the clients. To avoid a prohibitively undesirable slowdown in game play that may be experienced due to prohibitively long network latencies associated with a few clients, the system of embodiments of the present invention may be configured such that only those clients with a network latency below a latency threshold are permitted to play the multiplayer game. However, to permit slower clients to play the game, the game application operated by the game server may also provide multiple occurrences of the game. In such instances, clients with similar network latencies may be matched with one another in each of the occurrences of the multiplayer game.
According to one aspect of the present invention, a system is provided for facilitating fairness in a multiplayer game. The system includes a gaming architecture having a least one network entity, such as a game server, routing server and/or client. The network entit(ies) are capable of operating a game application, which is capable of operating a multiplayer game. The system also includes a plurality of clients capable of communicating with the gaming architecture across at least one network to play the multiplayer game. The clients, including a particular client, are each associated with network latency. Thus, the system further includes a time-delay module disposed across the networks from the clients and between the clients and the game application, such as in a position integral with, or proximate to, the network entity. The time-delay module is capable of receiving a data packet associated with the particular client during play of the multiplayer game, and delaying the data packet for at least a portion of a delay time associated with the particular client. After delaying the data packet, then, the time-delay module is capable of passing the delayed data packet to the game application or to the particular client for processing. In this regard, the delay time is based upon the network latency of the particular client and an effective network latency set based upon the network latencies of the plurality of clients. During play of the game, then, the time-delay module may be capable of receiving a data packet, delaying the data packet and passing the delayed data packet for the plurality of clients such that the plurality of clients play the multiplayer game with a network latency substantially equal to the effective network latency.
More particularly, for example, the time-delay module can be further capable of determining the delay time associated with the particular client, where the delay time is determined to substantially equal the difference between the effective network latency and the network latency of the particular client. In this regard, the time-delay module can be further capable of determining the network latency associated with each of the plurality of clients. Then, for example, the time-delay module can set the effective network latency based upon the highest network latency of the plurality of clients. Also, if so desired, the time-delay module can be capable of periodically determining the network latency and setting the effective network latency.
The system can further include at least one routing server for routing data packets between a game server network entity and the plurality of clients. In such instances, the game server or routing server(s) may be capable of comparing the latencies of the clients against a threshold latency. Then, the game server or routing server(s) may prevent those clients having a network latency above the threshold latency from playing the multiplayer game. To also allow clients with higher network latencies to play the game, the game application may be capable of providing a plurality of occurrences of the multiplayer game, each occurrence being capable of being played by a plurality of clients. Thus, each occurrence is associated with the effective network latency of the clients playing the occurrence. The game application, then, may be further capable of receiving an additional client into an occurrence of the multiplayer game based upon the effective network latency associated with the occurrence and the network latency of the additional client. Even within each occurrence, however, the time-delay module may be capable of receiving a data packet, delaying the data packet and passing the delayed data packet.
According to other aspects of the present invention, a network entity, client, method are provided for facilitating fairness in a multiplayer game. Embodiments of the present invention therefore provide an improved system, network entity, client and method for facilitating fairness in a multiplayer game. By configuring game traffic such that the clients playing a game send/receive data packets with substantially the same effective latency, embodiments of the present invention therefore provide a framework for overcoming the drawback of network latency in communications between clients and game servers in playing a game. And to avoid decreasing the speed of game traffic to a prohibitively undesirable level, a threshold latency can be imposed on the clients playing the game, and/or clients can play different occurrences of the game with other clients having similar network latencies. As such, the system, network entity, client and method of embodiments of the present invention solve the problems identified by prior techniques and provide additional advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
FIG. 1 is a block diagram of one type of terminal and system that would benefit from embodiments of the present invention;
FIG. 2 is a schematic block diagram of an entity capable of operating as a mobile station, game server, proxy server, personal computer (PC) system and/or game console, in accordance with embodiments of the present invention;
FIG. 3 is a schematic block diagram more particularly illustrating a mobile station in accordance with one embodiment of the present invention;
FIG. 4 is a schematic block diagram of an exemplar configuration of various network entities of the system of FIG. 1, in accordance with one embodiment of the present invention;
FIG. 5 is a functional block diagram of a plurality of clients sending data packets to, and receiving data packets from, a game server to play a multiplayer game, in accordance with one embodiment of the present invention; and
FIG. 6 is a flowchart including various steps in a method of facilitating fairness in a multiplayer game, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.
Referring to FIG. 1, an illustration of one type of system that would benefit from the present invention is provided. The system, method and computer program product of embodiments of the present invention will be primarily described in conjunction with mobile communications applications. It should be understood, however, that the system, method and computer program product of embodiments of the present invention can be utilized in conjunction with a variety of other applications, both in the mobile communications industries and outside of the mobile communications industries. For example, the system, method and computer program product of embodiments of the present invention can be utilized in conjunction with wireline and/or wireless network (e.g., Internet) applications.
The system can include one or more mobile stations 10, each having an antenna 12 for transmitting signals to and for receiving signals from one or more base stations (BS's) 14, one of each being shown in FIG. 1. The base station is a part of one or more cellular or mobile networks that each includes elements required to operate the network, such as one or more mobile switching centers (MSC) 16. As well known to those skilled in the art, the mobile network may also be referred to as a Base Station/MSC/Interworking function (BMI). In operation, the MSC is capable of routing calls, data or the like to and from mobile stations when those mobile stations are making and receiving calls, data or the like. The MSC can also provide a connection to landline trunks when mobile stations are involved in a call.
The MSC 16 can be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN). The MSC can be directly coupled to the data network. In one typical embodiment, however, the MSC is coupled to a Gateway (GTW) 18, and the GTW is coupled to a WAN, such as the Internet 20. In turn, devices such as processing elements (e.g., personal computers, server computers or the like) can be coupled to the mobile station 10 via the Internet. For example, as explained below, the processing elements can include one or more processing elements associated with one or more game servers 22, routing servers 24, personal computer (PC) systems 26, game consoles 28, or the like, one of each being illustrated in FIG. 1 and described below. As will be appreciated, the processing elements can comprise any of a number of processing devices, systems or the like capable of operating in accordance with embodiments of the present invention.
The BS 14 can also be coupled to a Serving GPRS (General Packet Radio Service) Support Node (SGSN) 30. As known to those skilled in the art, the SGSN is typically capable of performing functions similar to the MSC 16 for packet switched services. The SGSN, like the MSC, can be coupled to a data network, such as the Internet 20. The SGSN can be directly coupled to the data network. In a more typical embodiment, however, the SGSN is coupled to a packet-switched core network, such as a GPRS core network 32. The packet-switched core network is then coupled to another GTW, such as a GTW GPRS support node (GGSN) 34, and the GGSN is coupled to the Internet.
Although not every element of every possible network is shown and described herein, it should be appreciated that the mobile station 10 may be coupled to one or more of any of a number of different networks. In this regard, mobile network(s) can be capable of supporting communication in accordance with any one or more of a number of first-generation (1G), second-generation (2G), 2.5G and/or third-generation (3G) mobile communication protocols or the like. More particularly, one or more mobile stations may be coupled to one or more networks capable of supporting communication in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, one or more of the network(s) can be capable of supporting communication in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. In addition, for example, one or more of the network(s) can be capable of supporting communication in accordance with 3G wireless communication protocols such as Universal Mobile Telephone System (UMTS) network employing Wideband Code Division Multiple Access (WCDMA) radio access technology. Some narrow-band AMPS (NAMPS), as well as TACS, network(s) may also benefit from embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDMA/CDMA/analog phones).
One or more mobile stations 10 (as well as one or more processing elements, although not shown as such in FIG. 1) can further be coupled to one or more wireless access points (APs) 36. The AP's can be configured to communicate with the mobile station in accordance with techniques such as, for example, radio frequency (RF), Bluetooth (BT), infrared (IrDA) or any of a number of different wireless networking techniques, including WLAN techniques. The APs may be coupled to the Internet 20. Like with the MSC 14, the AP's can be directly coupled to the Internet. In one embodiment, however, the APs are indirectly coupled to the Internet via a GTW 18. As will be appreciated, by directly or indirectly connecting the mobile stations and the user processors (e.g., game servers 22, routing servers 24, personal computer (PC) systems 26, game consoles 28) and/or any of a number of other devices to the Internet, whether via the AP's or the mobile network(s), the mobile stations and user processors can communicate with one another to thereby carry out various functions of the respective entities, such as to transmit and/or receive data, content or the like. As used herein, the terms “data,” “content,” “information,” and similar terms may be used interchangeably to refer to data capable of being transmitted, received and/or stored in accordance with embodiments of the present invention. Thus, use of any such terms should not be taken to limit the spirit and scope of the present invention.
Although not shown in FIG. 1, in addition to or in lieu of coupling the mobile stations 10 to game servers 22, routing servers 24, personal computer (PC) systems 26 and/or game consoles 28 across the Internet 20, one or more such entities may be directly coupled to one another. As such, one or more network entities may communicate with one another in accordance with, for example, RF, BT, IrDA or any of a number of different wireline or wireless communication techniques, including LAN and/or WLAN techniques.
Referring now to FIG. 2, a block diagram of an entity capable of operating as a mobile station 10, game server 22, routing server 24, personal computer (PC) system 26 and/or game console 28, is shown in accordance with one embodiment of the present invention. Although shown as separate entities, in some embodiments, one or more entities may support one or more of a mobile station, game server, routing server, personal computer (PC) system and/or game console, logically separated but co-located within the entit(ies). For example, a single entity may support a logically separate, but co-located, game server and routing server. Also, for example, a single entity may support a logically separate, but co-located personal computer and game console.
As shown, the entity capable of operating as a mobile station 10, game server 22, routing server 24, personal computer (PC) system 26 and/or game console 28 generally includes a processor 38 connected to a memory 40. The memory can comprise volatile and/or non-volatile memory, and typically stores content, data or the like. For example, the memory typically stores content transmitted from, and/or received by, the entity. Also for example, the memory typically stores client applications, instructions or the like for the processor to perform steps associated with operation of the entity in accordance with embodiments of the present invention. As explained below, for example, the memory can store client application(s) including a configuration utility, content manager and/or display manager. In this regard, when executed, the configuration utility may function to configure a source of content to receive or otherwise provide content. The content manager, when executed, may function to manage the receipt of content from the source, and/or the use of content received from the source. And the display manager may function to manage presentation of content received from the source. As described herein, the client application(s) each comprise software operated by the respective entities. It should be understood, however, that any one or more of the client applications described herein can alternatively comprise firmware or hardware, without departing from the spirit and scope of the present invention.
In addition to the memory 40, the processor 38 can also be connected to at least one interface or other means for displaying, transmitting and/or receiving data, content or the like. In this regard, the interface(s) can include at least one communication interface 42 or other means for transmitting and/or receiving data, content or the like, as well as at least one user interface that can include a display 44 and/or a user input interface 46. The user input interface, in turn, can comprise any of a number of devices allowing the entity to receive data from a user, such as a keypad, a touch display, a joystick or other input device.
Reference is now made to FIG. 3, which illustrate one type of mobile station 10, a mobile telephone, which would benefit from embodiments of the present invention. It should be understood, however, that the mobile station illustrated and hereinafter described is merely illustrative of one type of mobile station that would benefit from the present invention and, therefore, should not be taken to limit the scope of the present invention. While several embodiments of the mobile station are illustrated and will be hereinafter described for purposes of example, other types of mobile stations, such as portable digital assistants (PDAs), pagers, laptop computers, mobile gaming devices and other types of electronic systems, can readily employ the present invention.
As shown, in addition to an antenna 14, the mobile station 10 can include a transmitter 48, receiver 50, and controller 52 or other processor that provides signals to and receives signals from the transmitter and receiver, respectively. These signals include signaling information in accordance with the air interface standard of the applicable cellular system, and also user speech and/or user generated data. In this regard, the mobile station can be capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More particularly, the mobile station can be capable of operating in accordance with any of a number of first generation (1G), second generation (2G), 2.5G and/or third-generation (3G) communication protocols or the like. For example, the mobile station may be capable of operating in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, the mobile station may be capable of operating in accordance with 2.5G wireless communication protocols GPRS, EDGE, or the like. Further, for example, the mobile station may be capable of operating in accordance with 3G wireless communication protocols such as UMTS network employing WCDMA radio access technology. Some NAMPS, as well as TACS, mobile stations may also benefit from the teaching of this invention, as should dual or higher mode phones (e.g., digital/analog or TDMA/CDMA/analog phones).
It is understood that the controller 52 includes the circuitry required for implementing the audio and logic functions of the mobile station 10. For example, the controller may be comprised of a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits. The control and signal processing functions of the mobile station are allocated between these devices according to their respective capabilities. The controller can additionally include an internal voice coder (VC) 52 a, and may include an internal data modem (DM) 52 b. Further, the controller may include the functionally to operate one or more client software programs such as those indicated above, which may be stored in memory (described below).
The mobile station 10 also comprises a user interface including a conventional earphone or speaker 54, a ringer 56, a microphone 58, a display 60, and a user input interface, all of which are coupled to the controller 52. Although not shown, the mobile station can include a battery for powering the various circuits that are required to operate the mobile station, as well as optionally providing mechanical vibration as a detectable output. The user input interface, which allows the mobile station to receive data, can comprise any of a number of devices allowing the mobile station to receive data, such as a keypad 52, a touch display (not shown), a joystick (not shown) or other input device. In embodiments including a keypad, the keypad includes the conventional numeric (0-9) and related keys (#, *), and other keys used for operating the mobile station.
The mobile station 10 can also include one or more means for sharing and/or obtaining data. For example, the mobile station can include a short-range radio frequency (RF) transceiver or interrogator 64 so that data can be shared with and/or obtained from electronic devices in accordance with RF techniques. The mobile station can additionally, or alternatively, include other short-range transceivers, such as, for example an infrared (IR) transceiver 66, and/or a Bluetooth (BT) transceiver 68 operating using Bluetooth brand wireless technology developed by the Bluetooth Special Interest Group. The mobile station can therefore additionally or alternatively be capable of transmitting data to and/or receiving data from electronic devices in accordance with such techniques. Although not shown, the mobile station can additionally or alternatively be capable of transmitting and/or receiving data from electronic devices according to a number of different wireless networking techniques, including WLAN techniques such as IEEE 802.11 techniques or the like.
The mobile station 10 can further include memory, such as a subscriber identity module (SIM) 70, a removable user identity module (R-UIM) or the like, which typically stores information elements related to a mobile subscriber. In addition to the SIM, the mobile station can include other removable and/or fixed memory. In this regard, the mobile station can include volatile memory 72, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data. The mobile station can also include other non-volatile memory 74, which can be embedded and/or may be removable. The non-volatile memory can additionally or alternatively comprise an EEPROM, flash memory or the like. The memories can store any of a number of software applications, instructions, pieces of information, and data, used by the mobile station to implement the functions of the mobile station.
As will be appreciated, a number of the entities of the system of FIG. 1 can be configured in any of a number of different architectures to perform any of a number of functions, such as to manage a multiplayer game. For example, the entities of the system of FIG. 1 can be configured to manage a multiplayer game in a centralized client-server architecture, decentralized architecture and/or proxy architecture, each of which are explained above in the background section. Additionally or alternatively, for example, the entities of the system of FIG. 1 can be configured in an architecture given in the Scalable Network Application Package (SNAP) (formerly Sega Network Application Package) provided by Nokia Corporation for applications such as in the context of multiplayer gaming.
More particularly, as shown in FIG. 4, for example, one or more mobile stations 10, PC systems 26 and/or game consoles 28 may operate as clients 76 in a gaming architecture that also includes one or more game servers 22 and/or routing servers 24. In the illustrated architecture, similar to a conventional client-server architecture (see background section above), the game servers operate games and maintain the state of those games. As will be appreciated, however, the routing servers and/or one or more of the clients themselves may alternatively operate portions, or all, of the games and maintain the state of those games. As used herein, then, although games can be operated by one or more network entities, including game servers, routing servers and/or client(s), the following description may refer to a game server as operating the games for purposes of illustration. Irrespective of the network entit(ies) that operate the games, however, the clients operate game applications that communicate with those network entit(ies) to continuously change the game state of the games operated and maintained by the network entit(ies) to thereby play those games.
Also in the illustrated architecture, the clients 76 are operatively coupled to routing servers 24 which, in turn, are coupled to the game servers 22. Thus, the routing servers route data packets between one or more clients 76 and the game servers 22, and/or other clients, to facilitate the operation of each entity in the architecture. As shown, the routing servers can be coupled between groups of clients and one or more game servers, directly or indirectly via one or more other routing servers. In this regard, one or more routing servers can also be coupled to other routing servers such that the routing servers can also be coupled between one or more clients and one or more groups of other clients, such as groups of clients coupled to other routing servers.
The entities (i.e., clients 76, game servers 22 and routing servers 24) of the illustrated architecture can communicate in any of a number of different manners. In one embodiment, for example, the entities communicate in accordance with the UDP (Universal Datagram Protocol) transport protocol, or in accordance with rUDP (reliable UDP), a proprietary protocol that operates above UDP. And although architectures such as that illustrated may provide an environment for ease in authentication, chat applications, and the setting up of game rooms and lobbies, a feature in such architectures that most directly impacts fairness is the transport protocol (e.g., rUDP/UDP) by which the entities of the architecture communicate with one another. Specifically, for example, rUDP provides for a means of guaranteed delivery of packets. In addition, rUDP allows for in-sequence delivery of packets generated from a client or game server. However, transport protocols such as rUDP do not provide a means of ordering packets as delivered from different clients. That is, transport protocols utilized by entities of architectures such as that illustrated in FIG. 4 generally do not include in-built mechanisms to ensure fairness. Moreover, the bandwidth management mechanism of such architectures allows for throttling the throughput generated by a client or game server based upon a fixed parameter. Effective latency of network communications between entities of these architectures, however, is not only variable from client to client but also variable over time for any individual client.
Embodiments of the present invention therefore provide a framework for overcoming the drawback of network latency in communications to and/or from clients 76 to one or more game servers 22 such that the client(s) 76 are capable of playing a game with the same perceived network latency, that being based upon the greatest network latency experienced by the client(s). Reference is now drawn to FIGS. 5 and 6, which illustrate functional block diagram and method, respectively, facilitating fairness in a game. As shown in FIG. 5, then, a plurality of clients (three being shown as clients 76 a, 76 b and 76 c) send data packets to, and receive data packets from, a game server to play a multiplayer game. In this regard, the game server is capable of operating a game application 78 for operating the game and maintaining the state of that game based at least in part on data packets received from the clients.
In addition, in accordance with embodiments of the present invention, the game server 22 is capable of operating a time-delay module 80, such as a time-delay application programming interface (API), for delaying data packets to the game server from one or more of the clients, and/or from the game server to one or more of the clients. More particularly, the time-delay module is capable of delaying data packets to the game server from one or more of the clients 76, and/or delaying data packets to one or more of the clients from the game server. The time-delay module is capable of delaying the data packets based upon network latency experienced by the respective clients 76 and an effective network latency, which is set based upon the network latencies experienced by the plurality of the clients playing the game.
As shown and described below, the game server 22 operates the time-delay module 80. It should be understood, however, that one or more routing servers 24 and/or other network entities can additionally or alternatively operate time-delay modules without departing from the spirit and scope of the present invention. Generally, then, data packets to and/or from the game server may be delayed from any of a number of different network entities between the clients and the game application operated by the game server. Further, although the time-delay module may comprise software operated by a network entity, the time-delay module may alternatively comprise firmware or hardware, without departing from the spirit and scope of the present invention.
A method of facilitating fairness in a multiplayer game includes determining, at the time-delay module 80, a network latency associated with each of a plurality of clients 76 playing a game. As will be appreciated, the network latency of a client can be determined or otherwise represented in any of a number of different manners including, for example, as a round trip time (RTT). In this regard, the RTT of a client is typically a measure of the time required for a data packet to travel from the client to the time-delay module, and back again to the respective client. Thus, as shown in FIG. 5 and block 84 of FIG. 6, determining a network latency associated with each of the clients may more particularly comprise determining a RTT associated with each of the clients. The RTT's can be determined in any of a number of different manners. In this regard, although the RTT associated with each client may be determined in a number of different manners, the RTT can be determined by sending a data packet (e.g., game traffic packet, control packet, etc.) to the client, and determining the amount of time required to receive an acknowledgement (ACK) packet back from the client. For purposes of example, presume that client 176 a has an RTT1=926.47 ms, client 2 76 b has an RTT2=1304.87 ms, and client 3 76 c has an RTT 3=1103.56 ms.
Irrespective of exactly how the RTT's of the clients 76 are determined, the time-delay module 80 can thereafter set an effective RTT based upon the RTT's of the clients, as shown in block 86. Although the effective RTT can be identified in a number of different manners, to facilitate fairness among the clients, particularly those with the highest RTT, the effective RTT may be identified as the highest RTT experienced by any of the clients. Delivery of data packets to and/or from one or more of clients can then be delayed based upon the effective RTT such that all of the clients experience the same effective RTT without requiring any of the clients to decrease their RTT, such as by altering the network channels over which the clients with the highest RTT send/receive data packets. Continuing the above example, then, the effective RTT may be set to RTT 2 of client 2 76 b, i.e., effective RTT=1304.87 ms.
Thus, at one or more instances after setting the effective RTT, the time-delay module 80 receives data packets from one or more of the clients 76, the data packets being intended for the game server 24, or more particularly the game application 78 operated by the game server, as shown in block 88. Similarly, the time-delay module may receive data packets from the game application, where the data packets are intended for one or more of the clients. For data packets received by the time-delay module from a client intended for the game application, and/or for data packets received by the time-delay module from the game application intended for a client, the time-delay module can delay the data packet for a delay time (i.e., delay n) associated with the data packet, or more particularly associated with the client sending the data packet, as shown in block 90. In this regard, the time-delay module can delay data packets to and/or from a client for a delay time such that the respective client experiences a RTT substantially equal to the effective RTT (i.e., RTT n≈effective RTT). Thus, in accordance with one embodiment, the delay time for a data packet can be determined to substantially equal the difference of the effective RTT and the RTT of the client sending the data packet. As used throughout, various quantitative measures may be described as being equal or substantially equal. It should be understood that in instances where values are described as being equal, such values may be substantially equal. Thus, in actual implementation, various values may differ somewhat (e.g., 1.0-5.0%) depending on a number of different parameters, such as variances in network latencies over time, measurements of the network latencies, and the like.
For example, presume the time-delay module receives a data packet from client 1 76 a, which has an associated RTT 1=926.47 ms. In such an instance, the time-delay module can determine a delay 1 that substantially equals the difference of the effective RTT=1304.87 ms and RTT 1, namely 378.4 ms (e.g., delay 1=1304.87 ms-926.47 ms). As will be appreciated, when the effective RTT is identified as highest RTT, the client (e.g., client 2 76 b) having the highest RTT will also have an associated delay of zero (e.g., effective RTT=RTT 2=1304.87 ms). The client having the lowest RTT, on the other hand, will have the highest delay.
The time-delay module 80 can be configured apply the delay time to data packets on the uplink (i.e., from the client 76 to the game application 78) and/or on the downlink (i.e., from the game application to the client) in any of a number of different manners to effectuate a RTT at the client substantially equal to the effective RTT. For example, when the time-delay module is configured to apply the delay time to data packets on the uplink, the time-delay module can delay data packets from the client to the game application for the entire delay time associated with the respective client. Alternatively, for example, when the time-delay module is configured to apply the delay time to data packets on the uplink and the downlink, the time-delay module can delay data packets from the client (i.e., client n) to the game application by a first time delay portion (e.g., ½ delay n), and delay data packets from the game application to the client by a second delay portion (e.g., ½ delay n). In such instances, the first and second delay portions sum to substantially the delay time (i.e., delay n) associated with the respective client. In yet another alternative example, when the time-delay module is configured to apply the delay time to data packets on the downlink, the time-delay module can delay data packets from the game application to the client for the entire delay time associated with the respective client.
After delaying data packets, the time-delay module 80 can pass the data packets to the game server 22, or more particularly the game application 78 operated by the game server, or to the respective client 76, for processing, as shown in block 92. More particularly, for example, after delaying data packets received from a client for the game application (if configured to at least partially delay packets on the uplink), the time-delay module can pass the data packets to the game application for processing. Similarly, for example, after delaying data packets received from the game application for a client (if configured to at least partially delay packets on the downlink), the time-delay module can pass the data packets to the client for processing.
During game play, for example, a data packet from a client can comprise a request to change the state of the game. In such an instance, the game application can receive the data packet from the time-delay module 80, and process the request to effectuate a change in the state of the game operated and maintained by the game application. In addition, the game application can return to the requesting client and/or other clients, a return data packet notifying the client(s) of the change in the state of the game, the return data packet being sent to the client(s) via the time-delay module. Conventionally, the time required for the client to send the request a change of the state of the game, and receive the return data packet, substantially equals the RTT of the client. In accordance with embodiments of the present invention, however, the time required for the client to send the request and receive the acknowledgement substantially equals the effective RTT, irrespective of the particular client.
As shown in block 94 and again in block 88, the time-delay module 80 can receive a number of different data packets from a number of different clients 76 playing the game operated and maintained by the game application 78. For data packets received from a client and/or the game application, then, the time-delay module can delay the data packet for at least a portion of the delay time associated with the client sending or receiving the data packet (see block 90). After the delay time, the time-delay module passes the delayed data packet to the receiving entity (i.e., game server 22 or client) for processing by the respective entity (see block 92).
As will be appreciated, the effective RTT can be periodically set or otherwise updated by the time-delay module 80. In this regard, at regular or irregular periodic intervals the time-delay module can determine or otherwise update the RTT's of one or more of the clients (see block 84). For example, when the network entities communicate in accordance with a protocol such as rUDP, the time-delay module can be configured to determine the RTT's of a client upon each instance of the client and the game application 78 operated by the game server 22 exchanging reliable transport packets, such as to transfer game states, variables, chat messages or the like during game play. Irrespective of exactly when the time-delay module determines or otherwise updated the RTT's of one or more of the clients, the time-delay module can then reset or otherwise update the effective RTT based upon the newly determined RTT's of the clients. Further, as shown in FIG. 5, the effective RTT can be periodically sent to the game application. The game application, if so configured, can then modify play of the game based upon the effective RTT and/or notification indicating that all of the clients are communicating with the game server with approximately the same effective RTT.
Additionally, by setting effective RTT equal to that of the slowest client 76 playing the game (i.e., client with the highest RTT), the time-delay module 78 effectively slows down game traffic to that of the slowest client. In various instances, such as when a large disparity exists between the slowest client and the other clients playing the game, however, it may be prohibitively undesirable to slow down game traffic to that of the slowest client. Thus, in various instances, the RTT's of the clients may be compared against a threshold RTT. Those clients having an RTT above the threshold may then be prohibited from participating or otherwise playing in the game, such as by the game server 22 or the routing server 24. By restricting game play to only those clients having a RTT below the threshold, the effective RTT can thereafter be set at or below the threshold, thereby facilitating faster game play among the clients permitted to play the game.
So as to not completely restrict from playing the game those clients 76 that otherwise have differing RTT's, such as those above the threshold RTT, the game server 22, or more particularly the game application 78 operated by the game server, may be configured to provide multiple concurrently operating occurrences of the game, each being capable of being played by a plurality of clients. The occurrences of the game can then be organized based upon the network latencies of the plurality of clients. More particularly, each occurrence of the game may be played by clients having similar RTT's such that none of the clients playing a particular instance of the game experience a significant decrease in speed of game activity by the delay of data packets to/from the game application. More particularly, for example, the game server or routing server 24 may be configured to provide a virtual lobby listing the occurrences of the game, the listing also indicating the relative speed of the clients playing the respective occurrences, such as by indicating effective RTT's of the clients playing each instance. An additional client desiring to play the game, then, may enter the virtual lobby and select an occurrence of the game to play based upon the relative speed of the clients playing the occurrence of the game. In this regard, the client desiring to play the game may receive, such as from the entity providing the virtual lobby, an indication of the RTT of the client such that the client can compare its RTT with the effective RTT's of the various occurrences to find an occurrence with an effective RTT more closely matching that of the client. The client may then select an occurrence to thereafter be received into the occurrence of the game.
According to one aspect of the present invention, all or a portion of the system of the present invention, such all or portions of the game server 22, routing server 24 and/or client 76 (e.g., mobile station 10, PC system 26, game console 28, etc.), generally operate under control of a computer program product (e.g., game application 78, time-delay module 80, etc.). The computer program product for performing the methods of embodiments of the present invention includes a computer-readable storage medium, such as the non-volatile storage medium, and computer-readable program code portions, such as a series of computer instructions, embodied in the computer-readable storage medium.
In this regard, FIG. 6 is a flowchart of methods, systems and program products according to the invention. It will be understood that each block or step of the flowchart, and combinations of blocks in the flowchart, can be implemented by computer program instructions. These computer program instructions may be loaded onto a computer or other programmable apparatus to produce a machine, such that the instructions which execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block(s) or step(s). These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block(s) or step(s). The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block(s) or step(s).
Accordingly, blocks or steps of the flowchart support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block or step of the flowchart, and combinations of blocks or steps in the flowchart, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
Many modifications and other embodiments of the invention will come to mind to one skilled in the art to which this invention pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A system for facilitating fairness in a multiplayer game, the system comprising:

a gaming architecture comprising at least one network entity capable of operating a game application, the game application being capable of operating a multiplayer game;

a plurality of clients capable of communicating with the gaming architecture across at least one network to play the multiplayer game, wherein the plurality of clients are each associated with a network latency, and wherein the plurality of clients include a given client; and

a time-delay module disposed across at least one network from the plurality of clients, and between the plurality of clients and the game application,

wherein the time-delay module is capable of receiving a data packet associated with the particular client during play of the multiplayer game, wherein the time-delay module is capable of delaying the data packet for at least a portion of a delay time associated with the particular client, the delay time being based upon the network latency of the particular client and an effective network latency set based upon the network latencies of the plurality of clients, and

wherein the time-delay module is capable of passing the delayed data packet to one of the game application and the particular client.

2. A system according to claim 1, wherein the time-delay module is capable of receiving data packets, delaying the data packets and passing the delayed data packets at least one of to and from the plurality of clients such that the plurality of clients play the multiplayer game with a network latency substantially equal to the effective network latency.

3. A system according to claim 1, wherein the game application is capable of providing a plurality of occurrences of the multiplayer game, wherein each occurrence is capable of being played by a plurality of clients, and

wherein the time-delay module is capable of receiving a data packet, delaying the data packet and passing the delayed data packet for each occurrence of the multiplayer game.

4. A network entity for facilitating fairness in a multiplayer game, the game server comprising:

a processor capable of at least partially operating a game application, the game application being capable of operating a multiplayer game played by a plurality of clients across at least one network, wherein the plurality of clients include a particular client and are each associated with a network latency, wherein the processor is also capable of operating a time-delay module,

5. A network entity according to claim 4, wherein the time-delay module is further capable of determining the network latency associated with each of the plurality of clients, and setting the effective network latency based upon the highest network latency of the plurality of clients.

6. A network entity according to claim 5, wherein the time-delay module is capable of periodically determining the network latency and setting the effective network latency.

7. A network entity according to claim 4, wherein the time-delay module is further capable of determining the delay time associated with the particular client, the delay time determined to substantially equal the difference between the effective network latency and the network latency of the particular client.

8. A network entity according to claim 4, wherein the time-delay module is capable of receiving a data packet, delaying the data packet and passing the delayed data packet for the plurality of clients such that the plurality of clients play the multiplayer game with a network latency substantially equal to the effective network latency.

9. A network entity according to claim 4, wherein the processor is further capable of comparing the latencies of the plurality of clients against a threshold latency, and prohibiting clients having a network latency above the threshold latency from playing the multiplayer game.

10. A network entity according to claim 4, wherein the game application is capable of providing a plurality of occurrences of the multiplayer game, wherein each occurrence is capable of being played by a plurality of clients, and

11. A network entity according to claim 10, wherein each occurrence is associated with the effective network latency of the clients playing the occurrence, and wherein the game application is further capable of receiving an additional client into an occurrence of the multiplayer game based upon the effective network latency associated with the occurrence and the network latency of the additional client.

12. A client for playing a multiplayer game, the client comprising:

a processor capable of communicating with a game application during play of a multiplayer game played by at least one other client, each of the clients being associated with a network latency,

wherein the processor is capable of communicating with the game application such that a time-delay module, disposed across the at least one network from the client, is capable of receiving a data packet associated with the client during play of the multiplayer game, such that the time-delay module is capable of delaying the data packet for at least a portion of a delay time associated with the client, the delay time being based upon the network latency of the client and an effective network latency set based upon the network latencies of the plurality of clients, and such that the time-delay module is capable of passing the delayed data packet to one of the game application and the client.

13. A client according to claim 12, wherein the processor is capable of communicating with the game application such that a time-delay module is further capable of determining the network latency associated with each of the plurality of clients, and setting the effective network latency based upon the highest network latency of the plurality of clients.

14. A client according to claim 13, wherein the processor is capable of communicating with the game application such that the time-delay module is capable of periodically determining the network latency associated with each of the plurality of clients, and setting the effective network latency.

15. A client according to claim 12, wherein the processor is capable of communicating with the game application such that a time-delay module is further capable of determining the delay time associated with the client, the delay time determined to substantially equal the difference between the effective network latency and the network latency of the client.

16. A client according to claim 12, wherein the network latency of the client is capable of being compared against a threshold latency such that the processor is prohibited from communicating with the game application if the network latency of the client is above the threshold latency.

17. A client according to claim 12, wherein the game application is capable of providing a plurality of occurrences of the multiplayer game, wherein each occurrence is capable of being played by a plurality of clients, and wherein the processor is capable of communicating with the game application during play of an occurrence of the multiplayer game.

18. A client according to claim 17, wherein each occurrence is associated with the effective network latency of the clients playing the occurrence, and wherein the processor is capable of being received into an occurrence of the multiplayer game based upon the effective network latency associated with the occurrence and the network latency of the client.

19. A method of facilitating fairness in a multiplayer game, the method comprising:

receiving a data packet during play of a multiplayer game, wherein receiving a data packet comprises at least one of receiving a data packet from a particular client across at least one network, and receiving a data packet intended for the particular client, and wherein the particular client is one of a plurality of clients that are each associated with a network latency;

delaying the data packet for at least a portion of a delay time associated with the particular client, the delay time being based upon the network latency of the particular client and an effective network latency set based upon the network latencies of the plurality of clients; and

passing the delayed data packet, wherein passing the delayed data packet comprises at least one of passing the delayed data packet to a game application when the received data packet is from the particular client, and passing the delayed data packet across at least one network to the particular client when the received data packet is intended for the particular client.

20. A method according to claim 19 further comprising:

determining the network latency associated with each of the plurality of clients; and

setting the effective network latency based upon the highest network latency of the plurality of clients.

21. A method according to claim 20, wherein determining the network latency and setting the effective network latency comprise periodically determining the network latency and setting the effective network latency.

22. A method according to claim 19 further comprising:

determining the delay time associated with the particular client, the delay time determined to substantially equal the difference between the effective network latency and the network latency of the particular client.

23. A method according to claim 19, wherein receiving a data packet, delaying the data packet and passing the delayed data packet occur for the plurality of clients such that the plurality of clients play the multiplayer game with a network latency substantially equal to the effective network latency.

24. A method according to claim 19 further comprising:

comparing the latencies of the plurality of clients against a threshold latency; and

prohibiting clients having a network latency above the threshold latency from playing the multiplayer game.

25. A method according to claim 19 further comprising:

providing a plurality of occurrences of the multiplayer game, wherein each occurrence is capable of being played by a plurality of clients, and

wherein receiving a data packet, delaying the data packet and passing the delayed data packet occur for each occurrence of the multiplayer game.

26. A method according to claim 25, wherein each occurrence is associated with the effective network latency of the clients playing the occurrence, and wherein the method further comprises:

receiving an additional client into an occurrence of the multiplayer game based upon the effective network latency associated with the occurrence and the network latency of the additional client.