WO2013021777A1 - ゲームシステム及びその制御方法、プログラム - Google Patents

ゲームシステム及びその制御方法、プログラム Download PDF

Info

Publication number
WO2013021777A1
WO2013021777A1 PCT/JP2012/067743 JP2012067743W WO2013021777A1 WO 2013021777 A1 WO2013021777 A1 WO 2013021777A1 JP 2012067743 W JP2012067743 W JP 2012067743W WO 2013021777 A1 WO2013021777 A1 WO 2013021777A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
class
users
group
game system
Prior art date
Application number
PCT/JP2012/067743
Other languages
English (en)
French (fr)
Inventor
泰良 中村
大翼 関岡
Original Assignee
株式会社バンダイ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社バンダイ filed Critical 株式会社バンダイ
Publication of WO2013021777A1 publication Critical patent/WO2013021777A1/ja

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/73—Authorising game programs or game devices, e.g. checking authenticity
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A63F13/798—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for assessing skills or for ranking players, e.g. for generating a hall of fame
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/20—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of the game platform
    • A63F2300/206—Game information storage, e.g. cartridges, CD ROM's, DVD's, smart cards
    • A63F2300/208—Game information storage, e.g. cartridges, CD ROM's, DVD's, smart cards for storing personal settings or data of the player
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/556—Player lists, e.g. online players, buddy list, black list
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • A63F2300/558—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by assessing the players' skills or ranking

Definitions

  • 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.
  • league game a multiplayer participation tournament online
  • winning game a brute force game
  • 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.
  • 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.
  • An object of the present invention is to solve at least one of the above-described problems.
  • a game system has the following configuration. *
  • a registration system for accepting a user registration request from a user terminal, assigning a unique user ID to the user who made the registration request, and registering it in the user management database; For each registered user, a class that varies depending on the results of the battle between the users, and by associating a class ID indicating one class of a predetermined class with the user ID of the user
  • the class granting means for granting the class and the second user from the user terminal of the first user among the registered users Between the first user and the second user by accepting the friend registration request and adding each other's user ID to the friend table associated with the user ID of each of the first user and the second user.
  • Friend registration means for constructing a friend relationship
  • group generation means for generating one or more groups by generating one or more group tables having unique group IDs for adding user IDs of users constituting the group
  • classifying means for classifying each registered user into one or more groups by adding a user ID associated with a class ID indicating the same class to the same group table.
  • the classifier is a friend table associated with the user ID of the user to be added to the group table. If there is a user ID associated with the same class ID as the class ID associated with the user ID, the user ID of the user to be added and the user ID associated with the same class ID are the same group. It is added to the table. *
  • the game system according to the second aspect of the present invention has the following configuration. *
  • a registration system for accepting a user registration request from a user terminal, assigning a unique user ID to the user who made the registration request, and registering it in the user management database; For each registered user, a class that varies depending on the results of the battle between the users, and by associating a class ID indicating one class of a predetermined class with the user ID of the user
  • the group generation means for generating one or more groups and the registered users are assigned the same user IDs associated with the class IDs indicating the same class.
  • the registered user has a classification means for classifying into one or more groups by adding to the group table, and the registered user receives a registration request from the user terminal and registers with the real user registered in the user management database
  • the virtual user is generated by the game system without receiving a request and registered in the user management database.
  • the real user and the virtual user are distinguished from each other by assigning user IDs generated according to different rules. Is characterized by preferentially adding user IDs of a predetermined number of real users to each group table. To. *
  • a game system has the following configuration. *
  • 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.
  • 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.
  • a classification unit that classifies the group into one or more groups
  • 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.
  • the class assigning means associates a class ID indicating the lowest class among predetermined classes after the login management means accepts a login request for the user ID associated with the flag. In addition to the association, the association of the flag is deleted.
  • competition card game which concerns on embodiment of this invention The figure which showed the system configuration
  • 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.
  • a game system is a simulation-type online that realizes a battle between users using a deck composed of a plurality of cards registered in advance by each user. Run the battle card game.
  • 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.
  • 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
  • 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.
  • 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. *
  • FIG. 2 shows an exemplary configuration of 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. *
  • 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.
  • 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. *
  • the CPU 301 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. *
  • 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.
  • GUI graphical user interface
  • 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. *
  • ⁇ 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 arbitrarily selects a battle user from among the other users currently logged in, and battles against a deck that the battle user has set for free battle in advance. In order to save the effort of building the deck as far as possible, the deck set for the original league or the official league may be used instead).
  • Original League A league game in which one user is the host and invites multiple users to participate in the regulations set by the host.
  • Official league A league battle held on the game system, where all users who have organized a deck for the official league are ranked according to the results of their battles. All users are assigned to one or more groups to play against each other so that the length of the league match is not prolonged.
  • Interception Battle Displays the content and results of the battle when selected as a free battle battle user by another user.
  • 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. *
  • U Total number of non-relegated total number of people
  • Undownt The total number of users who are not demoted from each rank of the official league to the next lower rank (the total number of promoted Uupt + remaining total number of people Ustayt) and the number of assigned group Guser: The number of groups to which real users are assigned for the class.
  • 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.
  • Users are ranked for each group according to the number of wins in one season.
  • 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.
  • 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. *
  • FIG. 5 (a) 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. *
  • C3 which is one of the classes
  • three users promotion number Uup
  • C2 the upper class
  • 6 users ranked down Udown
  • C4 the next lower class
  • the seven users remaining number of people Ustay
  • the class is not changed and remains in the class C3.
  • 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.
  • 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.
  • bonus NPC virtual user generated by the game system and stored in the user management database 304 without receiving a registration request.
  • the information of the battle record of each user in an official league should just be linked
  • 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.
  • a bonus NPC 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.
  • 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.
  • a user (hereinafter referred to as a real user) added to the user management database 304 in response to a registration request from the user terminal 202 is assigned to one or more groups in the official league. Distribute.
  • 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.
  • 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.
  • the distinction between a real user and a virtual user is not limited to this.
  • logical type information indicating whether or not the user is a real user is stored in association with the user ID. There may be. *
  • 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. *
  • 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.
  • 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.
  • 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.
  • the process of generating the group results can be omitted.
  • the season record 604 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.
  • the hole-filling NPC is identified by, for example, clearly indicating “NPC”.
  • 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. *
  • 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. *
  • 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. *
  • 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.
  • 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.
  • 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.
  • the virtual users of the hole-filling NPC and the bonus NPC have different cards and deck configurations depending on each class.
  • the cards owned by the virtual user are set so that the average value of the parameters becomes higher as the rank is higher.
  • 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.
  • 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. *
  • 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 according to the game scenario. For example, among bonus NPCs prepared during a single season, the player can compete with different bonus NPCs for each season. You may make it play a part with. *
  • 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.
  • 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. *
  • 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. *
  • 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. *
  • 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. *
  • the CPU 301 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. *
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the user ID of the registered user is added to the friend table associated with the user ID.
  • the friend registration method of the present invention is not limited to this. Not limited to.
  • 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.
  • 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.
  • the CPU 301 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 process In the official league group determination process described above, an arbitrary user and a friend user who has a friend relationship with the user and who has the same rank as the user are classified into the same group.
  • the group classification process will be described in detail with reference to the flowchart of FIG.
  • 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.
  • 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.
  • 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. *
  • the user IDs of real users who have friend users in the same class can be separated into the list A.
  • 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.
  • the processed real user list will be described as list B. *
  • 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.
  • 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. *
  • 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.
  • the CPU 301 moves the user ID of the selected user to the list B.
  • the CPU 301 moves the remaining user IDs included in the list A to the list B.
  • 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. *
  • 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. *
  • 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.
  • 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.
  • 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.
  • 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. . *
  • 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. *
  • 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. *
  • 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. *
  • 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.
  • 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.
  • 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.
  • a real user 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.
  • the group of users having a friend relationship has been described as being grouped to be half the number of non-downgraded people Undown.
  • 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.
  • 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. *
  • the game system 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.
  • 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.
  • 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
  • a friend relationship is established between the first user and the second user.
  • 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. *
  • step S ⁇ b> 1001 when the class change process is performed, the CPU 301 first specifies a class (error class) in which the class ID of the class is associated with the user ID of the real user exceeding 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.
  • 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.
  • 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.
  • 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.
  • 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. . *
  • 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). *
  • 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). *
  • 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. *
  • 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.
  • the processing described above can be applied to C2 to C4 in which upper and lower classes exist.
  • 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.
  • the CPU 301 stores 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 next higher class 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.
  • the CPU 301 compares the number of real users exceeding the upper limit user number Ucmax5 in C5 (Uruser5-Ucmax5) with the number of real users that can be added to C4 (Ucmax4-Uruser4). If Uruser5 ⁇ Ucmax5> Ucmax4 ⁇ Uruser4 at this time, the number of C5 class real users Uruser5 cannot be increased to the upper limit user number Ucmax5 after the end of the season. For the real user of C5, it is only necessary to notify that the number of users has reached the capacity after the end of the season, and not to be distributed in the next season. *
  • 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.
  • 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. *
  • 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.
  • 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. *
  • the CPU 301 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, it has been described that all users who have organized a deck for the official league are targeted for participation in the official league. If the number of real users who become a person exceeds the maximum number Umaxt of participation in the entire official league, real users who cannot participate in the official league will appear. *
  • Participation target determination process for determining a user who will be a participation target 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.
  • this participation object determination process shall be performed before performing the official league group determination process mentioned above.
  • 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. *
  • 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. *
  • 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. *
  • 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. *
  • 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.
  • 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.
  • 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.
  • step S1305 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. *
  • 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. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】交流のあるユーザと同一グループに割り当てられる確率を上昇させる、対戦リーグに係る処理負荷を軽減させる、あるいは公平な階級制度を実現する。【解決手段】ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当て、さらに予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する。また登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、第１のユーザ及び第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、第１のユーザと第２のユーザとの間にフレンド関係を構築する。そして登録されているユーザを同一の階級に属する所定数のユーザで構成される１以上のグループテーブルに追加する際に、当該ユーザのユーザＩＤに関連付けられたフレンドテーブルに、当該ユーザＩＤに関連付けられた階級ＩＤと同一の階級ＩＤが関連付けられたユーザＩＤが存在する場合は、追加するユーザのユーザＩＤと当該同一の階級ＩＤが関連付けられたユーザＩＤとを同一のグループテーブルに追加する。

Description

ゲームシステム及びその制御方法、プログラム
本発明は、ゲームシステム及びその制御方法、プログラムに関し、特にゲーム上でのカードを用いたユーザ同士の対戦を実現するゲームシステム及びその制御方法、プログラムに関する。
例えば、野球やサッカー等の対戦型ゲームの中には、勝ち抜き戦や総当たり戦等、オンライン上で多人数参加型の大会（リーグ戦）を開催するものがある。　
このような対戦型ゲームでは、例えばリーグ戦を行う期間の単位であるシーズンを複数設けて、１シーズンごとにユーザの勝敗成績に応じて順位付けを行うことでユーザの向上意識を高め、長期的な利用を促す工夫がなされている。　
また対戦型ゲームの中には、ユーザがより飽きにくいゲームシステムとするために、例えばリーグ戦の成績によって昇格・降格を行う階級制度を導入しているものもある。このようなシステムでは、ユーザがより上位の階級を目指して継続的かつ積極的にリーグ戦へ参加することが望まれる。また階級制度を導入したゲームシステムでは、ユーザは自身と同じレベルの戦力や熟練度を有するユーザを選んで対戦することができるため、新規ユーザが参加しやすく、ユーザ数の増加が見込まれる。　
特許文献１には、対戦の終了後にユーザによりなされた対戦相手の評価を集計することよって各ユーザの操作スキルを評価し、同レベルの操作スキルを有するユーザ同士が対戦相手となるように、ユーザ同士の対戦を制御するゲームシステムが開示されている。
特開２００６－１４９４２５号公報
対戦型ゲームにおいて管理するユーザ数が増加した場合、１回のリーグ戦の開催期間が長期化してしまい、ユーザがゲームに飽きてしまう可能性がある。このため、リーグ戦の参加ユーザを、シーズンごとにランダムに複数のグループのいずれかに割り当て、対戦成績の順位付けをグループで完結させることで、１回のリーグ戦の開催期間を短縮することが好ましい。　
オンラインの対戦型ゲームでは、特許文献１のように、システムによってランダムに決定された見ず知らずのユーザと対戦を行うよりも、学校の友人や家族等、現実世界の知人であるユーザと対戦を行う方が、現実世界での友好関係の向上も見込まれるため好まれる。しかしながら、参加ユーザのグループ分けがランダムに行われる場合、必ずしも知人のユーザと同一のグループに振り分けされないため、ユーザの興趣をそいでしまう可能性があった。例えば、仲間内でリーグ戦の順位を競うことをユーザが所望したとしても、仲間内の各ユーザが別々のグループに割り当てられた場合は、グループごとの成績による相対的な順位での評価しかできないため、ユーザのリーグ戦への参加意欲を減退させてしまう可能性があった。オンラインゲームにおいてユーザ同士の交流関係を増進することは、より長期的な利用ユーザを増加させることにもつながるため、ユーザ間の交流を阻害しないグループ分けが考慮されることが望ましい。　
一方で、運営開始当初の参加ユーザの絶対数が少ない場合や、参加ユーザ数がグループ分けにおいて端数が生じうる場合等、１グループの参加ユーザ数が予め設定された定員に満たない場合は、ＮＰＣ（Non Player Character）と呼ばれる仮想ユーザを参加させることにより、定員のユーザでリーグ戦を行うことができる。　
対戦型ゲームの場合、少なくとも一方にユーザが参加する対戦では、戦況を如何に魅力的に提示するかが重要であるため、詳細な戦況を生成する処理が実行される必要があるが、ＮＰＣ同士の対戦については、大抵のユーザにとって当該対戦の戦況は興味のない情報であるため、詳細な戦況を生成する処理は省略することができる。　
しかしながら、上述したようにリーグ戦のグループ分けがランダムに行われる場合、例えばリーグ戦の全てのグループにおいてユーザとＮＰＣとが存在するように振り分けされる可能性がある。この場合、戦況の生成処理が省略不可能なユーザ同士あるいはユーザ対ＮＰＣの対戦数が増加するため、対戦を管理するサーバの処理を軽減することができなかった。　
また、階級制度を導入した対戦ゲームにおいて、ゲームバランスのために各階級の上限ユーザ数を制限する場合、リーグ戦に長期間参加していないユーザが階級に参加対象として含まれてしまい、後からゲームを始めたユーザがリーグ戦に参加したとしても、人数制限によって昇格ができなくなってしまうことがあった。　
本発明は、上述の問題点の少なくともいずれかを解決することを目的とする。
前述の目的の１つを達成するために、本発明の第１の態様のゲームシステムは、以下の構成を備える。　
登録されているユーザが参加するリーグ戦であって、登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、登録されているユーザの各々について、ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、第１のユーザ及び第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、第１のユーザと第２のユーザとの間にフレンド関係を構築するフレンド登録手段と、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、１以上のグループを生成するグループ生成手段と、登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、１以上のグループに分類する分類手段と、を有し、分類手段は、グループテーブルに追加するユーザのユーザＩＤに関連付けられたフレンドテーブルに、当該ユーザＩＤに関連付けられた階級ＩＤと同一の階級ＩＤが関連付けられたユーザＩＤが存在する場合は、追加するユーザのユーザＩＤと当該同一の階級ＩＤが関連付けられたユーザＩＤとを同一のグループテーブルに追加することを特徴とする。　
また前述の目的の１つを達成するために、本発明の第２の態様のゲームシステムは、以下の構成を備える。　
登録されているユーザが参加するリーグ戦であって、登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、登録されているユーザの各々について、ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、１以上のグループを生成するグループ生成手段と、登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、１以上のグループに分類する分類手段と、を有し、登録されているユーザは、ユーザ端末より登録要求を受け付けてユーザ管理データベースに登録された実ユーザと、登録要求を受けずにゲームシステムが生成してユーザ管理データベースに登録した仮想ユーザとで構成され、実ユーザと仮想ユーザとは、異なるルールで生成されたユーザＩＤを付与することにより区別され、分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加することを特徴とする。　
また前述の目的の１つを達成するために、本発明の第３の態様のゲームシステムは、以下の構成を備える。　
登録されているユーザが参加するリーグ戦であって、登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当てて登録する登録手段と、登録されているユーザの各々について、ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、１以上のグループを生成するグループ生成手段と、登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、１以上のグループに分類する分類手段と、登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザＩＤに関連付けて管理するログイン管理手段と、を有し、分類手段は、ユーザＩＤに関連付けられているログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザＩＤをグループテーブルに追加しないことにより、当該ユーザをリーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザＩＤに関連付け、階級付与手段は、フラグが関連付けられたユーザＩＤについてログイン管理手段がログイン要求を受け付けた後に、予め定められた種類の階級のうちの最下位の階級を示す階級ＩＤを当該ユーザＩＤに関連付けるともに、当該フラグの関連付けを削除することを特徴とする。
このような構成により本発明によれば、交流のあるユーザと同一グループに割り当てられる確率を上昇させる、対戦リーグに係る処理負荷を軽減させる、あるいは公平な階級制度を実現することが可能となる。
本発明の実施形態に係るオンライン対戦カードゲームにおいてユーザ端末の表示装置に表示される対戦画面例を示す図 本発明の実施形態に係るゲームシステムのシステム構成を示した図 本発明の実施形態に係るゲームサーバ２０１の機能構成を示した図 本発明の実施形態に係るオンライン対戦カードゲームにおいて、提供されるゲームの種類を説明するための図 本発明の実施形態に係るオンライン対戦カードゲームにおいて、公式リーグ及び各階級について定められている情報を示した図 本発明の実施形態に係るオンライン対戦カードゲームにおいて、公式リーグにユーザが参加している場合のユーザ端末の表示装置に表示される画面構成例を示す図 本発明の実施形態に係る公式リーググループ決定処理のフローチャート 本発明の実施形態に係るユーザ同士のフレンド登録を説明するための図 本発明の実施形態に係るグループ分類処理のフローチャート 本発明の実施形態２に係るエラー回避処理のフローチャート 本発明の実施形態３に係る長期未ログインユーザ排除処理のフローチャート 本発明の実施形態３に係るオンライン対戦カードゲームにおいて、公式リーグにおける階級変更を通知する際に、ユーザ端末の表示装置に表示される通知画面例を示す図 本発明の実施形態４に係る参加対象決定処理のフローチャート 本発明の実施形態に係るデータ構造を示した図
［実施形態１］　＜ゲーム概要＞　本発明の１つの実施形態に係るゲームシステムは、各ユーザが予め登録した、複数のカードからなるデッキを用いたユーザ同士の対戦を実現する、シミュレーション型のオンライン対戦カードゲームを実行する。　
図１は、ユーザ同士が対戦する際の、各ユーザが所有する表示装置に表示される、対戦画面の画面構成を示している。対戦画面１００は、対戦相手のユーザの手持ちカードが表示される相手エリア１０１、自身の手持ちカードが表示される自エリア１０２、及び各ユーザのカードが並べられ、カード毎に設定されたパラメータに応じて、カードに描かれたキャラクタ同士が戦闘を行う戦闘エリア１０３から構成される。　
相手エリア１０１及び自エリア１０２にはそれぞれ、ユーザの分身となるアバター１０４、対戦に使用するデッキを構成するカードがランダムに設定された順序で積み上げられたカード山１０５、戦闘エリア１０３に配置するカードの待機エリア１０６、使用不可能になったカードが配置される廃棄エリア１０７、アバター１０４の体力ゲージ等を含むゲージ１０８が含まれる。　
ユーザ同士の対戦は、各ユーザが自身のエリアのカード山１０５からカードを１枚ずつ取得するターン制で行われる。カード山１０５から取得されたカードは、待機エリア１０６に置かれた後、所定数のターンが経過後に戦闘エリア１０３に移動され、当該カードに描かれたキャラクタが戦闘可能な状態になる。なお、カード山１０５に積み上げられたカードは、次に取得されるカードがわからないよう、例えば裏返された状態で表示される。また、各カードには描かれたキャラクタに応じた待機時間（ターン数）が設定されており、待機エリア１０６に置かれてからカードに応じた待機時間の経過後に、当該カードは戦闘エリア１０３に移動される。　
カードが戦闘エリア１０３に移動されると、同じく戦闘エリア１０３に置かれている相手ユーザのカードとの間で、描かれているキャラクタ同士の戦闘イベントが実行される。当該キャラクタ同士の戦闘イベントの結果、体力がなくなったキャラクタのカードは、使用不可能な状態となり、廃棄エリア１０７に移動される。なお、戦闘エリア１０３に相手ユーザのカードが置かれていない場合は、戦闘エリア１０３に移動したカードに描かれたキャラクタの攻撃対象は、相手ユーザのアバター１０４となる。　
このように、ユーザ同士が戦闘エリア１０３にカードを出し合うことにより対戦は進行し、デッキのカードが全て廃棄エリア１０７に移動された、あるいはアバター１０４の体力ゲージが０になったユーザが当該対戦の敗者となる。　
＜システム構成＞　上述のようなユーザ同士のオンライン対戦カードゲームのゲームプログラムを実行するゲームシステムのシステム構成について説明する。図２は、本実施形態のゲームシステムの例示的な構成を示している。　
本実施形態のゲームシステムでは、各ユーザが使用する例えばＰＣ等のユーザ端末２０２ａあるいはｂは、ネットワーク２０３を介してゲームサーバ２０１に接続する。各ユーザは、ユーザ端末２０２上において、例えばインターネットブラウザを起動し、ゲームサーバ２０１が提供するＵＲＬにアクセスしてゲームサーバ２０１にログイン処理を行うことにより、上述したオンライン対戦カードゲームのサービスを利用することができる。　
ゲームサーバ２０１は、オンライン対戦カードゲームに登録しているユーザの管理、及びオンライン対戦カードゲームに係るゲームプログラムの実行を行う。ゲームサーバ２０１はゲームプログラムに従って、ユーザ端末２０２で実行されているブラウザにおいて所定の表示を行うようにネットワーク２０３を介して情報を出力する。ゲームサーバ２０１においてゲームプログラムを実行することにより、ユーザ端末２０２を使用する各ユーザのデッキ編成、及びユーザ同士の対戦を実現する。なお、ユーザ端末２０２の各々は、例えば表示装置及びポインティングデバイスを有するＰＣであってよい。　
（ゲームサーバ２０１の機能構成）　ここで、ゲームサーバ２０１の機能構成について図３を用いて詳細に説明する。　
ＣＰＵ３０１は、ゲームサーバ２０１が備える各ブロックの動作を制御する。具体的にはＣＰＵ３０１は、例えばＲＯＭ３０２に記憶されている本実施形態のオンライン対戦カードゲームのゲームプログラムを読み出し、ＲＡＭ３０３に展開して実行することにより、各ブロックの動作を制御する。　
ＲＯＭ３０２は、不揮発性メモリであり、本実施形態のオンライン対戦カードゲームのゲームプログラムに加えて、例えば各ブロックの動作及びゲームプログラム上で用いる動作パラメータを記憶する。　
ＲＡＭ３０３は、揮発性メモリであり、ゲームプログラムの展開領域としてだけでなく、例えば各ブロックの動作において出力された中間データの一時的な記憶領域としても用いられる。　
ネットワークＩ／Ｆ３０６は、ゲームサーバ２０１をネットワーク２０３に接続するためのインタフェースであり、所定のプロトコルに準拠した通信接続を実現する。ゲームサーバ２０１は、ネットワークＩ／Ｆ３０６を介してネットワーク２０３に接続されることにより、同じくネットワーク２０３に接続されているユーザ端末２０２からのログイン要求を受信する。またゲームサーバ２０１は、当該ゲームサーバ２０１にログインしたユーザ端末２０２との間で、ネットワークＩ／Ｆ３０６を介して情報の送受信を行う。　
例えば１人のユーザが使用するユーザ端末２０２に対してゲームサーバ２０１からの情報送信を行う場合は、まず当該ユーザがゲームサーバ２０１にログインした際に、使用しているユーザ端末２０２を特定するアドレス情報をＣＰＵ３０１が当該ユーザのユーザＩＤ（各ユーザ固有の識別情報）に関連付けて、後述するユーザ管理データベース３０４に記憶する。ＣＰＵ３０１は、ゲームプログラムの実行において当該ユーザＩＤについて生成した情報を、当該ユーザＩＤに関連付けられたアドレス情報で定義された通信経路を用いてユーザ端末２０２に送信する。　
ユーザ管理データベース３０４は、上述したように、ゲームサーバ２０１にログインする全てのユーザについて、各ユーザに固有のユーザＩＤを割り当てて管理する。ユーザ管理データベース３０４において管理される情報（ユーザデータ）は、ユーザＩＤに限らず、例えば図１４（ａ）に示すように、各ユーザの階級を示す階級ＩＤ１４０２、各ユーザが所有するカードの情報１４０５及び作成したデッキの情報１４０６等のユーザ情報を含む。当該ユーザ情報は、それぞれのユーザＩＤに関連付けられて管理される。　
なお、ユーザ管理データベース３０４への新規ユーザの登録は、ユーザ端末２０２からのネットワーク２０３を介した登録要求がネットワークＩ／Ｆ３０６において受信された場合に、ＣＰＵ３０１が行う。ＣＰＵ３０１は、ネットワークＩ／Ｆ３０６において受信された登録要求に含まれる情報を取得し、当該登録要求を行なったユーザに対して固有のユーザＩＤを割り当てるとともに、例えばユーザ名１４０３や接続端末アドレス情報１４０４等の取得した情報を当該ユーザＩＤに関連付けて記憶する。なお、ユーザＩＤは、ユーザ管理データベース３０４への登録順の情報を含むようにＣＰＵ３０１が所定の規則に従って生成してもよいし、ユーザにより指定された文字列の情報を用いてもよい。ユーザにより指定された文字列の情報を用いる場合は、ユーザＩＤにはさらに、ユーザ管理データベース３０４の内部ＩＤとして登録順を示すＩＤが割り当てられるものとする。　
カードデータベース３０５は、本実施形態のオンライン対戦カードゲームにおいて使用する全種類のカードの情報を管理する。カードは、各々異なるカードＩＤが割り当てられたカードデータとして管理される。例えば図１４（ｄ）に示すように、カードデータには、カードに描かれているキャラクタのキャラクタ名１４４１や、ゲーム上での当該キャラクタの攻撃力や防御力等のパラメータ１４４２の情報が含まれる。パラメータ１４４２は、それぞれのカードのカードＩＤ１４４０に関連付けられている。なお、上述した各ユーザの所有するカードの情報１４０５は、例えば全種類のカードＩＤに対して所有するか否かの論理型の情報、及び所有する枚数を示す情報等であり、ユーザＩＤに関連付けてユーザ管理データベース３０４に記憶される。　
また本実施形態のオンライン対戦カードゲームでは、ユーザは後述するゲームの種類ごとに、１以上のカードで構成される「デッキ」を編成することができる。デッキの情報１４０６は、ユーザＩＤに関連付けられてユーザ管理データベース３０４に管理される。ゲームの１つの種類について編成するデッキの情報は、当該ゲームの種類を示すゲームＩＤ、ユーザが管理するデッキを識別するデッキＩＤ、及びデッキを構成する１以上のカードのカードＩＤ等を有する。　
グラフィックデータベース３０７は、本実施形態のオンライン対戦カードゲームにおいて、ユーザ端末２０２の表示装置に表示するグラフィカルユーザインタフェース（ＧＵＩ）を生成するデータ群を記憶する。ＣＰＵ３０１は、ユーザ端末２０２におけるユーザ入力、及びゲームの進行に応じたＧＵＩを生成するデータ群をグラフィックデータベース３０７より読み出し、ネットワークＩ／Ｆ３０６からネットワーク２０３を介して各ユーザのユーザ端末２０２に送信する。　
グループデータベース３０８は、本実施形態のオンライン対戦カードゲームにおいて、後述する公式リーグにおけるユーザ振り分け単位である「グループ」ごとに作られたグループテーブルを管理する。グループテーブルには、グループに振り分けされたユーザのユーザＩＤが追加される。各グループテーブルは、例えば図１４（ｃ）のように、固有のグループＩＤ１４３０が割り当てられて管理される。本実施形態のオンライン対戦カードゲームでは、公式リーグに参加するユーザを、付与さえている後述の階級が同一であるユーザでグループが構成されるように振り分ける。このため各グループテーブルには、階級ＩＤ１４３１が含まれ、当該階級ＩＤと同一の階級ＩＤが付与されたユーザの情報（１４３２、１４３３）が含まれる。　
このように構成された本実施形態のゲームシステムにおいて、ユーザに提供されるゲーム及びその処理について、以下に説明する。　
＜ゲーム種類＞　ユーザがゲームサーバ２０１にログインすると、図４に示すようなメニュータブを有する画面がユーザ端末２０２の表示装置に表示される。メニュータブ４０１ａ乃至ｄに示されるように、本実施形態のオンライン対戦カードゲームでは、ユーザに対し、「フリーバトル」（４０１ａ）、「オリジナルリーグ」（４０１ｂ）、「公式リーグ」（４０１ｃ）、「迎撃戦」（４０１ｄ）の４つのゲームを提供する。　
提供されるゲームは、それぞれ以下のような特徴を有する。・フリーバトル　　：ユーザが、現在ログインしている他のユーザの中から対戦ユーザを　　　　　　　　　　任意に選択し、当該対戦ユーザが予めフリーバトル用に設定したデ　　　　　　　　　　ッキと対戦を行う（なお、フリーバトルに限りデッキ構築の手間を　　　　　　　　　　省くためにもオリジナルリーグ用又は公式リーグ用に設定したデッ　　　　　　　　　　キで代用するようにしても良い）。・オリジナルリーグ：１人のユーザがホストとなり、ホストが設定したレギュレーション　　　　　　　　　　で複数のユーザの参加を募って開催するリ
ーグ戦。・公式リーグ　　　：ゲームシステム上で開催される、ユーザの戦績によって順位付けを　　　　　　　　　　行う、公式リーグ用のデッキを編成済みの全ユーザが参加となるリ　　　　　　　　　　ーグ戦。リーグ戦の会期が長期化しないよう、全ユーザは１以上の　　　　　　　　　　グループに振り分けされて対戦を行う。・迎撃戦　　　　　：他のユーザにフリーバトルの対戦ユーザとして選択された際の対戦　　　　　　　　　　の内容及び結果の表示を行う。　
なお、本実施形態においては「リーグ戦」とは、リーグ戦内の１グループに参加しているユーザ同士の総当たり戦を行うものとして説明するが、例えばトーナメント戦や、予め定められた会期内で実行可能な所定数の対戦を行うものであってもよい。　
＜公式リーグ詳細＞　ここで、本発明に係る公式リーグの詳細について、以下に説明する。なお、以下の説明では便宜上、以下の定数を用いて説明する。各定数を示す情報は、ＲＯＭ３０２あるいはＲＡＭ３０３に記憶されているものとする。　
・参加上限数Ｕmaxt　　　　　：公式リーグに参加可能なユーザ数・上限ユーザ数Ｕcmax　　　　：公式リーグの各階級について設定されたユーザの上限数・グループ総数Ｇmax 　　　　：公式リーグの各階級について設定されたグループ数・階級実ユーザ数Ｕruser 　　：公式リーグの各階級について、当該階級が付与されてい　　　　　　　　　　　　　　　る実ユーザの数・昇格順位Ｒup　　　　　　　：公式リーグの各階級について設定された１つのグループ　　　　　　　　　　　　　　　から１つ上位の階級に昇格するユーザ順位の条件・降格順位Ｒdown　　　　　　：公式リーグの各階級について設定された１つのグループ　　　　　　　　　　　　　　　から１つ下位の階級に降格するユーザ順位の条件・昇格人数Ｕup　　　　　　　：公式リーグの各階級について設定された１つのグループ　　　　　　　　　　　　　　　から１つ上位の階級に昇格するユーザの数・残留人数Ｕstay　　　　　　：公式リーグの各階級について設定された１つのグループ　　　　　　　　　　　　　　　から同一の階級に残留するユーザの数・降格人数Ｕdown　　　　　　：公式リーグの各階級について設定された１つのグループ　　　　　　　　　　　　　　　から１つ下位の階級に降格するユーザの数・非降格人数Ｕndown 　　　　：公式リーグの各階級について設定された１つのグループ　　　　　　　　　　　　　　　から１つ下位の階級に降格しないユーザの数　　　　　　　　　　　　　　　（昇格人数Ｕup＋残留人数Ｕstay）・昇格総人数Ｕupt 　　　　　：公式リーグの各階級から１つ上位の階級に昇格するユー　　　　　　　　　　　　　　　ザの総数・残留総人数Ｕstayt 　　　　：公式リーグの各階級に残留するユーザの総数・降格総人数Ｕdownt 　　　　：公式リーグの各階級から１つ下位の階級に降格するユー　　　　　　　　　　　　　　　ザの総数・非降格総人数Ｕndownt　　　：公式リーグの各階級から１つ下位の階級に降格しないユ　　　　　　　　　　　　　　　ーザの総数（昇格総人数Ｕupt＋残留総人数Ｕstayt）・振り分けグループ数Ｇruser ：公式リーグの各階級について、実ユーザが振り分けされ　　　　　　　　　　　　　　　るグループの数　
上述したように公式リーグは、基本的には公式リーグ用のデッキを編成済みの全ユーザが参加対象者となる。例えば１人のユーザが公式リーグ用のデッキを編成済みであるか否かは、ＣＰＵ３０１が、ユーザ管理データベース３０４に記憶されている当該ユーザのユーザＩＤを有するユーザデータを参照して判断する。具体的にはＣＰＵ３０１は、当該ユーザＩＤに関連付けられている編成デッキ情報１４０６に、公式リーグのゲームＩＤが含まれるデッキ情報が存在するか否かを判断する。　
公式リーグは、１つの会期として「シーズン」という単位を設ける。シーズンの長さは、リーグ戦の１グループにおけるユーザの総当たり戦の実行に要する期間に応じて設定される。例えば１グループに１６人のユーザが振り分けされ、１シーズンあたり１人のユーザについて３回対戦する総当たり戦を行う場合、シーズンの長さは（１６－１）×３＝４５戦分の長さとなる。　
ユーザの順位付けは１シーズンの勝利数に応じてグループごとに行う。本実施形態では、公式リーグに参加している全ユーザに対してグループごとに順位付けを行い、グループ内の順位に応じて階級の昇格あるいは降格を行う。　
（階級制度）　ここで、本実施形態のオンライン対戦カードゲームにおける、階級制度について説明する。　
公式リーグでは、同じようなレベル（操作スキル、あるいはデッキ構成）を有するユーザ同士を同一グループに振り分けることで、どちらかのユーザが有利に戦況を進めてしまうような対戦を回避する。このようにすることでユーザの興趣を長続きさせることができる。具体的にはＣＰＵ３０１は、グループへのユーザの振り分けを行う際にユーザ管理データベースに記憶されているユーザデータを参照し、同一の階級ＩＤが関連付けられているユーザＩＤでグループを構成するように分類する。即ち、１つのグループには、同一の階級が付与されたユーザが分類される。階級の情報は、例えば新規ユーザがユーザ登録後、公式リーグ用のデッキを編成した際に当該ユーザに対して最初に付与される。このとき付与される階級は、予め定められた種類の階級のうちの最下位の階級である。ＣＰＵ３０１は、当該最下位の階級を示す階級ＩＤをユーザのユーザＩＤに関連付けてユーザ管理データベース３０４に記憶させる。　
本実施形態のオンライン対戦カードゲームでは、図５（ａ）に示すように５段階の階級が設けられている。各階級には上限ユーザ数（Ｕcmax1、Ｕcmax2、Ｕcmax3、Ｕcmax4、及びＵcmax5）が設定されている。また、公式リーグの各グループに属するユーザは、１シーズン終了後のグループ内順位に応じて、階級の昇格あるいは降格が実行される。具体的には、階級の昇格あるいは降格の条件は階級のグループごとに例えば図５（ｂ）のように定められており、各階級間では公式リーグの１シーズンごとに決められた人数のユーザの階級が変動する。　
例えば、階級の１つであるＣ３では、当該階級の１つのグループにおいて、１シーズン終了後の順位が１～３位の３名（昇格人数Ｕup）のユーザは１つ上の階級のＣ２に昇格する。また、順位が１１～１６位の６名（降格人数Ｕdown）のユーザは１つ下の階級のＣ４に降格する。また、順位が４～１０位の７名（残留人数Ｕstay）のユーザについては階級の変更はなく、階級Ｃ３に残留する。図示されるように、Ｃ３のグループ総数は１６００であるため、１シーズン終了後にはＣ３全体で１６００×３＝４８００人（昇格総人数Ｕupt）のユーザがＣ２に昇格し、１６００×６＝９６００人（降格総人数Ｕdownt）のユーザがＣ４に降格することになる。　
なお、上述したオリジナルリーグは、公式リーグとは無関係に１人のユーザがホストとなって一部のユーザを対象に開催するものであるため、当該オリジナルリーグの対戦の戦績は階級の変動に用いられない。　
（ボーナスマッチ）　グループ内の総当たり戦による勝利数によって階級の昇格あるいは降格を行う場合、昇格あるいは降格の対象となる順位（昇格順位Ｒup、降格順位Ｒdown）に、勝利数が同数であるユーザが複数存在することが生じうる。これに対し、勝利数、及び引分数の各々について予め設定された係数を、それぞれの数に応じて加算して得られる点数（勝ち点）を用いることにより、同一の勝利数のユーザ間に点数の差をつけて、順位に差を付ける方法が考えられる。しかしながら、本実施形態のオンライン対戦カードゲームのようにターン制を有するゲームでは対戦結果が引き分けとなる可能性が低く、差がつかない可能性がある。　
本実施形態では、勝利数が同数のユーザが複数存在する場合に当該ユーザの順位に差が付くように、上述したグループに属するユーザの総当たり戦に加え、複数回のボーナスマッチを設ける。ボーナスマッチではユーザは、登録要求を受けずにゲームシステムが生成してユーザ管理データベース３０４に記憶した、ＮＰＣと呼ばれる仮想ユーザ（以下、ボーナスＮＰＣ）と対戦する。当該ボーナスマッチでユーザがボーナスＮＰＣに勝利した場合、当該勝利はグループの総当たり戦における勝利数には影響しないが、上述した勝ち点に対して、一定の点数を加えるものとする。このようにすることで、総当たり戦の勝利数では階級の昇格あるいは降格を行うユーザが決定できない場合に、当該総当たり戦の戦績には無関係のボーナスマッチの対戦結果による勝ち点の加算を考慮して、同一の順位のユーザに差をつけることができる。　
なお、公式リーグにおける各ユーザの対戦の戦績の情報は、図１４（ｃ）に示すように、グループに参加する各ユーザのユーザＩＤに関連付けられてグループテーブルに含まれればよい。具体的にはグループテーブルに含まれる各ユーザの情報（１４３２、１４３３）には、ユーザのユーザＩＤ、公式リーグで使用するデッキ情報、勝利数、引分数、勝ち点、及びボーナスマッチでのボーナスＮＰＣとの戦績が含まれる。　
なお、例えばゲームのシナリオに登場する重要キャラクタ等をボーナスＮＰＣとして割り当てることにより、ユーザ同士の対戦だけでなく、ゲームの世界観をユーザに楽しませる効果も与えることができる。またボーナスマッチにユーザが勝利した場合に勝ち点に加えられる一定の点数は、総当たり戦の１つの対戦で勝利した場合に勝ち点に加えられる点数よりも大きくすることで、同一の順位のユーザがいた場合に差がつきやすくしてもよい。　
（仮想ユーザの種類）　本実施形態のオンライン対戦カードゲームでは、ユーザ端末２０２からの登録要求を受けてユーザ管理データベース３０４に追加されたユーザ（以下、実ユーザ）を公式リーグの１以上のグループに振り分ける。この結果、グループの実ユーザの数が定員に満たないグループが存在する場合には、ＣＰＵ３０１は、仮想ユーザ（以下、穴埋めＮＰＣ）を追加することで当該グループを定員にする。なお、穴埋めＮＰＣはボーナスＮＰＣとは別に設けられているものとする。また、実ユーザと仮想ユーザとは、異なるルールで生成されたユーザＩＤが付与されてユーザ管理データベース３０４に管理される。実ユーザ及び仮想ユーザのいずれであるか否かは、ＣＰＵ３０１が当該ユーザＩＤを参照することにより判別可能であるものとする。しかしながら、実ユーザと仮想ユーザとの区別はこれに限らず、例えばユーザ管理データベース３０４において実ユーザであるか否かを示す論理型の情報がユーザＩＤに関連付けられて記憶されることによって判別可能であってもよい。　
本実施形態のオンライン対戦カードゲームでは、図５（ｂ）に示すように各階級について予め定められた固定数（グループ総数Ｇmax1、Ｇmax2、Ｇmax3、Ｇmax4、及びＧmax5）のグループを毎シーズン作成してリーグ戦を開催する。公式リーグの１シーズンを開始する前に行われるグループ分けでは、実ユーザは付与されている階級について作成されるグループのうちのいずれかに振り分けされる。この結果、振り分けられた実ユーザの数が定員に満たないグループについては、定員になるまで穴埋めＮＰＣが追加される。　
例えば、ある階級を示す階級ＩＤが付与されている実ユーザをグループに振り分けるときを考える。このとき、１つのグループのグループテーブルに追加された実ユーザのユーザＩＤの数が、グループの定員（例：１６人）に満たない数（例：５人）であった場合、当該グループテーブルにはユーザ数が定員になるまで、穴埋めＮＰＣのユーザＩＤが追加される（例：１６ー５＝１１人）。　
上述したように対戦型ゲームにおいては、実ユーザ同士の対戦及び実ユーザと仮想ユーザとの対戦は、詳細な戦況を生成する処理を実行する必要がある。本実施形態のオンライン対戦カードゲーム
では、各階級において実ユーザが振り分けされるグループ数を制限して実ユーザの振り分けを行うことで、当該詳細な戦況を生成する処理の実行を最小限にしてサーバ負荷を軽減する。即ち、実ユーザが振り分けされないグループについては、詳細な戦況の生成処理の実行及びグループの戦績の通知を行う必要がない。このため、当該グループの対戦に係る戦況の生成処理は省略することができる。　
公式リーグ戦においてユーザ端末２０２の表示装置に表示される表示画面構成は、例えば図６のようになっている。図示されるように、公式リーグ戦における表示画面には、ユーザ端末２０２を使用するユーザが参加しているグループの詳細情報６０１、総当たり戦において次にユーザが対戦する相手ユーザの情報６０２、次に行われるグループ内の対戦情報６０３、及びグループに参加している全ユーザの現在のシーズンの戦績６０４が含まれる。このように、公式リーグに参加している各ユーザに対しては、当該ユーザが参加しているグループの情報のみが、公式リーグ戦における表示画面として提供される。即ち、ユーザが参加していないグループについてはユーザに通知しないことにより、グループの戦績を生成する処理を省略可能である。　
なお、図６に示されるようにシーズン戦績６０４には、グループに参加している全ユーザのユーザ名（ユーザＩＤであってもよい）、勝利数、勝率、勝ち点等の情報が、現在の順位に応じてリスト表示されている。当該リストにおいて、穴埋めＮＰＣは例えば「ＮＰＣ」と明示されることにより識別可能にされている。またグループの詳細情報６０１には、シーズン終了後に当該グループに参加しているユーザのうち、上位の階級に昇格するユーザ数及び下位の階級に降格するユーザ数の情報、及び当該グループに参加している実ユーザ数である「プレイ人数」の情報が表示される。　
一方で、当該オンライン対戦カードゲームの運営開始直後は、昇格人数が限られているため、実ユーザは下位の階級に偏る。このとき、グループに昇格人数Ｕupと残留人数Ｕdownの合計数（非降格人数Ｕndown）を超える実ユーザがグループに振り分けた場合、シーズン終了後に階級が降格する実ユーザが存在することになる。例えば１グループが定員１６人であり、階級Ｃ４のグループに実ユーザ４８人を振り分ける場合、実ユーザが振り分けられる最小のグループ数は３となる。そして３つのグループに４８人の実ユーザを振り分けてゲームを行うと、シーズン終了後には図５（ｂ）に従って、各グループの１１～１６位の１８人のユーザは降格することになる。即ち、上位の階級は上限ユーザ数となる実ユーザが存在しないにも関わらず、下位の階級に降格する実ユーザが存在するため、上位の階級に実ユーザが増加しづらい。つまり、実ユーザの中には上位の階級になかなか昇格できない実ユーザもおり、当該実ユーザのゲームへの参加意欲を削ぐことになってしまう。また、上位の階級に昇格した実ユーザも、対戦相手となる実ユーザが増加しにくく、決まった実ユーザあるいは穴埋めＮＰＣとの対戦の機会が多いため、ゲームに飽きてしまう可能性がある。　
このため、本実施形態のオンライン対戦カードゲームでは階級の各々について、当該階級が付与された実ユーザの数が、シーズン終了後に当該階級から降格しない非降格総人数Ｕndowntを超えるまでは、少なくとも１つのグループに降格人数Ｕdownの穴埋めＮＰＣを追加するものとする。例えば、上述したようにＣ３全体における非降格総人数Ｕndownt3は、Ｃ３の上限ユーザ数Ｕcmax3から降格総人数Ｕdownt3を減算した２５６００－９６００＝１６０００人となる。このため、本実施形態ではＣ３の階級ＩＤが付与された実ユーザの数が１６０００人を超えるまでは、ＣＰＵ３０１は１つのグループに降格人数Ｕdown3に相当する６人の穴埋めＮＰＣを少なくとも追加してグループ分けを行う。このときＣＰＵ３０１は、例えば穴埋めＮＰＣは実ユーザとの対戦時には敗北するように戦況を生成するものとし、シーズン終了後には降格順位に実ユーザがならないようにしてもよい。　
即ち、ＣＰＵ３０１は、当該階級が付与された実ユーザの数が当該階級の非降格人数Ｕndownを超えるまでは、公式リーグの１つの階級における１つのグループに、非降格人数Ｕndownずつ実ユーザを振り分けする。そして実ユーザが振り分けされたグループの各々には、グループのユーザ数が定員となるまで、少なくとも降格人数Ｕdownの穴埋めＮＰＣであって、実ユーザとの対戦に必ず敗北する穴埋めＮＰＣを追加する。このようにすることで、階級が降格する実ユーザをなくし、かつ戦況を生成する必要があるグループ数を最小限にすることができる。　
また、１つの階級が付与された実ユーザの数が当該階級の非降格総人数Ｕndowntを超えた場合は、当該階級のグループ総数Ｇmaxのグループに実ユーザの数を均等に振り分ける。さらに実ユーザが振り分けされたグループの各々には、グループのユーザ数が定員となるまで、実ユーザとの対戦に必ず敗北する穴埋めＮＰＣを追加することで、少なくとも降格順位Ｒdownになる実ユーザの数を最小限にすることができる。　
なお、ＣＰＵ３０１は、実ユーザとの対戦において穴埋めＮＰＣを必ず敗北させるか否かを、階級ごとに判断するものとする。即ち、穴埋めＮＰＣを必ず敗北させる処理は、当該処理が行われるグループの階級よりも上位の階級において、当該階級が付与された実ユーザの数が、例えば同階級の上限ユーザ数Ｕcmaxあるいは所定数に満たない場合に行われる処理であってよい。つまり、当該処理は上位の階級が付与された実ユーザの数を増やすための処理であり、上位の階級が付与された実ユーザの数が所望の数になった場合には停止してよい。具体的にはＣＰＵ３０１は、１つの階級について公式リーグの対戦の戦況を生成する処理を行う際に、当該階級よりも上位の階級が付与された実ユーザの人数の情報をユーザ管理データベース３０４から取得し、当該人数が各階級について予め設定された数に満たない場合にのみ、穴埋めＮＰＣが必ず敗北するように戦況を生成するものとする。　
なお、穴埋めＮＰＣやボーナスＮＰＣの仮想ユーザは、所有するカードやデッキ構成等が各階級に応じて異なることが好ましい。即ち、階級が上位に行くほど仮想ユーザが所有するカードは、パラメータの平均値が高くなるように設定されるものとする。本実施形態のオンライン対戦カードゲームでは、各階級について一定数の穴埋めＮＰＣ及びボーナスＮＰＣが用意されている。穴埋めＮＰＣ及びボーナスＮＰＣは、実ユーザと同様にそれぞれ異なるユーザＩＤが割り当てられて、ユーザ管理データベース３０４に記憶されている。グループに含まれるユーザの総当たり戦では、同一のユーザＩＤを含めることは戦績の処理上不可能であるため、各階級のグループ分けにおいては、１つのグループ内に同一の穴埋めＮＰＣが存在しないようにする必要がある。このため、１つの階級について用意する穴埋めＮＰＣの数は、１つのグループに実ユーザが１人のみが振り分けられた場合であっても、当該グループに追加する穴埋めＮＰＣについて、同一の穴埋めＮＰＣが存在しない数であればよい。即ち、本実施形態のように１グループにおける実ユーザと穴埋めＮＰＣの合計数が１６人として設定されている場合は、各階級に用意される穴埋めＮＰＣの数は、最低１５人あればよい。　
なお、例えば最上位の階級のみ、グループ内だけでなく階級内でのユーザの順位付けを行って前ユーザに公表する場合は、最上位の階級用に用意する穴埋めＮＰＣを、当該階級の上限ユーザ数分用意するようにすればよい。これは、実ユーザが最上位の階級に存在しない場合であっても、最上位の階級における順位付けを生成するためである。またボーナスＮＰＣの数は、ゲームのシナリオに応じて決定されればよいが、例えばシーズン毎に異なるボーナスＮＰＣとの対戦を行えるように、１回のシーズン中には用意されているボーナスＮＰＣのうちの一部と対戦が組まれるようにしてもよい。　
（公式リーググループ決定処理）　ここで、本実施形態のゲームシステムにおける、実ユーザが分類されるグループ数を考慮した、公式リーグにおける公式リーググループ決定処理について、図７のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本公式リーググループ決定処理は、公式リーグの１シーズンの開始前に実行されるものとして説明する。　
Ｓ７０１で、ＣＰＵ３０１は、ＲＯＭ３０２に記憶されている予め定められた種類の階級のうち、まだ実ユーザのグループ分けがなされていない１つの階級の階級ＩＤを選択する。またＣＰＵ３０１は、選択した階級ＩＤで示される階級について、公式リーグで設けるグループ総数Ｇmaxを示す情報、当該階級の１つのグループについて設定された非降格人数Ｕndownを示す情報、及びシーズン終了後に当該階級から降格しない非降格総人数Ｕndownt（非降格人数Ｕndown×グループ総数Ｇmax、あるいは昇格総人数Ｕupt＋残留総人数Ｕstayt）を示す情報をＲＯＭ３０２より取得する。　
Ｓ７０２で、ＣＰＵ３０１は、Ｓ７０１で選択した階級ＩＤで示される階級が付与された実ユーザの数（階級実ユーザ数Ｕruser）を取得する。具体的にはＣＰＵ３０１は、Ｓ７０１で選択した階級ＩＤが関連付けられてユーザ管理データベース３０４に記憶されている実ユーザの数を計数し、階級実ユーザ数Ｕruserを示す情報を取得する。　
Ｓ７０３で、ＣＰＵ３０１は、階級実ユーザ数Ｕruserがシーズン終了後に少なくともＳ７０１で取得した、当該階級から降格しない非降格総人数Ｕndownt以下であるか否かを判断する。ＣＰＵ３０１は、階級実ユーザ数Ｕruserが非降格総人数Ｕndownt以下であると判断した場合は処理をＳ７０４に移し、非降格総人数Ｕndowntより大きいと判断した場合は処理をＳ７０５に移す。　
Ｓ７０４で、ＣＰＵ３０１は、選択した階級ＩＤが示す階級が付与された実ユーザを振り分けるグループの数（振り分けグループ数Ｇruser）を算出する。具体的にはＣＰＵ３０１は階級実ユーザ数Ｕruserを各グループにおいて非降格人数Ｕndownで除し、端数を切り上げることにより振り分けグループ数Ｇruserを算出する。　
またＳ７０３で、階級実ユーザ数Ｕruserが、選択した階級ＩＤが示す階級から降格しない非降格総人数Ｕndowntより大きいと判断した場合、ＣＰＵ３０１はＳ７０５で、振り分けグループ数をＳ７０１で取得した当該階級について設けるグループ総数Ｇmaxに設定する。　
Ｓ７０６では、ＣＰＵ３０１は、選択した階級ＩＤが示す階級が付与された実ユーザを、予め定められた規則に従って、振り分けグループ数Ｇruserのグループに振り分けるグループ分類処理を実行する。なお、当該グループ分類処理の詳細については後述するが、階級実ユーザ数Ｕruserが非降格総人数Ｕndownt以下である場合は、ＣＰＵ３０１は１つのグループに振り分ける実ユーザの数が非降格人数Ｕndownとなるように、順にグループを選択して実ユーザを振り分ける。また階級実ユーザ数Ｕruserが非降格総人数Ｕndowntより大きい場合は、ＣＰＵ３０１は各グループに振り分ける実ユーザの数が均等になるように振り分けを行う。即ち、１つのグループには非降格人数Ｕndownの実ユーザが優先的に振り分けられる。　
Ｓ７０７で、ＣＰＵ３０１は、ＲＯＭ３０２に記憶されている予め定められた種類の階級の全てについて、実ユーザのグループ分けを行なったか否かを判断する。ＣＰＵ３０１は、まだ実ユーザのグループ分けを行っていない階級がある場合は処理をＳ７０１に戻し、全ての階級について実ユーザのグループ分けが完了している場合は公式リーググループ決定処理を完了する。　
（フレンド登録）　また、本実施形態のオンライン対戦カードゲームでは、ユーザ同士の交流を促進する
ためにフレンド登録機能を有し、フレンド登録を行なったユーザ同士は公式リーグ戦において同一のグループに振り分けされるようにグループ分類処理が行われる。　
ここで、ユーザ同士のフレンド登録を行う方法について、図を用いて説明する。例えばユーザＡがユーザＢをフレンドとして登録したい場合、ユーザＡは、ユーザ検索画面においてユーザＢを検索する、あるいはゲームシステムにログイン中のユーザの一覧リストの中からユーザＢを選択することにより、図８（ａ）のようなユーザＢの詳細画面に遷移する。そして当該画面においてフレンド登録ボタン８０１を選択することにより、ユーザＢをフレンドとして登録することができる。フレンドとして登録されたユーザＢは、例えば図８（ｂ）に示されるようなユーザＡに関する詳細情報を確認する画面におけるフレンドリスト領域８０２にフレンドアイコン８０３を用いて表示される。　
当該フレンド登録に係る処理は、例えば以下のようにＣＰＵ３０１によって処理される。ＣＰＵ３０１は、ネットワークＩ／Ｆ３０６を介してユーザＡのユーザ端末２０２からユーザＢについてのフレンド登録要求を受信すると、ユーザ管理データベース３０４に記憶されている、ユーザＡのユーザＩＤに関連付けられたフレンドテーブルの情報を読み出す。フレンドテーブルは、例えば図１４（ｂ）に示すようにユーザによってフレンド登録要求がなされたユーザのユーザＩＤが追加されたリストであり、ＣＰＵ３０１は読み出したユーザＡのユーザＩＤに関連付けられたフレンドテーブルに、ユーザＢのユーザＩＤを追加して再びユーザ管理データベース３０４に記憶させることにより、ユーザＡとユーザＢとのフレンド関係を構築する。なお、本実施形態ではユーザからフレンド登録要求を受信した際に、当該ユーザＩＤに関連付けられたフレンドテーブルに被登録ユーザのユーザＩＤを追加するものとして説明するが、本発明のフレンド登録方法はこれに限られない。例えばＣＰＵ３０１は、ユーザＡのユーザ端末２０２からユーザＢのフレンド登録要求を受信した場合に、まずユーザＢに対してユーザＡのフレンド登録の承認の可否を要求し、ユーザＢが当該承認を認可した際にユーザＡ及びユーザＢそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤの情報を追加し、ユーザＡとユーザＢとの間にフレンド関係を構築する構成であってもよい。　
なお、ＣＰＵ３０１は、ユーザ端末２０２よりユーザに関する詳細情報の表示要求を受信した場合は、まず当該ユーザのユーザＩＤに関連付けられているフレンドテーブルをユーザ管理データベース３０４より読み出す。そしてＣＰＵ３０１は、当該テーブルに含まれるユーザＩＤに関連付けられているグラフィック情報をグラフィックデータベース３０７より取得して、図８（ｂ）のフレンドリスト領域８０２にフレンドアイコン８０３として描画するものとする。　
（グループ分類処理）　ここで、任意のユーザと、当該ユーザとフレンド関係を有し、かつ当該ユーザと同一の階級を有するフレンドユーザとを同一のグループに分類する、上述した公式リーググループ決定処理におけるグループ分類処理について、図９のフローチャートを用いて詳細に説明する。なお、本グループ分類処理は、上述した公式リーググループ決定処理において呼び出される処理であるため、決定された実ユーザを分類するグループ数（振り分けグループ数）の情報に基づいて階級ごとに実行される。　
Ｓ９０１で、ＣＰＵ３０１は、処理対象の階級ＩＤが示す階級が付与された実ユーザの集合を、ユーザとフレンド関係を有するフレンドユーザが当該集合内に含まれるか否かによって２つの集合に分類する。　
具体的にはＣＰＵ３０１は、まず処理対象の階級ＩＤが関連付けられている実ユーザのユーザＩＤをユーザ管理データベース３０４より読み出してＲＡＭ３０３の実ユーザリストに追加する。そしてＣＰＵ３０１は、当該実ユーザリストに追加されているユーザＩＤの各々について、当該ユーザＩＤに関連付けられているフレンドテーブルの情報をユーザ管理データベース３０４より読み出す。さらにフレンドテーブルと実ユーザリストの両方に含まれるユーザＩＤが存在する場合は、ＣＰＵ３０１は当該両方に含まれるユーザＩＤと、フレンドテーブルが関連付けられているユーザＩＤとを、同じ階級内にフレンドユーザが存在する実ユーザのリストであるＲＡＭ３０３のリストＡに追加するとともに、実ユーザリストからリストＡに追加したユーザＩＤを削除する。　
このような処理を実ユーザリストに含まれるユーザＩＤの各々について繰り返し実行することにより、同じ階級内にフレンドユーザが存在する実ユーザのユーザＩＤをリストＡに分離することができる。なお、本ステップの処理後の実ユーザリストは、同じ階級内にフレンドユーザが存在しない実ユーザのユーザＩＤのみが含まれるリストとなっている。以下の説明では、処理後の実ユーザリストをリストＢとして説明する。　
Ｓ９０２で、ＣＰＵ３０１は、リストＡに含まれる実ユーザを、ユーザ関係を有するユーザの組に分類する。具体的にはＣＰＵ３０１は、リストＡに含まれるユーザＩＤをランダムに選択し、当該ユーザＩＤとフレンド関係を有する、リストＡに含まれるフレンドユーザのユーザＩＤのうちから、４人のフレンドユーザのユーザＩＤをランダムに選択する。なお、このときフレンド関係を有するフレンドユーザが４人に満たない場合は、ＣＰＵ３０１はフレンド関係を有する全てのフレンドユーザのユーザＩＤを選択する。そしてＣＰＵ３０１は、当該ランダムに選択したユーザＩＤと、最大４人のフレンドユーザのユーザＩＤとを、フレンド関係を有する最大５人のユーザのユーザＩＤで構成される構造体としてＲＡＭ３０３のリストＣに追加する。このとき、ＣＰＵ３０１はリストＡから当該構造体に含められたユーザＩＤを削除する。即ち、本ステップにおいてＣＰＵ３０１は、処理対象の階級における１つのグループについての非降格人数Ｕndownの半数以下で構成される、フレンド関係を有するユーザの組を作る。　
本ステップでは、ＣＰＵ３０１はこのような組分け処理を、リストＡに含まれるユーザＩＤがなくなるまで、あるいはリストＣに追加された構造体の数が振り分けグループ数Ｇruserの２倍になるまで繰り返す。なお、組分け処理を実行することにより、ランダムに選択したユーザについて、当該ユーザのフレンドユーザが既に組分けされており、リストＡに含まれるフレンドユーザのユーザＩＤの数が０である場合がある。このような場合は当該選択したユーザに対して組分けを行うことができないため、ＣＰＵ３０１は当該選択したユーザのユーザＩＤをリストＢに移動するものとする。また、リストＣに追加された構造体の数が振り分けグループ数Ｇruserの２倍になり組分け処理を停止した場合、ＣＰＵ３０１はリストＡ似含まれる残りのユーザＩＤについては、リストＢに移すものとする。　
Ｓ９０３で、ＣＰＵ３０１は、処理対象の階級ＩＤに関連付けて、振り分けグループ数Ｇruserのグループテーブルをグループデータベース３０８に作成する。このとき、作成された振り分けグループ数Ｇruserのグループテーブルは、それぞれ異なるグループＩＤが関連付けられ、独立して管理されるものとする。　
Ｓ９０４乃至Ｓ９０７の処理で、ＣＰＵ３０１は、リストＢ及びリストＣに含まれる実ユーザのユーザＩＤをグループテーブルに順に追加することで、Ｓ９０３でグループデータベース３０８に作成した振り分けグループ数Ｇruserのグループテーブルのそれぞれに非降格人数Ｕndownの実ユーザを追加する。　
Ｓ９０４で、ＣＰＵ３０１は、グループデータベース３０８に作成した振り分けグループ数のグループテーブルのうち、実ユーザのユーザＩＤをまだ追加していないグループテーブルを選択する。　
Ｓ９０５で、ＣＰＵ３０１は、リストＣから２つの構造体を読み出し、当該構造体に含まれるユーザＩＤの全てをＳ９０４で選択したグループテーブルに追加する。またＣＰＵ３０１は、読み出した２つの構造体をリストＣから削除する。なお、リストＣに１つの構造体しか存在しない場合は、ＣＰＵ３０１は当該１つの構造体に含まれるユーザＩＤのみを選択したグループテーブルに追加するものとする。また、リストＣに含まれる構造体が存在しない場合は、ＣＰＵ３０１は本ステップの処理を行わずに、処理をＳ９０６に移す。　
Ｓ９０６で、ＣＰＵ３０１は、選択中のグループテーブルに追加したユーザＩＤの数、即ちＳ９０５で読み出した２つの構造体に含まれていたユーザＩＤの数が非降格人数Ｕndownと等しい否かを判断する。ＣＰＵ３０１は、選択中のグループテーブルに追加したユーザＩＤの数が非降格人数Ｕndownと等しいと判断した場合は処理をＳ９０７に移し、非降格人数Ｕndownに満たないと判断した場合は処理をＳ９０６に移す。　
Ｓ９０６で、ＣＰＵ３０１は、リストＢに含まれるユーザＩＤをグループテーブルにランダムに選択して追加することで、選択中のグループテーブルに含まれるユーザＩＤの数を非降格人数Ｕndownとする。このとき、ＣＰＵ３０１は、Ｓ９０５と同様に、グループテーブルに追加したユーザＩＤをリストＢから削除する。なお、本ステップにおいてリストＢに含まれる全てのユーザＩＤを追加しても選択中のグループテーブルに含まれるユーザＩＤの数が非降格人数Ｕndownに達しない場合は、ＣＰＵ３０１は選択中のグループテーブルに当該全てのユーザＩＤを追加して処理をＳ９０７に移せばよい。また、リストＢに含まれるユーザＩＤが存在しない場合は、ＣＰＵ３０１は本ステップの処理を行わずに処理をＳ９０７に移す。　
Ｓ９０７で、ＣＰＵ３０１は、グループデータベース３０８に作成した振り分けグループ数のグループテーブルの全てに、ユーザＩＤを追加したか否かを判断する。ＣＰＵ３０１は、振り分けグループ数のグループテーブルの全てにユーザＩＤを追加したと判断した場合は処理をＳ９０８に移し、ユーザＩＤを追加していないグループテーブルが存在すると判断した場合は処理をＳ９０４に戻す。　
Ｓ９０８で、ＣＰＵ３０１は、リストＢに含まれるユーザＩＤが存在するか否かを判断する。即ち、本ステップにおいてＣＰＵ３０１は、処理対象の階級の実ユーザのうち、まだグループテーブルに追加されていないユーザＩＤが存在するか否かを判断する。ＣＰＵ３０１は、リストＢに含まれるユーザＩＤが存在すると判断した場合は処理をＳ９０９に移し、リストＢに含まれるユーザＩＤは存在しないと判断した場合は処理をＳ９１０に移す。　
Ｓ９０９で、ＣＰＵ３０１は、リストＢに含まれるユーザＩＤを、グループデータベース３０８に作成された振り分けグループ数Ｇruserのグループテーブルに均等に配分して追加する。なお、リストＢに含まれるユーザＩＤの数を振り分けグループ数Ｇruserで除した際に端数が存在する場合は当該配分は均等ではなく、端数分のグループは、他のグループよりもグループテーブルに追加されるユーザＩＤの数が多くなることは言うまでもない。　
Ｓ９１０で、ＣＰＵ３０１は、グループデータベース３０８に作成された振り分けグループ数のグループテーブルの各々を参照し、追加した実ユーザのユーザＩＤがグループに含めるユーザの定員に満たない場合は、処理対象の階級ＩＤに関連付けられている仮想ユーザのユーザＩＤをユーザ管理データベース３０４から読み出して追加して当該グループテーブルに含まれるユーザＩＤの数を定員数として、本グループ分類処理を完了する。　
このようにすることで、本実施形態のオンライン対戦カードゲームでは、公式リーグにおける実ユーザのグループ分類において、フレンド関係を有するユーザ同士が同一のグループに含まれるように実ユーザを分類することができる。なお、本実施形態では、フレンド関係を有するユーザの組を、非降格人数Ｕndownの半数となるように組分けするものとして説
明したが、本発明の実施はこれに限らず、組分けは任意の階級においてフレンド関係を有するユーザ同士が同一のグループに含まれるように行えばよい。　
また、このように公式リーグにおける実ユーザのグループ分類において、フレンド関係を有するユーザが同一グループに分類されていることは、例えば図６に示すように、ユーザ端末２０２の表示装置に表示される表示画面に含まれるフレンドリスト６０５において通知される。具体的には、フレンド関係を有するユーザのアイコンに対して参加通知６０６が付加されることによりユーザに通知されればよい。　
以上説明したように、本実施形態のゲームシステムは、交流のあるユーザと同一グループに割り当てられる確率を上昇させる、対戦リーグに係る処理負荷を軽減させることができる。具体的にはゲームシステムは、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当て、さらに予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する。また登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、第１のユーザ及び第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、第１のユーザと第２のユーザとの間にフレンド関係を構築する。そして登録されているユーザを同一の階級に属する所定数のユーザで構成される１以上のグループテーブルに追加する際に、当該ユーザのユーザＩＤに関連付けられたフレンドテーブルに、当該ユーザＩＤに関連付けられた階級ＩＤと同一の階級ＩＤが関連付けられたユーザＩＤが存在する場合は、追加するユーザのユーザＩＤと当該同一の階級ＩＤが関連付けられたユーザＩＤとを同一のグループテーブルに追加する。　
［実施形態２］　上述した実施形態１のオンライン対戦カードゲームでは、公式リーグのシーズン終了後の各グループにおける戦績に応じて、実ユーザに付与されている階級の昇格あるいは降格が行われる。図５（ｂ）に示したように、基本的には昇格及び降格が行われる２つの階級間において、上位の階級に昇格する実ユーザの合計数（昇格総人数Ｕupt）と、下位の階級に降格する実ユーザの合計数（降格総人数Ｕdownt）とは等しくなるように設定される。しかしながら、ゲームサーバ２０１に高い処理負荷が与えられた場合等で想定外の処理が発生すると、１つの階級において上限ユーザ数を超える実ユーザが割り当てられてしまう可能性が考えられる。このような状況が発生した場合、上述したグループ分類時にゲームサーバ２０１がフリーズしてしまうこともあり得るため、本実施形態では当該状況を想定したエラー回避処理について説明する。　
＜エラー回避処理＞　以下、本実施形態のゲームシステムにおける、１つの階級に上限ユーザ数を超える実ユーザが割り当てられた場合のエラー回避処理について、図１０のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本エラー回避処理は、公式リーグのシーズン終了後に各グループにおける戦績に応じて階級変更処理を行う際に、１つの階級ＩＤが関連付けられるユーザＩＤの数が当該階級ＩＤが示す階級について予め定められたグループ総数Ｇmaxのグループテーブルに追加できるユーザＩＤの数（上限ユーザ数Ｕcmax）を超えるとＣＰＵ３０１が判断した場合に実行されるものとする。　
Ｓ１００１で、ＣＰＵ３０１はまず、階級変更処理を行った場合に、階級について予め定められた上限ユーザ数Ｕcmaxを超える実ユーザのユーザＩＤに当該階級の階級ＩＤが関連付けられる階級（エラー階級）を特定する。そして特定したエラー階級について、グループ総数Ｇmaxを一時的に引き上げる。このとき、一時的に引き上げるグループ総数Ｇ’maxは、引き上げ後のグループ総数Ｇ’maxのグループテーブルに追加できるユーザＩＤの数が、当該エラー階級の階級ＩＤが関連付けられるユーザＩＤの数を超えるように設定される。　
Ｓ１００２で、ＣＰＵ３０１は、エラー階級から昇格及び降格可能な階級の各々ついて、各階級の上限ユーザ数Ｕcmaxと、階級変更処理後に当該階級が付与される実ユーザの数（階級実ユーザ数Ｕruser）との差分の情報を取得し、階級変更処理後に階級実ユーザ数Ｕruser実ユーザが上限ユーザ数Ｕcmaxに満たない階級を把握する。　
具体的にはＣＰＵ３０１は、エラー階級（例：Ｃ３）の１つ上位（例：Ｃ２）及び１つ下位（例：Ｃ４）の階級のそれぞれについて、階級変更処理を行なった場合に当該階級の階級ＩＤが関連付けられるユーザＩＤの数（階級実ユーザ数Ｕruser2、Ｕruser4）をユーザ管理データベース３０４より取得する。またこのときＣＰＵ３０１は、エラー階級の１つ上位及び１つ下位の階級のそれぞれについて上限ユーザ数（Ｕcmax2、Ｕcmax4）の情報をＲＯＭ３０２より取得する。そしてＣＰＵ３０１は、エラー階級の１つ上位及び１つ下位の階級のそれぞれについて、上限ユーザ数から階級変更処理後の階級実ユーザ数を減算する。ＣＰＵ３０１は当該減算結果が０より大きい階級、即ち階級変更処理後に実ユーザの数が上限ユーザ数に満たない階級が、エラー階級の１つ上位の階級、エラー階級の１つ下位の階級、及びエラー階級の１つ上位及び１つ下位の両方の階級、のいずれであるかを判断する。　
そしてＣＰＵ３０１は、階級変更処理後の階級実ユーザ数Ｕruserが上限ユーザ数Ｕcmaxに満たない階級がエラー階級の１つ上位の階級であると判断した場合は処理をＳ１００３に移し、エラー階級の１つ下位の階級であると判断した場合は処理をＳ１００４に移す。またＣＰＵ３０１は、階級変更処理後の階級実ユーザ数Ｕruserが上限ユーザ数Ｕcmaxに満たない階級がエラー階級の１つ上位及び１つ下位の階級の両方であると判断した場合は処理をＳ１００５に移す。　
Ｓ１００３で、ＣＰＵ３０１は、次のシーズン終了後にエラー階級の１つ上位の階級に昇格する、エラー階級が付与された実ユーザの数を増加させる。具体的にはＣＰＵ３０１は、次のシーズン終了後には当該エラー階級の階級ＩＤが割り当てられるユーザＩＤの数が引き上げ前の上限ユーザ数（Ｕcmax3）となるように、階級を昇格させる実ユーザの数（昇格総人数Ｕupt）を設定する。　
同様にＳ１００４で、ＣＰＵ３０１は、次のシーズン終了後にエラー階級の１つ下位の階級に降格する、エラー階級が付与された実ユーザの数を増加させる。具体的にはＣＰＵ３０１は、次のシーズン終了後には当該エラー階級の階級ＩＤが割り当てられるユーザＩＤの数が引き上げ前の上限ユーザ数Ｕcmaxとなるように、階級を降格させる実ユーザの数（降格総人数Ｕdownt）を設定する。　
またＳ１００５で、ＣＰＵ３０１は、次のシーズン終了後にエラー階級の１つ上位の階級に昇格する、及び１つ下位の階級に降格する、エラー階級が付与された実ユーザの数（昇格総人数Ｕupt及び降格総人数Ｕdownt）を増加させる。具体的にはＣＰＵ３０１は、次のシーズン終了後にはエラー階級、当該エラー階級の１つ上位の階級、及び当該エラー階級の１つ下位の階級の階級ＩＤが割り当てられるユーザＩＤの数（階級実ユーザ数Ｕruser2、Ｕruser3、及びＵruser4）が、それぞれの階級にもともと割り当てられた上限ユーザ数（Ｕcmax2、Ｕcmax3、及びＵcmax4）となるように、階級を昇格させるあるいは降格させる実ユーザの数を設定する。　
このように、１シーズンの終了時の階級変更処理を行う際に、１つの階級についての階級実ユーザ数Ｕruserが、当該階級について予め定められた上限ユーザ数Ｕcmaxを超える場合であっても、一時的に上限ユーザ数Ｕcmaxを引き上げることで、当該エラーを許容し、さらに階級の昇格及び降格を制御することで、次のシーズン終了後にエラーを修正する。　
なお、本実施形態では上述した処理は、上位及び下位の階級が存在するＣ２～Ｃ４に適用可能であることは容易に想像されよう。また、最上位である階級Ｃ１についても、上位の階級についての上限ユーザ数Ｕcmaxと階級実ユーザ数Ｕruserの比較の処理を除外すれば適用可能であることは理解されよう。即ち、Ｃ１については、ＣＰＵ３０１はＳ１００２の処理は省略してＳ１００４に処理を移してもよい。　
また、最下位である階級Ｃ５については、公式リーグ用のデッキを編成したユーザが新たに追加される可能性があるため、公式リーグの実ユーザの振り分けを行う公式リーググループ決定処理の直前に以下のように処理すればよい。ＣＰＵ３０１は、Ｃ５の階級ＩＤが付与された階級実ユーザ数Ｕruser5と、１つ上位の階級に当たるＣ４の階級が付与された階級実ユーザ数Ｕruser4、及びそれぞれの階級の上限ユーザ数Ｕcmax4、Ｕcmax5の情報を、それぞれユーザ管理データベース３０４及びＲＯＭ３０２より取得する。そしてＣＰＵ３０１は、Ｃ５において上限ユーザ数Ｕcmax5を超える実ユーザの数（Ｕruser5－Ｕcmax5）と、Ｃ４に追加可能な実ユーザの数（Ｕcmax4－Ｕruser4）とを比較する。このときＵruser5－Ｕcmax5＞Ｕcmax4－Ｕruser4である場合は、シーズン終了後にＣ５の階級実ユーザ数Ｕruser5を上限ユーザ数Ｕcmax5にすることができないため、ＣＰＵ３０１は（Ｕruser5－Ｕcmax5）－（Ｕcmax4－Ｕruser4）人のＣ５の実ユーザについては、シーズン終了後にユーザ数が定員に達したことを通知し、次のシーズンには振り分け対象としないようにすればよい。　
なお、本実施形態では、１つの階級についてユーザ上限数を超えるようなユーザＩＤに当該階級の階級ＩＤが関連付けられるエラーが発生した場合に、次のシーズン終了後に当該エラーを修正する方法について説明したが、本発明の実施はこれに限らず、ユーザ上限数を永続的に引き上げられる構成にすることで、さらなるエラーを生じないようにしてもよい。　
［実施形態３］　本実施形態及び上述した実施形態のオンライン対戦カードゲームは、ユーザが全ての対戦のためにゲームシステムにログインする必要がないよう、あるいはリーグ戦に参加する全てのユーザがログインしなくても進行するように、公式リーグの１シーズンに係る処理が自動的に開始される。ユーザ同士の対戦について生成される詳細な戦況は、対戦するユーザの各々が使用するデッキに応じて自動的に生成されるように構成されている。なお、上述したように公式リーグの１シーズンは、基本的には公式リーグ用のデッキを編成済みの全ユーザが参加対象者となる。 　しかしながら、このように自動的に進行するオンライン対戦カードゲームでは、長期間ログインしていないユーザも参加対象者として含まれるため、サービスを破綻させてしまう可能性がある。具体的には、実際にはサービスの利用意欲がないユーザのユーザＩＤの情報が公式リーグに自動的に登録されることにより、公式リーグに参加する実ユーザの数が公式リーグ全体の参加上限数Ｕmaxtに到達してしまうことがあるため、新規のユーザは公式リーグに参加することができない可能性がある。　
本実施形態では、このように長期間ログインしていないユーザを強制的に排除することで、公式リーグに参加する実ユーザの数が公式リーグ全体の参加上限数Ｕmaxtとなりにくくする方法について説明する。　
＜長期未ログインユーザ排除処理＞　以下、本実施形態のゲームシステムにおける、公式リーグの参加対象者となるユーザのうち、長期間ログインしていないユーザを強制的に排除する長期未ログインユーザ排除処理について、図１１のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本長期未ログイ
ンユーザ排除処理は、公式リーグの１シーズン終了後、次のシーズンに係る公式リーググループ決定処理を実行する前に行われるものとする。　
また、本実施形態ではネットワークＩ／Ｆ３０６を介してユーザ端末２０２よりユーザのログイン要求を受け付けた場合、ＣＰＵ３０１はログイン要求を受け付けたユーザのユーザＩＤに関連付けて、最後にログイン要求を受け付けた日時の情報１４０８（図１４（ａ））をユーザ管理データベース３０４に記憶させるものとする。　
Ｓ１１０１で、ＣＰＵ３０１は、公式リーグの参加対象者の全実ユーザのうち、１人の実ユーザのユーザＩＤを選択し、当該ユーザＩＤに関連付けられてユーザ管理データベース３０４に記憶されている、最後にログイン要求を受け付けた日時の情報が、現在日時から所定期間以上前の日時を示しているか否かを判断する。ＣＰＵ３０１は、選択した実ユーザのユーザＩＤに関連付けられている、最後にログイン要求を受け付けた日時の情報が、現在日時から所定期間以上前の日時を示していると判断した場合は処理をＳ１１０２に移し、所定期間内の日時を示していると判断した場合は処理をＳ１１０３に移す。　
Ｓ１１０２で、ＣＰＵ３０１は、選択したユーザＩＤで示される実ユーザを公式リーグに参加させないことを示す論理型のフラグ情報１４０９を、当該ユーザＩＤに関連付けてユーザ管理データベース３０４に記憶する。　
Ｓ１１０３で、ＣＰＵ３０１は、公式リーグの参加対象者の全実ユーザのユーザＩＤに対して、最後にログイン要求を受け付けた日時に基づく、公式リーグへの参加可否の判断が完了したか否かを判断する。ＣＰＵ３０１は、公式リーグの参加対象者の全実ユーザのユーザＩＤに対して公式リーグへの参加可否の判断が完了していると判断した場合は本長期未ログインユーザ排除処理を完了し、参加可否の判断が完了していないユーザＩＤが存在すると判断した場合は処理をＳ１１０１に戻す。　
本実施形態では、このように最後にログイン要求を受け付けた日時が現在日時から所定期間以上前である実ユーザについては、当該ユーザのユーザＩＤに公式リーグにさせないことを示すフラグ情報を関連付けることにより、上述した公式リーググループ決定処理及びグループ分類処理において、当該ユーザをグループテーブルに追加する対象から除外することができる。　
なお、公式リーグにさせないことを示すフラグ情報がユーザＩＤに関連付けられているユーザから、ネットワークＩ／Ｆ３０６を介して再度ログイン要求を受信した場合、ＣＰＵ３０１は当該ユーザのユーザＩＤに関連付けられているフラグ情報を削除する。これにより当該ユーザは公式リーグに再度参加可能な状態となるが、公式リーグに参加不可能な状態にされる前に当該ユーザに付与されていた階級の情報は削除され、予め定められた種類の階級のうちの最下位の階級の階級ＩＤが当該ユーザのユーザＩＤに関連付けられるものとする。これは、当該ユーザに付与されていた階級が付与された実ユーザの数が、既に当該階級について予め定められているユーザ上限数となっている可能性があるからである。なお、このときＣＰＵ３０１は、例えば図１２に示すような最下位の階級が付与されたことを示す通知画面を当該ユーザのユーザ端末２０２の表示装置にさせればよい。　
［実施形態４］　上述した実施形態１乃至３では、公式リーグ用のデッキを編成済みの全ユーザを公式リーグの参加対象者とするものとして説明したが、実施形態３で説明したように参加対象者となる実ユーザの数が公式リーグ全体の参加上限数Ｕmaxtを超えた場合、公式リーグに参加できなくなる実ユーザが現れることになる。　
上述した実施形態１乃至３のようなオンライン対戦カードゲームでは、運営上、単発的な利用ユーザよりも長期的な利用ユーザを増加させることが好ましいが、以下のような場合、長期的な利用ユーザであっても、公式リーグに参加することができない状況になる可能性がある。例えば長期的な利用ユーザが、公式リーグ用に編成したデッキを一度削除することにより１度公式リーグから外れ、その後再度公式リーグ用のデッキを編成して公式リーグに参加しようとしても、公式リーグに参加しているユーザの数が公式リーグ全体の参加上限数に達していた場合、当該ユーザはサーバの増設が行われるまでは公式リーグに参加できなくなってしまう可能性がある。結果として、長期的な利用ユーザの興趣をそいでしまうことになる。　
本実施形態では、このような問題を解決するために、長期的な利用ユーザが公式リーグの参加対象者として選択されやすくする方法について説明する。　
（参加対象決定処理）　以下、本実施形態のゲームシステムにおける、公式リーグの参加対象者となるユーザを決定する参加対象決定処理について、図１３のフローチャートを用いて説明する。当該フローチャートに対応する処理は、ＣＰＵ３０１が、例えばＲＯＭ３０２に記憶されている対応する処理プログラムを読み出し、ＲＡＭ３０３に展開して実行することにより実現することができる。なお、本参加対象決定処理は、上述した公式リーググループ決定処理を実行する前に行われるものとする。　
また、本実施形態ではＣＰＵ３０１は、最後に終了した公式リーグのシーズンに参加していたユーザの各々について、当該最後に終了したシーズンに参加していたことを示すフラグ情報１４２０をユーザＩＤに関連付けてユーザ管理データベース３０４に記憶するものとする。また、公式リーグ全体の参加上限数Ｕmaxtは、各階級について予め定められている上限ユーザ数Ｕcmaxを足しあわせた数よりも小さい値（例えば１０万人等）に設定されてもよいものとする。　
Ｓ１３０１で、ＣＰＵ３０１は、ユーザ管理データベース３０４に記憶されている実ユーザのユーザＩＤのうち、当該ユーザＩＤに最後に終了したシーズンに参加していたことを示すフラグ情報が関連付けられているユーザＩＤを、まず次のシーズンの公式リーグへの参加対象者の実ユーザとして選択する。具体的にはＣＰＵ３０１は、最後に終了したシーズンに参加していたことを示すフラグ情報が関連付けられているユーザＩＤに対して、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報１４１１を関連付けてユーザ管理データベース３０４に記憶する。　
なお、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報は、次のシーズンが終了した際には、最後に終了したシーズンに参加していたことを示すフラグ情報として用いられてもよい。また本ステップは、上述した実施形態３の長期未ログインユーザ排除処理が実行された後に、公式リーグに参加させないことを示すフラグ情報が関連付けられていないユーザＩＤを対象としてもよい。　
Ｓ１３０２で、ＣＰＵ３０１は、ユーザ管理データベース３０４を参照し、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザＩＤの数が、公式リーグ全体の参加上限数Ｕmaxtより小さいか否かを判断する。ＣＰＵ３０１は、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザＩＤの数が公式リーグ全体の参加上限数Ｕmaxtより小さい場合は処理をＳ１３０３に移し、公式リーグ全体の参加上限数以上である場合は本参加対象者決定処理を完了する。　
Ｓ１３０３で、ＣＰＵ３０１は、ユーザ管理データベース３０４に記憶されている、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられていない実ユーザのユーザＩＤのうち、当該ユーザＩＤのユーザ管理データベース３０４への登録順の情報が最も若い、即ち時系列順で最も古いユーザＩＤを選択する。なお、本ステップにおいて、既にＳ１３０４以降の処理を行うために選択したユーザＩＤについては選択対象外とし、選択対象のユーザＩＤが存在しない場合は本参加対象者決定処理を完了するものとする。　
Ｓ１３０４で、ＣＰＵ３０１は、Ｓ１３０３で選択したユーザＩＤに関連付けられている階級ＩＤをユーザ管理データベース３０４より取得する。そしてＣＰＵ３０１は、当該階級ＩＤが関連付けられ、かつ次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報が関連付けられているユーザＩＤの数が、当該階級ＩＤが示す階級について予め定められた上限ユーザ数Ｕcmaxを超えているか否かを判断する。即ち、ＣＰＵ３０１は本ステップで、Ｓ１３０３で選択したユーザＩＤに関連付けられた階級のグループに、さらに実ユーザを加えられる空きが存在するか否かを判断する。ＣＰＵ３０１は、選択したユーザＩＤに関連付けられた階級のグループに、さらに実ユーザを加えられる空きが存在すると判断した場合は処理をＳ１３０５に写、存在しないと判断した場合は処理をＳ１３０２に戻す。　
Ｓ１３０５で、ＣＰＵ３０１は、Ｓ１３０３で選択したユーザＩＤに対して、次のシーズンの公式リーグへの参加対象者であることを示すフラグ情報を関連付けてユーザ管理データベース３０４に記憶し、処理をＳ１３０２に戻す。　
このようにすることで、長期的な利用ユーザであると思われる、登録要求がなされた日時が古いユーザを優先的に公式リーグへの参加対象者とすることができる。　
なお、上述した各実施形態の説明では、ネットワークを介して、カードを用いたユーザ同士の対戦を実現するゲームシステムについて説明したが、本発明のゲームシステムはこれに限られない。本発明の実施は、ユーザ同士の対戦を実現する形態としてリーグ戦を有する如何なるゲームシステムにおいても適用可能であることは容易に理解されよう。

Claims (19)

  1. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、　ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、　前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、　前記登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、前記第１のユーザ及び前記第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、前記第１のユーザと前記第２のユーザとの間にフレンド関係を構築するフレンド登録手段と、　グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成手段と、　前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類手段と、を有し、　前記分類手段は、グループテーブルに追加するユーザのユーザＩＤに関連付けられたフレンドテーブルに、当該ユーザＩＤに関連付けられた階級ＩＤと同一の階級ＩＤが関連付けられたユーザＩＤが存在する場合は、前記追加するユーザのユーザＩＤと当該同一の階級ＩＤが関連付けられたユーザＩＤとを同一のグループテーブルに追加することを特徴とするゲームシステム。
  2. 前記登録されているユーザは、前記ゲームシステムがユーザ端末より前記登録要求を受け付けて前記ユーザ管理データベースに登録した実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、実ユーザと仮想ユーザとは、異な
    るルールで生成されたユーザＩＤを付与することにより区別され、　前記分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加することを特徴とする請求項１に記載のゲームシステム。
  3. それぞれの階級について前記ユーザ管理データベースに登録されている前記仮想ユーザの数は固定であり、　前記分類手段は、各グループテーブルに、同一の階級ＩＤが関連付けられた実ユーザのユーザＩＤと仮想ユーザのユーザＩＤとを追加し、当該グループテーブルに追加したユーザＩＤの数を定員にすることを特徴とする請求項２に記載のゲームシステム。
  4. 前記ユーザ同士の対戦のうち、実ユーザのユーザＩＤが含まれるグループテーブルで示されるグループにおける対戦の結果は通知し、仮想ユーザのユーザＩＤのみが含まれるグループテーブルで示されるグループ対戦の結果は非通知とする対戦結果通知手段をさらに有することを特徴とする請求項２または３に記載のゲームシステム。
  5. 前記登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザＩＤに関連付けて管理するログイン管理手段をさらに有し、　前記分類手段は、ユーザＩＤに関連付けられている前記ログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザＩＤをグループテーブルに追加しないことにより、当該ユーザを前記リーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザＩＤに関連付け、　前記階級付与手段は、前記フラグが関連付けられたユーザＩＤについて前記ログイン管理手段がログイン要求を受け付けた後に、前記予め定められた種類の階級のうちの最下位の階級を示す階級ＩＤを当該ユーザＩＤに関連付けるともに、当該フラグの関連付けを削除することを特徴とする請求項１乃至４のいずれか１項に記載のゲームシステム。
  6. 前記リーグ戦は所定の開催期間をシーズンとして定義し、少なくとも最後に終了したシーズンのリーグ戦に参加していたユーザの各々について、当該最後に終了したシーズンのリーグ戦に参加していたことを示すフラグをユーザＩＤに関連付ける参加管理手段をさらに有し、　前記登録手段は、ユーザの前記ユーザ管理データベースへの登録を時系列順に管理しており、　前記分類手段は、各階級について、当該階級の階級ＩＤが関連付けられたユーザＩＤの数が、当該階級について予め定められたグループ上限数のグループテーブルに追加できるユーザＩＤの数を超える場合、当該階級の階級ＩＤが関連付けられたユーザＩＤのうち、前記最後に終了したシーズンのリーグ戦に参加していたことを示すフラグが関連付けられているユーザＩＤを優先的にグループテーブルに追加した後、前記最後に終了したシーズンのリーグ戦に参加していたことを示すフラグが関連付けられていないユーザＩＤを、前記ユーザ管理データベースに登録された順に当該グループテーブルに追加することを特徴とする請求項１乃至５のいずれか１項に記載のゲームシステム。
  7. 前記リーグ戦は、前記ゲームシステムが開催する公式リーグ戦と、前記登録されているユーザがホストとなって開催するオリジナルリーグ戦とがあり、　前記階級付与手段は、　　前記公式リーグ戦に参加したユーザについては、前記公式リーグ戦の各グループにおけるユーザ同士の対戦の戦績に応じて決定される順位に基づいて、予め定められた順位のユーザのユーザＩＤに関連付けられた階級ＩＤを異なる階級ＩＤに変更し、　　前記オリジナルリーグ戦に参加したユーザについては、当該ユーザのユーザＩＤに関連付けられた階級ＩＤの、前記オリジナルリーグ戦の各グループにおけるユーザ同士の対戦の戦績に基づく変更を行わないことを特徴とする請求項１乃至６のいずれか１項に記載のゲームシステム。
  8. 前記階級付与手段によるユーザＩＤに関連付けられた階級ＩＤの変更が行われた結果、変更後の階級ＩＤが関連付けられたユーザＩＤの数が、当該階級ＩＤが示す階級について予め定められた前記公式リーグ戦におけるグループ上限数のグループテーブルに追加できるユーザＩＤの数を超える場合、当該グループ上限数を引き上げて前記公式リーグ戦を開催することを特徴とする請求項７に記載のゲームシステム。
  9. 各階級ＩＤが関連付けられたユーザＩＤの数が、当該階級ＩＤが示す階級についての前記グループ上限数のグループテーブルに追加できるユーザＩＤの数を超える場合、一時的に当該グループ上限数を引き上げて前記公式リーグ戦を開催した後、　前記階級付与手段は、前記グループ上限数を引き上げた階級の階級ＩＤが関連付けられたユーザＩＤを追加したグループテーブルにおける階級ＩＤを変更するユーザＩＤの数を増やすことにより、前記グループ上限数を引き上げた階級の階級ＩＤが関連付けられたユーザＩＤの数を、引き上げる前のグループ上限数のグループテーブルに追加できるユーザＩＤの数にすることを特徴とする請求項８に記載のゲームシステム。
  10. 前記公式リーグ戦では、前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザであって、当該公式リーグ戦に参加していない１以上の仮想ユーザと、前記公式リーグ戦に参加している全ユーザとの対戦がさらに行われ、当該対戦の結果を各ユーザのユーザＩＤに関連付けて記憶する対戦結果記憶手段をさらに有し、　前記公式リーグ戦の各グループにおけるユーザ同士の対戦の戦績が同一であるユーザが存在する場合、当該ユーザの各々のユーザＩＤに関連付けられて前記対戦結果記憶手段に記憶されている対戦の結果に基づいて、当該グループにおける順位を決定することを特徴とする請求項７乃至９のいずれか１項に記載のゲームシステム。
  11. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、　ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録手段と、　前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、　グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成手段と、　前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類手段と、を有し、　前記登録されているユーザは、ユーザ端末より前記登録要求を受け付けて前記ユーザ管理データベースに登録された実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、実ユーザと仮想ユーザとは、異なるルールで生成されたユーザＩＤを付与することにより区別され、　前記分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加することを特徴とするゲームシステム。
  12. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、　ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当てて登録する登録手段と、　前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与手段と、　グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成手段と、　前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類手段と、　前記登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザＩＤに関連付けて管理するログイン管理手段と、を有し、　前記分類手段は、ユーザＩＤに関連付けられている前記ログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザＩＤをグループテーブルに追加しないことにより、当該ユーザを前記リーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザＩＤに関連付け、　前記階級付与手段は、前記フラグが関連付けられたユーザＩＤについて前記ログイン管理手段がログイン要求を受け付けた後に、前記予め定められた種類の階級のうちの最下位の階級を示す階級ＩＤを当該ユーザＩＤに関連付けるともに、当該フラグの関連付けを削除することを特徴とするゲームシステム。
  13. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムの制御方法であって、　前記ゲームシステムの登録手段が、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録工程と、　前記ゲームシステムの階級付与手段が、前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与工程と、　前記ゲームシステムのフレンド登録手段が、前記登録されているユーザのうち、第１のユーザのユーザ端末より、第２のユーザについてのフレンド登録要求を受け付け、前記第１のユーザ及び前記第２のユーザそれぞれのユーザＩＤに関連付けられたフレンドテーブルに互いのユーザＩＤを追加することにより、前記第１のユーザと前記第２のユーザとの間にフレンド関係を構築するフレンド登録工程と、　前記ゲームシステムの生成手段が、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成工程と、　前記ゲームシステムの分類手段が、前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類工程と、を有し、　前記分類工程において前記分類手段は、グループテーブルに追加するユーザのユーザＩＤに関連付けられたフレンドテーブルに、当該ユーザＩＤに関連付けられた階級ＩＤと同一の階級ＩＤが関連付けられたユーザＩＤが存在する場合は、前記追加するユーザのユーザＩＤと当該同一の階級ＩＤが関連付けられたユーザＩＤとを同一のグループテーブルに追加することを特徴とするゲームシステムの制御方法。
  14. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムの制御方法であって、　前記ゲームシステムの登録手段が、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行な
    ったユーザに固有のユーザＩＤを割り当ててユーザ管理データベースに登録する登録工程と、　前記ゲームシステムの階級付与手段が、前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与工程と、　前記ゲームシステムのグループ生成手段が、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成工程と、　前記ゲームシステムの分類手段が、前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類工程と、を有し、　前記登録されているユーザは、ユーザ端末より前記登録要求を受け付けて前記ユーザ管理データベースに登録された実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、実ユーザと仮想ユーザとは、異なるルールで生成されたユーザＩＤを付与することにより区別され、　前記分類工程において前記分類手段は、予め定められた所定数の実ユーザのユーザＩＤを各グループテーブルに優先的に追加することを特徴とするゲームシステムの制御方法。
  15. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムの制御方法であって、　前記ゲームシステムの登録手段が、ユーザ端末よりユーザの登録要求を受け付け、当該登録要求を行なったユーザに固有のユーザＩＤを割り当てて登録する登録工程と、　前記ゲームシステムの階級付与手段が、前記登録されているユーザの各々について、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級ＩＤを当該ユーザのユーザＩＤに関連付けることにより階級を付与する階級付与工程と、　前記ゲームシステムのグループ生成手段が、グループを構成するユーザのユーザＩＤを追加する、固有のグループＩＤを有する１以上のグループテーブルを生成することにより、前記１以上のグループを生成するグループ生成工程と、　前記ゲームシステムの分類手段が、前記登録されているユーザの各々を、同一の階級を示す階級ＩＤが関連付けられているユーザＩＤを同一のグループテーブルに追加することによって、前記１以上のグループに分類する分類工程と、　前記ゲームシステムのログイン管理手段が、前記登録されているユーザの各々について、最後にユーザ端末よりログイン要求を受け付けた日時をユーザＩＤに関連付けて管理するログイン管理工程と、有し、　前記分類工程において前記分類手段は、ユーザＩＤに関連付けられている前記ログイン要求を受け付けた日時が、現在日時から所定期間以上前である場合は、当該ユーザＩＤをグループテーブルに追加しないことにより、当該ユーザを前記リーグ戦へ参加させない状態にするとともに、グループに割り当てていないことを示すフラグを当該ユーザＩＤに関連付け、　前記階級付与工程において前記階級付与手段は、前記フラグが関連付けられたユーザＩＤについて前記ログイン管理手段がログイン要求を受け付けた後に、前記予め定められた種類の階級のうちの最下位の階級を示す階級ＩＤを当該ユーザＩＤに関連付けるともに、当該フラグの関連付けを削除することを特徴とするゲームシステムの制御方法。
  16. コンピュータを、請求項１乃至１０のいずれか１項に記載のゲームシステムの各手段として機能させるためのプログラム。
  17. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、　前記ゲームシステムは、表示手段に表示するユーザインタフェースにおいて　登録要求を行なったユーザに割り当てられた、ユーザ管理データベースにおける固有のユーザＩＤを示すユーザＩＤ表示部と、　前記登録要求を行なったユーザに付与された、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級表示部と、　前記登録要求を行なったユーザとの間にフレンド関係が構築されたユーザのユーザＩＤを通知するフレンドリストを表示するフレンド表示部と、　前記各グループに分類されたユーザのユーザＩＤを通知するグループメンバリストであって、前記登録要求を行ったユーザとの間にフレンド関係が構築されたユーザのうち、少なくとも同一の階級が付与された１人のユーザのユーザＩＤが含まれるグループメンバリストを表示するグループメンバ表示部と、を有することを特徴とするゲームシステム。
  18. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、　前記登録されているユーザは、ユーザ端末より登録要求を受け付けてユーザ管理データベースに登録された実ユーザと、前記登録要求を受けずに前記ゲームシステムが生成して前記ユーザ管理データベースに登録した仮想ユーザとで構成され、　前記ゲームシステムは、表示手段に表示するユーザインタフェースにおいて　登録要求を行なったユーザに割り当てられた、前記ユーザ管理データベースにおける固有のユーザＩＤを示すユーザＩＤ表示部と、　前記登録要求を行なったユーザに付与された、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級表示部と、　前記各グループに分類されたユーザのユーザＩＤを通知するグループメンバリストであって、予め定められた実ユーザ下限数以上の実ユーザのユーザＩＤが含まれるグループメンバリストを表示するグループメンバ表示部と、　前記ユーザ同士の対戦のうち、実ユーザが含まれるグループにおける対戦結果は表示して、仮想ユーザが含まれるグループにおける対戦の結果は非表示とする対戦結果表示部と、を有することを特徴とするゲームシステム。
  19. 登録されているユーザが参加するリーグ戦であって、前記登録されているユーザを、各グループが同一の階級に属するユーザで構成される１以上のグループに分類し、各グループに分類されたユーザ同士で対戦を行うリーグ戦を開催するゲームシステムであって、　前記ゲームシステムは、表示手段に表示するユーザインタフェースにおいて　登録要求を行なったユーザに割り当てられた、ユーザ管理データベースにおける固有のユーザＩＤを示すユーザＩＤ表示部と、　前記登録要求を行なったユーザに付与された、前記ユーザ同士の対戦の戦績によって変動する階級であって、予め定められた種類の階級のうちの１つの階級を示す階級表示部と、　前記各グループに分類されたユーザのユーザＩＤを通知するグループメンバリストであって、前記登録されているユーザのうち、前記ゲームシステムに最後にログインした日時が、現在日時から所定期間以上前であるユーザのユーザＩＤを含まないグループメンバリストを表示するグループ表示部と、を有し、　前記登録要求を行なったユーザが、前記ゲームシステムに最後にログインしてから前記所定期間以上経過後に再びログインした場合に、前記予め定められた種類の階級のうちの最下位の階級が前記階級表示部に表示されることを特徴とするゲームシステム。
PCT/JP2012/067743 2011-08-05 2012-07-11 ゲームシステム及びその制御方法、プログラム WO2013021777A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011172383A JP4955829B1 (ja) 2011-08-05 2011-08-05 ゲームシステム及びその制御方法、プログラム
JP2011-172383 2011-08-05

Publications (1)

Publication Number Publication Date
WO2013021777A1 true WO2013021777A1 (ja) 2013-02-14

Family

ID=46505999

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/067743 WO2013021777A1 (ja) 2011-08-05 2012-07-11 ゲームシステム及びその制御方法、プログラム

Country Status (2)

Country Link
JP (1) JP4955829B1 (ja)
WO (1) WO2013021777A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015024118A (ja) * 2014-03-03 2015-02-05 グリー株式会社 サーバ装置、その制御方法、プログラム、及びゲームシステム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5947728B2 (ja) * 2013-01-18 2016-07-06 株式会社コナミデジタルエンタテインメント ゲーム制御装置、プログラム、ゲームシステム
JP6965565B2 (ja) * 2017-05-12 2021-11-10 株式会社セガ ゲームシステム、サーバ装置及びプログラム
JP7263782B2 (ja) * 2019-01-10 2023-04-25 株式会社セガ ゲーム装置及びプログラム
CN110062258B (zh) * 2019-03-14 2021-07-30 视联动力信息技术股份有限公司 一种视联网号码的分配方法和装置
JP7199473B2 (ja) * 2019-08-21 2023-01-05 株式会社スクウェア・エニックス ビデオゲーム処理プログラム及びビデオゲーム処理システム
JP6878551B2 (ja) * 2019-10-31 2021-05-26 株式会社Ｃｙｇａｍｅｓ プログラム、情報処理装置および情報処理装置の制御方法
KR102235700B1 (ko) * 2020-06-16 2021-04-05 대한민국 기후 변화 협약 교육용 보드게임 시스템 및 이를 이용한 보드 게임 방법

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004329914A (ja) * 2003-05-09 2004-11-25 Microsoft Corp インスタントメッセージ機能を組み込んだゲーム
JP2007047889A (ja) * 2005-08-05 2007-02-22 Square Enix Co Ltd 通信制御プログラム、通信制御サーバ及び通信制御方法
JP2008036240A (ja) * 2006-08-08 2008-02-21 Sega Corp ランキング設定システム
JP2008538318A (ja) * 2005-04-19 2008-10-23 マイクロソフト コーポレーション ゲームプレイヤに関するフィードバックを提供し、ソーシャルマッチメイキング（ｓｏｃｉａｌｍａｔｃｈｍａｋｉｎｇ）を向上するためのシステムおよび方法
JP2009189594A (ja) * 2008-02-14 2009-08-27 Namco Bandai Games Inc サーバシステム及びマッチング方法
JP2009279345A (ja) * 2008-05-26 2009-12-03 Sega Corp ネットワークゲームシステム
JP2010237970A (ja) * 2009-03-31 2010-10-21 Namco Bandai Games Inc ネットワークシステム、サーバ、プログラム、及び情報記憶媒体

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004329914A (ja) * 2003-05-09 2004-11-25 Microsoft Corp インスタントメッセージ機能を組み込んだゲーム
JP2008538318A (ja) * 2005-04-19 2008-10-23 マイクロソフト コーポレーション ゲームプレイヤに関するフィードバックを提供し、ソーシャルマッチメイキング（ｓｏｃｉａｌｍａｔｃｈｍａｋｉｎｇ）を向上するためのシステムおよび方法
JP2007047889A (ja) * 2005-08-05 2007-02-22 Square Enix Co Ltd 通信制御プログラム、通信制御サーバ及び通信制御方法
JP2008036240A (ja) * 2006-08-08 2008-02-21 Sega Corp ランキング設定システム
JP2009189594A (ja) * 2008-02-14 2009-08-27 Namco Bandai Games Inc サーバシステム及びマッチング方法
JP2009279345A (ja) * 2008-05-26 2009-12-03 Sega Corp ネットワークゲームシステム
JP2010237970A (ja) * 2009-03-31 2010-10-21 Namco Bandai Games Inc ネットワークシステム、サーバ、プログラム、及び情報記憶媒体

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015024118A (ja) * 2014-03-03 2015-02-05 グリー株式会社 サーバ装置、その制御方法、プログラム、及びゲームシステム

Also Published As

Publication number Publication date
JP2013034623A (ja) 2013-02-21
JP4955829B1 (ja) 2012-06-20

Similar Documents

Publication Publication Date Title
JP4955829B1 (ja) ゲームシステム及びその制御方法、プログラム
US11141655B2 (en) Game control method, game control device, and recording medium
JP4975880B1 (ja) ゲームシステム、その制御方法、及びプログラム
JP5388016B1 (ja) ゲーム制御方法、ゲーム制御装置及びプログラム
KR101756191B1 (ko) 게임 서비스의 관리 서버, 게임 서비스의 제공 방법
JP6733019B1 (ja) ゲームシステム、ゲームシステムの実行方法およびゲームシステムのプログラム
JP5021835B1 (ja) ゲームシステム及びその制御方法、プログラム
JP5021834B1 (ja) ゲームシステム及びその制御方法、プログラム
JP5704266B1 (ja) ゲームサーバ装置およびゲームサーバプログラム
JP2018118105A (ja) 端末装置、コンピュータ、制御方法、及び制御プログラム
JP6526891B1 (ja) ゲーム制御プログラム、ゲーム制御方法およびゲーム制御システム
JP7157033B2 (ja) 情報処理装置、ゲームプログラム、及び、情報処理方法
JP6203035B2 (ja) ゲーム制御方法、ゲーム制御装置及びプログラム
JP6542156B2 (ja) ゲーム制御方法、コンピュータ及び制御プログラム
JP2020025854A (ja) ゲーム制御プログラム、ゲーム制御方法およびゲーム制御システム
JP5444498B1 (ja) ゲーム制御方法、ゲーム制御装置及びプログラム
JP2014161653A (ja) サーバ装置、および、方法
JP2017099946A (ja) 端末装置、制御方法及びプログラム
JP2017039037A (ja) ゲーム制御方法、ゲーム制御装置及びプログラム
KR101357918B1 (ko) 온라인 게임의 협력플레이 제공 시스템 및 그 방법
KR20140060026A (ko) 게임 방법, 이를 수행하는 게임 서버 및 이를 저장한 기록매체
JP2023123697A (ja) ゲーム制御方法、ゲーム制御装置及びプログラム
JP5458197B1 (ja) ゲームサーバ、ゲーム提供方法、コンピュータプログラム、コンピュータプログラムを記録したコンピュータに読み取り可能な記録媒体及びゲームシステム

Legal Events

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

Ref document number: 12821723

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12821723

Country of ref document: EP

Kind code of ref document: A1