Program, method, and system

Abstract

To provide a match game having further improved strategic characteristics regarding attributes.SOLUTION: In an authentication system, a program for allowing a computer to execute provision of a match game using a deck including a predetermined number of game media selected from multiple game media with which attributes are correlated each to users, and allows a computer to execute reception of selection of a game medium included in a deck used for a match game by users of multiple attributes before starting the match game, management of a deck such that the number of game media of each attribute of multiple attributes selected by a user becomes the minimum number predetermined for each attribute in the deck, and display of multiple attributes selected by a user and multiple attributes of a predetermined number of game media included in a deck used by a user's match opponent.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to programs, methods, and systems. [Background technology]

[0002] BACKGROUND ART Conventionally, there is known a technique for providing a user with a competitive game using a deck containing a predetermined number of game media selected from a plurality of game media (for example, digital cards), each of which has an attribute associated therewith. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6804675 Summary of the Invention [Problem to be solved by the invention]

[0004] In conventional battle games such as those described above, there is a restriction that decks must be organized using game media with a single attribute. Therefore, there is room for further improvement in strategic aspects related to attributes.

[0005] Therefore, one of the problems that the present disclosure aims to solve is to provide a program, method, and system that can provide a fighting game with improved strategic element regarding attributes. [Means for solving the problem]

[0006] An example authentication system of the present disclosure is a program that causes a computer to execute the following to provide a user with a competitive game using a deck that includes a predetermined number of game media selected from a plurality of game media, each of which has an attribute associated therewith. The program causes a computer to execute the following steps before the start of the competitive game: accepting a user's selection of multiple attributes of the game media to be included in the deck used in the competitive game; managing the deck so that the number of game media of each attribute selected by the user in the deck is equal to or greater than a predetermined minimum number for each attribute; and displaying the multiple attributes selected by the user and the multiple attributes of the predetermined number of game media included in the deck used by the user's opponent.

[0007] Another example method of the present disclosure is a method for providing a user with a competitive game using a deck including a predetermined number of game media selected from a plurality of game media each having an attribute associated therewith, the method including: accepting, before the start of the competitive game, a user's selection of multiple attributes of the game media to be included in the deck used in the competitive game; managing the deck so that the number of game media of each attribute selected by the user in the deck is equal to or greater than a predetermined minimum number for each attribute; and displaying the multiple attributes selected by the user and the multiple attributes of the predetermined number of game media included in the deck used by the user's opponent.

[0008] Furthermore, as yet another example of a system of the present disclosure, there is provided a system for providing a user with a competitive game using a deck containing a predetermined number of game media selected from a plurality of game media each having an attribute associated therewith, and the system includes: a reception processing unit that receives a user's selection of multiple attributes of the game media to be included in the deck to be used in the competitive game before the start of the competitive game; a management processing unit that manages the deck so that the number of game media of each attribute of the multiple attributes selected by the user in the deck is equal to or exceeds a predetermined minimum number for each attribute; and a display processing unit that displays the multiple attributes selected by the user and the multiple attributes of the predetermined number of game media included in the deck used by the user's opponent. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is an exemplary schematic diagram showing the configuration of a system according to an embodiment. [Figure 2] FIG. 2 is an exemplary schematic block diagram illustrating a functional configuration of a terminal device according to an embodiment. [Figure 3] FIG. 3 is an exemplary schematic sequence diagram illustrating a flow of processing executed by the terminal device and the server device according to the embodiment. [Figure 4] FIG. 4 is an exemplary schematic flowchart showing the flow of the deck compilation process executed by the terminal device according to the embodiment. [Figure 5] FIG. 5 is an exemplary schematic diagram showing an example of a class selection screen according to the embodiment. [Figure 6] FIG. 6 is an illustrative schematic diagram showing an example of a deck organization screen according to the embodiment. [Figure 7] FIG. 7 is an illustrative schematic diagram showing an example of a replacement confirmation image according to the embodiment. [Figure 8] FIG. 8 is an exemplary schematic diagram showing a deck organization screen in which the main class and sub-class are swapped with respect to the example shown in FIG. 6 according to an embodiment. [Figure 9]FIG. 9 is an exemplary schematic diagram illustrating an example of a storage confirmation image according to the embodiment. [Figure 10] FIG. 10 is an exemplary schematic diagram illustrating an example of a save alert image according to the embodiment. [Figure 11] FIG. 11 is an illustrative schematic diagram showing an example of a saved alert image different from that shown in FIG. 10 according to the embodiment. [Figure 12] FIG. 12 is an illustrative schematic diagram showing an example of the saved alert image according to the embodiment that is different from the examples shown in FIGS. 10 and 11. In FIG. [Figure 13] FIG. 13 is an illustrative schematic diagram showing an example of a saved alert image according to the embodiment that is different from those shown in FIGS. [Figure 14] FIG. 14 is an illustrative schematic diagram showing an example of a saved alert image according to the embodiment that is different from the examples shown in FIGS. [Figure 15] FIG. 15 is an exemplary schematic diagram showing an example of a battle start screen according to the embodiment. [Figure 16] FIG. 16 is an illustrative schematic diagram showing an example of the battle start screen different from that shown in FIG. 15 according to the embodiment. [Figure 17] FIG. 17 is an illustrative schematic diagram showing an example of the battle start screen according to the embodiment that is different from those in FIGS. 15 and 16. In FIG. [Figure 18] FIG. 18 is an exemplary schematic diagram showing an example of a battle screen according to an embodiment. [Figure 19] FIG. 19 is an illustrative schematic diagram showing an example of the battle screen according to the embodiment that is different from FIG. 18. [Figure 20] FIG. 20 is an illustrative schematic diagram showing an example of the battle screen according to the embodiment that is different from those in FIGS. 18 and 19. In FIG. [Figure 21] FIG. 21 is an exemplary schematic diagram illustrating an example of the interruption screen according to the embodiment. [Figure 22]FIG. 22 is an exemplary schematic block diagram illustrating an example of a hardware configuration of an information processing device constituting a terminal device and a server device according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of a program, method, and system according to the present disclosure will be described with reference to the accompanying drawings. The configurations of the embodiments described below, as well as the actions and effects brought about by the configurations, are merely examples and are not limited to the contents of the following description.

[0011] In addition, ordinal numbers such as "first" and "second" are used as necessary below, but these ordinal numbers are used for the convenience of identification and do not indicate a particular priority.

[0012] FIG. 1 is an exemplary schematic diagram showing the configuration of a system according to an embodiment.

[0013] 1, the system according to the embodiment includes a plurality of terminal devices 110, each including a display 110A with a touch panel, and a server device 120. The terminal devices 110 and the server device 120 are connected to each other so as to be able to communicate with each other via a network 150, such as the Internet.

[0014] 1 is merely an example and does not limit the technical spirit of the present disclosure. For example, FIG. 1 illustrates terminal devices 111 and 112 configured as tablet computers including displays 111A and 112A as examples of terminal device 110 including display 110A. However, the number of terminal devices 110 may be three or more, and terminal device 110 may be configured as an electronic device other than a tablet computer as long as it has a configuration equivalent to that of a general computer (a specific example will be described later with reference to FIG. 22).

[0015] With the above-described configuration, in the embodiment, a competitive game is realized between users of the terminal devices 110 via the network 150. For example, in the embodiment, the competitive game is a competitive game using a deck including a predetermined number of cards selected from a plurality of game media, such as digital cards (hereinafter simply referred to as cards), each of which is associated with an attribute (hereinafter referred to as a class).

[0016] For example, in an embodiment, a user of each terminal device 110 owns cards provided by the operator of the competitive game by digitally acquiring them through a lottery or the like, and then assembles a deck by selecting a predetermined number of cards from the cards they own, taking into consideration their class, and uses the assembled deck to play the competitive game with other users via the server device 120.

[0017] In the embodiment, the server device 120 records, for example, player information about users (players) playing a competitive game for each user participating in the competitive game. The player information includes, for example, information about cards owned by the player and information about decks that the player has organized in the past. The server device 120 then updates the recorded player information and controls the progress of the competitive game based on information output from the terminal device 110 in response to user operations.

[0018] Various techniques have been developed to provide users with a fighting game using a deck containing a predetermined number of cards selected from a plurality of cards, each of which is associated with a class. In such conventional fighting games, a deck must be constructed using game media of a single class. Therefore, there is room for further improvement in the strategic aspects of classes.

[0019] Therefore, the embodiment uses technology described in detail below to enable a competitive game using decks organized to include cards from multiple classes, under the condition that the minimum number of cards that must be included in a deck is predetermined for each class, thereby providing a competitive game with improved strategy regarding classes.

[0020] FIG. 2 is an exemplary schematic block diagram showing a functional configuration of the terminal device 110 according to the embodiment.

[0021] As shown in FIG. 2, the terminal device 110 includes a reception processing unit 201, a management processing unit 202, a game control processing unit 203, and a display processing unit 204.

[0022] The reception processing unit 201 receives inputs of various operations performed by the user using the terminal device 110. For example, before the start of a competitive game, the reception processing unit 201 receives a selection of the class of cards to be included in the deck used in the competitive game, and after the class selection, receives a selection of cards to be included in the deck.

[0023] The management processing unit 202 manages the organized decks in response to user operations. The specific content of the management performed by the management processing unit 202 will be explained in detail later, so further explanation will be omitted here.

[0024] The game control processing unit 203 controls the progress of the competitive game while communicating with the server device 120. The display processing unit 204 controls the output of images relating to the competitive game to the display 110A.

[0025] Based on the functional configuration described above, when providing a fighting game to a user, the terminal device 110 according to the embodiment executes various processes in cooperation with the server device 120 in accordance with the flow shown in the following Figure 3.

[0026] FIG. 3 is an exemplary schematic sequence diagram showing the flow of processing executed by the terminal device 110 and the server device 120 according to the embodiment.

[0027] 3, in the embodiment, the terminal device 110 (for example, the game control processing unit 203) first executes a login request process in S311 to obtain player information of the user of the terminal device 110 from the server device 120, and transmits login information including identification information of the user to the server device 120. The process of S311 is executed, for example, when an application installed on the terminal device 110 to provide a fighting game is started.

[0028] Then, in S321, the server device 120 executes a login process based on the login information received from the terminal device 110, extracts corresponding player information from the player information recorded by the server device 120, and transmits the extracted player information to the terminal device 110.

[0029] Then, in S313, the terminal device 110 (for example, the reception processing unit 201, the management processing unit 202, and the display processing unit 204) executes a deck organization process to organize decks to be used in the competitive game in accordance with user operations, and transmits deck information regarding the organized decks to the server device 120. As will be described in detail later, the deck organization process is a process in which the reception processing unit 201 accepts user operations and the management processing unit 202 manages the decks while the display processing unit 204 displays various images (screens) on the display 110A as necessary.

[0030] Then, in S322, the server device 120 executes a deck information saving process to save the deck information received from the terminal device 110 and update the player information recorded by the server device 120 itself.

[0031] Then, in S313 and S323, the terminal device 110 (for example, the reception processing unit 201, the game control processing unit 203, and the display processing unit 204) and the server device 120 each execute a game execution process in which they execute a competitive game while cooperating with each other via communication. The game execution process is a process in which the reception processing unit 201 accepts user operations and the display processing unit 204 displays various images (screens) on the display 110A, while the game control processing unit 203 controls the progress of the game.

[0032] Here, in an embodiment, the deck organization process of S312 above includes, as described below, a process of having the user select the class of cards to be included in the deck to be used in the competitive game, a process of having the user select the cards to organize the deck, a process of saving the organized deck, and a process of displaying various images used in these processes on display 110A.

[0033] FIG. 4 is an exemplary schematic flowchart showing the flow of the deck compilation process executed by the terminal device 110 according to the embodiment.

[0034] 4, in the deck compilation process, first, in S401, the display processing unit 204 displays on the display 110A a class selection screen, such as that shown in the following Fig. 5, which is used for processing to allow the user to select the class of cards to be included in the deck to be used in the battle game. Then, the reception processing unit 201 receives input of a user's operation via the class selection screen.

[0035] FIG. 5 is an exemplary schematic diagram showing an example of a class selection screen according to the embodiment.

[0036] 5 is an example of a class selection screen. This image 500 includes an area 510 for accepting the selection of a class to be included in a deck used in a battle game, and a confirm button 520 for confirming the selection.

[0037] Under the condition that a deck containing cards of multiple classes is to be used in a battle game, the user can select multiple classes of cards to be included in the deck by performing an operation on area 510, for example, a touch operation via the touch panel of display 110A. The selection of these multiple classes is confirmed when a selection completion operation is performed by touching enter button 520.

[0038] For simplicity, the following description will focus on the case where two classes are selected via the class selection screen, but the technology disclosed herein is equally applicable to cases where three or more classes are selected via the class selection screen.

[0039] 5, area 510 displays selection button 511 for accepting selection of the class "Elf," selection button 512 for accepting selection of the class "Royal," selection button 513 for accepting selection of the class "Witch," and selection button 514 for accepting selection of the class "Dragon." Area 510 also displays selection button 515 for accepting selection of the class "Necromancer," selection button 516 for accepting selection of the class "Vampire," selection button 517 for accepting selection of the class "Bishop," and selection button 518 for accepting selection of the class "Nemesis."

[0040] Under the condition that a deck containing cards of two classes is to be used in a battle game, the user can select two classes of cards to be included in the deck by operating any two of the eight selection buttons 511 to 518. The selection of these two classes is confirmed when a selection completion operation is performed using the decision button 520. The first selected class becomes, for example, a main class as the main attribute that will be the main strength of the deck, and the second selected class becomes, for example, a sub-class as a sub-attribute that will support the main strength. In the embodiment, a restriction is imposed such that the above-mentioned minimum number predetermined for the main class must be greater than the above-mentioned minimum number predetermined for the sub-class.

[0041] 4, in S402, the reception processing unit 201 determines whether or not a selection completion operation, such as a touch operation on the above-described decision button 520, has been performed. If it is determined in S402 that a selection completion operation has not been performed, the process returns to S401, and the reception processing unit 201 continues to accept input of a user operation via the class selection screen.

[0042] On the other hand, if it is determined in S402 that the selection completion operation has been performed, the process proceeds to S403. Then, in S403, the display processing unit 204 displays on the display 110A a deck composition screen, such as that shown in the following Fig. 6, which is used for processing to allow the user to select cards to be included in the deck. Then, the reception processing unit 201 receives input of the user's operation via the deck composition screen.

[0043] FIG. 6 is an illustrative schematic diagram showing an example of a deck organization screen according to the embodiment.

[0044] 6 is an example of a deck organization screen. This image 600 includes a first area 610, a second area 620, a save button 630, a third area 640, a class swap button 650, and an automatic organization button 660.

[0045] First area 610 displays, for example, a list of cards digitally owned by the user, including cards of the class selected on the class selection screen described above and cards with a characteristic called "neutral," which are treated in data as having no class (or corresponding to all classes). Second area 620 displays a list of cards in the deck. The user organizes a deck by performing an operation (e.g., a touch operation) to select a card displayed in first area 610 and then performing an operation (e.g., a swipe operation) to move the selected card into second area 620. When save button 630 is operated (e.g., a touch operation), the organized deck is saved after undergoing a predetermined determination process (described below) to determine whether the number of cards in the deck meets a predetermined condition.

[0046] Note that the above-described display mode in which a list of cards of the main class, sub class, and "neutral" is displayed in the first area 610 is merely an example. In an embodiment, a list of all cards owned by the user may be displayed in the first area 610 by default. In this case, the user may use a card filter function that can be called up from the deck organization screen to extract (search) only desired cards from all cards, thereby displaying only the desired cards in the first area 610.

[0047] The third area 640 displays the name of the deck currently being organized. The user can change the name of the deck as desired. For example, the default deck name is a name in which the main class and subclass are listed in this order from left to right, separated by a slash mark ("Elf / Royal" in the example shown in FIG. 6). If the order of the main class and subclass in the default deck name is fixed, it becomes easy to identify from the default deck name which main class has a relatively large number of cards and which subclass has a relatively small number of cards.

[0048] The class swap button 650 accepts an operation to swap the main class and sub-class on the deck organization screen to reduce the need to return to the class selection screen to swap the main class and sub-class. When an operation (for example, a touch operation) is performed on the class swap button 650, a swap confirmation image such as that shown in the following Figure 7 is displayed as a pop-up on the deck organization screen.

[0049] FIG. 7 is an exemplary schematic diagram showing an example of a replacement confirmation image displayed when the main class and the sub class are replaced according to the embodiment.

[0050] 7 is an example of a replacement confirmation image, and displays a message prompting the user to confirm whether there is no problem with replacing the main class and subclass.

[0051] Image 700 also includes an execute button 710 and a cancel button 720. When the cancel button 720 is operated (for example, a touch operation), the deck organization screen as shown in Fig. 6 is displayed again. On the other hand, when the execute button 710 is operated (for example, a touch operation), the deck organization screen as shown in the following Fig. 8 is displayed, in which the main class and subclass have been swapped from the example shown in Fig. 6.

[0052] FIG. 8 is an exemplary schematic diagram showing a deck organization screen in which the main class and sub-class are swapped with respect to the example shown in FIG. 6 according to an embodiment.

[0053] Image 800 shown in Figure 8 is a deck organization screen in which the main class and subclass have been swapped compared to the example shown in Figure 6. Image 800 has the same screen configuration as image 600 shown in Figure 6. However, in this image 800, due to the swapping of the main class and subclass, the order of the main class and subclass is reversed in the deck name displayed in third area 640 ("Royal / Elf") compared to the deck name displayed in third area 640 of image 600 shown in Figure 6 ("Elf / Royal").

[0054] 4, in S404, the reception processing unit 201 determines whether or not a deck save operation has been performed via the deck composition screen, for example, a touch operation on the above-mentioned save button 630. If it is determined in S404 that a save operation has not been performed, the process returns to S403, and the reception processing unit 201 continues to accept input of user operations via the deck composition screen.

[0055] On the other hand, if it is determined in S404 that a save operation has been performed, the process proceeds to S405. Then, from S405 onwards, a predetermined determination process is executed to determine whether or not the number of cards in the deck satisfies a predetermined condition.

[0056] More specifically, in S405, the management processing unit 202 determines whether the total number of cards included in the deck is 40 or more. The number 40 corresponds to the predetermined number that is determined in advance as the necessary and sufficient number of cards to organize a deck. Needless to say, the number 40 is just an example, and in embodiments, a number other than 40 may be used as the predetermined number. Also, in embodiments, the predetermined number may be set as a range of numbers with an arbitrary width having an upper limit and a lower limit, such as 39 to 41.

[0057] If it is determined in S405 that the total number of cards included in the deck is less than 41, the process proceeds to S406. Then, in S406, the management processing unit 202 determines whether the total number of cards included in the deck is less than 41, that is, whether the deck contains exactly the predetermined number of cards.

[0058] In S406, if it is determined that the total number of cards in the deck is less than 41, the condition regarding the total number of cards in the deck is met. In this case, the process from S407 onward is executed to determine whether the condition regarding the minimum number of cards predetermined for each class is met.

[0059] More specifically, in S407, the management processing unit 202 determines whether the number of main class cards included in the deck is 24 or more. The number 24 corresponds to the predetermined minimum number of main class cards that must be included in a deck. Needless to say, the number 24 is just an example, and in some embodiments, a number other than 24 may be used as the minimum number of main class cards.

[0060] If it is determined in S407 that the number of main class cards is 24 or more, processing proceeds to S408. Then, in S408, the management processing unit 202 determines whether the number of sub-class cards included in the deck is 9 or more. Note that the number 9 corresponds to the predetermined minimum number of sub-class cards that must be included in a deck. Needless to say, the number 9 is just an example, and in embodiments, a number other than 9 may be used as the minimum number of sub-class cards as long as it is smaller than the minimum number of main class cards.

[0061] In the above example, the minimum number of cards in the main class is 24, the minimum number of cards in the subclass is 9, and the sum of the two (24 + 9), or 33, is smaller than the predetermined number of 40. For this reason, in this embodiment, it is possible to include up to seven cards in a deck that have the above-mentioned "neutral" characteristics and do not fall into either the main class or subclass. This further improves the playability of the game.

[0062] In the present embodiment, when creating a deck, it is possible to use decks created by other people that are publicly available on the Internet, etc. However, decks created by other people may contain cards that the player does not own, and decks that contain cards that the player does not own cannot be used in a competitive game. For this reason, it is desirable to check whether a deck is created using only cards that the player owns.

[0063] Therefore, if it is determined in S408 that the number of cards in the main class is 24 or more, the process proceeds to S409. Then, in S409, the management processing unit 202 determines whether the deck to be saved is composed only of owned cards.

[0064] If it is determined in S409 that the deck is composed only of owned cards, it can be determined that the deck can be used in a competitive game. In this case, the process proceeds to S410. Then, in S410, the management processing unit 202 saves deck information related to the deck that has been created, and shares the saved deck information with the server device 120.

[0065] Note that, when saving the deck information in S410, it is desirable to prompt the user to confirm whether or not there is no problem with confirming the saving of the deck information beforehand. Therefore, in the embodiment, the display processing unit 204 displays a save confirmation image as shown in the following Fig. 9 before saving the deck information. Then, the reception processing unit 201 receives user input via the save confirmation image.

[0066] FIG. 9 is an exemplary schematic diagram illustrating an example of a storage confirmation image according to the embodiment.

[0067] 9 is an example of a save confirmation image 900. This image 900 displays a message prompting the user to input the name of the deck.

[0068] Image 900 also includes an area 910 in which the input deck name is displayed, an enter button 920, and a cancel button 920. This allows the user to enter the deck name while checking area 910, and then operate enter button 920 (for example, by touching) to confirm the saving of the deck information.

[0069] Returning to FIG. 4, if the conditions in S405 to S409 are not met, it is desirable to notify the user of this.

[0070] Therefore, in the embodiment, if the conditions in S405 to S409 are not met, the process proceeds to S411. Then, in S411, the display processing unit 204 notifies the user that a deck that does not meet the conditions is about to be saved by displaying a save alert image as shown in the following Figures 10 to 14. Then, the reception processing unit 201 receives input of a user operation via the save alert image.

[0071] FIG. 10 is an exemplary schematic diagram illustrating an example of a save alert image according to the embodiment.

[0072] 10 shows an example of a save alert image that is displayed when the condition of S405 is not met. Image 1000 displays a message informing the user that a deck that does not meet the condition of S405 is about to be saved, and a message asking the user whether or not to save the deck despite the fact that the condition is not met.

[0073] Image 1000 also includes a save button 1010 and a cancel button 1020. This allows the user to confirm the saving of the deck, knowing that the condition of S405 above is not met, by operating (for example, touching) save button 1010. Note that if cancel button 1020 is operated (for example, touched), the deck organization screen as shown in FIG. 6 is displayed again.

[0074] FIG. 11 is an illustrative and schematic diagram showing an example of a saved alert image according to the embodiment that is different from the example shown in FIG.

[0075] 11 is an example of a save alert image that is displayed when the condition of S406 above is not met. This image 1100 displays a message informing the user that a deck that does not meet the condition of S406 above is about to be saved, and a message asking the user whether or not to save the deck despite the fact that the condition is not met.

[0076] Image 1100 also includes a save button 1110 and a cancel button 1120. This allows the user to confirm the saving of the deck, knowing that the condition of S406 above will not be met, by operating (for example, touching) save button 1110. Note that if cancel button 1120 is operated (for example, touched), the deck organization screen as shown in FIG. 6 is displayed again.

[0077] FIG. 12 is an illustrative and schematic diagram showing an example of a saved alert image according to the embodiment that is different from those shown in FIGS. 10 and 11. In FIG.

[0078] 12 is an example of a save alert image that is displayed when the condition of S407 is not met. This image 1200 displays a message informing the user that a deck that does not meet the condition of S407 is about to be saved, and a message asking the user whether or not to save the deck despite the fact that the condition is not met.

[0079] Image 1200 also includes a save button 1210 and a cancel button 1220. This allows the user to confirm the saving of the deck, knowing that the condition of S407 above will not be met, by operating (for example, touching) save button 1210. Note that if cancel button 1220 is operated (for example, touched), the deck organization screen as shown in FIG. 6 is displayed again.

[0080] FIG. 13 is an illustrative and schematic diagram showing an example of a saved alert image according to the embodiment that is different from those shown in FIGS.

[0081] 13 shows an example of a save alert image that is displayed when the condition of S408 is not met. Image 1300 displays a message informing the user that a deck that does not meet the condition of S408 is about to be saved, and a message asking the user whether or not to save the deck despite the fact that the condition is not met.

[0082] Image 1300 also includes a save button 1310 and a cancel button 1320. This allows the user to confirm the saving of the deck by operating (for example, touching) save button 1310, knowing that the condition of S408 above is not met. Note that if cancel button 1320 is operated (for example, touched), the deck organization screen as shown in FIG. 6 is displayed again.

[0083] FIG. 14 is an illustrative and schematic diagram showing an example of a saved alert image according to the embodiment that is different from those shown in FIGS.

[0084] 14 shows an example of a save alert image that is displayed when the condition of S409 is not met. This image 1400 displays a message informing the user that a deck that does not meet the condition of S409 is about to be saved, and a message asking the user whether or not to save the deck despite the fact that the condition is not met.

[0085] Image 1400 also includes a save button 1410 and a cancel button 1420. This allows the user to confirm the saving of the deck by operating (for example, touching) save button 1410, knowing that the condition of S409 above is not met. Note that if cancel button 1420 is operated (for example, touching), the deck organization screen as shown in FIG. 6 is displayed again.

[0086] 4, once the process of S411 is executed, the process proceeds to S412. Then, in S412, the reception processing unit 201 determines whether or not a save operation, for example, an operation (for example, a touch operation) of the save button 1010, 1110, 1210, 1310, or 1410, has been executed.

[0087] In S411, if it is determined that the save operation has not been performed, that is, that the cancel button 1020, 1120, 1220, 1320, or 1420 has been operated (for example, touched), the process returns to S403. On the other hand, if it is determined that the save operation has been performed, the process proceeds to S410.

[0088] When the process of S410 is completed, the series of processes shown in FIG. 4, that is, the process of S312 shown in FIG. 3, ends.

[0089] The above conditions of S405 to S409 may also be taken into consideration when a deck is automatically organized in response to an operation (e.g., a touch operation) of the automatic organization button 660 on the deck organization screen shown in FIG. 6 or 8. That is, in an embodiment, when the automatic organization button 660 is operated, a predetermined number of cards are automatically selected from a plurality of owned cards to organize a deck so that all of the above conditions of S405 to S409 are met. Which cards are selected may also be taken into consideration, for example, a cost predetermined for each card as play points required to play a card in a competitive game, and a priority arbitrarily set for each card by the organizer of the competitive game based on the usage rate of all cards, etc.

[0090] Furthermore, if a deck contains cards with an expiration date, and there is a long period of time between the compilation of the deck and the actual playing of a competitive game using that deck, the deck may become unusable when the competitive game is actually played due to the expiration date.

[0091] Therefore, in an embodiment, the determination of the conditions in S405 to S409 above may also be performed by the server device 120 at the start of the competitive game, that is, prior to S313 and S323 shown in Fig. 3. If the deck is unusable, the server device 120 notifies the terminal device 110 of this fact. In this way, it is possible to prevent the competitive game from being played with an unusable deck.

[0092] In the embodiment, it is desirable that the user be able to check the classes of cards included in the deck not only when organizing the deck, but also at the start of the competitive game (which may include before the start) and after the start. At this time, it is desirable that the user be able to check not only the classes of cards included in his / her own deck, but also the classes of cards included in the opponent's deck. Therefore, in the embodiment, the display processing unit 204 may display the classes of cards included in the deck using images (screens) such as those shown in Figures 15 to 21 below.

[0093] For example, in an embodiment, the display processing unit 204 may display a battle start screen such as that shown in the following Figure 15 at the start of a battle game, and may display on the battle start screen the classes of cards contained in the player's deck and the classes of cards contained in the opponent's deck.

[0094] First, FIG. 15 is an illustrative schematic diagram showing an example of a battle start screen according to the embodiment.

[0095] 15 is an example of a battle start screen. This image 1500 includes a first area 1510 that displays the classes of cards included in your deck, and a second area 1520 that displays the classes of cards included in your opponent's deck.

[0096] In the example shown in Figure 15, the classes of cards included in the deck are displayed with a letter indicating the main class and a letter indicating the subclass, arranged in that order from left to right with a slash mark between them ("Elf / Bishop", "Elf / Nemesis"). However, in an embodiment, the classes of cards included in the deck do not necessarily have to be displayed as letters, as in the example shown in the following Figure 16.

[0097] FIG. 16 is an illustrative schematic diagram showing an example of the battle start screen different from that shown in FIG. 15 according to the embodiment.

[0098] 16 is an example of a match start screen in which the classes of cards included in the deck are displayed as information other than text. This image 1600 includes a first area 1610 in which the classes of cards included in the player's deck are displayed, and a second area 1620 in which the classes of cards included in the opponent's deck are displayed.

[0099] In the first area 1610, an image 1611 indicating "Elf" as the main class of cards included in one's deck and an image 1612 indicating "Bishop" as the subclass of cards included in one's deck are displayed side by side in this order from left to right. In the second area 1620, an image 1621 indicating "Elf" as the main class of cards included in the opponent's deck and an image 1622 indicating "Nemesis" as the subclass of cards included in the opponent's deck are displayed side by side in this order from left to right.

[0100] In the example shown in Figure 16, the classes of cards included in the deck are displayed graphically. However, in some embodiments, the classes of cards included in the deck may be displayed as a combination of text and images, as in the example shown in Figure 17.

[0101] FIG. 17 is an illustrative schematic diagram showing an example of the battle start screen according to the embodiment that is different from those in FIGS. 15 and 16. In FIG.

[0102] 17 is an example of a match start screen in which the classes of cards included in the deck are displayed as information consisting of a combination of letters and graphics. This image 1700 includes a first area 1710 in which the classes of cards included in the player's deck are displayed, and a second area 1720 in which the classes of cards included in the opponent's deck are displayed.

[0103] In first area 1710, characters indicating "Elf" as the main class of cards included in one's deck, an image 1711 indicating "Elf" as the main class of cards included in one's deck, and an image 1712 indicating "Bishop" as the subclass of cards included in one's deck are displayed in this order from left to right. In second area 1720, characters indicating "Elf" as the main class of cards included in the opponent's deck, an image 1721 indicating "Elf" as the main class of cards included in the opponent's deck, and an image 1722 indicating "Nemesis" as the subclass of cards included in the opponent's deck are displayed in this order from left to right.

[0104] In the example shown in FIG. 17, only the main class is displayed as a character, and the subclass is not displayed as a character, but in an embodiment, both the main class and the subclass may be displayed as a character.

[0105] In addition, in an embodiment, after the start of a battle game, the display processing unit 204 may display a battle screen such as that shown in Fig. 18 below, and display supplemental information associated with the classes of cards included in the deck on the battle screen, allowing the user to confirm the classes of the cards included in the deck. The supplemental information is information indicating predetermined abilities for each class, etc.

[0106] FIG. 18 is an exemplary schematic diagram showing an example of a battle screen according to an embodiment.

[0107] 18 is an example of a battle screen. This image 1800 includes first information 1811 as supplemental information associated with "Necromancer," which is the main class of the cards included in the player's deck, and second information 1812 as supplemental information associated with "Elf," which is the subclass of the cards included in the player's deck. This allows the user to easily check the main classes and subclasses of the cards included in the player's deck and the abilities of the main classes and subclasses while playing a battle game.

[0108] 18, supplemental information about the classes (main class and sub class) of cards included in the opponent's deck is not displayed on the battle screen. However, in an embodiment, supplemental information about the classes of cards included in the opponent's deck may also be displayed on the battle screen. In this case, the user can (indirectly) understand the classes included in the opponent's deck by checking the supplemental information on the opponent's side.

[0109] In addition, the embodiment can also display the classes of cards included in the opponent's deck on the battle screen, for example, in a manner as shown in the following FIG.

[0110] FIG. 19 is an illustrative schematic diagram showing an example of the battle screen according to the embodiment that is different from FIG. 18.

[0111] Image 1900 shown in Figure 19 is an example of a battle screen that displays only the main classes of the cards included in the opponent's deck. This image 1900 includes an area 1910 that displays text indicating "Elf" as the main class of the cards included in the opponent's deck. This allows the user to easily check the main classes of the cards included in the opponent's deck while playing a battle game.

[0112] In the example shown in Figure 19, the subclasses of the cards in the opponent's deck are not displayed on the battle screen. However, in an embodiment, as shown in the following Figure 20, it is also possible to display both the main class and subclass of the cards in the opponent's deck on the battle screen.

[0113] FIG. 20 is an illustrative schematic diagram showing an example of the battle screen according to the embodiment that is different from those in FIGS. 18 and 19. In FIG.

[0114] Image 2000 shown in Figure 20 is an example of a battle screen that displays both the main class and subclass of cards included in the opponent's deck. This image 2000 includes an area 1910 in which, from the left, text indicating "Elf" as the main class of cards included in the opponent's deck and text indicating "Nemesis" as the subclass of cards included in the opponent's deck are displayed, separated by a slash mark. This allows the user to easily check both the main class and subclass of cards included in the opponent's deck while playing a battle game.

[0115] Furthermore, in an embodiment, it is also possible to display the classes of cards included in the deck on a pause screen that is displayed when a battle game is temporarily paused after it has started, as shown in the following Figure 21. The pause screen can be displayed in response to an operation (for example, a touch operation) of a pause button (not shown) provided on the battle screen.

[0116] FIG. 21 is an exemplary schematic diagram illustrating an example of the interruption screen according to the embodiment.

[0117] Image 2100 shown in FIG. 21 is an example of a pause screen. This image 2100 includes a first area 2110 and a second area 2120. In the first area 2110, characters indicating "Elf" as the main class of cards included in the player's deck and characters indicating "Bishop" as the subclass of cards included in the player's deck are displayed side by side in this order from left to right, separated by a slash mark. In addition, in the second area 2120, characters indicating "Elf" as the main class of cards included in the opponent's deck and characters indicating "Nemesis" as the subclass of cards included in the opponent's deck are displayed side by side in this order from left to right, separated by a slash mark. This allows the user to easily check the main classes and subclasses of cards included in the player's deck and the main classes and subclasses of cards included in the opponent's deck while the competitive game is paused.

[0118] As described above, the terminal device 110 according to the embodiment is configured to provide a user with a competitive game using a deck containing a predetermined number of cards selected from a plurality of cards, each of which is associated with a class. The terminal device 110 includes a reception processing unit 201, a management processing unit 202, and a display processing unit 204. The reception processing unit 201 is configured to receive, before the start of a competitive game, a user's selection of multiple classes of cards to be included in the deck used in the competitive game. The management processing unit 202 manages the deck so that the number of cards of each of the multiple classes selected by the user in the deck is equal to or greater than a predetermined minimum number for each class. The display processing unit 204 is configured to display the multiple classes selected by the user and the multiple classes of a predetermined number of cards included in the deck used by the user's opponent.

[0119] According to the above configuration, a user plays a battle game while taking into consideration multiple classes selected by the user and multiple classes of a predetermined number of cards included in the deck used by the user's opponent. Therefore, unlike a game where a deck must be organized using cards of a single class, a battle game with improved class-related strategy can be provided.

[0120] For example, in an embodiment, the plurality of classes includes a main class and a sub-class, and the minimum number of main classes is greater than the minimum number of sub-classes. With this configuration, the user needs to strategically organize their deck taking into account the minimum number of each of the main classes and sub-classes, thereby further improving the strategic nature of the battle game.

[0121] Furthermore, in an embodiment, the display processing unit 204 may display text or images indicating the multiple classes selected by the user and the multiple classes of a predetermined number of cards included in the deck used by the opponent on a battle start screen that is displayed at the start of the battle game (see, for example, FIGS. 15 to 17). With this configuration, it is possible to easily confirm at the start of the battle game what types of decks will be used in the battle game.

[0122] Furthermore, in an embodiment, the display processing unit 204 may display multiple pieces of supplemental information associated with multiple classes selected by the user on a battle screen that is displayed after the start of a battle game (see, for example, FIG. 18). With this configuration, the supplemental information related to one's own deck can be easily checked while playing a battle game.

[0123] Furthermore, in an embodiment, the display processing unit 204 may display, on a battle screen that is displayed after the start of a battle game, text or an image indicating all of the classes of a predetermined number of cards included in the deck used by the opponent, or the class of one card that contains the largest number of cards among the predetermined number of cards (see, for example, FIGS. 19 and 20). With this configuration, it is possible to easily check at least some of the classes used by the opponent while playing the battle game.

[0124] Furthermore, in an embodiment, the display processing unit 204 may display text or images indicating the multiple classes selected by the user and the multiple classes of a predetermined number of cards included in the deck used by the opponent on an interruption screen that is displayed when the competitive game is temporarily interrupted after it has started (see, for example, FIG. 21). With this configuration, it is possible to easily check what decks are being used in the competitive game when the competitive game is interrupted.

[0125] In addition, in an embodiment, the display processing unit 204 may display multiple classes selected by the user in a manner that allows the relative magnitude of the number of cards in each class to be discerned, and may also display multiple classes of a predetermined number of cards included in the deck used by the opponent in a manner that allows the relative magnitude of the number of cards in each class to be discerned. This configuration allows players to play a competitive game while checking the number of cards of each class included in their own deck and predicting, to some extent, the number of cards of each class included in their opponent's deck. This further enhances the strategic nature of the competitive game.

[0126] Finally, the hardware configuration of the terminal device 110 and the server device 120 according to the above-described embodiment will be described. The authentication module according to the embodiment is configured as an information processing device 2200 having a hardware configuration equivalent to that of a general computer, for example, as shown in the following Fig. 22.

[0127] FIG. 2 is an exemplary schematic block diagram showing a hardware configuration of an information processing device 2200 constituting the terminal device 110 and the server device 120 according to the embodiment.

[0128] 22, the information processing device 2200 includes a processor 2210, a memory 220, a storage 2230, an input / output interface (I / F) 2240, and a communication interface (I / F) 2250. These pieces of hardware are connected to a bus 2260.

[0129] The processor 2210 is configured as, for example, a CPU (Central Processing Unit), and controls the overall operation of each part of the information processing device 2200.

[0130] The memory 2220 includes, for example, ROM (Read Only Memory) and RAM (Random Access Memory), and provides volatile or non-volatile storage of various data such as programs executed by the processor 2210, and provides a working area for the processor 2210 to execute programs.

[0131] The storage 2230 includes, for example, a hard disk drive (HDD) or a solid state drive (SSD), and stores various types of data in a non-volatile manner.

[0132] The input / output interface 2240 controls the input of data to the information processing device 2200 from input devices such as a touch panel, keyboard, and mouse, and the output of data from the information processing device 2200 to output devices such as a display and speaker.

[0133] The communication interface 2250 enables the information processing device 2200 to communicate with other devices.

[0134] The functional configuration (see FIG. 2) of the terminal device 110 according to the embodiment is realized as a group of functional modules formed by cooperation between hardware and software as a result of the processor 2210 executing a program pre-stored in the memory 2220 or the storage 2230. However, in the embodiment, some or all of the group of functional modules shown in FIG. 2 may be realized only by hardware such as a dedicated circuit. Furthermore, in the embodiment, at least some of the group of functional modules shown in FIG. 2 may be realized on the server device 120 side.

[0135] It should be noted that the above-described programs do not necessarily need to be stored in advance in memory 2220 or storage 2230. For example, the above-described programs may be provided as a computer program product recorded in an installable or executable format on a computer-readable medium, such as various magnetic disks such as flexible disks (FDs) or various optical disks such as DVDs (Digital Versatile Disks).

[0136] The above-described program may also be provided or distributed via a network such as the Internet. That is, the above-described program may be provided in a state where it is stored on a computer connected to a network such as the Internet and is available for download via the network.

[0137] Although several embodiments and variations thereof of the present disclosure have been described above, these embodiments and variations thereof are presented as examples and are not intended to limit the scope of the invention. These novel embodiments and variations thereof may be embodied in various other forms, and various omissions, substitutions, and modifications may be made without departing from the spirit of the invention. These embodiments and variations thereof are included within the scope or spirit of the invention, and are also included in the inventions described in the claims and their equivalents. [Explanation of symbols]

[0138] 110 Terminal Equipment 201 Reception Department 202 Management Department 204 Display processing unit

Claims

1. A program for causing a computer to provide a user with a battle game using a deck including a predetermined number of game media selected from a plurality of game media each having an attribute associated therewith, before the start of the competitive game, accepting a selection by the user of a plurality of attributes of game media to be included in the deck used in the competitive game; managing the deck so that the number of game media for each of a plurality of attributes selected by the user in the deck is equal to or greater than a predetermined minimum number for each attribute, wherein the plurality of attributes include a main attribute and a sub-attribute, and the minimum number of the main attribute is greater than the minimum number of the sub-attribute; displaying the plurality of attributes selected by the user; and A program for causing the computer to execute the above.

2. The displaying includes displaying the plurality of attributes selected by the user on a deck composition screen that is displayed in response to the user's selection of the plurality of attributes to allow the user to select a game medium for forming the deck. The program according to claim 1.

3. A method for providing a user with a competitive game using a deck containing a predetermined number of game media selected from a plurality of game media each having an attribute associated therewith, comprising: receiving, by the computer, a selection by the user before the start of the competitive game of a plurality of attributes of game media to be included in the deck used in the competitive game; managing the deck by the computer so that the number of game media for each of a plurality of attributes selected by the user in the deck is equal to or greater than a predetermined minimum number for each attribute, wherein the plurality of attributes include main attributes and sub-attributes, and the minimum number of the main attributes is greater than the minimum number of the sub-attributes; displaying, by the computer, the plurality of attributes selected by the user; A method comprising:

4. A system for providing a user with a competitive game using a deck containing a predetermined number of game media selected from a plurality of game media each having an attribute associated therewith, comprising: a reception processing unit that receives, before the start of the competitive game, a selection by the user of a plurality of attributes of game media to be included in the deck used in the competitive game; a management processing unit that manages the deck so that the number of game media for each of a plurality of attributes selected by the user in the deck is equal to or greater than a predetermined minimum number for each attribute, the plurality of attributes including a main attribute and a sub-attribute, and the minimum number of the main attribute is greater than the minimum number of the sub-attribute; a display processing unit that displays the plurality of attributes selected by the user; A system comprising:

Images