JP4865366B2 - Network game system and network game method - Google Patents

Description

  The present invention relates to a network game system and a network game method that allow a player to play a game via a network by an operation from a terminal device such as a mobile phone.

  There is known a network game system in which various games can be enjoyed by a game server on a network by operating from a PC, a mobile phone or the like.

  A general multiplayer network game system includes a gate server, a database server, and a plurality of game servers.

  In such a system, when a player accesses the gate server from a terminal device such as a PC or a mobile phone, the gate server refers to the database server to authenticate the player with an ID, password, etc., and then the game starts. . That is, the player selects one from a plurality of game servers (divided into room 1, room 2,... When viewed from the player), or the network game system side plays a game on each game server. By determining the number of players who are playing and instructing the player to play on a specific game server, the game is played on one specific game server. Each game server executes a game on-memory, and even when a battle game is played as a game, matching of opponents is performed at each game server.

  However, in the above-described network game system, when the programs to be processed by the game server are diverse and complicated, all the games are executed on-memory, which increases the load on the game server. There is a problem.

  In addition, since a player plays a game only with a specific game server, there is a problem that if the game server goes down, subsequent games cannot be continued.

  In addition, because each game server also performs matching of opponents when performing a battle game, the candidate of the opponent can be another game game that is similarly played on a specific game server where the player is playing a game. Since only a player and a player who is playing a game on another game server cannot be a candidate, there is a problem that the selection range of the opponent is narrow.

  Therefore, an object of the present invention is to reduce the load on the game server, continue the game after the specific game server goes down, and match the player of the battle game from a wide range of options. Is to be able to.

  (1) The present invention is a network game system that accepts a player's operation request from each terminal device and executes a game via a network, wherein a plurality of game servers and the game servers are accessed in common Provided in each game server, a load balancer that accepts an operation request from the terminal device, determines a load on each game server, and distributes the operation request from the terminal device to each game server. A first game executing means for accessing the database and executing a predetermined game in response to an operation request from the terminal device, and a player can play a game with another player by the terminal device during the game of the predetermined game. When requesting execution of a battle game, the matching means for matching the player with another player who is the opponent, and Distribution to the same game server with respect to operation requests from the respective terminal devices of the players who are fighting in the matched game after the matching is established. And a second game execution means that is provided in each of the game servers and executes the battle game in an on-memory in response to the operation request that has received the distribution. Is a network game system characterized by

  In this case, when there is an operation request for requesting execution of the battle game from the terminal device, a second identification indicating that the terminal device is desired and execution of the battle game is second. Registration means for associating with an identification mark and registering in a common table is further provided, wherein the matching means refers to the table, and the players of the first identification mark are attached with the second identification mark. May be matched.

  In addition, when the matching is established and the game server shifts to the battle game, each game server assigns the same third identification mark to the terminal device of each player who performs the battle game. And the distribution means distributes the operation request with the same third identification mark to the same game server when the operation request with the third identification mark is from the terminal device. You may do it.

  Furthermore, the predetermined game may be a role playing game.

(2) The present invention viewed from another aspect is a control method of a network game system that accepts a player's operation request from each terminal device and executes a game via a network, wherein the terminal is operated by a load balancer A first step of accepting an operation request from a device, determining a load of each game server, and distributing the operation request from the terminal device to each game server; and receiving the operation request from the load balancer A second step of accessing a database commonly accessed by the game servers by the game server and executing a predetermined game in response to an operation request from the terminal device, and a player during a game of the predetermined game When the terminal device requests execution of a battle game with another player, a match between the player and another player who is the opponent The operation request from each of the terminal devices of the player who is competing in the match game after the matching is established by the load balancer after the third step is performed is the same as the operation request from each terminal device. A fourth step of distributing to the game server, and a fifth step of executing the battle game in an on-memory in response to the operation request received by the game server that has received the distribution. It is a control method of the network game system characterized.

  In this case, when there is an operation request for requesting execution of the battle game from the terminal device, a second identification indicating that the terminal device is desired and execution of the battle game is second. The game further includes a sixth step of associating the identification mark with a common table and registering the identification mark in the common table, wherein the third step refers to the table and the first identification mark is attached with the second identification mark. You may make it match a person.

  In addition, when the matching is established and the game is shifted to the battle game, a seventh step of assigning the same third identification mark to the terminal device of each player who performs the battle game is performed in each game server. Further, in the fourth step, when an operation request with the third identification mark is received from the terminal device, the operation request with the same third identification mark is distributed to the same game server. You may do it.

  Furthermore, the predetermined game may be a role playing game.

  According to the present invention, during execution of a normal predetermined game, the load balancer determines the load on each game server, distributes each operation request from each terminal device to each game server, and each game server Since the game can proceed while accessing the database and reading / writing data necessary for the game, the load on each game server can be reduced as compared with the case where all the games are processed in the on-memory. In this case, since each game server uses a common database, each operation request may be processed once and once through different game servers in the same game of the same player. There is no contradiction in the game.

  In addition, when shifting to a battle game within a predetermined game, the load balancer distributes all operation requests from both players in the same battle game to the same game server, and the game server is turned on.・ Run a battle game in memory. Therefore, for a complex game with a large amount of processing data, the processing is not slowed down by caching in the memory, and the response time as viewed from the player side is fast.

  In other words, while taking care to handle complex games that require processing huge amounts of data without problems, the load on each game server is sufficiently reduced during the execution of a predetermined game such as a role-playing game. Therefore, various programs can be processed by each game server as a whole.

  Furthermore, the load balancer distributes each operation request from each terminal device to each game server during execution of a normal predetermined game, and the load balancer issues each operation request for each player during the execution of a battle game. Since the game server is assigned to a specific game server, it is possible to avoid the game server even if one of the game servers is down, and it is possible to continue the subsequent game even if a failure occurs in the game server.

  In addition, if a table is used, all players who are currently requesting a competitive game in the network game system can be matched if all the competitive game requests from the player are processed using a common table. Thus, it is possible to match a player of a battle game from a wide range of options.

  Hereinafter, the best mode for carrying out the present invention will be described.

[System configuration]
FIG. 1 is a block diagram showing the overall configuration of the network game system of the present embodiment. The network game system 1 includes a plurality of game servers 2 (first game server, second game server, third game server,...) And a single database (DB) that can be commonly accessed by the game servers 2. A server 3 and a load balancer 4 are provided. Each game server 2 and load balancer 4 are connected to the Internet 5, and are connected to a terminal device 8 (a mobile phone in this example) via the Internet 5, a gateway 6, and a mobile communication network 7 (a mobile phone network in this example). Packet communication can be performed. In addition to the mobile phone, the terminal device 8 can be a PHS, a PC or PDA having a mobile communication function, or the like.

  Each game server 2 causes a player who is the owner of the terminal device 8 to play a predetermined game in accordance with the operation of the terminal device 8. Each game server 2 operates a common game program, and any game server 2 can play the same game. The load balancer 4 receives all operation signals from the terminal device 8 and distributes them to the game servers 2 as described later.

  FIG. 2 is a block diagram of electrical connection of each computer constituting the game server 2, the load balancer 4, and the DB server 3. These computers are connected through a bus 13 to a CPU 11 that performs various calculations and centrally controls each unit, and a memory 12 that includes various ROMs and RAMs. Further, the bus 13 includes a magnetic storage device (HDD) 14, a communication control device 15 that communicates with the Internet 5 and other computers (between the game server 2 and the load balancer 4, between the game server 2 and the DB server 3), 16 is connected. By setting up dedicated programs in the computer shown in FIG. 2, the game server 2, the load balancer 4, and the DB server 3 operate as described later, respectively.

  FIG. 3 is a block diagram of electrical connection of the terminal device 8. The terminal device 8 is a mobile phone in this example, and a CPU 21 that centrally controls each unit and a storage device 22 including various ROMs, RAMs, or magnetic storage devices (HDDs) are connected by a bus 23. . Further, an input device 24 composed of various keys, a display device 25 composed of a liquid crystal display, and a speaker 27 are connected to the bus 23 via a predetermined sound generator 26. A transmitting / receiving device 28 that communicates with the mobile communication network 7 is also connected.

  An application program 31 is downloaded to the terminal device 8 from the game server 2 or a server device (not shown) constituting the network game system 1 and set up in the storage device 22. The application program 31 includes two programs, a city application 32 and a battle application 33. The city application 32 and the battle application 33 are downloaded separately because of the limitation of the capacity that can be downloaded at one time via the mobile communication network 7. Further, if the city application 32 is downloaded and set up, even if the battle application 33 is not downloaded, it is possible to play a game by communicating with the network game system 1 for the time being. The battle application 33 may be downloaded as necessary after the game has progressed.

  The predetermined game played in the network game system 1 is a role-playing game, and during the role-playing game, it is possible to shift to a battle game in which characters are operated by different players to fight each other. After the battle game, the role playing game can be restored.

  The town application 32 enables the player to perform various operations of the game. Among the aforementioned games, the role playing game can be operated by the city application 32. Further, the game application 32 also makes a request for a match game (matching request).

  When the player issues a match request that the player wants to play a battle game by the city application 32, the player is matched with the player who has made another battle request, and when this match is successful, the game shifts to battle game. To do. This battle game operation is performed based on the battle application 33.

[Outline of game processing]
Next, specific processing of a game executed between the terminal device 8 and the network game system 1 in the system configuration as described above will be described with reference to the flowcharts in FIG. In these flowcharts, the game server 2 is a game server 2 to which the load balancer 4 transmits an operation request from the terminal device 8 among a plurality of game servers 2, and always means the same game server 2. is not.

  FIG. 4 is a flowchart of processing when a role playing game is performed. The player initially plays a role-playing game by a process executed by the city application 32. In the role playing game, when the player operates the terminal device 8 (Y in Step S1), a data operation request is transmitted to the load balancer 4 (Step S2).

  When the load balancer 4 receives the data operation request (Y in step S3), the load balancer 4 determines the usage rate of the RAM serving as the main memory of each game server 2 and the load on the CPU 11, and each game server 2 One game server 2 to be used is selected (step S4), and a data operation request is transmitted to the game server 2 (step S5).

The game server 2 that has received this data operation request (Y in step S6) makes a data request for the player to the DB server 3 (step S7). That is, the data needed to perform the role-playing game is registered in the DB server 3 for each player. This data is registered for each player with an identification mark for identifying the player, in this example, a user ID (UID). Since the same UID is also attached to the data operation request (step S2), the data in the DB server 3 of the player who made the data operation request (step S2) can be identified. The data request (step S7) to the DB server 3 is not always performed every time a data operation request is received (Y in step S6), and is appropriately performed when necessary.

  When this data request is accepted (Y in step S8), the DB server 3 sends a corresponding data to the game server 2 that has made the data request (step S7) and responds (step S9).

  The game server 2 that has received this response (Y in step S10) processes the data operation request based on the data relating to the game of the player received from the DB server 3 (step S11). Thereby, one progress of the game according to the player's operation is achieved. Then, the DB server 3 is requested to register new data so that new data corresponding to the processing of the data operation request is added to the player's data (step S12), and a response is sent to the corresponding player's data. It returns to the terminal device 8 (step S13). In the terminal device 8 that has received this response (Y in step S14), an image display reflecting the content of this response is performed on the display device 25 and an audio output is performed from the speaker 27 (step S15). The progress of the game according to the operation (Y in step S1) can be confirmed by image display and audio output.

  By repeating such processing, the player can advance the game of the role-playing game and advance the story that each character develops in the virtual world. When a player requests a battle game in the progress of the role playing game, matching with other players who are opponents is performed, and different players play a battle game over the network. be able to.

  FIG. 5 is a flowchart of the process when requesting this battle game. First, when the player operates the terminal device 8 to make a matching request that is an operation request for requesting execution of a battle game based on the city application 32 (Y in step S21), a matching request is transmitted to the load balancer 4 (Step S22). This matching request includes information for requesting matching for a match game, the player's UID, the condition of the match partner input by the player (the ability level of the match game requested of the match player, etc.), and the like. .

  When the load balancer 4 receives the data operation request (Y in step S23), the load balancer 4 determines the usage rate of the RAM serving as the main memory of each game server 2 and the load on the CPU 11, and each game server 2 One game server 2 to be used is selected so that the load can be distributed (step S24), and a matching request is transmitted to the game server 2 (step S25).

  The game server 2 that has received the matching request (Y in step S26) transmits the matching request to the DB server 3 (step S27). When receiving the matching request (Y in step S28), the DB server 3 registers the data of the player who has made the matching request in the battle table 41 shown in FIG. 6 (step S29).

  As shown in FIG. 6, data of each player who has made a matching request is registered in the battle table 41. Reference numeral 42 indicates individual data of each player. In the personal data 42, information necessary for matching an opponent, such as a predetermined identification mark (such as a UID) for identifying the player, a matching partner condition designated by the player, and the like is associated and registered. In addition, state information “matching state” is also registered as an identification mark indicating whether the player is currently waiting for matching or whether a battle is established. When the “matching state” is “0”, it indicates that the player is currently waiting for matching, and when the “matching state” is “1”, it indicates that a battle has been established. Therefore, in step S29, “0” indicating that the current state is waiting for matching is added as the “matching state”, and the personal data 42 is registered.

  Then, the DB server 3 specifies the personal data 42 of the two players who play a game against each other according to a predetermined algorithm from among the individual data 42 in which “0” is registered as the “matching state”. Thus, matching is performed (step S30). When the matching is successful (Y in step S31), the personal data 42 of both names is combined into a single battle data 43. The “matching state” is set to “1”, and a battle ID (BID), which is an identification mark made up of, for example, a 32-digit random character string, is registered in the battle data 43 (step S32).

  Note that the example of FIG. 5 shows an example in which the matching process is continued until the matching is successful (steps S30 and S31). 2 may be transmitted to the terminal device 8 to refuse the execution of the battle game, or the game server 2 may play a battle game with the opponent as described later.

  When the BID is registered in this way (step S32), the DB server 3 sends a data response to the game server 2 that has made the matching request (step S33). This response includes the BID registered in step S32.

  In addition, since the matching request is made by two players who are to compete, the game server 2 that has made the matching request may differ depending on the player. In this case, for example, when matching is established, a data response may be performed by selecting a game server 2 having a light processing load. In this case, if the game server 2 receiving the data response transmits the identification information and BID of itself (game server 2) in association with the load balancer 4, it will be described later with reference to FIG. As described above, the load balancer 4 can specify the game server 2 to be used when performing the battle game.

  Upon receiving this response (Y in step S34), the game server 2 sends a request for activation of the battle application 33 to each of the terminal devices 8 of the two players who have been matched by making a matching request (step S34). In the example of FIG. 5, only one terminal device 8 is shown, but the transmission destination of the activation request of the battle application 33 in this process is two terminal devices 8) (step S35). In step S35, the identification of each terminal device 8 of the two players who have been matched may be performed based on the UIDs of both players included in the response transmitted to the game server 2 in step S33. . Each activation request also includes the BID registered in step S32.

  In this way, the player who has received the activation request for the battle application 33 activates the battle application 33 when the battle application 33 has already been set up in the terminal device 8, and when the battle application 33 has not yet been downloaded. Downloads the battle application 33, sets up the terminal device 8, and activates the battle application 33. In this battle application 33, the BID included in the above-described start request of the battle application 33 is held. Thereby, the process based on the battle application 33 is started. Hereinafter, processing based on the battle application 33 will be described.

  FIG. 7 is a flowchart for explaining processing based on the battle application 33. First, when a player operates a battle game on the terminal device 8 (Y in step S41), the terminal device 8 transmits battle request data as an operation request to the load balancer 4 (step S42). This battle request data includes the BID included in the activation request transmitted in step S35.

  When the load balancer 4 receives this battle request data (Y in step S43), the load balancer 4 distributes the battle request data to any game server 2 according to the BID included in the battle request data ( Steps S44 and S45). That is, the game server 2 is selected (step S44) and battle request data is transmitted (step S45). This distribution is performed so that battle request data including the same BID is always transmitted to the same game server 2. Specifically, as described above, the load balancer 4 can determine the game server 2 to which data should be transmitted based on the identification information and BID of the game server 2 transmitted from the game server 2.

  In this way, the same game server 2 is always selected for the same BID, and in the game server 2 that has received the battle request data (Y in step S46), according to the player's operation indicated by the battle request data, Processing of the battle request data is performed on-memory without referring to the DB server 3 (step S47), and the processing result is transmitted to the mobile terminals 8 of the two players who are given the same BID. (Step S48). The identification of the mobile terminals 8 of the two players includes, for example, the UIDs of the two matched players in the activation request of the battle application 33 in step S35, and thereby the battle request data in step S42. May include the UIDs of two matched players. Alternatively, if the UIDs of the two matched players are included in the activation request of the battle application 33 in step S35 and the UID and BID are associated with each other and held in the game server 2, the battle in step S42 is performed. Request data need only contain BID.

  As described above, the battle game progresses by alternately performing the battle game operation (Y in step S41) by the two players in the battle and performing the processing of step S41 and subsequent steps for each operation. The battle game ends when the battle is over. When the battle game ends, the DB server 3 deletes the battle data 43 relating to the completed battle game from the battle table 41 in accordance with an instruction from the game server 2. Then, a declaration of the end of the battle game is transmitted to the terminal devices 8 of both players who have played the battle, and the terminal device 8 of these players ends the processing by the battle application 33, and the role playing game by the city app 32 Return to. Moreover, the battle result data of the battle game is stored in the DB server 3 or delivered to the city application 32 as necessary.

  By performing the above processing, during the role playing game, the load balancer 4 determines the load on each game server 2, distributes each operation request from each terminal device 8 to each game server 2, and Since each game server 2 can access the DB server 3 and proceed with the game while reading and writing data necessary for the game, the game server 2 can be compared with the case where all the games are processed on-memory. The load can be reduced. In this case, there may occur a case where each operation request is processed once through the different game server 2 in the same game of the same player, but each game server 2 is a common DB server 3. Since the game is advanced by reading and writing data necessary for the game, there is no inconsistency in the game.

  In addition, when shifting to a battle game in a role playing game, the load balancer 4 distributes all operation requests from both players in the same battle game to the same game server 2, and this game server. At 2, the battle game is executed on-memory. Therefore, for a complex game with a large amount of processing data, the processing is not slowed down by caching in the memory, and the response time as viewed from the player side is fast.

  That is to say, while taking care that a complex game that requires a huge amount of data processing can be processed without problems, the burden on each game server 2 can be sufficiently reduced during the role-playing game. As described above, various game programs can be processed by each game server 2.

  In particular, in this system, even if communication with one terminal device 8 of both players competing during the execution of a battle game is interrupted due to some trouble, the subsequent game of the player is artificially stored in each game server 2. It has a function to take over until communication is restored by intelligence. Thereby, when it sees from the other player, a battle game can be continued without any problem.

  Such a function requires complicated program processing. However, since the system can sufficiently reduce the burden on each game server 2 as described above, such a program can be processed without any problem. it can.

  Further, during the execution of the normal role-playing game, the load balancer 4 distributes each operation request from each terminal device 8 to each game server 2, and during the execution of the battle game, the load balancer 4 is for each player. Since each operation request is distributed to a specific game server 2, it is possible to avoid the game server 2 even if any of the game servers 2 goes down, and continue the game even if a failure occurs in the game server 2. be able to.

  In addition, all the players who are currently requesting a battle game are matched against each other by processing all the battle game requests from the player in the single battle table 41. Therefore, it is possible to match the players of the battle game. For example, even when two players of acquaintances show and access the network game system 1 and play a game, each player is distributed to a separate game server 2 as in the past. It is possible to prevent a situation in which a battle game by both names cannot be performed.

[Game display screen]
Next, the screen displayed on the display device 25 of the terminal device 8 of the player in the above-described battle game will be described. In this example, the players A and B are playing a battle game, the player A operates the character a being played, the player B operates the character b being played, and the characters a and b An example of making a match will be described.

  FIG. 8 is an explanatory diagram illustrating an example of a screen display in the case of a general battle game. FIG. 8A shows a screen displayed on the display device 25 of the terminal device 8 of the player A who becomes one player (1P), and FIG. 8B shows a terminal of the player B who becomes two players (2P). The screen displayed on the display device 25 of the device 8 is shown. In the screen of the player A in FIG. 8A, the character a operated by the player A who becomes 1P is displayed on the left side of the screen, and the character b which is operated by the player B who becomes 2P is displayed on the right side of the screen. . The left and right arrangements of the characters a and b are the same on the screen of the player B in FIG. 8B, and the character a operated by the player A that is 1P is displayed on the left side of the screen on the screen of the player B. Then, the character b operated by the player B who becomes 2P is displayed on the right side of the screen.

  However, when the terminal device 8 is a mobile phone as in this example, a right-handed person supports the mobile phone with the right hand and operates with the right thumb, for example, a left button (for moving the characters a and b) It is easy to operate, but the right button (moving to the right) is difficult to operate, and key operations that are easy to operate and key operations that are difficult to operate may occur. Nevertheless, in the example of FIG. 8, the key for operating the character differs depending on whether the player becomes 1P or 2P, and the operating conditions differ depending on the accidental condition of 1P or 2P. Will end up. In the above example, a player who is easy to operate the left button (moves the character to the left) but is difficult to operate the right button (moves the character to the right) will move the player forward smoothly at 1P. But changing it doesn't go smoothly. If this becomes 2P, it will not go smoothly to advance the player, but it will go smoothly to change. The difference in operability depending on whether it is 1P or 2P can be said to be very difficult for a player to play. In this case, since the image display is different between the players A and B, it is necessary to prepare different battle applications 33 for the players A and B. Alternatively, if the match application 33 having the same contents can be used by the players A and B, the amount of processing is doubled.

  Therefore, in this embodiment, a screen display as shown in FIG. 9 is performed. That is, on the screen of the player A in FIG. 9A, the character a operated by the player A who becomes 1P is displayed on the left side of the screen, and the character b which is operated by the player B who becomes 2P is displayed on the right side of the screen. ing. This is the same as the example of FIG. On the other hand, in FIG. 9B, on the screen of the player B, the character b operated by the player B who is 2P is displayed on the left side of the screen, and the character a which is operated by the player A who is 1P is on the right side of the screen. It is displayed. That is, in this embodiment, regardless of whether the player is 1P or 2P, the character operated by the player is always displayed on the left side of the screen, and the character operated by the opponent is displayed on the right side (of course, the opposite is true). May be)

  In this way, regardless of whether the player is 1P or 2P, the character that he / she operates is always displayed on the same side of the screen, so that the operability is always the same, making it very easy for the player to play. In addition, since both players who compete will have their own character displayed on their terminal device 8 and the opponent's character the same, the battle application 33 performing such image display is Software of the same processing content can be used for all players, and nevertheless the processing amount does not become large.

  In the above example, the character operated by the player is always displayed on the same side of the screen regardless of whether the player is 1P or 2P. The ease may vary, and there is also a difference between right-handed and left-handed, so the player operates the terminal device 8 to determine whether his character is right or left (whether the opponent's character is left or right) as desired You may make it selectable.

[Opportunity information acquisition function]
In the present embodiment, the function of the battle application 33 automatically acquires predetermined information of the terminal device 8 in which the battle application 33 is set up, and transmits it to a server such as the game server 2 at a predetermined timing. Can be transmitted to the terminal device 8 of the opponent and displayed on the display device 25 (this display is also based on the function of the battle application 33).

  As examples of information that can be acquired from the terminal device 8 by the battle application 33 in this manner, the battery level of the terminal device 8, which is a mobile phone, the volume of sound, and ON / OFF of the backlight of the display device 25 , ON / OFF of vibration, setting for voice incoming / outgoing call, ID information such as mobile phone ID, folding state of terminal device 8, mail status such as presence / absence of mail and presence / absence of unread mail, contents of mail, antenna within range Antenna mode, manner mode with / without manner mode setting, voice call to specified phone number, new registration of phone book group, new registration of phone book entry, bookmark registration of web browser, (when there is schedule registration function Registration of schedule, camera image size setting and shooting attribute setting (if equipped with camera), w The presence or absence of the start-up of b browser or another application, the camera captured image, the contents of the ringtone, there are various such.

  Using these functions, for example, if information that the remaining battery level of the terminal device 8 is low is acquired and displayed on the opponent's screen and notified, it is likely that one player will lose the match game halfway Therefore, it is possible to make the opponent realize that the battery level of the terminal device 8 is low, not to escape.

  Also, if the terminal device 8 is currently folded and displayed on the opponent's screen to notify the player, the game is interrupted because the opponent device does not use the terminal device 8 because of some circumstances. You can also let them know.

  As described above, in this embodiment, the function of the battle application 33 can automatically acquire predetermined information of the terminal device 8 and display it on the opponent's terminal device 8, so that the player I can know the situation.

[Download application]
The application 31 according to the present embodiment purchases the application 31 by the player paying in a predetermined method, downloads the application 31 from the game server 2 or another server (not shown), and sets up the terminal device 8. Use it.

  In the server that downloads the application 31, the number of sales of the application 31 on that day is determined, and a counter function that indicates the remaining amount of the application 31 after sales is provided. Each time, the counter value is decremented by "1". When the value of this counter becomes “0”, subsequent sales and download of the application 31 are rejected.

  FIG. 10A shows a download screen displayed on the terminal device 8 of the player who purchased the application 31 at the time of this download. By operating the button 51, the download of the application 31 is started, and the number of applications 31 currently remaining is displayed in the area of reference numeral 52. Each time one application 31 is sold, the stock quantity 52 is decremented by “1” and displayed. When this value becomes “0”, a screen as shown in FIG. 10B is displayed. Requests for sales and download of the application 31 are rejected.

  Thus, in this embodiment, since the number of applications 31 to be sold per day is limited, an excessive number of applications 31 are sold, and the player's access is excessively concentrated on the network game system 1, which is excessive. This prevents the system from going down due to a heavy load.

It is a block diagram which shows the system configuration | structure of the network game system which is one Embodiment of this invention. It is a block diagram of the electrical connection of each computer which comprises a network game system. It is a block diagram of the electrical connection of a terminal device. It is a flowchart of the process in the case of performing a role playing game. It is a flowchart of a process in the case of requesting a battle game. It is explanatory drawing of a battle | competition table. It is a flowchart of the process of a battle game. It is explanatory drawing which shows arrangement | positioning of each character in the screen display in the conventional battle game. It is explanatory drawing which shows arrangement | positioning of each character in the screen display in the competitive game of this embodiment. It is explanatory drawing of the download screen (a) displayed on a player's terminal device in the case of downloading of an application, and the download screen (b) displayed on a player's terminal device when an application inventory is exhausted.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Network game system 2 Game server 3 Database server 4 Load balancer 8 Terminal device 31 Application 32 Town application 33 Battle application 41 Competitive table

Claims (8)

A network game system that accepts a player's operation request from each terminal device and executes a game via a network,
Multiple game servers,
A database commonly accessed by the game servers;
A load balancer that accepts an operation request from the terminal device, determines a load on each game server, and distributes the operation request from the terminal device to each game server;
A first game execution means provided in each game server, for accessing the database and executing a predetermined game in response to an operation request from the terminal device;
Matching means for performing matching between the player and another player who is the opponent when the player requests execution of a battle game with another player by the terminal device during the game of the predetermined game When,
Distribution provided to the same game server with respect to operation requests from the respective terminal devices of the players who are fighting in the matched game after the matching is established, provided in the load balancer Means,
A second game execution means that is provided in each game server and executes the battle game in an on-memory in response to the operation request that received the distribution;
A network game system characterized by comprising: When there is an operation request for requesting the execution of the battle game from the terminal device, a first identification mark for identifying the terminal device and a second identification mark indicating that the battle game is desired to be executed It further comprises registration means for associating and registering in a common table,
The matching means matches the players of the first identification mark to which the second identification mark is attached with reference to the table.
The network game system according to claim 1. Each of the game servers includes an identification mark assigning unit that assigns the same third identification mark to the terminal device of each player who performs the match game when the match is established and the game is shifted to the match game. In addition,
The distribution means distributes the operation request with the same third identification mark to the same game server when the operation request with the third identification mark is from the terminal device.
The network game system according to claim 1, wherein the network game system is a network game system.   The network game system according to claim 1, wherein the predetermined game is a role playing game. A control method of a network game system that accepts a player's operation request from each terminal device and executes a game via a network,
A first step of receiving an operation request from the terminal device by a load balancer, determining a load on each game server, and distributing the operation request from the terminal device to the game servers;
A second step in which the game server that receives the operation request from the load balancer accesses a database that is commonly accessed by the game servers and executes a predetermined game in response to the operation request from the terminal device; ,
When a player requests execution of a battle game with another player by the terminal device during the game of the predetermined game, matching is performed between the player and another player who is the opponent. Steps,
After the matching is established by the load balancer, a fourth step of distributing an operation request from each terminal device of a player who is competing in the matched game for which the matching is performed to the same game server; ,
A fifth step of executing the battle game on-memory in response to the operation request received by the game server that has received the distribution;
A network game system control method comprising: When there is an operation request for requesting the execution of the battle game from the terminal device, a first identification mark for identifying the terminal device and a second identification mark indicating that the battle game is desired to be executed And further comprising a sixth step of associating and registering in a common table,
The third step refers to matching the players of the first identification mark to which the second identification mark is attached with reference to the table,
The method of controlling a network game system according to claim 5. When the match is established and the game is shifted to the battle game, the game server further includes a seventh step of assigning the same third identification mark to the terminal device of each player who performs the battle game. And
In the fourth step, when an operation request with the third identification mark is received from the terminal device, an operation request with the same third identification mark is distributed to the same game server.
7. The network game system control method according to claim 5, wherein the network game system is controlled . The method for controlling a network game system according to claim 5, wherein the predetermined game is a role-playing game.

Images