JP5021835B1 - GAME SYSTEM, ITS CONTROL METHOD, PROGRAM - Google Patents

Abstract

An object of the present invention is to increase the probability of being assigned to the same group as a user who has an exchange, reduce the processing load related to the battle league, or realize a fair class system.
A user registration request is received from a user terminal, a unique user ID is assigned to the user who made the registration request, and a class ID indicating one class among predetermined classes is assigned to the user. A class is given by associating it with the user ID. Moreover, the friend registration request | requirement about a 2nd user is received from the user terminal of a 1st user among the registered users, and it is made into the friend table linked | related with each user ID of a 1st user and a 2nd user. By adding each other's user ID, a friend relationship is established between the first user and the second user.
[Selection] Figure 1

Description

  The present invention relates to a game system, a control method thereof, and a program, and more particularly to a game system that realizes a battle between users using cards on a game, a control method thereof, and a program.

  For example, some of the competitive games such as baseball and soccer hold a multiplayer participation tournament (league game) online such as a winning game or a brute force game.

  In such a competitive game, for example, a plurality of seasons, which are units of a league game, are provided, and ranking is performed according to the user's winning / losing results for each season, so that the user's improvement awareness is enhanced and long-term Ingenuity to promote proper use is made.

  In addition, some competitive games have introduced a class system that promotes or relegates, for example, in accordance with the results of league matches, in order to make the game system more difficult for users to get bored of. In such a system, it is desired that the user continuously and actively participate in the league game aiming for a higher rank. In addition, in a game system in which a class system is introduced, a user can select a user having the same level of strength and skill level as the user, so that a new user can easily participate and an increase in the number of users is expected.

  In Patent Literature 1, the user's operation skill is evaluated by aggregating the evaluation of the opponent made by the user after the end of the battle, and the users having the same level of operation skill become opponents. A game system for controlling a battle between each other is disclosed.

JP 2006-149425 A

  When the number of users managed in a competitive game increases, the holding period of one league game becomes longer, and the user may get bored with the game. For this reason, it is possible to shorten the holding period of one league game by assigning users who participate in the league game randomly to one of a plurality of groups every season and completing ranking of the competition results in the group. preferable.

  In online battle-type games, as in Patent Document 1, it is more difficult to play against users who are acquaintances in the real world, such as school friends and family, than to play against strangers randomly determined by the system. However, it is preferred because it is expected to improve friendships in the real world. However, when the grouping of participating users is performed at random, it is not necessarily assigned to the same group as the acquaintance's user, and there is a possibility that the user's interest will be aroused. For example, even if the user desires to compete for league rankings within the group, if each user within the group is assigned to a different group, only a relative ranking based on the results of each group can be performed. Therefore, there is a possibility that the user's willingness to participate in the league game is reduced. In the online game, increasing the exchange relationship between users also leads to an increase in the number of users who will be used for a longer period of time. Therefore, it is desirable to consider grouping that does not impede exchange between users.

  On the other hand, when the absolute number of participating users at the beginning of the operation is small, or when the number of participating users can be fractional in grouping, the number of participating users in one group is less than the preset capacity. By joining a virtual user called (Non Player Character), it is possible to play a league game with a limited number of users.

  In the case of a battle-type game, since it is important how attractively the battle situation is presented in a battle in which a user participates in at least one of them, a process for generating a detailed battle situation needs to be executed. For most of the battles, since the battle situation of the battle is information that is not of interest to most users, the process of generating a detailed battle situation can be omitted.

  However, as described above, when grouping of league matches is performed at random, for example, there is a possibility that users and NPCs are allocated in all groups of league matches. In this case, since the number of battles between users or users versus NPCs that cannot be omitted in the battle situation generation process increases, the processing of the server that manages the battles cannot be reduced.

  In addition, in a battle game that introduces a class system, if the upper limit number of users of each class is limited for game balance, users who have not participated in the league for a long time will be included in the class and will be included later. Even if the user who started the game participates in the league, the promotion may not be possible due to the limitation of the number of people.

  An object of the present invention is to solve at least one of the above-described problems.

To achieve one of the objectives of the previous mentioned, the game system of one embodiment of the present invention comprises the following arrangement.

It is a league game in which registered users participate, and the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users classified into each group A registration system for receiving a user registration request from a user terminal and allocating and registering a unique user ID to the user who has made the registration request. For each user, a class that varies depending on the results of the battle between the users, and a class ID indicating one class of a class of a predetermined type is associated with the user ID of the user to give the class. One or more group tables having a unique group ID for adding a class granting means and user IDs of users constituting the group. By creating a group, a group generation unit that generates one or more groups and a user ID associated with a class ID indicating the same class for each registered user are added to the same group table. Accordingly, a classification unit that classifies the group into one or more groups, and a login management unit that manages, for each registered user, the date and time when the login request was last received from the user terminal is associated with the user ID. If the date and time when the log-in request associated with the user ID is received is a predetermined period or more before the current date and time, the classifying means does not add the user ID to the group table, so that the user participates in the league game. A flag indicating that the user I is not assigned to the group. To the association, the league, and the official league game system is held, there is the original league that users who are registered are held in a host, class applying means, for the user who participated in the official league, Based on the ranking determined according to the battle results between the users in each group of the official league match, the rank ID associated with the user ID of the user of the predetermined rank is changed to a different rank ID, and the original league For users who have participated in the battle, the class ID associated with the user ID of the user is not changed based on the results of the battle between the users in each group of the original league match, and the user ID associated with the flag is logged in. After the management means accepts the login request, The class ID indicating the lowest class is associated with the user ID, and the association of the flag is deleted.

According to the present invention by such a configuration, it is possible to realize the equitable class system.

The figure which shows the example of a battle | competition screen displayed on the display apparatus of a user terminal in the online battle | competition card game which concerns on embodiment of this invention. The figure which showed the system configuration | structure of the game system which concerns on embodiment of this invention. The figure which showed the function structure of the game server 201 which concerns on embodiment of this invention. The figure for demonstrating the kind of game provided in the online competitive card game which concerns on embodiment of this invention. The figure which showed the information defined about the official league and each class in the online competitive card game concerning the embodiment of the present invention The figure which shows the example of a screen structure displayed on the display apparatus of a user terminal in case the user is participating in an official league in the online competitive card game which concerns on embodiment of this invention. Flow chart of official league group determination processing according to an embodiment of the present invention The figure for demonstrating friend registration of the users which concern on embodiment of this invention Flow chart of group classification processing according to an embodiment of the present invention Flowchart of error avoidance processing according to Embodiment 2 of the present invention Flowchart of long-term unlogged user exclusion processing according to Embodiment 3 of the present invention The figure which shows the example of a notification screen displayed on the display apparatus of a user terminal, when notifying the class change in an official league in the online competitive card game which concerns on Embodiment 3 of this invention. Flowchart of participation target determination processing according to Embodiment 4 of the present invention The figure which showed the data structure which concerns on embodiment of this invention

[Embodiment 1]
<Game overview>
A game system according to an embodiment of the present invention executes a simulation-type online battle card game that realizes a battle between users using a deck composed of a plurality of cards registered in advance by each user.

  FIG. 1 shows a screen configuration of a battle screen displayed on a display device owned by each user when the users battle each other. In the battle screen 100, the opponent area 101 where the hand held card of the opponent user is displayed, the own area 102 where the own hand held card is displayed, and the cards of each user are arranged, and according to the parameters set for each card Thus, a battle area 103 in which characters drawn on the card battle each other is formed.

  Each of the opponent area 101 and the player's area 102 has an avatar 104 as a user's alternation, a card pile 105 in which cards used in a battle are stacked in a randomly set order, and cards placed in the battle area 103. A waiting area 106, a disposal area 107 where cards that cannot be used are placed, a gauge 108 including a physical strength gauge of the avatar 104, and the like.

  The battle between users is performed by a turn system in which each user acquires a card one by one from the card pile 105 in his area. After the card obtained from the card pile 105 is placed in the waiting area 106, the card is moved to the battle area 103 after a predetermined number of turns have elapsed, and the character drawn on the card becomes ready for battle. Note that the cards stacked on the card pile 105 are displayed, for example, in an inverted state so that the next acquired card is not known. Each card has a waiting time (number of turns) corresponding to the drawn character, and after the waiting time corresponding to the card has elapsed after being placed in the waiting area 106, the card is placed in the battle area 103. Moved.

  When the card is moved to the battle area 103, a battle event between the drawn characters is executed with the opponent user's card that is also placed in the battle area 103. As a result of the battle event between the characters, the card of the character whose physical strength is lost becomes unusable and is moved to the discard area 107. If the opponent user's card is not placed in the battle area 103, the attack target of the character drawn on the card moved to the battle area 103 is the avatar 104 of the opponent user.

  In this way, the battle progresses when the users put out cards in the battle area 103, and all the cards in the deck have been moved to the discard area 107 or the user whose avatar 104's physical strength gauge has become 0 Become a loser.

<System configuration>
A system configuration of a game system that executes a game program of an online battle card game between users as described above will be described. FIG. 2 shows an exemplary configuration of the game system of the present embodiment.

  In the game system of the present embodiment, a user terminal 202a or b such as a PC used by each user is connected to the game server 201 via the network 203. Each user uses, for example, the online battle card game service described above by starting an Internet browser on the user terminal 202, accessing a URL provided by the game server 201, and performing login processing to the game server 201. be able to.

  The game server 201 manages users registered in the online battle card game and executes a game program related to the online battle card game. In accordance with the game program, the game server 201 outputs information via the network 203 so that a predetermined display is performed on the browser executed on the user terminal 202. By executing the game program in the game server 201, the deck organization of each user who uses the user terminal 202 and the battle between users are realized. Note that each of the user terminals 202 may be a PC having a display device and a pointing device, for example.

(Functional configuration of game server 201)
Here, the functional configuration of the game server 201 will be described in detail with reference to FIG.

  The CPU 301 controls the operation of each block included in the game server 201. Specifically, the CPU 301 controls the operation of each block by reading out the game program of the online battle card game of the present embodiment stored in the ROM 302, for example, and expanding and executing it in the RAM 303.

  The ROM 302 is a non-volatile memory and stores, for example, operation of each block and operation parameters used on the game program in addition to the game program of the online battle card game of the present embodiment.

  The RAM 303 is a volatile memory, and is used not only as a game program development area, but also as a temporary storage area for intermediate data output in the operation of each block, for example.

  The network I / F 306 is an interface for connecting the game server 201 to the network 203, and realizes communication connection conforming to a predetermined protocol. The game server 201 is connected to the network 203 via the network I / F 306, thereby receiving a login request from the user terminal 202 that is also connected to the network 203. In addition, the game server 201 transmits and receives information to and from the user terminal 202 logged into the game server 201 via the network I / F 306.

  For example, when information is transmitted from the game server 201 to the user terminal 202 used by one user, an address that identifies the user terminal 202 being used when the user first logs into the game server 201. The CPU 301 associates the information with the user ID of the user (identification information unique to each user) and stores the information in a user management database 304 described later. CPU301 transmits the information produced | generated about the said user ID in execution of a game program to the user terminal 202 using the communication path defined by the address information linked | related with the said user ID.

  As described above, the user management database 304 assigns and manages a unique user ID to each user for all users who log in to the game server 201. The information (user data) managed in the user management database 304 is not limited to the user ID, but for example, as shown in FIG. 14A, a class ID 1402 indicating the class of each user, and card information 1405 owned by each user. And user information such as information 1406 of the created deck. The user information is managed in association with each user ID.

  Registration of a new user in the user management database 304 is performed by the CPU 301 when a registration request from the user terminal 202 via the network 203 is received by the network I / F 306. The CPU 301 acquires information included in the registration request received at the network I / F 306, assigns a unique user ID to the user who made the registration request, and, for example, a user name 1403, connection terminal address information 1404, and the like. Is stored in association with the user ID. Note that the user ID may be generated by the CPU 301 according to a predetermined rule so as to include information on the order of registration in the user management database 304, or information on a character string designated by the user may be used. When using information on a character string designated by the user, an ID indicating the registration order is assigned as the internal ID of the user management database 304 to the user ID.

  The card database 305 manages information on all types of cards used in the online battle card game of this embodiment. The cards are managed as card data to which different card IDs are assigned. For example, as shown in FIG. 14D, the card data includes information on the character name 1441 of the character drawn on the card, and parameters 1442 such as the attack power and defense power of the character on the game. . The parameter 1442 is associated with the card ID 1440 of each card. Note that the card information 1405 owned by each user described above is, for example, logical type information indicating whether or not the card is owned for all types of card IDs, information indicating the number of cards owned, and the like. And stored in the user management database 304.

  In the online competitive card game of this embodiment, the user can organize a “deck” composed of one or more cards for each type of game described later. The deck information 1406 is managed in the user management database 304 in association with the user ID. The deck information organized for one type of game includes a game ID indicating the type of the game, a deck ID for identifying a deck managed by the user, a card ID for one or more cards constituting the deck, and the like.

  The graphic database 307 stores a data group for generating a graphical user interface (GUI) to be displayed on the display device of the user terminal 202 in the online competitive card game of the present embodiment. The CPU 301 reads from the graphic database 307 a user group at the user terminal 202 and a data group for generating a GUI according to the progress of the game, and transmits the data group to the user terminal 202 of each user from the network I / F 306 via the network 203.

  The group database 308 manages a group table created for each “group” that is a user distribution unit in the official league described later in the online competitive card game of the present embodiment. User IDs of users distributed to groups are added to the group table. Each group table is assigned and managed with a unique group ID 1430 as shown in FIG. In the online competitive card game of the present embodiment, the users who participate in the official league are distributed so that a group is composed of users who have been given the same ranks described later. For this reason, each group table includes a class ID 1431 and includes information (1432 and 1433) of users to whom the same class ID as the class ID is assigned.

  In the game system of the present embodiment configured as described above, a game provided to the user and its processing will be described below.

<Game type>
When the user logs into the game server 201, a screen having menu tabs as shown in FIG. 4 is displayed on the display device of the user terminal 202. As shown in the menu tabs 401a to 401d, in the online battle card game of the present embodiment, the “free battle” (401a), “original league” (401b), “official league” (401c), “ Four games of “Interception Battle” (401d) are provided.

Each provided game has the following characteristics.
・ Free Battle: The user chooses a battle user from among other currently logged in users
It is arbitrarily selected, and the battle user set in advance for free battle.
Play with Kikki (Note that there is no need to build a deck for free battles only.
In order to save, the deck set for the original league or the official league
You may substitute it with ki).
・ Original League: One user is the host, and the regulations set by the host
A league game that invites multiple users to participate.
・ Official league: Ranking based on the results of the users held on the game system
All users who have organized an official league deck will participate.
The game against To prevent the length of the league match from extending,
They are assigned to groups and play.
・ Interception Battle: Battle when selected as a free battle battle user by another user
The contents and results are displayed.

  In the present embodiment, the “league game” is described as a round-robin game between users who participate in one group in the league game. For example, a tournament game or a predetermined event period A predetermined number of battles that can be executed by the player may be performed.

<Official league details>
Here, the details of the official league according to the present invention will be described below. In the following description, the following constants are used for convenience. Information indicating each constant is stored in the ROM 302 or the RAM 303.

-Maximum number of participation Umaxt: Number of users who can participate in the official league-Maximum number of users Ucmax: Maximum number of users set for each class of the official league-Total number of groups Gmax: Number of groups set for each class of the official league- Number of real class users Uruser: For each class in the official league, the class is assigned
Number of real users and promotion rank Rup: one group set for each rank of the official league
Conditions for user rank to be promoted to the next higher rank from the first rank / downgrade rank Rdown: one group set for each rank of the official league
Conditions for user rank to be demoted to the next lower rank from the number of people promoted Uup: one group set for each rank of the official league
Number of users to be promoted to the next higher rank from U./Remaining number of people Ustay: One group set for each rank of the official league
Number of users who remain in the same class, number of demoted Udown: one group set for each class in the official league
Number of users who are demoted to the next lower rank / Nondown: One group set for each rank of the official league
Number of users who are not demoted to the next lower rank
(Promotion number Uup + Remaining number Ustay)
・ Total number of promoted Uupt: You are promoted from each rank of the official league to the next higher rank
The total number of people and the total number of remaining people Ustayt: Total number of users remaining in each class of the official league and the total number of demoted Udownt: The user who is demoted to the next lower class from each class of the official league
Undownt: Total number of non-delegated people: You will not be demoted from one rank of the official league to the next lower rank
-Total number of users (promotion total number of people Uupt + remaining total number of people Ustayt)
・ Gruser: Number of distribution groups: Real users are allocated to each official league class.
Number of groups

  As described above, in the official league, all users who have organized a deck for the official league basically become participants. For example, the CPU 301 determines whether one user has already organized an official league deck with reference to user data having the user ID of the user stored in the user management database 304. Specifically, the CPU 301 determines whether or not deck information including the official league game ID exists in the organized deck information 1406 associated with the user ID.

  The official league has a unit called “season” as one session. The length of a season is set according to the period required for execution of a brute force game of a user in one group of league games. For example, when 16 users are assigned to one group and a round-robin battle is played three times for one user per season, the length of the season is (16-1) × 3 = 45 battle lengths. Become.

  Users are ranked for each group according to the number of wins in one season. In this embodiment, all users participating in the official league are ranked for each group, and the rank is promoted or demoted according to the rank within the group.

(Class system)
Here, the class system in the online battle card game of this embodiment will be described.

  In the official league, users having the same level (operation skill or deck configuration) are assigned to the same group, thereby avoiding a battle in which either user advantageously advances the battle situation. In this way, the user's interest can be continued for a long time. Specifically, the CPU 301 refers to the user data stored in the user management database when allocating users to the group, and classifies the group so that the group is configured with user IDs associated with the same class ID. To do. That is, users assigned with the same class are classified into one group. The class information is first given to the user when, for example, a new user registers a user and forms an official league deck. The class assigned at this time is the lowest class among predetermined classes. The CPU 301 stores the class ID indicating the lowest class in the user management database 304 in association with the user ID of the user.

  In the online battle card game of this embodiment, as shown in FIG. 5 (a), five levels are provided. An upper limit number of users (Ucmax1, Ucmax2, Ucmax3, Ucmax4, and Ucmax5) is set for each class. Also, users belonging to each group of the official league are promoted or demoted according to the rank within the group after the end of one season. Specifically, the conditions for class promotion or demotion are determined for each class group, for example, as shown in FIG. 5B, and the number of users determined for each season of the official league between each class. The class fluctuates.

  For example, in C3 which is one of the classes, in one group of the class, three users (promotion number Uup) ranked 1 to 3 after the end of one season are promoted to C2 of the next higher class. To do. In addition, six users (ranked Udown) ranked 11th to 16th are demoted to C4 of the next lower class. For the seven users (remaining number of people Ustay) ranked 4th to 10th, there is no change in the class, and the user remains in the class C3. As shown in the figure, since the total number of groups of C3 is 1600, after the end of one season, 1600 × 3 = 4800 users (promotion total number Uupt) of the entire C3 are promoted to C2, and 1600 × 6 = 9600 people Users of (downgrade total number Udownt) will be demoted to C4.

  In addition, since the above-mentioned original league is held for a part of users with one user as a host regardless of the official league, the battle results of the original league are used to change the class. I can't.

(Bonus match)
When a rank is promoted or demoted based on the number of brute force wins in the group, there must be multiple users with the same number of wins in the ranks to be promoted or demoted (promotion rank Rup, demotion rank Rdown) Can occur. On the other hand, by using the points (winning points) obtained by adding the coefficients set in advance for each of the number of wins and draws in accordance with the respective numbers, the points are calculated between users of the same number of wins. It is possible to make a difference in ranking by adding a difference. However, in a game having a turn system such as the online battle card game of the present embodiment, there is a low possibility that the battle result is a draw, and there is a possibility that a difference cannot be made.

  In this embodiment, a plurality of bonus matches are provided in addition to the round-robin battles of the users belonging to the group described above so that when there are a plurality of users having the same number of wins, the rankings of the users are different. In the bonus match, the user plays against a virtual user called NPC (hereinafter referred to as bonus NPC) generated by the game system and stored in the user management database 304 without receiving a registration request. When the user wins the bonus NPC in the bonus match, the victory does not affect the number of wins in the group round-robin battle, but a certain number of points is added to the above-mentioned winning points. In this way, if the number of wins in the round-robin battle cannot determine the user who will be promoted or demoted, the addition of points based on the results of the bonus match that is irrelevant to the round-robin battle results will be considered. Thus, it is possible to make a difference between users having the same rank.

  In addition, as shown in FIG.14 (c), the information of the battle record of each user in an official league should just be linked | related with the user ID of each user who participates in a group, and is contained in a group table. Specifically, the information (1432, 1433) of each user included in the group table includes the user ID of the user, deck information used in the official league, number of wins, draws, points, and bonus NPC for bonus matches. The results of the battle are included.

  For example, by assigning an important character or the like appearing in a game scenario as a bonus NPC, not only a battle between users but also an effect of making the user enjoy the world view of the game can be provided. In addition, when a user wins a bonus match, a certain number of points that are added to the winning points is set to be larger than the points that are added to the winning points when winning in one round-robin battle. It may be easy to make a difference when there is a crack.

(Virtual user type)
In the online competitive card game of the present embodiment, users (hereinafter referred to as real users) added to the user management database 304 in response to a registration request from the user terminal 202 are distributed to one or more groups in the official league. As a result, when there is a group in which the number of real users in the group is less than the capacity, the CPU 301 adds the virtual user (hereinafter referred to as “fill-up NPC”) to make the group a capacity. It is assumed that the hole filling NPC is provided separately from the bonus NPC. Also, real users and virtual users are managed in the user management database 304 with user IDs generated according to different rules. Whether the user is a real user or a virtual user can be determined by the CPU 301 referring to the user ID. However, the distinction between a real user and a virtual user is not limited to this. For example, in the user management database 304, logical type information indicating whether or not the user is a real user is stored in association with the user ID. There may be.

  In the online competitive card game of this embodiment, as shown in FIG. 5 (b), a fixed number of groups (total number of groups Gmax1, Gmax2, Gmax3, Gmax4, and Gmax5) are created for each class every season. Hold a league match. In the grouping performed before the start of one season of the official league, the real users are distributed to any of the groups created for the assigned class. As a result, for the group in which the number of allocated real users is less than the capacity, the filling NPC is added until the capacity becomes the capacity.

  For example, consider a case where real users to whom a class ID indicating a class is assigned are assigned to groups. At this time, if the number of user IDs of real users added to the group table of one group is less than the group capacity (for example, 16 people) (for example, 5 people), Until the number of users reaches the capacity, the user ID of the filling NPC is added (for example, 16-5 = 11 people).

  As described above, in a battle-type game, a battle between real users and a battle between a real user and a virtual user needs to execute a process for generating a detailed battle situation. In the online battle card game of this embodiment, by limiting the number of groups to which real users are distributed in each class and performing the distribution of real users, the server that minimizes the execution of the process for generating the detailed battle situation Reduce the load. That is, for a group to which no real user is assigned, there is no need to execute detailed battle situation generation processing and report the group's battle record. For this reason, the process of generating the battle situation relating to the battle of the group can be omitted.

  The display screen configuration displayed on the display device of the user terminal 202 in the official league game is, for example, as shown in FIG. As shown in the figure, on the display screen in the official league game, the detailed information 601 of the group in which the user who uses the user terminal 202 participates, the information 602 of the opponent user that the user will play next in the round-robin battle, In-group competition information 603 and the current season's battle results 604 of all users participating in the group are included. Thus, for each user participating in the official league, only information on the group in which the user is participating is provided as a display screen in the official league match. That is, by not notifying the user of a group in which the user is not participating, the process of generating the group results can be omitted.

  In addition, as shown in FIG. 6, in the season record 604, information such as user names (may be user IDs) of all users who participate in the group, the number of wins, the winning percentage, the winning points, etc. Listed according to ranking. In the list, the hole-filling NPC is identified by, for example, clearly indicating “NPC”. In addition, the detailed information 601 of the group includes information on the number of users who are promoted to a higher class and the number of users who are demoted to a lower class among users who participate in the group after the season, and Information on the “number of players”, which is the number of real users, is displayed.

  On the other hand, since the number of promoted people is limited immediately after the start of the online battle card game, real users are biased toward lower ranks. At this time, if real users exceeding the total number of promoted people Uup and remaining people Udown (non-downgraded people Undown) are assigned to the group, there will be real users whose classes are demoted after the season. For example, when one group has a capacity of 16 people and 48 real users are assigned to a group of class C4, the minimum number of groups to which real users are assigned is 3. Then, when 48 real users are assigned to the three groups and the game is played, after the end of the season, the 18 users in the 11th to 16th ranks of each group will be demoted according to FIG. 5B. That is, although there are no real users whose upper limit is the maximum number of users, there are real users who are demoted to a lower class, and therefore it is difficult for real users to increase in the upper class. That is, some real users cannot easily be promoted to a higher rank, and the real user's willingness to participate in the game will be reduced. In addition, real users who have been promoted to a higher rank are unlikely to increase the number of real users who will be opponents, and there are many opportunities for battles with certain real users or hole-filling NPCs, so there is a possibility that they will get bored with the game.

  For this reason, in the online competitive card game of this embodiment, for each class, at least one real user who is given the class exceeds the non-demotion total number Undownt that is not demoted from the class after the season is over. It is assumed that a NPC with a downgrading number Udown is added to the group. For example, as described above, the non-downgraded total number Undownt3 in C3 as a whole is 25600-9600 = 16000 people obtained by subtracting the demoted total number Udownt3 from the upper limit user number Ucmax3 of C3. For this reason, in this embodiment, until the number of real users to whom the class ID of C3 is given exceeds 16000, the CPU 301 adds at least six hole-filling NPCs corresponding to the demoted number Udown3 to one group. Divide. At this time, for example, the CPU 301 may generate a battle situation so that the hole-filling NPC is defeated at the time of the battle with the real user, and the real user may not be in the demoted rank after the end of the season.

  That is, until the number of real users to whom the class is assigned exceeds the number of non-downgraded persons Undown of the class, the CPU 301 distributes the real users to one group in one class of the official league by the number of non-relegated persons Undown. . Then, to each of the groups to which the real users are allocated, a fill-in NPC that is at least a down-filled Udown fill-up NPC that is surely defeated in the battle with the real user is added until the number of users in the group reaches the capacity. By doing so, it is possible to eliminate the number of real users whose classes are demoted and to minimize the number of groups that need to generate a battle situation.

  In addition, when the number of real users to whom one class is given exceeds the total number of non-demotions Undownt of the class, the number of real users is equally distributed to the group of the group total number Gmax of the class. Furthermore, for each group to which real users are assigned, the number of real users who are at least demoted Rdown by adding a hole-filling NPC that must be defeated in the battle with the real users until the number of users in the group reaches the capacity. Can be minimized.

  Note that the CPU 301 determines, for each class, whether or not the hole-filling NPC is always defeated in the battle with the real user. That is, in the process of defeating the hole-filling NPC, the number of real users to whom the class is assigned is, for example, the upper limit user number Ucmax of the same class or a predetermined number in the class higher than the class of the group in which the process is performed. It may be a process performed when the condition is not satisfied. That is, the process is a process for increasing the number of real users to which a higher class is given, and may be stopped when the number of real users to which a higher class is given reaches a desired number. Specifically, the CPU 301 acquires, from the user management database 304, information on the number of real users who have been assigned a higher rank than the class when performing the process of generating the battle status of the official league for one class. Only when the number of persons is less than the number set in advance for each class, the battle situation is generated so that the hole-filling NPC is always defeated.

  Note that it is preferable that the virtual users of the hole-filling NPC and the bonus NPC have different cards and deck configurations depending on each class. In other words, the cards owned by the virtual user are set so that the average value of the parameters becomes higher as the rank is higher. In the online battle card game of this embodiment, a fixed number of hole-filling NPCs and bonus NPCs are prepared for each class. The hole filling NPC and the bonus NPC are stored in the user management database 304 by being assigned different user IDs as in the case of the actual user. In the round-robin battle of users included in a group, it is impossible to include the same user ID for the processing of the battle record. Therefore, in the grouping of each class, the same filling NPC does not exist in one group. It is necessary to. For this reason, even if only one real user is assigned to one group, the same number of NPCs to be filled for one group exists. Any number is acceptable. That is, when the total number of real users and hole-filling NPCs in one group is set as 16 as in this embodiment, the number of hole-filling NPCs prepared for each class may be at least 15.

  In addition, for example, when ranking only users in the highest class, not only in the group but also in the class, and making it public to the previous user, the filling NPC prepared for the highest class is designated as the upper limit user of the class. You should prepare for several minutes. This is to generate a ranking in the highest class even if the real user does not exist in the highest class. The number of bonus NPCs may be determined in accordance with the game scenario. For example, among bonus NPCs prepared during one season, a battle with a different bonus NPC may be performed for each season. You may make it play a part with.

(Official league group decision process)
Here, the official league group determination process in the official league in consideration of the number of groups into which the real user is classified in the game system of the present embodiment will be described with reference to the flowchart of FIG. The processing corresponding to the flowchart can be realized by the CPU 301 reading, for example, a corresponding processing program stored in the ROM 302, developing the program in the RAM 303, and executing the program. In addition, this official league group determination process is demonstrated as what is performed before the start of one season of an official league.

  In step S <b> 701, the CPU 301 selects a class ID of one class that has not yet been grouped with real users among predetermined classes stored in the ROM 302. In addition, for the class indicated by the selected class ID, the CPU 301 includes information indicating the total number of groups Gmax provided in the official league, information indicating the non-downgraded number Undown set for one group of the class, and the class after the season ends. Information indicating the non-downgraded total number of people who are not demoted Undownt (non-downgraded number of people Undown × total number of groups Gmax or promoted total number of people Uupt + remaining total number of people Ustayt) is acquired from the ROM 302.

  In S702, the CPU 301 obtains the number of real users (class real user number Uruser) to which the class indicated by the class ID selected in S701 is assigned. Specifically, the CPU 301 counts the number of real users associated with the class ID selected in S701 and stored in the user management database 304, and acquires information indicating the class real user number Uruser.

  In S <b> 703, the CPU 301 determines whether or not the class real user number Uruser is equal to or less than the total number of non-demotions that are not demoted from the class acquired at least in S <b> 701 after the season is over. If the CPU 301 determines that the number of class real users Uruser is equal to or less than the non-demotion total number Undownt, the CPU 301 moves the process to S704, and if the CPU 301 determines that it is larger than the non-demotion total number Undownt, moves the process to S705.

  In step S <b> 704, the CPU 301 calculates the number of groups to which the real users to which the class indicated by the selected class ID is assigned (the number of distribution groups Gruser). Specifically, the CPU 301 calculates the distribution group number Gruser by dividing the class real user number Uruser by the non-downgraded number Undown in each group and rounding up.

  If it is determined in S703 that the actual number of users Uruser is larger than the total number of non-downgraded Undownt that is not demoted from the class indicated by the selected class ID, the CPU 301 provides the distribution group number for the class acquired in S701 in S705. Set to the total number of groups Gmax.

  In step S <b> 706, the CPU 301 executes a group classification process for distributing the real user to which the class indicated by the selected class ID is assigned to the group of the distribution group number Gruser according to a predetermined rule. Although details of the group classification process will be described later, when the class real user number Uruser is equal to or less than the non-demotion total number Undownt, the CPU 301 causes the number of real users to be assigned to one group to be the non-demotion number Undown. Then, select groups in order and assign real users. When the class real user number Uruser is larger than the non-downgraded total number Undownt, the CPU 301 performs distribution so that the number of real users distributed to each group is equal. That is, the real users of the number of non-relegated people Undown are preferentially assigned to one group.

  In step S <b> 707, the CPU 301 determines whether the real users have been grouped for all of the predetermined types of classes stored in the ROM 302. CPU301 returns a process to S701, when there exists a class which has not yet grouped a real user, and completes an official league group determination process, when the grouping of a real user is completed about all the classes.

(Friend registration)
Moreover, in the online competitive card game of this embodiment, it has a friend registration function in order to promote the exchange between users, and the users who performed friend registration are grouped so that it may be distributed to the same group in an official league match. Classification processing is performed.

  Here, a method for registering friends between users will be described with reference to the drawings. For example, when user A wants to register user B as a friend, user A searches user B on the user search screen, or selects user B from the list of users logged in to the game system. A transition is made to the detail screen of user B as shown in FIG. And user B can be registered as a friend by selecting friend registration button 801 on the screen. The user B registered as a friend is displayed using a friend icon 803 in a friend list area 802 on a screen for confirming detailed information regarding the user A as shown in FIG. 8B, for example.

  The process related to the friend registration is processed by the CPU 301 as follows, for example. When the CPU 301 receives a friend registration request for the user B from the user terminal 202 of the user A via the network I / F 306, the CPU 301 stores the friend table associated with the user ID of the user A stored in the user management database 304. Read information. For example, as shown in FIG. 14B, the friend table is a list to which user IDs of users who have made friend registration requests are added, and the CPU 301 stores the friend table associated with the read user ID of user A. By adding the user ID of user B and storing it again in the user management database 304, a friend relationship between user A and user B is established. In this embodiment, when a friend registration request is received from a user, the user ID of the registered user is added to the friend table associated with the user ID. However, the friend registration method of the present invention is not limited to this. Not limited to. For example, when the CPU 301 receives a friend registration request of the user B from the user terminal 202 of the user A, the CPU 301 first requests the user B to approve the friend registration of the user A, and the user B authorizes the approval. At this time, the user ID may be added to the friend table associated with the user ID of each of the user A and the user B, and a friend relationship may be established between the user A and the user B.

  When the CPU 301 receives a request for displaying detailed information about a user from the user terminal 202, the CPU 301 first reads a friend table associated with the user ID of the user from the user management database 304. The CPU 301 acquires the graphic information associated with the user ID included in the table from the graphic database 307 and draws it as the friend icon 803 in the friend list area 802 of FIG.

(Group classification processing)
Here, regarding the group classification process in the official league group determination process described above, which classifies an arbitrary user and a friend user who has a friend relationship with the user and has the same rank as the user, into the same group, This will be described in detail with reference to the flowchart of FIG. In addition, since this group classification | category process is a process called in the official league group determination process mentioned above, it is performed for every class based on the information of the number of groups (sort group number) which classifies the determined real user.

  In step S901, the CPU 301 classifies the set of real users to which the class indicated by the class ID to be processed is assigned into two sets depending on whether or not a friend user who has a friend relationship with the user is included in the set.

  Specifically, the CPU 301 first reads the user ID of the real user associated with the class ID to be processed from the user management database 304 and adds it to the real user list in the RAM 303. Then, for each user ID added to the real user list, the CPU 301 reads from the user management database 304 the information in the friend table associated with the user ID. Furthermore, when there is a user ID included in both the friend table and the real user list, the CPU 301 displays the user ID included in both the user ID and the user ID associated with the friend table within the same class. While adding to the list A of the RAM 303 which is a list of existing real users, the user ID added to the list A is deleted from the real user list.

  By repeatedly executing such processing for each user ID included in the real user list, the user IDs of real users who have friend users in the same class can be separated into the list A. In addition, the real user list after the process of this step is a list including only user IDs of real users who do not have friend users in the same class. In the following description, the processed real user list will be described as list B.

  In step S902, the CPU 301 classifies real users included in the list A into a group of users having a user relationship. Specifically, the CPU 301 randomly selects a user ID included in the list A, and has four friend users among the user IDs of the friend users included in the list A that have a friend relationship with the user ID. ID is selected at random. At this time, when the number of friend users having a friend relationship is less than four, the CPU 301 selects the user IDs of all friend users having a friend relationship. Then, the CPU 301 adds the randomly selected user ID and the user IDs of up to four friend users to the list C of the RAM 303 as a structure composed of the user IDs of up to five users having a friend relationship. To do. At this time, the CPU 301 deletes the user ID included in the structure from the list A. That is, in this step, the CPU 301 creates a set of users having a friend relationship, which is composed of less than half of the number of non-relegated people Undown for one group in the class to be processed.

  In this step, the CPU 301 repeats such grouping processing until there is no user ID included in the list A or until the number of structures added to the list C is twice the number of distribution groups Gruser. In addition, by executing the grouping process, there may be a case where the friend user of the user has already been grouped for the randomly selected user, and the number of user IDs of the friend users included in the list A is zero. . In such a case, since the grouping cannot be performed for the selected user, the CPU 301 moves the user ID of the selected user to the list B. When the number of structures added to the list C is twice the number of distribution groups Gruser and the grouping process is stopped, the CPU 301 moves the remaining user IDs included in the list A to the list B. To do.

  In step S <b> 903, the CPU 301 creates a group table for the distribution group number Gruser in the group database 308 in association with the class ID to be processed. At this time, it is assumed that the created group table of the number of distribution groups Gruser is associated with different group IDs and managed independently.

  In the processing from S904 to S907, the CPU 301 adds the user IDs of the real users included in the list B and the list C to the group table in order, so that each of the group tables for the distribution group number Gruser created in the group database 308 in S903. To add real users with the number of non-downgraded people Undown.

  In step S <b> 904, the CPU 301 selects a group table in which the real user's user ID has not yet been added from among the group tables for the number of distribution groups created in the group database 308.

  In step S905, the CPU 301 reads two structures from the list C, and adds all the user IDs included in the structures to the group table selected in step S904. The CPU 301 deletes the two read structures from the list C. When there is only one structure in the list C, the CPU 301 adds only the user ID included in the one structure to the selected group table. If there is no structure included in the list C, the CPU 301 moves the process to S906 without performing the process of this step.

  In step S906, the CPU 301 determines whether or not the number of user IDs added to the selected group table, that is, the number of user IDs included in the two structures read in step S905 is equal to the non-relegated number Undown. If the CPU 301 determines that the number of user IDs added to the selected group table is equal to the number of undegraded people Undown, the process proceeds to S907. If the CPU 301 determines that the number is not less than the number of undegraded people Undown, the process proceeds to S906. .

  In step S <b> 906, the CPU 301 randomly selects and adds user IDs included in the list B to the group table, thereby setting the number of user IDs included in the currently selected group table as the non-downgraded number Undown. At this time, the CPU 301 deletes the user ID added to the group table from the list B as in S905. If the number of user IDs included in the selected group table does not reach the non-downgraded number Undown even if all the user IDs included in the list B are added in this step, the CPU 301 displays the selected group table in the selected group table. All the user IDs may be added and the process proceeds to S907. If there is no user ID included in the list B, the CPU 301 moves the process to S907 without performing the process of this step.

  In step S <b> 907, the CPU 301 determines whether a user ID has been added to all the group tables for the number of distribution groups created in the group database 308. If the CPU 301 determines that a user ID has been added to all the group tables for the number of sorting groups, the process proceeds to S908. If the CPU 301 determines that there is a group table to which no user ID has been added, the process returns to S904.

  In step S908, the CPU 301 determines whether a user ID included in the list B exists. That is, in this step, the CPU 301 determines whether there is a user ID that has not yet been added to the group table among the real users of the class to be processed. If the CPU 301 determines that the user ID included in the list B exists, the process proceeds to S909. If the CPU 301 determines that the user ID included in the list B does not exist, the process proceeds to S910.

  In step S <b> 909, the CPU 301 equally distributes and adds the user IDs included in the list B to the group table of the distribution group number Gruser created in the group database 308. In addition, when the number of user IDs included in the list B is divided by the distribution group number Gruser, when the fraction exists, the distribution is not equal, and the group for the fraction is added to the group table more than other groups. Needless to say, the number of user IDs increases.

  In S910, the CPU 301 refers to each of the group tables of the number of distribution groups created in the group database 308, and if the added real user's user ID is less than the number of users included in the group, the class ID to be processed The user ID of the virtual user associated with the user ID is read from the user management database 304 and added, and the number of user IDs included in the group table is set as the capacity number, thereby completing the group classification process.

  By doing in this way, in the online competitive card game of this embodiment, in a group classification of a real user in an official league, a real user can be classified so that users who have a friend relation may be included in the same group. . In the present embodiment, the group of users having a friend relationship has been described as being grouped to be half the number of non-downgraded people Undown. However, the present invention is not limited to this, and the grouping is arbitrary. What is necessary is just to carry out so that the users who have a friend relationship in a class may be included in the same group.

  Further, in the group classification of real users in the official league as described above, the fact that users having friendships are classified into the same group is displayed on the display device of the user terminal 202 as shown in FIG. 6, for example. Notification is made in the friend list 605 included in the screen. Specifically, the user may be notified by adding the participation notification 606 to the icon of the user who has a friend relationship.

  As described above, the game system according to the present embodiment can reduce the processing load related to the battle league, which increases the probability of being assigned to the same group as the user having the exchange. Specifically, the game system accepts a user registration request from the user terminal, assigns a unique user ID to the user who made the registration request, and further indicates a class indicating one class among predetermined classes. A class is assigned by associating the ID with the user ID of the user. Moreover, the friend registration request | requirement about a 2nd user is received from the user terminal of a 1st user among the registered users, and it is made into the friend table linked | related with each user ID of a 1st user and a 2nd user. By adding each other's user ID, a friend relationship is established between the first user and the second user. When adding a registered user to one or more group tables composed of a predetermined number of users belonging to the same class, the friend table associated with the user ID of the user is associated with the user ID. If there is a user ID associated with the same class ID as the class ID, the user ID of the user to be added and the user ID associated with the same class ID are added to the same group table.

[Embodiment 2]
In the online competitive card game of the first embodiment described above, the rank given to the real user is promoted or demoted according to the battle record in each group after the end of the season of the official league. As shown in FIG. 5 (b), the total number of real users who are promoted to a higher rank (promotion total number Uupt) and the lower rank are basically between two classes where promotion and demotion are performed. The total number of real users to be demoted (total number of demoted Udownt) is set to be equal. However, if unexpected processing occurs when a high processing load is applied to the game server 201, there is a possibility that real users exceeding the upper limit number of users may be assigned in one class. When such a situation occurs, the game server 201 may freeze during the above-described group classification. Therefore, in this embodiment, an error avoidance process assuming the situation will be described.

<Error avoidance processing>
Hereinafter, an error avoidance process when a real user exceeding the upper limit number of users is assigned to one class in the game system of the present embodiment will be described with reference to the flowchart of FIG. The processing corresponding to the flowchart can be realized by the CPU 301 reading, for example, a corresponding processing program stored in the ROM 302, developing the program in the RAM 303, and executing the program. In addition, this error avoidance process predetermines the number of user IDs associated with one class ID for the class indicated by the class ID when performing the class change process according to the results of each group after the official league season ends. It is assumed that the process is executed when the CPU 301 determines that the number of user IDs (upper limit user number Ucmax) that can be added to the group table of the total group number Gmax is exceeded.

  In step S <b> 1001, when the class change process is performed, the CPU 301 first identifies a class (error class) in which the class ID of the class is associated with the user ID of a real user that exceeds the upper limit number of users Ucmax determined in advance for the class. . Then, the group total number Gmax is temporarily raised for the specified error class. At this time, the group total number G′max that is temporarily raised is such that the number of user IDs that can be added to the group table of the group number G′max after the raising exceeds the number of user IDs that are associated with the class ID of the error class. Set to

  In S1002, the CPU 301 determines, for each class that can be promoted and demoted from the error class, the upper limit user number Ucmax of each class, and the number of real users (class actual user number Uruser) to which the class is assigned after the class change process. Are obtained, and after class change processing, the class real user number Uruser real user grasps the class that is less than the upper limit user number Ucmax.

  Specifically, when the CPU 301 performs the class change process for each of the classes one level higher (for example, C2) and one level lower (for example, C4) than the error class (for example, C3), the class of the class is displayed. The number of user IDs associated with the ID (number of class real users Uruser2, Uruser4) is acquired from the user management database 304. At this time, the CPU 301 obtains information on the upper limit number of users (Ucmax2, Ucmax4) from the ROM 302 for each of the upper and lower ranks of the error class. Then, the CPU 301 subtracts the number of actual class users after the class change process from the upper limit number of users for each of the upper and lower classes of the error class. The CPU 301 determines that the subtraction result is greater than 0, that is, the class whose number of real users is less than the maximum number of users after class change processing is one class higher than the error class, one class lower than the error class, and error. It is determined whether the class is both one class higher and one class lower.

  If the CPU 301 determines that a class whose number of real users Uruser after the class change process is less than the upper limit user number Ucmax is one class higher than the error class, the CPU 301 moves the process to S1003 and selects one of the error classes. If it is determined that it is a lower class, the process proceeds to S1004. On the other hand, if the CPU 301 determines that the class whose number of actual users Uruser after the class change process is less than the upper limit user number Ucmax is both one higher level and one lower level of the error class, the process proceeds to S1005. .

  In step S <b> 1003, the CPU 301 increases the number of real users to whom an error class is given that is promoted to a class one level higher than the error class after the end of the next season. Specifically, after the end of the next season, the CPU 301 increases the number of real users that promote the class so that the number of user IDs to which the class ID of the error class is assigned becomes the upper limit number of users (Ucmax3) before the increase. Set the total number of promoted people Uupt).

  Similarly, in S1004, the CPU 301 increases the number of real users to whom an error class is assigned that is demoted to the next lower class of the error class after the end of the next season. Specifically, after the next season, the CPU 301 counts the number of real users to demote the class (total demoted) so that the number of user IDs to which the class ID of the error class is assigned becomes the upper limit user number Ucmax before the increase. Set the number of people Udownt).

  In step S <b> 1005, after the next season, the CPU 301 is promoted to an upper rank of the error class and demoted to a lower rank. Increase the total number of demoted Udownt). Specifically, after the end of the next season, the CPU 301 counts the number of user IDs to which an error class, a class that is one level higher than the error class, and a class ID that is one level lower than the error class are allocated (class real users). The number of real users to be promoted or demoted is set so that the numbers Uruser2, Uruser3, and Uruser4) become the upper limit number of users (Ucmax2, Ucmax3, and Ucmax4) originally assigned to each class.

  As described above, when the class change process at the end of one season is performed, even if the class actual user number Uruser for one class exceeds the upper limit user number Ucmax determined in advance for the class, In particular, the error is allowed by raising the upper limit number of users Ucmax, and the error is corrected after the end of the next season by controlling the promotion and demotion of the class.

  In the present embodiment, it can be easily imagined that the processing described above can be applied to C2 to C4 in which upper and lower classes exist. Further, it will be understood that the uppermost class C1 can be applied by excluding the process of comparing the upper limit user number Ucmax and the class actual user number Uruser for the upper class. That is, for C1, the CPU 301 may omit the process of S1002 and move the process to S1004.

  In addition, for class C5, which is the lowest level, there is a possibility that a user who has organized a deck for the official league may be newly added. Therefore, immediately before the official league group determination process for allocating real users of the official league, It is sufficient to process as follows. The CPU 301 provides information on the number of class real users Uruser5 to which the class ID of C5 is assigned, the number of class real users Uruser4 to which the class of C4 corresponding to the rank one higher is assigned, and the upper limit number of users Ucmax4 and Ucmax5 of each class Are acquired from the user management database 304 and the ROM 302, respectively. Then, the CPU 301 compares the number of real users exceeding the upper limit number of users Ucmax5 in C5 (Uruser5-Ucmax5) with the number of real users that can be added to C4 (Ucmax4-Uruser4). At this time, if Uruser5-Ucmax5> Ucmax4-Uruser4, the C5 class real user number Uruser5 cannot be made the upper limit user number Ucmax5 after the end of the season. For the real user of C5, it is only necessary to notify the fact that the number of users has reached the capacity after the end of the season, and not to be distributed in the next season.

  In the present embodiment, a method has been described in which, when an error occurs in which a class ID of the class is associated with a user ID that exceeds the user upper limit for one class, the error is corrected after the end of the next season. However, the implementation of the present invention is not limited to this, and a configuration in which the upper limit number of users can be permanently raised may prevent further errors.

[Embodiment 3]
The online battle card game of the present embodiment and the above-described embodiment proceeds so that the user does not need to log in to the game system for all the battles, or all the users who participate in the league battle do not log in. As described above, the process related to one season of the official league is automatically started. The detailed battle situation generated for the battle between users is automatically generated according to the deck used by each of the users who compete. In addition, as described above, in one season of the official league, all users who have organized an official league deck are basically targeted for participation.
However, in the online battle card game that automatically progresses in this way, users who have not logged in for a long period of time are also included as participants, so there is a possibility that the service will be broken. Specifically, the number of real users who participate in the official league is the upper limit of participation in the entire official league by automatically registering the user ID information of users who do not actually want to use the service in the official league. New users may not be able to participate in the official league because Umaxt may be reached.

  In the present embodiment, a method for making it difficult for the number of real users participating in the official league to become the participation upper limit number Umaxt of the entire official league by forcibly removing users who have not logged in for a long period of time will be described.

<Long-term unlogged user exclusion process>
Hereinafter, long-term unlogged-in user exclusion processing that forcibly excludes users who have not logged in for a long time among users who are candidates for participation in the official league in the game system of the present embodiment, using the flowchart of FIG. explain. The processing corresponding to the flowchart can be realized by the CPU 301 reading, for example, a corresponding processing program stored in the ROM 302, developing the program in the RAM 303, and executing the program. In addition, this long-term unlogged-in user exclusion process shall be performed after the end of one season of the official league and before executing the official league group determination process related to the next season.

  In this embodiment, when a user login request is received from the user terminal 202 via the network I / F 306, the CPU 301 associates the login request with the user ID of the user who has received the login request. Information 1408 (FIG. 14A) is stored in the user management database 304.

  In S1101, the CPU 301 selects the user ID of one real user among all real users of the official league participants, and is stored in the user management database 304 in association with the user ID. It is determined whether or not the date and time information when the login request is accepted indicates a date and time that is a predetermined period or more before the current date and time. If the CPU 301 determines that the date and time information associated with the user ID of the selected real user and the date when the login request was last received indicates a date and time that is a predetermined period or more before the current date and time, the process proceeds to step S1102. If it is determined that the date and time within a predetermined period is indicated, the process proceeds to S1103.

  In S1102, the CPU 301 stores logical flag information 1409 indicating that the real user indicated by the selected user ID is not allowed to participate in the official league in the user management database 304 in association with the user ID.

  In S1103, the CPU 301 determines whether or not the determination of whether or not to participate in the official league is completed based on the date and time when the log-in request was last received for the user IDs of all real users of the official league participants. To do. CPU301 completes this long-term unlogged-in user exclusion process, when it is judged that judgment of the participation possibility in an official league is completed with respect to the user ID of all the real users of the participation candidate of an official league, and participation possibility If it is determined that there is a user ID for which this determination has not been completed, the process returns to S1101.

  In the present embodiment, for a real user whose date and time when the login request was last received in this way is more than a predetermined period before the current date and time, by associating flag information indicating that the user ID of the user is not made into the official league In the above-described official league group determination process and group classification process, the user can be excluded from being added to the group table.

  When a login request is received again from the user whose flag information indicating that the official league is not to be associated with the user ID is received via the network I / F 306, the CPU 301 has a flag associated with the user ID of the user. Delete information. As a result, the user is able to participate in the official league again, but the class information given to the user before the official league is disabled is deleted, and a predetermined type of It is assumed that the class ID of the lowest class among the classes is associated with the user ID of the user. This is because there is a possibility that the number of real users to whom the class that has been given to the user has been assigned is the user upper limit number that has already been determined for the class. At this time, for example, the CPU 301 may cause the display device of the user terminal 202 of the user to display a notification screen indicating that the lowest class as shown in FIG.

[Embodiment 4]
In Embodiments 1 to 3 described above, all users who have organized a deck for the official league are assumed to be participants in the official league. However, as described in Embodiment 3, real users who are participants If the number exceeds the maximum participation number Umaxt of the entire official league, a real user who cannot participate in the official league will appear.

  In the online competitive card game as in Embodiments 1 to 3 described above, it is preferable to increase the number of long-term users rather than single users in terms of operation. However, in the following cases, long-term users However, there is a possibility that it will be impossible to participate in the official league. For example, even if a long-term user removes a deck organized for the official league once and then leaves the official league once and then tries to form an official league deck and join the official league again, When the number of participating users has reached the participation limit for the entire official league, the user may not be able to participate in the official league until the number of servers is increased. As a result, it will arouse the interest of users for a long time.

  In this embodiment, in order to solve such a problem, a method for facilitating selection of a long-term use user as an official league participant will be described.

(Participation target decision processing)
Hereinafter, a participation target determination process for determining a user who is a target participant of the official league in the game system of the present embodiment will be described with reference to the flowchart of FIG. The processing corresponding to the flowchart can be realized by the CPU 301 reading, for example, a corresponding processing program stored in the ROM 302, developing the program in the RAM 303, and executing the program. In addition, this participation object determination process shall be performed before performing the official league group determination process mentioned above.

  In this embodiment, the CPU 301 associates flag information 1420 indicating that the user has participated in the last finished season with the user ID for each user who participated in the last finished official league season. Assume that it is stored in the user management database 304. Further, the upper limit number Umaxt of participation in the entire official league may be set to a value (for example, 100,000 people) smaller than the number obtained by adding the upper limit number of users Ucmax determined in advance for each class.

  In step S <b> 1301, the CPU 301 sets a user ID associated with flag information indicating that the user ID is the last completed season among the user IDs of real users stored in the user management database 304. First, it selects as a real user of a candidate for participation in the official league of the next season. Specifically, CPU301 is a flag which shows that it is a candidate for participation in the official league of the next season with respect to the user ID with which the flag information which showed having participated in the season which ended last was associated. Information 1411 is associated and stored in the user management database 304.

  In addition, flag information indicating that it is a candidate for participation in the official league of the next season is used as flag information indicating that it participated in the season that ended last when the next season ends. May be. Further, this step may be targeted for a user ID that is not associated with flag information indicating that it will not participate in the official league after the long-term unlogged user exclusion process of the third embodiment described above is executed.

  In S <b> 1302, the CPU 301 refers to the user management database 304, and the number of user IDs associated with flag information indicating that the person is a candidate for participation in the official league of the next season is the upper limit number of participations in the entire official league. It is determined whether or not it is smaller than Umaxt. CPU301 moves a process to S1303, when the number of user IDs with which the flag information which shows that it is a candidate for participation in the official league of the next season is smaller than the participation upper limit number Umaxt of the whole official league, moves to S1303. If it is equal to or greater than the participation limit for the entire league, this participation target person determination process is completed.

  In S <b> 1303, the CPU 301 stores the user ID among the user IDs of real users that are stored in the user management database 304 and are not associated with flag information indicating that they are candidates for participation in the official league of the next season. The user ID having the smallest registration order information in the user management database 304, that is, the oldest user ID in time series order is selected. In this step, the user ID already selected for performing the processing from S1304 onward is excluded from the selection target, and if the selection target user ID does not exist, the participation target person determination processing is completed.

  In step S <b> 1304, the CPU 301 acquires a class ID associated with the user ID selected in step S <b> 1303 from the user management database 304. Then, the CPU 301 determines in advance the number of user IDs associated with the class ID, and associated with flag information indicating that the person is a participant in the official league of the next season, for the class indicated by the class ID. It is determined whether or not the upper limit number Ucmax is exceeded. That is, in this step, the CPU 301 determines whether or not there is a vacancy in which a real user can be added to the class group associated with the user ID selected in S1303. If the CPU 301 determines that there is a vacancy in which a real user can be added to the class group associated with the selected user ID, the process is transferred to step S1305, and if it is determined that there is no room, the process returns to step S1302.

  In S1305, the CPU 301 associates the user ID selected in S1303 with flag information indicating that the user ID is a candidate for participation in the official league of the next season, stores it in the user management database 304, and returns the process to S1302. .

  By doing in this way, a user who seems to be a long-term user and who has an old date and time when a registration request is made can be preferentially targeted for participation in the official league.

  In the description of each embodiment described above, a game system that realizes a battle between users using a card via a network has been described. However, the game system of the present invention is not limited to this. It will be easily understood that the embodiment of the present invention can be applied to any game system having a league game as a form for realizing a battle between users.

Claims (9)

A league game in which registered users participate, wherein the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users are classified into each group. A game system for holding a league game in which each other competes,
A registration means for accepting a user registration request from a user terminal and assigning and registering a unique user ID to the user who has made the registration request;
For each of the registered users, a class ID that varies depending on the results of the battle between the users and indicates a class of a class of a predetermined type is associated with the user ID of the user. A class granting means for granting a class by
A group generating means for generating the one or more groups by generating one or more group tables having a unique group ID for adding user IDs of users constituting the group;
Classifying means for classifying each of the registered users into the one or more groups by adding a user ID associated with a class ID indicating the same class to the same group table;
For each of the registered users, login management means for managing the date and time when the login request was last received from the user terminal in association with the user ID,
If the date and time when the log-in request associated with the user ID is received is a predetermined period or more before the current date and time, the classifying means does not add the user ID to the group table, In addition to making the state not to participate in the battle, a flag indicating that it is not assigned to a group is associated with the user ID,
The league match includes an official league match held by the game system and an original league match held by the registered user as a host,
The class providing means is:
About the user who participated in the said official league game, it was related with the user ID of the user of the predetermined order based on the order determined according to the battle record between the users in each group of the official league game Change the class ID to a different class ID,
For users who participated in the original league game, without changing the class ID associated with the user ID of the user based on the results of the battle between users in each group of the original league game,
After the login management means accepts a login request for the user ID associated with the flag, the class ID indicating the lowest class among the predetermined types of classes is associated with the user ID, and the flag A game system characterized by deleting the association. A league game in which registered users participate, wherein the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users are classified into each group. A game system for holding a league game in which each other competes,
  Registration means for accepting a user registration request from a user terminal, assigning and registering a unique user ID to the user who made the registration request;
  For each of the registered users, a class ID that varies depending on the results of the battle between the users and indicates a class of a class of a predetermined type is associated with the user ID of the user. A class granting means for granting a class by
  A group generating means for generating the one or more groups by generating one or more group tables having a unique group ID for adding user IDs of users constituting the group;
  Classifying means for classifying each of the registered users into the one or more groups by adding a user ID associated with a class ID indicating the same class to the same group table;
  For each of the registered users, login management means for managing the date and time when the login request was last received from the user terminal in association with the user ID,
  If the date and time when the log-in request associated with the user ID is received is a predetermined period or more before the current date and time, the classifying means does not add the user ID to the group table, In addition to making the state not to participate in the battle, a flag indicating that it is not assigned to a group is associated with the user ID,
  The league match includes an official league match held by the game system,
  The class providing means is:
    About the user who participated in the said official league game, it was related with the user ID of the user of the predetermined order based on the order determined according to the battle record between the users in each group of the official league game Change the class ID to a different class ID,
    After the login management means accepts a login request for the user ID associated with the flag, the class ID indicating the lowest class among the predetermined types of classes is associated with the user ID, and the flag Remove the association
  The official league in which the number of user IDs associated with the changed class ID is determined in advance for the class indicated by the class ID as a result of the class ID associated with the user ID being changed by the class granting unit If the number of user IDs that can be added to the group table for the maximum number of groups in a match is exceeded, the official league match will be held with the maximum number of groups raised.
A game system characterized by that. The league game defines a predetermined holding period as a season, and for each of the users who participated in the league game of the last season at least, a flag indicating that the user has participated in the league game of the last season ended And a participation management means for associating the user ID with the user ID,
The registration means is, manages the user's registration in chronological order,
The classification means, for each class, if the number of user IDs associated with the class ID of the class exceeds the number of user IDs that can be added to the group table of the upper limit number of groups predetermined for the class, The user ID associated with a flag indicating that the player has participated in the league game of the last season among the user IDs associated with the class ID of the last is added to the group table preferentially, and then the last flag indicating that had participated in the league of the terminated season is not associated with the user ID, the according to claim 1 or 2, characterized in that added to the group table to the registration order of the user Game system. If the number of user IDs associated with each class ID exceeds the number of user IDs that can be added to the group table of the group upper limit number for the class indicated by the class ID, the group upper limit number is temporarily increased to After holding the official league match,
The class granting unit increases the group upper limit number by increasing the number of user IDs that change the class ID in the group table to which the user ID associated with the class ID of the class whose group upper limit number has been increased is added. 3. The game system according to claim 2 , wherein the number of user IDs associated with class IDs of classes is set to the number of user IDs that can be added to the group table of the upper limit number of groups before being raised. A league game in which registered users participate, wherein the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users are classified into each group. A control method of a game system for holding a league game in which each other competes,
A registration step in which the registration means of the game system accepts a user registration request from a user terminal, assigns a unique user ID to the user who made the registration request, and
The class granting means of the game system is a class that varies for each of the registered users depending on the battle results between the users, and indicates a class of a class of a predetermined type. A class granting step of granting a class by associating the ID with the user ID of the user;
A group generation step of generating one or more groups by generating one or more group tables having unique group IDs, wherein the group generation means of the game system adds user IDs of users constituting the groups; ,
The classification means of the game system classifies each of the registered users into the one or more groups by adding a user ID associated with a class ID indicating the same class to the same group table. A classification process to
A login management step in which the login management means of the game system manages, for each of the registered users, the date and time when the login request was last received from the user terminal in association with the user ID;
In the classification step, when the date and time when the log-in request associated with the user ID is received is a predetermined period or more before the current date and time, the classification unit does not add the user ID to the group table, A state in which the user is not allowed to participate in the league game, and a flag indicating that the user is not assigned to the group is associated with the user ID,
The league match includes an official league match held by the game system and an original league match held by the registered user as a host,
In the class granting step, the class granting means is:
About the user who participated in the said official league game, it was related with the user ID of the user of the predetermined order based on the order determined according to the battle record between the users in each group of the official league game Change the class ID to a different class ID,
For users who participated in the original league game, without changing the class ID associated with the user ID of the user based on the results of the battle between users in each group of the original league game,
After the login management means accepts a login request for the user ID associated with the flag, the class ID indicating the lowest class among the predetermined types of classes is associated with the user ID, and the flag A game system control method, wherein the association is deleted. A league game in which registered users participate, wherein the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users are classified into each group. A control method of a game system for holding a league game in which each other competes,
  A registration step in which the registration means of the game system accepts a user registration request from a user terminal, assigns a unique user ID to the user who made the registration request, and
  The class granting means of the game system is a class that varies for each of the registered users depending on the battle results between the users, and indicates a class of a class of a predetermined type. A class granting step of granting a class by associating the ID with the user ID of the user;
  A group generation step of generating one or more groups by generating one or more group tables having unique group IDs, wherein the group generation means of the game system adds user IDs of users constituting the groups; ,
  The classification means of the game system classifies each of the registered users into the one or more groups by adding a user ID associated with a class ID indicating the same class to the same group table. A classification process to
  A login management step in which the login management means of the game system manages, for each of the registered users, the date and time when the login request was last received from the user terminal in association with the user ID;
  In the classification step, when the date and time when the login request associated with the user ID is received is a predetermined period or more before the current date and time, the classification means does not add the user ID to the group table, A state in which the user is not allowed to participate in the league game, and a flag indicating that the user is not assigned to the group is associated with the user ID,
  The league match includes an official league match held by the game system,
  The class granting means is the class granting step,
    About the user who participated in the said official league game, it was related with the user ID of the user of the predetermined order based on the order determined according to the battle record between the users in each group of the official league game Change the class ID to a different class ID,
    After the login management means accepts a login request for the user ID associated with the flag, the class ID indicating the lowest class among the predetermined types of classes is associated with the user ID, and the flag Remove the association
  The official league in which the number of user IDs associated with the changed class ID is determined in advance for the class indicated by the class ID as a result of the change of the class ID associated with the user ID in the class granting step If the number of user IDs that can be added to the group table for the maximum number of groups in a match is exceeded, the official league match will be held with the maximum number of groups raised.
A game system control method characterized by the above. The program for functioning a computer as each means of the game system of any one of Claims 1 thru | or 4 . A league game in which registered users participate, wherein the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users are classified into each group. A game system for holding a league game in which each other competes,
The league match includes an official league match held by the game system and an original league match held by the registered user as a host,
The game system includes a user ID display unit indicating a unique user ID in a user management database assigned to a user who has made a registration request in a user interface displayed on a display unit;
A class that is given to the user who has made the registration request and fluctuates depending on the results of the battle between the users, and a class display unit that indicates one class of a class of a predetermined type;
It is a group member list for notifying user IDs of users classified into the respective groups, and among the registered users, the date and time when the user last logged into the game system is more than a predetermined period before the current date and time. A group display unit that displays a group member list that does not include the user ID of the user,
In the class display section,
For users who participated in the official league match, the assigned rank is changed and displayed for the users in a predetermined order determined according to the battle results between the users in each group of the official league match. And
For users who participated in the original league game, the same class as the class that was given before the battle is displayed regardless of the battle results between the users in each group of the original league game,
User who made the registration request, when log back in to or more after the predetermined period of time after last logged in to the game system, the lowest rank among the predetermined type of class is displayed A game system characterized by that. A league game in which registered users participate, wherein the registered users are classified into one or more groups each consisting of users belonging to the same class, and the users are classified into each group. A game system for holding a league game in which each other competes,
  The league match includes an official league match held by the game system,
  In the game system, the user interface for displaying on the display means
  A user ID display section showing a unique user ID in the user management database assigned to the user who made the registration request;
  A class that is given to the user who has made the registration request and fluctuates depending on the results of the battle between the users, and a class display unit that indicates one class of a class of a predetermined type;
  It is a group member list for notifying user IDs of users classified into the respective groups, and among the registered users, the date and time when the user last logged into the game system is more than a predetermined period before the current date and time. A group display unit that displays a group member list that does not include the user ID of the user,
  In the class display section,
    For users who participated in the official league match, the assigned rank is changed and displayed for the users in a predetermined order determined according to the battle results between the users in each group of the official league match. And
    As a result of the class change, if the number of users in the class after the change exceeds the number of users that can be added to the group upper limit number in the official league match, the group member list that is larger than the group upper limit number Is displayed,
    When the user who made the registration request logs in again after a predetermined period of time has elapsed since the last login to the game system, the lowest rank of the predetermined types of classes is displayed.
A game system characterized by that.