JP6576413B2 - GAME PROGRAM, METHOD, AND INFORMATION PROCESSING DEVICE - Google Patents

Description

  The present disclosure relates to a game program, a method for executing the game program, and an information processing apparatus.

  Various businesses have provided game programs that use a deck organized by one or more objects to advance the game. A game using a deck is provided regardless of genre, and in addition to a play part for playing the main game, this type of game is a play preparation part for preparing to play the main play part. including. The play preparation part is, for example, a deck organization part for organizing a deck.

  In general, in the above-mentioned type of game, the concept of “cost” is often adopted for the deck in order to enhance the fun of the game. The cost is a value consumed as a consideration for incorporating an object into the deck, and is set for each object. The higher the in-game value an object has, the higher the cost. An upper limit value of the cost that can be consumed for the organization of the deck is set for the user, and the user can incorporate the object into the deck within the range of the upper limit value set for the user.

  As a result, only users who have abundant objects will be able to prevent the game from being favorably organized by vigorously organizing objects that have a high contribution (for example, high ability and strength) in the play part. Can keep.

  In addition, by setting an upper limit value for the cost of the deck, the user manages the objects on hand within the upper limit value, and strategically organizes an advantageous deck in the play part. Therefore, while the deck organization part is in the preparation stage of the main play part, the game performance of the deck organization part itself is enhanced.

JP 2014-128454 A (published July 10, 2014)

  However, the upper limit of the cost set for the user is generally set low for a user (beginner) who has just started a game, and the user satisfies the conditions by repeatedly playing. It will be raised by things. Therefore, it is difficult for a beginner to incorporate an object with high cost (that is, high value and strong) into the deck due to the upper limit of cost. In other words, even if a beginner obtains an object with a high value, he cannot use it to play a play part. As a result, the problem that the beginner's willingness to play the game is reduced, and the interest of the game is particularly impaired for the beginner.

  An object of one embodiment of the present disclosure is to improve the interest of a game.

  A game program according to the present disclosure is executed by a computer including a processor, a memory, an operation unit, and a display unit. The game program is incorporated in the deck by accepting an input operation for incorporating one or more objects into the deck from the user and executing a play preparation part for storing the deck generated according to the input operation in the memory. A step of determining whether or not the total cost associated with each of the one or more objects exceeds a predetermined upper limit, and a play part in which a user plays a game based on the game program using a deck. The step of executing the play part includes a step in which a play part progress is disadvantageous for the user when it is determined that the sum exceeds the upper limit. A step to be imposed at a predetermined timing and a penalty will be imposed And at least one of the notification that the penalties imposed, and displaying on the display unit at a predetermined timing during the progress of the play part.

  The method according to the present disclosure is a method in which a computer including a processor, a memory, an operation unit, and a display unit executes a game program. The method includes the steps of: a processor receiving an input operation for incorporating one or more objects in a deck from a user; and executing a play preparation part for storing the deck generated according to the input operation in a memory; Determining whether the sum of the costs associated with each of the one or more objects incorporated in the computer exceeds a predetermined upper limit, and the processor uses the game based on the game program and the user uses the deck Executing the play part, and the step of executing the play part includes a penalty that causes the play part to be disadvantageous to the user when the total is determined to exceed the upper limit. Steps and penalties to be imposed at predetermined times during the part At least one of the notification of and the penalties imposed imposed, and displaying on the display unit at a predetermined timing during the progress of the play part.

  An information processing apparatus according to the present disclosure includes a storage unit that stores a game program, a control unit that controls the operation of the information processing apparatus by executing the game program, an operation unit, and a display unit. The control unit receives an input operation for incorporating one or more objects into the deck from the user, executes a play preparation part that saves the deck generated according to the input operation in the storage unit, and executes at least one of the one or more objects incorporated in the deck The control unit determines whether or not the total cost associated with each of the objects exceeds a predetermined upper limit, and executes a play part in which a user plays a game based on the game program using a deck. When executing the play part, if it is determined that the total exceeds the upper limit, the penalty that the play part progress is disadvantageous for the user is imposed at a predetermined timing during the play part progress, and the penalty is Notifications of at least one of being imposed and / or penalized will be given to the play part in progress It is displayed on the display unit in the timing.

  According to one aspect of the present disclosure, there is an effect of improving the interest of the game.

It is a figure which shows the hardware constitutions of a game system. It is a block diagram which shows the functional structure of a user terminal and a server. It is a flowchart which shows the flow of the process performed in a user terminal based on the game program which concerns on this embodiment. It is a figure which shows an example of the game screen displayed on a display part when the play preparation part is performed. It is a figure which shows an example of the data structure of a card database. It is a figure which shows an example of the data structure of deck information. It is a figure which shows an example of the data structure of user information. It is a flowchart which shows the flow of a process when a user part performs a play part. It is a figure which shows an example of the battle ability parameter of each character after penalty implementation. It is a figure which shows an example of the game screen displayed on a display part when the play part is performed. It is a figure which shows an example of the game screen displayed on a display part when the play part is performed. It is a flowchart which shows the flow of a process when a server and a user terminal enforce a penalty. It is a flowchart which shows the flow of a process when a user terminal performs a play preparation part. It is a figure which shows an example of the game screen displayed on a display part when the play preparation part is performed. It is a flowchart which shows the flow of a process when a user terminal performs a migration preparation part. It is a figure which shows an example of the game screen displayed on a display part when the transfer preparation part is performed. It is a figure which shows an example of the game screen displayed on a display part when the transfer preparation part is performed.

Embodiment 1
A game system according to the present disclosure is a system for providing a game to a plurality of users. Hereinafter, the game system will be described with reference to the drawings. It should be noted that the present invention is not limited to these exemplifications, but is defined by the scope of claims, and is intended to include all modifications within the meaning and scope equivalent to the scope of claims. The In the following description, the same reference numerals are given to the same elements in the description of the drawings, and repeated description is not repeated.

<Hardware configuration of game system 1>
FIG. 1 is a diagram illustrating a hardware configuration of the game system 1. The game system 1 includes a plurality of user terminals 100 and a server 200 as illustrated. Each user terminal 100 is connected to the server 200 via the network 2. The network 2 includes various mobile communication systems constructed by the Internet and a radio base station (not shown). Examples of the mobile communication system include a so-called 3G and 4G mobile communication system, LTE (Long Term Evolution), and a wireless network (for example, Wi-Fi (registered trademark)) that can be connected to the Internet through a predetermined access point. It is done.

  The server 200 (computer, information processing apparatus) may be a general-purpose computer such as a workstation or a personal computer. The server 200 includes a processor 20, a memory 21, a storage 22, a communication IF 23, and an input / output IF 24. These components included in the server 200 are electrically connected to each other via a communication bus.

  The user terminal 100 (computer, information processing apparatus) may be a mobile terminal such as a smartphone, a feature phone, a PDA (Personal Digital Assistant), or a tablet computer. The user terminal 100 may be a game device suitable for game play. As illustrated, the user terminal 100 includes a processor 10, a memory 11, a storage 12, a communication interface (IF) 13, an input / output IF 14, a touch screen 15 (display unit), a camera 17, and a distance measuring sensor 18. With. These components included in the user terminal 100 are electrically connected to each other via a communication bus. Further, as shown in FIG. 1, the user terminal 100 may be configured to be able to communicate with one or more controllers 1020. For example, the controller 1020 establishes communication with the user terminal 100 in accordance with a communication standard such as Bluetooth (registered trademark). The controller 1020 may have one or more buttons and the like, and transmits an output value based on a user input operation to the buttons and the like to the user terminal 100. The controller 1020 may include various sensors such as an acceleration sensor and an angular velocity sensor, and transmits output values of the various sensors to the user terminal 100.

  Note that the controller 1020 may include the camera 17 and the distance measuring sensor 18 instead of or in addition to the user terminal 100 including the camera 17 and the distance measuring sensor 18.

  For example, at the start of a game, the user terminal 100 desirably allows a user who uses the controller 1020 to input user identification information such as the user's name or login ID via the controller 1020. As a result, the user terminal 100 can associate the controller 1020 with the user, and identifies which user the output value belongs to based on the transmission source (controller 1020) of the received output value. be able to.

  When the user terminal 100 communicates with a plurality of controllers 1020, each user grasps each controller 1020, so that the one user terminal 100 does not communicate with other devices such as the server 200 via the network 2. Multi-play can be realized. Further, each user terminal 100 is connected to each other by a wireless standard such as a wireless local area network (LAN) standard (communication connection is not performed via the server 200), so that a plurality of user terminals 100 can realize multi-play locally. You can also When the above-described multiplay is realized locally by one user terminal 100, the user terminal 100 may further include at least a part of various functions described later included in the server 200. Further, when the above-described multi-play is realized locally by a plurality of user terminals 100, the plurality of user terminals 100 may be provided with various functions described later included in the server 200 in a distributed manner.

  Note that the user terminal 100 may communicate with the server 200 even when the above-described multiplayer is realized locally. For example, information indicating a play result such as a result or win / loss in a certain game may be associated with the user identification information and transmitted to the server 200.

  The controller 1020 may be configured to be detachable from the user terminal 100. In this case, a coupling portion with the controller 1020 may be provided on at least one surface of the housing of the user terminal 100. When the user terminal 100 and the controller 1020 are coupled by wire through the coupling unit, the user terminal 100 and the controller 1020 transmit and receive signals via the wire.

  As shown in FIG. 1, the user terminal 100 may accept the mounting of a storage medium 1030 such as an external memory card via the input / output IF 14. Accordingly, the user terminal 100 can read the program and data recorded in the storage medium 1030. The program recorded in the storage medium 1030 is a game program, for example.

  The user terminal 100 may store the game program acquired by communicating with an external device such as the server 200 in the memory 11 of the user terminal 100, or store the game program acquired by reading from the storage medium 1030 in the memory 11. May be stored.

  As described above, the user terminal 100 includes the communication IF 13, the input / output IF 14, the touch screen 15, the camera 17, and the distance measuring sensor 18 as an example of a mechanism for inputting information to the user terminal 100. Each of the above-described units serving as an input mechanism can be regarded as an operation unit configured to accept a user input operation.

  For example, when the operation unit is configured by at least one of the camera 17 and the distance measuring sensor 18, the operation unit detects an object 1010 in the vicinity of the user terminal 100, and performs an input operation from the detection result of the object. Identify. As an example, a user's hand as an object 1010, a marker having a predetermined shape, or the like is detected, and an input operation is specified based on the color, shape, movement, or type of the object 1010 obtained as a detection result. The More specifically, when a user's hand is detected from a captured image of the camera 17, the user terminal 100 performs a user's input operation on a gesture (a series of movements of the user's hand) detected based on the captured image. Identify and accept as Note that the captured image may be a still image or a moving image.

  Alternatively, when the operation unit includes the touch screen 15, the user terminal 100 identifies and accepts a user operation performed on the input unit 151 of the touch screen 15 as a user input operation. Or when an operation part is comprised by communication IF13, the user terminal 100 specifies and receives the signal (for example, output value) transmitted from the controller 1020 as a user's input operation. Alternatively, when the operation unit includes the input / output IF 14, a signal output from an input device (not shown) different from the controller 1020 connected to the input / output IF 14 is specified and accepted as a user input operation.

<Game overview>
The game system 1 which concerns on this embodiment is a system for performing the game program which advances a game using the deck organized by one or more objects as an example. The game provided by the game system 1 includes a play preparation part for organizing a deck in addition to a play part for playing the main game.

  For example, an object may be called a character, a card, an item, or the like, and in particular, a character may be called a spirit, a player, or the like depending on the game context. Decks are sometimes called parties, teams, orders, etc., depending on the context of the game.

  The play part is the main part of the game that the user plays with the object incorporated in the deck aiming at clearing or winning. For example, in a game such as a role-playing game (RPG), a battle part that causes an ally object (character) incorporated in a deck to fight an enemy object corresponds to this play part. In some cases, a plurality of battle parts may be grouped into one quest as a play part.

  In a battle game based on sports, a part that plays a game of the sport against an enemy object operated by a computer or another person by a teammate object (player) incorporated in the deck corresponds to this play part. .

  The play preparation part is a part executed in a preparation stage for playing the play part. As an example, the play preparation part is a deck organization part. The deck organization part is a part in which the user selects an object to appear in the play part from among the objects on hand and performs an operation for organizing the deck.

  The above-described game program receives from the user an input operation for organizing one or more objects on the deck to the game system 1 and executes a play preparation part that stores the deck organized by the user in a memory; Determining whether or not the total cost associated with each of the one or more objects incorporated in the deck exceeds a predetermined upper limit, and a game based on the game program by the user using the deck Executing a play part to be played.

  The game system 1 is not limited to a specific genre, and may be a system for executing games of any genre. For example, games such as tennis, table tennis, dodge ball, baseball, soccer and hockey, puzzle games, quiz games, RPG, adventure games, shooting games, simulation games, training games, action games, etc. Also good.

  The game system 1 is not limited to a specific play form, and may be a system for executing a game of any play form. For example, a single player game by a single user, a multiplayer game by a plurality of users, a multiplayer game, a battle game in which a plurality of users battle, a cooperative play game in which a plurality of users cooperate, and the like. May be.

  In the present embodiment, as an example, the object is given to the user as digital content resembling a card. Here, the form which gives an object to a user is not specifically limited. An object as digital content may be transmitted from the server 200 to the user terminal 100 via a communication network. Alternatively, in the server 200, an object is stored in the memory 21 in association with the user identification information of the user, and the user terminal 100 can arbitrarily read an object owned by the user from the server 200. Also good. Alternatively, the object may be sold or provided to the user on a physical medium on which a code, a password, a barcode, a QR code (registered trademark), or the like is printed. In this case, the user terminal 100 is caused to read the information printed on the physical medium so that the object can be used on a game executed by the user terminal 100.

  In the present embodiment, as an example, the game system 1 is a system that provides an RPG including a battle part that causes an ally object incorporated in a deck to fight an enemy object. In the present embodiment, a quest including one or a plurality of battle parts is provided to the user terminal 100 of the user as a play part. The user uses the deck to play a quest that is the main part of the game. In the present embodiment, an object is treated as a character as an example.

  In this embodiment, as an example, in the battle part, a quiz element is executed, an attack action of the teammate character is determined based on a user's play result in the quiz element, and each teammate character is caused to perform an attack action. Further, in the battle part, the attack action of the enemy character is determined in accordance with the turn system, and each enemy character is caused to perform the attack action. The combat part continues until the end condition is met. For example, the battle part is (1) the enemy character attacked by the friendly character is annihilated, and the party of the deck organized by the user wins. (2) the friendly character attacked by the enemy character is annihilated. The end condition is that the party is defeated by this, or (3) the user performs an operation of retirement (abandonment).

  As described above, the RPG provided by the game system 1 according to the present embodiment includes at least a deck organization part as a play preparation part in addition to a main play part including one or a plurality of battle parts.

  As an example, in addition to the above-mentioned two game parts, the RPG accepts various user instructions, selections, etc. during the preparation period from the play preparation part to the play part. A migration preparation part for setting may be included. Further, the RPG may include a reward granting part that grants a reward corresponding to the play result to the user after the play part is played by the user.

  The game system 1 may be a system for executing a multiplayer game, for example. RPG as a multiplayer game is between a user terminal 100 (client computer) operated by a user and one or more other user terminals 100 (other client computers) operated by one or more other users. Share at least part of the data related to the game. For example, a deck owned by each of a plurality of users is shared by the plurality of users. Thereby, RPG which can use a plurality of decks for play of one play part is realized.

  When the game system 1 is a multiplayer RPG, decks are organized in each of the first user terminal 100, the second user terminal 100, the third user terminal 100,... That communicate via the server 200. The Then, deck information D1, D2,... Each representing the contents of the organized decks is shared between the user terminals 100 via the server 200.

<Hardware components of each device>
The processor 10 controls the operation of the entire user terminal 100. The processor 20 controls the operation of the entire server 200. The processors 10 and 20 include a central processing unit (CPU), a micro processing unit (MPU), and a graphics processing unit (GPU).

  The processor 10 reads a program from a storage 12 described later and develops it in a memory 11 described later. The processor 20 reads a program from a storage 22 described later and develops it in a memory 21 described later. The processor 10 and the processor 20 execute the developed program.

  The memories 11 and 21 are main storage devices. The memories 11 and 21 include storage devices such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The memory 11 provides a work area to the processor 10 by temporarily storing a program and various data read from the storage 12 described later by the processor 10. The memory 11 also temporarily stores various data generated while the processor 10 is operating according to the program. The memory 21 provides the work area to the processor 20 by temporarily storing various programs and data read from the storage 22 described later by the processor 20. The memory 21 temporarily stores various data generated while the processor 20 is operating according to the program.

  In the present embodiment, the program may be a game program for realizing the game by the user terminal 100. Alternatively, the program may be a game program for realizing the game by cooperation between the user terminal 100 and the server 200. Alternatively, the program may be a game program for realizing the game by cooperation of a plurality of user terminals 100. The various data includes data relating to the game such as user information and game information, and instructions or notifications transmitted / received between the user terminal 100 and the server 200 or between the plurality of user terminals 100.

  The storages 12 and 22 are auxiliary storage devices. The storages 12 and 22 are constituted by a storage device such as a flash memory or an HDD (Hard Disk Drive). Various data relating to the game is stored in the storage 12 and the storage 22.

  The communication IF 13 controls transmission / reception of various data in the user terminal 100. The communication IF 23 controls transmission / reception of various data in the server 200. The communication IFs 13 and 23 control communication using, for example, communication via a wireless local area network (LAN), Internet communication via a wired LAN, a wireless LAN, or a cellular phone network, and short-range wireless communication.

  The input / output IF 14 is an interface for the user terminal 100 to accept data input, and is an interface for the user terminal 100 to output data. The input / output IF 14 may input / output data via a USB (Universal Serial Bus) or the like. The input / output IF 14 may include, for example, a physical button of the user terminal 100, a camera, a microphone, a speaker, or the like. The input / output IF 24 of the server 200 is an interface for the server 200 to accept data input, and is an interface for the server 200 to output data. The input / output IF 24 may include, for example, an input unit that is an information input device such as a mouse or a keyboard, and a display unit that is a device that displays and outputs an image.

  The touch screen 15 of the user terminal 100 is an electronic component that combines an input unit 151 and a display unit 152. The input unit 151 is a touch-sensitive device, for example, and is configured by a touch pad, for example. The display unit 152 is configured by, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display.

  The input unit 151 detects a position where a user operation (physical contact operation such as a touch operation, a slide operation, a swipe operation, and a tap operation) is input to the input surface, and inputs information indicating the position. A function of transmitting as a signal is provided. The input unit 151 may include a touch sensing unit (not shown). The touch sensing unit may adopt any method such as a capacitance method or a resistance film method.

  Although not shown, the user terminal 100 may include one or more sensors for specifying the holding posture of the user terminal 100. This sensor may be, for example, an acceleration sensor or an angular velocity sensor. When the user terminal 100 includes a sensor, the processor 10 can specify the holding posture of the user terminal 100 from the output of the sensor and perform processing according to the holding posture. For example, when the user terminal 100 is held in the portrait orientation, the processor 10 may perform a portrait screen display in which a portrait image is displayed on the display unit 152. On the other hand, when the user terminal 100 is held sideways, a horizontal screen display in which a horizontally long image is displayed on the display unit may be used. As described above, the processor 10 may be able to switch between the vertical screen display and the horizontal screen display according to the holding posture of the user terminal 100.

  The camera 17 includes an image sensor and the like, and generates a captured image by converting incident light incident from a lens into an electric signal.

  The distance measuring sensor 18 is a sensor that measures the distance to the measurement object. The distance measuring sensor 18 includes, for example, a light source that emits pulse-converted light and a light receiving element that receives the light. The distance measuring sensor 18 measures the distance to the measurement object based on the light emission timing from the light source and the light reception timing of the reflected light generated when the light emitted from the light source is reflected by the measurement object. The distance measuring sensor 18 may include a light source that emits light having directivity.

  Here, an example in which the user terminal 100 receives a detection result of detecting an object 1010 in the vicinity of the user terminal 100 using the camera 17 and the distance measuring sensor 18 as an input operation of the user will be further described. The camera 17 and the distance measuring sensor 18 may be provided on the side surface of the housing of the user terminal 100, for example. A distance measuring sensor 18 may be provided in the vicinity of the camera 17. As the camera 17, for example, an infrared camera can be used. In this case, the camera 17 may be provided with an illumination device that emits infrared light, a filter that blocks visible light, and the like. Thereby, it is possible to further improve the detection accuracy of the object based on the captured image of the camera 17 regardless of whether it is outdoors or indoors.

  The processor 10 may perform one or more processes on the captured image of the camera 17, for example, among the processes shown in the following (1) to (5). (1) The processor 10 performs image recognition processing on the captured image of the camera 17 to identify whether the captured image includes a user's hand. The processor 10 may use a technique such as pattern matching as an analysis technique employed in the above-described image recognition processing. (2) Moreover, the processor 10 detects a user's gesture from the shape of a user's hand. For example, the processor 10 specifies the number of the user's fingers (the number of fingers extending) from the shape of the user's hand detected from the captured image. The processor 10 further identifies a gesture performed by the user from the number of identified fingers. For example, when the number of fingers is five, the processor 10 determines that the user has performed a “par” gesture. In addition, when the number of fingers is 0 (no finger is detected), the processor 10 determines that the user has made a “goo” gesture. On the other hand, when the number of fingers is two, the processor 10 determines that the user has performed a “choke” gesture. (3) The processor 10 performs image recognition processing on the image captured by the camera 17 to detect whether the user's finger is in the state where only the index finger is raised or whether the user's finger has moved. . (4) The processor 10 determines an object 1010 (such as a user's hand) in the vicinity of the user terminal 100 based on at least one of the image recognition result of the image captured by the camera 17 and the output value of the distance measuring sensor 18. ) And the user terminal 100 are detected. For example, the processor 10 determines whether the user's hand is near (for example, a distance less than a predetermined value) or far (for example, a predetermined value) depending on the size of the shape of the user's hand specified from the captured image of the camera 17. It is detected whether the distance is above. When the captured image is a moving image, the processor 10 may detect whether the user's hand is approaching or moving away from the user terminal 100. (5) If it is determined that the distance between the user terminal 100 and the user's hand has changed while the user's hand is detected based on the image recognition result of the captured image of the camera 17, the processor 10 recognizes that the user is shaking his / her hand in the shooting direction of the camera 17. When an object is not detected in the distance measuring sensor 18 having higher directivity than the shooting range of the camera 17, the processor 10 indicates that the user is shaking his / her hand in a direction perpendicular to the shooting direction of the camera. recognize.

  In this manner, the processor 10 determines whether or not the user is grasping his / her hand by image recognition on the captured image of the camera 17 (“Goo” gesture or other gesture (eg “Par”)). ) Is detected. The processor 10 also detects how the user is moving the hand along with the shape of the user's hand. In addition, the processor 10 detects whether the user is approaching or moving away from the user terminal 100. Such an operation can correspond to an operation using a pointing device such as a mouse or a touch panel. For example, the user terminal 100 moves the pointer on the touch screen 15 according to the movement of the user's hand, and detects the user's gesture “goo”. In this case, the user terminal 100 recognizes that the user is continuing the selection operation. Continuation of the selection operation corresponds to, for example, maintaining a state where the mouse is clicked and pressed, or maintaining a touched state after a touchdown operation is performed on the touch panel. Further, when the user further moves his / her hand while the user's gesture “go” is detected, the user terminal 100 performs such a series of gestures as an operation corresponding to the swipe operation (or drag operation). It can also be recognized. In addition, when the user terminal 100 detects a gesture that the user repels a finger based on the detection result of the user's hand based on the captured image of the camera 17, the user terminal 100 clicks the gesture or taps the touch panel. You may recognize as operation corresponding to.

<Functional configuration of game system 1>
FIG. 2 is a block diagram illustrating functional configurations of the server 200 and the user terminal 100 included in the game system 1. Each of the server 200 and the user terminal 100 may include a functional configuration necessary for realizing a known function in a game, and a functional configuration necessary for functioning as a general computer (not shown).

  The user terminal 100 has a function as an input device that receives a user input operation and a function as an output device that outputs a game image and sound. The user terminal 100 functions as the control unit 110 and the storage unit 120 through cooperation of the processor 10, the memory 11, the storage 12, the communication IF 13, the input / output IF 14, and the like.

  The server 200 communicates with each user terminal 100 and has a function of supporting the user terminal 100 to advance the game. For example, the server 200 supports the progress of a quest or supports sharing of a deck among a plurality of users. When the game is a multiplayer game, the server 200 may have a function of communicating with each user terminal 100 participating in the game and mediating exchanges between the user terminals 100. The server 200 functions as the control unit 210 and the storage unit 220 through the cooperation of the processor 20, the memory 21, the storage 22, the communication IF 23, the input / output IF 24, and the like.

  The storage unit 120 and the storage unit 220 store a game program 131, game information 132, and user information 133. The game program 131 is a game program that is executed by the user terminal 100 and the server 200. The game information 132 is data that the control unit 110 and the control unit 210 refer to when executing the game program 131. The user information 133 is data relating to the user account. In the storage unit 220, game information 132 and user information 133 are stored for each user terminal 100.

  In the present embodiment, as an example of the game information 132, deck information 121 and a card database (hereinafter referred to as DB) 122 are stored in the storage unit 220 and the storage unit 120. As an example of the user information 133, an upper limit value of cost (hereinafter, cost upper limit value) set for each user is stored. The data structure of the deck information 121, the card DB 122, and the user information 133 will be described later.

(Functional configuration of server 200)
The control unit 210 performs overall control of the server 200 by executing the game program 131 stored in the storage unit 220. For example, the control unit 210 transmits various data and programs to the user terminal 100. The control unit 210 receives part or all of the game information or user information from the user terminal 100. When the game is a multiplayer game, the control unit 210 may receive a multiplayer synchronization request from the user terminal 100 and transmit data for synchronization to the user terminal 100.

  The control unit 210 functions as a quest support unit 211 and a sharing support unit 212 according to the description of the game program 131. The control unit 210 can also function as other functional blocks (not shown) in order to support the progress of the game on the user terminal 100 according to the nature of the game to be executed.

  The quest support unit 211 communicates with the user terminal 100 and provides support for the user terminal 100 to advance a quest as a play part. In particular, the quest support unit 211 provides the user terminal 100 with information necessary to implement a penalty when the user terminal 100 executes a penalty process in the play part.

  The sharing support unit 212 communicates with a plurality of user terminals 100, and supports a plurality of users to share each other's decks with each user terminal 100. The deck information of the decks organized by each user is stored in the storage unit 220 as game information 132 for each user. When receiving a request from the user terminal 100 of the user, the sharing support unit 212 supplies the deck information of the other user to the user terminal 100. Thereby, the user of the user terminal 100 can play a play part using another user's deck based on the supplied deck information.

  In the present embodiment, the sharing support unit 212 may randomly determine which user's deck information is to be supplied. Further, the sharing support unit 212 may supply the deck information of the user registered as a friend as the supply target, or may supply the deck information owned by the user of the online user terminal 100 as the supply target.

(Functional configuration of user terminal 100)
The control unit 110 performs overall control of the user terminal 100 by executing the game program 131 stored in the storage unit 120. For example, the control unit 110 advances the game according to the game program 131 and the user's operation. In addition, the control unit 110 communicates with the server 200 and transmits / receives information as necessary while the game is in progress.

  In accordance with the description of the game program 131, the control unit 110 includes an operation reception unit 111, a display control unit 112, a user interface (hereinafter referred to as UI) control unit 113, an animation generation unit 114, a deck organization unit 115, a transition preparation unit 116, It functions as a quest progression unit 117 and a cost determination unit 118. The control unit 110 can also function as other functional blocks (not shown) in order to advance the game according to the nature of the game to be executed.

  The operation receiving unit 111 detects and receives a user input operation on the input unit 151. The operation reception unit 111 determines what input operation has been performed based on the user's action on the console via the touch screen 15 and other input / output IF 14, and outputs the result to each element of the control unit 110. To do.

  For example, the operation reception unit 111 receives an input operation on the input unit 151, detects the coordinates of the input position of the input operation, and identifies the type of the input operation. The operation reception unit 111 specifies, for example, a touch operation, a slide operation, a swipe operation, a tap operation, and the like as the types of input operations. Further, the operation receiving unit 111 detects that the contact input is canceled from the touch screen 15 when the input that has been continuously detected is interrupted.

  The UI control unit 113 controls UI components displayed on the display unit 152 in order to construct a UI. The UI component is a tool for the user to make input necessary for the progress of the game to the user terminal 100, or a tool for obtaining information output during the progress of the game from the user terminal 100. The UI component is not limited to this, but is, for example, an icon, a button, a list, a menu screen, or the like.

  The animation generation unit 114 generates an animation indicating the motion of various digital contents based on the control mode of the various digital contents. For example, an animation representing a state in which a character card lottery is being executed may be generated. Alternatively, in the battle part, an animation expressing the action of an ally or enemy character may be generated. In the present embodiment, in particular, the animation generation unit 114 generates an animation that expresses how the teammate character incurs a penalty associated with cost excess in the battle part.

  The display control unit 112 outputs a game screen on which the processing results executed by the above-described elements are reflected on the display unit 152 of the touch screen 15. The display control unit 112 may display a game screen including the animation generated by the animation generation unit 114 on the display unit 152. In addition, the display control unit 112 may draw the above-described UI component so as to be superimposed on the game screen.

  The deck knitting unit 115 executes the deck knitting part according to the user's operation received through the operation receiving unit 111. The deck organization unit 115 has a deck organization function, and processes the deck information 121 in accordance with a user operation. For example, the deck organization function reads card information of a necessary character from the card DB 122, associates the read character with one or more frames provided in the deck information 121, and associates the frame with the character. Including releasing.

  The deck organization unit 115 also has a database processing function for searching, extracting, and sorting characters that match all conditions from the card DB 122 based on various parameters of the characters included in the card information.

  The migration preparation unit 116 executes the migration preparation part in accordance with a user input operation received via the operation reception unit 111. The transition preparation part is a part for performing various settings related to the play part after the user completes the deck organization part and transitions to play of the play part.

  The transition preparation part includes, for example, a first subpart for causing the user to select a quest to be played when there are multiple types of quests. Moreover, the 2nd subpart which makes the above-mentioned user select the helper character who participates in this quest may be included in the transition preparation part.

  In this embodiment, the user can be summoned to the battle part in the quest as a helper from another user's deck registered as a friend. The user can operate the summoned assistant character in the same manner as an ally character incorporated in his / her deck to participate in the battle.

  For example, in the second subpart, immediately before the start of the quest, the user selects another user who has organized a character that the assistant wants to come to the deck. The number of characters to be summoned as an assistant may be limited, for example, up to one, or all characters in the decks of other users may be summonable. Further, the conditions for summoning the assistant may not be set in particular, or may be determined in advance such as when a teammate character in his / her deck becomes incapable of combat.

  The quest progression unit 117 advances the quest as a play part based on the deck knitted by the deck knitting unit 115. In this embodiment, when the user clears one quest, a reward corresponding to the quest is given. The user plays the quest aiming at clearing. In this embodiment, as an example, in all battle parts included in the quest, it is determined that the user has cleared the quest when the ally character wins the enemy character.

  In this embodiment, multiple types of quests are provided according to the difficulty level and the attributes of enemy characters appearing in the battle part, and the user can select a quest to be challenged from among the multiple quests. . The quest progression unit 117 loads the quest selected by the user from the quest support unit 211 of the server 200 and causes the user terminal 100 to proceed.

  The cost determination unit 118 determines whether there is a cost excess in the deck knitted by the deck knitting unit 115. In the present embodiment, the above-described cost is set for all characters, and a cost upper limit value is set for the user. The cost determination unit 118 adds up the costs of all the characters that the user has organized into the deck, and compares the total cost in the obtained deck (hereinafter referred to as the total deck cost) with the user's cost upper limit value.

  Excessive cost means that the above-mentioned total deck cost exceeds the above-mentioned cost upper limit value. The cost determination unit 118 determines that the cost has exceeded the deck when the total deck cost exceeds the cost upper limit value of the user.

  In the present embodiment, the determination result of the cost determination unit 118 affects the behavior of at least one of the deck organization unit 115, the transition preparation unit 116, and the quest progression unit 117. In the example shown in FIG. 2, the cost determination unit 118 is provided independently of the deck organization unit 115, the transition preparation unit 116, and the quest progression unit 117. However, the cost determination unit 118 may function as a part of the deck organization unit 115, may function as a part of the transition preparation unit 116, or may function as a part of the quest progression unit 117. Good.

  Specifically, when the cost determination unit 118 determines that there is an excess cost in the deck, the quest progression unit 117 instead of disallowing the progress of the play part using the deck in which the cost excess has occurred, The penalty that the progress of the play part is disadvantageous for the user is imposed at a predetermined timing during the progress of the play part. In other words, the quest progression unit 117 performs the above-described penalty while the play part is in progress (in progress of the quest) instead of allowing the play part (quest) to be played while the cost is exceeded.

  Further, the quest progression unit 117 may display a notification to the effect that the penalty is to be imposed on the display unit 152 of the user terminal 100 before the above-described penalty is implemented during the play part. Alternatively, the quest progression unit 117 may display a notification that a penalty has been imposed on the display unit 152 of the user terminal 100 at a predetermined timing after the penalty is implemented while the play part is in progress. Further, the quest progression unit 117 may display the above notifications on the display unit 152 before and after the penalty is performed.

  Note that the functions of the server 200 and the user terminal 100 shown in FIG. 2 are merely examples. The server 200 may include at least a part of functions included in the user terminal 100. Further, the user terminal 100 may include at least a part of the functions included in the server 200. Furthermore, a device other than the user terminal 100 and the server 200 may be used as a component of the game system 1, and the other device may be caused to execute part of the processing in the game system 1. That is, the computer that executes the game program in the present embodiment may be any of the user terminal 100, the server 200, and other devices, or may be realized by a combination of these devices.

<Game flow>
FIG. 3 is a flowchart schematically showing a flow of processing when the game provided by the game system 1 according to the present embodiment is executed on the user terminal 100.

  In step S1, the deck organization unit 115 executes a play preparation part. As an example, the play preparation part is a deck organization part. The deck knitting unit 115 receives an input operation for knitting one or more objects on the deck from the user, and forms the deck according to the input operation. Then, deck information 121 indicating the organized deck is generated and stored in the storage unit 120 as shown in FIG.

  In step S2, the cost determination unit 118 determines whether the total cost (deck cost total) associated with each of the one or more objects incorporated in the deck by the user exceeds a predetermined upper limit (cost upper limit). Determine whether or not.

  In step S <b> 3, the transition preparation unit 116 may execute the transition preparation part to play part according to the determination result by the cost determination unit 118.

  In step S4, the quest progression unit 117 executes a play part. The play part is advanced based on the deck generated by the deck organization unit 115 in step S1.

  Step S4 includes the following steps in place of not being permitted when the execution of step S4 is determined to have exceeded the cost. Specifically, the play part in step S4 imposes (performs) a penalty at which the progress of the play part is disadvantageous for the user at a predetermined timing during the progress of the play part. Displaying at least one notification (penalty execution notification) of being imposed and a penalty being imposed on the display unit 152 at a predetermined timing during the play part.

  That is, even when it is determined that the cost has been exceeded, the execution of the play part in step S4 is permitted. Instead, while the play part is in progress, a penalty that impairs the progress is imposed, and a notification for causing the user to recognize it is displayed on the display unit 152.

  In step S5, after completing the play part, the quest progression unit 117 may give a reward to the user according to the play result of the user in the play part. Furthermore, the quest progression unit 117 may change the content of the reward to be given to the user according to the determination result by the cost determination unit 118. Specifically, when the above-mentioned play part is played using a deck that is determined to have a cost excess, the reward is reduced or the value is reduced compared to the case where it is not exceeded. You may make low and give to a user.

  The reward given to the user in step S5 is provided to the user as digital content that can be used on the game, for example. Specific contents of the reward include, for example, a card or figure corresponding to the character operated by the user, an item having a special effect, or an ability that can be worn by the character. Alternatively, the reward may be a right that the user can exercise on the game. Rights as rewards include, for example, the right to strengthen characters, the right to play special quests, the right to expand item inventory, the right to unlock locked quests or items, or the right to raise the cost limit. is assumed.

  Giving the digital content as a reward to the user may, for example, be a transition of the status of the digital content managed in association with the user from unusable to usable. Alternatively, the digital content may be stored in at least one of the memories (memory 11 and memory 21) included in the game system 1 in association with the user identification information.

  Hereinafter, the functional configuration of the user terminal 100 will be described in detail with reference to the game screen. Each game screen referred to below is configured by a UI part generated by the UI control unit 113, an animation generated by the animation generation unit 114, or a combination thereof. The game screen generated by the UI control unit 113 or the animation generation unit 114 is displayed on the display unit 152 of the user terminal 100 by the display control unit 112. The display control unit 112, the UI control unit 113, and the animation generation unit 114 are under the control of any of the units that advance each part of the game (deck organization unit 115, transition preparation unit 116, and quest progression unit 117). Processing for displaying the game screen on the display unit 152 is executed. Therefore, the description that “each part that advances each part displays the game screen on the display unit 152” means that “the part controls the UI control unit 113 or the animation generation unit 114 to generate a UI part or an animation. The display control unit 112 is controlled to display the game screen including the generated UI part or animation on the display unit 152 ”.

<About Deck>
(Screen example)
FIG. 4 is a diagram illustrating an example of a game screen displayed on the display unit 152 when the play preparation part is being executed. The game screen shown in FIG. 4 is a deck organization screen 400. The deck organization screen 400 includes various UI parts for the user to organize the deck. For example, the deck organization screen 400 includes at least a deck 401 and a copy list 402. The deck 401 is a UI component for arranging one or more characters to participate in the play part. The copy list 402 is a UI component that displays a list of copy characters held by the user that are candidates for incorporation into the deck.

  The operation receiving unit 111 receives a user input operation for placing a character on the deck 401. In the input operation, for example, a card icon (R1 to R15) of one character displayed in the copy list 402 is dragged and dropped on a frame (F1 to F5) to be arranged on the deck 401. This is realized by a drag and drop operation.

  The deck organizing unit 115 places the selected character's card in the drop destination frame in the deck 401 in accordance with the input operation. As an example, a maximum of 5 characters can be placed on the deck. The example shown in FIG. 4 shows a state in which characters are arranged in all five frames of the deck 401.

  The deck organization unit 115 preferably displays various parameters of the arranged characters in each frame of the deck 401. As a result, the user can check the performance of each character incorporated in the deck 401. In the present embodiment, at least the cost 403 of each character is displayed as a parameter related to the cost excess. Parameters referred to in the play part (for example, “physical strength”) may be further displayed.

  It is preferable that the deck organization unit 115 further displays the cost upper limit 404 set by the user and the deck cost total 405 of the deck 401 on the deck organization screen 400. As a result, the user can check whether the current total deck cost 405 exceeds the cost upper limit 404 of the user or is below.

  When the user can place a desired character on the deck 401 by repeating the drag-and-drop operation, the user inputs an instruction to confirm the contents of the deck 401 to the user terminal 100. The input of this instruction is realized by, for example, tapping the determination button 406.

  The operation reception unit 111 receives a tap operation on the determination button 406. In accordance with this instruction, the deck organizing unit 115 generates deck information representing the contents of the deck 401 and stores it in the storage unit 120 as the deck information 121. In the play part, the quest progression unit 117 refers to the deck information 121 stored in the storage unit 120 and advances the quest based on the deck represented by the deck information 121.

(data structure)
FIG. 5 is a diagram illustrating an example of the data structure of the card DB 122. The card DB 122 is a database for centrally managing cards possessed by the user. The card DB 122 is stored as game information 132 in the storage unit 120 of the user terminal 100, for example. The game information 132 held by each user terminal 100 may be fed back to the server 200 and stored in the storage unit 220 of the server 200. In this case, user identification information is associated with the card DB 122 and is managed for each user in the server 200. Alternatively, the card DB 122 may be stored for each user in the storage unit 220 of the server 200. In this case, the user terminal 100 requests and acquires the user's card DB 122 from the server 200 as necessary.

  Card DB122 contains each item of card ID, a card name, a basic parameter, and a battle ability parameter as an example.

  The card ID is for uniquely managing the user's card on the game system 1. In this embodiment, the user can carry a plurality of cards of the same character. Accordingly, when there are a plurality of cards even if the characters are the same, different card IDs are assigned to the respective cards in order to identify the respective cards. The card name indicates the name of the character corresponding to the card.

  The basic parameters refer to various parameters related to the character properties. The basic parameters are parameters that do not change during the play part. Examples of basic parameters include rarity, level, cost, and attribute.

  The rarity level represents the rarity value of a card (character) by a grade. In general, a high degree of rarity is set for a character that gives a good result in a game, particularly in a play part, that is, a character with high fighting ability. In the present embodiment, the degree of rarity is set by alphabets “S”, “A”, “B”, and “C” in order from the class with the highest rarity value.

  The rarity is, for example, the difficulty of obtaining a card, more specifically, the winning probability in a lottery where a card will win, the difficulty of a quest when it is obtained as a quest clear reward, or There may be a correlation with the price. The higher the rarity of the card, the higher the difficulty of obtaining the card.

  The level is a parameter indicating the degree of character strengthening. The higher the level, the higher the combat ability parameter referenced in the play part. In the play preparation part, the character's ability may be increased by strengthening the character with a reinforcing material or the like to increase the character's ability.

  The cost is a value consumed as a consideration for incorporating the character into the deck, and is set for each character. Generally, the higher the value of the character in the game, that is, the higher the fighting ability, the higher the cost.

  The attribute is a parameter indicating which property group the character belongs to when the character is classified by property. In the present embodiment, as an example, each character is classified into one of three attributes: fire, lightning, and water. The attribute may also be set for the enemy character.

  The attributes of the characters incorporated in the deck are referenced in the battle part to determine various values in the battle part. Each attribute may be set with an advantageous attribute and a disadvantageous attribute. For example, fire may be set to be advantageous for lightning, lightning for water, and water for fire. More specifically, in the battle part, it is conceivable that the fire attribute character can give more damage than usual to the lightning attribute enemy character. In addition, in the battle part, it is conceivable that friendly characters having the same attributes give an advantageous interaction for battle. Also, attributes may be set for quizzes given in the battle part. For example, the quest progression unit 117 may control so that only a character having the same attribute as the attribute set for the correctly answered quiz can perform the attack action.

  The battle ability parameter defines the performance of the character in the play part. The battle ability parameter is a parameter that can change during the progress of the play part. Examples of the battle ability parameter include physical strength, attack power, and skill.

  The physical strength is a parameter that defines the physical strength of the character, and is represented by a numerical value, for example. The numerical value is reduced by receiving an attack from an enemy character in the battle part. If the physical strength becomes 0, the character becomes incapable of battle. The physical strength is also set for the enemy character, and the battle can be won by setting the physical strength of all the enemy characters to 0 by the attack of the teammate character.

  The attack power is a parameter that defines the power of damaging the enemy character, and is represented by a numerical value, for example. The larger the value, the stronger the damage. In this embodiment, the attack power can be deprived of the physical strength of the enemy character by an attack that the character normally performs and a special attack (hereinafter referred to as “special attack”) performed by the character by activating a skill described later under certain conditions. Influences

  The skill is a special ability that each character has, and is a special ability that can be activated based on a predetermined condition in the battle part. Skills have an advantageous effect on teammate characters in the battle part. The action of the skill may be directly applied to the ally character, or the ally character may be indirectly advantageous by reaching the enemy character.

  As shown in the figure, the skill item includes the content of the skill and the degree of effect of the skill. The degree of the effect is represented by a numerical value, for example. Although not shown, the item may further include a condition that allows the skill to be activated.

  Specific examples of skills include, for example, a skill that damages enemy characters by special attacks, a skill that temporarily increases the attack power of a friendly character, a skill that recovers the physical strength of a friendly character, and damage received by an attack from an enemy character There may be a skill to alleviate the skill and a skill to lower the defense power of the enemy character. The conditions that enable these skills to be activated may be common to all characters or may be different for each character.

  As a numerical value representing the level of skill effect, for example, “300% (damage)” means to give three times as much damage as a normal attack.

  For example, the skill may be able to be activated when the user can correctly answer quickly within a predetermined time after the quiz is given. A skill that is activated based on the speed of the correct answer as described above may be referred to as a quick answer skill. Or a skill may be able to be activated when, for example, a predetermined number or more of correct answers can be made over a plurality of turns. A skill that is activated based on the cumulative number of correct answers as described above may be referred to as a correct answer number skill. Alternatively, the skill may be able to be activated when a correct answer is made more than a predetermined number of times without making an incorrect answer over a plurality of turns. A skill that is activated based on the number of consecutive correct answers may be referred to as a continuous answer skill.

  As described above, the basic parameter and the battle ability parameter are set for each character. The user selects five characters to be incorporated into the deck 401 shown in FIG. 4 from the record list 402 in consideration of the basic parameters and the combat ability parameters set for the hand-held character.

  FIG. 6 is a diagram illustrating an example of the data structure of the deck information 121. The deck information 121 is information representing the contents of the deck 401 organized by the user. One deck information 121 is generated for one deck. When the user owns a plurality of decks, deck information 121 is generated for each of the owned decks.

  The deck information 121 is stored as game information 132 in the storage unit 120 of the user terminal 100, for example. The deck information 121 may be stored in the storage unit 220 of the server 200 as with the card DB 122.

  The deck information 121 includes at least frame identification information corresponding to a frame provided on the deck 401 and a card ID of a card associated with the frame identification information. In the present embodiment, the deck 401 has five frames. Therefore, the deck information 121 includes deck frame numbers 1 to 5 corresponding to the five frames as frame identification information. A card ID is stored in association with each of the deck frame numbers 1 to 5.

  For example, deck frame number 1 corresponds to the frame F1 of the deck 401 in the deck organization screen 400 shown in FIG. Deck frame numbers 2 to 5 also correspond to frames F2 to F5, respectively. As an example, the deck information 121 shown in FIG. 6 indicates that the character “Fairy” having the card ID “0001-01” is arranged in the frame F1 corresponding to the deck frame number 1.

  The deck information 121 may further include an item for storing the cost of the arranged character for each frame. Furthermore, the deck information 121 may have an item for storing the total deck cost for each deck.

  FIG. 7 is a diagram illustrating an example of the data structure of the user information 133. The user information 133 includes various information set for each user who uses the game system 1.

  As an example, the user information 133 includes a user ID, a user name, and a cost upper limit value. In addition, the user information 133 may include a level, an experience value, and the like.

  The user ID is user identification information for uniquely identifying a user in the game system 1. The user name is a name indicating the user who plays the game system 1. The user name is used by, for example, the user himself / herself and other users to identify the user himself / herself. The cost upper limit value indicates the upper limit of the total deck cost in the deck. The cost upper limit is set for each user. The cost upper limit value is preferably increased when a predetermined condition is satisfied by the user playing the game. As an example, the cost upper limit is a parameter that increases according to the level of the user. An experience value is given to the user in response to the user playing a quest or the like of the play part, and the user's level increases when the experience value reaches a certain value. As the user level increases, the cost upper limit is increased. If the user wants to raise the cost upper limit value, he / she can play, accumulate experience values, and raise the level. In the present embodiment, the right to increase the cost upper limit value may be given to the user in exchange for a paid or free item. In this case, the control unit 110 accepts an operation for consuming a paid or free item performed by the user, consumes the item of the user, and instead, a cost upper limit value corresponding to the consumed item. Increase.

<About Penalty>
In this embodiment, when the total deck cost of the deck exceeds the cost upper limit value, the user terminal 100 gives the user a play part using a deck where the cost excess has occurred (hereinafter, a violation deck). Do not ban play. Instead, the user terminal 100 permits the user to play the play part using the violating deck in exchange for imposing a penalty based on the cost excess.

  In the present embodiment, the user terminal 100 further performs the above-described penalty during the period when the play part is in progress. For example, in the play preparation part (deck organization part), the user terminal 100 does not immediately perform a penalty when a cost excess is detected.

  Below, it demonstrates in detail using a specific example that the user terminal 100 implements a penalty in the advancing period of step S4 shown in FIG.

(Play part processing flow)
FIG. 8 is a flowchart showing the flow of processing when the user terminal 100 executes the play part in step S4 shown in FIG.

  In step S101, the quest progression unit 117 advances the quest and starts a battle part. In step S102, the cost determination unit 118 determines whether or not the deck used in the quest is a violation deck. Here, the quest progression unit 117 may instead read from the storage unit 120 the result of the determination already performed by the cost determination unit 118.

  In the case of YES in step S102, in step S103, the quest progression unit 117 imposes a penalty based on the cost excess on the user. As an example, the penalty has an effect on the ally character or enemy character in which the progress of the play part is disadvantageous to the user.

  In step S <b> 104, the quest progression unit 117 displays on the display unit 152 a notification for allowing the user to recognize at least one of being penalized based on excess and penalized. That is, the quest progression unit 117 may impose a penalty in step S103 after notifying that a penalty is imposed in step S104.

  Thereby, the battle part in each subsequent step proceeds under the influence of an adverse action for the user based on the penalty being implemented.

  In step S105, the quest progression unit 117 advances the first strike turn by the enemy object. If the enemy object does not have the ability of first strike, this step may be omitted.

  If YES in step S106, that is, if the physical strength of all the characters incorporated in the deck becomes zero due to the attacking action of the enemy object, the quest progression unit 117 transitions to step S107.

  In step S107, the quest progression unit 117 determines that the party based on the user's deck has been defeated, and ends the battle part. Then, the quest progression unit 117 ends the play part (quest) itself. The quest progression unit 117 may accept a continuation instruction for a quest that allows continuation. When the continue instruction is input, after step S107, the quest progression unit 117 cancels the battle disabled state of the teammate character and returns to step S106.

  If NO in step S106, the quest progression unit 117 transitions to step S108. In step S108, the quest progression unit 117 performs a quiz element. As an example, the quest progression unit 117 presents a quiz genre associated with an attribute, accepts a genre selection from the user, presents a quiz of the selected genre, and accepts an answer. In this step, the quest progression unit 117 may set which enemy character will attack which enemy character or activate the skill of the teammate character according to the user's operation.

  In step S <b> 109, the quest progression unit 117 advances the attack turn of the teammate object according to the execution result of the quiz element.

  If NO in step S110, the quest progression unit 117 transitions to step S111. In step S111, the quest progression unit 117 advances the attack turn of the enemy character. Thereafter, similarly, Steps S106 to S110 are repeated.

  If YES in step S110, the quest progression unit 117 transitions to step S112. In step S112, the quest progression unit 117 determines that the party has won and ends the battle part.

  If NO in step S113, that is, if an unexecuted battle part remains in the quest, the quest progression unit 117 returns to step S101 and repeats the subsequent processing. If YES in step S113, the quest progression unit 117 ends the quest. Note that steps S102 to S104 may be executed at any timing from steps S101 to S113.

(Penalty variation)
In step S <b> 103, the quest progression unit 117 contributes to adversely affecting a teammate character incorporated in the user's deck and having a good play result for the user, and to provide a play result that the user does not want. In other words, at least one of acting on the enemy character that is hostile to the ally character may be implemented as a penalty.

  That is, the penalty based on the cost excess includes content that acts negatively on a friend character and / or positively acts on an enemy character in the battle part.

  For example, the quest progression unit 117 at least reduces the battle ability parameter (parameter) that defines the performance of the teammate character during the battle, and increases the battle ability parameter that defines the performance of the enemy character during the battle. Either one may be implemented as a penalty.

  For example, the disadvantageous action for the above-mentioned teammate character includes that the teammate object falls into an abnormal state in which the performance of the teammate object is not exhibited as prescribed. The quest progression unit 117 causes the teammate character to fall into the abnormal state described above, and the time required for the battle part to proceed until the abnormal state is canceled when the teammate character falls into the abnormal state. May be implemented as a penalty. The cancellation of the abnormal state includes, for example, that the teammate character returns to a normal state where the performance of the teammate character is exhibited as prescribed.

  Abnormal conditions that the ally character falls into include, for example, poison (physical strength is automatically cut at each turn), paralysis or sleep (cannot take action during an ally character's attack turn), attack / defense reduction, and skill Sealing (skills cannot be activated even if the activation conditions are satisfied).

  In the present embodiment, as an example, as described above, the play part includes one or more battle parts. A battle part advances by making one or more friendly characters and one or more enemy characters fight. For example, the quest progression unit 117 may assist the enemy character as a penalty while the battle part is in progress.

  As assisting the enemy character, for example, recovering the physical strength of the enemy character, increasing the attack power of the enemy character, increasing the defense power of the enemy character, adding an enemy character, etc. This is advantageous for the enemy character.

(Notification variations)
In step S104, it is preferable that the quest progression unit 117 displays a notice regarding the penalty based on the cost excess in a display manner in accordance with the game context.

  When a penalty that is implemented due to a non-play part violation action (excess cost) is performed while the play part is in progress, the possibility that the user will feel uncomfortable is reduced if the causal relationship is clear be able to. Here, when a notice regarding a penalty based on an excess of cost is given, for example, “Penalty has been implemented due to an excess of cost”, the causal relationship of the implementation of the penalty becomes clear to the user.

  The notification regarding the penalty is preferably performed in a display manner in accordance with the context of the game, rather than being mechanical and tasteless. Thereby, it is possible to allow the user to recognize that a penalty based on an excess of cost has been implemented while avoiding a loss of immersion in the game. Furthermore, when the above-described notification is performed in a display mode that matches the context of the game, it is possible to further improve the sense of immersion in the game during the progress of the main play part of the game. .

  Note that the penalty notification is generated by text, symbols, icons, still images, animations, and various UI components that combine these. Regardless of which UI component is used, it is preferable that an effect matching the world view of the game is provided. For example, in an RPG including a battle part, when the notification is realized by text, a phrase such as “a curse with excessive cost hits the party!” May be adopted as the above-described notification.

  For example, in an RPG including a battle part, when notification is realized by animation, an adverse effect on a teammate object based on a penalty in the notification is expressed by an attack of an enemy object. An animation expressing a situation in which an enemy character's attack has an adverse effect on a teammate character may be employed as the above-described notification.

  Alternatively, in step S <b> 104, the quest progression unit 117 may display information on the display unit 152 that explains that the penalty that is recognized by the user by the above notification is based on an excess of cost. As a result, the user can clearly recognize that a penalty has been imposed due to the excess cost of the deck. Moreover, the user who actually experienced the disadvantageous situation due to the penalty recognizes again that this penalty is based on the excess of cost. For this reason, motivation for the game is nurtured, such as wanting to raise the level and raising the cost upper limit value, or strategizing and creating an effective deck within the cost upper limit value.

(Notification timing)
As shown in FIG. 8, the quest progression unit 117 executes step S104 for displaying a notification subsequent to step S103 for imposing a penalty, or executes step S103 for imposing a penalty following step S104 for displaying a notification. Is preferred. Thereby, it is possible to make the user aware of the cost violation and its disadvantages. As a result, the user's willingness to eliminate the cost violation can be nurtured, and the motivation for the user's play can be enhanced.

  Or the quest progress part 117 may perform step S104 which displays a notification immediately after step S101 which performs a play part is started. As a result, it is possible to notify the user in an easy-to-understand manner that the entire play part is affected by the penalty.

  Or the quest progress part 117 may perform step S104 which displays a notification just before the first turn in which an ally character can act is started. Thereby, it is possible to notify the user in an easy-to-understand manner that there is a penalty effect particularly in the action turn of the teammate character.

(Concrete example)
In this embodiment, as an example, the penalty based on the excess of cost is “to reduce the battle ability parameter of a character by 25% uniformly”. Based on this specific example, the functional configuration of the user terminal 100 will be described in more detail.

  The quest progression unit 117 executes a penalty based on the excess cost of the deck in step S103. Specifically, the quest progression unit 117 uniformly reduces the original combat ability parameter of the character by 25% for all the characters organized in the deck. The quest progression unit 117 advances the battle part represented by each step after step S105 based on the reduced battle ability parameter.

  FIG. 9 is a diagram showing a specific example of the battle ability parameter of each character organized in the deck after the penalty has been implemented. In the present embodiment, among the combat ability parameters, for example, (1) physical strength, (2) attack power, and (3) a numerical value representing the degree of skill effect, There are three.

  In the present embodiment, the quest progression unit 117 performs a penalty by reducing all the above three numerical values by 25% for all five characters. The battle ability parameters shown in FIG. 9 indicate the fight ability parameters after the penalty of the five characters arranged in the frames F1 to F5 of the deck 401. Compared to the original combat capability parameter before the penalty shown in FIG. 5, all the above three numerical values are reduced by 25%. The quest progression unit 117 advances the battle part based on the battle ability parameter shown in FIG.

  In another embodiment, the numerical value subject to 25% reduction as a penalty may be at least one of the above (1) to (3), not all. For example, the quest progression unit 117 may reduce only (1) physical strength and (2) attack power of each character by 25%. In still another embodiment, not all of the characters subject to the penalty may be a part of the characters arranged on the deck.

  In another embodiment, an object whose value is decreased as a penalty for a predetermined amount of action (for example, the amount of damage given to an enemy character) in a play part, which is calculated based on an original battle ability parameter (for example, attack power). It is good.

  FIG. 10 is a diagram illustrating an example of a game screen displayed on the display unit 152 when the play part is being executed. The game screen shown in FIG. 10 is a battle screen 500 as an example. The battle screen 500 includes various UI parts for the user to play a battle part. For example, the battle screen 500 includes an enemy character area 501, a teammate character area 502, and a quiz area 503. The enemy character area 501 is an area for displaying information on the enemy character. The teammate character area 502 is an area that displays information about the teammate character and accepts a user operation for designating the behavior of the teammate character. The quiz area 503 is an area for implementing a quiz element.

  In the present embodiment, the quest progression unit 117 displays the battle screen 500 on the display unit 152 in step S101 of FIG. In the present embodiment, the quest progression unit 117 may further display a first notification 504 indicating the state of the deck on the battle screen 500 in step S104. The first notification 504 includes information explaining that the penalized penalty or penalized is based on cost overruns, or information explaining that there is a cost violation on the deck. The step S104 for displaying the first notification 504 may be performed after the step S102 and before the step S103. Since the first notification 504 is a notification related to the deck, the first notification 504 is superimposed on the teammate character area 502 for displaying the deck, but the quest progression unit 117 displays the first notification 504 at an arbitrary position on the battle screen 500. Can be superimposed and displayed.

  From the first notification 504, the user can recognize that the cost 401 has been exceeded in the deck 401 he / she has organized, and if the penalty is implemented, the penalty is due to the cost excess. I can understand that.

  FIG. 11 is a diagram illustrating an example of a game screen displayed on the display unit 152 when the play part is being executed. As an example, the game screen shown in FIG. 11 is a battle screen 500 including a second notification 505 displayed after the first notification 504 is displayed in the battle screen 500 shown in FIG.

  In the present embodiment, the quest progression unit 117 superimposes a second notification 505 on the battle screen 500 for allowing the user to recognize that a penalty based on cost excess has been implemented or has been implemented in step S104 of FIG. indicate. The second notification 505 may be realized by an animation representing a state where the fighting ability parameter of the teammate character is reduced. Since the second notification 505 is a notification related to the teammate character, it is superimposed on the teammate character area 502, but the quest progression unit 117 displays the second notification 505 superimposed on an arbitrary position on the battle screen 500. Can do. For example, when the second notification 505 is a notification related to an enemy character, the second notification 505 may be superimposed on the enemy character area 501.

  The second notification 505 allows the user to recognize that a penalty based on cost excess has been implemented.

(effect)
According to the above-described configuration and method, the deck in which the cost violation occurs without prohibiting the organization of the deck in which the cost violation has occurred or prohibiting the play on the deck in which the cost violation has occurred. Play using is allowed.

  Thereby, an opportunity to play a game can be given to a beginner whose cost upper limit value is set low using a high-cost character, that is, a strong character. As a result, even if a strong character or item is acquired, the upper limit of the deck cost becomes a bottleneck and it cannot be used in play, especially for beginners, solving the problem that the interest of the game is significantly impaired it can.

  On the other hand, a penalty is imposed on the user who uses the cost violating deck so that the progress of the game is disadvantageous for the user. As a result, the value and enjoyment of performing the knitting within the upper cost limit so as not to be penalized are not impaired. In addition, it is possible to prevent unfairness from occurring with a user playing a game while organizing a deck in consideration of no cost violation.

  The arrangement and method described above also provide benefits for advanced users. Specifically, the strategy is diversified, such as adopting a deck that is within the upper limit of cost, or incorporating the desired character into the deck even if it suffers a disadvantage of excess cost, and further enhances the fun of the game To do.

  According to the above-described configuration and method, the following problems that the prior art holds can be solved. The cause of the cost violation lies in the organization of the party selected by the user in the play preparation part. According to Patent Document 1, the penalty reduces the ability value of the character on the spot, that is, in the play preparation part. Implemented in the form. However, it is the play part that actually has a penalty effect as a result of the cost violation. Thus, the causal relationship between the organization by the user in the play preparation part and the game progress status in the play part is difficult to understand, and the user is less aware of the cost violation and its disadvantages. Therefore, if the penalty is implemented in the play preparation part, the willingness to eliminate the cost violation cannot be nurtured.

  Also, if the cost violation becomes normal and the state where the penalty has been implemented continues on the deck organization screen and the character continues to be displayed with the ability value lowered, the user gets used to that state. Therefore, the original charm of the character is impaired. As a result, the interest of the game is also reduced.

  On the other hand, according to the above-described configuration and method, after a play part is started, a penalty is imposed while the play part is in progress, and a penalty based on an excess of cost is or is recognized. A notification for playing is displayed while the play part is in progress. Thereby, it is possible to make the user aware of the cost violation and its disadvantages.

  By displaying the penalty notification while the play part is in progress, there is no need to display the result after the penalty (decreased character ability value) on the deck organization screen. Therefore, since the original ability value of the character can be displayed on the deck organization screen, it is possible to avoid the loss of the attractiveness of the character due to the cost violation. As a result, motivation to eliminate the cost violation is nurtured, and motivation for play can be strengthened.

[Embodiment 2]
The penalty may be implemented by cooperation between the server 200 and the user terminal 100. FIG. 12 is a flowchart showing the flow of processing when the server 200 and the user terminal 100 implement the penalty of step S103 shown in FIG.

  In step S <b> 201, the quest progression unit 117 of the user terminal 100 transmits the deck information 121 together with the user ID to the server 200 for the deck displayed in the teammate character area 502 of the battle screen 500. The deck information 121 is information indicating the correspondence between the deck frame number and the card ID, as shown in FIG.

  The storage unit 220 of the server 200 stores the card DB 122 shown in FIG. 5 for each user. In step S <b> 202, the quest support unit 211 of the server 200 acquires, from the card DB 122, the battle ability parameter of each character placed on the user's deck based on the card ID included in the deck information 121 received from the user terminal 100. To do. The battle ability parameter acquired here indicates a normal value before the penalty is implemented.

  The storage unit 220 stores a reduction rate as part of the game program 131. The rate of decrease is information that defines the amount by which the combat ability parameter is decreased as a penalty, and is represented as “25% down”, for example. In addition to the example described above, a plurality of types of reduction rates such as “20% down” and “50% down” may be stored.

  In step S <b> 203, the quest support unit 211 acquires from the storage unit 220 a reduction rate applied when the cost exceeds, for example, “25% down”. In step S <b> 204, the quest support unit 211 replies to the user terminal 100 with the normal battle ability parameter and the reduction rate of each character.

  In step S <b> 205, the quest progression unit 117 reduces the supplied battle ability parameter based on the decrease rate designated by the server 200.

  According to the above-described method, the user terminal 100 can perform a penalty for the battle ability parameter without storing the user's card DB 122 locally in the storage unit 120. Since the card DB 122 has an enormous amount of information as the number of cards held by the user increases, there is a merit that the capacity of the memory 11 of the user terminal 100 can be avoided.

  On the other hand, the server 200 is configured to simply transmit the normal information of the character placed on the deck and a predetermined reduction rate to the user terminal 100. The server 200 does not need to determine whether or not the user's deck is over-cost, and when it is over-cost, the server 200 does not need to execute a process for reducing the battle ability parameter. There is an advantage that the processing load of the server 200 can be reduced in the server 200 in which requests are expected to be flooded from a large number of user terminals 100.

  Furthermore, according to the configuration of the server 200 in which a plurality of types of reduction rates are prepared, it is possible to vary the weight of the penalty according to the situation, and the fun of the game can be further improved. The situation is assumed to be, for example, the level of the user, the amount that the total deck cost exceeds the cost upper limit, the difficulty level of the quest selected by the user, and the like. As disclosed in Patent Document 1, in the configuration in which the penalty is implemented in the deck organization part, the weight of the penalty cannot be changed depending on the situation. As described in the first embodiment, since the user terminal 100 has a configuration in which the penalty is implemented by the play part, it is possible to vary the weight of the penalty according to the situation.

[Embodiment 3]
In the third embodiment, the game system 1 may vary the behavior in the play preparation part depending on whether or not the cost is exceeded.

(Processing flow of play preparation part)
FIG. 13 is a flowchart showing the flow of processing when the user terminal 100 executes the play preparation part in step S1 shown in FIG.

  In step S301, the deck organization unit 115 displays a deck organization screen. For example, the deck organization screen 400 shown in FIG. In step S <b> 302, the operation reception unit 111 receives user input operations for various UI components included in the deck organization screen 400.

  In step S303, the deck organization unit 115 generates the deck 401 according to the input operation described above. Specifically, for example, deck information 121 as shown in FIG. 6 corresponding to the deck 401 organized by the input operation is generated.

  In step S <b> 304, the cost determination unit 118 determines whether the total deck cost 405 of the generated deck 401 exceeds the user cost upper limit 404. The deck knitting unit 115 changes the steps (S306 to S308) for displaying the knitted deck 401 as follows depending on whether the cost is exceeded.

  If YES in step S305, that is, if a cost excess has occurred, the deck organization unit 115 transitions to steps S306 and S307. In step S <b> 306, the deck organization unit 115 causes the UI control unit 113 to generate a warning that a cost excess has occurred in the deck 401. In step S <b> 307, the deck organization unit 115 causes the UI control unit 113 to generate a notice that a penalty based on cost excess will be implemented in the play part. The deck organization unit 115 may read a warning or notice UI component generated in advance from the storage unit 120. The warning and the advance notice may be collectively stored as one UI component in the storage unit 120. The warning and the advance notice are stored in the storage unit 120 as text, symbols, icons, still images, animations, and various UI parts combining these.

  In step S <b> 308, the deck organization unit 115 displays the generated deck 401 on the deck organization screen 400, and displays at least one of the generated warning and notice on the deck organization screen 400. The warning or advance notice may be displayed in a pop-up manner superimposed on the deck 401, or may be displayed in a different area from the deck 401. Here, when displaying the knitted deck 401 after the knitting, the deck knitting unit 115 displays the parameters of the characters arranged in the frames F1 to F5 with their original values and results of the penalty (specifically) In particular, the reduced parameter value) is not displayed.

  In the case of NO in step S305, that is, if the cost has not exceeded, the deck organization unit 115 omits steps S306 and S307 and transitions to step S308. In step S <b> 308, the deck knitting unit 115 displays the knitted deck 401 on the deck knitting screen 400.

  If YES in step S309, that is, if the operation reception unit 111 receives an input operation for completing the formation of the deck 401, the deck formation unit 115 transitions to step S310. In step S <b> 310, the deck organization unit 115 stores the deck information 121 corresponding to the current deck 401 in the storage unit 120. The input operation described above is, for example, a touch operation on the enter button 406 on the deck organization screen 400.

  In the case of NO in step S309, the deck knitting unit 115 returns to step S301 and repeats the processing of each subsequent step.

(Screen example)
FIG. 14 is a diagram illustrating an example of a game screen displayed on the display unit 152 when the play preparation part is being executed. The game screen shown in FIG. 14 is the second deck organization screen 410, and is a screen that has transitioned from the deck organization screen 400 shown in FIG. 4 when a cost excess has occurred in the deck 401. For example, the deck organization screen 410 includes at least one of a warning that a cost excess has occurred in the deck 401 and a notice that a penalty based on the cost excess will be implemented in the play part.

  As shown in FIG. 14, for example, the deck organization unit 115 generates the above warning as the warning text 412 and generates the above notice as the notice text 413. The deck organization unit 115 can display the deck organization screen 410 on the display unit 152 by popping up the window 411 including these UI parts on the deck organization screen 400.

  It should be noted that the window 411 may be displayed each time when a card of a character with a high cost is placed in one of the frames of the deck 401 and transitions from a state where there is no cost excess to a certain state. Alternatively, the window 411 may be displayed at a timing when the enter button 406 is touched in a state where the cost of the deck 401 exceeds the cost.

  As a result, the user can understand the disadvantages of excess cost, and can then consider whether to adopt the excess cost deck 401 or reorganize the deck 401 so as not to exceed the cost. Moreover, even if a penalty is implemented in the play part, it can be understood and understood that it is a penalty based on cost excess.

[Embodiment 4]
In the fourth embodiment, the game system 1 may also change the behavior in the transition preparation part depending on whether there is an excess of cost.

(Processing flow of migration preparation part)
FIG. 15 is a flowchart showing the flow of processing when the user terminal 100 executes the migration preparation part in step S3 shown in FIG. The transition preparation part is a part that prepares to transition from a part other than the play part to the play part. As an example, the transition preparation part includes a first subpart for selecting a quest and a second subpart for selecting an assistant. More specifically, the transition preparation part includes a step in which the user displays a UI component on the display unit 152 for instructing the user terminal 100 to start executing the play part. For example, steps S403, S407, and S411 to S413, which will be described later, correspond to the steps for displaying UI parts.

  In step S401, the migration preparation unit 116 displays a quest selection screen for selecting a quest on the display unit 152. In step S402, the operation reception unit 111 receives an input operation for designating a quest from the user.

  In step S <b> 403, the migration preparation unit 116 acquires detailed information of the quest designated by the user from the server 200 and displays a quest detail screen for displaying the detailed information on the display unit 152. On the quest detail screen, an input operation for designating a deck to be adopted for the quest may be accepted.

  In step S <b> 404, the transition preparation unit 116 displays an assistant selection screen for selecting an assistant on the display unit 152. Helper information as an option is provided from the sharing support unit 212 of the server 200. The assistant selection screen may be included in advance in the quest detail screen, or may be called from a UI component arranged on the quest detail screen.

  In step S405, the operation reception unit 111 receives an input operation for designating an assistant from the user.

  In step S <b> 406, the migration preparation unit 116 acquires information on the designated assistant from the server 200. Specifically, the deck information 121 of the specified other user is acquired, and various parameters of the character placed on the deck by the other user are acquired.

  In step S407, the transition preparation unit 116 displays a play start button for starting a quest on the display unit 152. The play start button may already be displayed in the quest detail screen in step S403. In step S408, the operation reception unit 111 receives an input operation for the play start button.

  In step S409, the cost determination unit 118 determines whether there is a cost excess for the deck set when the play start button is pressed. This step may be executed in step S403.

  In the case of YES in step S410, the transition preparation unit 116 executes steps S411 to S413 in an arbitrary order as the play start button is pressed. Depending on the case, either step S411 or S412 may be omitted. In step S <b> 411, the migration preparation unit 116 displays a warning that the total deck cost 405 exceeds the cost upper limit 404 on the display unit 152. In step S <b> 412, the transition preparation unit 116 displays on the display unit 152 a notice that a penalty will be implemented in the quest (play part) based on the cost excess. In step S413, the transition preparation unit 116 displays UI parts on the display unit 152 for the user to select whether to maintain or cancel the play start instruction. Specifically, the transition preparation unit 116 displays a play start button for the user to maintain a play start instruction and a stop button for canceling the play start instruction on the display unit 152.

  In the case of YES in step S414, when the play start button is pressed again, the transition preparation unit 116 transitions to step S415. In step S415, the transition preparation unit 116 instructs the quest progression unit 117 to start the play part, and ends the transition preparation part.

  If NO in step S414, when the cancel button is pressed, the transition preparation unit 116 hides the above-described warning, notice, and various buttons, returns to step S403, and repeats the subsequent steps.

(Screen example)
FIG. 16 is a diagram illustrating an example of a game screen displayed on the display unit 152 when the migration preparation part is being executed. The game screen shown in FIG. 16 is a quest detail screen 600. In the example shown in FIG. 16, as an example, the assistant selection screen 604 is included in a part of the quest detail screen 600. In addition, for example, the quest detail screen 600 includes quest information 601, a deck 602, a warning 603, and a play start button 605. The quest information 601 is a UI component that indicates detailed information about the quest. The deck 602 is a UI component indicating information on a deck that is currently employed. A warning 603 is a UI component that warns the user that the cost has been exceeded. The play start button 605 is a UI component for the user to instruct the start of a quest.

  From the quest information 601, the user can confirm whether there is no mistake in the quest he or she wants to challenge. The deck 602 allows the user to check the contents of the deck adopted in the quest that is about to be challenged. The warning 603 allows the user to recognize before the challenge if an excess cost has occurred in the adopted deck. The assistant selection screen 604 allows the user to select a desired assistant to participate in the quest.

  When the user prepares to challenge the quest by operating the various UI parts described above, the user can press the play start button 605 to instruct the start of the quest. When the play start button 605 is pressed, if the cost determination unit 118 determines that there is no cost excess in the deck, the quest progression unit 117 starts the progression of the quest. On the other hand, when there is a cost excess in the deck, the transition preparation unit 116 displays the game screen shown in FIG.

  FIG. 17 is a diagram illustrating an example of a game screen displayed on the display unit 152 when the migration preparation part is being executed. The game screen shown in FIG. 17 is the second quest detail screen 610. When the play start button 605 is pressed on the quest detail screen 600 shown in FIG. This is a screen that has been transitioned from the detail screen 600. For example, the quest detail screen 610 includes at least one of a warning that the deck 602 has an excess cost and a notice that a penalty based on the cost excess will be implemented in the play part.

  As illustrated in FIG. 17, as an example, the migration preparation unit 116 generates the above warning as the warning text 612 and generates the above warning as the warning text 613. In addition, the play start button 605 is disposed again as a UI part for maintaining the quest start instruction, and the cancel button 614 is disposed as a UI part for selecting cancellation of the quest. Then, the migration preparation unit 116 can display the quest detail screen 610 on the display unit 152 by overlaying the window 611 including these UI components on the quest detail screen 600 and displaying the popup.

  Thereby, when there is an excess of cost in the adopted deck 602, the user can notice that immediately before shifting to the quest. Therefore, it is possible to avoid a situation in which a quest is progressed by using a deck that has inadvertently exceeded the cost, and a penalty is unintentionally received, thereby improving user convenience.

[Modification]
In step S103, the quest progression unit 117 may change the penalty weight according to the amount by which the total deck cost exceeds the cost upper limit value. Specifically, the character status may be lowered as the excess amount increases.

  As a result, the user can be conscious of trying to reduce the cost as much as possible even when the excess is exceeded, and the value of carefully knitting the deck can be provided to the user. Also, there is no injustice between users who are trying to organize their decks with strong characters without worrying about the excess of costs at all, and those who are trying to keep costs as low as possible through strategy. Can be.

  Execution of a play part based on a deck in which the total deck cost 405 exceeds the cost upper limit 404 may be permitted only when a predetermined condition is satisfied. That is, even if an instruction to start a quest is input from the user, if the deck is in a cost-exceeded state and a predetermined condition is not satisfied, the transition preparation unit 116 sends a quest progression unit 117 to the quest progression unit 117. On the other hand, the progress of the quest is prohibited. Alternatively, the quest progression unit 117 invalidates the instruction and does not start the quest.

  In the present embodiment, as an example, the user is given a level according to the number of times the game is played, and the cost upper limit 404 set for each user increases as the level increases. is there. In this case, the execution of the play part based on the deck that exceeds the cost may be permitted only to users having a predetermined level or less. For example, even if an instruction to start a quest is input from the user, if the deck is in a cost-exceeded state and the user exceeds a predetermined level, the transition preparation unit 116 instructs the quest progression unit 117 to The progress of the quest is prohibited.

  In this embodiment, as an example, the play part is composed of a plurality of types of quests for each difficulty level of play. In this case, the execution of the play part based on the deck that exceeds the cost may be permitted only to quests having a predetermined difficulty level or less. For example, even if an instruction to start a quest is input from the user, if the deck is in an excessive cost state and the difficulty level of the instructed quest exceeds a predetermined difficulty level, the transition preparation unit 116 The quest progression unit 117 is prohibited from proceeding with the quest.

  The main purpose of the remedy to allow play with over-deck decks is to prevent beginners from becoming clogged at the beginning of the game or feeling unhappy with the game.

  As a side effect of this remedy, advanced users who have been playing the game for a long time feel that this remedy is unnecessary, they feel that they are denied the way they enjoy the game, There is concern about losing willingness to play games. This is because advanced users have found the pleasure and value of completing an effective deck through trial and error over a long playing experience.

  Therefore, the above-described remedy is applied only to a user who has a low game experience and has a low cost upper limit set, or to a quest with a low difficulty level that a novice user is likely to challenge. Thereby, there are few side effects and there exists an effect that the above-mentioned purpose can be achieved effectively.

  The game according to the present embodiment may be a multiplayer game in which a deck owned by each of a plurality of users is shared by a plurality of users, and a plurality of decks are used for playing one play part. In this case, the transition preparation unit 116 displays a screen for selecting an assistant (a deck of another user) on the display unit 152 in step S404.

  Here, it is preferable that the transition preparation unit 116 displays information indicating whether or not the total deck cost of decks organized by other users exceeds the cost upper limit value.

  Accordingly, the user can select a desired assistant's deck while avoiding the deck where the cost is exceeded. As information indicating whether or not the deck causes an excessive cost, for example, an icon indicating an excessive cost may be displayed in association with the assistant's icon.

  In the quest detail screen 600 illustrated in FIG. 16, the migration preparation unit 116 displays an assistant selection screen 604. The transition preparation unit 116 displays on the assistant selection screen 604 a selectable icon of a character placed on another user's deck. Here, it is assumed that among the displayed assistant characters, there are some characters scheduled to be penalized for parameter reduction due to deck violations. In this case, it is preferable that the transition preparation unit 116 further assigns an icon indicating that the character is a penalty target to the icon of the character that is the target of the parameter reduction penalty among the assistant characters. . As an example, the icon may be a down arrow icon 606 reminiscent of a parameter being down due to a penalty.

  In another embodiment, the quest progression unit 117 is also subject to a parameter reduction penalty if the user's own deck is over cost, regardless of whether the other user's deck is over cost. It may be configured to.

  In another embodiment, the rescue procedure according to this embodiment can be applied to a battle game in which the main play part is a sporting game or the like. For example, in a battle game in which a user battles against a CPU, a configuration that permits a battle on a violation deck limited to a user at a certain level or below, or limited to a quest below a predetermined difficulty level, It can be suitably employed.

  For example, a configuration in which the weight of a penalty is changed in accordance with an excessive amount of cost can be suitably employed in an interpersonal battle game in which another user battles against an opponent. This configuration is particularly advantageous because it can maintain fairness among users.

[Example of software implementation]
Control blocks of the control unit 210 (particularly, the quest support unit 211 and the sharing support unit 212), and control blocks of the control unit 110 (particularly, the operation reception unit 111, the display control unit 112, the UI control unit 113, and the animation generation unit 114). The deck organization unit 115, the transition preparation unit 116, the quest progression unit 117, and the cost determination unit 118) may be realized by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like. It may be realized by software using a Central Processing Unit.

  In the latter case, an information processing apparatus provided with the control unit 210 and / or the control unit 110 includes a CPU that executes instructions of a program that is software for realizing each function, and the program and various data are computers (or CPUs). ROM (Read Only Memory) or storage device (referred to as “recording medium”) recorded in such a manner as to be readable, and a RAM (Random Access Memory) for expanding the program. And the objective of this invention is achieved when a computer (or CPU) reads the said program from the said recording medium and runs it. As the recording medium, a “non-temporary tangible medium” such as a tape, a disk, a card, a semiconductor memory, a programmable logic circuit, or the like can be used. The program may be supplied to the computer via an arbitrary transmission medium (such as a communication network or a broadcast wave) that can transmit the program. Note that one embodiment of the present invention can also be realized in the form of a data signal embedded in a carrier wave, in which the program is embodied by electronic transmission.

  The present invention is not limited to the above-described embodiments, and various modifications are possible within the scope shown in the claims, and embodiments obtained by appropriately combining technical means disclosed in different embodiments. Is also included in the technical scope of the present invention.

[Additional Notes]
The contents according to one aspect of the present invention are listed as follows.

  (Item 1) The game program (131) has been described. According to an aspect of the present disclosure, the game program is executed by a computer (user terminal 100) including a processor (10), a memory (11), an operation unit (such as the input unit 151) and a display unit (152). The game program is incorporated in the deck by accepting an input operation for incorporating one or more objects into the deck from the user and executing a play preparation part for storing the deck generated according to the input operation in the memory. A step of determining whether or not the total cost associated with each of the one or more objects exceeds a predetermined upper limit, and a play part in which a user plays a game based on the game program using a deck. The step of executing the play part includes a step in which a play part progress is disadvantageous for the user when it is determined that the sum exceeds the upper limit. A step to be imposed at a predetermined timing and a penalty will be imposed And at least one of the notification that the penalties imposed, and displaying on the display unit at a predetermined timing during the progress of the play part. Thereby, there exists an effect of improving the interest property of a game.

  (Item 2) In (Item 1), the step of imposing a penalty has an adverse effect on an ally object incorporated in the user's deck, and has an advantageous effect on an enemy object that is hostile to the ally object. At least one of these may be included.

  (Item 3) In (Item 2), the step of imposing a penalty includes at least one of lowering a parameter that defines the performance of an ally object and increasing a parameter that defines the performance of an enemy object. You may go out.

  (Item 4) In (Item 2) or (Item 3), the disadvantageous action includes that the ally object falls into an abnormal state in which the performance of the ally object is not exhibited as prescribed, and the step of imposing a penalty is At least to make an object fall into an abnormal state, and when a teammate object falls into an abnormal state, the time required for the play part to proceed until the abnormal state is canceled is longer than a specified value. Either one may be included.

  (Item 5) In any one item from (Item 2) to (Item 4), the play part progresses by making one or more ally objects and one or more enemy objects play against each other. The imposing step may include assisting the enemy object during the battle.

  (Item 6) In any one item from (Item 1) to (Item 5), in the step of displaying the notification, the notification may be displayed in a display mode according to the context of the game.

  (Item 7) In (Item 6), in the notification, an adverse effect on the friendly object incorporated in the user's deck based on the penalty may be expressed by an enemy object attacking the friendly object.

  (Item 8) In any one item from (Item 1) to (Item 7), the game program stores the deck stored in the step of executing the play preparation part in the processor and the step of executing the play part. Prior to executing the step of displaying on the display unit and displaying the deck, if it is determined that the total exceeds the upper limit value, the penalty result is not displayed but displayed. Based on the warning to the effect and the excess, at least one of the notice that the play part will be penalized may be displayed.

  (Item 9) In any one item from (Item 1) to (Item 8), in the step of executing the play part, the step of displaying the notification is executed following the step of imposing the penalty, or the notification is displayed. Subsequent to this step, a step of imposing a penalty may be performed.

  (Item 10) A method for executing a game program has been described. According to an aspect of the present disclosure, the game program is executed by a computer including a processor, a memory, an operation unit, and a display unit. The method includes the steps of: a processor receiving an input operation for incorporating one or more objects in a deck from a user; and executing a play preparation part for storing the deck generated according to the input operation in a memory; Determining whether the sum of the costs associated with each of the one or more objects incorporated in the computer exceeds a predetermined upper limit, and the processor uses the game based on the game program and the user uses the deck Executing the play part, and the step of executing the play part includes a penalty that causes the play part to be disadvantageous to the user when the total is determined to exceed the upper limit. Steps and penalties to be imposed at predetermined times during the part At least one of the notification of and the penalties imposed imposed, and displaying on the display unit at a predetermined timing during the progress of the play part. The method according to (Item 10) has the same effects as the game program according to (Item 1).

  (Item 11) The information processing apparatus has been described. According to an aspect of the present disclosure, the information processing device includes a storage unit (120) that stores a game program, and a control unit that controls the operation of the information processing device (user terminal 100) by executing the game program. 110), an operation unit, and a display unit. The control unit receives an input operation for incorporating one or more objects into the deck from the user, executes a play preparation part that saves the deck generated according to the input operation in the storage unit, and executes at least one of the one or more objects incorporated in the deck The control unit determines whether or not the total cost associated with each of the objects exceeds a predetermined upper limit, and executes a play part in which a user plays a game based on the game program using a deck. When executing the play part, if it is determined that the total exceeds the upper limit, the penalty that the play part progress is disadvantageous for the user is imposed at a predetermined timing during the play part progress, and the penalty is Notifications of at least one of being imposed and / or penalized will be given to the play part in progress It is displayed on the display unit in the timing. The information processing apparatus according to (Item 11) has the same effects as the game program according to (Item 1).

  (Item 12) In any one item from (Item 1) to (Item 9), the step of imposing a penalty may change the weight of the penalty according to the amount by which the total exceeds the upper limit. .

  (Item 13) In any one item from (Item 1) to (Item 9), the game program is played by the processor using a deck whose total is determined to exceed the upper limit. In addition, the step of giving the reward to the user may be executed by reducing the amount or reducing the value as compared with the case where the reward is not exceeded.

  (Item 14) In any one item from (Item 1) to (Item 9), in the step of displaying the notification, it is explained that the penalty to be recognized by the user by the notification is based on excess. The information may be displayed on the display unit.

  (Item 15) In any one item from (Item 1) to (Item 9), the game program is a user interface (hereinafter referred to as UI) component for instructing the processor to start executing the step of executing the play part. Is displayed on the display unit, and in the step of displaying the UI part, when the UI part is operated, if it is determined that the total exceeds the upper limit value, the process proceeds to the step of executing the play part. In addition, at least one of a warning and a notice may be displayed on the display unit, and a UI part for selecting whether to maintain or cancel the execution start instruction may be displayed.

  (Item 16) In any one item from (Item 1) to (Item 9), the step of displaying the notification may be executed immediately after the start of the step of executing the play part.

  (Item 17) In any one item from (Item 1) to (Item 9), the play part is incorporated in the deck, and one or more ally objects that provide a good play result for the user, and the user does not want. It progresses by making one or more enemy objects contributing to bring about a play result, and the battle includes a turn in which an ally object acts and a turn in which an enemy object acts, and displays a notification. The step may be executed immediately before the first turn of the ally object is started.

  (Item 18) In any one item from (Item 1) to (Item 9), the user is given a level according to the number of game plays, and the upper limit value set for each user is Execution of the step of executing a play part based on a deck that increases as the level increases and exceeds the total may be permitted only to users having a predetermined level or less.

  (Item 19) In any one item from (Item 1) to (Item 9), the play part is composed of a plurality of quests for each difficulty level of play, and is based on a deck whose total exceeds. Execution of the step of executing the play part may be permitted only for quests having a predetermined difficulty level or less.

  (Item 20) In any one item from (Item 1) to (Item 9), in the game, a deck owned by each of a plurality of users is shared by a plurality of users, and a plurality of games are played in one play part. The game program is a multi-play game in which a deck is used. The game program causes the processor to execute a step of displaying a screen for selecting another user's deck on the display unit. In the step of displaying the screen, the other user Information indicating whether or not the total of the organized decks exceeds the upper limit value may be displayed.

  (Item 21) In any one item from (Item 1) to (Item 9), the predetermined upper limit value is set for each user, and the memory has a predetermined upper limit value set for the user. Is stored, and the predetermined upper limit value is preferably increased when a predetermined condition is satisfied by the user playing the game.

1 game system, 2 network, 10,20 processor, 11,21 memory, 12,22 storage, 13,23 communication IF (operation unit), 14,24 input / output IF (operation unit), 15 touch screen (display unit, Operation unit), 17 camera (operation unit), 18 distance sensor (operation unit), 100 user terminal (information processing device), 110, 210 control unit, 111 operation reception unit, 112 display control unit, 113 UI control unit, 114 animation generation unit, 115 deck organization unit, 116 transition preparation unit, 117 quest progression unit, 118 cost determination unit, 120, 220 storage unit, 121 deck information, 122 card DB, 131 game program, 132 game information, 133 user information 151 Input unit 152 Display unit 200 Server 21 1 Quest Support Unit, 212 Sharing Support Unit, 1010 Object, 1020 Controller (Operation Unit), 1030 Storage Medium

Claims (10)

A game program,
The game program is executed by a computer including a processor, a memory, an operation unit, and a display unit,
The game program is stored in the processor.
Receiving an input operation for incorporating one or more objects into the deck from a user, and executing a play preparation part for storing the deck generated according to the input operation in the memory;
Determining whether the total cost associated with each of the one or more objects incorporated in the deck stored in the memory as an execution result of the play preparation part exceeds a predetermined upper limit value; When,
Executing a play part in which the user plays a game based on the game program using the deck, and
The predetermined upper limit value is a parameter that is set for each user and increases according to the level of the user, and the level of the user is given to the user in response to the user playing a quest of a play part. The accumulated value of the experience value to be increased by reaching a certain value, and the memory is configured to store the predetermined upper limit value set for the user,
The predetermined upper limit value increases when the user's level is increased by playing the game,
The game program is stored in the processor.
Prior to the step of executing the play part, the step of displaying the deck stored in the step of executing the play preparation part on the display unit is executed;
In the step of displaying the deck, as a timing to display the deck prior to the step of executing the play part, (i) when the deck is displayed in the play preparation part and the sum exceeds the upper limit value If it is determined, at least one of a warning that the penalty has been exceeded and a notice that the penalty will be implemented in the play part based on the excess is displayed in the play preparation part,
In the step of displaying the deck, as a timing for displaying the deck prior to the step of executing the play part, (ii) based on the quest by accepting an operation for selecting a quest to be played from the user. Displaying a game screen for accepting the start of execution of the play part from the user, displaying the deck stored in the memory together with information on the quest on the game screen, and determining that the sum exceeds the upper limit value When displayed, at least one of the warning and the advance notice is displayed on the game screen,
The step of executing the play part starts execution of the play part in accordance with an input operation of the user for instructing start of execution of the play part on the game screen, and determines that the total exceeds the upper limit value. After starting the play part,
A step of progress of the play part is disadvantageous to the user, the process to impose a penalty for excess of the total, is performed at predetermined timing during the progress of the play part,
Displaying at least one notification that the penalty is imposed and that the penalty has been imposed on the display unit at a predetermined timing during the progress of the play part,
The step of executing the play part includes:
The play part is matched with one or more ally objects incorporated in the deck that provide a good play result for the user and one or more enemy objects that contribute to providing a play result that the user does not want. Progress by
In the step of imposing the penalty, before the action of the ally object or the enemy object is started as the predetermined timing , the penalty is imposed,
A game program for displaying the notification on the display unit before the action of the teammate object or the enemy object is started at the predetermined timing in the step of displaying the notification. The step of performing the processing of imposing the penalty includes:
Adversely affecting a friendly object incorporated in the user's deck; and
The game program according to claim 1, comprising at least one of exerting an advantageous effect on an enemy object that is hostile to the ally object. The step of performing the processing of imposing the penalty includes:
Reducing parameters that define the performance of the friendly object; and
The game program according to claim 2, comprising at least one of increasing a parameter that defines the performance of the enemy object. The disadvantageous action includes that the ally object falls into an abnormal state where the performance of the ally object is not exhibited as prescribed,
The step of performing the processing of imposing the penalty includes:
Causing the ally object to fall into the abnormal state; and
3. When the ally object falls into the abnormal state, it includes at least one of making a required time in the play part progress until the abnormal state is canceled longer than a prescribed time. Or the game program of 3. The play part proceeds by causing one or more teammate objects and one or more enemy objects to battle each other.
The step of performing the processing of imposing the penalty includes:
The game program according to any one of claims 2 to 4, comprising assisting the enemy object during a battle.   The game program according to any one of claims 1 to 5, wherein, in the step of displaying the notification, the notification is displayed in a display mode according to a context of the game.   The game program according to claim 6, wherein in the notification, an adverse effect on a friend object incorporated in the deck of the user based on the penalty is expressed by an enemy object attacking the friend object. In the step of executing the play part,
Performing the step of displaying the notification following the step of performing the process of imposing the penalty, or
The game program according to any one of claims 1 to 7 , wherein a step of executing a process of imposing the penalty is executed following the step of displaying the notification. A method for executing a game program,
The game program is executed by a computer including a processor, a memory, an operation unit, and a display unit,
In the method, the processor comprises:
Receiving an input operation for incorporating one or more objects into the deck from a user, and executing a play preparation part for storing the deck generated according to the input operation in the memory;
Determining whether the total cost associated with each of the one or more objects incorporated in the deck stored in the memory as an execution result of the play preparation part exceeds a predetermined upper limit value; When,
Executing a play part in which the user plays a game based on the game program using the deck, and
The predetermined upper limit value is a parameter that is set for each user and increases according to the level of the user, and the memory is configured to store the predetermined upper limit value set for the user. And
The predetermined upper limit value is increased when the level of the user is increased by playing the game, and the level of the user is increased according to the user playing a quest of a play part. The accumulated experience value given to the user increases when it reaches a certain value,
In the method, the processor comprises:
Executing the step of displaying the deck stored in the step of executing the play preparation part on the display unit prior to the step of executing the play part;
In the step of displaying the deck, as a timing to display the deck prior to the step of executing the play part, (i) when the deck is displayed in the play preparation part and the sum exceeds the upper limit value If it is determined, at least one of a warning that the penalty has been exceeded and a notice that the penalty will be implemented in the play part based on the excess is displayed in the play preparation part,
In the step of displaying the deck, as a timing for displaying the deck prior to the step of executing the play part, (ii) based on the quest by accepting an operation for selecting a quest to be played from the user. Displaying a game screen for accepting the start of execution of the play part from the user, displaying the deck stored in the memory together with information on the quest on the game screen, and determining that the sum exceeds the upper limit value When displayed, at least one of the warning and the advance notice is displayed on the game screen,
The step of executing the play part starts execution of the play part in accordance with an input operation of the user for instructing start of execution of the play part on the game screen, and determines that the total exceeds the upper limit value. After starting the play part,
A step of progress of the play part is disadvantageous to the user, the process to impose a penalty for excess of the total, is performed at predetermined timing during the progress of the play part,
Displaying at least one notification that the penalty is imposed and that the penalty has been imposed on the display unit at a predetermined timing during the progress of the play part,
The step of executing the play part includes:
The play part is matched with one or more ally objects incorporated in the deck that provide a good play result for the user and one or more enemy objects that contribute to providing a play result that the user does not want. Progress by
Step of implementing a process of imposing the penalty, before the teammate object or behavior of the enemy object as the predetermined timing is started, imposes the penalty,
The method of displaying the notification on the display unit before the action of the friend object or the enemy object is started at the predetermined timing in the step of displaying the notification. An information processing apparatus,
The information processing apparatus includes:
A storage unit for storing game programs;
A control unit that controls the operation of the information processing apparatus by executing the game program;
An operation unit;
A display unit,
The controller is
Receiving an input operation for incorporating one or more objects into the deck from the user, and executing a play preparation part for storing the deck generated according to the input operation in the storage unit;
It is determined whether the total cost associated with each of the one or more objects incorporated in the deck stored in the storage unit as a result of execution of the play preparation part exceeds a predetermined upper limit value. ,
Executing a play part in which the user plays a game based on the game program using the deck;
The predetermined upper limit value is a parameter that is set for each user and increases according to the level of the user, and the memory is configured to store the predetermined upper limit value set for the user. And
The predetermined upper limit value is increased when the level of the user is increased by playing the game, and the level of the user is increased according to the user playing a quest of a play part. The accumulated experience value given to the user increases when it reaches a certain value,
The control unit is
Prior to executing the play part, displaying the deck stored in executing the play preparation part on the display unit;
In displaying the deck, as a timing for displaying the deck prior to executing the play part, (i) the deck is displayed in the play preparation part, and the total exceeds the upper limit value. If it is determined, at least one of a warning that the penalty has been exceeded and a notice that the penalty will be implemented in the play part based on the excess is displayed in the play preparation part,
Displaying the deck is based on the quest by accepting an operation to select a quest to be played from the user as a timing to display the deck prior to executing the play part. Displaying a game screen for accepting the start of execution of the play part from the user, displaying the deck stored in the memory together with information on the quest on the game screen, and determining that the sum exceeds the upper limit value When displayed, at least one of the warning and the advance notice is displayed on the game screen,
The control unit starts execution of the play part in accordance with the user's input operation for instructing start of execution of the play part on the game screen, and when it is determined that the total exceeds the upper limit value After starting the play part,
The progress of the play part is disadvantageous to the user, the process to impose a penalty for excess of the total, was performed at a predetermined timing during the progress of the play part,
Displaying at least one notification that the penalty is imposed and the penalty is imposed on the display unit at a predetermined timing during the progress of the play part;
The controller is
The play part is matched with one or more ally objects incorporated in the deck that provide a good play result for the user and one or more enemy objects that contribute to providing a play result that the user does not want. Progress by
Before the action of the ally object or the enemy object is started as the predetermined timing , the penalty is imposed,
An information processing apparatus that displays the notification on the display unit before the action of the teammate object or the enemy object is started at the predetermined timing .

Images