WO2012164786A1 - ゲーム制御装置、マッチング方法、プログラム - Google Patents

ゲーム制御装置、マッチング方法、プログラム Download PDF

Info

Publication number
WO2012164786A1
WO2012164786A1 PCT/JP2012/001207 JP2012001207W WO2012164786A1 WO 2012164786 A1 WO2012164786 A1 WO 2012164786A1 JP 2012001207 W JP2012001207 W JP 2012001207W WO 2012164786 A1 WO2012164786 A1 WO 2012164786A1
Authority
WO
WIPO (PCT)
Prior art keywords
player
identification information
player identification
game
matching
Prior art date
Application number
PCT/JP2012/001207
Other languages
English (en)
French (fr)
Inventor
高橋　究
Original Assignee
株式会社コナミデジタルエンタテインメント
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社コナミデジタルエンタテインメント filed Critical 株式会社コナミデジタルエンタテインメント
Publication of WO2012164786A1 publication Critical patent/WO2012164786A1/ja

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/798—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for assessing skills or for ranking players, e.g. for generating a hall of fame
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/80—Special adaptations for executing a specific game genre or game mode
    • A63F13/812—Ball games, e.g. soccer or baseball
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/406—Transmission via wireless network, e.g. pager or GSM
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/5566—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by matching opponents or finding partners to build a team, e.g. by skill level, geographical area, background, play style

Definitions

  • the present invention relates to a technique for matching player identification information for a match between players for a plurality of player identification information.
  • player identification information for individually identifying each player is registered in a server connected to the network. Then, matching (combination of battles) between a plurality of players in the battle game is automatically determined by the server based on the player identification information.
  • a matching method for a plurality of player identification information a tournament-type automatic matching method as described in Patent Document 1 and an opponent (player ID) are randomly determined as described in Patent Document 2. Automatic matching methods and the like are known.
  • player identification information registered by the player is recorded in a non-volatile memory such as an HDD (Hard Disk Drive) in a server (game control device) connected to the network.
  • the server processor uses a main memory such as a RAM (Random Access Memory) to match a plurality of player identification information in the nonvolatile memory.
  • main memory such as a RAM (Random Access Memory)
  • the delay in the matching process becomes more prominent as the number of player identification information to be processed increases.
  • the number of pieces of player identification information to be matched in the server is much less than 1 million, for example, about several thousand to several tens of thousands.
  • each time the player identification information is extracted to the main memory in order to perform the matching process for the active player identification information connected to the network in the nonvolatile memory data of several tens of K bits is scanned. It will be.
  • the player does not need to perform a complicated operation, and the game is performed by a simple operation only in a short time. Further, the player performs an operation in parallel with this game.
  • a game is automatically executed in the background (that is, on the server side) to notify the player only of the result of the battle.
  • a battle is automatically executed for all player identification information registered in a server on the network regardless of the player's intention to participate in the battle. In that case, for example, if 1 million player identification information is registered for a specific game, it is necessary to perform matching on 1 million player identification information.
  • each time player identification information is extracted from the non-volatile memory to the main memory in order to perform the matching process, a large amount of data of several M bits is scanned.
  • the present invention has been made in view of the above-described viewpoints. When matching is performed on a large number of player identification information for a match between players using a limited main memory, matching is performed. It is an object of the present invention to provide a game control device, a matching method, and a program that can suppress delay due to processing.
  • a first aspect of the present invention is a game control device that performs matching of player identification information for a battle between players for a plurality of player identification information stored in a nonvolatile memory, First extraction means for extracting M player identification information from the plurality of player identification information according to a certain rule and developing the extracted information in a main memory; Second extraction means for randomly extracting N (N ⁇ M) player identification information from the player identification information on the main memory; Matching execution means for performing matching on N pieces of player identification information extracted by the second extraction means; From the plurality of player identification information, N player identification information not extracted by the first extraction means is newly extracted according to the certain rule, and the newly extracted N player identification information is A third extraction means for developing in the main memory instead of the N player identification information matched by the matching execution means; And the processes by the second extraction unit, the matching unit, and the third extraction unit may be repeated in this order.
  • the game control device may be any information processing device that can establish a connection with each of the communication devices of a large number or a large number of unspecified players via a network.
  • a game control device may be, for example, one or a plurality of servers arranged on a network, or a large computer device.
  • the player and the communication terminal do not necessarily have a fixed one-to-one correspondence, and a usage mode of the communication terminal in which a plurality of players share a single communication terminal is also assumed. Therefore, this game control apparatus may manage a player for each piece of player identification information such as a player ID, as information that can uniquely identify a player who plays a battle game.
  • the “certain rule” may be any rule as long as it is a rule that orders each of a plurality of player IDs without overlapping, for example, ascending order or descending order.
  • the nonvolatile memory stores each player identification information in association with the time when the player device was last accessed based on the player identification information.
  • the first extraction means and the third extraction means may extract player identification information for which a predetermined time has not elapsed from the time of the last access from the plurality of player identification information.
  • class management means for managing each player identification information in association with any one of a plurality of classes; Storage means for storing each N pieces of player identification information extracted by the second extraction means and the third extraction means for each corresponding class, When the number of player identification information accumulated for each class reaches a predetermined number for the class, the matching execution unit determines that matching for the player identification information accumulated for the class is completed. Also good.
  • a communication means for communicating with an arbitrary communication terminal via a network;
  • Storage means for storing player identification information in the non-volatile memory based on an access for registration related to a battle participation from an arbitrary communication terminal may be provided.
  • a matching method in a game control device for matching player identification information for a match between players for a plurality of player identification information stored in a nonvolatile memory.
  • a third aspect of the present invention is a program for matching player identification information for a match between players targeting a plurality of player identification information stored in a nonvolatile memory, A first extraction procedure for extracting M player identification information from the plurality of player identification information according to a certain rule and developing the extracted information in the main memory of the computer; A second extraction procedure for randomly extracting N (N ⁇ M) player identification information from the player identification information on the main memory; A matching execution procedure for performing matching on N pieces of player identification information extracted by the second extraction procedure; From the plurality of player identification information, N player identification information not extracted in the first extraction procedure is newly extracted according to the certain rule, and the newly extracted N player identification information is A third extraction procedure that expands in the main memory in place of the N player identification information matched in the matching execution procedure; A procedure of repeating the second extraction procedure, the matching execution procedure and the third extraction procedure in this order; May be a program for causing a computer to execute.
  • This program may be stored in a computer-readable information storage medium such as a DVD-ROM or CD-ROM.
  • the figure which shows the basic composition of the game system of 1st Embodiment The block diagram which shows the structure of the communication terminal of 1st Embodiment.
  • the block diagram which shows the structure of the game server of 1st Embodiment The block diagram which shows the structure of the database server of 1st Embodiment.
  • the figure which shows the structural example of the ranking database contained in a database server The figure which shows the basic composition of the game system of 1st Embodiment.
  • the block diagram which shows the structure of the communication terminal of 1st Embodiment The block diagram which shows the structure of the game server of 1st Embodiment.
  • FIG. 1 shows a system configuration example of a game system according to the embodiment.
  • this game system includes communication terminals 10a, 10b, 10c,... That can be connected to a communication network NW such as the Internet, a game server 20 connected to the communication network NW, and a database server 30. And is composed of.
  • Each of the communication terminals 10a, 10b, 10c,... Is a terminal operated by an individual player.
  • an application operable on a web browser is installed in the game server 20 as a game application.
  • the communication terminal 10 includes a web browser capable of displaying a web page provided by the game server 20, and a player operates the communication terminal 10 on the web page to execute a game.
  • the database server 30 stores various types of information to be described later in executing the game, and is connected to the game server 20 by, for example, a wire for reading and writing such information.
  • an authentication server for authenticating the player of each communication terminal 10 may be provided separately from the game server 20. Further, when a plurality of game servers 20 are provided in order to accept access from many communication terminals 10, a load balancer for adjusting a load between the plurality of game servers 20 may be provided.
  • the game server 20 may be configured as a single server device, but may be configured as a plurality of server devices having distributed functions.
  • the communication terminal 10 includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an image processing unit 14, an operation input unit 15, a display unit 16, A wireless communication interface unit 17 is provided, and a bus 18 for transmitting control signals or data signals between the units is provided.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • a wireless communication interface unit 17 is provided, and a bus 18 for transmitting control signals or data signals between the units is provided.
  • the CPU 11 loads the web browser in the ROM 12 into the RAM 13 and executes it. Then, the CPU 11 displays data for displaying a web page from the game server 20 via the wireless communication interface unit 17 based on appropriate designation of a URL (Uniform Resource Locator) input to the player by the operation input unit 15 or the like. That is, data of an object such as an HTML (HyperText Markup Language) document and an image associated with the document (hereinafter, collectively referred to as “HTML data” as appropriate) is acquired via the wireless communication interface unit 17. The HTML data is interpreted.
  • the communication terminal 10 may be mounted with various plug-ins for extending the browser function of the web browser. In acquiring HTML data, the CPU 11 sends an access request message including a player ID (player identification information) registered in advance or a player ID input via the operation input unit 15 via the wireless communication interface unit 17. To the game server 20.
  • the web browser displays the web page provided from the game server 20 on the display unit 16 based on the acquired HTML data via the image processing unit 14. Further, when the player selects a hyperlink or object on the web page by operating the operation input unit 15, the web browser transmits new HTML data for displaying the web page according to the selection. Is requested to the game server 20.
  • the image processing unit 14 displays a web page on the display unit 16 based on the display image data given from the CPU 11 as the analysis result of the HTML data.
  • the display unit 16 is, for example, an LCD (Liquid-Cristal-Display) monitor including thin film transistors arranged in units of pixels in a matrix, and displays an image of a web page by driving the thin film transistors based on display image data.
  • LCD Liquid-Cristal-Display
  • the operation input unit 15 may include a plurality of buttons for accepting the player's operation input and an interface circuit for recognizing the pressing input of each button and outputting it to the CPU 11, but in FIG. Examples of buttons are shown.
  • the direction instruction button is provided to instruct the CPU 11 to scroll and display the web page displayed on the display unit 16.
  • the determination button instructs the CPU 11 that the player selects one hyperlink or object that is actively displayed (for example, highlighted) when, for example, a plurality of hyperlinks or objects are displayed on the web page.
  • these buttons are arranged on the front surface of the communication terminal 10 so that the player can easily operate with the thumb while holding the communication terminal 10 with one hand. It is preferable.
  • the configuration of the game server 20 will be described with reference to FIG.
  • the game server 20 manages, for example, a battle game website including a plurality of web pages having a hierarchical structure, and provides a battle game web service to the communication terminal 10.
  • the game server 20 includes a CPU 21, a ROM 22, a RAM 23, a database (DB) access unit 24, and a communication interface unit 25 (an example of a communication means).
  • a bus 26 is provided for transmitting signals.
  • the game server 20 can take the same structure as a general-purpose web server regarding hardware.
  • the ROM 22 stores an application program (program of this embodiment) that provides a service of displaying an object such as an HTML document or an image (displaying a web page) to the web browser of the communication terminal 10 that is a client.
  • the CPU 21 loads the game program in the ROM 22 to the RAM 23 and executes it, and performs various processes via the communication interface unit 25.
  • the CPU 21 transmits HTML data to the communication terminal 10 via the communication interface unit 25.
  • the CPU 21 performs the authentication process.
  • the CPU 21 performs processing according to the hyperlink or object selected by the player on the web page displayed on the communication terminal 10 via the communication interface unit.
  • the processing includes, for example, transmission of new HTML data, arithmetic processing in the game server 20 or data processing.
  • the database access unit 24 is an interface when the CPU 21 reads / writes data from / to the database server 30.
  • the database server 30 is an embodiment of a nonvolatile memory, and can be realized by a general-purpose storage such as a large-capacity hard disk device or a device in the form of RAID (Redundant Arrays of Inexpensive Disks).
  • Each database in the database server 30 is configured to be able to read and write data from the CPU 21 via the database access unit 24 of the game server 20.
  • FIG. 4 shows an example of the configuration of the database server 30.
  • the example shown in FIG. 4 is an example of a database for realizing a battle game described later, and the database server 30 includes a player database 31, a league game database 32, and a ranking database 33. The contents of these databases will be described later.
  • the game server 20 and the database server 30 constitute the game control device of the present invention.
  • the game executed by the game control device may be in any format as long as it is a game including a battle element between players, such as a game simulating sports such as baseball and soccer, or a game simulating battle. It does n’t matter.
  • competition game is demonstrated with reference to FIG.
  • FIG. 5 is a functional block diagram for explaining functions that play a main role in the game control apparatus of the present embodiment.
  • the baseball game of this embodiment is configured so that two battles progress.
  • One is an individual battle (first battle) performed between player characters associated with different player IDs, triggered by an operation input of the communication terminal 10 by the player.
  • the other is a league battle (second battle) that is automatically performed between player characters associated with different player IDs without triggering an operation input to the communication terminal 10 by the player.
  • a battle between player characters associated with different player IDs and “a battle between player IDs” are synonymous.
  • the game progression means 51 has a function of advancing a game displayed on the player's communication terminal 10 through a web page on the communication terminal 10 in response to an operation on the communication terminal 10 by the player.
  • the CPU 21 transmits HTML data for displaying a web page according to the selection of a hyperlink or object on the web page by the player to the communication terminal 10 via the communication interface unit 25.
  • the CPU 21 sequentially transmits new HTML data in accordance with the selection of a hyperlink or an object on the web page by the player, whereby the web page displayed on the communication terminal 10 is sequentially switched, so that the player progresses the game.
  • the game progress means 51 when the CPU 21 of the game server 20 receives an access request message from the communication terminal 10 via the communication interface unit 25 prior to the start of the game, after the predetermined authentication process, the communication terminal 10 recognizes the player ID included in the access request message. Then, the CPU 21 of the game server 20 manages the progress of the game displayed on each communication terminal 10 in units of player IDs. For example, the player ID may be given (registered) after the player accesses a baseball game website provided by the game server 20 through the communication terminal 10 and undergoes a predetermined procedure.
  • FIG. 6 is an example of a web page displayed on the communication terminal 10 by the game progress means 51.
  • the web page shown in FIG. 6 is a web page that is displayed when a player accesses a baseball game website provided by the game server 20 through the communication terminal 10, and corresponds to the main menu of the baseball game.
  • the text “Scout”, “Order”, “Strengthen”, “Lottery”, “Game”, “League game” is displayed in a predetermined area (with a hyperlink).
  • the CPU 21 is played by the player via the communication interface unit 25 in the game progress means 51. Recognizing the selection result, new HTML data is transmitted to the communication terminal 10.
  • a new web page corresponding to the selection result of the player is displayed on the display unit 16 of the communication terminal 10.
  • the storage means 52 has a function of storing the player character's ability value in association with each player ID.
  • the storage means 52 is realized by the player database 31 of the database server 30.
  • FIG. 7 is an example of the player database 31 in the baseball game of this embodiment.
  • the player database 31 includes, for each player ID, ability value data for each item of a plurality of player characters associated with the player ID.
  • the capability value is a value in the range of 0 to 1000, and the higher the capability value is, the higher the capability is.
  • the batting power is 300
  • the running power is 450
  • the defense power is 810 is shown as an example.
  • FIG. 7 for player A, the case where the batting power is 300, the running power is 450, and the defense power is 810 is shown as an example.
  • FIG. 7 for player A, the case where the batting power is 300, the running power is 450, and the defense power is 810 is shown as an example.
  • FIG. 7 for player A, the case where the batting power
  • the player database 31 has each player ID and the time of last access to the game server 20 based on the player ID (corresponding to “last access date” in FIG. 7). And may be stored in association with each other. In this case, in the game server 20, the time when the game server 20 was accessed is held for each player ID, and the game server 20 notifies the database server 30 of the player ID and the accessed time for each access, The last access date is updated sequentially.
  • the first battle execution unit 53 executes an individual battle (first battle) between player characters associated with different player IDs, triggered by an operation input to the communication terminal 10, and a storage unit 52 (this embodiment). Then, the battle result of the individual battle is determined based on the ability value of the player character stored in the player database 31) of the database server 30.
  • the CPU 21 of the game server 20 determines an opponent to perform an individual battle based on an operation input to the operation input unit 15 of the communication terminal 10 by the player. For example, when an operation for selecting an object including the text “game” is performed by the player on the web page illustrated in FIG. 6, the selection result is transmitted to the CPU 21 of the game server 20. And CPU21 accesses the player database 31 of the database server 30 via the database access part 24, for example, selects player ID used as an opponent at random. Alternatively, for a plurality of randomly selected player IDs, the CPU 21 displays the plurality of player IDs and the ability values of the corresponding player characters in order to confirm the selection of the player ID to be the opponent by the player. HTML data may be transmitted to the communication terminal 10 of the player. When the opponent is determined, the CPU 21 executes an individual battle between the player characters associated with the two player IDs to battle.
  • the determination method of the win / loss of the individual battle can be any method as long as the ability value of the player character affects the win / loss.
  • the ability values of the player characters associated with the two player IDs that are opponents are compared, and a player character with a larger ability value has a higher probability (for example, a predetermined probability within a range of 60 to 90%).
  • You may set it to win.
  • the win rate may be higher as the difference in ability values is larger.
  • predetermined weighting for example, in the example of FIG.
  • the total ability value can be set with a weight of 0.2 for “power” and a weight of 0.4 for “defense”.
  • the CPU 21 of the game server 20 determines the battle results of the individual battles of the player characters associated with the two player IDs that are opponents, a web page including the battle results is displayed. HTML data to be transmitted is sent to the communication terminal 10 of the player of the two player IDs that are opponents. Then, the communication terminal 10 interprets the HTML data received from the game server 20 and displays the battle result on the display unit 16. It should be noted that the time from when the player selects an object including the text “game” on the web page illustrated in FIG. 6 until the match result is displayed is extremely short (for example, several seconds). The player can know the battle result in a very short period of time only with a simple operation.
  • the character ability updating means 54 has a function of updating the ability value of the player character corresponding to the player ID based on the battle result of the individual battle (first battle).
  • the CPU 21 of the game server 20 accesses the player database 31 of the database server 30 based on the battle results of the individual battles between the player characters associated with different player IDs, and the player IDs thereof.
  • the ability value of the player character associated with is updated. That is, the CPU 21 writes a new ability value in the player database 31.
  • it is preferable that the ability value of the player character is updated so as to be larger than the current value when the player character corresponding to the player ID wins the individual battle.
  • the ability value of the player character is updated to be smaller than the current value when the player character corresponding to the player ID is defeated in the individual battle.
  • the amount of change in the ability value can be set arbitrarily. For example, as shown in FIG. 7, when there are a plurality of ability value items, the ability value of all player characters may be made larger or smaller by the same value. Or you may set the variation
  • the second battle execution means 55 automatically executes a league battle (second battle) between player characters associated with different player IDs without triggering an operation input to the communication terminal 10, and a storage means. 52 (in this embodiment, the player database 31 of the database server 30) determines the match result of the league match based on the ability value of the player character stored.
  • the league game executed by the second battle execution means 55 is performed at a predetermined time (for example, a time set by a timer in the game server 20).
  • the league match may be set so that all player IDs participate (or register), but may be set so that only some of the player IDs who want to participate in the league match will participate.
  • the determination method of the winning / losing of the battle executed by the second battle execution means 55 can be the same as that of the first battle execution means 53. In other words, any method can be adopted as long as the ability value of the player character affects the winning or losing. Note that it takes a certain time to determine all the results of the league match, and the ability value of the player character can be updated in accordance with the execution of the individual match within that time. Accordingly, copy data of the player database 31 is created at the start time of the league match, and the ability value of the player character in the copy data is referred to while the second battle execution means 55 is being executed. Thereby, the ability value of the player character (data of the player database 31 itself) can be continuously updated by the character ability update means 54 even during the execution of the second battle execution means 55.
  • the second battle execution means 55 records the battle results of at least a past league match for a certain period. Specifically, in the second battle execution means 55, the CPU 21 of the game server 20 accesses the database server 30 and writes the league match result in the league match database 32 in the database server 30.
  • An example of the league game database 32 is shown in FIG. In the example illustrated in FIG. 8, when a league game is executed every day, a battle result of the league game is recorded for each date. In the example of FIG.
  • the match result of the league match includes a match ID for identifying the match, a player ID corresponding to the winning player character (winning player ID), and a player ID corresponding to the defeated player character (defeat) Player ID), score, and other data (for example, data of a player character corresponding to a winning pitcher).
  • the ranking of the player ID in the league game is recorded and updated sequentially.
  • the CPU 21 of the game server 20 accesses the league match database 32 of the database server 30 to read out the match result of the past league match of the league match, and the read match result Based on the above, the ranking for each player ID is calculated. Then, the CPU 21 accesses the database server 30 and writes the calculated ranking in the ranking database 33 in the database server 30.
  • An example of the ranking database 33 is shown in FIG. In the example shown in FIG. 9, the ranking of the player ID is recorded in order from the first, and the number of wins, the negative number, and the number of draws in the league game are recorded for each player ID.
  • the notifying means 56 shows the player's ranking (rank) for each player ID based on the battle result of one or more league matches (second match) for the predetermined period or the predetermined number of times and / or the match result. Notification is made to the communication terminal 10.
  • the notification means 56 when the CPU 21 of the game server 20 recognizes that the “league game” has been selected on the web page shown in FIG. 6, for example, the battle result in the latest league game and / or a predetermined past number HTML data for displaying a web page including a ranking for each player ID based on a match result of one or a plurality of league matches for a period or a predetermined number of times is transmitted to the communication terminal 10.
  • FIG. 10 shows an example of a web page displayed on the communication terminal 10 by interpreting the HTML data.
  • the result of the league match corresponding to the player ID (for example, the result of winning and losing 45 wins and 15 losses, the ranking of 6573th etc.) is displayed.
  • information about each of a plurality of sections in the league game (section 4, section 5, section 6) is scrolled by, for example, a direction instruction button of the operation input unit 15 of the communication terminal 10. An example to be displayed is shown.
  • FIG. 10 shows an example of a web page displayed on the communication terminal 10 by interpreting the HTML data.
  • 10 is a display example on a specific date when the league match of Section 5 is being performed, for example, in order from the bottom, the match result of Section 4, the match result of Section 5, the match schedule of Section 6, The overall winning and losing results and rankings in the current league match are shown.
  • FIG. 11 is a functional block diagram showing a plurality of means constituting a part of the functions executed by the second battle execution means 55, and each means is executed mainly by the CPU 21.
  • the first extraction unit 551 has a function of extracting M player IDs from the player IDs stored in the player database 31 and developing them in the RAM 23 (main memory) according to a certain rule.
  • the second extraction unit 552 has a function of randomly extracting N (N ⁇ M) player IDs from the player identification information on the RAM 23.
  • the matching execution unit 553 has a function of performing matching on N player IDs extracted by the second extraction unit 552.
  • the third extraction means 554 newly extracts N player IDs that have not been extracted by the first extraction means 551 from the player IDs stored in the player database 31 according to the above-mentioned fixed rule.
  • a function of expanding the extracted N player IDs in the RAM 23 in place of the N player IDs matched by the matching execution unit 553 is provided.
  • the second battle execution means 55 has a function of repeating the processes by the second extraction means 552, the matching execution means 553, and the third extraction means 554 in this order.
  • the battle execution unit 555 has a function of executing a league battle (second battle) between player characters associated with the player ID based on the matching result of the player ID obtained by the matching execution unit 553. .
  • FIG. 12 is a flowchart showing the matching process of this embodiment.
  • FIG. 13A and FIG. 13B are diagrams for conceptually explaining the state of the matching process of the present embodiment.
  • symbol is used so that it can contrast with each step of FIG.
  • steps S10, S20, S30, and S40 in FIG. 12 correspond to the first extraction unit 551, the second extraction unit 552, the matching execution unit 553, and the third extraction unit 554, respectively.
  • the CPU 21 first extracts 10,000 (M) player IDs from the player IDs stored in the player database 31 (player DB 31) in the ascending order of the player IDs, and the RAM 23 (main memory). (Step S10).
  • M 10,000
  • N 100
  • the CPU 21 first extracts 10,000 (M) player IDs from the player IDs stored in the player database 31 (player DB 31) in the ascending order of the player IDs, and the RAM 23 (main memory).
  • Step S10 it is assumed that a certain rule for extracting the player ID from the player database 31 follows the ascending order of the numbers indicated by the player ID.
  • the player IDs 1 to 100 are extracted in step S 10
  • the player ID (101 in this case) for starting the next extraction from the player database 31 is stored in the RAM 23.
  • the CPU 21 randomly extracts 100 (N) player IDs from 10,000 (M) player identification information on the RAM 23 (step S20), and the extracted 100 players. Matching is performed for the ID (step S30).
  • An example of matching for 100 player IDs is as follows. 100 player IDs are randomly classified into 25 groups (4 player IDs in each group), and a round-robin battle is performed in each group. In this case, if the four player IDs of each set are A, B, C, and D, A ⁇ B, A ⁇ C, A ⁇ D, B ⁇ C, B ⁇ D, and C ⁇ D 6 Matching of matches (three games for each player ID) is made for each group.
  • step S35 the CPU 21 determines whether or not there is an unextracted player ID in the player database 31 (step S35). As a result, when there is an unextracted player ID, the CPU 21 newly extracts 100 player IDs not extracted in step S10 from the player IDs stored in the player database 31 in ascending order. Then, the 100 newly extracted player IDs are expanded in the RAM 23 in place of the 100 player IDs matched in step S30 (step S40).
  • step S40 is first executed, player IDs are extracted in ascending order from the player ID: 101 stored in step S10. After 100 new player IDs are newly extracted and expanded in the RAM 23, the process returns to step S20.
  • steps S20, S30, and S40 are repeated in this order until there is no unextracted player ID in the player database 31.
  • the processes of the first steps S20 and S30 are indicated by S20 (# 1) and S30 (# 1), respectively, and the processes of the second steps S20 and S30 are respectively indicated by S20 (# 2), This is indicated by S30 (# 2).
  • S20 to S40 are sequentially repeated. As a result, the player IDs that have not been extracted from the player IDs stored in the player database 31 gradually decrease.
  • step S35 When there is no unextracted player ID in the player database 31, the process proceeds from step S35 to step S50, and the processes of steps S20 and S30 are repeated in this order.
  • This is a state in which there is no player ID to be newly extracted from the player database 31, but matching is sequentially performed for player IDs (maximum 10,000) in the RAM 23.
  • S20 (#n) and S30 (#n) which are the processes of the n-th steps S20 and S30, and the next The number of player IDs that have not been matched gradually decreases as the process proceeds in the order of S20 (# n + 1), S30 (# n + 1).
  • step S50 YES
  • step S40 which is repeatedly executed, extraction from the player database 31 storing 1 million player IDs is sequentially performed in ascending order of player IDs. Each time the player ID is extracted, by storing only the player ID for which extraction is newly started, it is possible to perform the extraction every time in step S40 at high speed.
  • the number of player IDs stored in the player database 31 is 1 million
  • M is 10,000
  • N is 100
  • the number of extractions in step S40 is (1 million-10,000) / 100.
  • the player ID at the start of each extraction is immediately known and the extraction method follows the ascending order of the player ID, each extraction process can be completed at high speed.
  • matching for a very large number of player IDs can be executed at high speed using the RAM 23 with a limited capacity.
  • step S10 or step S40 for extracting the player ID from the player database 31 the player ID is sequentially extracted in ascending order of the player ID, and data for identifying whether or not the extraction has been performed. Processing for scanning for each player ID is not necessary. Therefore, even if the number of player IDs in the player database 31 increases during the operation of the game server 20, an increase in processing time required for matching player IDs in the player database 31 is suppressed. Therefore, it is possible to avoid a response such as expansion of the RAM 23 (for example, addition of memory) or system modification corresponding to the increase of the player ID stored in the player database 31.
  • each player ID is stored in association with the time (last access date and time) when the game server 20 was last accessed based on the player ID. Also good.
  • step S10 and step S40 it is preferable to extract from the player IDs in the player database 31 a player ID whose current time has not passed a predetermined time from the last access date. That is, not all player IDs stored in the player database 31 are extracted, but filtering of player IDs to be extracted is performed based on the last access date and time. In this way, player IDs that have been registered in the game server 20 but have not been accessed for a certain period of time (that is, player IDs that are registered but not used) are excluded from the extraction targets. Thereby, since the number of player IDs to be extracted is limited, the time required for matching is further shortened.
  • the player ID whose current time has not passed the predetermined time from the last access date and time will be further described as follows. That is, the player with the player ID whose current time has elapsed from the last accessed time has not accessed the game control device for a certain period of time with reference to the current time, and substantially participates in the game. It is thought that it is not.
  • the player ID can be registered with a relatively simple procedure, so the number of player IDs managed by the game control device is likely to increase, but the corresponding player continues after registration. It does not necessarily participate in the game.
  • FIG. 14 shows an example of a league game schedule using such matching.
  • the leagues of the 1st, 2nd, 3rd and 4th sections of the week are scheduled on weekdays (in the example of FIG. 14, 9 o'clock, 14 o'clock, 19 o'clock and 25 o'clock), respectively. Scheduled for war to take place.
  • the matching process shown in FIG. 12 is performed each time, and in each section, a total of six games (three games for each player ID included in each group) are performed. .
  • each player ID will have a total of 12 games of 3 games x 4 games.
  • the second battle execution means 55 calculates the ranking of the player ID in the league game every time each section is finished, and writes the calculated ranking in the ranking database 33 in the database server 30. Good.
  • the player IDs to be matched may be classified into 100 pairs each composed of two player IDs, and a single battle may be scheduled at an appropriate timing. That is, if the number to be matched is determined, a battle plan can be arbitrarily set according to the number.
  • FIG. 15 is a flowchart showing execution processing of a league match (second match).
  • the second match execution means 55 is executed when the league match of each section is scheduled (YES in Step S ⁇ b> 200).
  • the second battle execution means 55 is automatically executed without triggering an operation input to the communication terminal 10 by the player.
  • the second battle execution means 55 performs, for example, the matching process of the battle in the first league game when the first league game is performed for the player ID stored in the player database 31 (step 1). S210).
  • This matching process is as shown in the flowchart of FIG. 12, and is performed at high speed even when the number of player IDs stored in the player database 31 is extremely large.
  • the second match execution means 55 next refers to the player database 31 so that the player character's ability value affects the winning / losing based on the ability value of the player character. Then, the battle result is determined (step S220). The second match execution means 55, after determining the match result, records the match result of the first round league match in the league match database 32, and also determines the player ID based on the match result of the first round match match. The ranking is recorded in the ranking database 33 (step S230). Thereafter, the notification means 56 notifies the communication terminal 10 of the player corresponding to each player ID participating in the league game of the match result of the first section and the ranking of the player ID at the time when the first section ends. (Step S240).
  • this notification is made when each player selects “League Battle” on the web page illustrated in FIG. 6, for example, at the communication terminal 10 as a result of the first section match and at the time when the first section ends.
  • the web page including the ranking of the player ID can be displayed.
  • steps S200 to S240 are performed again.
  • the first extraction unit 551 extracts M player IDs from a plurality of player IDs according to a certain rule and expands them in the main memory.
  • the “certain rule” may be any rule as long as it is a rule that orders each of the plurality of player IDs without duplication, for example, ascending order or descending order.
  • this first extraction means 551 since the player ID is extracted according to a certain rule, it is determined whether or not each of the plurality of player IDs stored in the database server 30 (nonvolatile memory) has been extracted, for example, a flag. Does not need to be associated with identifying data.
  • the number (M) of player IDs to be extracted can be set to an arbitrary value according to the capacity of the main memory, and the number of player IDs stored in the database server 30 is 1 to 2 million. For example, M may be about 10,000.
  • the second extracting means 552 randomly extracts N (N ⁇ M) player IDs from the player IDs on the RAM 23 (main memory).
  • the matching execution unit 553 performs matching for the N player IDs extracted by the second extraction unit 552.
  • the third extracting means 554 newly extracts N player IDs that have not been extracted by the first extracting means 551 from the plurality of player IDs according to the predetermined rule, and newly adds the new player IDs.
  • the extracted N player IDs are developed in the RAM 23 in place of the N player IDs that have been matched by the matching execution unit 553.
  • the already matched N player IDs are removed from the RAM 23, and instead, new N player IDs are extracted from the database server 30 and developed in the RAM 23.
  • the extraction from the database server 30 is sequentially performed according to a certain rule in the same manner as the first extraction unit 551 with the player ID last extracted by the first extraction unit 551 as a reference.
  • the processes by the second extraction unit 552, the matching unit, and the third extraction unit 554 are repeated in this order.
  • the matching of N player IDs is executed in sequence, and each time the matching of N player IDs is completed, a new N player IDs are stored in the plurality of player IDs stored in the database server 30. Will be extracted from.
  • the third extraction means 554 sequentially performs extraction from the database server 30 including a large number of player IDs according to the above-mentioned fixed rule. By storing only the obtained player ID (or only the player ID that newly starts extraction), the third extraction unit 554 can perform extraction every time at high speed.
  • the number of extractions by the third extraction means 554 is (1 million-10,000) /
  • 100 9900 times
  • the player ID at the start of each extraction is recognized based on the “certain rule” as described above, that is, based on the player IDs ordered without duplication in ascending or descending order.
  • the location where the extraction should start this time is immediately known with respect to the previous extraction, and the extraction method follows a certain rule, so that each extraction process can be completed at high speed.
  • this game control device matching for a very large number of player IDs can be executed at high speed using the RAM 23 with a limited capacity.
  • the first extraction unit 551 or the third extraction unit 554 that extracts the player ID from the database server 30 sequentially extracts the player ID according to a certain rule. In other words, it is not necessary to perform processing for sequentially checking, for each player ID, data for identifying whether or not extraction has been performed, for example, depending on whether or not a flag is set. Therefore, even if the number of player IDs in the database server 30 increases during the operation of the game control apparatus, an increase in processing time required for matching the player IDs in the database server 30 is suppressed. Therefore, it is possible to avoid a response such as expansion of the RAM 23 (for example, addition of memory) or system modification corresponding to the increase of the player ID stored in the database server 30.
  • N player IDs are randomly extracted from the player IDs by the second extraction means 552, and after the extraction, new N player IDs are supplemented from the database server 30. Is done. Therefore, any possibility of matching of the player ID in the database server 30 is not excluded. Specifically, even if the number of player IDs stored in the database server 30 is 1 million (1st to 1 millionth player IDs) and extracted in ascending order, the 1st and 100th The possibility of matching the 10,000th player ID is not excluded. In other words, according to this game control device, it is possible to provide an opportunity for a player to play against each other over a wide range.
  • each player ID is associated with one of a plurality of classes.
  • the class type can be arbitrarily set. For example, hierarchical classes from a beginner class (beginner class, for example, class: 1) to a master class (advanced class, for example, class: 9) can be set.
  • a league game for a certain period is performed for each class.
  • a replacement game is held between league games for a certain period.
  • the class corresponding to the player ID may be updated (changed). Therefore, in the baseball game of this embodiment, in addition to the game elements described in the first embodiment, the game is performed for the purpose of promoting the player of each player ID to a higher class.
  • the class update performed by the replacement battle is either promotion to a higher class, demotion to a lower class, or maintenance of the current class.
  • FIG. 17 shows an example of the schedule of the baseball game of the present embodiment including the league game and the replacement game.
  • classes 1, 3, 5, 7, and 9 are provided for league games
  • classes 2, 4, 6, and 8 are provided for replacement games.
  • the higher the class the higher the class.
  • league game # 1 which is the first league game
  • four leagues every week from Monday to Friday on weekdays
  • league game # 1 in class units
  • League game # 1 in class units. Will be determined on Friday.
  • Replacement game # 1 which is the first replacement game, has four verses every day on weekends and Sundays (for example, the same as in FIG. 14).
  • Ranking for Replacement Game # 1 is decided on Sunday.
  • the update of the class of each player ID in the replacement game # 1 following the league game # 1 is determined according to a predetermined rule based on the ranking result of the league game # 1.
  • all the player IDs of class 1 in league game # 1 and the lower half of the player IDs in class 3 ranking are class 2 in replacement game # 1.
  • the upper half of the player IDs in the class 3 ranking in the league game # 1 and the lower half of the player IDs in the class 5 ranking become the class 4 in the replacement game # 1.
  • the upper half of the player IDs in the class 5 ranking in the league game # 1 and the lower half of the player IDs in the class 7 ranking are the class 6 in the replacement game # 1.
  • the player ID of the upper half in the ranking of class 7 in league game # 1 and all player IDs of class 9 become class 8 in replacement game # 1.
  • the update of the class of each player ID in league game # 2 following replacement game # 1 is determined according to a predetermined rule based on the ranking result of replacement game # 1.
  • the lower 2/3 number of player IDs in the ranking of class 2 in replacement game # 1 is class 1 in league game # 2, and higher in the ranking of class 2 in replacement game # 1.
  • the 1/3 number of player IDs is class 3 in league # 2.
  • the lower half of the player IDs in the class 4 ranking in the replacement game # 1 is class 3 in the league battle # 2, and the upper half of the player IDs in the ranking of the class 4 in the replacement game # 1 is the league. Class 5 in Battle # 2.
  • the lower half of the player IDs in the class 6 ranking in the replacement game # 1 is class 5 in the league game # 2, and the upper half of the player IDs in the class 4 ranking in the replacement game # 1 is the league. Class 7 in Battle # 2.
  • the lower 1/3 number of player IDs in class 8 ranking in replacement game # 1 becomes class 7 in league game # 2, and the upper 2/3 number of players in class 8 ranking in replacement game # 1.
  • the ID is class 9 in league game # 2. It should be noted that the schedule or class update shown in FIG. 17 is merely an example and can be arbitrarily set.
  • FIG. 18 is a functional block diagram for explaining functions that play a major role in the game control device of the present embodiment.
  • the functional block diagram shown in FIG. 18 is different from that shown in FIG. 5 in that third battle execution means 57 and class management means 58 are added.
  • the third battle execution means 57 automatically executes a replacement battle (third battle) between player characters associated with different player IDs without triggering an operation input to the communication terminal 10, and a storage means. 52 (in this embodiment, the player database 31 of the database server 30) determines the match result of the replacement battle based on the ability value of the player character stored.
  • the replacement battle executed by the third battle execution means 57 is performed at a predetermined time (for example, a time set by a timer in the game server 20).
  • the replacement game may be set so that all player IDs participate, but it may be set so that only some of the player IDs who want to participate in the league game participate.
  • the determination method of the winning / losing of the battle executed by the third battle execution means 57 can be the same as that of the first battle execution means 53. In other words, any method can be employed as long as the ability value of the player character affects the winning or losing.
  • the third battle execution means 57 records the battle result of the replacement battle. Specifically, in the third battle execution means 57, the CPU 21 of the game server 20 accesses the database server 30a and writes the match result of the replacement battle in the replacement battle database 34 in the database server 30a.
  • the third battle execution means 57 records the player ID ranking in the replacement battle and updates it sequentially. Specifically, in the third battle execution means 57, the CPU 21 of the game server 20 accesses the replacement battle database 34 of the database server 30a, and in the past certain period of the replacement battle (for example, in the replacement battle # 1 in FIG. 17). (2 days) of the battle results are read out, and the ranking of the player IDs for each class is calculated based on the read-out battle results. Then, the CPU 21 accesses the database server 30a and writes the calculated ranking in the ranking database 33 in the database server 30a.
  • the CPU 21 of the game server 20 accesses the league match database 32 of the database server 30a to access a league match in the past for a certain period (for example, league match # 1 in FIG. 17). For 5 days), and the ranking of player IDs in class units is calculated based on the read competition results. Then, the CPU 21 accesses the database server 30a and writes the calculated ranking in the ranking database 33 in the database server 30a.
  • the class management means 58 manages each player ID in association with any one of a plurality of classes (including both league games and replacement games), and a league game for a certain period (for example, In FIG. 17, when the league match # 1 (for 5 days) and the replacement match (for example, in FIG. 17, the replacement match # 1 for 2 days) are finished, as shown in FIG. Update the class. Specifically, the CPU 21 accesses the database server 30 a and updates the data of each player ID class in the player database 31 based on the ranking result stored in the ranking database 33.
  • FIG. 19 shows an example of a web page displayed on the communication terminal 10 by interpreting the HTML data.
  • the match result of the replacement game and the result of the class update are additionally displayed in the league game result column with respect to the web page shown in FIG. 10.
  • FIG. 19 shows a case where the result of the replacement battle last week was promoted to one class with 18 wins and 6 losses, and the result of this week's replacement battle was demoted to one class after 3 wins and 7 losses.
  • (2-2) Matching Processing A matching processing (matching method) for determining opponents for a very large number of player IDs in the second battle execution means 55 of this embodiment will be described below.
  • the matching process in the 3rd battle execution means 57 of this embodiment is the same as that in the 2nd battle execution means 55 demonstrated below, duplication description is abbreviate
  • the second battle execution means 55 of the present embodiment is different from the first embodiment in that a league game is performed on a class basis.
  • FIG. 20 is a functional block diagram showing a plurality of means constituting a part of functions executed by the second battle execution means 55 of the present embodiment, and each means is executed mainly by the CPU 21.
  • the functional block diagram shown in FIG. 20 is different from that shown in FIG. 11 in that a storage unit 556 is added.
  • the accumulation unit 556 has a function of accumulating N player IDs extracted by the second extraction unit 552 and the third extraction unit 554 for each corresponding class.
  • the matching execution unit 553 of the present embodiment determines that matching for the player ID accumulated for the class is completed. It has a function to do.
  • FIG. 21 is a flowchart showing the matching process of this embodiment.
  • FIG. 22 is a diagram conceptually showing accumulation of player IDs for each class in the buffer in the matching processing of the present embodiment.
  • buffers corresponding to the league game classes 1, 3, 5, 7, and 9 are provided.
  • step S31 in FIG. 21 (corresponding to the processing of the storage means 556), each player ID extracted in step S20 in FIG.
  • step S32 YES
  • the battle execution means 555 uses a plurality of sets for the 100 player IDs of the same class that have been swept out of the buffer (that is, matching has been completed) as in the method described with reference to FIG. Every round-robin battle may be executed. Since the matching method of this embodiment is the same as that of the first embodiment in the extraction process, matching can be performed at high speed using a limited main memory, and the matching is individually performed for each class. Since it is performed using the provided buffer, matching of player IDs of different classes can be avoided even in a game configuration with a plurality of classes, thereby realizing efficient matching without wasteful processing. There is an advantage that can be.
  • FIG. 23 is a flowchart showing execution processing of a replacement battle (third battle).
  • the third battle execution means 57 is executed.
  • the third battle execution means 57 is automatically executed without triggering an operation input to the communication terminal 10 by the player.
  • the third battle execution means 55 performs a replacement battle for the player ID stored in the player database 31
  • the third battle execution means 55 performs a match matching process in the replacement battle (step S310). This matching process is as shown in the flowchart of FIG. 21 and is performed at high speed for each class even when the number of player IDs stored in the player database 31 is extremely large.
  • the third battle execution means 57 next refers to the player database 31 so that the player character's ability value affects the winning / losing based on the ability value of the player character. Then, the battle result is determined (step S320). After determining the battle result, the third battle execution means 57 records the battle result of the replacement battle in the replacement battle database 34.
  • the class management means 58 updates the class for each player ID according to a predetermined rule (step S330).
  • the class management means 58 refers to the match result of the replacement battle recorded in the replacement battle database 34, and determines a new class for each player ID according to a predetermined standard.
  • the class management means 58 records a new class for each player ID in the player database 31.
  • the notification means 56 notifies the player's communication terminal 10 corresponding to each player ID of the match result of the replacement battle and the update result of the class (step S340). In this notification, when each player selects “League Battle” on the web page illustrated in FIG. 6, for example, the communication terminal 10 displays a web page including the result of the replacement battle along with the result of the league battle. Can be done.
  • the class management means 58 manages each player ID in association with any one of a plurality of classes.
  • the association between the player ID and the class can be set from various viewpoints. For example, when the player ID is associated with the ability value of the player character on the game, each player ID may be associated with a class corresponding to the magnitude of the ability value. Alternatively, when a battle game of a plurality of stages (for example, a plurality of different battle types) corresponding to the class is set, each player ID may be associated with the stage to participate.
  • the storage means 556 corresponds to N player IDs extracted by the second extraction means 552 and the third extraction means 554 in order to perform matching of player IDs for each class. Sort and accumulate sequentially for each class. Then, when the number of player IDs accumulated for each class reaches a predetermined number for the class, the matching execution unit 553 determines that matching for the player ID accumulated for the class is completed.
  • the predetermined number for the class can be arbitrarily set, and is the same value as the value of N (the number of player IDs extracted from the player IDs on the RAM 23 (main memory)). There may be different values.
  • the matching is completed.
  • the matching can be performed in units of classes. Therefore, it is possible to avoid useless processing such as combining player IDs of different classes, and perform efficient matching.
  • the variation of the game provided by the game control apparatus can be expanded by providing a plurality of classes.
  • the communication terminal may be, for example, a game device with a communication function equipped with game software, a mobile terminal such as a so-called smartphone, a PDA (Personal Digital Assistance), or the like. That is, an online game or a social game is assumed as a battle game executed by the game control device.
  • the player ID can be registered by a relatively simple procedure. Therefore, the number of player IDs managed by the game control device is determined at the time when the operation of the game control device is started. It is difficult to predict.
  • 1 million players participate for example, 1 million player IDs are registered
  • 2 million people are registered one month after the start of operation.
  • the number of player IDs to be stored in the database server 30 of the game control device rapidly increases in a short period of time, such as a player participating (for example, registering 2 million player IDs).
  • a player participating for example, registering 2 million player IDs.
  • an increase in processing time required for matching the player IDs in the database server 30 is suppressed, so the RAM 23 corresponding to the increase in the player IDs stored in the database server 30.
  • measures such as expansion of (main memory) (for example, addition of memory) or system modification. That is, this game control device has a useful effect particularly when applied to an online game or a social game.
  • each embodiment may be variously improved and changed without departing from the gist of the present invention.
  • the battle game is progressed by a web page displayed by the web browser of the communication terminal of the player based on the provision of the web service from the game server.
  • the competitive game of this embodiment can also be configured to download or install a part of functions realized by game software on a communication terminal.
  • Each functional block described in the description of each embodiment can be realized by causing a computer to execute a program including a procedure corresponding to each function.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一定の規則に従って不揮発性メモリ内の複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して主メモリに展開する（Ｓ１０）。主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する（Ｓ２０）。抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行う（Ｓ３０）。不揮発性メモリ内の複数のプレイヤ識別情報の中から、過去に抽出されなかったＮ個のプレイヤ識別情報を上記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、マッチングが行われたＮ個のプレイヤ識別情報に代えて主メモリに展開する（Ｓ４０）。Ｓ２０、Ｓ３０、Ｓ４０の各処理を、この順番に繰り返す。

Description

ゲーム制御装置、マッチング方法、プログラム
　本発明は、複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行う技術に関する。
　従来、ゲーム用ソフトウエアを搭載した通信機能付きゲーム装置を各プレイヤが操作することで、複数のプレイヤの間でネットワークを介して実行されるオンラインゲームが知られている。
　また近年、ソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のプレイヤ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。しかしながら、ソーシャルゲームでは、上述したオンラインゲームとは異なり、ゲーム用ソフトウエアを搭載した通信機能付きゲーム装置を通してプレイヤ間でゲームを行うものではなく、プレイヤ側でゲーム用ソフトウエアのインストールあるいはダウンロードを行う必要がない。つまり、プレイヤは、ウェブブラウザが搭載された通信装置を備えていれば、ソーシャルゲームを実行できる。そのため、例えばインターネットに接続可能な携帯端末を備えていれば、プレイヤは時間と場所を問わずソーシャルゲームを楽しむことができる。
　上述したオンラインゲームあるいはソーシャルゲームでは、ネットワークに接続されたサーバにおいて、各プレイヤを個別に識別するためのプレイヤ識別情報（プレイヤＩＤ）を予め登録するようになっている。そして、対戦ゲームにおける複数のプレイヤ間におけるマッチング（対戦の組み合わせ）は、プレイヤ識別情報に基づいてサーバによって自動的に決定される。従来、複数のプレイヤ識別情報に対するマッチング方法として、特許文献１に記載されているようにトーナメント方式の自動マッチング方法、特許文献２に記載されているようにランダムに対戦相手（プレイヤＩＤ）を決定する自動マッチング方法等が知られている。
特開２００２－３５４２４号公報 特開２００１－１５７７８２号公報
　上述したオンラインゲームあるいはソーシャルゲームでは、プレイヤによって登録されたプレイヤ識別情報は、ネットワークに接続されたサーバ（ゲーム制御装置）内のＨＤＤ(Hard Disk Drive)等の不揮発性メモリに記録される。そして、サーバのプロセッサは、ＲＡＭ(Random Access Memory)等の主メモリを利用して、不揮発性メモリ内の複数のプレイヤ識別情報のマッチングを実行することになる。このとき、マッチング対象となるプレイヤ識別情報の数が、主メモリにおいて一度に処理可能なプレイヤ識別情報の数よりも遥かに多い場合には、従来のマッチング方法では、すべてのマッチングの処理を実行するのに時間が掛かる場合がある。例えば、不揮発性メモリに記録された複数のプレイヤ識別情報からランダムに、主メモリにおいて一度に処理可能な数のプレイヤ識別情報を順次抽出してマッチングを行う方法を採る場合には、抽出済みか否かを識別するためのフラグ等をプレイヤ識別情報ごとに設定して記憶するとともに、抽出の度に、不揮発性メモリ内の各プレイヤ識別情報のフラグを走査する処理が必要となって時間が掛かる。
　かかるマッチング処理における遅延は、処理対象となるプレイヤ識別情報の数が増大するほど顕著となる。
　上述したオンラインゲーム（ソーシャルゲームではなく）において、例えば特定のゲームに対して１００万個のプレイヤ識別情報が登録されていたならば、そのすべてのプレイヤ識別情報に対応したプレイヤがネットワークに同時に接続していることは通常想定し難いため、サーバにおいてマッチングの対象となるプレイヤ識別情報の数は、１００万個よりもずっと少なく、例えば数千個から数万個程度である。この場合、不揮発性メモリ内の、ネットワークに接続しているアクティブなプレイヤ識別情報を対象として、マッチング処理を行うために主メモリへプレイヤ識別情報を抽出する度に、数１０Ｋビットのデータを走査することになる。
　これに対して、上述したソーシャルゲームでは、プレイヤが複雑な操作を行う必要がなく簡易な操作のみで対戦を短時間で実行させるゲーム、さらには、このゲームと並行して、プレイヤが操作を行うことなくバックグラウンドで（つまり、サーバ側で）自動的に対戦を実行してプレイヤに対戦結果のみを通知するゲームが実行される場合がある。そのようなゲームでは、ネットワーク上のサーバに登録されたすべてのプレイヤ識別情報を対象として、プレイヤの対戦参加の意思とは無関係に自動的に対戦を実行する。その場合、例えば特定のゲームに対して１００万個のプレイヤ識別情報が登録されていたならば、１００万個のプレイヤ識別情報を対象としてマッチングを行う必要がある。このとき、マッチング処理を行うために不揮発性メモリから主メモリへプレイヤ識別情報を抽出する度に、数Ｍビットの膨大なデータを走査することになる。
　さらに、ソーシャルゲームでは、広く普及している携帯端末を用いて簡単な手続きで特定のゲームに登録することが可能であることから、ゲーム配信後に、時間が経過するにつれて登録者数が増加していき、ゲーム配信前に予測したプレイヤ識別情報の数よりもずっと多くのプレイヤ識別情報が登録される可能性がある。したがって、例えば当初１００万個のプレイヤ識別情報を予定してマッチング処理による遅延がないようにサーバの主メモリの容量を設定した場合であっても、将来的に２００～３００万個のプレイヤ識別情報のマッチングを処理する場合には、マッチング処理による遅延が許容できないレベルになることが考えられる。
　本発明は上述した観点に鑑みてなされたもので、限られた容量の主メモリを用いて、プレイヤ間の対戦のために非常に多数のプレイヤ識別情報を対象としたマッチングを行う場合に、マッチング処理による遅延を抑制することを可能とするゲーム制御装置、マッチング方法、プログラムを提供することを目的とする。
　本発明の第１の観点は、不揮発性メモリに記憶された複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行うゲーム制御装置であって、
　一定の規則に従って前記複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して主メモリに展開する第１抽出手段と、
　主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する第２抽出手段と、
　第２抽出手段によって抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行うマッチング実行手段と、
　前記複数のプレイヤ識別情報の中から、前記第１抽出手段により抽出されなかったＮ個のプレイヤ識別情報を前記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、前記マッチング実行手段によりマッチングが行われたＮ個のプレイヤ識別情報に代えて前記主メモリに展開する第３抽出手段と、
　を備え、前記第２抽出手段、マッチング手段および第３抽出手段による各処理を、この順番に繰り返してもよい。
　このゲーム制御装置は、例えば、特定多数あるいは不特定多数のプレイヤの通信装置の各々と、ネットワークを介してコネクションを確立できる情報処理装置であれば何でもよい。そのようなゲーム制御装置は、例えばネットワーク上に配置された１または複数のサーバ、あるいは大型コンピュータ装置であってよい。また、プレイヤと通信端末は必ずしも１対１で対応する固定的な関係である必要はなく、複数のプレイヤが単一の通信端末を共用する通信端末の使用形態も想定される。したがって、このゲーム制御装置は、対戦ゲームを行うプレイヤを一意に特定可能な情報として、プレイヤＩＤ等のプレイヤ識別情報ごとにプレイヤを管理してもよい。
　本発明において、「一定の規則」は、例えば昇順あるいは降順など、複数のプレイヤＩＤの各々を重複することなく順序付ける規則であれば如何なる規則でもよい。
　上記ゲーム制御装置において、前記不揮発性メモリは、各プレイヤ識別情報と、プレイヤ識別情報を基に自装置に最後にアクセスされた時刻と対応付けて記憶しており、
　前記第１抽出手段および前記第３抽出手段では、前記複数のプレイヤ識別情報の中から、現在時刻が前記最後にアクセスされた時刻から所定時間経過していないプレイヤ識別情報を抽出してもよい。
　上記ゲーム制御装置において、各プレイヤ識別情報を複数のクラスのうちのいずれかのクラスと対応付けて管理しているクラス管理手段と、
　第２抽出手段および第３抽出手段によって抽出されたそれぞれＮ個のプレイヤ識別情報を、対応するクラスごとに蓄積する蓄積手段と、を備え、
　前記マッチング実行手段は、クラスごとに蓄積されたプレイヤ識別情報の数がクラスについて予め定められた数に達した場合に、当該クラスについて蓄積されたプレイヤ識別情報についてのマッチングが完了したと判定してもよい。
　上記ゲーム制御装置において、ネットワークを介して任意の通信端末と通信を行う通信手段と、
　任意の通信端末からの対戦参加に関する登録のためのアクセスに基づいて、プレイヤ識別情報を前記不揮発性メモリに記憶させる記憶手段と、を備えてもよい。
　本発明の第２の観点は、不揮発性メモリに記憶された複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行うゲーム制御装置におけるマッチング方法であって、
　一定の規則に従って前記複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して前記ゲーム制御装置の主メモリに展開する第１のステップと、
　前記主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する第２のステップと、
　第２のステップによって抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行う第３のステップと、
　前記複数のプレイヤ識別情報の中から、前記第１のステップで抽出されなかったＮ個のプレイヤ識別情報を前記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、前記第３のステップでマッチングが行われたＮ個のプレイヤ識別情報に代えて前記主メモリに展開する第４のステップと、
　を備え、
　前記第２、第３および第４のステップを、この順番に繰り返してもよい。
　本発明の第３の観点は、不揮発性メモリに記憶された複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行うためのプログラムであって、
　一定の規則に従って前記複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して前記コンピュータの主メモリに展開する第１抽出手順と、
　前記主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する第２抽出手順と、
　第２抽出手順によって抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行うマッチング実行手順と、
　前記複数のプレイヤ識別情報の中から、前記第１抽出手順で抽出されなかったＮ個のプレイヤ識別情報を前記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、前記マッチング実行手順でマッチングが行われたＮ個のプレイヤ識別情報に代えて前記主メモリに展開する第３抽出手順と、
　前記第２抽出手順、マッチング実行手順および第３抽出手順を、この順番に繰り返す手順と、
　をコンピュータに実行させるためのプログラムであってよい。
　このプログラムは、ＤＶＤ－ＲＯＭやＣＤ－ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。
第１の実施形態のゲームシステムの基本構成を示す図。 第１の実施形態の通信端末の構成を示すブロック図。 第１の実施形態のゲームサーバの構成を示すブロック図。 第１の実施形態のデータベースサーバの構成を示すブロック図。 第１の実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 第１の実施形態の通信端末における表示例を示す図。 データベースサーバに含まれるプレイヤデータベースの構成例を示す図。 データベースサーバに含まれるリーグ戦データベースの構成例を示す図。 データベースサーバに含まれるランキングデータベースの構成例を示す図。 第１の実施形態の通信端末における表示例を示す図。 第１の実施形態のゲーム制御装置の第２の対戦実行手段の機能ブロック図。 第１の実施形態におけるマッチング処理を示すフローチャート。 第１の実施形態におけるマッチング処理を概念的に示す図。 第１の実施形態におけるマッチング処理を概念的に示す図。 第１の実施形態のマッチングを応用したリーグ戦のスケジュールの一例を示す図。 第１の実施形態における野球ゲームの主要な処理の一部を示すフローチャート。 第２の実施形態のデータベースサーバの構成を示すブロック図。 第２の実施形態の野球ゲームのスケジュールの一例を示す図。 第２の実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 第２の実施形態の通信端末における表示例を示す図。 第２の実施形態のゲーム制御装置の第２の対戦実行手段の機能ブロック図。 第２の実施形態におけるマッチング処理を示すフローチャート。 第２の実施形態におけるマッチング処理の一部を概念的に示す図。 第２の実施形態における野球ゲームの主要な処理の一部を示すフローチャート。
　この出願は、２０１１年５月２７日に出願された日本国における先の出願である特願２０１１－１１８９２４号に基づいており、かつその出願の優先権の利益を主張するものであり、当該出願全体は参照によってここに組み込まれる。
　（１）第１の実施形態
　（１－１）ゲームシステムの構成
　図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷに接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のプレイヤによって操作される端末であり、例えば、携帯端末、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータなどの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。このゲームシステムでは、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションがゲームサーバ２０に実装されている。通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、プレイヤは、通信端末１０をウェブページ上で操作してゲームを実行する。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
　なお、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のプレイヤを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
　（１－２）通信端末の構成
　図２を参照して通信端末１０の構成について説明する。
　図２に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、操作入力部１５、表示部１６、および、無線通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。
　ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、操作入力部１５等によってプレイヤに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、無線通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を無線通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
　なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたプレイヤＩＤ（プレイヤ識別情報）、あるいは操作入力部１５を介して入力されるプレイヤＩＤを含むアクセス要求メッセージを、無線通信インタフェース部１７を介してゲームサーバ２０へ通知する。
　ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、プレイヤが操作入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはオブジェクトが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信をゲームサーバ２０へ要求する。
　画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示する。
　操作入力部１５は、プレイヤの操作入力を受け入れるための複数の釦と、各釦の押下入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含みうるが、図２では、方向指示釦と決定釦とを例示している。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはオブジェクトが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはオブジェクトをプレイヤが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、プレイヤが通信端末１０を片手で保持したままその親指で操作しやすいように、通信端末１０の前面に配置されていることが好ましい。
　（１－３）ゲームサーバの構成
　図３を参照してゲームサーバ２０の構成について説明する。
　ゲームサーバ２０は、例えば階層構造の複数のウェブページからなる対戦ゲームのウェブサイトを管理しており、通信端末１０に対して対戦ゲームのウェブサービスを提供する。図３に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、および、通信インタフェース部２５（通信手段の一例）を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
　ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラム（本実施形態のプログラム）が格納されている。
　ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。
　例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のプレイヤの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
　ＣＰＵ２１は、通信インタフェース部を介して、通信端末１０で表示されるウェブページ上でプレイヤにより選択されたハイパーリンクまたはオブジェクトに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
　データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。
　（１－４）データベースサーバの構成
　データベースサーバ３０は不揮発性メモリの一実施形態であり、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
　図４に、データベースサーバ３０の構成の一例を示す。図４に示す例は、後述する対戦ゲームを実現するためのデータベースの一例であり、データベースサーバ３０は、プレイヤデータベース３１と、リーグ戦データベース３２と、ランキングデータベース３３とを備える。これらのデータベースの内容は後述する。
　（１－５）ゲーム制御装置における各機能の概要
　本実施形態では、ゲームサーバ２０およびデータベースサーバ３０によって本発明のゲーム制御装置が構成されている。このゲーム制御装置によって実行されるゲームは、野球、サッカー等のスポーツを模擬したもの、あるいは戦闘を模擬したものなど、プレイヤ間の対戦要素が含まれたゲーム（対戦ゲーム）であれば如何なる形式のものでも構わない。以下では、対戦ゲームの一例として野球ゲームが本実施形態のゲーム制御装置によって実行される場合のゲーム制御装置で実現される機能について、図５を参照して説明する。図５は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
　本実施形態の野球ゲームでは、２つの対戦が進行するように構成されている。１つは、プレイヤによる通信端末１０の操作入力を契機として、異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間で行われる個別対戦（第１の対戦）である。もう１つは、プレイヤによる通信端末１０に対する操作入力を契機とせずに自動的に、異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間で行われるリーグ戦（第２の対戦）である。
　なお、以下の説明において、「異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間での対戦」と「プレイヤＩＤ間の対戦」とは同義である。
　ゲーム進行手段５１は、プレイヤによる通信端末１０に対する操作に応じた通信端末１０におけるウェブページを通して、プレイヤの通信端末１０で表示されるゲームを進行させる機能を備える。例えば、ゲーム進行手段５１では、ＣＰＵ２１は、プレイヤによるウェブページ上のハイパーリンクまたはオブジェクトの選択に応じたウェブページを表示するためのＨＴＭＬデータを、通信インタフェース部２５を介して通信端末１０宛に送信する。ＣＰＵ２１は、プレイヤによるウェブページ上のハイパーリンクまたはオブジェクトの選択に応じて新たなＨＴＭＬデータを逐次送信し、これにより、通信端末１０で表示されるウェブページが逐次切り替わることで、プレイヤがゲームの進行を認識する。
　また、ゲーム進行手段５１では、ゲームサーバ２０のＣＰＵ２１が、ゲームの開始に先立って、通信インタフェース部２５を介して通信端末１０からアクセス要求メッセージを受けると、所定の認証処理の後、その通信端末１０からアクセス要求メッセージに含まれるプレイヤＩＤを認識する。そして、ゲームサーバ２０のＣＰＵ２１は、各通信端末１０に表示されるゲームの進行を、プレイヤＩＤ単位で管理する。このプレイヤＩＤは、例えば、プレイヤが通信端末１０を通してゲームサーバ２０が提供する野球ゲームのウェブサイトにアクセスし、所定の手続きを経た後に付与（登録）されてよい。
　図６は、ゲーム進行手段５１によって通信端末１０に表示されるウェブページの一例である。図６に示すウェブページは、プレイヤが通信端末１０を通してゲームサーバ２０が提供する野球ゲームのウェブサイトにアクセスしたときに表示されるウェブページであって、この野球ゲームのメインメニューに相当する。図６に示すウェブページでは、例えば、「スカウト」、「オーダー」、「強化」、「抽選」、「試合」、「リーグ戦」のテキストが、ハイパーリンクが付される状態で所定の領域（オブジェクト）内に表示される。このとき、プレイヤが通信端末１０の操作入力部１５の方向指示釦および決定釦の操作によって、このいずれかの文字を選択すると、ゲーム進行手段５１では、ＣＰＵ２１が通信インタフェース部２５を介してプレイヤによる選択結果を認識して、新たなＨＴＭＬデータを通信端末１０宛に送信する。その結果、通信端末１０の表示部１６には、プレイヤの選択結果に応じた新たなウェブページを表示する。
　記憶手段５２は、各プレイヤＩＤに対応付けてプレイヤキャラクタの能力値を記憶する機能を備える。本実施形態では、記憶手段５２は、データベースサーバ３０のプレイヤデータベース３１により実現される。
　図７は、本実施形態の野球ゲームにおけるプレイヤデータベース３１の一例である。この例では、プレイヤデータベース３１には、プレイヤＩＤごとに、プレイヤＩＤに対応付けられた複数のプレイヤキャラクタの各々の項目ごとの能力値のデータが含まれる。図７の例では、能力値は０～１０００の範囲の値であって、能力値が大きい値であるほど能力が高いことを示している。図７では、選手Ａについて、打力が３００であり、走力が４５０であり、守備力が８１０である場合が例として示されている。図７では、能力の指標としての項目として、「打力」，「走力」，「守備力」を例示しているが、選手が投手であれば別の項目、例えば「球速」，「制球力」，「スタミナ」等としてもよい。
　なお、プレイヤがプレイヤＩＤを取得した時点では、プレイヤＩＤに対応付けられたプレイヤキャラクタの能力値がデフォルトの値として設定される。つまり、ゲームサーバ２０のＣＰＵ２１が、プレイヤデータベース３１にアクセスして、プレイヤＩＤに対応したプレイヤキャラクタの能力値のデフォルトのデータを書き込み、プレイヤデータベース３１がこの能力値のデフォルトのデータを記憶する。
　また、図７に示すように、プレイヤデータベース３１には、各プレイヤＩＤと、プレイヤＩＤを基にゲームサーバ２０に最後にアクセスされた時刻（図７では、「最終アクセス日時」に相当する。）と対応付けて記憶してもよい。この場合、ゲームサーバ２０において、ゲームサーバ２０にアクセスされた時刻がプレイヤＩＤごとに保持されており、ゲームサーバ２０はアクセスの度に、プレイヤＩＤとアクセスされた時刻をデータベースサーバ３０に通知し、最終アクセス日時が逐次更新される。
　第１の対戦実行手段５３は、通信端末１０に対する操作入力を契機として、異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間の個別対戦（第１の対戦）を実行し、記憶手段５２（本実施形態では、データベースサーバ３０のプレイヤデータベース３１）が記憶するプレイヤキャラクタの能力値に基づいて個別対戦の対戦結果を決定する。
　この第１の対戦実行手段５３では先ず、ゲームサーバ２０のＣＰＵ２１が、プレイヤによる通信端末１０の操作入力部１５に対する操作入力に基づいて個別対戦を行う対戦相手を決定する。例えば、図６に例示するウェブページ上でプレイヤにより「試合」というテキストを含むオブジェクトを選択する操作が行われると、その選択結果がゲームサーバ２０のＣＰＵ２１宛に送信される。そしてＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のプレイヤデータベース３１にアクセスし、例えばランダムに、対戦相手となるプレイヤＩＤを選択する。あるいは、ＣＰＵ２１は、ランダムに選択した複数のプレイヤＩＤについて、プレイヤによる対戦相手となるプレイヤＩＤの選択の確定のため、その複数のプレイヤＩＤと、対応するプレイヤキャラクタの能力値とを表示するためのＨＴＭＬデータを、プレイヤの通信端末１０宛に送信してもよい。対戦相手が確定すると、ＣＰＵ２１は、対戦する２つのプレイヤＩＤに対応付けられたプレイヤキャラクタ間の個別対戦を実行する。
　個別対戦の勝敗の決定方法は、プレイヤキャラクタの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦相手となる２つのプレイヤＩＤに対応付けられたプレイヤキャラクタの能力値を比較し、より大きな能力値のプレイヤキャラクタが、高い確率（例えば、６０～９０％の範囲内の所定の確率）をもって勝利するように設定してよい。この勝率は、能力値の差が大きいほど高い確率としてもよい。このとき、図７に示したように、比較対象となる能力値の項目が複数存在する場合には、所定の重み付け（例えば、図７の例では、「打力」を０．４、「走力」を０．２、「守備力」を０．４の重み付けにする等）をもって総合的な能力値を設定することができる。
　第１の対戦実行手段５３において、ゲームサーバ２０のＣＰＵ２１は、対戦相手となる２つのプレイヤＩＤに対応付けられたプレイヤキャラクタの個別対戦の対戦結果を決定すると、その対戦結果を含むウェブページを表示させるためのＨＴＭＬデータを、対戦相手となる２つのプレイヤＩＤのプレイヤの通信端末１０宛に送信する。そして、通信端末１０は、ゲームサーバ２０から受信したＨＴＭＬデータを解釈して対戦結果を表示部１６に表示する。なお、図６に例示するウェブページ上でプレイヤにより「試合」というテキストを含むオブジェクトを選択する操作が行われてから対戦結果が表示されるまでの時間は、極めて短時間（例えば数秒）であり、プレイヤは、簡易な操作のみで極めて短期間で対戦結果を知ることができる。
　キャラクタ能力更新手段５４は、個別対戦（第１の対戦）の対戦結果に基づいて、プレイヤＩＤに対応するプレイヤキャラクタの能力値を更新する機能を備えている。
　キャラクタ能力更新手段５４では、ゲームサーバ２０のＣＰＵ２１が、異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間の個別対戦の対戦結果に基づいて、データベースサーバ３０のプレイヤデータベース３１にアクセスして、そのプレイヤＩＤに対応付けられたプレイヤキャラクタの能力値を更新する。つまり、ＣＰＵ２１は、プレイヤデータベース３１に対して新たな能力値の書き込みを行う。
　キャラクタ能力更新手段５４において、プレイヤキャラクタの能力値は、プレイヤＩＤに対応するプレイヤキャラクタが個別対戦で勝利した場合に、現在の値よりも大きくなるように更新されることが好ましい。一方、プレイヤキャラクタの能力値は、プレイヤＩＤに対応するプレイヤキャラクタが個別対戦で敗北した場合に、現在の値よりも小さくなるように更新されることが好ましい。なお、能力値の変化量は任意に設定しうる。例えば、図７に示したように能力値の項目が複数存在する場合、すべてのプレイヤキャラクタの能力値に対し、同一の値だけ大きく、あるいは小さくするようにしてよい。あるいは、能力値の変化量はランダムに設定してもよい。
　第２の対戦実行手段５５は、通信端末１０に対する操作入力を契機とせずに自動的に、異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間のリーグ戦（第２の対戦）を実行し、記憶手段５２（本実施形態では、データベースサーバ３０のプレイヤデータベース３１）が記憶するプレイヤキャラクタの能力値に基づいてリーグ戦の対戦結果を決定する。
　この第２の対戦実行手段５５により実行されるリーグ戦は、所定の時刻（例えば、ゲームサーバ２０内のタイマで設定される時刻）に行われる。リーグ戦は、すべてのプレイヤＩＤが参加（あるいは登録）するように設定してもよいが、リーグ戦の参加を希望する一部のプレイヤＩＤのみが参加するように設定してもよい。
　第２の対戦実行手段５５によって実行される対戦の勝敗の決定方法は、第１の対戦実行手段５３と同様とすることができる。つまり、プレイヤキャラクタの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。
　なお、リーグ戦のすべての対戦結果を決定するには一定の時間が掛かり、その時間内においても個別対戦の実行に応じてプレイヤキャラクタの能力値が更新されうる。したがって、リーグ戦の開始時刻においてプレイヤデータベース３１のコピーデータを作成し、第２の対戦実行手段５５の実行中は、そのコピーデータ内のプレイヤキャラクタの能力値を参照するようにする。これにより、第２の対戦実行手段５５の実行中においてもキャラクタ能力更新手段５４によってプレイヤキャラクタの能力値（プレイヤデータベース３１そのもののデータ）を更新し続けることができる。
　第２の対戦実行手段５５は、少なくとも過去の一定期間のリーグ戦の対戦結果を記録する。具体的には、第２の対戦実行手段５５では、ゲームサーバ２０のＣＰＵ２１がデータベースサーバ３０にアクセスし、データベースサーバ３０内のリーグ戦データベース３２にリーグ戦の対戦結果を書き込む。
　ここで、リーグ戦データベース３２の一例を図８に示す。図８に示す例では、リーグ戦が毎日実行される場合に、日付ごとにリーグ戦の対戦結果が記録されている。図１２の例では、リーグ戦の対戦結果には、対戦を特定するための対戦ＩＤ、勝利したプレイヤキャラクタに対応したプレイヤＩＤ（勝利したプレイヤＩＤ）、敗北したプレイヤキャラクタに対応したプレイヤＩＤ（敗北したプレイヤＩＤ）、スコア、その他のデータ（例えば、勝利投手に相当するプレイヤキャラクタのデータ等）が含まれている。
　第２の対戦実行手段５５では、リーグ戦におけるプレイヤＩＤのランキングを記録するとともに逐次更新する。具体的には、第２の対戦実行手段５５は、ゲームサーバ２０のＣＰＵ２１がデータベースサーバ３０のリーグ戦データベース３２にアクセスしてリーグ戦の過去の一定期間の対戦結果を読み出し、その読み出した対戦結果に基づいてプレイヤＩＤ単位でのランキングを算出する。そして、ＣＰＵ２１は、データベースサーバ３０にアクセスし、データベースサーバ３０内のランキングデータベース３３に、算出したランキングを書き込む。
　ここで、ランキングデータベース３３の一例を図９に示す。図９に示す例では、プレイヤＩＤのランキングが１番から順に記録されているとともに、プレイヤＩＤごとにリーグ戦における勝数、負数、引き分け数が記録されている。
　通知手段５６は、過去の所定期間あるいは所定回数の１または複数のリーグ戦（第２の対戦）の対戦結果、および／または、当該対戦結果に基づくプレイヤＩＤごとのランキング（順位）を、プレイヤの通信端末１０宛に通知する。
　通知手段５６では、ゲームサーバ２０のＣＰＵ２１が、例えば図６に示すウェブページで「リーグ戦」が選択されたことを認識した場合に、直近のリーグ戦における対戦結果、および／または、過去の所定期間あるいは所定回数の１または複数のリーグ戦の対戦結果に基づくプレイヤＩＤごとの順位を含むウェブページを各プレイヤの通信端末１０に表示するためのＨＴＭＬデータを、通信端末１０宛に送信する。このＨＴＭＬデータを解釈して通信端末１０で表示されるウェブページの例を図１０に示す。図１０に示すウェブページの例では、プレイヤＩＤに対応したリーグ戦の結果（例えば、４５勝１５敗等の勝敗結果や、６５７３位等のランキング）が表示されている。図１０に例示するウェブページでは、リーグ戦における複数の節の各々（第４節、第５節、第６節）についての情報が例えば通信端末１０の操作入力部１５の方向指示釦等でスクロール表示される例が示されている。図１０は、例えば第５節のリーグ戦が行われている特定の日付における表示例であり、下から順に、第４節の対戦結果、第５節の対戦結果、第６節の対戦予定、現在のリーグ戦における総合的な勝敗結果およびランキングが示されている。
　（１－６）マッチング処理
　前述した第２の対戦実行手段５５により実行されるリーグ戦では、プレイヤデータベース３１に記憶される非常に多数のプレイヤＩＤを対象としているが、その非常に多数のプレイヤＩＤを対象として対戦相手を決定するためのマッチング処理（マッチング方法）について、以下説明する。
　図１１は、第２の対戦実行手段５５で実行される機能の一部を構成する複数の手段を示す機能ブロック図であり、各手段はＣＰＵ２１を主体として実行される。
　第１抽出手段５５１は、一定の規則に従って、プレイヤデータベース３１に記憶されているプレイヤＩＤの中からＭ個のプレイヤＩＤを抽出してＲＡＭ２３（主メモリ）に展開する機能を備えている。第２抽出手段５５２は、ＲＡＭ２３上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤＩＤをランダムに抽出する機能を備えている。マッチング実行手段５５３は、第２抽出手段５５２によって抽出されたＮ個のプレイヤＩＤを対象としてマッチングを行う機能を備えている。
　第３抽出手段５５４は、プレイヤデータベース３１に記憶されているプレイヤＩＤの中から、第１抽出手段５５１により抽出されなかったＮ個のプレイヤＩＤを上記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤＩＤを、マッチング実行手段５５３によりマッチングが行われたＮ個のプレイヤＩＤに代えてＲＡＭ２３に展開する機能を備えている。
　また、第２の対戦実行手段５５では、第２抽出手段５５２、マッチング実行手段５５３および第３抽出手段５５４による各処理を、この順番に繰り返す機能を備えている。
　対戦実行手段５５５は、マッチング実行手段５５３により得られたプレイヤＩＤのマッチング結果に基づいて、プレイヤＩＤに対応付けられたプレイヤキャラクタ間のリーグ戦（第２の対戦）を実行する機能を備えている。
　次に、図１２、図１３Ａ及び図１３Ｂを参照して、第２の対戦実行手段５５で実行されるマッチング処理について、より具体的に説明する。図１２は、本実施形態のマッチング処理を示すフローチャートである。図１３Ａ及び図１３Ｂは、本実施形態のマッチング処理について、その処理の様子を概念的に説明するための図である。図１３Ａ及び図１３Ｂでは、図１２の各ステップと対比可能なように、同一のステップ符号を用いている。
　なお、図１２のステップＳ１０，Ｓ２０，Ｓ３０，Ｓ４０はそれぞれ、第１抽出手段５５１、第２抽出手段５５２、マッチング実行手段５５３、第３抽出手段５５４に対応する。
　図１２、図１３Ａ及び図１３Ｂでは、プレイヤデータベース３１に記憶されているプレイヤＩＤの数を１００万個、上記Ｍ＝１万、Ｎ＝１００とし、プレイヤＩＤとして数字が割り当てられている場合を例としている。
　図１２において先ず、ＣＰＵ２１は、プレイヤＩＤの昇順に従って、プレイヤデータベース３１（プレイヤＤＢ３１）に記憶されているプレイヤＩＤの中から１万個（Ｍ個）のプレイヤＩＤを抽出してＲＡＭ２３（主メモリ）に展開する（ステップＳ１０）。ここでは、プレイヤデータベース３１からプレイヤＩＤを抽出するに当たっての一定の規則が、プレイヤＩＤが示す番号の昇順に従うものとする。ここで、ステップＳ１０において、プレイヤＩＤ：１～１００が抽出されたならば、プレイヤデータベース３１からの次の抽出の開始となるプレイヤＩＤ（この場合、１０１）をＲＡＭ２３に記憶させておく。
　次に、ＣＰＵ２１は、ＲＡＭ２３上の１万個（Ｍ個）のプレイヤ識別情報の中から１００個（Ｎ個）のプレイヤＩＤをランダムに抽出し（ステップＳ２０）、その抽出された１００個のプレイヤＩＤを対象としてマッチングを行う（ステップＳ３０）。１００個のプレイヤＩＤを対象としたマッチングの一例については、以下のとおりである。１００個のプレイヤＩＤを２５組（各組で４個のプレイヤＩＤ）にランダムに分類し、各組で総当り戦を行うようにする。この場合、各組の４個のプレイヤＩＤをＡ，Ｂ，Ｃ，Ｄとした場合には、Ａ×Ｂ，Ａ×Ｃ，Ａ×Ｄ，Ｂ×Ｃ，Ｂ×Ｄ，Ｃ×Ｄの６試合のマッチング（各プレイヤＩＤ単位では３試合ずつ）が各組でなされることになる。
　次に、ＣＰＵ２１は、プレイヤデータベース３１において未抽出のプレイヤＩＤが有るか否かを判定する（ステップＳ３５）。その結果、未抽出のプレイヤＩＤが有る場合には、ＣＰＵ２１は、プレイヤデータベース３１に記憶されているプレイヤＩＤの中から、ステップＳ１０において抽出されなかった１００個のプレイヤＩＤをその昇順に従って新たに抽出し、その新たに抽出した１００個のプレイヤＩＤを、ステップＳ３０でマッチングが行われた１００個のプレイヤＩＤに代えてＲＡＭ２３に展開する（ステップＳ４０）。最初にステップＳ４０を実行するときには、ステップＳ１０で記憶しておいたプレイヤＩＤ：１０１から昇順にプレイヤＩＤの抽出を行うことになる。新たに１００個のプレイヤＩＤを抽出してＲＡＭ２３に展開した後は、ステップＳ２０へ戻る。
　その後、ステップＳ２０，Ｓ３０，Ｓ４０の処理は、この順番で、プレイヤデータベース３１内に未抽出のプレイヤＩＤが無くなるまで繰り返される。図１３Ａを参照すると、１回目のステップＳ２０，Ｓ３０の処理をそれぞれ、Ｓ２０（＃１），Ｓ３０（＃１）で示し、２回目のステップＳ２０，Ｓ３０の処理をそれぞれ、Ｓ２０（＃２），Ｓ３０（＃２）で示してある。図１３Ａに示すように、プレイヤデータベース３１に記憶されている１００万個のプレイヤＩＤの中から、ステップＳ１０で１万個のプレイヤＩＤが抽出された後は、Ｓ２０～４０を順次繰返していく。これにより、プレイヤデータベース３１に記憶されているプレイヤＩＤから未抽出のプレイヤＩＤが徐々に少なくなっていくことになる。
　プレイヤデータベース３１内に未抽出のプレイヤＩＤが無くなると、ステップＳ３５からステップＳ５０へ進み、ステップＳ２０，Ｓ３０の処理がこの順番で繰り返される。これは、プレイヤデータベース３１から新たに抽出すべきプレイヤＩＤは存在しないが、ＲＡＭ２３内のプレイヤＩＤ（最大：１万個）について順にマッチングを行っている状態である。このとき、図１３Ｂに示すように、ＲＡＭ２３内に展開されている複数のプレイヤＩＤのうち、ｎ回目のステップＳ２０，Ｓ３０の処理であるＳ２０（＃ｎ），Ｓ３０（＃ｎ）、その次のｎ＋１回目のステップＳ２０，Ｓ３０の処理であるＳ２０（＃ｎ＋１），Ｓ３０（＃ｎ＋１）…、というように進むにつれて、マッチングが行われていないプレイヤＩＤの数が徐々に減少していく。そして、プレイヤデータベース３１から抽出されたすべてのプレイヤＩＤのマッチングが完了すると（ステップＳ５０：ＹＥＳ）、全体のマッチング処理が終了することになる。
　図１２に示したマッチング処理において、繰返し実行されるステップＳ４０では、１００万個のプレイヤＩＤを記憶しているプレイヤデータベース３１からの抽出を、プレイヤＩＤの昇順に従って順次行うことになるため、１００個のプレイヤＩＤの抽出の度に、新たに抽出を開始するプレイヤＩＤのみを記憶しておくことで、ステップＳ４０における毎回の抽出を高速に行うことができる。ここでは一例として、プレイヤデータベース３１に記憶しているプレイヤＩＤの数を１００万個、Ｍを１万、Ｎを１００としたので、ステップＳ４０における抽出回数は、（１００万－１万）／１００＝９９００回と多くなるが、この各回における抽出開始のプレイヤＩＤが直ちに分かり、抽出方法もプレイヤＩＤの昇順に従っているため、各回の抽出処理を高速で完了させることができる。結果として、図１２に示すマッチング処理によれば、非常に多くのプレイヤＩＤを対象とするマッチングを、限られた容量のＲＡＭ２３を用いて高速で実行することができる。
　また、このマッチング処理では、プレイヤデータベース３１からプレイヤＩＤの抽出を行うステップＳ１０あるいはステップＳ４０において、プレイヤＩＤの昇順に従って順次プレイヤＩＤを抽出しており、抽出済みか否かを識別するようなデータをプレイヤＩＤごとに走査するような処理は必要ない。そのため、プレイヤデータベース３１内のプレイヤＩＤの数が、ゲームサーバ２０の運用の途中で増大した場合であっても、プレイヤデータベース３１内のプレイヤＩＤのマッチングに要する処理時間の増加が抑制される。そのため、プレイヤデータベース３１に記憶されたプレイヤＩＤの増大に応じたＲＡＭ２３の拡張（例えば、メモリの増設）あるいはシステム改変等の対応を回避することができる。
　なお、図７に例示したように、プレイヤデータベース３１では、各プレイヤＩＤと、プレイヤＩＤを基にゲームサーバ２０に最後にアクセスされた時刻（最終アクセス日時）とを対応付けて記憶するようにしてもよい。この場合、ステップＳ１０及びステップＳ４０では、プレイヤデータベース３１内のプレイヤＩＤの中から、現在時刻が最終アクセス日時から所定時間経過していないプレイヤＩＤを抽出することが好ましい。つまり、プレイヤデータベース３１に記憶されているすべてのプレイヤＩＤを抽出対象とするのではなく、最終アクセス日時を基準として抽出対象となるプレイヤＩＤのフィルタリングを行う。このようにすることで、プレイヤＩＤをゲームサーバ２０に登録したものの一定時間アクセスしていないプレイヤＩＤ（つまり、登録されているが使用されていないプレイヤＩＤ）を抽出対象から排除する。これにより、抽出対象となるプレイヤＩＤの数が限定されるため、マッチングに要する時間がさらに短縮する。
　現在時刻が最終アクセス日時から所定時間経過していないプレイヤＩＤを抽出することが好ましい理由についてさらに説明すると、以下のとおりである。すなわち、最後にアクセスされた時刻から現在時刻が所定時間経過しているプレイヤＩＤのプレイヤは、現在時刻を基準として一定期間の間、ゲーム制御装置にアクセスしておらず、実質的にゲームに参加していないと考えられる。例えば、ソーシャルゲームあるいはオンラインゲームでは、比較的簡易な手続きでプレイヤＩＤを登録することができるため、ゲーム制御装置で管理するプレイヤＩＤの数は増加しやすいが、それらに該当するプレイヤが登録後に継続的にゲームに参加するとは限らない。実際には、ゲーム制御装置のデータベースサーバ３０（不揮発性メモリ）に記憶されている複数のプレイヤＩＤの中で、全くアクセスしていないプレイヤＩＤがある程度の割合で存在する。そこで、現在時刻が最後にアクセスされた時刻から所定時間経過していないプレイヤＩＤのみを抽出することで、実質的にゲームに参加していないプレイヤＩＤを抽出対象から排除する。これにより、抽出対象となるプレイヤＩＤの数が限定されるため、マッチングに要する時間がさらに短縮する。なお、排除された識別情報に該当するプレイヤは実質的にゲームに参加していないので（すなわち、ゲームにアクセスもしていないので）、例えば通常のゲームのバックグラウンドで自動的に実行される対戦への参加が行なわれなかったとしても、それを知ることもなく問題は生じない。但し、長期間アクセスしなかった後に再アクセスする場合を想定して、例えば、「所定期間以上（例えば２週間以上）のアクセスが無かったために、対戦が行なわれなかった」という旨のメッセージを流すようにしてもよい。この場合、ゲームへのアクセスを継続的に行なわないと、対戦が実行されないということをプレイヤが認識できるので、ゲーム継続への動機付けを与えることができる。
　上記説明において、１００個のプレイヤＩＤを対象としたマッチングの一例として、１００個のプレイヤＩＤを２５組（各組で４個のプレイヤＩＤ）にランダムに分類し、各組で総当り戦を行う例を説明したが、このようなマッチングを応用したリーグ戦のスケジュールの一例を図１４に示す。図１４では、１週間のうち平日の定刻（図１４の例では、９時、１４時、１９時、２５時）にそれぞれ、第１節、第２節、第３節、第４節のリーグ戦が行われるようにスケジューリングされている。各節のリーグ戦では、その都度、図１２に示したマッチング処理が行われ、各節では組ごとに総当りの６試合（各組に含まれる個々のプレイヤＩＤにとっては３試合）が行われる。その結果、平日の一日では、各プレイヤＩＤは、各節３試合×４節の計１２試合が行われることになる。この場合、第２の対戦実行手段５５は、各節が終了する度に、リーグ戦におけるプレイヤＩＤのランキングを算出して、データベースサーバ３０内のランキングデータベース３３に、算出したランキングを書き込むようにしてよい。
　なお、以上の説明では、Ｍ＝１万の場合を例としたが、Ｍの数は、予め本実施形態のゲームサーバ２０に設定されるＲＡＭ２３の容量に応じて適宜設定すればよいのは言うまでもない。また、以上の説明では、Ｎ＝１００を例とし、１００個のプレイヤＩＤを対象としてマッチングを行うこととしたが、ステップＳ２０で抽出されるプレイヤＩＤの数、ステップＳ４０で抽出されるプレイヤＩＤの数は、マッチング対象となるプレイヤＩＤの数に応じて適宜変更してよい。例えば、Ｎ＝５０とした場合に、マッチング対象となるプレイヤＩＤを、各組５個のプレイヤＩＤからなる１０組に分類し、総当り戦をスケジューリングしてもよい。Ｎ＝２００とした場合に、マッチング対象となるプレイヤＩＤを、１組２個のプレイヤＩＤからなる１００組に分類し、単一の対戦を適切なタイミングでスケジューリングしてもよい。すなわち、マッチング対象となる数が定まれば、その数に応じて任意に対戦計画が設定されうる。
　（１－７）野球ゲームの主要な処理のフロー
　次に、本実施形態における野球ゲームのリーグ戦における主要な処理フローの一例について、図１５のフローチャートを参照して説明する。図１５は、リーグ戦（第２の対戦）の実行処理を示すフローチャートである。
　図１５において、例えば図１４に示したように各節のリーグ戦が行われる定刻になると（ステップＳ２００のＹＥＳ）、第２の対戦実行手段５５が実行される。この第２の対戦実行手段５５は、プレイヤによる通信端末１０に対する操作入力を契機とせずに自動的に実行される。第２の対戦実行手段５５は、プレイヤデータベース３１に記憶されているプレイヤＩＤを対象として例えば第１節のリーグ戦を行う場合、その第１節のリーグ戦における対戦のマッチングの処理を行う（ステップＳ２１０）。このマッチングの処理は、図１２のフローチャートに示したとおりであり、プレイヤデータベース３１に記憶されているプレイヤＩＤの数が極めて多い場合であっても高速に行われる。
　マッチングの処理が完了すると、第２の対戦実行手段５５は次にプレイヤデータベース３１を参照し、プレイヤキャラクタの能力値に基づいて、つまり、プレイヤキャラクタの能力値の差が勝敗に影響を与えるようにして、対戦結果を決定する（ステップＳ２２０）。第２の対戦実行手段５５は、対戦結果を決定した後、その第１節のリーグ戦の対戦結果をリーグ戦データベース３２に記録するとともに、第１節のリーグ戦の対戦結果に基づくプレイヤＩＤのランキングをランキングデータベース３３に記録する（ステップＳ２３０）。その後、通知手段５６は、リーグ戦に参加している各プレイヤＩＤに対応するプレイヤの通信端末１０宛に、第１節の対戦結果と、第１節が終了した時点におけるプレイヤＩＤのランキングを通知する（ステップＳ２４０）。なお、この通知は、各プレイヤが例えば図６に例示したウェブページで「リーグ戦」が選択された場合に、通信端末１０において、第１節の対戦結果と、第１節が終了した時点におけるプレイヤＩＤのランキングとを含むウェブページが表示されるようにして行うことができる。
　第２節以降についても同様にして、ステップＳ２００～Ｓ２４０の処理が再度行われる。
　本実施形態のゲーム制御装置におけるマッチング処理の作用効果については、以下のとおりである。
　本実施形態のゲーム制御装置において、第１抽出手段５５１は、一定の規則に従って複数のプレイヤＩＤの中からＭ個のプレイヤＩＤを抽出して主メモリに展開する。ここで、「一定の規則」は、例えば昇順あるいは降順など、複数のプレイヤＩＤの各々を重複することなく順序付ける規則であれば如何なる規則でもよい。この第１抽出手段５５１では、一定の規則に従ってプレイヤＩＤが抽出されるため、データベースサーバ３０（不揮発性メモリ）に記憶された複数のプレイヤＩＤの各々を、例えばフラグ等、抽出済みか否かを識別するデータと関連付ける必要がない。例えば、最後に抽出されたプレイヤＩＤのみ（あるいは、新たに抽出を開始するプレイヤＩＤのみ）を一時的に記憶しておけば足りる。なお、抽出するプレイヤＩＤの数（Ｍ）は、主メモリの容量に応じた任意の値に設定することができ、データベースサーバ３０に記憶されているプレイヤＩＤの数を１００～２００万個とすれば、例えば、Ｍは１万程度でよい。
　このゲーム制御装置において、第２抽出手段５５２は、ＲＡＭ２３（主メモリ）上のプレイヤＩＤの中からＮ個（Ｎ＜Ｍ）のプレイヤＩＤをランダムに抽出する。マッチング実行手段５５３は、第２抽出手段５５２によって抽出されたＮ個のプレイヤＩＤを対象としてマッチングを行う。上記Ｎは、Ｎ＜Ｍを満たす限り任意の値に設定することができるが、ＭがＮの整数倍となることが好ましい。例えば、Ｍ＝１万とした場合には、Ｎ＝１００としてよい。この場合、１万個のプレイヤＩＤからランダムに抽出された１００個のプレイヤＩＤを対象としてマッチングが実行される。
　このゲーム制御装置において、第３抽出手段５５４は、複数のプレイヤＩＤの中から、第１抽出手段５５１により抽出されなかったＮ個のプレイヤＩＤを上記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤＩＤを、マッチング実行手段５５３によりマッチングが行われたＮ個のプレイヤＩＤに代えてＲＡＭ２３に展開する。つまり、既にマッチング済みのＮ個のプレイヤＩＤはＲＡＭ２３から除去され、代わりにデータベースサーバ３０から新たなＮ個のプレイヤＩＤを抽出してＲＡＭ２３に展開する。ここで、データベースサーバ３０からの抽出は、第１抽出手段５５１で最後に抽出されたプレイヤＩＤを基準として、第１抽出手段５５１と同様に一定の規則に従って順次行われる。
　このゲーム制御装置では、いったん第１抽出手段５５１が実行された後は、第２抽出手段５５２、マッチング手段および第３抽出手段５５４による各処理を、この順番に繰り返す。これにより、Ｎ個ずつのプレイヤＩＤのマッチングが順に実行され、Ｎ個のプレイヤＩＤのマッチングが完了する度に、新たなＮ個のプレイヤＩＤが、データベースサーバ３０に記憶されている複数のプレイヤＩＤから抽出されていく。
　このとき、第３抽出手段５５４では、多数のプレイヤＩＤを含むデータベースサーバ３０からの抽出を、上記一定の規則に従って順次行うことになるため、Ｎ個のプレイヤＩＤの抽出の度に、最後に抽出されたプレイヤＩＤのみ（あるいは、新たに抽出を開始するプレイヤＩＤのみ）を記憶しておくことで、第３抽出手段５５４による毎回の抽出を高速に行うことができる。例えば、データベースサーバ３０に記憶しているプレイヤＩＤの数を１００万個、Ｍを１万、Ｎを１００としたならば、第３抽出手段５５４による抽出回数は、（１００万－１万）／１００＝９９００回と多くなるが、この各回における抽出開始のプレイヤＩＤについては、上記の通り「一定の規則」、すなわち昇順あるいは降順などによって重複することなく順序付けられたプレイヤＩＤに基づき認識されるので、前回までの抽出分に対して今回抽出開始すべき箇所が直ちに分かり、抽出方法も一定の規則に従っているため、各回の抽出処理を高速で完了させることができる。結果として、このゲーム制御装置によれば、非常に多くのプレイヤＩＤを対象とするマッチングを、限られた容量のＲＡＭ２３を用いて高速で実行することができる。
　このゲーム制御装置では、上述したように、データベースサーバ３０からプレイヤＩＤの抽出を行う第１抽出手段５５１あるいは第３抽出手段５５４では、一定の規則に従って順次プレイヤＩＤを抽出する。つまり、抽出済みか否かを、例えばフラグが立てられているか否かによって識別するようなデータをプレイヤＩＤごとに順次、確認するような処理は不要である。そのため、データベースサーバ３０内のプレイヤＩＤの数が、ゲーム制御装置の運用の途中で増大した場合であっても、データベースサーバ３０内のプレイヤＩＤのマッチングに要する処理時間の増加が抑制される。よって、データベースサーバ３０に記憶されたプレイヤＩＤの増大に応じたＲＡＭ２３の拡張（例えば、メモリの増設）あるいはシステム改変等の対応を回避することができる。
　このゲーム制御装置において、ＲＡＭ２３では、プレイヤＩＤの中から第２抽出手段５５２によりＮ個のプレイヤＩＤがランダムに抽出され、かつ、その抽出後に、新たなＮ個のプレイヤＩＤがデータベースサーバ３０から補充される。そのため、データベースサーバ３０内のプレイヤＩＤの如何なるマッチングの可能性は排除されない。具体的には、データベースサーバ３０に記憶しているプレイヤＩＤの数を１００万個（１番目から１００万番目のプレイヤＩＤ）であって、昇順に抽出した場合であっても、１番目と１００万番目のプレイヤＩＤのマッチングの可能性は排除されない。つまり、このゲーム制御装置によれば、広範囲におけるプレイヤ同士で対戦する機会を提供することができる。
　なお、仮に、１００万個のプレイヤＩＤに対して、ＲＡＭ２３の容量に応じた数のプレイヤＩＤごとにグループ分けを行い、各グループでランダムにマッチングを行うようにした場合には、対戦相手がグループ内に限定され、異なるグループのプレイヤ同士で対戦する機会が失われるが、このゲーム制御装置ではそのようなことはない。
　（２）第２の実施形態
　以下、本発明の第２の実施形態について説明する。なお、以下の各実施形態では、特記しない限り、通信端末１０、ゲームサーバ２０の構成及び動作、ゲーム制御装置によって実行される各手段、野球ゲームの主要な処理のフローは、第１の実施形態で説明したものと同様である。
　図１６に示すように、本実施形態のデータベースサーバ３０ａは、データベースサーバ３０（図４参照）とは入替戦データベース３４が追加された点で異なる。また、プレイヤデータベース３１では、図７に示したように、プレイヤＩＤごとにクラスが対応付けられている。図７では例えば、プレイヤＩＤ：０００００１に対してクラス：１が対応付けられている。
　本実施形態では、各プレイヤＩＤは複数のクラスのいずれかに対応付けられる。クラスの種別は任意に設定することができるが、例えば、ビギナークラス（初心者クラス、例えばクラス：１）からマスタークラス（上級クラス、例えばクラス：９）までの階層的なクラスが設定されうる。そして、本実施形態の野球ゲームは、クラス単位で一定期間のリーグ戦が行われる。一定期間のリーグ戦とリーグ戦の間には、入替戦が行われる。入替戦の結果如何で、プレイヤＩＤに対応するクラスの更新（変動）が生じうる。そのため、本実施形態の野球ゲームでは、第１の実施形態で説明したゲーム要素に加え、各プレイヤＩＤのプレイヤがより上位のクラスに昇格することを目的として行われる。なお、入替戦によって行われるクラスの更新は、上位クラスへの昇格、下位クラスへの降格、現状のクラスの維持のいずれかである。
　図１７に、リーグ戦と入替戦を含む本実施形態の野球ゲームのスケジュールの一例を示す。図１７に示すスケジュールによれば、リーグ戦のためにクラス１，３，５，７，９が設けられ、入替戦のためにクラス２，４，６，８が設けられる。ここで、リーグ戦、入替戦ともに、数字が大きいクラスほど上級のクラスである。例えば、１回目のリーグ戦であるリーグ戦＃１では、平日の月曜日から金曜日まで毎日４節（図１４参照）、計２０節のリーグ戦がクラス単位で実行され、クラス単位でリーグ戦＃１のランキングが金曜日に決定される。１回目の入替戦である入替戦＃１は、週末の土曜日と日曜日の毎日４節（例えば、図１４と同様にする。）、計８節の入替戦がクラス単位で実行され、クラス単位で入替戦＃１のランキングが日曜日に決定される。
　リーグ戦＃１に続く入替戦＃１における各プレイヤＩＤのクラスの更新は、リーグ戦＃１のランキング結果に基づき、所定の規則に従って決定される。図１７に示す例では、リーグ戦＃１におけるクラス１のすべてのプレイヤＩＤと、クラス３のランキングで下位の半分の数のプレイヤＩＤとが、入替戦＃１におけるクラス２となる。リーグ戦＃１におけるクラス３のランキングで上位の半分の数のプレイヤＩＤと、クラス５のランキングで下位の半分の数のプレイヤＩＤとが、入替戦＃１におけるクラス４となる。リーグ戦＃１におけるクラス５のランキングで上位の半分の数のプレイヤＩＤと、クラス７のランキングで下位の半分の数のプレイヤＩＤとが、入替戦＃１におけるクラス６となる。リーグ戦＃１におけるクラス７のランキングで上位の半分の数のプレイヤＩＤと、クラス９のすべてのプレイヤＩＤとが、入替戦＃１におけるクラス８となる。
　入替戦＃１に続くリーグ戦＃２における各プレイヤＩＤのクラスの更新は、入替戦＃１のランキング結果に基づき、所定の規則に従って決定される。図１７に示す例では、入替戦＃１におけるクラス２のランキングで下位の２／３の数のプレイヤＩＤは、リーグ戦＃２におけるクラス１となり、入替戦＃１におけるクラス２のランキングで上位の１／３の数のプレイヤＩＤは、リーグ戦＃２におけるクラス３となる。入替戦＃１におけるクラス４のランキングで下位の半分の数のプレイヤＩＤは、リーグ戦＃２におけるクラス３となり、入替戦＃１におけるクラス４のランキングで上位の半分の数のプレイヤＩＤは、リーグ戦＃２におけるクラス５となる。入替戦＃１におけるクラス６のランキングで下位の半分の数のプレイヤＩＤは、リーグ戦＃２におけるクラス５となり、入替戦＃１におけるクラス４のランキングで上位の半分の数のプレイヤＩＤは、リーグ戦＃２におけるクラス７となる。入替戦＃１におけるクラス８のランキングで下位の１／３の数のプレイヤＩＤは、リーグ戦＃２におけるクラス７となり、入替戦＃１におけるクラス８のランキングで上位の２／３の数のプレイヤＩＤは、リーグ戦＃２におけるクラス９となる。
　なお、図１７に示したスケジュール、あるいはクラスの更新は、一例に過ぎず、任意に設定可能であることは言うまでもない。
　（２－１）ゲーム制御装置における各機能の概要
　図１８は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。図１８に示す機能ブロック図は、図５に示したものと比較すると、第３の対戦実行手段５７およびクラス管理手段５８が追加された点で異なる。
　第３の対戦実行手段５７は、通信端末１０に対する操作入力を契機とせずに自動的に、異なるプレイヤＩＤに対応付けられたプレイヤキャラクタ間の入替戦（第３の対戦）を実行し、記憶手段５２（本実施形態では、データベースサーバ３０のプレイヤデータベース３１）が記憶するプレイヤキャラクタの能力値に基づいて入替戦の対戦結果を決定する。
　この第３の対戦実行手段５７により実行される入替戦は、所定の時刻（例えば、ゲームサーバ２０内のタイマで設定される時刻）に行われる。入替戦は、すべてのプレイヤＩＤが参加するように設定してもよいが、リーグ戦の参加を希望する一部のプレイヤＩＤのみが参加するように設定してもよい。
　第３の対戦実行手段５７によって実行される対戦の勝敗の決定方法は、第１の対戦実行手段５３と同様とすることができる。つまり、プレイヤキャラクタの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。
　第３の対戦実行手段５７は、入替戦の対戦結果を記録する。具体的には、第３の対戦実行手段５７では、ゲームサーバ２０のＣＰＵ２１がデータベースサーバ３０ａにアクセスし、データベースサーバ３０ａ内の入替戦データベース３４に入替戦の対戦結果を書き込む。
　第３の対戦実行手段５７は、入替戦におけるプレイヤＩＤのランキングを記録するとともに逐次更新する。具体的には、第３の対戦実行手段５７では、ゲームサーバ２０のＣＰＵ２１がデータベースサーバ３０ａの入替戦データベース３４にアクセスして入替戦の過去の一定期間（例えば図１７では、入替戦＃１の２日分）の対戦結果を読み出し、その読み出した対戦結果に基づいてクラス単位でのプレイヤＩＤのランキングを算出する。そして、ＣＰＵ２１は、データベースサーバ３０ａにアクセスし、データベースサーバ３０ａ内のランキングデータベース３３に、算出したランキングを書き込む。
　なお、本実施形態の第２の対戦実行手段５５では、ゲームサーバ２０のＣＰＵ２１がデータベースサーバ３０ａのリーグ戦データベース３２にアクセスしてリーグ戦の過去の一定期間（例えば図１７では、リーグ戦＃１の５日分）の対戦結果を読み出し、その読み出した対戦結果に基づいてクラス単位でのプレイヤＩＤのランキングを算出する。そして、ＣＰＵ２１は、データベースサーバ３０ａにアクセスし、データベースサーバ３０ａ内のランキングデータベース３３に、算出したランキングを書き込む。
　クラス管理手段５８は、各プレイヤＩＤを複数のクラス（リーグ戦および入替戦のクラスの双方を含む。）のうちのいずれかのクラスと対応付けて管理しており、一定期間のリーグ戦（例えば図１７では、リーグ戦＃１の５日分）および入替戦（例えば図１７では、入替戦＃１の２日分）が終了すると、図１７に例示したように、所定の規則に従って各プレイヤＩＤのクラスの更新を行う。具体的には、ＣＰＵ２１がデータベースサーバ３０ａにアクセスし、ランキングデータベース３３に記憶されたランキング結果に基づいて、プレイヤデータベース３１内の各プレイヤＩＤのクラスのデータの更新を行う。
　本実施形態の通知手段５６では、ゲームサーバ２０のＣＰＵ２１が、例えば図６に示すウェブページで「リーグ戦」が選択されたことを認識した場合に、直近のリーグ戦における対戦結果、および／または、過去の所定期間あるいは所定回数の１または複数のリーグ戦の対戦結果に基づくプレイヤＩＤごとの順位に加え、入替戦の結果を含むウェブページを各プレイヤの通信端末１０に表示するためのＨＴＭＬデータを、通信端末１０宛に送信する。このＨＴＭＬデータを解釈して通信端末１０で表示されるウェブページの例を図１９に示す。図１９に示すウェブページの例では、図１０に示したウェブページに対し、リーグ戦結果の欄の中に入替戦の対戦結果、およびクラスの更新の結果が追加して表示されている。図１９では一例として、先週の入替戦の結果は１８勝６敗で１クラス上に昇格し、今週の入替戦の結果は３勝７敗では１クラス下に降格した場合を示している。
　（２－２）マッチング処理
　本実施形態の第２の対戦実行手段５５において、非常に多数のプレイヤＩＤを対象として対戦相手を決定するためのマッチング処理（マッチング方法）について、以下説明する。なお、本実施形態の第３の対戦実行手段５７におけるマッチング処理は、以下で説明する第２の対戦実行手段５５におけるそれと同様であるため、重複説明を省略する。
　本実施形態の第２の対戦実行手段５５では、クラス単位でリーグ戦を行う点で第１の実施形態と異なる。
　図２０は、本実施形態の第２の対戦実行手段５５で実行される機能の一部を構成する複数の手段を示す機能ブロック図であり、各手段はＣＰＵ２１を主体として実行される。図２０に示す機能ブロック図は、図１１に示したものと比較すると、蓄積手段５５６が追加された点で異なる。
　蓄積手段５５６は、第２抽出手段５５２および第３抽出手段５５４によって抽出されたそれぞれＮ個のプレイヤＩＤを、対応するクラスごとに蓄積する機能を備える。
　本実施形態のマッチング実行手段５５３は、クラスごとに蓄積されたプレイヤＩＤの数がクラスについて予め定められた数に達した場合に、当該クラスについて蓄積されたプレイヤＩＤについてのマッチングが完了したと判定する機能を備える。
　以下、本実施形態のマッチング処理について、図２１および図２２を参照して説明する。図２１は、本実施形態のマッチング処理を示すフローチャートである。図２２は、本実施形態のマッチング処理においてクラスごとのプレイヤＩＤのバッファへの蓄積を概念的に示す図である。
　図２１に示すフローチャートは、図１２のフローチャートと比較して、ステップＳ３０のマッチング処理の代わりに、ステップＳ３１，Ｓ３２，Ｓ３３を設けた点と、Ｎ＝５００の場合を例示している点で異なる。また、図２２に示すように、リーグ戦のクラス１，３，５，７，９（図１７参照）に対応したバッファを設ける。ここで、図２１のステップＳ３１（蓄積手段５５６の処理に相当）では、図２１のステップＳ２０で抽出された各プレイヤＩＤを、対応するクラスごとに分配して各クラスのバッファに蓄積していく。マッチング処理を実行する前の初期状態では、各クラスのバッファは空の状態であるが、ステップＳ３１を繰り返すごとに順にバッファにプレイヤＩＤが蓄積されていく。そして、ＣＰＵ２１は、ＦＵＬＬになったバッファについては（ステップＳ３２：ＹＥＳ）、そのバッファ内のプレイヤＩＤのマッチングが完了したと判定し、バッファ内のプレイヤＩＤを掃き出して再び空の状態とする（ステップＳ３３）。
　バッファの容量は適宜設定してよいが、ここでは一例としてＮ＝５００としているので、各バッファの容量はそれぞれ、１００個分のプレイヤＩＤとしてよい。この場合、対戦実行手段５５５は、バッファから掃き出された（つまり、マッチングが完了した）同一のクラスの１００個のプレイヤＩＤについて、図１４を参照して説明した方法と同様に、複数の組ごとの総当り戦を実行してよい。
　本実施形態のマッチング方法は、抽出処理については第１の実施形態と同様であるため、限られた容量の主メモリを用いて高速でマッチングを実行でき、かつ、そのマッチングをクラス単位で個々に設けたバッファを利用して行うようにしているので、複数クラスを設けたゲーム構成であっても、異なるクラスのプレイヤＩＤのマッチングを回避できることから、無駄な処理のない効率よいマッチングを実現することができるという利点がある。
　（２－３）野球ゲームの入替戦の処理のフロー
　次に、本実施形態における野球ゲームの入替戦の処理フローの一例について、図２３のフローチャートを参照して説明する。図２３は、入替戦（第３の対戦）の実行処理を示すフローチャートである。
　図２３において、入替戦が行われる開始時刻になると（ステップＳ３００のＹＥＳ）、第３の対戦実行手段５７が実行される。この第３の対戦実行手段５７は、プレイヤによる通信端末１０に対する操作入力を契機とせずに自動的に実行される。第３の対戦実行手段５５は、プレイヤデータベース３１に記憶されているプレイヤＩＤを対象として入替戦を行う場合、その入替戦における対戦のマッチングの処理を行う（ステップＳ３１０）。このマッチングの処理は、図２１のフローチャートに示したとおりであり、プレイヤデータベース３１に記憶されているプレイヤＩＤの数が極めて多い場合であっても、クラス単位で高速に行われる。
　マッチングの処理が完了すると、第３の対戦実行手段５７は次にプレイヤデータベース３１を参照し、プレイヤキャラクタの能力値に基づいて、つまり、プレイヤキャラクタの能力値の差が勝敗に影響を与えるようにして、対戦結果を決定する（ステップＳ３２０）。第３の対戦実行手段５７は、対戦結果を決定した後、その入替戦の対戦結果を入替戦データベース３４に記録する。
　次に、クラス管理手段５８は、所定の規則に従ってプレイヤＩＤごとにクラスの更新を行う（ステップＳ３３０）。このとき、クラス管理手段５８は、入替戦データベース３４内に記録されている入替戦の対戦結果を参照し、所定の基準に従ってプレイヤＩＤごとに新しいクラスを決定する。そしてクラス管理手段５８は、プレイヤデータベース３１においてプレイヤＩＤごとに新しいクラスを記録する。その後、通知手段５６は、各プレイヤＩＤに対応するプレイヤの通信端末１０宛に、入替戦の対戦結果とクラスの更新結果を通知する（ステップＳ３４０）。なお、この通知は、各プレイヤが例えば図６に例示したウェブページで「リーグ戦」が選択された場合に、通信端末１０において、リーグ戦の結果とともに入替戦の結果を含むウェブページが表示されるようにして行うことができる。
　以上説明したように、本実施形態のゲーム制御装置では、クラス管理手段５８は、各プレイヤＩＤを複数のクラスのうちのいずれかのクラスと対応付けて管理する。プレイヤＩＤとクラスとの対応付けは、様々な観点から設定しうる。例えば、プレイヤＩＤがゲーム上のプレイヤキャラクタの能力値と関連付けられている場合には、その能力値の大きさに応じたクラスに各プレイヤＩＤを対応付けてもよい。あるいは、クラスに応じた複数のステージ（例えば、それぞれ異なる複数の対戦種目）の対戦ゲームが設定されている場合には、参加するステージに各プレイヤＩＤを対応付けてもよい。
　本実施形態のゲーム制御装置では、クラスごとにプレイヤＩＤのマッチングを行うべく、蓄積手段５５６が、第２抽出手段５５２および第３抽出手段５５４によって抽出されたそれぞれＮ個のプレイヤＩＤを、対応するクラスごとに順次、振り分けて蓄積する。そして、マッチング実行手段５５３は、クラスごとに蓄積されたプレイヤＩＤの数がクラスについて予め定められた数に達した場合に、当該クラスについて蓄積されたプレイヤＩＤについてのマッチングが完了したと判定する。ここで、クラスについて予め定められた数は、任意に設定することができ、上記Ｎの値（ＲＡＭ２３（主メモリ）上のプレイヤＩＤの中から抽出されるプレイヤＩＤの数）と同一の値であってもよいし、異なる値でもよい。１回の第２抽出手段５５２または第３抽出手段５５４の実行によって各クラスに蓄積されるプレイヤＩＤの数が上記予め定められた数に達しない場合には、複数回の第２抽出手段５５２または第３抽出手段５５４の実行により予め定められた数までプレイヤＩＤが蓄積された時点で、マッチングが完了したと判定される。このゲーム制御装置によれば、非常に多くのプレイヤＩＤを対象とするマッチングを限られた容量の主メモリを用いて高速で実行しつつ、そのマッチングをクラス単位で行うようにすることができるため、異なるクラスのプレイヤＩＤが組み合わされるといった無駄な処理を回避し得て、効率よいマッチングを行なえる。また、複数のクラスを設けることで、ゲーム制御装置によって提供されるゲームのバリエーションを広げることができる。
　上述したように、上述した各実施形態のゲーム制御装置は、ネットワークを介して任意の通信端末と通信を行うことが想定される。通信端末は例えば、ゲーム用ソフトウエアを搭載した通信機能付きゲーム装置、いわゆるスマートフォン等の携帯端末、ＰＤＡ(Personal Digital Assistance)等であってよい。つまり、このゲーム制御装置によって実行される対戦ゲームとして、オンラインゲームまたはソーシャルゲームが想定されている。前述したように、ソーシャルゲームあるいはオンラインゲームでは、比較的簡易な手続きでプレイヤＩＤを登録することができるため、ゲーム制御装置で管理するプレイヤＩＤの数は、ゲーム制御装置の運用を開始する時点では予測が困難である。そのため、特定のゲームに対応したゲーム制御装置の運用開始時点では、例えば１００万人のプレイヤが参加（例えば１００万個のプレイヤＩＤを登録）し、運用開始の１ヶ月後には、２００万人のプレイヤが参加（例えば２００万個のプレイヤＩＤを登録）する、というように、ゲーム制御装置のデータベースサーバ３０に記憶すべきプレイヤＩＤの数が短期間で急激に増加する状況があり得る。かかる状況下においても、このゲーム制御装置によれば、データベースサーバ３０内のプレイヤＩＤのマッチングに要する処理時間の増加が抑制されるため、データベースサーバ３０に記憶されたプレイヤＩＤの増大に応じたＲＡＭ２３（主メモリ）の拡張（例えば、メモリの増設）あるいはシステム改変等の対応を回避することができる。すなわち、このゲーム制御装置は、特にオンラインゲームまたはソーシャルゲームに適用することで有用な効果を奏する。
　以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
　例えば、上述した実施形態では、対戦ゲームは、ゲームサーバからのウェブサービスの提供に基づき、プレイヤの通信端末のウェブブラウザにより表示されるウェブページによってゲームが進行することとした。これによれば、ゲーム用ソフトウエアを通信端末がダウンロードあるいはインストールする必要がないという長所があるが、これに限られない。本実施形態の対戦ゲームは、ゲーム用ソフトウエアで実現される一部機能を通信端末にダウンロードあるいはインストールして実行する形態とすることもできる。
　なお、各実施形態の説明で述べた各機能ブロックは、各機能に相当する手順を含むプログラムをコンピュータに実行させることで実現することができる。
　１０…通信端末
　　　１１…ＣＰＵ
　　　１２…ＲＯＭ
　　　１３…ＲＡＭ
　　　１４…画像処理部
　　　１５…操作入力部
　　　１６…表示部
　　　１７…無線通信インタフェース部
　　　１８…バス
　２０…ゲームサーバ
　　　２１…ＣＰＵ
　　　２２…ＲＯＭ
　　　２３…ＲＡＭ
　　　２４…データベースアクセス部
　　　２５…通信インタフェース部
　　　２６…バス
　３０，３０ａ…データベースサーバ
　　　３１…プレイヤデータベース
　　　３２…リーグ戦データベース
　　　３３…ランキングデータベース
　　　３４…入替戦データベース
　５１…ゲーム進行手段
　５２…記憶手段
　５３…第１の対戦実行手段
　５４…キャラクタ能力更新手段
　５５…第２の対戦実行手段
　５６…通知手段
　５７…第３の対戦実行手段
　５８…クラス管理手段

Claims (6)

  1. 　不揮発性メモリに記憶された複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行うゲーム制御装置であって、
    　一定の規則に従って前記複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して主メモリに展開する第１抽出手段と、
    　主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する第２抽出手段と、
    　第２抽出手段によって抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行うマッチング実行手段と、
    　前記複数のプレイヤ識別情報の中から、前記第１抽出手段により抽出されなかったＮ個のプレイヤ識別情報を前記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、前記マッチング実行手段によりマッチングが行われたＮ個のプレイヤ識別情報に代えて前記主メモリに展開する第３抽出手段と、
    　を備え、前記第２抽出手段、マッチング手段および第３抽出手段による各処理を、この順番に繰り返すことを特徴とする、
    　ゲーム制御装置。
  2. 　前記不揮発性メモリは、各プレイヤ識別情報と、プレイヤ識別情報を基に自装置に最後にアクセスされた時刻と対応付けて記憶しており、
    　前記第１抽出手段および前記第３抽出手段では、前記複数のプレイヤ識別情報の中から、現在時刻が前記最後にアクセスされた時刻から所定時間経過していないプレイヤ識別情報を抽出することを特徴とする、
    　請求項１に記載されたゲーム制御装置。
  3. 　各プレイヤ識別情報を複数のクラスのうちのいずれかのクラスと対応付けて管理しているクラス管理手段と、
    　第２抽出手段および第３抽出手段によって抽出されたそれぞれＮ個のプレイヤ識別情報を、対応するクラスごとに蓄積する蓄積手段と、
    　を備え、
    　前記マッチング実行手段は、クラスごとに蓄積されたプレイヤ識別情報の数がクラスについて予め定められた数に達した場合に、当該クラスについて蓄積されたプレイヤ識別情報についてのマッチングが完了したと判定することを特徴とする、
    　請求項１または２に記載されたゲーム制御装置。
  4. 　ネットワークを介して任意の通信端末と通信を行う通信手段と、
    　任意の通信端末からの対戦参加に関する登録のためのアクセスに基づいて、プレイヤ識別情報を前記不揮発性メモリに記憶させる記憶手段と、を備えたことを特徴とする、
    　請求項１～３のいずれかに記憶されたゲーム制御装置。
  5. 　不揮発性メモリに記憶された複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行うゲーム制御装置におけるマッチング方法であって、
    　一定の規則に従って前記複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して前記ゲーム制御装置の主メモリに展開する第１のステップと、
    　前記主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する第２のステップと、
    　第２のステップによって抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行う第３のステップと、
    　前記複数のプレイヤ識別情報の中から、前記第１のステップで抽出されなかったＮ個のプレイヤ識別情報を前記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、前記第３のステップでマッチングが行われたＮ個のプレイヤ識別情報に代えて前記主メモリに展開する第４のステップと、
    　を備え、
    　前記第２、第３および第４のステップを、この順番に繰り返すことを特徴とする、
    　マッチング方法。
  6. 　不揮発性メモリに記憶された複数のプレイヤ識別情報を対象としてプレイヤ間の対戦のためのプレイヤ識別情報のマッチングを行うためのプログラムであって、
    　一定の規則に従って前記複数のプレイヤ識別情報の中からＭ個のプレイヤ識別情報を抽出して前記コンピュータの主メモリに展開する第１抽出手順と、
    　前記主メモリ上のプレイヤ識別情報の中からＮ個（Ｎ＜Ｍ）のプレイヤ識別情報をランダムに抽出する第２抽出手順と、
    　第２抽出手順によって抽出されたＮ個のプレイヤ識別情報を対象としてマッチングを行うマッチング実行手順と、
    　前記複数のプレイヤ識別情報の中から、前記第１抽出手順で抽出されなかったＮ個のプレイヤ識別情報を前記一定の規則に従って新たに抽出し、その新たに抽出したＮ個のプレイヤ識別情報を、前記マッチング実行手順でマッチングが行われたＮ個のプレイヤ識別情報に代えて前記主メモリに展開する第３抽出手順と、
    　前記第２抽出手順、マッチング実行手順および第３抽出手順を、この順番に繰り返す手順と、
    　をコンピュータに実行させるためのプログラム。
PCT/JP2012/001207 2011-05-27 2012-02-22 ゲーム制御装置、マッチング方法、プログラム WO2012164786A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011118924A JP5214770B2 (ja) 2011-05-27 2011-05-27 ゲーム制御装置、マッチング方法、プログラム
JP2011-118924 2011-05-27

Publications (1)

Publication Number Publication Date
WO2012164786A1 true WO2012164786A1 (ja) 2012-12-06

Family

ID=47258665

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/001207 WO2012164786A1 (ja) 2011-05-27 2012-02-22 ゲーム制御装置、マッチング方法、プログラム

Country Status (2)

Country Link
JP (1) JP5214770B2 (ja)
WO (1) WO2012164786A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106823376B (zh) 2017-01-24 2020-08-21 腾讯科技（深圳）有限公司 一种实现用户匹配的方法及装置

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1142368A (ja) * 1997-07-26 1999-02-16 Namco Ltd ゲーム装置および該ゲーム装置に係るプログラムを記憶した記憶媒体
JP2001157782A (ja) * 1999-12-02 2001-06-12 Dowango:Kk 対戦相手決定システム
JP2001344372A (ja) * 2000-03-30 2001-12-14 Sega Corp オンライン組織化方法
JP2002035424A (ja) * 2000-07-15 2002-02-05 Ellicion Inter Network Co Ltd インターネットを利用した自動ゲームマッチング及び勝敗認識機能を有するネットワークゲーム大会運営システム及びそれの運営方法
JP2006293694A (ja) * 2005-04-11 2006-10-26 Sony Computer Entertainment Inc 情報処理装置、コンピュータの制御方法及びプログラム
JP2007061616A (ja) * 2005-08-26 2007-03-15 Nhn Corp ゲームルーム及びゲームチャンネル管理システム
JP2008538318A (ja) * 2005-04-19 2008-10-23 マイクロソフト コーポレーション ゲームプレイヤに関するフィードバックを提供し、ソーシャルマッチメイキング（ｓｏｃｉａｌｍａｔｃｈｍａｋｉｎｇ）を向上するためのシステムおよび方法
JP2009279345A (ja) * 2008-05-26 2009-12-03 Sega Corp ネットワークゲームシステム

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1142368A (ja) * 1997-07-26 1999-02-16 Namco Ltd ゲーム装置および該ゲーム装置に係るプログラムを記憶した記憶媒体
JP2001157782A (ja) * 1999-12-02 2001-06-12 Dowango:Kk 対戦相手決定システム
JP2001344372A (ja) * 2000-03-30 2001-12-14 Sega Corp オンライン組織化方法
JP2002035424A (ja) * 2000-07-15 2002-02-05 Ellicion Inter Network Co Ltd インターネットを利用した自動ゲームマッチング及び勝敗認識機能を有するネットワークゲーム大会運営システム及びそれの運営方法
JP2006293694A (ja) * 2005-04-11 2006-10-26 Sony Computer Entertainment Inc 情報処理装置、コンピュータの制御方法及びプログラム
JP2008538318A (ja) * 2005-04-19 2008-10-23 マイクロソフト コーポレーション ゲームプレイヤに関するフィードバックを提供し、ソーシャルマッチメイキング（ｓｏｃｉａｌｍａｔｃｈｍａｋｉｎｇ）を向上するためのシステムおよび方法
JP2007061616A (ja) * 2005-08-26 2007-03-15 Nhn Corp ゲームルーム及びゲームチャンネル管理システム
JP2009279345A (ja) * 2008-05-26 2009-12-03 Sega Corp ネットワークゲームシステム

Also Published As

Publication number Publication date
JP2012245152A (ja) 2012-12-13
JP5214770B2 (ja) 2013-06-19

Similar Documents

Publication Publication Date Title
JP5373156B2 (ja) ゲーム制御装置、ゲームプログラム、ゲーム制御方法、ゲームシステム
JP5710432B2 (ja) ゲーム制御装置、ゲームプログラム、ゲームシステム
JP5599855B2 (ja) ゲーム制御装置、アイテム抽選プログラム、ゲームシステム
JP5336681B1 (ja) プログラム、及び、情報処理装置
JP2013233385A (ja) ゲーム制御装置、ゲーム制御方法、ゲーム制御プログラム、及びゲームシステム
JP2013150768A (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5149986B1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5260783B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP5214770B2 (ja) ゲーム制御装置、マッチング方法、プログラム
JP5562400B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5526295B1 (ja) ゲームプログラム、及び、情報処理装置
JPWO2013161652A1 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP5499208B1 (ja) プログラム、及び、情報処理装置
JP5894109B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP6542156B2 (ja) ゲーム制御方法、コンピュータ及び制御プログラム
JP6206772B2 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP7128247B2 (ja) ゲーム制御方法、コンピュータ及び制御プログラム
JP2017154016A (ja) ビデオゲーム処理装置、およびビデオゲーム処理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12793216

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12793216

Country of ref document: EP

Kind code of ref document: A1