CA2254915A1

CA2254915A1 - Multi-player game system and method

Info

Publication number: CA2254915A1
Application number: CA002254915A
Authority: CA
Inventors: Mark Vange; Alexander Effimov; Michael Kouts; Vladimir Lagutin; Marc Plumb; Daniel Shields; David Mckellar; Glen Wilson
Original assignee: Vr-1, Inc.; Mark Vange; Alexander Effimov; Michael Kouts; Vladimir Lagutin; Marc Plumb; Daniel Shields; David Mckellar; Glen Wilson; Circadence Corporation
Current assignee: Circadence Corp
Priority date: 1996-05-15
Filing date: 1997-05-15
Publication date: 1997-11-20
Also published as: AU2687697A; EP0958687A1; US6390922B1; US6050898A; WO1997043846A1

Abstract

An interactive multi-player computer hosted game employs an unstructured telecommunications link, such as the Internet (16), between a game server (14) and a plurality of game clients (18). A game server (14), associated with a game driver (14), performs a performance monitoring function to determine an optimal bandwidth for each connection to a game client. Each information packet generated by the game driver is prioritized and queued for transmission in order of relevance for the game client. The game server then optimizes the transmission of information packets through the telecommunication network to the game client. Processed user input is received through the telecommunication network from the game client and transmitted to the game driver.

Description

CA 022~491~ 1998-11-13 WO 97/43846 .PCT/CA97/00325 MULTI-PLAYER GAME SYSTEM AND METHOD

Field Of The Invention The present invention relates to a system and method of providing an interactiveS co,l,~uLer-hosted game to multiple players via a co,.~ .-ic~tions system.

Background Of The Invention Computer-hosted games are popular and comprise a wide variety of game subject matter ranging from conventional games such as chess to more exotic games such as flight 10 combat simulators. Traditionally, in most of these games the player conll,el~d against the c~ ule~, which em~ 3t~1 an opponent, or against another player present at the location of the computer, or a combination of both.

More recently, some computer-hosted games have provided features whereby two or 15 more players can play the game, either cooperatively or comretitively, via modem-based, local area n~o,k based, or Internet based teleco-----~ ions links between each player's computer.

While such multi-player games have enjoyed considerable success, they are relatively 20 limited in the number of players which can participate, often allowing no more than a maximum of four players, and require structured teleco-~ tions links between the player's co",l,.~l.,.~. in order to function prol)~,ly. Specifically, either a dial up telephone link or a local area network link must be established btlw~el~ the player's co~ ule,.. so that minim~l latency and guaranteed deliverability of i,~~ lioll through the telecomm-mir~ti~ns 25 link is provided.

~ Particular examples of Internet-based games include Multi-User Dungeons (MUDs), AIR WARRIOR, WARBIRDS, SUBSPACE, and MERIDIAN 59. MUDs are text based games where multiple users interact, but only in small groups. Players are grouped 30 according to the room in which the player is at any time. Only those players in the same room will interact with each other. However, since the game is text based, latency of SUBSTITUTE SHEET(RULE26) CA 022~491~ 1998-11-13 WO 97/43846 . PCT/CA97/00325 Il,u~ ion of information is not a problem for a smooth operation of the game. Further, there is usually a limit on the number of players who may enter a room at any time.

In AIR WARRIOR, WARBIRDS, SUBSPACE and MERIDIAN 59, there appears 5 to be no appm~l,l lirnit on the number of players who may play the game at any given time, nor a means of ac~essing band width requirements and throughput. While the air space of the game may be logically divided, there is no control over the band~,vidth of ll,."~",ic~ion All h~llllation is Ll~ lP~ on the assumption that all h~follllalion will arrive at the inten~led destinqtion in time. Clearly, the assumption becomes less viable as the number of l0 payers and their level of interaction hlcrcases.

S~ Of The Invention It is an object of the present invention to provide a novel multi-player game system and method which obviates or mitig~tes at least one of the disadvantages of the prior art.
It is desirable to have a multi-player game system and method which will support a relatively larger number of players and which does not require structured teleco,-",~ ions links such as dial up telephone links or local area network links.

According to one aspect of the present invention, there is provided a game server for a multi-player game system. The game server con~ ;ses:
a game driver for eY~oC~1ting a multi-player game and ge~ ting game il~llllation for playing the multi-player garne by at least one game client through a teleco-~ "ir~tion network, pri~ lg means for plin- ;~ g the game il~llllalion and le~l~ol~ivc;ly queuing the game h~llllation for Ll~ sion to the at least one game client, ap."luie control means for ~I;"-i,i"g the game h~llllalion for tr~n~mi~sion to the at least one garne client, and co1-----~.,ir-~tions means for ll~..c-lli~ g the game hlfullllation through the 30 teleco"""~.-ir~tiQn nt;lwolk to the at least one game client and for receiving processed user WO 97t43846 - PCT/CA97/00325 input through the teleco~ tion network from the at least one game client and tr~n~miftirlg the processed user input to the game driver.

According to another aspect of the present invention there is provided method of5 ~y~la~ g a multi-player game system having a game server co------~--ir~ting with a plurality of game clients connPcted through a teleco..----~ tions llelwo~k. The method comprises the steps of, for each game client:
prioritizing game h~llnalion gel.~.aled by a game driver executing a multi-player game, qlnPI~ing the game il~ll~ lion in order of priority for l~ .-.;.cs;on to the game client, optimi7.ing tr~n~mi~sion of the game hlrollllation to the game client, g the game ilLfollllation through the telecol,llllunication l~lwolk to the game client, receiving processed user input through the t~lPcol-,.--~ ion n~lwolh from the game 15 client and tr~ g the plocessed user input to the game driver, and repeating the steps for playing the multi-player game.

According to another aspect of the invention, there is provided an article of m~n-lf~-~.tllre comprising:
a cq--.~ l.,l usable mP-lil-m having co,ll~,uL~r readable program code means embodied therein for i~ le ll~ a multi-player game playable by at least one game client connected through a teleco---..-~ lions rlllw~lk. The co...y~h readable program code means in the article of m~n--f~ctllre colll~lises:
comrlutPr readable plogl~ code means for causing the CCnI1JLII~1 to prioritize game 25 inrollllalion gene~aled by a game driver exPc~ting a multi-player game, colllyut~l readable program code means for causing the col~ el to queue the gameinformation in an order of priority for l~ sion to the at least on game client, colllyulel readable program code means for causing the coll,yL~ l to oyLilni;~e Ll,.... ..~ sion of the game information to the at least game client, ColllyLIt~,~ readable ylOglalll code means for causing the COIIIYLII~1 to ~lal~llliL the game information through the teleco.n,...~i-ic~fion network to the at least one game client, Wo 97/43846 PCT/CAg7/00325 co~ uler readable program code means for causing the COlllyulel to receive processed user input through the teleco~ ation network from the game client and to tra~smit the processed user input to the game driver.

5 Brief Des~ ion Of The Drawings Preferred embo~1imPnt~ of the present invention will now be described, by way ofexample only, with reference to the ~tt~chPd figures, wherein:
Figure 1 shows a sc~ ic rèpresP.~ ion of an Inlelllet-based embodiment of the present invention;
Figure 2 shows a block diagram of a game client for the embodiment of Figure 1;
Figure 3 shows a block diagram of a server and game driver for the embodiment ofFigure 1; and Figure 4 shows a block diagram of pel~~ lce mo~ olillg, aperture control and syncl~ n functions of the game server shown in Figure 3.
Detailed Des~ tion Of The Invention A multi-player game system in accordance with the present invention is in~ at~P~generally at 10 in Figure 1. Game system 10 inr~ lPs a game driver 14 connP-cted to one or more co.~ ir~tions servers 12. Co--....--,-ir~tions server 12 is connPcted to a 20 teleco~ r~tion netwolh 16 which is in turn connPcte(l to a plurality of game clients 18 via a distribution system 20.

In the embodiment shown in Figure 1, it is co~ "~lated that teleco~----...,-ir~lion nc;Lwolh 16 will be a data packet type ll~;lwo~h, such as an IP based l~elwolh. Thus, llelwolh 25 16 will generally comprise a variety of relatively high bandwidth point to point teleco,.----,..~ ns links 22, the actual number and identity of the links 22 being subject to change, on a packet to packet basis, depel~dillg upon packet routing. The dynamic arrangement of these telecol~ r~tions links 22 is in~lir~lr~ in Figure 1 by the cloud-shaped block.

While it is contemplated tnat, in particular, game system 10 can advantageously employ the Internet as telecol~""~ tion nelw~lk 16, it will be a~parelll to those of skill in the art that the present invention is not limited to such use. Accordingly, other suitable telecolllll.~ ;r~liQn l~twulhs, including networks which are not packet-based, as will occur 5 to those of skill in the art, can be employed with the present invention as desired.

Distribution system 20 comlecL~ game clients 18 to teleco"""~"i~-~ion network 16 via telecomm~nirations linhs 24. In the case wh~ lehl teleco"""~"i~-~tion network 16 is tne Internet, it is contemplated that disllil~ulion system 20 will be an Internet Service Provider 10 (ISP) or the like and tclcco"-..,.l.,i~ions links 24 will be dial up telephone links, preferably with data commllni~tion rates of at least 9600 baud and higher, with higher rates being preferred. It is also ap~a~cnl to those skilled in the art that distribution system 20 is not limited to a single ISP; multiple ISP's can connect other game clients 18 via sepaldte telecol...l.~llir~tions links 24.
As will be appa~ l to those of skill in tne art, any other data l~,."~,."eeion t~chl~ e, such as CATV l~lwûlh~ ISDN or di~llibulcd fiber optic networks can be used for teleco"""~ ;r~tiQns link 24. In any case, it will be ~ ood by tnose of skill in the art that teleco--"",-,-;r~ti- n~ links 24 will be cQn~ to game clients 18 by a suitable data il~Lclrace 20 for lldl-~ g and receiving data.

Each game client 18 can be any c~ ulcr l)lallullll suitable for ex~c~ting a game and m~int~inin~ a teleco,,,.,.~ ir~ion link and such platforms include IBM PC compatible collllJulcl ~y~LclllS, Apple Macintosh co"ll,uler systems, games collll,ul~ l systems such as a 25 SEGA Saturn games co",~ut~r, game consoles or set top consoles.

As shown in ~igure 2, each game client 18 can collll)lise an O~e~dLing system 100, a co""",l"ic~tions sorlv-ale 102, an optional client system clock 104 or other means of system ~y~chlo~ alion, game client software 106 and a game client API 108 providing a 30 defined interface bclweell col~ c~tions software 102 and game client software 106. In CA 022~491~ 1998-11-13 WO 97/43846 . PCT/CA97/00325 addition, game client 18 includes game playing input and output devices 110 to interact with the game player.

Operating system 100 can be any suitable ope~ g system which provides at least S a set of basic input and output functions for the hal-lw~lè platform. If an IBM PC colllpalil)le system is selected, operating system 100 can be a GUI-based OpClalin~ system such as Windows 95 or OS/2 Warp, or an older opeldlillg system such as MS-DOS. If an Apple Macintosh is selected, operating system 100 can be Apple's System 7, etc. If a games COlll~utC. system is selectr~l, such as a SEGA Saturn, Nintendo Ultra or the }ihe, opelàlillg 10 system 100 may be rwl;",~ .y and/or specifically written to provide nrce~ ry system level functions for use as a component of the software of game client 18.

G~llllll.l,1ications software 102 coo~ ates with opel~Lillg system 100 and the c~ irAIions har-l~alè, such as a modem, LAN or WAN, of game client 18 to establish, 15 ~"~ ;" and utilize teleco""l,-l.~;r~tion linh 24 to distribution system 20. Co-llll.~ ir~tions software 102 opc l~L~s to receive inrollllation from col~ ..;r~lions server 12, via teleco-"",~ ir~tion l1é~wolh 16 and telec~ ""~,ir~ions linh 24 and to forward this received information to client sorLwale 106 via client API 108. Co"""~ ;r~ions software 102 also ol)el~s to receive il~llllalion from client sorLwal~e 106, via client API 108, and to Ll~lL~lllil 20 this processed data to c~ ions server 12 via telecu~",.,~ lions linh 24 and n~lw.Jlh 16. As will be a~a~ l to those of skill in the art, the IlA~ sion of data to game client 18 need not occur at the same rate as data is llAn~ d from game client 18.

In any event, ccs"""~ ;r~lions software 102 p~lrO,llls all of the functions nrceSS~ry 25 to effect the receipt and L~ ion of data belween co-~ -;rztions server 12 and game client 18, including pelrollllil1g the nrcess~ry steps to construct suitable packets for l"i~ion and/or decode received packets for use by client software 106, includingestablishing tr~n~mi~ion and receipt buffers or analogous means to buffer il~llllalion, performing error correction on received packets, providing acknowledgement of packets 30 received and/or re-sen~ling packets, re-ordering packets, etc. A variety of known methods CA 022~491~ 1998-11-13 WO 97/43846 . PCT/CA97/00325 for implem~nting co~ ir~tions software 102 will be apparent to those of skill in the art and thus will not be further di~cussed herein.

Client software 106 is executed by game client 18 to, at a minium, receive input and S provide the output n~ce~s~ry for a computer-hosted game to be played at game client 18.
DepPn~iing upon the h~dwale capabilities of game client 18, client software 106 can produce a variety of suitable outputs with game playing input and outputs 110 including graphics, text, sounds, etc. Similarly, client software 106 can accept a variety of game player inputs via game playing inputs and outputs 110 including keyboard, joystick, games controller, 10 mouse input, etc.

Client software 106 pe.rulllls a ~ignifir~nt amount of proces~ing of user input received from the game player via game playing input and output 110 and applc,pliale updating of output. In this manner, raw or processed user input is ll~ .c~--illed back to the 15 game driver 14, limiting the amount of data to be ll~...x---ill~d.

For example, in a flight sim~ tor air combat-type game, client software 106, e~cl~ting on an I13M PC compatible co",~uler system, can process input received from the game player and produce ~pplopli~t~ly updated graphics, status changes, sounds, etc.
20 Specifically, client sorl~are 106 will process a user input ,~rese..-li-.g an attitude change for the ~im~ t~ l aircraft through a m~ l model of the flight characteristics of the aircraft to de~ the cha"ges to the aircraft's res~lltin~ flight condition. The graphics displayed to the game player by game playing input/output 110 is then updated to reflect the applol"idl~ changes to the aircraft's cockpit hl~L~ llelll~ and the view through the canopy.
25 Further, game client software 106 can de~e~ ~ . -i. .~ whether another player's shots have hit, and if so, dt;l.,l,llh~e whether the player can continue play. Accordingly, client software 106 - preferably pelrull"s a ~ irr~ portion of the processi,lg required to implement a colll~uleL
hosted game.

It is colllellll)lated that client sof~wale 106 will be written or modified specifir~lly for each game int~nrl~d to be played with system 10 and to provide multi-player capabilities CA 022~491~ 1998-11-13 through network 16 via client API 108. Further, while in some cases client software 106 may be stored in a non-volatile memory in game client 18, it is contemplated that in many circumstances client software 106 will be tr~n~mittPcl to game client 18, as n~e~le~l, via network 16.

As shown in Figure 3, co~ ir~fions server 12 may include one or more game servers 200, a server system clock 202, and a server API 204 through which game server 200 co-,~ ir-~s with game driver 14.

Game driver 14 includes game software 206 providing the co-ordination and a~ dlion of events reslllting from the play of the game players in a particular multi-player game. Game driver 14 may receive h~ll,ldlion from game clients 18 to which it isconn~-cte~l via ct)..----~l,-ications server 12. The i,~l"lalion is processed by game software 206 to produce an appl~lidt~ output which is then tr~n~mittPd to each affected game client 15 18. For example, in an interactive air combat type game, game driver 14 may receive ,l~ro"-~tion that a player has fired a shot. After ploce~ g by game software 206, the output may be that the player has shot down another player at a dir~.enl game client 18. Game driver 14 may also l,al~",il information of a global nature to each game client 18, such as a transition from day to night oc~;ulling in the game.
Game driver 14 may be integrated with co-~ tions server 12. However, it is contemplated that game driver 14 be ~aldle sorlware of the multi-player game system 10.
An advantage of sepaldlil~g the co-~ ic~tions server 12 from the game driver 14 is that a variety of dirr~l~nl games can be played by using dirre~nl game drivers siml-lt~n~ously 25 with a single cc~ -ir~tions server 12. Additionally, one or more game drivers 14, responsible for a single game, may commun~ e with multiple coln---~ tions servers 12 to co,--~ t~ with a greater ~ lber of gafi~ clients 18. However, it is apl,dlenl to those skilled in the art that when multiple co..---.~,-ic~tions servers 12 are used, the multiple c~ ons servers 12 must be ~ynclllol~i~ed. S~--chlo~ n can be through a network 30 time protocol, or independent means associated with the system.

Game il~llllalion, in the form of il~l,nalion packets, is fo, ~lded from game driver 14 through server API 204 to game server 200, for tr~n~mi~sion to game clients 18.
Associated with each il~o~ inn packet is a component referred to by the present invenlol~
as a Relevancy Vector (RV). The RV is a logical construct which provides an indication of S the importance of the illr~ lalion in the il~l,l~Lion packet relative to other packets int~n-le~l for the same game client 18. In the plel; ~led embo-lim~nt, RV's are ml~lti~ ional arrays of values that can be e~min~d by game server 200 to evaluate packets against each other to prioritize the packets for tr~ncmi~sion. The h~ollllalion packets with the highest RV values are inserted into a queue for transmission to each game client 18 in decrcasillg order. When 10 information packets are received by the game server 200 which have the same level of importance, the RV is then processed by the game software 206 to a.l,illate which is to be Ll~ cl first. The creator of the game software 206 must consider the relative importance of h~llllaLion when ~ alillg the game software to provide a~plul.l;ate rules for arbitrating relative importance of information.
For example, in an air combat simlll~tor game, game driver 204 iS continll~lly l;l-g some h~~ alion to each game client 18. This information can be: Location(x, y, z); ~ ling(x, y, z); Global Status(Hit, Crashed, Exploding); Local Status(Firing, Weapons, Burning, Control_Surface_Movement); etc. An RV for this h~llllation packet 20 will include information for each piece of data which is appl~u~riaLe to characterize it's relevance. The actual values in the RV array can be booleans, numerical values, flags or mixture of these types, as rnay be a~rol)liat~, for the type of il~l-llaLion they are associated with. When il~lllldliol1 packets have the same integer for the first value, i.e. the same level of importance, the rest of the RV is then processed by the game software 206 to all,ill~le 25 which information packet is to be l~ .lliu~l first.

- For example, the RV can contain the following information:
Location: How far away is the sending aircraft from the receiving aircraft? Is the sending aircraft in the field of view of the receiving pilot?
~Te~-ling: Is the sending aircraft h~ing tow~ds or away from the receiving aircraft?
If towards, how quickly are they closing?

CA 022~491~ 1998-11-13 WO 97143846 . PCT/CA97100325 Global_Status: If any defined event is occurring, is it hlll)olldlll?; and Local_Status: How important is an event to a particular client? This could, for example, depend upon physical fiict~nre for visual effects or the age of the hlrolllldlion.

One of the contemplated advantages of the present invention is that teleco~ ir~tions ncLwolh 16 can be the Internet or other network. However, such networks have problems in that the bandwidth available for ll,.,~",i.csion of a packet from c- """~"ir~ ons server 12 to a game client 18 can change from packet to packet and certainly each time a new telec-""""~l-ir~lions link 24 is established. Further, depelldhlg upon the type 10 of packet protocol employed, it is not always possible to certify delivery of a packet andlor the delivery order of a series of packets. For example, the packet protocol employed on the Internet is presently IP which provides for TCP packets and UDP packets. The delivery and delivery order are gudld,l~eed for a TCP packet. In contrast, delivery and/or delivery order of UDP packets is not gua,d"lccd.
While it is desirable to always employ TCP packets or the like, these typically result in a reduced overall useful throughput in teleco~ tion llclwO~h 16 due to the protocol overhead and the bandwidth used to lldn~lllil the acknowledgement packets which are sent by the destination to COnfllm receipt of the packet. Thel~crcilc, in the embodiment of the 20 present invention shown in Figure 1, UDP packets are employed to m~ximi7e the useful throughput of telecc lllll .~ ion network 16. Accordingly, client sorlwdrc 106 and game software 206 are constructed with the assumption that teleco-",~ ie,ltion llclwOlh 16 is "lossy", i.e. - some packets may not arrive at their inten-led l1estini~tion, as is described below in more detail.
To achieve s~ticf~ctQry pclrulllldllce regardless of the lossy nature of the tr~ncmiccinn network, game server 200 pc~r~ -s a pclro~ dnce ",ol..loli,lg function 300 and a bandwidth aperture function 320, each of which is dicc~lcsed below with rere,cllce to Figure 4.

In the ~ru.~ance "lonilo",lg function 300, the game server 200 allc",~ to monitor the available bandwidth of the connection btlween game server 200 and each le~ e~ e game CA 022~491~ 1998-11-13 client 18. Specifically, at step 302, game server 200 'floods' a connection to a respective garne client by ll~n~ g packets at an initial bandwidth predete~ ined by the capabilities of the tr~ncmicsion nclwolh, and varying the tr~ncmiccion speed up or down depending on the capabilities of the connection to a specific game client 18. In a marmer somewhat similar 5 to the PING utility of the IP protocol, i,lrol,llalion relating to the ll,.~,~---iccion time of these packets is reflected back to game server 200 and recorded. Altc"~tively, ilirolllldlion relating to the tr~n.cmic.cion time of packets can be ~csessed on an ongoing basis without flooding the connection.

The inrollllalioll reflected back to pel~~ ce mol~ilolillg function 300 at server 200 includes the total round trip t~ .--icsion tirne. However unlike the PING utility, the packets are of a variety of sizes, rather than a fixed size, to more closely replicate the real world ~,~ n.~ ic!~ion of game data packets which are of variable length. The pe. rollllallce mol~ilolillg function 300 increase or decreases the lla,~..-i.ccion rate and records the tr~ncmic.cion time 15 for each packet sent back to game server 200.

From the data produced in the above-described latency test, at step 304 the pe,roll"allce Ill~l~ilolil~g feature develops a set of metrics for each connection, including the bandwidth available and, more illl~Ol l~lllly, how the latency in the connection varies with 20 bandwidth utilization and packet size. These metrics are used in conjuilclion with the a~ellure control function 320. The co---~ ionC bandwidth is m~xi~ d to an optimal bandwidth until the predetermined m~ximllm latency is excee~le~l In general, the optimal bandwidth is det~,.lllilled by d~l~."-;..;--g a m~ximllm25 bandwidth at the pred~le,l,lilled m~ximl-m latency. If the maximum bandwidth is greater than the initial bandwidth, the initial bandwidth is increased to the m~ximllm bandwidth. If the maximum bandwidth is less than the initial bandwidth, the initial bandwidth is hlcr~ lly reduced to the m~ximllm bandwidth. The process is continuously repeated varying the optimal bandwidth. If the m~ximllm bandwidth is outside predetermined limits 30 at any time, the connection is ~ d.

CA 022~49l~ l998-ll-l3 The predel~ od maximum latency is set by the author of the game. Certain games can wi~ l greater latency than others. For in~t~nre, chess can have an extended latency whereas air combat games must have a very short latency.

It will be ul~de~ od by those of skill in the art that p~,. r(~ ce monitoring function 300 will be performed each time a connection is established to a game client 18 and is ~esesse~l on an ongoillg basis. Garne server 200 continuously monitors each tr;~n~mi~sion of each i,~llllaLion packet and will d~ lll.ne whether the latency is increasing or decreasing.
In response, the bandwidth is varied so that the pred~Lellnilled maximum latency is not 10 excee-le(l As will be a~arellt to those of skill in the art, lla.-~-"i~sion latency is an important consideration in implr~n~ i--g a multi-player colll~ul~l hosted game and, specifically, ill~la~;~ions belw~ell players which are subject to large l~1r~ ies are often un~ceptable. For 15 example, an ~ rc~l~ble latency can result in one player in an air combat sim~ tor shooting at another player who avoids the shot because he has moved to another location before the data r~l.,.~f ~ g the shot arrives at his game client 18 from game server 200. Accordingly, the present inventors have detellllilRd that game server 200 must give consideration to the metrics for both the available bandwidth and the latency characteristics for each comleclion 20 and these metrics are used to derive a present optimal bandwidth for the connection at step 306. As used herein, the term present optimal bandwidth refers to the bandwidth at which the best tr~n~mi~sion bandwidth is obtained for a preselected m~imllm latency.

As will be appalenl to those of skill in the art, each of the game clients 18 may 25 experience a different latency with the conse~luence that dirr~ l game clients 18 will llanslllil and receive il~llllalion at dirr~,.ell~ rates. This is further complicated by the fact that the latency for each game client f.~ f,s every time a new Internet connection is made.
Moreover, each of the client system clocks 104 and game system clock 202 may be set to different times. Therefore, further associated with each iuro~ ation packet is a time stamp.

CA 022~491~ 1998-ll-13 Co~ Ations server 12 time stamps the information packet when it is inserted in the queue and sets an age limit on each information packet. In order that the time stamp - associated with each il~~ alion packet is co~ lell~ for each game client 18, the time stamp ~tt~t'h~ to each i,lr~lmaLion packet is s~llcl~ ed with the game client's client system clock 5 104 by synchlolli~alion function 350. Each time game client 18 makes a new connection, a client time signal according to the client system clock 104 is sent to the game driver 14 where the signal is received at a certain system time as in-licAtecl by the game system clock 202 at step 352. Game driver 14 cAlr-ul~t~os the dirr~,r~ilce belw~ell the system time and client time at step 354.
When an information packet is being assembled for a specific game client 18, thedifference c~lculAt~d at step 354 is subtracted from the system time to arrive at the synchronized time stamp in step 356.

As mentioned above, game server 200 implements an a~ lule control function 320.
Aperture control function 320iS used to proactively restrict and oplin.i,e the bandwidth of the data leaving co..~ --cAtions server 200 to the present optimal bandwidth for the connection. Specifically, at step 322, game server 200 e~all.hles each ' infollnation packet received from game driver 14 to delclllline its bandwidth requirements.

At step 324, game driver 14 e~ s the RV associated with each il~lmation packet and det~,lll-i~les the relevance of each il~lllldlion packet relative to those others int~n-1ed for the same game client 18. The h~llllalion packets with the highest relevancy are inserted into a queue in decreasing order.

At step 326, if the time the h~lll~lion packet sits in the queue e~rree~ls its age limit, then the information packet is discarded or deleted. Otherwise, the hlrollllation packets remain in the queue and could be assembled into larger data packet(s) which will not exceed the present optimal bandwidth at step 328. Game server 200 assembles the hlfollllalion 30 packets into one or more data packets and tl~lllils the data packets to game client 18 at step 330.

In the example RV given above, if an i,~~ ion packet relates to an aircraft which is firing its weapons, but which is out of range of the aircraft flown by the player at a game client 18, then ap~llu,e control function 320 will queue this il~l,llalion packet if the present optimal bandwidth to game client 18 would be exceedecl. If the aircraft is flying and there 5 are several other aircraft flying, some nearer than others, then the information packets relating to the nearest aircraft are ll~ d first and more frequently to the game client 18.

The above-described embo-lim~nt~ of the invention are inten~led to be examples of the 10 present invention and alterations and mo~lifir~ti~ns may be effected thereto, by those of skill in the art, without depalling from the scope of the invention

Claims

We claim:

1. A game server for a multi-player game system, said game server comprising:
a game driver for executing a multi-player game and generating game information for playing said multi-player game by at least one game client through a telecommunication network, prioritizing means for prioritizing said game information and responsively queuing said game information for transmission to said at least one game client, aperture control means for optimizing said game information for transmission to said at least one game client, and communications means for transmitting said game information through said telecommunication network to said at least one game client and for receiving processed user input through said telecommunication network from said at least one game client and transmitting said processed user input to said game driver.

2. A game server as claimed in claim 1 wherein said aperture control means comprises monitoring means for determining an optimal bandwidth of a connection through said telecommunications network to said at least one game client; and limit means for limiting a bandwidth for transmission of said game information to said optimal bandwidth.

3. A game server as claimed in claim 2 wherein said monitoring means comprises means for flooding said connection with information to determine a latency characteristic of said connection;
means for developing a set of metrics for said connection responsive to said latency characteristic; and means for assessing said set of metrics and responsively determining said optimal bandwidth.

4. A game server as claimed in claim 3 wherein said game information is generated in information packets, and said prioritizing means assesses each information packet, produces an array of values indicative of a relevance relative to other information packets for said at least one game client and assess the array for queuing each information packet in order of highest relevance first.

5. A game server as claimed in claim 4 wherein said game server has means for receiving a time signal from said at least one game client when said at least one game client connects with said game server through said network and determining a difference between a game server time and time of said at least one game client, and synchronization means for applying said difference to each information packet.

6. A game server as claimed in claim 5 wherein said prioritizing means has means for setting an age limit for each information packet to remain in said queue, and means for discarding each information packet from the queue if said age limit isexceeded.

7. A game server as claimed in claim 6 wherein said game server has a plurality of game drivers.

8. A game server as claimed in claim 6 wherein said game driver generates game information for playing said multi-player game by at least two game clients through a telecommunication network, and said prioritizing means prioritizes said game information and responsively queues said game information for each of said at least two game clients, and said aperture control means optimizes said game information for transmission for each of said at least two game clients.

9. A method of operating a multi-player game system having a game server communicating with a plurality of game clients connected through a telecommunications network comprising the steps of, for each game client:
prioritizing game information generated by a game driver executing a multi-player game, queuing said game information in order of priority for transmission to the game client, optimizing transmission of said game information to the game client, transmitting said game information through said telecommunication network to thegame client, receiving processed user input through said telecommunication network from the game client and transmitting said processed user input to said game driver, and repeating the steps for playing the multi-player game.

10. A method as claimed in claim 9 wherein said step of optimizing comprises the steps of determining an optimal bandwidth of a connection through said telecommunicationsnetwork to said game client; and limiting a bandwidth for transmission of said game information to said optimal bandwidth.

11. A method as claimed in claim 10 wherein said step of determining an optimal bandwidth comprises the steps of:
flooding said connection with information at an initial bandwidth to determine alatency characteristic of said connection;
developing a set of metrics for said connection responsive to said latency characteristic; and assessing said set of metrics and responsively determining a maximum bandwidth at a preselected maximum latency, and if the initial bandwidth is less than the maximum bandwidth, increasing the initial bandwidth to said maximum bandwidth, and if said initial bandwidth is greater than said maximum bandwidth incrementally reducing the initial bandwidth to said maximum bandwidth and if the maximum bandwidth is outside predetermined limits, terminating the connection.

12. A method as claimed in claim 11 wherein said step of determining an optimal bandwidth is repeated each time a new game client is connected to the game server through the telecommunications network.

13. A method as claimed in claim 12 wherein said game information is generated in information packets, and said step of prioritizing comprises the steps of assessing each information packet for its relevance relative to other information packets for said game client, and queuing each information packet in order of highest relevance first.

14. A method as claimed in claim 13 wherein said method further includes the steps of receiving a time signal from the game client when said game client connects with said game server through said network;
determining a difference between a game server time and time of said game client, and applying said difference to each information packet.

15. A method as claimed in claim 14 wherein said step of claim 14 is conducted on an ongoing basis.

16. A method as claimed in claim 14 wherein said step of prioritizing includes the steps of setting an age limit for each information packet to remain in said queue, and discarding each information packet from the queue if said age limit is exceeded.

17. An article of manufacture comprising:
a computer usable medium having computer readable program code means embodied therein for implementing a multi-player game playable by at least one game client connected through a telecommunications network, the computer readable program code means in said article of manufacture comprising:
computer readable program code means for causing the computer to prioritize gameinformation generated by a game driver executing a multi-player game, computer readable program code means for causing the computer to queue said gameinformation in an order of priority for transmission to the at least on game client, computer readable program code means for causing the computer to optimize transmission of said game information to the at least game client, computer readable program code means for causing the computer to transmit said game information through said telecommunication network to the at least one game client, computer readable program code means for causing the computer to receive processed user input through said telecommunication network from the game client and to transmit said processed user input to said game driver.

18. The article of manufacture as claimed in claim 17 wherein said computer readable program code means for causing the computer to prioritize game information generated by a game driver executing a multi-player game includes computer readable program code means for assessing information packets of said game information, for producing an array of values indicative: of a relevance relative to other information packets for said game client and for assessing the array for queuing each information packet in order of highest relevance first.

19. The article of manufacture as claimed in claim 18 wherein said computer readable program code means to optimize transmission of said game information to the at least one game client, includes computer readable code means for flooding said connection with information to determine a latency of said connection;
computer readable code means for developing a set of metrics for said connectionresponsive to said latency; and computer readable code means for assessing said set of metrics and responsively determining a maximum bandwidth at a preselected maximum latency, and for increasing an initial bandwidth to said maximum bandwidth if the initial bandwidth is less than the maximum bandwidth, and incrementally reducing the initial bandwidth to said maximum bandwidth if said initial bandwidth is greater than said maximum bandwidth and terminating the connection if the maximum bandwidth is outside predetermined limits.

20. The article of manufacture as claimed in claim 19 wherein said computer readable program code means for optimizing transmission of said game information to the at least one game client, further includes computer readable code means for receiving a time signal from the game client;
computer readable code means for determining a difference between a game server time and time of said game client, and computer readable code means for applying said difference to each information packet.

21. The article of manufacture as claimed in claim 20 wherein said computer readable program code means for optimizing transmission of said game information to the at least one game client, further includes computer readable code means for causing the said computer readable program codemeans for optimizing transmission of said game information to the at least one game client, to optimize on an ongoing basis.

22. The article of manufacture as claimed in claim 19 wherein said computer readable program code means for causing the computer to prioritize game information generated by a game driver executing a multi-player game further comprises, computer readable code means for setting an age limit for each information packet to remain in said queue, and computer readable code means for discarding each information packet from the queue if said age limit is exceeded.