Multi-player computer game system and method

【0001】

[Cross reference for related applications]

This application claims the priority of Provisional Patent Application No. 60 / 183,318 filed on February 17, 2000.

[Technical field]

The present invention relates to multiplayer and improved single player computer games, systems and methods.

【0002】

[Background technology]

Computer game players always demand more provocative, visually and emotionally exciting games. The game must retain the player's attention, pull the player back into the game over and over, and facilitate the play of the multiplayer game. Although some forms of multiplayer games are already playable (eg video arcades, side-by-side platform gameplay), game players have become more proficient, and high-performance computing devices are now available to the general public, and Now that you have quick internet connection speeds, it's all helping to raise the bar for multiplayer gameplay.

【0003】

What is not yet possible is to play multiplayer games between players with different arithmetic units. For example, side-by-side gameplay requires that each player's computing device is compatible with the devices of other players. Even when playing multiplayer games over the Internet, many players need to have the same or at least compatible arithmetic units. The reason is that the software that each player runs on his computer must be compatible with the software on the devices of the other players (ie, must be able to communicate in both directions).

【0004】

Also, the development of multiplayer computer games is still time consuming and costly. One reason is that a wide variety of hardware platforms are currently available for playing multiplayer games. Multiplayer games must be developed for each platform with little crossover or reuse of application code from one platform to another. In addition, new software developers and even experienced developers have significant learning curves for hardware-specific protocols, communication specifications, new platforms and development tools. Therefore, current methods of developing multiplayer computer games suffer from significant drawbacks.

【0005】

[Disclosure of Invention]

The present invention is directed to multiplayer computer games, systems and development methods. INDUSTRIAL APPLICABILITY The present invention may operate in connection with a processor of a client computer so that a multiplayer game can be played between different hardware platforms in any of a client / server, client / client, or client / client / server configuration. Provide the desired software. The present invention also provides special purpose software that may operate in connection with the processor of a server computer (or multiple server computers) to facilitate and manage the play of multiplayer games over a network. Special purpose software on each of the client and server computers can be installed and run on various client computers to provide a seamless connection between game players over the network, regardless of different hardware platforms and operating systems. , Facilitates and manages communication between client computers (ie players) and server computers. The amount of functionality provided by the client special purpose software and the server special purpose software is a number of variables, such as the format of the multiplayer game, the number of players, the connection configuration (eg, client / client, etc.), the game state (eg, client / client, etc.). , Start, add new player, leave player, etc.).

【0006】

According to embodiments of the present invention, special purpose software that may operate in connection with the processor of a client computer to facilitate a multiplayer computer game is a client computer, a server computer, and at least one other client computer. Multiple elements (eg, modules, libraries, subsystems) that facilitate communication with other client computers that are installed there and have special purpose software that can operate in connection with that processor. , Etc.). The elements provided on the client computer depend on the level of multiplayer functionality required for a particular multiplayer game.

【0007】

The client computer includes a computing device having a processor involved in operating the special purpose software according to the present invention. Such calculators include, for example, personal computers (desktops, laptops), handheld calculators (eg, personal digital assistants (PDAs), such as Palm®, BlackBerry®), computer game consoles (eg. For example, Sony Playstation® and Playstation 2, Sega Dreamcast®), cellular devices, and other currently known, upcoming computers suitable for multiplayer gameplay, including. Not limited to these.

【0008】

The present invention is also directed to, for example, a multiplayer game system for facilitating multiplayer computer gameplay via a network such as the Internet. According to this embodiment of the invention, servers or servers that can connect to each other and to a network are each associated with each processor to facilitate multiplayer gameplay across the network between multiple client computers. Includes special purpose software that can work with. Based on various embodiments of the present invention, a single server, a plurality of servers in a single location, or a plurality of geographically displaced servers are provided. The server provides the client computer with various functions to facilitate multiplayer gameplay. For example, a server is a client (ie player) registration information, a logical map of the names and locations of all servers in a multiplayer game system, resources given to or made available to players during gameplay (but security). Or not given to the client computer for efficiency reasons), and various other functions and information detailed below can be maintained.

【0009】

The server architecture of the system of the present invention provides flexibility, ruggedness and performance improvements, among other features and effects. Typically, a server provides a category of functionality. In essence, server A provides function A. Within a network environment as provided by the present invention, there is a set of servers that provide various functions that are sometimes redundant (ie, provide backup) and sometimes completely individual and different. When servers of the same form (ie, functionality) work together, they give primary functionality, scalability, load balance, quick response, and thus game performance, reliability, consistency, and can work together. On the other hand, servers that provide different functions may or may not collaborate to provide functional improvements.

【0010】

The consistent server configuration of the multiplayer gaming system of the present invention effectively provides multiple servers specifically designed and intended to work together. This improves the overall functionality of the system of the invention. The servers provided by the present invention are complementary in service and can leverage all or some of each other's capabilities. One of the important benefits of the present invention is given in the interoperability of the server. Different applications can be developed to interact with certain other applications. This is usually done by having an engineer develop a custom solution for the application to work together. However, more advanced systems, such as the systems of the invention, provide a set of infrastructure tools that allow different applications to work with different other applications without custom solutions (eg, there are). (Similar to the "cut and paste" feature, which is given by the word process program but can also be used in applications other than the word process program). "Sharing" of server interoperability and functionality according to embodiments of the present invention includes, for example, service finding tools, common user registration, common authentication / security, common administration, open databases, common protocols, common data formats, and others. Provides the ability to work with the system of, but is not limited to these.

【0011】

The present invention also allows software engineers to rapidly develop new multiplayer computer games by eliminating the need to write specific application code for each hardware platform, communication protocol or operating system (OS). That is, it is also directed to software development methods that facilitate software development). According to this embodiment of the invention, the software developer writes software code specific to a multiplayer game application without involving the hardware platform or OS on which the game is played or the communication protocol is used. Just need it. According to the present invention, the cross-platform core is between a particular application code and the communication protocol of the operating system, hardware unit, and computer (these generally differ from one computer to the next). Give an interface to. Therefore, software developers only need code for the cross-platform core, which is always the same regardless of the hardware platform or operating system. The cross-platform core handles all communication between the application code and the client computer, including communication between the client computer and the server.

【0012】

[Best mode for carrying out the invention]

Other aspects, features and functions of the present invention will become apparent from the following detailed description with reference to the accompanying drawings. However, the accompanying drawings that are not on the correct scale merely exemplify the present invention and do not limit the present invention in any way, and the present invention shall be limited only by the scope of claims. The same elements are described in detail below with reference to the accompanying drawings with the same reference numbers across a number of drawings.

【0013】

The present invention is directed to multiplayer computer games, systems and development methods that facilitate the play of multiplayer games between different hardware platforms using different operating systems and communication protocols. To describe a player in a multiplayer computer game, the terms "client," "user," and "player" are used interchangeably here. The term "multiplayer game" as used herein refers to, for example, a sport simulation game, such as basketball, baseball, football, hockey, motorcross, wrestling, car racing, skiing, and virtually between at least two players. Competition, high-speed twitch games, such as first-person shooting games, alternate-based games in which two players take turns playing games, such as chess, card games, checkers, etc., as well as hundreds or thousands of players. Includes, but is not limited to, large-scale multiplayer games in which the game is played at the same time.

【0014】

The present invention provides special purpose software that may operate in connection with the processor of a client computing unit to form a multiplayer computer game. This special purpose software provides an interface between application modules that provide functionality for a particular multiplayer computer game and client computing device operating systems and hardware devices and protocols. For example, the application module provides functions for racing games, sports games, and the like. This application module communicates with the cross-platform core that handles all communication between the application module and the computing hardware, operating system and required protocols (ie bidirectional data exchange). Therefore, according to the present invention, different application modules are written to provide different multiplayer game functions, and each of the different application modules is used in connection with the same cross-platform core to form various multiplayer computer games. To do.

【0015】

The present invention also provides a system that facilitates the play of multiplayer games among a plurality of players, regardless of the different hardware platforms used by the various players (ie different client computing units). Each client computer runs the same multiplayer application module (or code), and each client computer has a cross-platform core. Also, each client computing device communicates with a server having special purpose software to facilitate the play of multiplayer games among various players. This server provides various functions that improve and / or supplement the functions given to the client computer, and generally network such as modem-modem or direct link (eg, Internet, intranet (LAN,). Manage and facilitate the play of multiplayer games via WAN) or other networks).

【0016】

According to various embodiments of the present invention, multiplayer gameplay between multiple players is now possible regardless of the hardware platform, communication protocol and operating system of each player's computing device. Therefore, according to the present invention, players having different hardware and software configurations in each computing device and communicating using various communication protocols can participate in the play of a multiplayer game with each other.

【0017】

According to the present invention, novel application modules that use the cross-platform core of the present invention and other basic technologies (eg, communication engine, client / server architecture) to simplify and speed up software development. Will be developed. Code for a particular operating system or hardware device or protocol is no longer needed. Therefore, the software development interval is significantly shortened. Moreover, the reusable cross-platform core does not require integration testing for each new application module. This is because the cross-platform core has already been tested and integrated with multiple hardware platforms, operating systems and hardware devices and protocols.

【0018】

The terms "computer", "computing device" and "computational hardware" (and variants thereof) are used interchangeably herein and are intended to be broadly interpreted. These terms do not define or limit the scope or content of the invention. A computer (client or server) includes some or all of the following elements: Processor (eg, central processing unit (CPU)), memory (eg, RAM, ROM), hard drive unit (HDU), communication interface (eg, modem, ROM) BIOS), data input devices (eg keyboards, mice, etc.), and displays. The computer also includes additional known hardware elements and devices (eg, joysticks), and the configuration of the server and client computers is not limited to the present invention. They also include general purpose software that provides the overall operation of the client or server computer, and also includes operating systems, commercially available software (eg, databases), communication software, and the like. Computers include, for example, personal computers (desktops, laptops), handheld calculators (eg, personal digital assistants (PDAs), such as Palm®, BlackBerry®), computer game consoles (eg, Sony Playstation). (Registered Trademarks) and Playstation 2, Sega Dreamcast®), cellular devices, and other currently known, upcoming computers suitable for multiplayer gameplay, including, but not limited to. ..

【0019】

The special purpose software provides the functionality of the present invention and may include one or more web native modules, library files, etc., may reside on client and / or server computers, and may use general purpose software. May be good. As will be apparent to those skilled in the art from the description herein, the programming languages (C, C ++, Java®, etc.) used to form special purpose software (ie code) are routines for design selection. It is a problem. Therefore, the present invention is not limited to specific embodiments of special purpose software defined by the programming language used to encode the software.

【0020】

Now, with particular reference to FIG. 1A-1G of the accompanying drawings, a system for playing a multiplayer computer game according to the present invention is generally indicated by reference numeral 100. The system 100 of the present invention uses a client / server architecture, which requires a client computer 200 to connect to another client computer 200 via a server 120, and a direct client-client ( That is, the player-to-player) connection is prevented (see, for example, Figure 1A-1E). Such a configuration reduces the bandwidth requirements of each player, facilitates server intervention in making decisions between players, and "supervises" all aspects of gameplay and is provided on server 120. Gives high security by restricting client access to certain data. A preferred embodiment of the client / server architecture of the present invention provides a central data center 20 with at least one server 120.

【0021】

Alternatively, the system 100 may use a peer-to-peer architecture (ie, client-to-client) in which all players (ie, clients) communicate directly with each other, as shown in FIG. 1F. In such an architecture, there is no central data center 20 or server 120, and client computers 200 can connect and communicate directly with each other. Multiplayer gaming capabilities are provided by each client computer 200, as detailed below.

【0022】

Yet another, System 100 may use a hybrid configuration between client / server and peer-to-peer architecture, as shown in Figure 1G. Communication between client computers 200 may be a combination of a peer-to-peer model in which clients communicate directly with each other and a client / server model in which clients communicate with each other only through the server. The server referee 120 monitors gameplay for fraud and takes appropriate action (eg, drops rogue connections to server 120).

【0023】

Continuing with reference to FIG. 1A, and further with reference to FIG. 2, an embodiment of the system 100 of the present invention comprises a primary data center 20, which comprises at least two substantially identical servers, each consisting of multiple computers. It has a computer 120, for example, web server 122, matchmaking server 124, resource server 126, user (client) identification server 128, chat server 180, tournament server 182, ranking server 184, ideal service finder 130. , Domain name server 132, and game server 134, but not limited to these. Alternatively, the functionality provided by these servers (discussed in detail below) may be provided on a single server 120 (or primary and backup servers 120), or to configure a small number of servers. It may be appropriately grouped. The server computer 120 is protected against unauthorized access and exposure to unauthorized data, etc. by the firewall 110 placed between each server 120 and the network 10, and software such as security algorithms in the server and operating system. Therefore, it is also referred to here as a "protected" server. This protected server 120 cannot directly access or connect to a public network such as the Internet. These servers 120 typically have sensitive information (eg, client identification and account data) stored in databases 144, 146 of data storage devices 140, 142.

【0024】

The primary data center 20 also includes a public server computer 1120 as part of the multiplayer game system 100 of the present invention. These server computers 1120 are directly connected to network 10 and accessible by client computer 200. This public server computer 1120 may have additional security as a matter of design choice given by equipment, firewalls, operating systems, server applications, routers, or other known or upcoming applications or devices. it can. For example, the web server 122 and the resource server 126 may configure the public server computer 1120.

【0025】

The protected server 120 is connected to a back-end network 150 (eg, a local area network (LAN)) built into the primary data center 20. This back-end network 150 is actually a wire-type (eg, twisted pair, coaxial, fiber, etc.) or wireless (eg, infrared, high frequency, etc.) that is local to and housed in the buildings that make up the primary data center 20. ) Is included (the primary data center 20 may consist of one or more buildings, as will be apparent to those skilled in the art from the description herein). Data storage devices 140, 142, which are provided with databases 144 and 146, respectively, are connected to the protected server 120. In a preferred embodiment, the data storage device 142 and the database 146 provided therein provide a mirror image of the data storage device 140 and the database 144, respectively. Data storage devices 140, 142 and databases 144, 146 are described in detail below. One or more backup server computers (2120) are provided in the backup data center 30, which is connected to the back-end network 150 of the primary data center 20 via a private virtual connection (PVC) 40 and a firewall 110.

【0026】

The connection between the primary data center 20 and the network 10 is made via a primary connection 60 and a secondary connection 62 provided by an Internet service provider (ISP). Both the primary and secondary connections 60 and 62 may be a wire connection or a wireless connection as a routine design selection problem. Further, referring to FIG. 1A, yet another server computer may be connected to network 10 to provide some functionality of multiplayer gameplay according to the invention. For example, the public server 1320 is located away from the primary data center 20, but may be geographically close to the client (eg, client A). While playing the game, it is more efficient to give client A some functionality from the public server 1320 instead of from the primary data center 20. The present invention makes this condition possible and easy. In addition, the fraud server 1220 can be connected to network 10 and provide some functionality to the client computer 200 during gameplay as well.

【0027】

Each client computer 200 in the system 100 of the present invention is installed with special purpose software that may operate in relation to the processor of that computer. This special purpose software facilitates multiplayer gameplay between client computers 200, regardless of the hardware platform, operating system, and hardware and communication protocols of each client computer 200. Based on the network configuration (see, eg, Figure 1A-1G), communication between the client computer 200 and the server 120, or direct communication between the client computer 200, is provided by this special purpose software on the client computer 200. Be made easy. Special purpose software installed on server 120 and capable of operating in connection with its processor facilitates and aligns the play of multiplayer games between client computers 200. The functions provided by each of the server 120 and the client computer 200 depend on the network configuration. For example, as shown in FIG. 1D, the server 120 may simply pass all client data and provide all functionality to each client computer 200. Alternatively, as shown in FIG. 1E, the function may be allocated between the server and the client computer (20/80 in this embodiment). Further, in the configuration of FIG. 1F, each client computer 200 is given full functionality.

【0028】

Next, the protected server computer 120 of the primary data center 20 will be described in detail with reference to FIG. As mentioned above, server 120 comprises one or more computers, which are, for example, web server 122, matchmaking server 124, resource server 126, user (client) identification server 128, chat server 180, tournament. Includes, but is not limited to, Server 182, Ranking Server 184, Ideal Service Finder 130, Domain Name Server 132, and Game Server 134. Alternatively, some of these servers are provided as unprotected servers (eg, 1120 in Figure 1A), for example, based on the capabilities of that particular server and the importance of the data stored on the server. May be good. Which server is provided as a protected server and which is provided as an unprotected server is a routine design choice. Each server shown in FIG. 2 may be connected to network 10 via a separate switch 136, or multiple servers may share a single switch 136. The connection shown in FIG. 2 merely illustrates one of the many different connection schemes obtained between the server and network 10, and should not be construed as limiting the scope of the invention.

【0029】

The functionality provided by the various servers shown in FIG. 2 facilitates and manages the play of multiplayer games individually and / or collectively by a plurality of client computers 200, based on the present invention. As detailed below, either server (and its respective function) is used by the system 100 at a particular time and accessed by the client computer 200, based on the particular game activity. For example, the matchmaking server 124 and its features are utilized when a player (ie, client computer 200) first attempts to connect to server 120 and then participates in playing a multiplayer game. However, once the player establishes a connection to the game server 134, the matchmaking server 124 and its functionality are no longer needed. Similarly, other servers in the server cluster 120 can be used by the client computer 200 at different times and in different ways while playing a multiplayer game.

【0030】

The multiplayer functionality provided by the various servers 120 and each client computer 200 based on embodiments of the present invention is generally provided by special purpose software that may be installed on each computer and operate in relation to the processor. In some cases, this is also provided by general purpose software that can be installed on each computer and operate in relation to each processor. Based on the multiplayer function requirements of a particular multiplayer game and the configuration of system 100 (eg, client / server, client / client, etc.), both server 120 and client computer 200 are given the same or similar functionality. You may. At a minimum, the functionality provided to the client computer 200 is a subset of the functionality provided to the server 120. This relationship is outlined in Figure 3, which shows the capabilities of the client computer, the capabilities of the server, and the interrelationships between them. FIG. 3 shows a single client computer 200 for a single server 120, but many client computers 200 with the same or similar functionality provide the functionality of the server 120, as shown in FIG. Note that you may "map".

【0031】

Further, with reference to FIG. 3, the functions provided to the client computer 200 by the special purpose software based on the embodiment of the present invention will be described in detail below. As will be apparent to those skilled in the art, special purpose software may be provided on currently known or upcoming storage media (eg, CD-ROMs, DVDs, etc.) as a routine matter in design selection. It may be downloaded in whole or in part to the client computer 200 (included in the ROM or cartridge), or it may be otherwise loaded into the memory of the client computer 200. This feature includes multiple elements including Name Service 202, Gaming 204, Lobby 206 (including Matchmaker 208 and Chat 210 elements), Tournament 212, Ranking System 214, User Registration 216, and Resource Up / Down 218. Given by the element. Each element provides a function for facilitating communication between the client computer 200 and the various functions provided by the server 120.

【0032】

In the embodiment shown in FIG. 3, each function provided by the special purpose software of the client computer 200 has a corresponding complementary function in the server 120. The connection between the client computer 200 and the server 120 shown in Figure 3 is functional, but based on the functionality required at a particular point during game play, even if not all exist at the same time. Good. For example, the ideal service finder 130 and the name service element 202 identify various resources and other functions not provided by the special purpose software of the client computer 200 through the symbolic names given to the database of the ideal service finder 130. And give the function to explore. For example, the game server 134 is provided as part of the primary data center 20 as well as as part of the public server 1320. During game play, the client computer 200 is information from the game server 134 and its player from the game server 134 located on the public server 1320, which is geographically closer to the player than the game server 134 in the primary data center 20. Need information that can be given to. The function of the ideal service finder facilitates the location of its nearby game server 134. The use of symbolic names by the features of the Ideal Service Finder eliminates the need to hard code the network location of the game server and thus allows the movement of the network location of the desired resource or feature. System 100 may have more than one ideal service finder 130 (ie, both the primary data center 20 and the public server 1320 may have ideal service finder 130). If two or more ideal service finder 130s are provided, a database of symbolic names is copied to all ideal service finder 130s in system 100.

【0033】

Further, referring to FIG. 3, the game server 134 and the gaming element 204 provide a gaming function, which includes providing an in-game library, facilitating game data communication between players during gameplay. .. The game server 134 provides a function for facilitating communication between the client computers 200 by the server 120. The game server 134 stores game state and synchronization information and game management responsibilities (between various client computers 200 and various servers including server 120). The corresponding gaming element 204 facilitates the connection between the client computer 200 and the game server 134 (client / server architecture) or the connection between the client computers 200 (peer-to-peer architecture).

【0034】

The elements of match make server 124 and match maker 208 are that the player searches network 10 for a game server 134 that satisfies the player-defined requirements (eg, game name, number of players, rules, ping time). Gives a matchmaking feature that allows you to do it. Match-make server 124 has a database of game servers 134 located within network 10, which contains specifications for each game server 134 (eg, game format, number of concurrent players, etc.). Is preferable. System 100 may be provided with two or more matchmaking servers 124.

【0035】

Next, the functions of the matchmaking server 124 will be described in detail with reference to FIGS. 8A-8C. The match-make server 124 stores in its database a list of game servers 134 for one or more multiplayer games, such as game X, game Y, and so on. When the client computer 200 requests a game server for the game X via the match make element 208, the match make server 124 can return the available game X game server 134 to the client computer 200. When that information is returned from the matchmaking server 124 to the client computer 200, the client computer 200 can connect to and participate in playing multiplayer games on any of Game X's game servers 134. Similarly, the match-make server 124 can direct the client computer 200 to the game server 134 of game Y. For example, when the client computer 200 intends to participate in the game Y, the request is communicated to the match make server 124 by the match make element 208 resident in the client computer 200 (indicated by 1 in the figure). The match-make server 124 determines which Game Y servers 134 are available to the client computer and communicates a list of these servers to the client computer 200 (indicated by 2 in the figure). The choice of Game Y server 134 to which the client computer 200 ultimately connects is left to the user of the client computer 200. In Figure 8A, the client computer is selected to connect to the game server Syl (indicated by 3 in the figure).

【0036】

Alternatively, as shown in FIG. 8B, the match-make server 124 can return the game server 134 of the particular game X to the client computer 200, and then the client server 200 connects to this and of the game X. You can participate in the play of multiplayer games. In FIG. 8B, the client computer communicates a request for Game X's list of servers 134 to game server 124 (via matchmaking element 208) (indicated by 1 in the figure). The game server 124 returns information about the game server Sx2 to the client computer 200 (indicated by 2 in the figure). The client computer 200 then establishes a connection to the game server Sx2 (indicated by 3 in the figure).

【0037】

In another embodiment shown in FIG. 8C, the plurality of matchmaking servers 124 each store a list of game servers 134 for one or more multiplayer games, such as game X, game Y, game Z, and so on. To. This configuration provides high reliability and load balance among multiple matchmaking servers 124. If one matchmaking server 124 is having problems or is flooded with requests from multiple client computers 200, another matchmaking server 124 can provide matchmaking functionality. Requests from client computer A to the Game X server are handled by Match Make Servers 1 (MM1) or 2 (MM2), both of which have information about the Game X server. Similarly, Match Make Servers 2 (MM2) and 3 (M3) can handle requests for Game Y's server.

【0038】

In each of the above embodiments of the match-make server 124 (shown in FIGS. 8A-8C), a request from the client computer 200 to search for the game server 134 is desired by some of the game server 134 and the client computer 200. Includes performance characteristics and connections between them. For example, the client makes a request to the matchmaking server 124 for the game name, number of players, rules, world in which the game is played, and ping time (eg, best performance, minimum latency, random selection, etc.). Submit such criteria.

【0039】

The chat server 180 and chat element 210 provide chat functionality that allows players to communicate (usually via text messages) over network 10, i.e. send and receive instant messages, chat room messages, group messages, etc. Gives the ability to. The chat server can receive text messages from the chat element 210 of the first client computer 200 (eg, client A). Included in the message is the identification of the desired recipient (eg, client B, client C, etc.). The chat server 180 receives the message, interprets the recipient, and sends the message to be received by the chat element 210 of the client computer 200 of the desired recipient.

【0040】

Tournament server 182 and tournament element 212 provide tournament functionality that facilitates tournament gameplay across multiple client computers 200. Tournament Server 182 provides a place for registered clients to demonstrate their game competence by participating in game tournaments, and this server is a player based on competence demonstrated by its success over other players. Eliminate or rank. The ranking server 184 and the ranking system element 214 provide a ranking function for tracking individual and / or group player statistical information, comparing players, ranking players, and so on.

【0041】

User (client) identification server 128 and user registration element 216 register players, specify a unique player identifier for each player, define a player profile for each player, and player access to game services via system 100. Provides user identification and registration functions that allow or deny. The user (client) identification server 128 communicates directly with the data storage device 140 and the database 144 provided in the primary data center 20. The new client must first be registered and the registration is stored by the user identification server 128.

【0042】

The resource server 126 and the resource up / download element 218 provide a resource function that allows the client to upload and download game resources from another server to the client computer 200 during gameplay. For example, clients can download new game graphics, updated sports statistics, post-production ads, and client customization data (eg, racetracks, player representatives, etc.). The client can also upload client customization data (eg, from the client computer to the resource server 126). The resource server 126 is located in the primary data center 20 and acts as a master resource server, and preferably contains complete data about the location of all available resources in network 10 (eg, all other public servers). 1320, fraudulent server 1220, and other unprotected servers 1120).

【0043】

The server 120 (or one or more of the above servers that make up the server 120) also forms a companion list manager that can operate in connection with the user (client) identification server 128. For example, the client computer 200 can start a particular multiplayer game with appropriate restriction instructions that only its client's peers (given by the peer list manager) can participate in the game. An ideal service finder that allows the client to search for the service that best suits the client's particular request is also formed by the server 120 (or by one or more of the above servers). For example, a client can search for the best service on the Internet (ie, network 10) without experiencing IP-related address issues. The Ideal Service Finder maintains data about registered services (ie, services that the Ideal Service Finder notices) (eg, performance, location feedback, etc.) and uses that data to provide the ideal service for a particular client request. Select.

【0044】

Then, referring to FIGS. 4A and 4B, the special purpose software that may operate in connection with the processor of the client computer 200 based on the embodiment of the present invention is a cross-platform core (CPC) 320, which is a collection of modules. Used, this allows programmers to develop similar programs (ie games) that can run on a large number of hardware and operating system platforms with minimal development overhead. For example, CPC320 provides a cross-platform compatible with Windows95, 98, NT, Win2000, WindowsCE, Linux, Solaris operating systems, and various hardware platforms and gaming consoles. The CPC320 of the present invention is a multiplayer computer game (or actually other software) installed to run on a first hardware platform in connection with a first operating system, but in connection with a second operating system. Allows seamless communication with multiplayer computer games (most often the same multiplayer computer games) installed to work on a second hardware platform. CPC320 provides cross-platform communication that allows game algorithms and programs to operate on different hardware platforms regardless of operating system, system application programmer interface (API), memory, file system, thread, time, etc. .. Therefore, player A in New Jersey running a multiplayer game using the invention installed on a personal computer resides in California with the same multiplayer game installed on Sega Dreamcast®. Can be played against player B of.

【0045】

Also, the special purpose software facilitates communication (ie, bidirectional data transfer) between the application module or code 302 and the operating system 310 of the client computer 200, the hardware device 312 and the communication protocol 314 (ie, bidirectional data transfer). comm) It also has an engine 402. This communication engine 600 (also known as the comm engine API) provides standard functions for communication between several hardware devices, such as data selection, initialization, connection and transmission / reception to the device. A cross-platform library. The communication engine 600 includes a service layer 410 and an equipment layer 450. The CPC320 and Communication Engine 600 provide the communication basis for developing software applications, provide hardware, software and protocol independence, and provide the features of customizable software algorithms. The CPC320 eliminates the need for software programmers to think about communication details (ie, protocols) when writing multiplayer computer games.

【0046】

The CPC320 identifies the hardware platform and operating system of the computer, provides a cross-platform ANSI C library, a cross-platform hardware emulation layer (HEL), and provides release and debug options. The CPC ANSI C library contains main system files such as hardware platform target and storage format files, ANSI C compatibility layer files, and advanced hardware construction layer (HAL) files. These files then contain various subelements of CPC320, as detailed below. The various subelements can be called individually or via their group files or the complete list of files. The platform target and storage format file contains all the definitions and constants needed to determine platform-specific features and cross-platform format standards.

【0047】

The ANSI C compatibility layer file contains definitions for ANSI C compatibility features. ANSI compatibility layer files provide the functionality found in the ANSI C library. This includes, but is not limited to, standard features such as memory, strings and math. ANSI C compatibility layer files provide these characteristics without operating system deviations. For example, ANSI C defines a standard method for performing time functions, but some operating systems use a variant of that standard. Therefore, it is difficult to develop a time function that can be transported across a large number of operating systems. ANSI C compatibility layer files eliminate this problem by providing an ANSI equivalent interface for accessing time features in any operating system. In addition, some operating systems do not provide the entire ANSI C library. In this case, the ANSI C compatibility layer file of the present invention provides a missing function.

【0048】

Advanced HAL files contain features that are not included as part of the ANSI C standard. This includes the ability to define what operating system is running, threads that are standard enough but not available or inconsistent across all platforms, debugging and other important features. For example, new C ++ delete features can be defined in these files.

【0049】

Then, with reference to FIGS. 4A and 4B, the elements and architecture of the special purpose software of the present invention will be described in detail below. The multiplayer game constructed according to the present invention has the architecture generally shown in FIG. 4A and generally shown by reference number 300. The game 300 includes application elements or modules 302 that include application software specific to the game format (eg, sports, high speed twitch, alternation base, etc.). This application module 302 directly interfaces with core technologies, including a comm engine 600 located at the top of the cross-platform core (CPC) 320. The CPC320 is a collection of files (ie, modules) that allow programmers to develop similar programs (eg, multiplayer computer games) that run on many hardware and operating system platforms with minimal software development overhead. )including. CPC320 provides cross-platform compatibility with Windows95, 98, NT, Win2000, WindowsCE, Linux, Unix®, Solaris and various gaming consoles. Therefore, multiplayer computer games can be developed quickly and easily to operate in connection with any hardware and software platform and configuration, and to communicate with other hardware and software platforms and configurations. it can.

【0050】

The communication engine 600 provides an interface between the application module 302 and the operating system 310 as well as various hardware devices 312 and communication protocols 314 specific to each communication device hardware platform. When writing the application module 302, the software developer does not need code for a particular operating system, nor does it need to consider the hardware or protocol requirements of a particular hardware platform. Rather, the application module 302 is written (ie, coded) to interface to the communication engine 600, runs on any operating system, and uses the hardware equipment and communication protocols supported by the communication engine 600. Can be done. The Communication Engine 600 is a general purpose cross-platform communication engine that makes programming network applications faster, easier, more efficient and more robust. This provides the technical basis for multiplayer games and web-based applications. Communication Engine 600 meets the needs of cross-platform, and operating systems such as Microsoft Windows95, 98, 2000, NT, and CE, Linux, Solaris, SGI, Personal Digital Assistant (PDA) operating system, and wireless operating. It can support the system, but is not limited to these. As will be apparent to those skilled in the art from the above description, other currently known or upcoming operating systems can also be supported by the communication engine 600.

【0051】

Communication engine 600 includes communication engine API 402, which includes main module 404, message (msg) module 406, external api (ex_api) module 408, error (err) module 412, and service protocol (svc prot) module 414. Including. Message module 406 provides application 302 with a general way for clients to send data through the communication engine infrastructure without having to worry about memory allocation and speed issues. The error module 412 is used by the communication engine 600 as a method of notifying the client that an error has occurred in the communication engine 600. With a wide range of errors, helper functionality is provided to extend the functionality of error module 412. These helpers are a textual display of the error. The service protocol module 414 extends the functionality of the communication engine 600 by providing clients with commonly used services such as compression and encryption.

【0052】

The communication engine 600 interfaces with service layer 410, which includes channel manager (chan mgr) 416, session manager (sess mgr) 418, and message queue manager (msg queue mgr) 452. Channel manager 416 manages the channel list for the session. The session manager 418 drives the channel manager 416 by performing an operation on the channel list. Tasks that need to be performed through the equipment layer channel are processed through the channel manager 416. One example is sending a message through device layer 450. Each channel contains transmit and receive queues, device protocols, device information, address information, software protocol stack and configuration information.

【0053】

Service layer 410 shields application module 302, hardware equipment and communication protocol requirements for a particular operating system (OS). The programmer only needs the code for service layer 410 (via the communication engine 600), which service layer is all that is needed for application module 302 to interface with the operating system and various devices and protocols. Perform the conversion of. The service layer 410 also provides access to advanced engine protocols through application module 302 and allows software developers to easily insert custom application protocols.

【0054】

The service layer 410 is generally considered a hardware emulation layer (HEL) because it transfers hardware execution calls to the equipment layer 450, and provides hardware features / emulations. The service layer 410 can also supply any internal protocol that can be used by the application module 302, if desired. The service layer 410 also allows the application module 302 to supply its own protocol, which can be inserted at different points in the service layer protocol stack 420, an example of which is shown in FIG. There is. This protocol stack 420 includes upper layer protocol features such as compression 422, encryption 424, keepalive 426 and stream support 428, as well as advanced routing technology 430, error correction 434, buffering 436, guaranteed messages 438, virtual. Includes ISP440 and lower layer protocol features including insert noise / debug 442.

【0055】

The protocol stack 420 allows you to use transmit priorities to optimize bandwidth, optimize protocol buffer management, and save CPU usage. In essence, this allows outgoing packets to be combined into a single outgoing packet, if possible. Each incoming and outgoing packet must be packed and processed, resulting in a CPU context switch, hardware transmission execution, and so on. In the absence of optimization, high packet counts result in significant local overhead and latency. Transmission priorities can be optimized based on the particular communication medium used by application module 302. When accessing the Internet using a relatively slow connection (eg a 28.8K modem), the latency is longer than 200 milliseconds (ms). Based on this knowledge, ordinary priority packets are grouped in a predetermined time window. For example, a pending packet that is not yet time to send is flushed and sent if a high priority packet is about to be sent. The expiration time window for each transmit priority is configured so that the transmit priority can be mapped to transmit within the next predetermined time window.

【0056】

The buffering 436 protocol of the service layer protocol stack 420 can take into account unnecessary memory allocation, freeing, copying, and so on. In addition, the internal receive buffer is directly reviewed, used, and copied. Some examples of optimal packet manipulation operations are the ability to add / remove headers / footers to data packets with a high probability of no memory allocation / release / copy. A dynamic protocol buffer pool is also provided, which includes pre-allocated and previously configured protocol buffers for use as needed.

【0057】

Virtual ISP protocol 440 provides all the necessary hooks for simulating application performance over the Internet. Virtual ISP Protocol 440 can test Application Module 302 using a LAN (in terms of Application Modules) configured as an Internet ISP connection. Virtual ISP protocol 440 allows service layer 410 to simulate the following situations: Random defects in connections, random loss of connections, random latency injections with variance, and random loss of packets. The Virtual ISP Protocol 440 option can be fully configured to provide multiple types of ISP connections across different media. For example, both tire 1 and tire 3 internet connections can be simulated. Fast or slow connections and device behavior, such as disconnected packet drops, can also be simulated using the virtual ISP protocol 440. Another effect of Virtual ISP Protocol 440 is security. It is no longer necessary to connect to the internet to see how communication software behaves.

【0058】

The equipment layer 450 is a low-level, cross-platform, equipment independent layer of the communication engine 600. It deals with operating system-specific API calls, platform-specific issues with byte ordering and data alignment, and device-specific programming techniques that provide a common API for all platforms. Instrument layer 450 provides an integrated interface to different communication devices on all operating systems, i.e. facilitating the addition of new devices by adding new device APIs for direct and immediate function performance. Hiding operating system-specific details from the software engineer, hiding device-specific form or structure details from the software engineer, hiding device-specific API details from the software engineer, and using it as a direct API to the device. Yes (for example, the device layer maps a general "SEND ()" command to a specific "DevApi_Send ()" command), and regardless of the intended operating system, platform, network protocol, etc., application module 302 Gives a common interface to be involved in when it works.

【0059】

Equipment layer 450 hides implementation details for different network protocols, operating systems and communications equipment. Thus, programming a modem on a Linux OS using the dial-in mechanism programs the exact same thing as a Windows machine from a higher level using a network interface card (NIC) and TCP / IP protocol. From the point of view of application module 302, the same sequence of subroutine calls is used, and only the address parameters are different. In addition, helper subroutines can be used to create different address formats so that the actual implementation of the address is hidden from the user.

【0060】

Equipment layer 450 provides any operating system with an integrated interface to all hardware equipment and protocols. Instrument layer 450 comprises code that is specific to all hardware platforms, including arbitrary code that handles different hardware, protocol implementations, and different operating systems. Therefore, support for the communication engine 600 for new operating systems, network devices or protocols can be provided by adding support for it only at device layer 450. The equipment layer 450 is considered the hardware abstraction layer (HAL) and provides interfaces between the application module 302 (via the service layer 410) and various equipment (ie, hardware platforms), operating systems and network protocols. Includes code for.

【0061】

The communication engine 600 generally has three modes of use: pass-through mode, synchronous mode and asynchronous mode. Each mode uses the functions of the communication engine 600 in different ways. How these modes and the use of the functions of the communication engine 600 are required will be described with reference to FIGS. 6 and 7. In the pass-through mode shown in FIG. 6, the communication engine 600 acts as an interface to the function of the equipment layer 450. An additional feature of the pass-through mode is the ability to set a data filter through which data passes before communicating via network 10 (which has a corresponding filter on the receiving side). For example, the data can be compressed and / or encrypted before transmission and then decrypted and decompressed upon reception.

【0062】

For pass-through mode operation, application module 302 creates a session and forms and opens a channel in that session. The connection, if applicable, is accepted, and data is sent directly back and forth between equipment layer 450 and application module 302 via the communication engine 600 without the need to buffer or queue the data in any way. Ru. In essence, pass-through mode expects the application module 302 to be familiar with network programs and simply use the communication engine 600 to hide device, protocol and operating system details.

【0063】

The data flow for synchronous and asynchronous mode operation of the communication engine 600 is shown in FIG. In asynchronous or synchronous mode, the communication engine 600 buffers data, provides data filtering services, and queues messages for application module 302. Further, an event driving method may be used in which the user of the library (ie, application module 302) is notified of events such as new connections, channel disconnections, etc. when new data is received.

【0064】

In the synchronous mode shown in FIG. 7, the application module 302 controls when the communication engine 600 performs its function. This differs from pass-through mode in that message queues and notification methods can be used, and therefore event-driven methods can be used when programming application module 302. However, the communication engine 600 must be frequently and explicitly allowed to perform its function by calling subroutines that allow it to perform synchronous operations and functions, such as CommEng_DoSynchronousWork (detailed below). The term "subroutine" as used herein includes subroutines, callbacks, functions, etc., and here the application program (or its associated application program) calls another application with its additional functionality. It refers to the case where additional functions are given to / for the application program by executing, executing, causing to execute, and so on. A subroutine performs a function on an application program, receives data from the application program (or another application program, subroutine, library, etc.) and passes the data through it, and is directed by the application program to another subroutine. Etc. can be called. The subroutine names given herein are merely examples and examples of names used to facilitate the description of the present invention, and are not limited thereto, and do not limit the scope of the present invention in any way. It will be apparent to those skilled in the art that any subroutine name may be used. The functions of the various subroutines are described in detail below.

【0065】

Synchronous mode is useful for incorporating the benefits of priority message queues and event-driven programming paradigms. In synchronous mode, no threads are used in the underlying network code, and the communication engine 600 processes the data only when the application module 302 calls a subroutine such as CommEng_DoSynchronousWork. In addition, the application module 302 can take advantage of a number of protocol services (encryption, compression, streaming, etc.) without having code specific to its function.

【0066】

In the asynchronous mode commonly shown in FIG. 7, the communication engine 600 runs using threads and allows the programmer (ie, application module 302) to be notified when an event occurs asynchronously. For example, when a new connection occurs, the application module 302 is notified by an appropriate notification method. When data is available on the communication channel, application module 302 is notified that data is also available, thus eliminating the need for application module 302 to poll for events, and application module 302 communicating. It is prevented from allowing the engine 600 to operate periodically.

【0067】

Asynchronous mode is similar to synchronous mode, except that the communication engine library does not need to call the CommEng_DoSynchronousWork subroutine or form a thread to handle the asynchronous execution of network communication. When application module 302 sends data, the CommEng_Send subroutine is called, resulting in the message get being placed on the appropriate send queue. The send queue is finally processed (when the CommEng_DoSynchronousWork subroutine is called or an internal thread does it), and each message is passed to the ChanMan_ProcessSend subroutine, which then passes it on the appropriate channel. Route to the protocol stack or directly to equipment layer 450.

【0068】

The functionality provided by the communication engine 600 is at least partially provided by the subroutine called by the communication engine 600. These various subroutines allow the communication engine 600 to operate in pass-through mode, synchronous mode, or asynchronous mode, as required by application module 302. These subroutines also shield the application module 302 from specific hardware, operating system and protocol requirements of the specific computing device. Therefore, the communication engine 600, service layer 410, device layer 450, and various communication engine subroutines facilitate the rapid and economical development of multiplayer computer games, and differences in computing device hardware, operating system or protocol. Regardless, it facilitates and manages communication between players in the arithmetic unit and provides seamless performance between game players over the network. The following description and names for the subroutine of the communication engine 600 are merely examples for facilitating the understanding of the present invention, and are not limited thereto.

【0069】

CommEng_Startup This subroutine causes application module 302 to initialize the required libraries. If the implementation is a static library, this subroutine is called only once by application module 302 to allocate and initialize the overall library resources. If the implementation is a shared library (.so) or a dynamic link library (.DLL), each can be executed using the communication engine 600 (given as part of application module 302, (Or used thereby or in connection with it), call the CommEng_Startup subroutine before accessing other subroutines. This means that the library of the communication engine 600 will be properly initialized for performance and memory management reasons. The communication engine 600 keeps a reference count of the current user of the communication engine 600, and thus knows when it can unload from memory and perform other cleanup tasks on its own.

【0070】

CommEng_Shutdown This subroutine is called when the communication engine 600 no longer needs an executable file or software module 302 that uses its API. Calling this subroutine decrements the library reference count and deallocates unnecessary resources back to the system as appropriate (ie, to be used by the hardware and software of the arithmetic unit). .. The term "system" as used herein generally refers to arithmetic units and general purpose and special purpose software.

【0071】

CommEng_OpenSession This subroutine is called by application module 302 to create and initialize a session. Sessions can be opened in three ways. For pass-through operations, the eCommSession_PassThrough subroutine is read so that the service layer 410 does minimal processing on the data and simply passes the data straight to the device layer 450. For synchronous operation, the eCommSession_Sync subroutine is called, which is recommended for non-threaded platforms. This subroutine allows the service layer 410 to act as if threads were available to the system. When an eCommSession_Sync session is opened, application module 302 (or any other application that has established the session) is responsible for timely ticking service layer 410.

【0072】

For asynchronous operation, the eCommSession_Async subroutine is called, which gives the most efficient and fastest way to open a session. Application module 302 is notified of errors or data that occur via a callback subroutine. If synchronous or asynchronous mode with notifications is required, the pNotifyMethodData parameter must point to a structure that gives notification details. CommEng_CloseSession This subroutine is called to destroy and clean up an existing session. CommEng_GetDeviceCount This subroutine returns the number of communication devices in the system.

【0073】

CommEng_GetCommDevice This subroutine is called to retrieve the list of COMM_DEVICE_IDs (ie communication devices) and / or the count of detected devices, which other APIs use to determine further information about each device ID. can do. When called with a NULL pointer to pCommDevice, the number of retrieved items is returned. Application module 302 preferably allocates (sizeof (COMM_DEVICE_ID) * number of devices) bytes and passes that buffer through this subroutine in the next call.

【0074】

CommEng_GetDeviceCaps This subroutine returns the capabilities of the device specified by the DeviceID. This subroutine can be used to determine which device to use based on its form and capabilities. CommEng_GetDeviceType This is a helper subroutine that returns the format of the device specified by the DeviceID. CommEng_GetProtocolCount This subroutine returns the number of communication protocols registered in the system.

【0075】

CommEng_GetCommProtocols This subroutine is similar to the CommEng_GetCommDevice subroutine, except that it returns the communication protocol on behalf of the communication device. When called with a null pointer to pCommProtocol, the number of registered protocols is returned. (sizeof (COMM_PROTOCOL_ID) * number of protocols) Byte allocation is buffered and passed to this subroutine on the next call. The caller can then search for the capabilities of each protocol. Note that it is more efficient to call CommEng_GetProtocolCount with a null pointer to the first parameter instead of this subroutine.

【0076】

CommEng_GetProtocolID This subroutine is called to get a pointer to COMM_PROTOCOL_ID given the calculated value of the communication protocol. CommEng_GetProtocolCaps This subroutine searches the capability structure of a communication protocol, which is used to determine the specified protocol capability. CommEng_CreateChannel This subroutine is called to allocate a channel. If a configuration structure is supplied, it will be used to configure the channel. Otherwise, the channel can be configured as needed before or after opening.

【0077】

CommEng_OpenChannel This subroutine is called to open a channel for sending and / or receiving data, as shown in Table 1.<img file="JP2004514189A_D0001.tif" /> 【0078】

CommEng_CloseChannel This subroutine is called to close an open channel. It can be opened as needed. Note that this subroutine does not unallocate all resources assigned to an existing channel (CommEng_DestroyChannel described below, which we do below). CommEng_DestroyChannel This subroutine is called to unassign a channel. If necessary, close the channel before destroying it.

【0079】

CommEng_SetChannelConfig This subroutine is called to configure channel attributes and software protocol stacks as needed, as shown in Table 2 below.<img file="JP2004514189A_D0002.tif" /> 【0080】

CommEng_GetChannelConfig This subroutine is called to find the attributes of the channel configuration, as shown in Table 3 below.<img file="JP2004514189A_D0003.tif" /> 【0081】

CommEng_PeekMsg This subroutine allows the user (ie, application module 302 or communication engine API 402) to search for the next message in the queue. The ppMsg parameter is packed with pointers to internal message buffers in the communication engine 600, treated as read-only, and used for peaking only. The CommEng_RecvMsg (described below) subroutine is called to retrieve a message from the buffer. If ppMsg is NULL, the message pointer is not filled. This subroutine simply returns the code that tells you if there is data. If there is a message, CommEng_PeekMsg sets pbData to a nonzero value. If there is no message, the value pointed to by pbData is set to zero.

【0082】

CommEng_RecvMsg This subroutine is called to retrieve a message from the message queue. When this is called, the pointer ppMsg is filled with pointers to the appropriate message data structure. Message helper subroutines (ie message crackers) can be called to extract the appropriate data from each message format. The caller must unassign the message by calling CommEng_FreeMsg at the end.

【0083】

CommEng_Send This subroutine is called to send data and is defined in Table 4 below. If queue buffering is not enabled for the associated session (ie, in passthrough mode), a message is simply sent (after being arbitrarily processed by the data filter in the channel's protocol stack). Otherwise, the data is placed in the appropriate send queue and processed at the appropriate time. Once the message is processed, it is sent through the channel's software protocol stack and finally to instrument layer 450. First, in pass-through mode, if the channel is configured to use the protocol stack, the COMM_MSG structure is assigned, and then the data is filtered through the data filter protocol of the protocol stack.<img file="JP2004514189A_D0004.tif" /> 【0084】

CommEng_SendMsg This subroutine can be used to send an existing message. This subroutine is useful when the user wants to send a custom message format or when the received message should be echoed or forwarded. CommEng_Peek This subroutine is a pass-through subroutine to the COMM_Peek API in the device layer, as shown in Table 5 below. However, it is not always possible for CommEng_Peek to detect this if the channel is closed from the remote end. Sometimes this subroutine successfully returns the existence of the data, but the data is that the channel was closed at the remote location. Therefore, a transmit or receive operation on a channel causes a disconnect to be detected.<img file="JP2004514189A_D0005.tif" /> 【0085】

CommEng_Recv This subroutine is called to receive data directly over the channel, as shown in Table 6 below. This blocks until there is data to be received or time runs out (per channel configuration), so the caller must handle the possibility of not returning immediately. If the receiving channel (ie, Channel ID) is composed of a protocol stack, the data is processed through the protocol stack before being returned to the caller. Unless the API is used as a pass-through to the equipment layer, the caller must use CommEng_RecvMsg to retrieve data and messages asynchronously. Note that the user must unallocate the returned data buffer. This is because this subroutine allocates data and returns a pointer to that data.

【0086】<img file="JP2004514189A_D0006.tif" /> 【0087】

CommEng_AcceptConnection Calling this subroutine allows the channel to wait for a connection. It should only be used with connection-oriented protocols in pass-through mode. CommEng_DoSynchronousWork When in synchronous mode, the user must call this subroutine to allow the communication engine 600 to perform its task. The user must ensure that this subroutine is called frequently enough to handle the amount of data that needs to be sent and / or received. CommEng_AllocMsg This subroutine assigns messages based on input parameters, as shown in Table 7 below.<img file="JP2004514189A_D0007.tif" /> 【0088】

CommEng_FreeMsg This subroutine frees the message structure specified by the pointer (that is, returns it to the internal Msg pool). CommEng_IsError This subroutine returns nonzero if eErrorCode is an error, otherwise it returns zero. In addition, if the eErrorCode is an error, in debug mode, print out the textual description of the error message and the szFunctionName parameter so that the debug output contains the name of the subroutine that detected the error.

【0089】

CommEng_IsProtocolSupported This subroutine returns nonzero if the specified device (DeviceID) supports the device protocol specified by the ProtocolID. The module interface function of Channel Manager 416 and related subroutines are described in detail below. ChanMan_CreateChannel This subroutine forms a channel structure and initializes it appropriately based on the specified flags. In addition, the channel is added to the channel list for the appropriate session. This is called by the CommEng_CreateChannel API subroutine to actually generate the channel structure as channel manager 416 hides the implementation.

【0090】

ChanMan_OpenChannel This subroutine actually opens a channel. A channel must be opened before it can be used to send or receive data. This is called by the CommEng_OpenChannel API subroutine. ChanMan_InitChannelFromID This subroutine initializes the channel of the communication engine 600 based on the device layer channel ID and address information.

【0091】

ChanMan_CloseChannel This subroutine is called to close the channel. Note that the resource is not deallocated and the channel is put into inactive mode. This is either called internally when the channel is connotatively closed, or CommEng_CloseChannel Called via an API subroutine. ChanMan_DestroyChannel This subroutine destroys the specified channel and ensures that the necessary cleanup is performed. Cleanup involves removing channels from the channel list for the appropriate session. This subroutine is called when a channel's resources must be deallocated, for example, when the corresponding session shuts down or the channel is no longer needed. If the channel is still open, this subroutine calls the CommEng_CloseChannel subroutine to close it and then destroys it. This ensures that reference counting is valid regardless of how the channel is destroyed.

【0092】

ChanMan_InitChannelList This subroutine creates and initializes a channel list for a given session. The channel list implementation is hidden from the session manager 418 by the channel manager 416, so this subroutine is called to initialize the channel list. ChanMan_DestroyChannelList This subroutine destroys the channel list for the specified session. ChanMan_ProcessSend This send subroutine calls the send subroutine of the appropriate protocol stack to do the actual processing (if needed) and the transmission of data or messages. The message queue manager 452 calls this subroutine when processing the send queue. The ChanMan_ProcessSend subroutine is finally called when something should be sent. This subroutine proceeds to push data through its protocol stack and send it down to equipment layer 450.

【0093】

ChanMan_ProcessRecv This ChanMan_ProcessRecv subroutine is called to process a received message before it is queued to be retrieved or peeked by the library user. This subroutine is called to pull a message from the protocol stack, which is then placed in the channel's receive queue by the caller. However, the protocol stack has its own receive queue, in which case this subroutine is called directly by the CommEng_RecvMsg API subroutine. When something comes from layer 450, ChanMan_ProcessRecv is called to process it before putting the data in the message queue.

【0094】

ChanMan_DoAsyncWork This subroutine is the entry point to the tick subroutine in the channel's protocol stack. This subroutine is called by session manager 418 to allow each channel the opportunity to do its work. The channel configuration manager manages to configure a channel to use a particular device, device protocol, and software protocol stack. It is primarily driven by the channel manager 416 to perform tasks in the channel configuration substructure or by the communication engine 600 to configure the channel.

【0095】

Each channel has its own channel-specific configuration. This configuration includes the software protocol stack and associated equipment, the equipment protocol used to carry the data, and other attributes such as whether it is open in transmit or receive or transmit / receive mode. The Channel Configuration Manager module API includes features that allow you to: That is, it adds or removes a protocol from the channel's protocol stack and sets it to use the device protocol (which saves the attributes needed to generate the channel, closes the device layer channel, and renews it. It can be changed at runtime via channel manager 416 by opening another device layer using the device protocol and now setting the device layer channel ID of Comm_channnel to the newly generated channel ID in the device layer. ), Includes the ability to set the device to use, and set or change other attributes.

【0096】

ChanCfg_DestroyChanCfg Channel manager 416 calls this subroutine to deal with the channel's configuration data. ChanCfg_CopyChannelCfg This helper subroutine copies data from the source channel configuration structure to the destination structure. Session manager 418 manages sessions and session-specific data, such as notification methods and channel lists. Each session has its own notification method, channel list, and session-specific data and library configuration.

【0097】

Session manager 418 drives other parts of the library, including channel manager 416 and message queue manager 452. Channel manager 416 manages the channel list for the session. The message queue manager 452 manages the message queue of the overall communication engine 600. A callback subroutine is registered in the device layer 450 to handle the received message. When a message is received, it is placed in the receive queue (via a call to message queue manager 452), and then the user uses the appropriate notification method configured for that particular session. Will be notified.

【0098】

The module interface function of the session manager and related subroutines will be described in detail below. SessMan_StartUp This subroutine starts session manager 418. Here, the initialization is performed all at once. SessMan_ShutDown This subroutine shuts down session manager 418 when it is called, and all resources used by the session are cleaned up. SessMan_AddSession This subroutine creates and initializes a session, including all necessary allocations of session-specific data.

【0099】

SessMan_RemoveSession This subroutine destroys the session and performs the necessary cleanup for the specified session. SessMan_SetConfig This subroutine allows the user to configure a session by state. SessMan_GetConfig This subroutine finds the current session state configuration. SessMan_SetNotificationMehod This subroutine sets notification methods and data for a particular session.

【0100】

SessMan_DoSynchronous This subroutine allows Session Manager 418 to perform the required synchronous actions. This subroutine then allows channel manager 416 to perform synchronous operations on the appropriate channels, if desired. The message queue manager 452 manages the message queue of the communication engine 600. Session manager 418 drives message queue manager 452 through its module interface. The architecture of the message queue manager 452 is very simple: insert messages into the appropriate queue based on priority. When a message is received via a callback subroutine registered in device layer 450, the message queue manager 452 processes the message through the channel's protocol stack and puts the message in the appropriate queue. When a message is sent via a transmit subroutine in the communication engine 600 (eg, CommEng_SendMsg), the message is placed in the send queue based on its priority. When the message queue manager 452 processes the send queue, it calls the send subroutine of channel manager 404 (eg, ChanMan_Send) to perform the actual send through the protocol stack.

【0101】

The module interface function of the message queue manager 452 and its related subroutines are described in detail below. MQMan_Startup This startup subroutine creates and initializes a message queue. MQMan_Shutdown This shutdown subroutine destroys the entire queue and cleans up after itself. MQMan_InitChannelQueue This subroutine initializes the incoming message queue for the specified channel. MQMan_DeInitChannelQueue This subroutine cleans up the incoming message queue for a given channel.

【0102】

MQMan_InsertSendMsg This subroutine inserts a message into the appropriate send queue based on priority. It is most often called by the mechanisms that handle the transmission and reception of data. This mechanism is executed via Session Manager 418. MQMan_ProcessSendQueue This subroutine is called by session manager 418 to process all messages in the send queue. In essence, this subroutine traverses the send queue, dereferences the channel pointer, and calls the channel's send subroutine.

【0103】

MQMan_FlishSendQueue This subroutine flushes the specified message queue. Queued messages are processed or discarded. MQMan_InsertRecvMsg This subroutine inserts a message into the appropriate channel receive queue. The session manager 418 calls this subroutine when receiving a message via the callback subroutine registered in the device layer 450. MQMan_PeekMsg This subroutine returns a pointer to the next message for the specified channel. MQMan_RemoveMsg This subroutine removes a message from the receive queue of a specified channel. If the message pointer itself is not specified, any message at the head of the receive queue on the specified channel will be removed.

【0104】

MQManFlushRecvQueue This subroutine flushes the receive queue for a given channel. The CPC302 offers the following features: Cross-Platform ANSI (American National Standards Institute) C Library, Standard Format Across Platform and Compiler, Standardized Compiler Features, Platform Format, Unicode Support, Cross-Platform Hardware Embroidery Gives layers and release and debug options. The CPC302 is the following hardware platform (for example, but not limited to): Windows 95/98 / NT 4.0 / 2000, Windows CE for Dreamcast, Shinobi for Dreamcast, Linux (Red hat). May work in connection with 5.1 / 5.2 / 6.0 / 6.1), and Playstation 2. Other hardware platforms are also included within the spirit and scope of the present invention, as will be apparent to those skilled in the art from the description herein. Therefore, the hardware platform described above is merely an example, and the present invention is not limited thereto. Supported hardware platforms may be defined in files such as C_targets.h.

【0105】

Unicode is a standard for representing characters as integers. Unlike ASCII, which uses 8 bits for each character, Unicode uses 16 bits, which means it can represent more than 65,000 unique characters. This is not necessary for English and Western language programs (ie computer games), but for some other languages such as Greek, Chinese and Japanese. As the software industry becomes more globalized, Unicode will eventually replace ASCII as the standard character code format. The CPC320 can include macros to convert ASCII to Unicode and vice versa.

【0106】

Although the basic novel features of the present invention have been described above in relation to the preferred embodiments thereof, those skilled in the art can make various omissions, replacements and changes without departing from the scope of the present invention. It will be understood to get. Therefore, the present invention shall be limited only by the scope of claims.

[Simple explanation of drawings]

[Fig. 1A]

It is a circuit diagram which shows the structure of the multiplayer computer game system configured by the Embodiment of this invention.

[Fig. 1B]

It is a circuit diagram which shows another structure of the multiplayer computer game system which was configured by embodiment of this invention.

[Fig. 1C]

It is a circuit diagram which shows still another structure of the multiplayer computer game system which was configured by embodiment of this invention.

[Fig. 1D]

It is a circuit diagram which shows still another structure of the multiplayer computer game system which was configured by embodiment of this invention.

[Fig. 1E]

It is a circuit diagram which shows still another structure of the multiplayer computer game system which was configured by embodiment of this invention.

[Fig. 1F]

It is a circuit diagram which shows still another structure of the multiplayer computer game system which was configured by embodiment of this invention.

[Fig. 1G]

It is a circuit diagram which shows still another structure of the multiplayer computer game system which was configured by embodiment of this invention.

[Figure 2]

A schematic of multiple servers configured as a server cluster and provided as part of the multiplayer computer game system of Figure 1A.

[Fig. 3]

It is a figure which shows the various elements provided by the special purpose software which can operate in connection with the processor of a client computing apparatus by embodiment of this invention.

[Fig. 4A]

It is a figure which shows the architecture of the application program, the cross-platform core, and the client computer hardware and the operating system by embodiment of this invention.

[Fig. 4B]

It is a figure which shows the architecture of the application program, the cross-platform core, and the client computer hardware and the operating system by embodiment of this invention.

[Fig. 5]

It is a figure which shows the protocol stack for the service layer of the cross-platform core shown in FIG. 4A.

[Fig. 6]

It is a figure which shows the flow of data with respect to the pass-through mode operation of the communication engine of the cross-platform core of this invention.

[Fig. 7]

It is a figure which shows the flow of data with respect to the synchronous mode operation of the communication engine of the cross-platform core of this invention.

[Fig. 8A]

It is a figure which shows the embodiment of the match make server by this invention.

[Fig. 8B]

It is a figure which shows another embodiment of the match make server by this invention.

[Fig. 8C]

It is a figure which shows still another embodiment of the match make server by this invention.