JP2013034624A - Game system, control method thereof, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To create a deck for every plurality of game modes, or to smoothly start a network match.SOLUTION: A game system receives a registration request, and relates a unique user ID to a user who has performed the registration request for registering in a user management database. Also, the game system adds a card ID of not less than one card to a deck table from among a plurality of cards related to a user ID of a user for each of the registered users, and creates a deck having a different deck ID in relation to either game ID in a plurality of game formats. In reception of a selection request of a game format from a user terminal, the game system displays a deck table related to the game ID in the game format concerned.

Description

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

  There is a game system in which a card (real card) on which a character or the like is actually purchased or obtained by a user in the real world is registered in the game, and the card can be used in a game representing a virtual world. . In many of such game systems, a network battle between users is performed, and as in Patent Document 1, a user creates a card group called a deck composed of a plurality of cards according to a game rule, Can participate in a match.

  A game system using a real card can be enjoyed not only by a user enjoying a game battle as usual, but also by collecting real cards. For example, an attractive character is decorated and drawn on a real card, and there is a way to enjoy the card. In addition, there are so-called rare cards or the like that have a small number of issued cards and are difficult to obtain and have an added value that can be advantageously developed in games. Expect to experience the game continuously. That is, such a game system can be used by long-term fixed users by synergistically enhancing both the user's desire to increase game performance and the user's desire to acquire rare cards. It is expected to be done.

JP 2007-330807 A

  In such a game system, a plurality of game modes (forms) such as an official league mode that is performed according to official rules and a free battle mode that is performed by determining rules between users are prepared so as not to bore users. Is done.

  In a conventional game system, a user creates a plurality of decks in advance, and selects a deck to be used for a battle from a plurality of decks created in advance, and performs a battle. When multiple game modes are prepared, the strategy is different depending on the game mode, such as different rules, so the user prefers to create a deck for each game mode. When selecting a deck to be played, an incorrect deck that is not a deck created for the game mode may be selected.

  On the other hand, a game system that creates a deck from a limited number of cards and plays a battle may limit the combinations of decks used by the user when operated for a certain period of time since the start of the service. . This is because information sharing such as game capture between users, decks imitating users with high winning rates, and the like increase. If the combination of decks used by the user is limited, the battle with the user who uses the same deck may continue, which may arouse the user's interest.

  For this reason, some game systems sell new real cards in conjunction with software upgrades as a means of preventing users from getting bored. The user can create more various decks by purchasing a new real card and registering it in the game system. That is, the interest of the entire user can be guided to a game strategy method using a deck including a new card, so that the continuous introduction of a new card results in a long-term increase in users.

  By registering the created deck in each online battle card game, when the game system is applied for by other users, the game system will register the registered deck with other users. Some games will automatically play matches. In such a game system, for example, the user can select a user to battle from a list of users registered in the game system, and can perform a battle between users. However, such a list includes users who have been registered in the game system and have not used for a long time. For this reason, when a user desires a battle between decks using new cards, it may take time to find a user who uses the corresponding deck.

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

  In order to achieve the one object described above, the game system of the present invention comprises the following arrangement.

  A game system in which a game is progressed by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck. User registration means for receiving a registration request of the user, assigning a unique user ID to the user who made the registration request and registering it in the user management database, and each of the users registered in the user management database A notification means for notifying the user of a plurality of cards each having a different card ID, and a card selection request notified to the user by the notification means from the user terminal; The card I of each of the one or more cards selected by the user Is added to a deck table having a unique deck ID associated with the user ID of the user, and a creation means for creating a deck and one or more deck tables created by the creation means are displayed. Of the above deck tables, deck selection means for registering the deck ID of the deck table that has received a selection request from the user terminal as a deck ID used in the game, and each game has a different game ID. For each registered user, the creation means creates a deck table having a different deck ID in association with the game ID of each of the plurality of game formats, and the deck selection means registers For each registered user, the deck associated with that user's user ID Of Buru, and displaying a deck table associated with the game ID received a selection request of the game format from the user terminal.

  In order to achieve the one object described above, the game system of the present invention comprises the following arrangement.

  A game system in which a game is progressed by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck. A user registration means for assigning a unique user ID to the user who made the registration request and registering it in the user management database, and for each of the users registered in the user management database, the game system from the user terminal Login management means for managing the date and time when a login request is received in association with the user ID, and a list for displaying the registered user IDs of the registered users in addition to a battle list that is a list of users who can participate in the game Display means, and the list display means is a login manager. It is managed by the date and time that received the login request the user ID of the user is within the predetermined time period from the current date, and displaying in addition to higher battle list.

  With such a configuration, according to the present invention, it is possible to create a deck for each of a plurality of game modes or to smoothly start a network battle.

The figure which shows the example of a battle | competition screen displayed on the display apparatus of a user terminal in the online battle | competition card game which concerns on embodiment of this invention. The figure which showed the system configuration | structure of the game system which concerns on embodiment of this invention. The figure which showed the function structure of the game server 201 which concerns on embodiment of this invention. The figure which shows the example of a screen displayed at the time of free battle selection in the online competitive card game which concerns on embodiment of this invention. The figure which showed the information defined about the official league and each class in the online competitive card game concerning the embodiment of the present invention The flowchart of the deck organization process which concerns on embodiment of this invention The figure which shows the example of a screen which performs creation, edit, and registration of the deck which concerns on embodiment of this invention Flow chart of deck registration processing according to an embodiment of the present invention The figure which shows the example of a screen displayed at the time of selection of the shop menu which concerns on embodiment of this invention The figure for demonstrating the rental card purchase production which concerns on embodiment of this invention. Another figure for demonstrating the rental card purchase production which concerns on embodiment of this invention Yet another diagram for explaining the rental card purchase effect according to the embodiment of the present invention. Flowchart of free battle list update processing according to the embodiment of the present invention The figure which showed the data structure which concerns on embodiment of this invention

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Each provided game has the following characteristics.
Free battle: From other users currently registered in the game system
Arbitrary users are arbitrarily selected, and the corresponding users are for free battle
Play against the deck set to (Deck only for free battle)
For the original league or the official league to save time and effort
You may be able to substitute the set deck).
・ Original League: One user is the host, and the regulations set by the host
A league game that invites multiple users to participate.
・ Official league: Ranking based on the results of the users held on the game system
All users who have organized an official league deck will participate.
The game against To prevent the length of the league match from extending,
They are assigned to groups and play.
・ Interception Battle: Battle when selected as a free battle battle user by another user
The contents and results are displayed.

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

<Deck organization and registration>
As shown in FIG. 14A, in the online competitive card game of the present embodiment, the user can organize a “deck” composed of one or more cards for each type of game. The deck information 1406 is managed in the user management database 304 in association with the user ID. As shown in FIG. 14B, the deck table indicating deck information includes a deck ID 1420 for identifying a deck managed by the user, a game ID 1421 indicating the type of game, and one or more cards constituting the deck. ID 1422 is included. In the present embodiment, one user can use a card owned by one user to organize a plurality of decks by the following deck organization process. Further, by selecting and registering a game that uses the organized deck through a deck registration process described later, a deck associated with a game ID indicating the selected game is associated with the user ID of the user. It can be stored in the management database 304.

(Deck formation process)
Here, in the game system of the present embodiment, each user (hereinafter referred to as an operation user) added to the user management database 304 in response to a registration request from the user terminal 202 is executed when a deck is organized for each game. The deck organization process will be described with reference to the flowchart of FIG. The processing corresponding to the flowchart can be realized by the CPU 301 reading, for example, a corresponding processing program stored in the ROM 302, developing the program in the RAM 303, and executing the program. In the deck organization process, when the “deck” menu 402 is selected by the operating user on the display screen shown in FIG. 4, the deck menu display screen is displayed. It is assumed that the information indicating that the “Create / Edit” menu has been selected is started when the CPU 301 receives the information via the network I / F 306.

  FIG. 7A shows a display screen displayed on the display device of the user terminal 202 when the “create / edit deck” menu of the pull-down menu 701 is selected. The display screen for creating and editing the deck includes a pull-down menu 701, a deck list 702, a new creation button 703, a deck organization area 704, an owned card area 705, a total cost 706, and a maximum cost 707.

  The pull-down menu 701 includes a “deck creation / edit” menu for creating a new deck or editing an already created deck, or a “deck registration” menu for registering the created deck in each game. This is a selection type menu list.

  The deck list 702 is a list of decks created by the operating user, and each deck is arranged to be selectable. The deck information displayed in the deck list 702 is stored in the user management database 304 as organized deck information in association with the user ID of the operating user. In the deck list 702, each deck is displayed as an icon composed of graphic data corresponding to one representative card, for example, among the information of the cards included in the deck. Specifically, the CPU 301 acquires the card ID of the representative card included in the deck, reads the graphic data associated with the card ID from the graphic database 307, creates an icon, and displays it.

  The representative card may be, for example, a leader card selected as a reference (base) for determining the attribute of the deck, a card first registered in the deck, or a card arbitrarily selected by the operating user.

  A new creation button 703 is a GUI for an operation user to issue a new creation instruction for a deck. When the operating user selects a new creation button 703 using the pointing device of the user terminal 202 to be used, a new deck creation request is transmitted from the user terminal 202 to the game server 201 via the network 203.

  The deck organization area 704 is an area in which cards added to the deck are displayed when a new deck is created or a previously created deck is edited. The operating user can create a deck by selecting a card to be added to the deck from the owned card area 705 described later and dragging and dropping the icon of the card to the deck organization area 704.

  The owned card area 705 is an area where a list of cards owned by the operating user is displayed. Information on the cards owned by the operating user is stored in the user management database 304 in association with the user ID of the operating user. For example, when displaying the deck creation / editing display screen, the CPU 301 reads possession card information associated with the user ID. As described above, the possessed card information includes logical type information indicating whether or not each card ID of all types of cards is owned and information indicating the number of owned cards. The CPU 301 reads the graphic data associated with the card ID from the graphic database 307 and draws it in the possessed card area 705 in accordance with the card ID of the card including the information indicating possession and the number of cards. .

  Cards that are already registered in the deck without allowing duplication of cards between the decks created by the operating user may not be displayed in the possessed card area 705. For example, when the CPU 301 displays a deck creation / edit display screen for one user, the CPU 301 refers to the organization deck information stored in the user management database 304 in association with the user ID of the user. Information on the organized card ID that is the card ID included in the deck table is acquired. The CPU 301 reads the graphic data associated with the card ID from the graphic database 307 and draws it in the owned card area 705 for the card ID that is not the organized card ID among the card IDs of the owned cards. In this way, by not displaying the cards already registered in the deck in the possessed card area 705, it is possible to avoid duplication of cards in the deck created by the operating user.

  Cards that are already registered in the deck are displayed in the possessed card area 705, but when the card selected in the area is added to the deck, the card ID of the card is included in the organized card ID. In such a case, the configuration may not be added. Further, although the cards already registered in the deck are displayed in the possessed card area 705, a configuration in which selection is impossible is also possible.

  The total cost 706 and the maximum cost 707 are information indicating conditions for the deck to be created. In the online battle card game, a concept of “cost” is provided so that a battle between users can be performed fairly. Each card is provided with a score set in advance as “cost”. The operating user needs to organize one deck so that the total cost (total cost) of cards included in the deck is equal to or less than a preset maximum cost. The cost is set higher as the card has an added value capable of advantageously developing the game, such as a rare card. In addition, by setting the maximum cost so that a large number of rare cards cannot be included in one deck, it is possible to avoid the unilateral development of a battle situation in a battle between users.

  As described above, all the cards of the online competitive card game of the present embodiment are stored in the card database 305 in association with character information drawn on the card for different card IDs. Each card has a cost set according to the character being drawn, and the CPU 301 adds up the costs of each card added to the deck being created or edited to display the total cost displayed in the total cost 706. Acquire information indicating the cost. The information on the maximum cost 707 is the maximum value of the total cost of the cards that make up the deck. The value of the maximum cost may be a value determined according to the card selected as the base of the deck, for example, may be fixed according to the game, or may be an invariable value in the online battle card game. .

  The save button 708 is a GUI for the operation user to instruct registration of a card added to the deck organization area 704 as a deck. When the operating user selects the save button 708 using the pointing device of the user terminal 202 to be used, a deck registration request is transmitted from the user terminal 202 to the game server 201 via the network 203.

  In the following description of the deck organization process, the process when a new deck is created will be described. However, the following process also excludes the processes of S601 and S602 when editing an already created deck. Applicable.

  In step S <b> 601, the CPU 301 determines whether a new deck creation request has been made from the user terminal 202 used by the operating user. Specifically, the CPU 301 determines whether information indicating that the operating user has selected the new creation button 703 is received via the network I / F 306 on the display screen for creating and editing the deck. If the CPU 301 determines that a new deck creation request has been received, the process proceeds to step S602. If the CPU 301 determines that a new deck creation request has not been received, the CPU 301 repeats this step.

  In step S <b> 602, the CPU 301 assigns an unassigned deck ID to a newly created deck, and creates a deck table associated with the deck ID in the RAM 303. The unassigned deck ID may be an unassigned deck ID for the operating user.

  In step S <b> 603, the CPU 301 determines whether a card addition instruction to the deck has been issued. Specifically, the CPU 301 receives, via the network I / F 306, information indicating that the card displayed in the possessed card area 705 is selected by the operation user and dragged and dropped to the deck organization area 704. It is determined whether or not an instruction to add a card to the deck is made. If the CPU 301 determines that an instruction to add a card to the deck has been given, the process proceeds to S604. If the CPU 301 determines that no instruction to add a card has been given, the process proceeds to S605.

  When the CPU 301 determines that an instruction to add a card to the deck has been made, the CPU 301 acquires information indicating the card ID of the selected card from the network I / F 306.

  In S604, the CPU 301 adds the card ID information of the selected card to the deck table created in S602. Further, the CPU 301 obtains the cost information of the added card ID from the card database 305 and adds it to the total cost value stored in the RAM 303, for example, to update the display of the corresponding total cost 706.

  In step S <b> 605, the CPU 301 determines whether a deck registration request has been made from the user terminal 202 used by the operating user. Specifically, the CPU 301 determines whether information indicating that the operating user has selected the save button 708 has been received via the network I / F 306. If the CPU 301 determines that a registration request for a deck has been received, the process proceeds to step S606. If the CPU 301 determines that a registration request has not been received, the process returns to step S603.

  In step S606, the CPU 301 determines whether the total cost (total cost) of the cards added to the deck table created in step S602 is equal to or less than the maximum cost value. Specifically, the CPU 301 acquires and compares the total cost value and the maximum cost value stored in the RAM 303, for example. When the CPU 301 determines that the total cost is equal to or less than the maximum cost, the deck ID and the deck table information stored in the RAM 303 are stored in the user management database 304 in association with the user ID of the operating user, and the main deck is stored. Complete the organization process. If the CPU 301 determines that the total cost is greater than the maximum cost, the CPU 301 transmits a notification indicating that the total cost exceeds the maximum cost to the user terminal 202, and moves the process to S603. Specifically, the CPU 301 reads from the graphic database 307 notification graphic data indicating that the total cost exceeds the maximum cost, for example. The CPU 301 transmits the graphic data to the user terminal 202 via the network I / F 306 together with an instruction to superimpose the graphic data on the current display screen.

  In this way, each user can create a deck composed of one or more owned cards.

(Deck registration process)
Next, a deck registration process for registering a deck created by the deck organization process as a deck to be used for an arbitrary game of the online battle card game of this embodiment will be described with reference to the flowchart of FIG. The processing corresponding to the flowchart can be realized by the CPU 301 reading, for example, a corresponding processing program stored in the ROM 302, developing the program in the RAM 303, and executing the program. In the deck organization process, when the “deck” menu 402 is selected by the operating user on the display screen shown in FIG. 4, the deck menu display screen is displayed, and “deck registration” in the pull-down menu 701 is displayed on the transition screen. The information indicating that the “menu” has been selected will be described as being started when the CPU 301 receives the information via the network I / F 306.

  FIG. 7B shows a display screen displayed on the display device of the user terminal 202 when the “deck registration” menu of the pull-down menu 701 is selected. The display screen for registering the deck includes a pull-down menu 701, a game selection list 710, a deck candidate area 711, a registration button 712, a deck selection area 713, a selected deck 714, and a deck configuration display area 715.

  The game selection list 710 is a pull-down list for selecting a game for registering a deck. In this embodiment, the pull-down list of the game selection list 710 includes the above-described “free battle”, “original league”, “official league”, and “interception battle” as selectable games.

  The deck candidate area 711 is an area for stocking registration candidate decks. The operating user selects a deck as a registration candidate from a deck selection area 713 to be described later, and drags and drops the icon of the deck to the deck candidate area 711 to display the deck as a registration candidate in the deck candidate area 711. Can do.

  The registration button 712 is a GUI for instructing an operation user to register a registration candidate deck (group) stocked in the deck candidate area 711 as a deck to be used in a game selected in the game selection list 710. . When the operating user selects the registration button 712 using the pointing device of the user terminal 202 to be used, a registration request for registration candidate decks is transmitted from the user terminal 202 to the game server 201 via the network 203. The registration button 712 may be used when, for example, a registration candidate deck is not stocked in the deck candidate area 711, or when a deck stocked in the deck candidate area 711 does not satisfy the regulation of the game scheduled to be registered. It may be displayed in a non-selectable state.

  The deck selection area 713 is an area in which a deck that is created by the above-described deck organization process and is associated with the user ID of the operating user and stored in the user management database 304 is displayed in a selectable manner. In the present embodiment, the deck displayed in the deck selection area 713 is a deck that is not registered in any of the above-mentioned “free battle”, “original league”, “official league”, and “intercept game”. Is displayed. Specifically, the CPU 301 reads information on a deck table stored in the user management database 304 and not associated with information on a game ID that uses the deck among decks associated with the user ID of the operating user. . In the present embodiment, it is assumed that only decks that are not registered in the game are displayed in the deck selection area 713, but the embodiment of the present invention is not limited to this. For example, in the deck selection area 713, a deck that is already registered in the game may be displayed together with a notification indicating that it is already registered, or may be displayed in a state where it cannot be selected. Similarly to the deck list 702, the CPU 301 acquires the card ID of one representative card among the card IDs included in the deck table of the deck, and the graphic data associated with the card ID is obtained from the graphic database 307. This is read out to create an icon and displayed in the deck selection area 713.

  A selected deck 714 indicates a deck selected by the operating user in the deck selection area 713. In the deck configuration display area 715, cards constituting the selected deck 714 are displayed.

In step S <b> 801, the CPU 301 determines whether a deck selection instruction has been issued from the user terminal 202 used by the operating user. Specifically, the CPU 301 receives information indicating that the deck associated with the user ID of the operation user displayed in the deck selection area 713 has been selected by the operation user via the network I / F 306. Thus, it is determined whether or not a deck selection instruction has been made. If the CPU 301 determines that an instruction to select a deck has been given, the process proceeds to S802. If the CPU 301 determines that a selection instruction has not been given, the process proceeds to S803.
In step S <b> 802, the CPU 301 acquires deck ID information indicating the deck selected by the operating user, and reads out the deck table attached with the deck ID, which is associated with the user ID of the operating user, from the user management database 304. . The CPU 301 refers to each of the card IDs included in the read deck table, reads the graphic data associated with the card ID from the graphic database 307, and draws it in the deck configuration display area 715.

  In step S <b> 803, the CPU 301 determines whether an instruction for setting the selected selected deck 714 as a registration candidate has been issued. Specifically, the CPU 301 displays information indicating that the selected deck 714 out of the decks displayed in the deck selection area 713 has been dragged and dropped into the deck candidate area 711 by the operation user, and the network I / F 306. It is determined whether or not an instruction for the selected deck 714 to be a registration candidate has been issued. If the CPU 301 determines that an instruction for the selected deck 714 to be a registration candidate has been given, the process proceeds to S804. If the CPU 301 determines that no instruction has been given, the process proceeds to S805.

  In step S <b> 804, the CPU 301 stores the deck ID of the selected deck 714 in the RAM 303 as a registration candidate deck ID. Note that a plurality of registration candidate deck IDs may be set, and registration candidate deck ID information may be stored in the RAM 303 as a list.

  In step S <b> 805, the CPU 301 determines whether or not a registration request for making a registration candidate deck to be used in the game selected in the game selection list 710 has been made. Specifically, the CPU 301 determines whether or not a registration candidate deck registration request has been made based on whether information indicating that the registration button 712 has been selected by the operating user has been received via the network I / F 306. To do. If the CPU 301 determines that a registration candidate deck registration request has been made, the process proceeds to step S806. If the CPU 301 determines that no registration request has been made, the process returns to step S801.

  In step S <b> 806, the CPU 301 reads the registration candidate deck ID information stored in the RAM 303. In addition, the CPU 301 acquires game ID information corresponding to the game selected in the game selection list 710. The CPU 301 associates the game ID with the deck table corresponding to the registration candidate deck ID and stores it in the user management database 304 to complete the deck registration process. Note that the game ID information corresponding to the game selected in the game selection list 710 may be updated according to the game selected in the game selection list 710 and stored in the RAM 303. The item selected in the game selection list 710 may be referred to, and the game ID associated with the item may be acquired from the ROM 302.

  By doing in this way, the operating user can register the deck created by the deck organization process for each game to be used. It is assumed that the deck registered for each game is selected by the operating user from a list or automatically selected when starting each game.

  In this embodiment, the operation user has been described as performing “create / edit deck” and “register deck” on the display screen displayed when the “deck” menu 402 is selected. The registration method is not limited to this. For example, on the display screen for each game displayed when any of the menu tabs 401a to 401d shown in FIG. 4 is selected, a corresponding game deck may be created and registered.

<Card type>
In the online battle card game of this embodiment, each user can use two types of cards for battle. One of the card types is a “owned card” that can be permanently acquired by registering a real card purchased by each user in the real world, for example, by registering an individual identification number printed on the real card in the game system. is there. The other type of card is a “rental card” that can be temporarily acquired by each user purchasing at a “shop” in the game.

  The rental card can be purchased using virtual money in the game, which can be acquired by winning the game, for example. The temporarily acquired rental card can be used in the same way as a normal possession card, such as for deck organization. The rental card information acquired by the operating user is stored in the user management database 304 separately from the possessed card information associated with the user ID of the operating user and stored in the user management database 304, for example. It may be managed in association with the user ID. The rental card information acquired by the user includes, for example, logical type information indicating whether or not the card is owned as a rental card with respect to the card IDs of all cards, and the number of acquired cards as in the possessed card information. It is. The rental card information only needs to be stored in the user management database 304 in association with the user ID of the operation user owned.

  It is assumed that the period during which the operating user can use the acquired rental card is determined in advance, for example, for one battle, during one login, or for a predetermined time.

<Shop>
Here, the shop which can purchase the rental card mentioned above is demonstrated below using FIG. FIG. 9 shows a shop menu display screen that is transitioned to when the “shop” menu 403 is selected by the operating user on the display screen shown in FIG.

  In the online competitive card game of this embodiment, the same sales form is realized in the game in accordance with the sales form of the real card. As shown in the figure, the acquisition of a rental card in the online match card game of the present embodiment is a virtual form such as a so-called Carddass (registered trademark), in which a single card enclosed in a bag of wafers (confectionery) is acquired. It can be done by selecting either the form of acquiring two cards by inserting money and turning the dial, or the form of acquiring three cards from a bag (pack) containing only the cards it can. Each of the selection buttons 901 to 903 in FIG. 9 corresponds to three acquisition modes, and when the CPU 301 receives the information that one of the selection buttons is selected by the operation user via the network I / F 306, respectively. The graphic data corresponding to the acquisition form is read from the graphic database 307, and the display screen is drawn and transmitted to the user terminal 202.

(Rental card purchase production)
10 to 12 are diagrams for explaining screen transitions corresponding to the respective acquisition forms. The CPU 301 receives, from the network I / F 306, information indicating that point input has been performed on a predetermined component on the display screen using, for example, the pointing device of the user terminal 202 owned by the operating user. In response to the reception, the CPU 301 acquires graphic data of the transition screen from the graphic database 307 and sequentially transmits it to the user terminal 202 via the network I / F 306.

  When the information indicating that the operating user has selected the selection button 901 on the display screen of FIG. 9 is received via the network I / F 306, the CPU 301 selects the candy box 1001 (collection of candy bags) in FIG. The graphic data of the screen to be read is read from the graphic database 307. Then, the CPU 301 transmits the graphic data of the candy box 1001 to the user terminal 202 used by the operating user via the network I / F 306 together with an instruction to superimpose the graphic data of the candy box 1001 on the display screen of FIG.

  The confectionery boxes are divided into sets corresponding to the appearance time of the real card, such as “first bullet”, “second bullet”, etc .. From the image of the confectionery bags arranged in one confectionery box , Cards with the same appearance time can be obtained. Information about which of all the types of cards used in the online match card game of this embodiment belongs to the set corresponding to the appearance time of the real card is, for example, from the numbers included in the card ID of each card It may be discriminable. For example, the CPU 301 obtains information on a range of numbers included in the card ID included in the set corresponding to each appearance time from the card database 305, thereby identifying a candidate card obtained from the candy bag of the selected candy box. it can. That is, a card whose number within the range is included in the card ID is a candidate for a card obtained from the confectionery bag. When the user acquires a rental card of one appearance time, the CPU 301 uses the card ID randomly selected from the candidate card IDs as a rental card temporarily owned by the user, for example. The user management database 304 may be stored in association with the ID.

  When the left button 1002 or the right button 1003 is selected by the operating user, the CPU 301 receives information indicating the selection via the network I / F 306, and displays graphic data in which a desired confectionery box is displayed in the center as a graphic database 307. Read from. Then, the CPU 301 transmits the graphic data together with an instruction to superimpose the graphic data on the display screen of FIG.

  In addition, when the CPU 301 receives that the operation user inputs a point to the GUI of the confectionery box via the network I / F 306, the CPU 301 reads the graphic data of only one confectionery box 1004 from the graphic database 307. Then, the CPU 301 replaces the graphic data for selecting the confectionery box 1001 with an instruction to superimpose and display the graphic data of only the one confectionery box 1004 on the display screen of FIG. Send to. In the present embodiment, the graphic data of the confectionery box 1004 includes images of a plurality of confectionery bags, for example, having a layer structure so as to be separable.

  Further, when the operation user receives a point input on the image of one confectionery bag 1005 included in the confectionery box 1004 and receives selection through the network I / F 306, the CPU 301, as shown in FIG. An instruction to move the selected candy bag 1005 so as to jump out of the candy box 1004 is transmitted to the user terminal 202. Thereby, on the display device of the user terminal 202, a transition state in which the candy bag 1005 selected from the candy box 1004 pops out is displayed. In addition, after the candy bag 1005 is moved, the CPU 301 transmits a drawing instruction for superimposing and displaying only the candy bag 1005 on the screen of FIG. 9 to the user terminal 202 via the network I / F 306.

  Thereafter, on the display screen on which only the confectionery bag 1005 is displayed, the CPU 301 receives the fact that a point input to the confectionery bag 1005 has been performed by the operating user via the network I / F 306, and the CPU 301 detects that the confectionery bag is torn. The graphic data (c) is read from the graphic database 307. Then, the CPU 301 replaces the graphic data of only the confectionery bag 1005 with an instruction to superimpose and display the graphic data of the confectionery bag on the display screen of FIG. To the user terminal 202.

  At this time, the CPU 301 reads graphic data (card image 1006) corresponding to the card ID determined at random from the graphic database 307 and transmits it to the user terminal 202 via the network I / F 306. It is assumed that the CPU 301 transmits to the user terminal 202 a drawing instruction for sequentially exposing the card image at a predetermined speed from below the graphic data in which the candy bag is torn. By doing in this way, as shown in FIG.10 (c), the effect which the card image 1006 enclosed from the confectionery bag exposes is given with respect to an operation user.

  After the entire card image 1006 is exposed, the CPU 301 transmits an instruction to superimpose and display only the card image 1006 on the display screen of FIG. At this time, the CPU 301 further reads out graphic data notifying that the rental card has been acquired from the graphic database 307 and transmits the graphic data to the user terminal 202 together with an instruction to superimpose the graphic data. For example, the CPU 301 reads out the sound data of the confectionery mastication sound stored in the ROM 302 and transmits it to the user terminal 202, and causes the user terminal 202 to reproduce the sound data together with an instruction to display only the card image 1006. By doing in this way, it is possible to give the operating user the same effect as when the card is obtained by purchasing confectionery in the real world.

  When the information indicating that the operating user has selected the selection button 902 on the display screen of FIG. 9 is received via the network I / F 306, the CPU 301 displays the card casing 1101 (discharges the card) of FIG. The graphic data of the screen for selecting the housing to be read is read from the graphic database 307. The CPU 301 transmits the graphic data of the card housing 1101 to the user terminal 202 via the network I / F 306 together with an instruction to superimpose the graphic data of 1101 on the display screen of FIG. When the left button 1102 or the right button 1103 is selected by the operating user, the CPU 301 receives information indicating the selection via the network I / F 306 and displays graphic data in which a desired card housing is displayed in the center (FIG. 11). (B)) is read from the graphic database 307. Then, the CPU 301 transmits the graphic data together with an instruction to superimpose the graphic data on the display screen of FIG.

  In addition, when the CPU 301 receives, via the network I / F 306, that the operating user has made point input to the GUI of the card casing, the graphic data of only one card casing 1104 is read from the graphic database 307. Then, the CPU 301 replaces the graphic data for selecting the card casing 1101 with the instruction to superimpose and display the graphic data for only one card casing 1104 on the display screen of FIG. Transmit to terminal 202. In the present embodiment, the graphic data of the card housing 1104 includes two card images that face down (in a state where the back of the card is drawn), for example, having a layer structure so as to be separable. To do.

  Further, when the operation user receives a point input to the dial 1105 of the card casing 1104 via the network I / F 306, the CPU 301 displays the graphic data of the card casing 1104 according to the number of point inputs. The card image 1106 included in the image is transmitted to the user terminal 202 as shown in FIGS. 11 (c) and 11 (d).

  The CPU 301 reads graphic data corresponding to two randomly determined card IDs from the graphic database 307 and transmits the graphic data to the user terminal 202 via the network I / F 306. Then, after the entire card image 1106 is exposed, the CPU 301 gives an instruction to superimpose and display randomly determined graphic data of the card on the display screen of FIG. 9 instead of the graphic data of the card casing 1104 and the card image 1106. Send. At this time, the CPU 301 further reads out graphic data notifying that the rental card has been acquired from the graphic database 307 and transmits the graphic data to the user terminal 202 together with an instruction to superimpose the graphic data. By doing so, it is possible to give the operating user the same effect as when the card is obtained in the card case in the real world.

  When the information indicating that the operating user has selected the selection button 903 on the display screen of FIG. 9 is received via the network I / F 306, the CPU 301 displays the card pack 1201 (the card is enclosed in FIG. 12A). The graphic data of the screen for selecting the bag is read from the graphic database 307. The CPU 301 transmits the graphic data of the card pack 1201 to the user terminal 202 via the network I / F 306 together with an instruction to superimpose the graphic data of the card pack 1201 on the display screen of FIG. When the left button 1202 or the right button 1203 is selected by the operating user, the CPU 301 receives information indicating the selection via the network I / F 306, and displays graphic data in which a desired card pack is displayed in the center as a graphic database 307. Read from. Then, the CPU 301 transmits the graphic data together with an instruction to superimpose the graphic data on the display screen of FIG.

  In addition, when the CPU 301 receives, via the network I / F 306, that the operating user has made point input to the GUI of the card pack, the graphic data (FIG. 12B) of only one card pack 1204 is displayed as a graphic. Read from database 307. Then, the CPU 301 replaces the graphic data for selecting the card pack 1201 with the instruction to superimpose the graphic data of only one card pack 1204 on the display screen of FIG. Send.

  Thereafter, on the display screen on which only the card pack 1204 is displayed, when the operating user receives the point input to the card pack 1204 via the network I / F 306, the CPU 301 A drawing instruction for dividing the graphic data of the card pack 1204 as shown in FIG. 12C is transmitted to the user terminal 202. The division of the graphic data of the card pack 1204 gives the operating user a presentation effect indicating that the packaging of the card pack has been cut.

  At this time, the CPU 301 reads graphic data (card image 1205) corresponding to three randomly determined card IDs from the graphic database 307 and transmits it to the user terminal 202 via the network I / F 306. It is assumed that the CPU 301 transmits a drawing instruction for sequentially exposing the card image at a predetermined speed from below the divided graphic data of the card pack 1204. By doing in this way, as shown in FIG.12 (d), the effect which the card image 1205 enclosed from the card pack exposes is given with respect to an operation user.

  After the entire card image 1205 is exposed, the CPU 301 transmits an instruction to superimpose only the card image 1205 on the display screen of FIG. At this time, the CPU 301 further reads out graphic data notifying that the rental card has been acquired from the graphic database 307 and transmits the graphic data to the user terminal 202 together with an instruction to superimpose the graphic data. By doing so, it is possible to give the operating user the same effect as when the card is obtained by purchasing a card pack in the real world.

  As described above, in the online competitive card game of the present embodiment, an intuitive display screen transition for acquiring a rental card is operated by preparing a method similar to a means for purchasing a real card in the real world on the game. It can be presented to the user.

<Class system>
In the online battle card game of the present embodiment, a five-stage class system as shown in FIG. 5A based on the battle results of the users in the official league is provided. An upper limit number of users (Ucmax1, Ucmax2, Ucmax3, Ucmax4, and Ucmax5) is set for each class. Each class is identified by a class ID, and the class ID is associated with the user ID and stored in the user management database 304, whereby the class is given to the user.

  In the official league held on the game system, the users are assigned to a group which is a unit in which the users are assigned and played against each other. Users belonging to each group of the official league are configured with users to which the same class ID is assigned. In the official league, users are grouped for each predetermined session called a season. The grouped users are promoted or demoted according to the rank within the group of the official league at the end of the season. Specifically, the conditions for class promotion or demotion are determined for each class group, for example, as shown in FIG. 5B, and the number of users determined for each season of the official league between each class. The class fluctuates.

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

<Free Battle>
Hereinafter, the details of the free battle provided in the online battle card game of the present embodiment will be described below.

  As described above, in the free battle, the operating user can perform a battle by arbitrarily selecting another user registered in the game system. Specifically, the operating user can play a battle with a user who has organized an intercept battle deck among other users registered in the game system. Information on other users that can be played by the operating user is displayed in a list in the free battle list 404 as shown in FIG. 4, and the operating user can perform a free battle by selecting another user on the screen. .

(Free battle list update process)
Here, the free battle list update process updated by the user displayed in the free battle list displayed for each user 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 free battle list update process will be described as being started when the free battle menu tab 401a is selected by the operating user.

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

  In step S <b> 1301, the CPU 301 acquires class information given to the operating user. Specifically, the CPU 301 reads out information on the class ID associated with the user ID of the operating user from the user management database 304.

  In S <b> 1302, the CPU 301 sorts users who are registered in the game system and are given the same class as the user assigned to the operating user in order of the date and time when the last login request was received. Create a list. Specifically, the CPU 301 first associates each user ID stored in the user management database 304 with the user ID in order to obtain a user ID (participating user ID) of a user who can participate in the free battle. The information of the user ID of the user in which the deck for interception battle is registered is acquired. In addition, CPU301 memorize | stores the information of the participating user ID of the acquired free battle in RAM303.

  Then, the CPU 301 reads the associated class ID information from the user management database 304 for each participating user ID of the free battle, and the class ID is the same as the class ID assigned to the operating user acquired in S1301. Judge whether there is. When the CPU 301 determines that the class ID information is the same, the CPU 301 obtains the participating user ID and the information of the last login date and time associated with the participating user ID from the user management database 304, and stores the same class in the RAM 303. Add sequentially to the list. When the determination as to whether or not the class IDs are the same for all participating user IDs is completed, the CPU 301 refers to the information on the last login date and time to display the same class list stored in the RAM 303 as information on the login date and time. Sort so that is in descending order.

  In step S1303, the CPU 301 sorts the users who can participate in the free battle and have been given a rank one higher than the rank given to the operation user in order of the date and time when the last login request was accepted. Create a list. Specifically, the CPU 301 acquires a participating user ID for free battle from the RAM 303. Note that the user ID added to the same class list in S1302 may be excluded from the free battle participation user ID acquired in this step. Further, the CPU 301 reads the associated class ID information from the user management database 304 for each participating user ID of the free battle, and the class of the class one level higher than the class assigned to the operating user. It is determined whether it is the same as the ID. When the CPU 301 determines that the class ID information is the same, the CPU 301 acquires the participating user ID and the information of the last login date and time associated with the participating user ID from the user management database 304, and the upper class of the RAM 303. Add sequentially to the list. When the determination is made as to whether or not a class ID of a class one higher than the class assigned to the operating user is assigned for all participating user IDs, the CPU 301 displays information on the last login date and time. By referencing, the upper class list stored in the RAM 303 is sorted so that the login date and time is in descending order.

  If the class assigned to the operating user is C1 and there is no one higher class, the process of this step need not be executed. Moreover, although this embodiment demonstrates as what produces the upper rank list of the user who can participate in a free battle to which the rank higher one rank than the rank provided to the operation user was provided, an upper rank list is an operation user. It may be configured by a user ID of a user who can participate in a free battle, to which a higher class is assigned.

  In step S1304, the CPU 301 sorts the users who can participate in the free battle and have the class one level lower than the class given to the operation user in order of the date and time when the login request was last received. Create a list. Specifically, the CPU 301 acquires a participating user ID for free battle from the RAM 303. In addition, from the participating user ID of the free battle acquired in this step, the user ID added to the same class list in S1302 and the user ID added to the upper class list in S1303 may be excluded and acquired. Further, the CPU 301 reads the associated class ID information from the user management database 304 for each of the participating user IDs of the free battle, and the class of the class one level lower than the class assigned to the operating user. It is determined whether it is the same as the ID. If the CPU 301 determines that the class ID information is the same, the CPU 301 acquires the participating user ID and the information of the last login date and time associated with the participating user ID from the user management database 304, and stores the lower level of the RAM 303. Add sequentially to the class list. When the determination is made as to whether or not the class ID is assigned to a class ID one level lower than the class assigned to the operating user for all participating user IDs, the CPU 301 displays information on the last login date and time. By referencing, the lower class list stored in the RAM 303 is sorted so that the login date is in descending order.

  If the class assigned to the operating user is C5 and there is no one lower class, the process of this step need not be executed. Further, in this embodiment, the description will be made on the assumption that a lower class list of users who can participate in a free battle is created with a class one level lower than the class given to the operating user. It may be configured by a user ID of a user who can participate in a free battle, to which a lower class is assigned.

  In step S <b> 1305, the CPU 301 acquires information about the user ID of the user included in the first page in the pre-update free battle list from the RAM 303. In the online battle card game of the present embodiment, the CPU 301 stores information on the user ID included in the first page of the free battle list in the RAM 303 every time it is updated. In the present embodiment, information of six users is included in one page of the free battle list as shown in FIG.

  In S1306, the CPU 301 first determines a user to be displayed on the first page of the free battle list, using the same class list, upper class list, and lower class list created in the RAM 303 in S1302 to S1304. Specifically, the CPU 301 first creates an empty free battle table corresponding to the free battle list in the RAM 303. Then, user IDs are selected and added to the table in the sort order from the same class list, the upper class list, and the lower class list. At this time, the CPU 301 excludes the user ID of the user from being added to the first page so that the user included in the first page in the pre-update free battle list is not displayed again on the first page. To do.

  For example, when there are six users included in the first page in the free battle list as described above, the CPU 301 selects the user ID from the same class list in the sort order, that is, the descending order of login date and adds it to the free battle list. . In the present embodiment, the operation user basically includes the first page of the free battle list on the first page of the free battle list so that the user can smoothly start a battle with a user having the same class as the class assigned to the operation user. It is assumed that users with the same class are displayed. However, for example, when a user wants to try a newly created deck or to practice a battle, a battle with a user higher or lower than the user may be desired. For this reason, in the online battle card game of this embodiment, it is assumed that the first page of the free battle list includes at least one user who is given a higher or lower rank than the operating user.

  That is, the CPU 301 takes 1 from each of the user IDs of the four users included in the same class list, the upper class list, and the lower class list for the top page of the free battle table, that is, the fields for the top six names in the table. Add user IDs of people. At this time, the CPU 301 obtains the user IDs of a predetermined number of users from the same class list, upper class list, and lower class list in which the added user IDs are sorted in descending order of login date and time. Add to the battle table. Note that the CPU 301 may delete the user ID added to the free battle table from each of the same class list, the upper class list, and the lower class list.

  In S1307, the CPU 301 adds the remaining user IDs included in the same class list, the upper class list, and the lower class list to the free battle table. At this time, the CPU 301 may add the user IDs to the free battle table in the order of the most recent login date and time by referring to the information of the last login date and time associated with each user ID, for example. In addition to the first page, only the user ID assigned the same class as the operating user or the user ID assigned the same class may be preferentially added to the free battle table.

  In S1306, the number of user IDs included in the same class list, upper class list, or lower class list may be less than the number of users of the corresponding class added to the field for the first page of the free battle table. is there. In this case, the CPU 301 may add the remaining user ID to the field for the first page of the free battle table in S1307.

  In addition, the user ID added to the free battle table in S1307 has been described as the user IDs included in the same class list, the upper class list, and the lower class list. However, all users who can participate in the free battle are described. An ID, that is, a user ID of a user to whom all classes are assigned may be used.

  By doing in this way, when an operating user performs a free battle, the user whose final login date and time is close to the current time is displayed in the free battle list. For example, when a new real card is introduced, a user whose last login date and time is close to the current time may be using a deck that contains the possessed card obtained by registering the new real card. high. That is, by displaying a user whose last login date and time is close to the current time on the first page of the free battle list, the user can play against a user who uses a new card.

  As described above, the game system of the present embodiment can create a deck for each of a plurality of game modes, or can smoothly start a network battle. Specifically, the game system receives the registration request, and registers the user ID that is unique to the user who has made the registration request in the user management database. In addition, for each registered user, the game system adds a card ID of one or more cards to a deck table among a plurality of cards associated with the user ID of the user, A deck having a different deck ID is created in association with any game ID. When the game system receives a game format selection request from the user terminal, the game system displays a deck table associated with the game ID of the game format.

  In this way, when one of a plurality of game formats is selected by the user, a list of decks created as decks used in the game type can be presented to the user. For this reason, when a user plays a game in one game format, the user can play the game without accidentally selecting a deck created for another game format.

A game system in which a game is progressed by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck. A user registration unit that receives a registration request of the user, assigns a unique user ID to the user who made the registration request, and registers the user ID in the user management database; and for each user registered in the user management database, the user ID of the user A notification means for notifying the user of a plurality of cards each having a different card ID, and a card selection request notified to the user by the notification means from the user terminal; The card I of each of the one or more cards selected by the user Is added to a deck table having a unique deck ID associated with the user ID of the user, and a creation means for creating a deck and one or more deck tables created by the creation means are displayed. Of the above deck tables, a deck system for registering a deck ID of a deck table that has received a selection request from a user terminal as a deck ID used in the game, and a game system for each registered user from the user terminal Login management means for managing the date and time when the login request is accepted in association with the user ID, and each game has a different game ID, at least one of the registered user IDs of the user A plurality of free battle formats including selecting a user ID and playing a game The game system has, for each registered user, a deck table associated with the free battle game ID among the deck tables associated with the user ID of the user. the user ID of the user who determined that there, further comprising: a list display means for displaying in addition to the free battle in the list in a free battle list of possible participation users, creating means, for each of the users that are registered A deck table having a different deck ID is created in association with the game ID of each of the plurality of game formats, and the deck selection unit is configured to display, for each registered user, a deck table associated with the user ID of the user. Of these, related to the game ID that received the game format selection request from the user terminal In the free battle format, the list display means displays the user ID of the user whose login request is received within a predetermined period from the current date and time, which is managed by the login management means. It is characterized by being added to the top of the battle list and displayed .

A game system in which a game is progressed by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck. A user registration unit that receives a registration request of the user, assigns a unique user ID to the user who made the registration request, and registers the user ID in the user management database; and for each user registered in the user management database, the user ID of the user A notification means for notifying the user of a plurality of cards each having a different card ID, and a card selection request notified to the user by the notification means from the user terminal; The card I of each of the one or more cards selected by the user Is added to a deck table having a unique deck ID associated with the user ID of the user, and a creation means for creating a deck and one or more deck tables created by the creation means are displayed. Of the above deck tables, a deck selection unit that registers a deck ID of a deck table that has received a selection request from a user terminal as a deck ID to be used in a game, and the creation unit includes the registered user's For each of the plurality of game formats each having a different game ID, a deck table having a different deck ID is created in association with the game ID of each of the plurality of game formats. From the deck table associated with the ID, the game form is selected from the user terminal. Display deck table associated with the game ID of accepting the selection request, the plurality of cards each having a different card ID, registers the real cards, each of users registered purchased in the real world gaming system The game system includes a possession card associated with the user ID of the user and a rental card temporarily associated with the user ID of the user when the user purchases in the game. The apparatus further includes a sales unit that sells a rental card accompanied by a plurality of different display effects in the device, and an input unit that receives a point input made at the user terminal, and the plurality of display effects is at least a device that discharges the card The exposure status of the card image changes depending on the number of point inputs on the image. An image in which the packaging is broken by the first effect of notifying the purchase of the rental card when the card image is completely exposed and the point input on the image in which the card is packaged. And the second effect of notifying that the card image is exposed from the package and the rental card has been purchased, and the image of one confectionery bag among the images of a plurality of confectionery bags enclosing the card After the image of the one confectionery bag is moved by the point input above, the third image is notified that the card image is exposed from the one confectionery bag and the purchase of the rental card is made together with the confectionery chewing sound. It includes any one of production .

Claims (14)

A game system in which a game progresses by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck,
User registration means 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 user registered in the user management database, a notification means for notifying the user of a plurality of cards each having a different card ID associated with the user ID of the user;
A card selection request notified to the user by the notification means is received from the user terminal, and the card ID of each of the one or more cards selected by the user among the plurality of cards is associated with the user ID of the user. Creating means for creating a deck by adding to a deck table having a unique deck ID,
A deck that displays one or more deck tables created by the creating means and registers the deck ID of the deck table that has received a selection request from the user terminal among the one or more deck tables as a deck ID used in the game. Selecting means, and
The game has a plurality of game formats each having a different game ID;
The creating means creates a deck table having different deck IDs in association with the game IDs of the plurality of game formats for each of the registered users.
The deck selection means, for each of the registered users, out of the deck tables associated with the user ID of the user, the deck table associated with the game ID that has received a game format selection request from the user terminal. A game system characterized by displaying.   The game system according to claim 1, wherein the creating means does not add a card ID already added to the deck table to the newly created deck table.   3. The game system according to claim 1, wherein the notifying unit does not notify the user of a card having a card ID already added to the deck table. 4. The game format includes a free battle format in which at least one user ID is selected from user IDs of the registered users and a game is played.
For each of the registered users, login management means for managing the date and time when a login request to the game system is received from the user terminal in association with the user ID;
For each of the registered users, among the deck tables associated with the user ID of the user, the user ID of the user who has determined that the deck table associated with the free battle format game ID is registered. And a list display means for displaying in addition to the free battle list which is a list of users who can participate in the free battle,
In the free battle format, the list display means displays a user ID of a user who is managed by the login management means and whose date and time when the log-in request is received is within a predetermined period from the current date and time in the higher rank of the free battle list The game system according to any one of claims 1 to 3, wherein the game system is additionally displayed. The list display means includes:
The free battle list is divided into a plurality of pages, and the free battle list is displayed for each page.
When executing the update process of the free battle list, among the user IDs of users who can participate in the free battle, the user ID included in the first page in the immediately previous update process is the first page after the update process. The game system according to claim 4, wherein the game system is not included in the game system. For each of the registered users, a class ID that varies depending on the results of the battle between the users and indicates a class of a class of a predetermined type is associated with the user ID of the user. A class granting means for granting a class by
The first page of the free battle list displayed for each of the registered users is associated with a user ID associated with a higher class ID than a class ID associated with the user and a lower class ID. The game system according to claim 5, comprising at least one user ID. A plurality of cards each having a different card ID are: an owned card associated with the user ID of the user by registering in the game system a real card purchased by each of the registered users in the real world; The game system according to claim 1, further comprising: a rental card that is temporarily associated with the user ID of the user when the user purchases the game. Sales means for selling the rental card, accompanied by a plurality of different display effects on the display device of the user terminal;
And an input means for accepting point input made at the user terminal,
The plurality of display effects are at least:
The exposure state of the card image is changed according to the number of points input on the image of the device that ejects the card, and the rental card is notified when the card image is completely exposed. 1 production and
The second effect of notifying that the rental card has been purchased because the card image is exposed from the packaging and the card image is exposed by the point input on the image on which the card is packaged. When,
After the image of the one confectionery bag is moved by the point input on the image of one confectionery bag among the images of the plurality of confectionery bags in which the card is enclosed, the one confectionery bag together with the chewing sound of the confectionery A third effect for notifying that the card image has been exposed and the rental card has been purchased;
The game system according to claim 7, comprising: A game system in which a game progresses by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck,
User registration means 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 user registered in the user management database, login management means for managing the date and time when a login request to the game system is received from the user terminal in association with the user ID;
List display means for adding and displaying the user ID of the registered user to a battle list that is a list of users who can participate in the game;
The list display means adds and displays the user ID of a user managed by the login management means whose date and time when the login request is accepted is within a predetermined period from the current date and time at the top of the battle list. Feature game system. A control method of a game system in which a game is progressed by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck,
A user registration step in which the user registration means of the game system accepts a user registration request from a user terminal, assigns a unique user ID to the user who made the registration request, and registers it in the user management database;
For each user registered in the user management database, the notification means of the game system notifies the user of a plurality of cards each having a different card ID associated with the user ID of the user. A notification process;
The creation means of the game system accepts a card selection request notified to the user from the user terminal in the notification step, and selects a card ID of each of the one or more cards selected by the user from the plurality of cards. Creating a deck by adding to a deck table having a unique deck ID associated with the user ID of the user;
The deck selection means of the game system displays one or more deck tables created in the creation step, and the deck ID of the deck table that has received a selection request from the user terminal among the one or more deck tables is displayed as a game. And a deck selection process for registering as a deck ID to be used in
The game has a plurality of game formats each having a different game ID;
In the creation step, the creation means creates a deck table having different deck IDs in association with the game IDs of the plurality of game formats for each of the registered users,
In the deck selection step, the deck selection means associates, for each of the registered users, a game ID that has received a game format selection request from a user terminal in a deck table associated with the user ID of the user. A control method for a game system, characterized in that a displayed deck table is displayed. A control method of a game system in which a game progresses by using a deck that is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck,
A user registration step in which the user registration means of the game system accepts a user registration request from a user terminal, assigns a unique user ID to the user who made the registration request, and registers it in the user management database;
A login management step in which the login management means of the game system manages, for each of the users registered in the user management database, the date and time when the login request to the game system is received from the user terminal in association with the user ID;
The list display means of the game system further includes a list display step of adding and displaying the registered user ID of the registered user to a battle list that is a list of users who can participate in the game,
In the list display step, the list display means adds a user ID of a user who is managed by the login management step and whose login request is received within a predetermined period from the current date and time to the top of the battle list. A game system control method comprising:   The program for functioning a computer as each means of the game system of any one of Claim 1 thru | or 9. A game system in which a game progresses by using a deck which is a card group composed of one or more cards registered in the game system in advance, and users share cards in the deck,
The game has a plurality of game formats,
In the user interface displayed on the display means, the game system includes:
A user ID display section showing a unique user ID in the user management database assigned to the user who made the registration request;
A card display unit for displaying a plurality of cards associated with the user who made the registration request;
For each of the plurality of game formats, a card selection unit that receives a selection instruction of a card to be added to the deck among the plurality of cards displayed on the card display unit;
A deck display for displaying a deck created for each of the plurality of game formats;
A game system comprising: A game system in which a game is progressed by using a deck which is a card group composed of one or more cards registered in advance in the game system, and users share cards in the deck,
In the user interface displayed on the display means, the game system includes:
A user ID display section showing a unique user ID in the user management database assigned to the user who made the registration request;
Among the users registered in the game system, a user display unit that displays a list of users who can participate in the game, including a user whose login date and time is within a predetermined period from the current date and time,
A game system comprising: