JP2019092655A - Game program, method, and information processing device - Google Patents

Abstract

To improve amusement properties of a game.SOLUTION: A game program causes a processor to execute a step S1 for executing a play preparation part for generating a deck according to an input operation received from a user, and storing the deck in a memory, a step S2 for determining whether or not a sum of costs of the deck exceeds a predetermined upper limit, and a step S4 for executing a play part for the user to play a game using the deck. The step for executing a play part includes a step for imposing a penalty by which the progress of the play part is disadvantageous to the user at a predetermined timing while the play part is in progress when the sum is determined to exceed the upper limit, and a step for displaying in a display part at least one of a notification that the penalty is to be imposed and a notification that the penalty has been imposed at a predetermined timing while the play part is in progress.SELECTED DRAWING: Figure 3

Description

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

  A game program for advancing a game using a deck made up of one or more objects is provided by various operators. A deck type game is provided for all genres, and this type of game is a play preparation part that prepares to play the main play part in addition to the play part that plays the main game. including. The play preparation part is, for example, a deck formation part for forming a deck.

  Generally, in the above-described type of game, the concept of “cost” is often adopted for the deck in order to enhance the interest of the game. The cost is a value consumed as compensation for incorporating an object into a deck, and is set for each object. The higher the in-game value the object has, the higher the cost. The user is set with an upper limit on the cost that can be consumed for organizing the deck, and the user can incorporate objects into the deck within the range of the upper limit set for him / her.

  In this way, only users who possess objects in abundance can suppress the advantageous progress of the game by blindly organizing objects with high contribution (for example, high ability and high strength) in the play part, thereby suppressing game balance. You can keep it.

  Also, by setting an upper limit on the cost of the deck, the user arranges the objects in hand within the upper limit to strategically organize an advantageous deck in the play part. Therefore, while the deck formation part is at the preparation stage of the main play part, the game nature of the deck formation part itself is also enhanced.

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

  However, the upper limit value of the cost set for the user is generally set low for the user (beginner) who has just started the game, and the user repeats the play to satisfy the condition. It will be enhanced by Therefore, it is difficult for beginners to incorporate expensive (i.e., high value and strong) objects into the deck, as the upper cost limit becomes a bottleneck. That is, even if a beginner gets an object of great value, he can not use it to play the play part. This causes, in particular, a problem that the willingness of the beginner to play the game is diminished, and a problem that the interest of the game is significantly impaired particularly for the beginner.

  One aspect 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 includes the steps of: receiving from the user an input operation for incorporating one or more objects into the deck; and executing a play preparation part for storing the deck generated in accordance with the input operation in the processor; Determining whether the total cost associated with each of the one or more objects exceeds a predetermined upper limit, and a play part in which the user plays the game based on the game program using the deck Performing the steps of performing and performing the play part is a penalty in which the progress of the play part is disadvantageous to the user when it is determined that the total exceeds the upper limit value; Imposing the step at a predetermined timing and the penalty being 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.

  A method according to the present disclosure is a method in which a computer including a processor, a memory, an operation unit, and a display executes a game program. The method includes the steps of: a processor receiving from the user an input operation for incorporating one or more objects into the deck; and executing a play preparation part in which the deck generated according to the input operation is stored in memory; Determining whether the sum of costs associated with each of the one or more objects incorporated in each exceeds a predetermined upper limit, the processor using the game based on the game program, the user using the deck Performing the play part to play, the step of performing the play part playing the penalty that the progress of the play part becomes disadvantageous to the user when it is determined that the total exceeds the upper limit value. Imposing steps and penalties at predetermined timings in progress of 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 an 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 from the user for incorporating one or more objects into the deck, executes a play preparation part for storing the deck generated according to the input operation in the storage unit, and performs one or more It is determined whether the total cost associated with each of the objects exceeds a predetermined upper limit value, and the control unit executes a play part in which the user plays the game based on the game program using the deck. When a play part is executed, if it is determined that the total exceeds the upper limit value, a penalty is imposed at a predetermined timing during the progress of the play part, such that the progress of the play part is disadvantageous to the user. Notice of imposition and / or of imposition of penalty shall be given to the playing part in progress It is displayed on the display unit in the timing.

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

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 | curd 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 terminal performs a play part. It is a figure which shows one specific 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 implement 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 flow chart which shows a flow of processing 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 transition preparation part is performed. It is a figure which shows an example of the game screen displayed on a display part, when the transition 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. The present invention is not limited to these exemplifications, but is shown by the claims, and all changes within the scope and meaning equivalent to the claims are intended to be included in the present invention. Ru. In the following description, the same components are denoted by the same reference symbols in the description of the drawings, and redundant description will not be repeated.

<Hardware Configuration of Game System 1>
FIG. 1 is a diagram showing 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 is composed of the Internet and various mobile communication systems constructed by wireless base stations (not shown). Examples of this mobile communication system include so-called 3G and 4G mobile communication systems, LTE (Long Term Evolution), and wireless networks (for example, Wi-Fi (registered trademark)) that can be connected to the Internet by a predetermined access point. Be

  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 configurations of the server 200 are electrically connected to each other by 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 And These configurations of the user terminal 100 are electrically connected to each other by 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. The controller 1020 establishes communication with the user terminal 100 according to a communication standard such as Bluetooth (registered trademark), for example. The controller 1020 may have one or more buttons and the like, and transmits an output value based on the user's input operation on the buttons and the like to the user terminal 100. In addition, the controller 1020 may have various sensors such as an acceleration sensor and an angular velocity sensor, and transmits the output values of the various sensors to the user terminal 100.

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

  The user terminal 100 desirably has a user using the controller 1020 input user identification information such as the user's name or login ID via the controller 1020, for example, at the start of the game. Thereby, the user terminal 100 can associate the controller 1020 with the user, and specifies which user the output value belongs to based on the transmission source (the controller 1020) of the received output value. be able to.

  When the user terminal 100 communicates with a plurality of controllers 1020, each user holds each controller 1020, thereby preventing communication with another device such as the server 200 via the network 2, the one user terminal 100. Can realize multiplayer. Also, multiplay is realized locally by a plurality of user terminals 100 by the respective user terminals 100 communicably connecting each other according to a wireless standard such as a wireless LAN (Local Area Network) standard (a communication connection is made without passing through the server 200). You can also When the above-described multiplayer is locally realized by one user terminal 100, the user terminal 100 may further include at least a part of various functions of the server 200 described later. Further, when the above-described multiplay 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.

  The user terminal 100 may communicate with the server 200 even if the above-described multiplay is realized locally. For example, the user identification information may be transmitted to the server 200 in association with information indicating a play result such as a score or an outcome in a certain game.

  In addition, the controller 1020 may be configured to be removable from the user terminal 100. In this case, a joint with the controller 1020 may be provided on at least one of the surfaces of the housing of the user terminal 100. When the user terminal 100 and the controller 1020 are connected by wire via the connection 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 receive attachment of a storage medium 1030 such as an external memory card via the input / output IF 14. Thereby, 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, for example, a game program.

  The user terminal 100 may store a game program acquired by communicating with an external device such as the server 200 in the memory 11 of the user terminal 100, or the game program acquired by reading from the storage medium 1030 may be stored 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. The above-described units as an input mechanism can be regarded as an operation unit configured to receive a user's 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 the object 1010 in the vicinity of the user terminal 100, and the input operation is performed from the detection result of the object Identify. As an example, the user's hand as the object 1010, a marker of a predetermined shape, etc. are detected, and the input operation is specified based on the color, shape, movement, type, etc. of the object 1010 obtained as a detection result. Ru. More specifically, when the user terminal 100 detects a user's hand from the captured image of the camera 17, the user's input operation is a gesture (a series of movements of the user's hand) detected based on the captured image. Identify and accept. The photographed image may be a still image or a moving image.

  Alternatively, when the operation unit is configured by the touch screen 15, the user terminal 100 identifies and accepts the user's operation performed on the input unit 151 of the touch screen 15 as the user's input operation. Alternatively, when the operation unit is configured by the communication IF 13, the user terminal 100 identifies and receives a signal (for example, an output value) transmitted from the controller 1020 as an input operation of the user. 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 the user's input operation.

<Game Outline>
The game system 1 which concerns on this embodiment is a system for executing 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 the deck, in addition to the play parts for playing the main game.

  For example, objects may be referred to as characters, cards, or items, etc. In particular, characters may be referred to as spirits, players, etc., depending on the context of the game. A deck may be called a party, team, order, etc., depending on the context of the game.

  The play part is the main part of the game played by the user aiming to clear or win, making full use of the objects incorporated into the deck. For example, in a game such as a role playing game (RPG), a battle part or the like that causes an ally object (character) incorporated in a deck to fight against an enemy object corresponds to this play part. In some cases, multiple combat parts may be combined into one quest as a play part.

  In sports-based competition games, the part that plays the game against an enemy object operated by a computer or another person corresponds to this play part by the ally object (player) incorporated in the deck. .

  The play preparation part is a part that is executed in preparation for playing the play part. The play preparation part is, for example, a deck formation part. The deck formation part is a part for the user to select an object to be included in the play part from among the objects in hand and perform an operation for forming the deck.

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

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

  Moreover, the game system 1 may be a system for performing the game of not only a specific play form but any play form. For example, a single play game by a single user, a multiplay game by a plurality of users, a battle game in which a plurality of users play a match among multiplay games, a cooperative play game in which a plurality of users cooperate, etc. May be

  In the present embodiment, as an example, the object is given to the user as digital content assumed to be a card. Here, the form of giving the object to the user is not particularly 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, the 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 the object owned by the user from the server 200. It is 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 information printed on the physical medium is read by the user terminal 100 so that the object can be used on the 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 against an enemy object. In the present embodiment, a quest including one or more battle parts is provided as a play part to the user terminal 100 of the user. The user uses the deck to play a quest, which is the main part of the game. In the present embodiment, an object is treated as a character as an example.

  In the present embodiment, as an example, in the battle part, the quiz element is performed to determine the attacking action of the teammate character based on the play result of the user in the quiz element, and the attacking action is performed on each teammate character. Also, in the battle part, according to the turn system, the attacking action of the enemy character is determined, and each enemy character is caused to perform the attacking action. The combat part is continued until the end conditions are met. The battle part is, for example, (1) that the party of the deck organized by the user wins by annihilating the enemy character attacked by the ally character, and (2) the ally character attacked by the enemy character is completely destroyed. By doing this, the party is defeated, or (3) the user performs an operation of retirement (termination), and the like, and the like are terminated as the termination condition.

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

  As an example, in addition to the two game parts described above, the RPG accepts various user's instructions, selections, etc. during the preparation period from the play preparation part to the play part, and relates to the play part. It may include a transition preparation part for setting. In addition, the RPG may include a reward granting part which gives the user a reward according to the play result after the play part is played by the user.

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

  When the game system 1 is a multiplayer RPG, a deck is organized in each of the first user terminal 100, the second user terminal 100, and the third user terminal 100 ... that communicate via the server 200. Ru. Then, deck information D 1, D 2,... Representing the contents of the organized decks are shared among the user terminals 100 via the server 200.

<Hardware components of each device>
The processor 10 controls the overall operation of the user terminal 100. The processor 20 controls the overall operation of the 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 the program in a memory 11 described later. The processor 20 reads a program from a storage 22 described later, and develops the program in a memory 21 described later. The processor 10 and the processor 20 execute the expanded program.

  The memories 11 and 21 are main storage devices. The memories 11 and 21 are configured by storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). The memory 11 provides the processor 10 with a work area by temporarily storing programs 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 a program. The memory 21 provides the processor 20 with a work area by temporarily storing various programs and data read from the storage 22 described later by the processor 20. The memory 21 also temporarily stores various data generated while the processor 20 is operating according to a 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 of 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. Further, various data includes data related to a game such as user information and game information, and an instruction or notification transmitted / received between the user terminal 100 and the server 200 or between a plurality of user terminals 100.

  The storages 12 and 22 are auxiliary storage devices. The storages 12 and 22 are configured by a storage device such as a flash memory or a hard disk drive (HDD). The storage 12 and the storage 22 store various data related to the game.

  The communication IF 13 controls transmission and reception of various data in the user terminal 100. The communication IF 23 controls transmission and reception of various data in the server 200. The communication IFs 13 and 23 control communication using, for example, wireless LAN (Local Area Network), wired LAN, wireless LAN, Internet communication via a mobile telephone network, short distance wireless communication, and the like.

  The input / output IF 14 is an interface for the user terminal 100 to receive input of data, 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, or a speaker. The input / output IF 24 of the server 200 is an interface for the server 200 to receive input of data, and is an interface for the server 200 to output data. The input / output IF 24 can 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 in which the input unit 151 and the display unit 152 are combined. The input unit 151 is, for example, a touch sensitive device, and is configured of, for example, a touch pad. The display unit 152 is configured of, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display.

  The input unit 151 detects the position at which the user's operation (physical touch operation such as touch operation, slide operation, swipe operation, and tap operation) on the input surface is input, and inputs information indicating the position. It has a function to transmit as a signal. 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 resistive 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 attitude of the user terminal 100 from the output of the sensor and perform processing according to the holding attitude. For example, when the user terminal 100 is held in the vertical orientation, the processor 10 may perform vertical screen display that causes the display unit 152 to display a vertically long image. On the other hand, when the user terminal 100 is held in landscape orientation, a landscape image may be displayed on the display unit to display a horizontally long image. Thus, the processor 10 may be capable of switching between vertical screen display and horizontal screen display according to the holding attitude of the user terminal 100.

  The camera 17 includes an image sensor and the like, and converts a light incident from the lens into an electric signal to generate a photographed image.

  The distance measurement 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 on the measurement object. The distance measuring sensor 18 may have a light source that emits light having directivity.

  Here, an example in which the user terminal 100 receives a detection result in which the object 1010 in the vicinity of the user terminal 100 is detected 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 measurement sensor 18 may be provided, for example, on the side of the housing of the user terminal 100. A distance measuring sensor 18 may be provided in the vicinity of the camera 17. For example, an infrared camera can be used as the camera 17. In this case, the camera 17 may be provided with a lighting device for emitting infrared light, a filter for blocking visible light, and the like. This makes it possible to further improve the detection accuracy of an object based on a photographed image of the camera 17 regardless of whether it is outdoors or indoors.

  The processor 10 may perform one or more of the processes shown in the following (1) to (5), for example, on the captured image of the camera 17. (1) The processor 10 performs image recognition processing on the captured image of the camera 17 to specify whether the captured image includes the user's hand. The processor 10 may use, for example, a technique such as pattern matching as an analysis technique employed in the above-described image recognition process. (2) Also, the processor 10 detects the user's gesture from the shape of the user's hand. The processor 10 specifies, for example, the number of fingers of the user (the number of extending fingers) from the shape of the user's hand detected from the captured image. The processor 10 further identifies a gesture made 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 made a gesture of “par”. Further, when the number of fingers is zero (the finger is not detected), the processor 10 determines that the user has made the gesture of “Go”. In addition, when the number of fingers is two, the processor 10 determines that the user has made a gesture of “Tokiki”. (3) The processor 10 performs image recognition processing on the captured image of the camera 17 to detect whether the user's finger is in a state where only the forefinger is standing or whether the user's finger makes a flicking motion. . (4) The processor 10 selects an object 1010 (a user's hand or the like in the vicinity of the user terminal 100 based on an image recognition result of a captured image of the camera 17 and / or an 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 the user terminal 100 (for example, a distance less than a predetermined value) or far (for example, the predetermined value) depending on the size of the user's hand specified from the captured image of the camera 17 It detects whether it is in the above distance). In addition, when the captured image is a moving image, the processor 10 may detect whether the user's hand is approaching or away from the user terminal 100. (5) If it is found that the distance between the user terminal 100 and the user's hand is changing while the user's hand is being detected based on the image recognition result of the captured image of the camera 17, etc., the processor 10 recognizes that the user shakes his hand in the shooting direction of the camera 17. If an object is detected or not detected by the distance measurement sensor 18 whose directivity is stronger than the shooting range of the camera 17, the processor 10 shakes the hand in the direction orthogonal to the shooting direction of the camera. recognize.

  As described above, the processor 10 determines whether the user holds the hand by image recognition on the captured image of the camera 17 (a gesture of “goo” or another gesture (eg, “par”)) To detect The processor 10 also detects how the user is moving this hand, as well as the shape of the user's hand. Also, the processor 10 detects whether the user is moving the hand closer to or away from the user terminal 100. Such an operation can correspond to, for example, an operation using a pointing device such as a mouse or a touch panel. For example, the user terminal 100 moves a pointer on the touch screen 15 in response 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. The continuation of the selection operation corresponds to, for example, the state in which the mouse is clicked and pressed down or the state in which the touch panel is touched after the touch-down operation is performed on the touch panel. In addition, when the user moves the hand further while the user terminal 100 detects the user's gesture "goo", such a series of gestures is 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 causes the user to repel a finger based on the detection result of the user's hand based on the captured image of the camera 17, the user clicks the gesture by tapping the mouse or tapping the touch panel. It may be recognized as an operation corresponding to

<Functional Configuration of Game System 1>
FIG. 2 is a block diagram showing 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 to function as a general computer (not shown) and a functional configuration necessary to realize known functions in the game.

  The user terminal 100 has a function as an input device for receiving an input operation of a user, and a function as an output device for outputting an image or a sound of a game. The user terminal 100 functions as a control unit 110 and a storage unit 120 by 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 has a function of communicating with each user terminal 100 to support the user terminal 100 to advance the game. For example, the server 200 supports the progress of the quest, and supports the sharing of the 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 to mediate the exchange between the user terminals 100. The server 200 functions as a control unit 210 and a storage unit 220 by 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 executed by the user terminal 100 and the server 200. The game information 132 is data to be referred to when the control unit 110 and the control unit 210 execute the game program 131. The user information 133 is data related to the account of the user. In the storage unit 220, the game information 132 and the 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, 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 referred to as a 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 centrally controls the server 200 by executing the game program 131 stored in the storage unit 220. For example, the control unit 210 transmits various data, programs, and the like to the user terminal 100. The control unit 210 receives part or all of the game information or the user information from the user terminal 100. When the game is a multiplay game, the control unit 210 may receive a request for multiplay synchronization 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 another functional block (not shown) in order to support the progress of the game on the user terminal 100, depending on the nature of the game to be executed.

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

  The sharing support unit 212 communicates with a plurality of user terminals 100, and supports a plurality of users sharing the decks of the respective user terminals 100 with each other. The deck information of the deck organized by each user is stored in the storage unit 220 as game information 132 for each user. When the sharing support unit 212 receives 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 the play part using the decks of other users 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 set the deck information of the user who has registered as a friend as a supply target, or may set the deck information owned by the user of the online user terminal 100 as a supply target.

(Functional Configuration of User Terminal 100)
The control unit 110 centrally controls 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 in accordance with the game program 131 and the operation of the user. In addition, while the game is in progress, the control unit 110 communicates with the server 200 as needed to transmit and receive information.

  The control unit 110 controls the operation reception unit 111, the display control unit 112, the user interface (hereinafter referred to as UI) control unit 113, the animation generation unit 114, the deck formation unit 115, the transition preparation unit 116 according to the description of the game program 131. It functions as the quest progression unit 117 and the cost determination unit 118. The control unit 110 can also function as another functional block (not shown) to advance the game according to the nature of the game to be executed.

  The operation accepting unit 111 detects and accepts an input operation of the user on the input unit 151. The operation receiving unit 111 determines which input operation has been performed from the action exerted by the user on the console via the touch screen 15 and the other input / output IF 14, and outputs the result to each element of the control unit 110. Do.

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

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

  The animation generation unit 114 generates an animation indicating motion of various digital contents based on the control mode of various digital contents. For example, an animation may be generated that expresses how a lottery of a card of a character is being executed. Alternatively, in the battle part, an animation representing 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 representing that the teammate character incurs a penalty associated with the cost excess in the battle part.

  The display control unit 112 outputs, to the display unit 152 of the touch screen 15, a game screen on which the processing result executed by each of the above-described elements is reflected. 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 UI component described above in a superimposed manner on the game screen.

  The deck forming unit 115 executes the deck forming part in accordance with the user's operation accepted via the operation accepting unit 111. The deck organization unit 115 has a deck organization function and processes the deck information 121 according to the user's operation. The deck organization function, for example, reads out 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 of searching, extracting, and sorting characters matching the various conditions from the card DB 122 based on various parameters of characters included in the card information.

  The transition preparation unit 116 executes the transition preparation part in accordance with the user's input operation accepted via the operation acceptance unit 111. The transition preparation part is a part for performing various settings relating to the play part between the completion of the deck formation part and the transition to the 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 a plurality of types of quests. In addition, a second subpart may be included in the transition preparation part, which causes the user described above to select the character of the assistant who is caused to participate in the quest.

  In this embodiment, the user can summon a character as a helper to a battle part in a quest from the deck of another user who has made a friend registration. The user can operate the summoned assistant character in the same manner as an ally character incorporated in his or her deck, and 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 in the deck the character he wants the helper to come to. The number of characters to be summoned as a helper may be limited, for example, up to one, or all characters in the deck of another user may be summonable. Further, the conditions under which the helpers are summoned may not be set in advance, or may be determined in advance, such as when the ally character on his or her deck becomes uncombatable.

  The quest progression unit 117 advances a quest as a play part based on the deck formed by the deck formation unit 115. In the present embodiment, when the user clears one quest, a reward corresponding thereto is given. The user will play the quest aiming to clear. In the present embodiment, as an example, it is determined that the user has cleared the quest when the teammate character beats the enemy character in all the battle parts included in the quest.

  In this embodiment, a plurality of quests are provided according to the difficulty level and the attribute of the enemy character appearing in the battle part, and the user can select a quest to be challenged from a plurality of quests. . The quest progress 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 progress.

  The cost determination unit 118 determines whether or not the cost is exceeded in the deck formed by the deck formation 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 organized in the deck by the user, and compares the obtained sum of costs in the deck (hereinafter, deck cost sum total) with the user's upper cost limit.

  The cost excess means that the total deck cost mentioned above exceeds the cost upper limit mentioned above. When the total deck cost exceeds the cost upper limit value of the user, the cost determination unit 118 determines that the cost excess occurs in the deck.

  In the present embodiment, the determination result of the cost determination unit 118 affects the behavior of at least one of the deck formation 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 formation unit 115, the transition preparation unit 116, and the quest progress unit 117. However, the cost determination unit 118 may function as part of the deck organization unit 115, may function as part of the transition preparation unit 116, or may function as part of the quest progression unit 117. Good.

  Specifically, when the cost determination unit 118 determines that the cost excess exists in the deck, the quest progress unit 117 disallows the progress of the play part using the deck in which the cost excess occurs, instead of disallowing A penalty at which the progress of the play part is disadvantageous to the user is imposed at a predetermined timing during the progress of the play part. That is, instead of allowing the play part (quest) to be played while the cost is exceeded, the quest progress unit 117 carries out the above-mentioned penalty while the play part is in progress (in progress of the quest).

  Furthermore, the quest progress unit 117 may display, on the display unit 152 of the user terminal 100, a notification that a penalty is to be imposed while the play part is in progress and before the above-described penalty is performed. Alternatively, the quest progress unit 117 may display, on the display unit 152 of the user terminal 100, a notification that the penalty is imposed at a predetermined timing after the penalty is performed while the play part is in progress. In addition, the quest progression unit 117 may display the above-described notices on the display unit 152 before and after the penalty.

  The functions of the server 200 and the user terminal 100 shown in FIG. 2 are merely an example. The server 200 may have at least a part of the functions of the user terminal 100. In addition, the user terminal 100 may have at least a part of the functions of the server 200. Furthermore, another 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 execute part of the processing in the game system 1. That is, in the present embodiment, the computer that executes the game program may be any of the user terminal 100, the server 200, and other devices, or may be realized by a combination of a plurality of these devices.

<Flow of game>
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 forming unit 115 executes the play preparation part. The play preparation part is, for example, a deck formation part. The deck organizing unit 115 receives an input operation for organizing one or more objects in the deck from the user, and organizes 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, whether the total cost (total deck cost) associated with each of the one or more objects incorporated into the deck by the user exceeds a predetermined upper limit value (cost upper limit value) It is determined whether or not.

  In step S3, the transition preparation unit 116 may execute the transition preparation part to the play part according to the result of the determination by the cost determination unit 118.

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

  Step S4 includes the following steps instead of not being permitted when execution of step S4 is determined to be cost overrun. Specifically, the play part in step S4 imposes a penalty at which the progress of the play part is disadvantageous to the user at a predetermined timing during the progress of the play part, and the penalty based on the excess is Displaying at least one notification of imposed and / or penalized (notice of penalty implementation) on the display unit 152 at a predetermined timing in progress of the play part.

  That is, even if it is determined that the cost is exceeded, the execution of the play part in step S4 is permitted. Instead, while the play part is in progress, a penalty is imposed which makes the progress disadvantageous, and a notification for making the user aware of it is displayed on the display unit 152.

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

  The reward given to the user in step S5 is, for example, provided to the user as digital content available on the game. The specific content of the reward is, for example, a card or a figure corresponding to the character operated by the user, an item having a special effect, or an ability to allow the character to wear it. Alternatively, the reward may be a right that the user can exercise on the game. The right as a reward is, for example, the right to strengthen the character, the right to play a special quest, the right to extend the item inventory, the right to release a locked quest or item, or the right to raise the cost limit etc. is assumed.

  Providing digital content as a reward to a user may, as an example, transition the status of digital content managed in association with the user from unavailable to usable. Alternatively, the digital content may be stored in at least one of the memories (the memory 11 and the 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 to be referred to below is configured by a UI component 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 by the display control unit 112 on the display unit 152 of the user terminal 100. 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 (the deck formation unit 115, the transition preparation unit 116, and the quest progression unit 117) for advancing each part of the game. A process for displaying the game screen on the display unit 152 is executed. Therefore, the description “each unit for advancing each part displays the game screen on the display unit 152” indicates that “each unit controls the UI control unit 113 or the animation generation unit 114 to generate a UI part or animation. , And controls the display control unit 112 to display on the display unit 152 a game screen including the generated UI component or animation.

<About the deck>
(Screen example)
FIG. 4 is a diagram showing an example of the 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 components for the user to organize decks. 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 be made to participate in the play part. The copy list 402 is a UI component for listing the copy characters of the user's hand, which are candidates to be incorporated into the deck.

  The operation receiving unit 111 receives an input operation of a user for arranging a character on the deck 401. The input operation is performed by, for example, dragging an icon (R1 to R15) of a card of one character displayed in the copy list 402 and dropping it on a frame (F1 to F5) to be arranged on the deck 401. It is realized by drag and drop operation.

  The deck formation section 115 arranges the card of the selected character in the frame of the drop destination in the deck 401 in accordance with the input operation. As an example, up to five characters can be arranged on the deck. The example shown in FIG. 4 shows that characters are arranged in all five frames of the deck 401.

  It is preferable that the deck forming unit 115 displays various parameters of the arranged character in each frame of the deck 401. Thereby, the user can confirm the performance of each character incorporated into 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” and the like) may be further displayed.

  It is preferable that the deck formation unit 115 further causes the deck formation screen 400 to display the upper cost limit 404 set by the user and the total deck cost 405 of the deck 401. This allows the user to check whether the current total deck cost 405 exceeds or is below the cost upper limit 404 of his or her own.

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

  The operation accepting unit 111 accepts a tap operation on the decision button 406. According to this instruction, the deck forming unit 115 generates deck information representing the contents of the deck 401, and stores the deck information as the deck information 121 in the storage unit 120. In the play part, the quest progression unit 117 advances the quest based on the deck represented by the deck information 121 with reference to the deck information 121 stored in the storage unit 120.

(data structure)
FIG. 5 is a view showing an example of the data structure of the card DB 122. As shown in FIG. The card DB 122 is a database for centrally managing cards owned by the user. The card DB 122 is stored, for example, as game information 132 in the storage unit 120 of the user terminal 100. 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 by the server 200 for each user. 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 card DB 122 of the user from the server 200 as necessary.

  The card DB 122 includes items of a card ID, a card name, basic parameters, and a battle ability parameter as an example.

  The card ID is for uniquely managing the card held by the user on the game system 1. In the present embodiment, the user can possess a plurality of cards of the same character in an overlapping manner. Therefore, when the character is the same but there are a plurality of cards, different card IDs are given to the respective cards in order to identify the respective cards. The card name indicates the name of the character corresponding to the card.

  Basic parameters refer to various parameters related to the nature of the character. The basic parameters are parameters that do not change during the progress of the play part. Basic parameters include, for example, rarity, level, cost, and attribute.

  The rarity is a grade representing the rarity value of a card (character). In general, characters that produce good results in the game, particularly in the play part, that is, characters with high combat ability, have a high degree of rarity. In the present embodiment, the rarity degree is set by the alphabet of “S”, “A”, “B”, and “C” in order from the grade having high rarity value.

  The rarity is, for example, the difficulty of obtaining a card, more specifically, the probability of winning in a lottery in which the card is hit, the degree of difficulty of a quest when obtained as a clear reward for a quest, or It may be correlated with the price etc. The higher the card's rarity, the more difficult it is to obtain the card.

  The level is a parameter indicating the degree of reinforcement of the character. The higher the level, the higher the combat ability parameter referenced in the play part. Note that, in the play preparation part, by strengthening the character with a reinforcement material or the like, the character level may be raised to improve the character's ability.

  The cost is a value consumed as compensation for incorporating the character into the deck, and is set for each character. Generally, the higher the in-game value the character has, that is, the higher the battle ability, the higher the cost.

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

  The attributes of characters incorporated into the deck are referenced in the combat part to determine various values in the combat part. Favorable attributes and disadvantageous attributes may be set to each other. For example, fire may be set to light, lightning to water, and water to fire. More specifically, in the battle part, it is conceivable that the fire attribute character may inflict more damage than usual against the lightning attribute enemy character. Also, in the battle part, it is conceivable that allied characters of the same attribute give an advantageous interaction to the battle. In addition, an attribute may be set to a quiz that is given a question in the battle part. For example, the quest progression unit 117 may control so that only the character having the same attribute as the attribute set in the correctly answered quiz can execute the attack operation.

  The battle ability parameter defines the performance of the character in the play part. The combat ability parameter is a parameter that can be varied during the progress of the play part. The combat ability parameters include, for example, strength, aggression, and skill.

  The physical strength is a parameter that defines the physical strength of the character and is represented, for example, by a numerical value. The numerical value is reduced by receiving an attack from an enemy character in the battle part, and if the strength becomes zero, the character becomes uncombatable. The physical strength is also set for the enemy character, and the attack of the ally character makes it possible to win the battle by setting the physical strength of all the enemy characters to zero.

  The attack power is a parameter that defines the power to damage the enemy character, and is represented by, for example, a numerical value. The larger the number, the stronger the damage. In the present embodiment, the aggressivity can deprive the enemy character of strength by the attack that the character normally performs and the special attack that the character performs by activating the skills described below under certain conditions (hereinafter, the special attack). Affect the

  A skill is a special ability that each of the characters has, and is a special ability that can be activated based on a predetermined condition in the battle part. Skills provide advantageous effects to allied characters in a combat part. The action of the skill may be directly applied to the ally character, or the ally character may be advantageous indirectly by extending to the enemy character.

  The item of the skill includes the content of the skill and the degree of the effect by the skill, as illustrated. The degree of the effect is expressed, for example, numerically. Although not illustrated, the item may further include a condition that enables the skill to be activated.

  Specific examples of the skills include, for example, a skill that causes an enemy character to be damaged by a special attack, a skill that temporarily increases the attack power of an ally character, a skill that restores the strength of an ally character, and damage received by an attack from an enemy character. And the skill to lower the defensive power of the enemy character. The conditions under which these skills can be activated may be common to all characters or may be different for each character.

  As a numerical value representing the degree of the effect of the skill, for example, "300% (damage)" means that it gives three times as much damage as normal attack.

  The skill may be activated, for example, if the user can quickly answer correctly within a predetermined time after the quiz is presented. A skill that is triggered based on the speed of correct answer may be referred to as a quick answer skill. Alternatively, the skill may be activated, for example, when a predetermined number or more of answers are correctly answered over a plurality of turns. As such, the skill activated based on the cumulative number of correct answers may be referred to as the correct answer number skill. Alternatively, the skill may be activated when the correct answer is made continuously for a predetermined number of times or more without making a wrong answer over a plurality of turns. A skill that is triggered based on the number of consecutive correct answers in this manner may be referred to as a successive answer skill.

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

  FIG. 6 is a view showing an example of the data structure of the deck information 121. As shown in FIG. 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. If the user owns a plurality of decks, deck information 121 is generated for each owned deck.

  The deck information 121 is stored, for example, as game information 132 in the storage unit 120 of the user terminal 100. 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. Thus, the deck information 121 includes, as frame identification information, deck frame numbers 1 to 5 corresponding to each of the five frames. Then, the card ID is stored in association with each of the deck frame numbers 1 to 5.

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

  The deck information 121 may further have 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 view showing an example of the data structure of the user information 133. As shown in FIG. The user information 133 is composed of various information set for each user who uses the game system 1.

  The user information 133 includes, as an example, a user ID, a user name, and a cost upper limit value. The user information 133 may also include levels, experience values, 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 username is used, for example, for the user himself and other users to identify the user himself. The upper cost limit indicates the upper limit of the total deck cost in the deck. The cost upper limit is set for each user. The upper cost limit is preferably increased when a predetermined condition is satisfied by the user playing the game. As one example, the cost upper limit is a parameter that rises according to the level of the user. The experience value is given to the user in response to the user playing a quest or the like of the play part, and when the experience value reaches a certain value, the user's level rises. As the user's level goes up, the cost cap is increased. If the user wants to raise the cost upper limit, he may repeat the play, accumulate experience points, and raise the level. Also, in the present embodiment, the right to increase the cost upper limit may be given to the user in exchange for a paid or free item. In this case, the control unit 110 accepts an operation performed by the user to consume a paid or free item, consumes the item of the user, and instead, a cost upper limit value of the consumed item. Increase

<About the penalty>
In the present embodiment, when the total deck cost of the decks exceeds the cost upper limit value, the user terminal 100 instructs the user to use the deck with the cost overrun (hereinafter referred to as 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 the penalty based on the cost excess.

  Further, in the present embodiment, the user terminal 100 implements the above-mentioned penalty during the progress of the play part. The user terminal 100 does not immediately carry out a penalty, for example, when a cost excess is detected in the play preparation part (deck formation part).

  Below, it will be described in detail that the user terminal 100 carries out a penalty in the proceeding period of step S4 shown in FIG. 3 using a specific example.

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

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

  In the case of YES in step S102, in step S103, the quest progress part 117 imposes a penalty to the user based on the cost excess. The penalty, as one example, exerts an action on the teammate character or the enemy character that makes the progress of the play part disadvantageous to the user.

  In step S104, the quest progress unit 117 displays, on the display unit 152, a notification for causing the user to recognize that at least one of the penalty based on the excess and the penalty based on the penalty. That is, the quest progress part 117 may impose a penalty in step S103 after notifying that the penalty is imposed in step S104.

  As a result, the battle part in each subsequent step will proceed under the influence of the user's adverse effects based on the fact that the penalty has been implemented.

  In step S105, the quest progress unit 117 causes the enemy object to advance a first strike turn. The step may be omitted if the enemy object is not capable of first strike.

  In the case of YES at step S106, that is, when the physical strengths of all the characters incorporated into the deck become zero due to the attack action of the enemy object, the quest progress unit 117 transitions to step S107.

  In step S107, the quest progress unit 117 ends the fighting part on the assumption that the party based on the user's deck has been defeated. Then, the quest progression unit 117 ends the play part (quest) itself. The quest progression unit 117 may receive a continue instruction for a type of quest that can be continued. When the instruction of continue is input, after step S107, the quest progress unit 117 cancels the incompetent state of the teammate character, and returns to step S106.

  In the case of NO at step S106, the quest progress unit 117 transitions to step S108. In step S108, the quest progress unit 117 implements the quiz element. As an example, the quest progression unit 117 presents the genre of the quiz associated with the attribute, accepts the selection of the genre from the user, issues the quiz of the selected genre, and accepts the answer. In this step, the quest progression unit 117 may set which ally character attacks which enemy character according to the user's operation, or activate the ally character's skill.

  In step S109, the quest progression unit 117 advances the attack turn of the teammate object according to the implementation result of the quiz element.

  In the case of NO at 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.

  In the case of YES at step S110, the quest progress unit 117 transitions to step S112. In step S112, the quest progress unit 117 ends the battle part on the assumption that the party has won.

  In the case of NO at step S113, that is, when there is an unexecuted battle part remaining in the quest, the quest progression unit 117 returns to step S101 and repeats the subsequent processing. In the case of YES at step S113, the quest progress part 117 ends the quest. Steps S102 to S104 may be performed at any timing from steps S101 to S113.

(Variation of penalty)
In step S103, the quest progressing unit 117 contributes to exerting an adverse effect on the allied character that brings good play results for the user and is incorporated in the user's deck, and contributes to bring the play results that the user does not want. That is, at least one of exerting an advantageous action 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 the content that acts in a negative manner on the teammate character and / or acts on the enemy character in the battle part.

  For example, the quest advancing unit 117 may lower at least a combat ability parameter (parameter) that defines the combat performance of the allied character, and increase a combat ability parameter that defines the combat performance of the enemy character. Either one may be implemented as a penalty.

  For example, the disadvantageous actions for the above-mentioned allied characters include that the allied objects fall into an abnormal state in which the performance of the allied objects is not exhibited as prescribed. The quest progressing unit 117 causes the teammate character to fall into the above-described abnormal state, and the time required for the battle part to progress to release the abnormal state when the teammate character falls into the above-mentioned abnormal state. And / or may be implemented as a penalty. The cancellation of the abnormal state includes, for example, the return of the ally character to a normal state in which the performance of the ally character is exhibited as prescribed.

  As an abnormal state in which the ally character falls, for example, poison (physical strength is automatically reduced every turn), paralysis or sleep (inability to act in the attack turn of the ally character), aggression / defensive ability down, and skill Sealing (cannot activate skills even if activation conditions are met), etc.

  In the present embodiment, as an example, as described above, the play part includes one or more combat parts. The battle part proceeds by causing one or more ally characters and one or more enemy characters to play a match. For example, the quest execution unit 117 may perform, as a penalty, assisting the enemy character while the battle part is in progress.

  For assisting the enemy character, for example, recovering the physical strength of the enemy character, increasing the attacking power of the enemy character, increasing the defensive power of the enemy character, adding an enemy character, etc. Of providing advantageous effects to the enemy character.

(Variation of notification)
In step S104, the quest progress unit 117 preferably displays a notification on a penalty based on cost excess in a display manner in line with the context of the game.

  If the penalty performed due to the violation operation (excess cost) other than the play part is performed during the progress of the play part, the user is less likely to feel discomfort if the causal relationship is clear be able to. Here, when the notification regarding the penalty based on the cost excess is made, such as displaying “the penalty has been carried out due to cost excess”, the causality of the implementation of the penalty becomes clear to the user.

  The notification regarding the penalty is preferably performed in a display mode in line with the context of the game, rather than mechanical and dry. This makes it possible for the user to recognize that a penalty based on cost overrun has been implemented while avoiding loss of immersion in the game. Furthermore, by performing the above-mentioned notification in a display mode in line with the context of the game, it is possible to further enhance the game immersion in the progress of the main play part of the game. .

  Notifications relating to penalties are generated by text, symbols, icons, still images, animations, and various UI components combining these. In any case where any UI component is adopted, it is preferable that a presentation conforming to the world view of the game is provided. For example, in the RPG including the battle part, when realizing the notice by text, a word such as “curse of over-cost strikes a party!” May be adopted as the above-mentioned notice.

  For example, in an RPG that includes a battle part, when the notification is realized by animation, in the notification, the adverse effect on the friend object based on the penalty is represented by the attack of the enemy object. An animation representing that the attack of the enemy character exerts an adverse effect on the ally character may be adopted as the above-mentioned notification.

  Alternatively, in step S104, the quest progress unit 117 may display information on the display unit 152 to explain that the penalty to be recognized by the user by the above notification is based on the cost excess. As a result, the user can clearly recognize that the penalty is imposed due to the excess cost of the deck. Also, a user who has actually experienced an adverse situation due to a penalty recognizes again that this penalty is based on cost overrun. For this reason, the desire for the game is fostered, such as wanting to raise the level and raise the cost upper limit, and formulate a strategy and organize an effective deck within the cost upper limit.

(Timing of notification)
As shown in FIG. 8, the quest progression unit 117 executes step S104 for displaying a notification following step S103 for applying a penalty, or executes step S103 for applying a penalty subsequent to step S104 for displaying a notification. Is preferred. This allows the user to be aware of cost violations and their disadvantages. As a result, it is possible to foster the user's willingness to eliminate cost violations and to enhance the user's motivation for playing.

  Alternatively, the quest progression unit 117 may execute step S104 of displaying the notification immediately after step S101 of executing the play part is started. As a result, the user can be easily notified that the entire part of the play part is affected by the penalty.

  Alternatively, the quest progression unit 117 may execute step S104 of displaying the notification immediately before the first turn in which the teammate character can act is started. In this way, the user can be notified in an easy-to-understand manner that the influence of the penalty is exerted particularly on the action turn of the ally character.

(Concrete example)
In the present embodiment, as an example, the penalty based on the cost excess is that “the combat ability parameter possessed by the character is uniformly reduced by 25%”. The functional configuration of the user terminal 100 will be described in more detail based on this specific example.

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

  FIG. 9 is a diagram showing one specific example of the battle ability parameter of each character organized in the deck after the penalty is taken. In the present embodiment, among combat ability parameters, numerical values to be subjected to a 25% reduction process are, for example, (1) strength, (2) aggression, and (3) numerical values indicating the degree of the effect of skills, There are three.

  In the present embodiment, the quest progression unit 117 carries out a penalty by decreasing all the above-mentioned three numerical values by 25% for all five characters. The battle ability parameters shown in FIG. 9 indicate the battle ability parameters of the five characters arranged in the frames F1 to F5 of the deck 401 after the penalty. All the above three figures are reduced by 25% as compared to the original combat ability parameters before the penalty shown in FIG. The quest progression unit 117 advances the battle part based on the battle ability parameter shown in FIG.

  In another embodiment, the numerical value targeted for the 25% reduction as a penalty may be not all but at least one of the above (1) to (3). For example, the quest progress unit 117 may decrease only (1) strength and (2) aggression of each character by 25%. In still another embodiment, the characters subject to the penalty may be not all but only some of the characters arranged in the deck.

  In another embodiment, a target whose value is reduced as a predetermined action amount (for example, an 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 may be

  FIG. 10 is a view showing an example of the 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, an allied character area 502, and a quiz area 503. The enemy character area 501 is an area for displaying information on enemy characters. The ally character area 502 is an area for displaying information related to the ally character and receiving a user operation for designating an action of the ally 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, in step S104, the quest progression unit 117 may further superimpose the first notification 504 indicating the state of the deck on the battle screen 500 and display it. The first notification 504 includes information describing that the penalty to be implemented or the penalty to be implemented is based on cost overrun, or information describing that there is a cost violation on the deck. Step S104 of displaying the first notification 504 may be performed prior to step S103 after step S102. The first notification 504 is a notification relating to the deck, so the first notification 504 is superimposed on the friend character area 502 for displaying the deck, but the quest progressing unit 117 determines the first notification 504 at any position on the battle screen 500 Can be superimposed on the display.

  By the first notification 504, the user can recognize that the cost excess has occurred in the deck 401 which he has organized, and that, if the penalty is taken, the penalty is due to the cost excess. You can understand that.

  FIG. 11 is a view showing an example of the game screen displayed on the display unit 152 when the play part is being executed. The game screen shown in FIG. 11 is, for example, a battle screen 500 including a second notification 505 which is subsequently displayed after the first notification 504 is displayed on the battle screen 500 shown in FIG.

  In the present embodiment, the quest progress unit 117 superimposes, on the battle screen 500, the second notification 505 for causing the user to recognize that the penalty based on the cost excess has been or has been performed in step S104 of FIG. indicate. The second notification 505 may be implemented by an animation that represents how the combat ability parameter of the ally character decreases. The second notification 505 is a notification relating to an ally character, and therefore, is displayed superimposed on the ally character area 502. However, the quest progression unit 117 causes the second notification 505 to be displayed superimposed on an arbitrary position on the battle screen 500. Can. For example, when the second notification 505 is a notification relating 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 cost overrun penalty has been implemented.

(effect)
According to the above configuration and method, the deck in which the cost violation has occurred without prohibiting the organization of the deck in which the cost violation has occurred or the prohibition of playing on the deck in which the cost violation has occurred. Play with is permitted.

  In this way, it is possible to give a beginner who has a low upper limit cost an opportunity to play a game using a high-cost character, that is, a strong character. As a result, even if a strong character or item etc. is acquired, the deck cost upper limit becomes a bottleneck and can not be used in play, and it solves the problem that the interest of the game is significantly impaired, especially for beginners. it can.

  On the other hand, for a user using a cost violating deck, a penalty is imposed that the progress of the game is disadvantageous to the user. This does not compromise the value and enjoyment of rolling up the organization within the cost cap so as not to be penalized. Also, it is possible to organize the deck with care so as not to cause cost violations, and to prevent inequity with the user who is playing the game.

  The configurations and methods described above also benefit advanced users. Specifically, the game will be more interesting, such as adopting a deck within the cost upper limit or incorporating the desired character into the deck even if the cost excess penalty is incurred. Do.

  According to the above-described configuration and method, the following problems that the prior art has can be further solved. The cause of the cost violation is the organization of the party selected by the user in the play preparation part, and in Patent Document 1, the penalty is that the ability value etc. of the character is lowered on the spot, that is, in the play preparation part. It is carried out in the form. However, it is the play part that is actually affected by the penalty as a result of the cost violation. As described above, it is difficult to understand the causal relationship between the organization by the user in the play preparation part and the game progress status in the play part, and it is difficult for the user to be aware of the cost violation and its disadvantages. Therefore, if the penalty is implemented in the play preparation part, the willingness to solve the cost violation is not fostered.

  In addition, if the cost violation is normalized, and the character continues to be displayed in the deck formation screen with the penalty being applied and the ability value is still lowered, the user gets used to the condition. And the original attraction of the character is lost. As a result, it also leads to a decrease in the interest of the game.

  On the other hand, according to the above configuration and method, after the play part is started, a penalty is imposed while the play part is in progress, and it is recognized that a penalty based on cost overrun is imposed or imposed. A notification to make it appear is displayed while the play part is in progress. This allows the user to be aware of cost violations and their disadvantages.

  By displaying the notification related to the penalty while the play part is in progress, it is not necessary to display the result after the penalty (the lowered ability value of the character) on the deck formation screen. Therefore, since it is possible to show the character's original ability value in the deck formation screen, it is possible to avoid losing the character's attraction due to cost violation. As a result, the motivation to eliminate cost violations is fostered, and the motivation to play can be strengthened.

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

  In step S201, the quest progress 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 ally 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 card DB 122 shown in FIG. 5 is stored in the storage unit 220 of the server 200 for each user. In step S202, the quest support unit 211 of the server 200 acquires, from the card DB 122, the battle ability parameter of each character arranged on the deck of the user based on the card ID included in the deck information 121 received from the user terminal 100. Do. The combat ability parameter acquired here indicates a normal time value before the penalty is taken.

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

  In step S203, the quest support unit 211 acquires, from the storage unit 220, the reduction rate to be applied when the cost is exceeded, for example, “25% down”. In step S 204, the quest support unit 211 sends back to the user terminal 100 the battle ability parameter of each character at normal times and the reduction rate.

  In step S205, the quest progress unit 117 reduces the supplied battle ability parameter based on the reduction rate specified by the server 200.

  According to the above-described method, the user terminal 100 can carry out a penalty on the battle ability parameter without storing the card DB 122 of the user locally in the storage unit 120. The card DB 122 has a huge amount of information as the number of cards held by the user increases, so that there is an advantage in that the memory 11 of the user terminal 100 can be prevented from becoming tight.

  On the other hand, the server 200 is configured to only transmit to the user terminal 100 the information at the normal time of the character arranged in the deck and the predetermined reduction rate. The server 200 does not have to determine whether the cost of the user's deck is excessive or not, and does not need to execute processing to reduce the battle ability parameter if the cost is excessive. There is an advantage that the processing load of the server 200 can be reduced in the server 200 where it is assumed that requests are 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 change the weight of the penalty according to the situation, and the interest of the game can be further improved. The situation is assumed to be, for example, the level of the user, the amount by which the total deck cost exceeds the cost upper limit, and the degree of difficulty of the quest selected by the user. As disclosed in Patent Document 1, in the configuration in which the penalty is implemented in the deck formation part, the weight of the penalty can not be changed according to the situation. As described in the first embodiment, the user terminal 100 is configured to carry out the penalty in the play part, so that the weight of the penalty can be changed according to the situation.

Third Embodiment
In the third embodiment, the game system 1 may also behave differently in the play preparation part depending on whether or not the cost is exceeded.

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

  In step S301, the deck forming unit 115 displays a deck forming screen. For example, the deck organization screen 400 shown in FIG. 4 is displayed on the display unit 152. In step S302, the operation receiving unit 111 receives an input operation by the user on various UI components included in the deck formation screen 400.

  In step S303, the deck formation unit 115 generates the deck 401 in accordance with the above-described input operation. 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 S304, the cost determination unit 118 determines whether the total deck cost 405 of the generated deck 401 exceeds the cost upper limit 404 of the user. The deck forming unit 115 makes each step (S306 to S308) for displaying the deck 401 after formation different as follows according to the presence or absence of the cost excess.

  In the case of YES at step S305, that is, when the cost excess has occurred, the deck forming unit 115 makes a transition to steps S306 and S307. In step S306, the deck formation unit 115 causes the UI control unit 113 to generate a warning that the cost excess has occurred in the deck 401. In step S307, the deck generation unit 115 causes the UI control unit 113 to generate a notice that the penalty based on the cost excess will be implemented in the play part. The deck organizing unit 115 may read out from the storage unit 120 UI components of a warning or notice generated in advance. The warning and the notice may be collectively stored in the storage unit 120 as one UI component. Warnings and notices are stored in the storage unit 120 as texts, symbols, icons, still images, animations, and various UI parts combining them.

  In step S308, in addition to displaying the deck 401 after formation on the deck formation screen 400, the deck formation unit 115 displays at least one of the generated warning and notice on the deck formation screen 400. The warning or notice may be displayed in a pop-up superimposed on the deck 401, or may be displayed in an area different from the deck 401. Here, when displaying the deck 401 after formation, the deck forming unit 115 displays the parameters of the respective characters arranged in the respective frames F1 to F5 with the original values, and as a result of the execution of the penalty (specifically, Does not display reduced parameter values).

  In the case of NO at step S305, that is, when the cost excess is not generated, the deck forming unit 115 omits steps S306 and S307 and shifts to step S308. In step S308, the deck formation unit 115 displays the deck 401 after formation on the deck formation screen 400.

  If YES in step S309, that is, if the operation receiving unit 111 receives an input operation for completing the formation of the deck 401, the deck forming unit 115 transitions to step S310. In step S310, the deck formation unit 115 stores the deck information 121 corresponding to the current deck 401 in the storage unit 120. The above-mentioned input operation is, for example, a touch operation on the decision button 406 of the deck organization screen 400 or the like.

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

(Screen example)
FIG. 14 is a diagram showing 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 the screen after the transition from the deck organization screen 400 shown in FIG. 4 when the cost excess occurs in the deck 401. For example, the deck formation screen 410 includes at least one of a warning that the deck 401 is in excess of cost and a notice that a penalty based on the cost excess is to be implemented in the play part.

  As illustrated in FIG. 14, the deck forming unit 115 generates the above-described warning as the warning text 412 and generates the above-described notice as the notice text 413, as an example. Then, the deck forming unit 115 can display the deck forming screen 410 on the display unit 152 by causing the window 411 including these UI components to be superimposed on the deck forming screen 400 and displayed in a pop-up manner.

  Note that the window 411 may be displayed each time the transition from a state where there is no cost excess to a state where there is a cost excess, as a card of a character with a high cost is placed in any of the frames of the deck 401. Alternatively, the window 411 may be displayed at the timing when the decision button 406 is touched in a state where the cost of the deck 401 is exceeded.

  This allows the user to understand the disadvantage of cost overrun and then consider whether to adopt the over cost deck 401 or reorganize the deck 401 so as not to exceed the cost. Also, even if a penalty is implemented in the play part, it can be understood and understood as a penalty based on cost excess.

Embodiment 4
Further, in the fourth embodiment, the game system 1 may make the behavior different in the transition preparation part depending on whether or not the cost is exceeded.

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

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

  In step S403, the transition preparation unit 116 acquires detailed information of the quest specified by the user from the server 200, and displays a quest detailed screen for displaying the detailed information on the display unit 152. In the quest detail screen, an input operation for specifying a deck adopted for the quest may be accepted.

  In step S404, the transition preparation unit 116 displays a helper selection screen for selecting a helper on the display unit 152. The information of the assistant serving as the 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 in the quest detail screen.

  In step S405, the operation receiving unit 111 receives an input operation for specifying a helper from the user.

  In step S406, the transition preparation unit 116 acquires the information of the designated assistant from the server 200. Specifically, the deck information 121 of the designated other user is acquired, and various parameters of the character disposed on the deck by the other user are acquired.

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

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

  In the case of YES at step S410, the transition preparation unit 116 executes the respective steps of steps S411 to S413 in an arbitrary order in response to pressing of the play start button. In some cases, either step S411 or S412 may be omitted. In step S411, the transition preparation unit 116 displays on the display unit 152 a warning that the total deck cost 405 exceeds the cost upper limit 404. In step S412, 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, on the display unit 152, a UI component for the user to select whether to maintain or cancel the play start instruction. Specifically, the transition preparation unit 116 causes the display unit 152 to display a play start button for the user to maintain the play start instruction and a cancel button for canceling the play start instruction.

  If 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 progress unit 117 to start the play part, and ends the transition preparation part.

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

(Screen example)
FIG. 16 is a view showing an example of the game screen displayed on the display unit 152 when the transition 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 indicating detailed information on the quest. The deck 602 is a UI component indicating information of the currently adopted deck. The warning 603 is a UI component that warns the user of cost excess. The play start button 605 is a UI component for the user to instruct the start of the quest.

  The quest information 601 allows the user to confirm whether the quest that he or she wants to challenge is correct. The deck 602 allows the user to confirm the contents of the deck to be adopted in the quest to be challenged. The warning 603 allows the user to recognize that the adopted deck has an excess cost before the challenge. The helper selection screen 604 allows the user to select a desired helper to participate in the quest.

  By operating the various UI components described above, when it is ready to challenge the quest, the user can depress the play start button 605 to instruct to start the quest. When the play start button 605 is pressed, as a result of the determination by the cost determination unit 118, if there is no cost excess in the deck, the quest progress unit 117 starts the progress 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. 17 on the display unit 152.

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

  As illustrated in FIG. 17, the transition preparation unit 116 generates the above-described warning as the warning text 612 and generates the above-described notice as the notice text 613, as an example. Further, the play start button 605 is re-arranged as a UI component for maintaining the quest start instruction, and the cancel button 614 is arranged as a UI component for selecting the quest cancellation. Then, the transition preparation unit 116 can display the quest detail screen 610 on the display unit 152 by causing the window 611 including these UI components to be superimposed on the quest detail screen 600 and displayed in a pop-up manner.

  This allows the user to notice that the adopted deck 602 is cost-exceeded, just before moving to the quest. Therefore, it is possible to prevent a situation in which a quest is advanced using a deck that is cost overrun by mistake and a user receives an unintentional penalty, thereby improving the user's convenience.

[Modification]
In step S103, the quest progress unit 117 may change the weight of the penalty in accordance with the amount by which the total deck cost exceeds the cost upper limit. Specifically, the more the excess amount, the lower the character's status may be lowered.

  This makes it possible for the user to have an awareness to try to reduce costs as much as possible, and to provide the user with the value of thoughtfully organizing the deck. In addition, there is no inequity between users who are going to organize decks with strong characters anyway, and users who are trying to control strategies as much as possible without worrying about excess costs. You can do so.

  The execution of the play part based on the deck whose total deck cost 405 exceeds the cost upper limit 404 may be permitted only when a predetermined condition is satisfied. That is, even if the user inputs an instruction to start a quest, if the deck is in a state of cost excess and a predetermined condition is not satisfied, the transition preparation unit 116 sends a request to the quest progress unit 117. On the other hand, prohibit the progress of the quest. Alternatively, the quest progress 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 has been 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 cost overrun deck may be permitted only to users of a predetermined level or lower. For example, even if the user inputs an instruction to start a quest, if the deck is in a state of cost excess and the user exceeds a predetermined level, the transition preparation unit 116 sends a request to the quest progress unit 117. , Prohibit the progress of the quest.

  In the present 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 cost overrun deck may be permitted only for the quest having a predetermined level of difficulty or less. For example, even if the user inputs an instruction to start a quest, if the deck is in a state of cost excess and the difficulty of the instructed quest exceeds a predetermined difficulty, the transition preparation unit 116 The quest progression unit 117 is prohibited from proceeding with the quest.

  The main purpose of the rescue plan to allow play with over-cost decks is to prevent beginners from getting stuck in the early stages of the game or feeling that they can not enjoy the game.

  As a side effect of this remedial action, advanced users who are playing games for a long time feel that this remedial action is unnecessary, seemingly denied the way they enjoy the game, and, furthermore, There is concern that you will lose your motivation to play the game. This is because advanced users find out the fun and value of completing an effective deck through trial and error during a long play experience.

  Therefore, the above-mentioned remedies are applied only to users who have a low game experience and a low cost upper limit, or to quests with low difficulty that a beginner user is likely to challenge. This produces an effect that the above-mentioned purpose can be achieved with less side effects and effectively.

  The game according to the present embodiment may be a multiplayer game in which the decks owned by each of a plurality of users are 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 a helper (the deck of another user) on the display unit 152 in step S404.

  Here, the transition preparation unit 116 preferably displays information indicating whether the total deck cost of decks organized by other users exceeds the cost upper limit value.

  This allows the user to select a desired helper's deck, avoiding decks that are cost overruns. As information indicating whether or not the deck causes cost overrun, for example, an icon indicating cost overrun may be displayed in association with a helper icon.

  In the quest detail screen 600 shown in FIG. 16, the transition preparation unit 116 displays the assistant selection screen 604. The transition preparation unit 116 displays the icons of the characters arranged on the decks of other users in a selectable manner on the assistant selection screen 604. Here, it is assumed that among the displayed helper characters, there are several characters scheduled to be penalized for decreasing the parameter due to a deck violation. In this case, it is preferable that the transition preparation unit 116 further adds an icon indicating that the character is a target of the penalty to the icon of the character of the assistant character who is the target of the parameter reduction penalty. . The icon may be, for example, a down arrow icon 606 reminding that the parameter is down due to a penalty.

  In another embodiment, the quest execution unit 117 determines that the assistant character is also subject to a parameter reduction penalty if the cost of the user's own deck is exceeded regardless of whether the cost of the other user's deck is exceeded. The configuration may be

  In another embodiment, the remedial measure according to the present embodiment can be applied to a battle game in which the main play part is a sport game or the like. For example, in a battle game in which the user plays a match against the CPU, the configuration is particularly permitted to limit the game to a user having a certain level or less, or to a quest having a predetermined level of difficulty or less. It may be suitably adopted.

  For example, in a person-to-person game in which another user is played against, it is preferable to adopt a configuration in which the weight of the penalty is changed according to the excess amount of cost, among others. This configuration is particularly advantageous because it can maintain fairness among users.

[Example of software implementation]
Control blocks of the control unit 210 (in particular, the quest support unit 211 and the share support unit 212), and control blocks of the control unit 110 (in particular, the operation reception unit 111, the display control unit 112, the UI control unit 113, the animation generation unit 114 The deck formation unit 115, the transition preparation unit 116, the quest progress 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, the information processing apparatus provided with the control unit 210 and / or the control unit 110 is a CPU that executes instructions of a program that is software that realizes each function, the above program and various data are computer (or CPU) The ROM (Read Only Memory) or storage device (these are referred to as a "recording medium") recorded in a readable manner, and a RAM (Random Access Memory) for expanding the program. The object of the present invention is achieved by the computer (or CPU) reading the program from the recording medium and executing the program. As the recording medium, a “non-transitory tangible medium”, for example, 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 any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. Note that one aspect 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 can be made within the scope of the claims, and embodiments obtained by appropriately combining the technical means disclosed in the different embodiments. Is also included in the technical scope of the present invention.

[Items to be added]
It will be as follows when the contents concerning one side of the present invention are listed.

  (Item 1) The game program (131) has been described. According to an aspect of the present disclosure, a game program is executed by a computer (user terminal 100) including a processor (10), a memory (11), an operation unit (such as an input unit 151), and a display unit (152). The game program includes the steps of: receiving from the user an input operation for incorporating one or more objects into the deck; and executing a play preparation part for storing the deck generated in accordance with the input operation in the processor; Determining whether the total cost associated with each of the one or more objects exceeds a predetermined upper limit, and a play part in which the user plays the game based on the game program using the deck Performing the steps of performing and performing the play part is a penalty in which the progress of the play part is disadvantageous to the user when it is determined that the total exceeds the upper limit value; Imposing the step at a predetermined timing and the penalty being 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. This has the effect of improving the interest of the game.

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

  (Item 3) In (Item 2), the step of imposing the penalty includes at least one of reducing a parameter that defines the performance of the friend object and increasing a parameter that defines the performance of the enemy object. It may be.

  (Item 4) In (Item 2) or (Item 3), the disadvantageous action includes the fact that the friend object falls into an abnormal state in which the performance of the friend object is not exhibited as prescribed, and the step of imposing the penalty At least putting an object into an abnormal state, and making a play part progress time longer than a specified time before the abnormal state is released when the ally object is in an abnormal state; Either one may be included.

  (Item 5) In any one of the items (Item 2) to (Item 4), the play part proceeds by playing a match between one or more ally objects and one or more enemy objects, and the penalty is The imposing step may include assisting the enemy object during the match.

  (Item 6) In any one of the items (Item 1) to (Item 5), in the step of displaying the notification, the notification may be displayed in a display manner in line with the context of the game.

  (Item 7) In (Item 6), in the notification, the adverse effect on the friend object incorporated into the user's deck based on the penalty may be expressed by the attack of the enemy object that is hostile to the friend object.

  (Item 8) In any one of the items (Item 1) to (Item 7), the game program causes the processor to execute the play part on the deck stored in the step of executing the play preparation part. Precedingly, in the step of performing the step of displaying on the display unit and displaying the deck, when it is determined that the total exceeds the upper limit value, the result of the penalty being performed is not displayed but is exceeded At least one of a warning to the effect and a notice that a penalty will be implemented in the play part may be displayed based on the excess.

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

  (Item 10) A method of executing a game program has been described. According to an aspect of the present disclosure, a 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 from the user an input operation for incorporating one or more objects into the deck; and executing a play preparation part in which the deck generated according to the input operation is stored in memory; Determining whether the sum of costs associated with each of the one or more objects incorporated in each exceeds a predetermined upper limit, the processor using the game based on the game program, the user using the deck Performing the play part to play, the step of performing the play part playing the penalty that the progress of the play part becomes disadvantageous to the user when it is determined that the total exceeds the upper limit value. Imposing steps and penalties at predetermined timings in progress of 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 function and effect 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 stores the game program, and 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 from the user for incorporating one or more objects into the deck, executes a play preparation part for storing the deck generated according to the input operation in the storage unit, and performs one or more It is determined whether the total cost associated with each of the objects exceeds a predetermined upper limit value, and the control unit executes a play part in which the user plays the game based on the game program using the deck. When a play part is executed, if it is determined that the total exceeds the upper limit value, a penalty is imposed at a predetermined timing during the progress of the play part, such that the progress of the play part is disadvantageous to the user. Notice of imposition and / or of imposition of penalty shall be given to the playing part in progress It is displayed on the display unit in the timing. The information processing apparatus according to (Item 11) has the same function and effect as the game program according to (Item 1).

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

  (Item 13) In any one of the items (Item 1) to (Item 9), the game program causes the processor to play the play part using the deck determined to exceed the upper limit value. The step of giving the reward to the user may be performed with a smaller amount or a lower value compared to the case where the reward is not exceeded.

  (Item 14) In any one of the items (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. Information may be displayed on the display unit.

  (Item 15) In any one of the items (Item 1) to (Item 9), the game program is a user interface (hereinafter, UI) component for instructing the processor to start the execution of the step of executing the play part In the step of displaying the UI widget on the display unit, the step of displaying the UI widget is performed before proceeding to the step of executing the play part when it is determined that the total exceeds the upper limit value when the UI widget is operated. In addition to displaying at least one of a warning and a notice on the display unit, a UI component may be displayed to select whether to hold or cancel the instruction to start execution.

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

  (Item 17) In any one of the items (Item 1) to (Item 9), the play part is one or more friend objects incorporated in the deck that provide good play results for the user, and the user does not want to It progresses by playing a match with one or more enemy objects contributing to the play result, and the match includes a turn to make the ally object act and a turn to make the enemy object act and display the notification. The steps may be performed just before the first turn of the friend object is started.

  (Item 18) In any one of the items (Item 1) to (Item 9), the user is given a level according to the number of times the game has been played, and the upper limit value set for each user is The execution of the step of executing the play part based on the deck which is increased as the level increases and the total is over may be permitted only to users below a predetermined level.

  (Item 19) In any one of the items (Item 1) to (Item 9), the play part is composed of a plurality of quests for each difficulty level of play, based on the deck whose total amount is exceeded, The execution of the step of performing the play part may be permitted only for the quests having a predetermined level of difficulty or less.

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

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

DESCRIPTION OF SYMBOLS 1 game system, 2 networks, 10, 20 processors, 11, 21 memories, 12, 22 storages, 13, 23 communication IF (operation part), 14, 24 input / output IF (operation part), 15 touch screen (display part, Operation unit), 17 camera (operation unit), 18 distance measuring sensor (operation unit), 100 user terminals (information processing apparatus), 110, 210 control unit, 111 operation reception unit, 112 display control unit, 113 UI control unit, 114 animation generation unit, 115 deck formation unit, 116 transition preparation unit, 117 quest progress 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 (12)

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 may include the processor
Receiving from the user an input operation for incorporating one or more objects into the deck, and executing a play preparation part storing the deck generated according to the input operation in the memory;
Determining whether a sum of costs associated with each of the one or more objects incorporated into the deck exceeds a predetermined upper limit;
Executing a play part in which the user plays the game based on the game program using the deck;
The step of executing the play part may include determining that the sum exceeds the upper limit value.
Imposing a penalty at which the progress of the play part is disadvantageous to the user at a predetermined timing during the progress of the play part;
Displaying at least one of notification that the penalty is imposed and that the penalty has been imposed on the display unit at a predetermined timing in progress of the play part. The step of imposing the penalty is
Adversely affecting ally objects incorporated into the deck of the user;
The game program according to claim 1, further comprising at least one of: an action that is advantageous to an enemy object that is hostile to the ally object. The step of imposing the penalty is
Reducing parameters that define the performance of the friend object;
The game program according to claim 2, comprising at least one of enhancing a parameter that defines the performance of the enemy object. The adverse effects include the fact that the friend object falls into an abnormal state in which the performance of the friend object is not exhibited as prescribed.
The step of imposing the penalty is
Putting the friend object into the abnormal state;
3. The method according to claim 2, further comprising at least one of a time required for progressing the play part to be longer than a predetermined time until the abnormal state is released, when the ally object is in the abnormal state. Or the game program described in 3. The play part is advanced by causing one or more of the teammate objects and one or more of the enemy objects to compete.
The step of imposing the penalty is
The game program according to any one of claims 2 to 4, comprising assisting the enemy object during a match.   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 manner in line with the context of the game.   The game program according to claim 6, wherein in the notification, an adverse effect on an ally object incorporated in the deck of the user based on the penalty is represented by an attack of an enemy object which is hostile to the ally object. The game program may include the processor
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, when it is determined that the total exceeds the upper limit value, a warning indicating that the penalty is exceeded without displaying the implemented result, and based on the excess. The game program according to any one of claims 1 to 7, wherein at least one of a notice that the penalty is to be implemented in the play part is displayed. In the step of executing the play part,
Following the step of imposing the penalty, performing the step of displaying the notification, or
The game program according to any one of claims 1 to 8, wherein the step of imposing the penalty is executed following the step of displaying the notification. The predetermined upper limit value is set for each user, and the memory is configured to store the predetermined upper limit value set for the user,
The game program according to any one of claims 1 to 9, wherein the predetermined upper limit value is increased when a predetermined condition is satisfied by the user playing the game. A method of executing a game program,
The game program is executed by a computer including a processor, a memory, an operation unit, and a display unit.
The method comprises:
Receiving from the user an input operation for incorporating one or more objects into the deck, and executing a play preparation part storing the deck generated according to the input operation in the memory;
Determining whether a sum of costs associated with each of the one or more objects incorporated into the deck exceeds a predetermined upper limit;
Executing a play part in which the user plays the game based on the game program using the deck;
The step of executing the play part may include determining that the sum exceeds the upper limit value.
Imposing a penalty at which the progress of the play part is disadvantageous to the user at a predetermined timing during the progress of the play part;
Displaying at least one notification that the penalty has been imposed and that the penalty has been imposed on the display unit at a predetermined timing in progress of the play part. An information processing apparatus,
The information processing apparatus is
A storage unit for storing a game program;
A control unit configured to control an operation of the information processing apparatus by executing the game program;
Operation unit,
And a display unit,
The control unit
Receiving from the user an input operation for incorporating one or more objects into the deck, and executing a play preparation part for storing the deck generated according to the input operation in the storage unit;
Determining whether a sum of costs associated with each of the one or more objects incorporated into the deck exceeds a predetermined upper limit;
Executing a play part in which the user plays the game based on the game program using the deck;
When it is determined that the total exceeds the upper limit value when executing the play part, the control unit executes the play part.
Imposing a penalty at which the progress of the play part is disadvantageous to the user at a predetermined timing during the progress of the play part,
An information processing apparatus, which displays, on the display unit, a notification that at least one of the penalty and the penalty is imposed, at a predetermined timing during the progress of the play part.

Images