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

Abstract

To respond to a request of a user who wants to acquire a desired game medium without damaging the amusement of a lottery.SOLUTION: A game program (131) causes a processor (10) to execute: a step (S4) for making a user acquire a first right in digital data to be used to acquire one or more game media usable in a game based on the game program by satisfying a first condition in the game; a step (S10) for making the user acquire a second right in the digital data by satisfying a second condition in the game; and a step (S7) for executing a lottery a plurality of times in accordance with the use of one of the first right and the second right to specify a game medium to be won per each time. The step for specification causes a game medium with an attribute being the same as an attribute designated by the user associated therewith to be won at least one time among the lotteries of the plurality of times executed on the basis of the second right.SELECTED DRAWING: Figure 4

Description

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

  Conventionally, a game played by a user using a game medium such as a character card is known. The game medium is digital data processed by a computer that executes the game program while the game program of the game is being executed. Specifically, it is the above-described character card (hereinafter referred to as a character) or an item for favorably progressing the game. The game media is provided to the user for a fee or free of charge as follows.

  For example, in-game values having a monetary value on games (for example, valuable media such as virtual currency, coins, jewelry, crystals, and points) are widely sold to users. Then, by providing the user with the valuable medium and consuming the value, various services (such as giving a game medium) used on the game are provided to the user. Non-Patent Document 1 discloses a technology capable of providing a lottery game service for allowing a user to acquire a character in exchange for a virtual currency held by the user.

  In addition, for example, when a user plays a game (for example, when a quest or battle is played a predetermined number of times, or when a predetermined task is cleared, etc.), the game medium is free of charge as a reward to the user. Acquiring is widely done.

Professional Baseball Spirits A Strategy Summary Directory, “[Prospiri A] Should the Team Confirm Scout be Rotated? The 10th Time is S Rank Probability”, [online], June 30, 2017, Professional Baseball Spirits A Strategy Summary Summary, [Search on March 12, 2018], Internet (URL: http://xn--a-39tzcn0z5bh0kza6q4a7209hpx1boi3b6letm2ly6i.com/post-15148/)

  In general, in a game developed with the intention of allowing the user to play for a long time, it is important how to deal with the problem that the user gets bored with the game. In particular, in a game in which the above characters are organized into a deck and enjoyed, various types of characters are prepared to give the user the pleasure of acquiring the characters and the pleasure of organizing the team with the acquired characters. Is required.

  However, the above-described conventional technology has the following problems. Specifically, in the game described in Non-Patent Document 1, a game medium having a desired attribute (player card belonging to a specific team) can be obtained with certainty, so it is desired to obtain a game medium having a desired attribute. However, there is a problem that the interest and playability of the lottery are impaired. Specifically, the expectation, tension, or excitement that the user will have before waiting for the lottery result is significantly reduced. In addition, for example, even if the user wins a target player card after winning, the degree of joy or uplifting feeling at that time is significantly reduced.

  An object of one aspect of the present disclosure is to meet a user's desire to obtain a desired game medium without impairing the interest of lottery.

  The game program according to the present disclosure is executed by a computer including a processor and a memory. The game program has a first right among the digital data used to acquire one or more game media usable in a game based on the game program, and the first condition is satisfied in the game. And a step of causing the user to acquire the second right of the digital data when the second condition is satisfied in the game, and the first right or the second right In accordance with the use of one, the lottery is executed a plurality of times, and the step of specifying the game media to be won each time is executed, and the step of specifying is a plurality of times executed based on the second right At least once in the lottery, a game medium associated with the same attribute as the attribute designated by the user is won.

  According to one aspect of the present disclosure, there is an effect that a user's desire to obtain a desired game medium can be met without impairing the interest of lottery.

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 figure which shows the specific example of the external appearance of a pack. It is a flowchart which shows the flow of the process performed in a game system based on the game program which concerns on this embodiment. It is a figure which shows an example of the data structure of deck detailed information. It is a figure which shows an example of the data structure of deck outline information. It is a figure which shows an example of a deck selection screen. It is a figure which shows an example of a fielder deck organization screen. It is a figure which shows an example of a pitcher deck organization screen. It is a figure which shows the specific example of a pack notification screen. It is a figure which shows the specific example of a pack operation screen. It is a figure which shows the other specific example of a pack operation | use screen. It is a figure which shows the specific example of a character notification screen. It is a flowchart which shows the flow of the process performed in a game system based on the game program which concerns on this embodiment. It is a figure explaining the mechanism which purchases a box and acquires a card. It is a figure which shows an example of the data structure of management data. It is a figure which shows the specific example of a ticket acquisition screen. It is a figure which shows the specific example of a menu screen. It is a figure which shows the specific example of a box purchase screen. It is a figure which shows the specific example of an unpacking result screen. It is a figure which shows the specific example of a final result screen. It is a flowchart which shows the flow of the process performed in a game system based on the game program which concerns on this embodiment. It is a figure which shows an example of the data structure of a lottery database. It is a figure which shows an example of the data structure of a probability table. It is a flowchart which shows the flow of the pack opening process which a user terminal or a server performs.

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

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

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

  The user terminal 100 (computer, information processing apparatus) may be a mobile terminal such as a smartphone, a feature phone, a PDA (Personal Digital Assistant), or a tablet computer. The user terminal 100 may be a game device suitable for game play. As illustrated, the user terminal 100 includes a processor 10, a memory 11, a storage 12, a communication interface (IF) 13, an input / output IF 14, a touch screen 15 (display unit), a camera 17, and a distance measuring sensor 18. With. These components included in the user terminal 100 are electrically connected to each other via a communication bus. Note that the user terminal 100 may include an input / output IF 14 capable of connecting a display (display unit) configured separately from the user terminal 100 main body instead of or in addition to the touch screen 15.

  Further, as shown in FIG. 1, the user terminal 100 may be configured to be able to communicate with one or more controllers 1020. For example, the controller 1020 establishes communication with the user terminal 100 in accordance with a communication standard such as Bluetooth (registered trademark). The controller 1020 may have one or more buttons and the like, and transmits an output value based on a user input operation to the buttons and the like to the user terminal 100. The controller 1020 may include various sensors such as an acceleration sensor and an angular velocity sensor, and transmits output values of the various sensors to the user terminal 100.

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

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

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

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

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

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

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

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

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

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

<Game overview>
As an example, the game system 1 is a system for executing a communication person-to-person battle game in which each user terminal 100 (client) operated by each user communicates to advance a battle based on a game program.

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

  As an example, the game system 1 executes a communication interpersonal battle type baseball game (hereinafter, referred to as a main game or a main baseball game) that advances a baseball game as a communication interpersonal battle game.

  In the baseball game executed by the game system 1, each team is operated by the first user terminal 100 and the second user terminal 100 that communicate via the server 200 (information processing apparatus). A team is created by the user incorporating one or more objects into the deck. The object is digital data that has some effect on the progress of the battle in this game. The strength of each user's deck constituted by one or more objects affects at least the progress of the battle. The object is, for example, a character, and the character is, for example, a baseball player who participates in a baseball game and confronts the player of the opponent team, or a team that supports the player so that the player can advance the game advantageously. Is the mascot. In this game, players and mascots are represented in the form of cards as an example. In this game, “affiliation team” indicating the team to which the character belongs is set for the player and the mascot as attributes.

  In the baseball game, when the user plays a match of the person, the evaluation result (the result of the match such as win / loss, record, score) is output. In the game, a reward is given for the user playing a battle. The reward is, for example, right data for giving a user the right to acquire one or more of the above objects. Specifically, it is a pack in which a predetermined number of players' cards are enclosed. By opening the pack, the user can obtain the card enclosed in the pack. Then, the obtained card is incorporated into the deck, and the player represented by the card can be used in the battle. The pack may contain a mascot card. The user can incorporate the mascot card obtained from the pack into the deck, assist the player who is also incorporated into the deck, and advance the battle advantageously.

  In this baseball game, for example, a pack given as a reward is not opened only by being acquired by the user. A pack can be opened only when it is used in the game. As a specific example, when a pack point counted in association with the pack reaches a predetermined value after being set in a slot owned by the user, it can be opened. Each time a user plays a battle, the pack points are given to the user as a reward for playing the battle, and are allocated to each pack owned by the user.

  The user gets as many packs as he plays a match and also gets many pack points. That is, the user can open more packs and possess more cards (characters such as players or mascots) as he plays more battles. Then, by incorporating a stronger player or a high-performance mascot into the deck, the entire deck can be strengthened and the battle can be advantageously advanced.

  This baseball game progresses while the team's offense and defense are swapped for each inning. In the following description, when it is necessary to distinguish between the user terminal 100 operating the defensive team and the attacking user terminal 100 on the front or back of a certain inning, the former is the pitching user terminal 100A and the latter is the hit This is referred to as a side user terminal 100B. When it is not necessary to distinguish between the two, the user terminal 100 is simply referred to. A user of the pitching user terminal 100A is referred to as a pitching user, and a user of the batting user terminal 100B is referred to as a batting user. However, when it is not necessary to distinguish between the two users and when the distinction is clear, the users are simply referred to as users. The pitching user operates the pitching by the pitcher character using the pitching user terminal 100A, and the attacking user operates the hit by the batter character using the hitting user terminal 100B.

  The pitching user terminal 100A determines a pitching result according to the pitching operation received from the pitching user, generates data including the pitching result (throwing result D1 shown in FIG. 1), and transmits it to the server 200. The pitching result D1 is transmitted via the server 200 to the opponent's hitting user terminal 100B. The pitching operation is an operation performed by the pitching user on the input unit 151 of the pitching user terminal 100A in order to cause the pitcher character to pitch.

  The batting user terminal 100B determines the batting result according to the batting operation received from the batting user, generates data including the batting result (the batting result D2 shown in FIG. 1), and transmits it to the server 200. The batting result D2 is transmitted to the pitching user terminal 100A of the opponent via the server 200. The batting operation is an operation performed by the batting user on the input unit 151 of the batting user terminal 100B in order to cause the batter character to hit the ball.

  In the baseball game, when the user does not wish to control the character himself, the user can operate the user terminal 100 to notify the server 200 of the fact. When receiving such a notification from the user terminal 100, the server 200 determines the action result (throwing result or hitting result) of the character based on various information relating to the ongoing battle according to the game program. Then, the determined operation result is transmitted to the user terminal 100 of the opponent. That is, the server 200 controls the character instead of the user terminal 100.

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

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

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

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

  In the present embodiment, the program may be a game program for realizing the game by the user terminal 100. Alternatively, the program may be a game program for realizing the game by cooperation between the user terminal 100 and the server 200. In addition, the game implement | achieved by cooperation with the user terminal 100 and the server 200 may be a game performed on the browser started in the user terminal 100 as an example. Alternatively, the program may be a game program for realizing the game by cooperation of a plurality of user terminals 100. The various data includes data relating to the game such as user information and game information, and instructions or notifications transmitted / received between the user terminal 100 and the server 200 or between the plurality of user terminals 100.

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

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

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

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

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

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

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

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

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

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

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

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

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

  The server 200 communicates with each user terminal 100 and has a function of supporting the user terminal 100 to advance the game. For example, the user terminal 100 provides necessary information when playing a battle, sells a valuable medium, or specifies a game medium to be provided to the user by lottery. When the game is a multiplayer game, the server 200 may have a function of communicating with each user terminal 100 participating in the game and mediating exchanges between the user terminals 100. The server 200 functions as the control unit 210 and the storage unit 220 through the cooperation of the processor 20, the memory 21, the storage 22, the communication IF 23, the input / output IF 24, and the like.

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

  In the present embodiment, as an example, the user information 133 includes an item of “designated team”. In this game, as an example, the user designates one favorite team as a designated team from among professional baseball teams (12 teams) that exist at the start of the game. The item of the designated team is referred to by the battle progress unit 115. For example, the battle progress unit 115 may determine the design of a team logo representing the user's team based on the user's favorite designated team, or may be set to a character incorporated in the designated team and the deck. The strength of the deck may be determined based on the attribute (for example, the team that belongs).

  The designated team may be arbitrarily changed by the user after the game is started, and can be changed by the user when certain conditions are satisfied as a result of the user playing this game. Also good.

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

  The control unit 210 functions as a battle support unit 211, a card providing unit 212, a charging processing unit 213, and a box processing unit 214 in accordance with the description of the game program 131. The control unit 210 can also function as other functional blocks (not shown) in order to support the progress of the game on the user terminal 100 according to the nature of the game to be executed.

  The battle support unit 211 supports the user terminal 100 to advance a battle in the communication battle game. Specifically, in the case of an interpersonal battle, the battle support unit 211 communicates with each user terminal 100 that battles to mediate the exchange between the user terminals 100. Furthermore, the battle support unit 211 executes matching control for synchronizing the opponents, synchronizing the progress of the battle, and the like. Moreover, the battle | competition support part 211 calculates a reward based on the result of a battle | competition, notifies the content of the reward to the user terminal 100, and gives a reward to a user.

  In response to a request from the user terminal 100, the card providing unit 212 provides a user with a game medium that can be used in a battle. In the present embodiment, the card providing unit 212 provides a character that can be incorporated into a deck and used in a battle. In the present embodiment, the card providing unit 212 identifies the character to be acquired by the user by opening the pack and executing a lottery based on the type of the pack. The type of pack will be described in detail later.

  In the baseball game according to the present embodiment, as an example, a method for the user to acquire a character is to open the acquired pack. In this baseball game, for example, there are two methods for opening a pack and allowing a user to acquire a character. The first method is a method in which the card providing unit 212 specifies a character based on the pack based on the operation of the pack (first right) given as the above-described reward, and provides the character. is there. In the second method, based on the fact that the user has consumed valuable media, that is, charged, the card providing unit 212 allows the user to own the pack, identifies the character based on the pack, It is a method to provide.

  The latter pack obtained in exchange for a valuable medium is preferably of a type in which a stronger or more valuable character is easier to win than the former pack given as a reward. In the present embodiment, the former pack, that is, the pack given to the user as a reward for playing the interpersonal battle, which is the main element of the baseball game, is referred to as a standard pack (first right). The latter pack, that is, a pack that can be obtained only when the user charges is referred to as a special pack (second right). When it is not necessary to distinguish the two, they are simply referred to as a pack.

  In this embodiment, as an example, the special pack is sold to the user in a state of being packed in a box (right collection medium). The box is a game medium for packing a plurality of packs including at least one special pack. The user can obtain a special pack by purchasing the box. The box may contain a standard pack.

  In the present embodiment, it is assumed that the special pack is not provided as a play reward for interpersonal battles, and is acquired only from a box purchased by the user for purchase.

  In response to the service request from the user terminal 100, the billing processing unit 213 performs billing processing in return for providing the requested service. As an example, the billing processing unit 213 stores, in the storage unit 220, a billing amount for charging money to a user associated with the user identification information and associated with the user identification information.

  In this embodiment, as an example, the service to be charged by the charging processing unit 213 is a service that allows the user to acquire one or more game media that can be used in this game. As an example, the game medium is a character that performs a battle in accordance with a user operation. Furthermore, in this embodiment, a character as a game medium is acquired by the user as digital data resembling a card. By acquiring the character by the user, the user can organize the character into a team and use it in a battle. Specifically, in the present embodiment, a service for unpacking a box in which a plurality of the above-described packs are packed and allowing the user to obtain a card obtained by opening each pack is a chargeable object.

  The box processing unit 214 executes a process of unpacking the box, and instructs the card providing unit 212 to open each pack packed in the box.

  In the present embodiment, as an example, the “process for unpacking a box” is a process for determining a predetermined number of types of a plurality of packs to be linked to a box and transmitting the types of each pack to the card providing unit 212. The box processing unit 214 may determine the type of pack by lottery.

  For example, for the type of pack, the box processing unit 214 (1) distinguishes between standard packs and special packs, (2) presence / absence of added value (details will be described later) for increasing the winning probability of a character having a specific attribute, Packing by determining at least one item of the type of added value and (3) a grade indicating the ease of winning a character whose value on the game is a predetermined value or more by lottery The type of may be determined.

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

  The control unit 110 serves as an operation reception unit 111, a display control unit 112, a user interface (hereinafter referred to as UI) control unit 113, an animation generation unit 114, a battle progress unit 115, and a card acquisition unit 116 in accordance with the description of the game program 131. Function. The control unit 110 can also function as other functional blocks (not shown) in order to advance the game according to the nature of the game to be executed.

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

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

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

  Further, during the battle, the display mode of the UI parts for supporting the pitching operation or the batting operation is controlled. Examples of UI parts that support the batting operation include a timing hint object that indicates a favorable timing of the batting, a ball thrown from the pitcher character, a direction hint object that indicates a change in the direction of pitching, and an estimated pitching position. There are a position hint object, a meet cursor for determining the hit of the bat and the ball, and the like. Examples of UI objects that support a pitching operation include a ball type selection object, a course presentation object, a course selection object, and a pitching timing object.

  The animation generation unit 114 generates an animation indicating the motion of each object based on the control mode of various objects including the above-described UI parts. For example, a pitcher's throwing animation, a batter's batting animation, a bat's bat animation, a ball thrown by the pitcher, a ball hit by the batter, a runner stealing animation, etc. May be. The above-mentioned pitcher, batter, and runner are defined based on cards (players) organized in a deck.

  The display control unit 112 outputs a game screen on which the processing results executed by the above-described elements are reflected on the display unit 152 of the touch screen 15. The display control unit 112 may display a game screen including the animation generated by the animation generation unit 114 on the display unit 152. Further, the display control unit 112 may draw the UI object described above by superimposing it on the game screen.

  The battle progress unit 115 transmits / receives data to / from the server 200 to advance the battle with the opponent user. The battle progress unit 115 also controls the UI control unit 113, the animation generation unit 114, and the display control unit 112 to provide the user with the above-described UI necessary for the user to play the baseball game. The battle progress unit 115 causes the UI control unit 113 or the animation generation unit 114 to generate a game screen including UI parts. The battle progress unit 115 causes the display control unit 112 to display the generated game screen on the display unit 152. Thereby, UI for a user to play this baseball game is implement | achieved.

  Therefore, the game screen, which will be described in detail later with reference to the drawings, includes UI parts generated by the UI control unit 113, animations generated by the animation generation unit 114, or a combination thereof. The game screen generated by the UI control unit 113 or the animation generation unit 114 is displayed on the display unit 152 of the user terminal 100 by the display control unit 112. The display control unit 112, UI control unit 113, and animation generation unit 114 execute processing for displaying a game screen on the display unit 152 under the control of the battle progress unit 115. Therefore, the description that “the battle progress unit 115 displays the game screen on the display unit 152” means that “the battle progress unit 115 controls the UI control unit 113 or the animation generation unit 114 to generate a UI part or an animation. The display control unit 112 is controlled to display the game screen including the generated UI part or animation on the display unit 152 ”.

  The card acquisition unit 116 cooperates with the server 200 to cause the user to acquire a character card. As an example, the card acquisition unit 116 operates a standard pack given to the user. Specifically, the card acquisition unit 116 makes a transition to a state where the standard pack can be opened by accumulating pack points for each standard pack and storing them up to a predetermined value. More specifically, in the present embodiment, the card acquisition unit 116 arranges a card pack in a slot that allows addition of pack points as an example. In this embodiment, a predetermined number of slots are provided to the user. For example, by default, three slots are defined in the game information 132 in association with the user. The card acquisition unit 116 can add a pack point in association with the card pack by arranging the card pack in the slot. When the card acquisition unit 116 adds the pack points, and the condition assigned to the card pack is satisfied, that is, the total of the pack points reaches the predetermined value indicated in the above-described conditions. The card pack is ready to be opened. The pack points may be given to the user as a reward for a battle, for example, in the same manner as the card pack.

  In the present embodiment, the card pack can be stored by placing the card pack in the slot. That is, the slot is a requirement that allows the card acquisition unit 116 to add pack points and allows the card pack to transition to a state where it can be opened. Furthermore, another requirement may be added to the addition of pack points.

  Next, the card acquisition unit 116 requests the server 200 to specify the character to be acquired by the user by consuming the pack. The card acquisition unit 116 acquires the character specified by the server 200 in response to the request from the server 200 and causes the user to acquire the character.

  Acquiring a character to a user may be, for example, shifting the status of the character, which is digital data managed in association with the user, from unusable to usable. Alternatively, the digital data corresponding to the character card may be stored in at least one of the memories (memory 11 and memory 21) included in the game system 1 in association with the user identification information or the user ID. .

  When acquiring a character based on the standard pack, the card acquisition unit 116 consumes the standard pack and transmits the type of the standard pack to the server 200 so as to specify the character to be acquired by the user. Request to server 200.

  When acquiring a character in accordance with the user's charging operation, the card acquisition unit 116 requests the server 200 to unpack the box. In response to the request, the server 200 unpacks the box and specifies a character based on a plurality of packs packed in the box. The card acquisition unit 116 acquires characters specified for a plurality of packs from the server 200 and causes the user to acquire each character.

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

<Pack type>
In this embodiment, there are a plurality of types of packs. Specifically, packs are classified into a plurality of grades according to the ease of winning a character having a high value in favor of the game. Furthermore, the packs are classified into a plurality of types according to the acquisition route or the winning object in the lottery.

  In the present embodiment, probability information may be set in the pack. For example, the probability information is set for each type of pack and for each lottery based on the pack. The probability information is, for example, a probability table indicating the winning probability of the character. For example, the storage unit 120 stores a probability table (probability information) to be referred to for each type of pack and each lottery. The card providing unit 212 executes each lottery based on the probability table for each time set in the used pack.

  Specifically, the probability table indicates the probability that a character wins in the above-described lottery. In the present embodiment, the character is set with a rarity level indicating the above-mentioned high value. For example, SS, S, A, B, and C are assigned in descending order of rarity level (for example, ability is high). There are five types. In the present embodiment, basically, in the lottery, the higher the rarity level, the lower the probability of winning. That is, the rarity level is also an index indicating difficulty in obtaining. In this embodiment, in the probability table set for each pack, the probability that the character wins is set for each rarity of the character.

  In the present embodiment, the expected value indicating the ease of winning a character with a high degree of rarity may be different depending on the type of pack. In this embodiment, the expected value indicates the ease of winning a character with a high degree of rarity. In the present embodiment, as an example, when “expected value is high (low)”, it means that the probability of winning a character set with SS and S rarity is high (low). In the present embodiment, the expected value is specified based on the winning probability for each rarity in the probability table set for each pack.

  In the present embodiment, a grade corresponding to the expected value may be set for the pack. The higher the expected value, the higher the grade. For example, four grades of black, gold, silver, and bronze may be set in order from the highest grade. In this embodiment, a probability table is set for each pack so as to correspond to an expected value corresponding to the grade set for the pack. Specifically, the probability table of each grade is set so that the SS or S rare character from the black pack wins with the highest probability, and the probability becomes lower as the grade goes down. As an example, the probability of winning an SS or S rarity character (high rarity game media) is 5% for black, 3% for gold, 1% for silver, and 0. The probability table may be set to be 1%. In addition, the winning probability after the rarity A in each grade may be appropriately set so as to increase as the rarity decreases, or may be set uniformly. Further, a winning probability may be set so that B and C characters with low rarity are not won from packs of gold of higher grade or higher.

  Furthermore, in this embodiment, as described above, packs are classified into several types. First, as described above, the packs are classified into either a standard pack or a special pack depending on the acquisition route. In addition, lottery added value is set for some types of packs, and packs are further classified into several types according to the added value. The pack in which the added value of the lottery is set refers to a pack to which the added value of increasing the winning probability of a character having a specific attribute is added, for example.

(Limited time)
The type “limited period” has an added value (third addition) that a limited character (limited game media) that is won only within a limited period may win or is likely to win this type of pack. (Value) indicates that the pack is added. As an example, the probability table of each pack may be set so that the limited character wins only from the limited-time type pack. Specifically, a probability table in which the winning probability of the limited character is higher than 0% is set only for the limited time type pack.

  In this embodiment, as an example, the added value of “limited time” is set for both standard packs and special packs, but is set only for packs of black or higher grades.

(Rareness S or higher confirmed)
The type “Rareness S or higher is confirmed” means that a character (high rarity game medium) having a rarity level of S or higher is won in at least one of a plurality of lotteries executed based on the pack of this type. This indicates that the pack is added with the added value (second added value) that it is determined to be performed. As an example, the probability table of this type of pack is set so that the winning probability of a character having a rarity level A or less is 0% only in the final lottery.

(Own team confirmed)
With the type “Own Team Confirm”, it is confirmed that a character belonging to the designated team (same attribute game medium) wins at least one of a plurality of lotteries executed based on the pack of this type. It indicates that the pack has an added value (first added value) added. As an example, the probability table of this type of pack is set so that the characters belonging to the user's designated team are always won only in the final lottery.

  In the present embodiment, as an example, the added values of “determined by rarity S or higher” and “determined own team” are set only for special packs obtained by charging.

  A plurality of added values described above may be combined and set in one pack. For example, a pack of “Rareness S or higher fixed” + “Limited time” type pack is determined that a character with a rarity S or higher will win at least once, and the probability that a limited character will win It is a pack in which the added value of being higher than that of the type is set. In addition, for example, a pack of the “Own team rarity S or higher” type pack probability table of this type so that a character (same attribute game medium) with a rarity S or higher and belonging to the user's designated team is won. Is set.

  The pack may be presented to the user in a different manner for each type so that the grade and type can be seen before opening. FIG. 3 is a diagram illustrating an example of the appearance of a pack having a different display mode for each type. When the pack is presented on the display unit 152 of the user terminal 100, it is preferable that the size, the color, the shape, the decoration, or the design such as the character is different for each type so that the user can identify the pack. . As a result, the user knows the grade and type of the pack he / she owns before opening, guesses the probability that a character with a rarity level S or higher can be obtained, determines whether or not a limited character can be obtained, It is possible to estimate the probability that a character of a designated baseball team can be acquired. Thereby, it becomes possible to operate a pack strategically, and the interest property of a game can be improved.

<Process overview>
The game system 1 according to the present embodiment generally includes at least a standard pack (first right) among digital data used to acquire one or more characters (game media) that can be used in the game. A step (step S4 to be described later) acquired by the user when the first condition is satisfied in the game and a special pack (second right) of the digital data are satisfied in the game. A step (step S10 to be described later) to be acquired by the user and a step of executing a lottery multiple times in response to the use of one standard pack or special pack and specifying a character to be won each time ( Step S7) to be described later is executed. In the specifying step, the game system 1 wins a character associated with the same attribute as the attribute designated by the user for at least one of a plurality of lotteries executed based on the special pack.

  The first condition described above is, for example, that the user plays a battle game. The second condition described above is, for example, that the user performs a charging operation for purchasing a special pack.

  FIG. 4 is a flowchart for explaining the flow of processing until the game system 1 causes the user to acquire a character in the baseball game. In general, at least one of the user terminal 100 and the server 200 included in the game system 1 is configured to execute each step shown in FIG. 4 by executing a game program.

  In step S1, when an instruction to start a battle is input from the user via the game screen (for example, the menu screen 610 shown in FIG. 18), the game system 1 (for example, the battle progress unit 115) Proceed from step S1 to step S2.

  In step S2, the game system 1 advances the battle.

  In step S3, if the battle is over, the game system 1 proceeds from YES in step S3 to step S4. Before the battle is over, the game system 1 returns from step S3 NO to step S2 and continues step S2.

  In step S4, the game system 1 allows the user to own the standard pack. The game system 1 may further grant a pack point and a box purchase ticket (hereinafter referred to as a ticket) certifying that the user has a right to purchase a box as a reward. The game system 1 may determine the content of the reward according to the results of the user in the battle. For example, the battle progress unit 115 or the battle support unit 211 may allow the user to own a standard pack of a better grade as the score is better, or may give more pack points as the score is better. It is good also as giving a ticket (3rd right) when it is good.

  In step S5, the game system 1 (for example, the card acquisition unit 116) operates a standard pack that the user has. The specific processing contents of the pack operation processing will be described in detail later with reference to another drawing.

  In step S6, when the operation shifts to a state where the standard pack can be opened, the game system 1 proceeds from YES in step S6 to step S7. On the other hand, when the standard pack cannot be opened, the standard pack is not used. In this case, the game system 1 proceeds from NO in step S6 by skipping step S7, and ends the series of processes.

  In step S <b> 7, the game system 1 (for example, the card providing unit 212) executes a character acquisition process for allowing the user to acquire a character using the standard pack that can be opened. Specifically, the game system 1 opens the standard pack and specifies the character to be acquired by the user based on at least the grade of the standard pack. The character is specified, for example, when the game system 1 executes a lottery based on the standard pack grade. The game system 1 causes the user to acquire the winning character. That is, the character won in association with the user identification information is stored in the storage unit 120 or the storage unit 220 as the user's possessed card. The specific processing content of the character acquisition processing will be described in detail later with reference to another drawing.

  In step S8, when an instruction to purchase a box is input from the user via the above-described game screen, the game system 1 (for example, the charging processing unit 213) proceeds from step S8 to step S9.

  In step S9, the game system 1 executes a billing process for purchasing the box. Specific processing contents of the billing process will be described in detail later with reference to another drawing.

  In step S10, the game system 1 (for example, the box processing unit 214) causes the user to own the purchased box. At least one of the packs associated with the box is a special pack. In the present embodiment, each pack in the box changes to a usable state in response to the box being owned by the user, that is, can be opened.

  Specifically, in step S6, the game system 1 unpacks the box, determines the grade of each pack packed in the box, and makes a transition to a state where each pack can be opened. Here, the pack grade and the pack type (for example, standard pack or special pack) may be determined by lottery. Then, the game system 1 proceeds from YES in step S6 to step S7.

  In step S <b> 7, the game system 1 (for example, the card providing unit 212) performs character acquisition processing for opening the pack in the box and causing the user to acquire a character.

<About decks and characters>
First, with reference to FIGS. 5 to 9, how the character acquired by the above-described method is used on the game will be described. This baseball game is a battle game in which a player's team composed of one or more characters owned by the user and the opponent team are battled. In this embodiment, a character becomes a member of the own team by being incorporated in a deck possessed by the user, and can participate in a battle.

(About the deck)
The deck held by the user is handled in the game system 1 as deck information. The data structure of the deck information will be described in detail later. The deck information is data for managing information related to a deck owned by the user. The deck information is stored as game information 132 in the storage unit 120. The deck information may also be stored in the storage unit 220 of the server 200. The deck information is referred to and used by the battle progress unit 115 when the battle progresses.

  In the present embodiment, as an example, the deck information includes deck detailed information and deck summary information. The deck detailed information is a collection of individual information of each character constituting the deck. The deck summary information is information related to the entire team organized by placing each character on the deck.

  In this game, for example, the user may be able to have two types of decks having different properties, that is, a first deck and a second deck. The first deck is, for example, a character priority deck. The first deck has a property that the strength of the deck increases as more characters with high ability are incorporated regardless of the user's designated team and the team to which the character belongs. By providing users with the first deck of this nature, they enjoy the pleasure of acquiring strong characters, the pleasure of collecting favorite characters, and the pleasure of organizing their own dream team with the acquired strong characters. Can be given to the user.

  The second deck is, for example, a baseball team priority deck. The second deck has a property that the strength of the deck increases as more characters belonging to the user's designated team are incorporated. By providing the user with the second deck having such a property, the joy of acquiring a character belonging to the designated team that is his favorite, the pleasure of collecting the characters belonging to the designated team, and the designation by the acquired character The pleasure of organizing a team such as a team can be given to the user.

(About characters)
In the present embodiment, the user can incorporate two types of characters, a player and a mascot, in the deck he possesses. A player is an object arranged in a virtual space in which a battle progresses. The player performs an action determined in the virtual space based on the attribute and ability value set for the player and, in some cases, based on the input operation of the user. That is, the player is a direct object that directly affects the progress of the battle. The mascot brings the effect determined based on the attribute and ability value set in the mascot individually to the player as an object directly or to the entire deck. In this way, the mascot assists the player so that the player can advance the battle advantageously. In other words, the mascot is an indirect object that indirectly acts on the progress of the battle by exerting an advantageous effect on the player who performs the action during the battle.

  In the present embodiment, not only players but also mascots can be incorporated into both the first deck and the second deck. It is preferable that the effects exhibited when the mascot is incorporated in the deck, the conditions for exhibiting the effects, and the like differ according to the properties of each deck. This allows the user to consider carefully which deck to use and how to place players in order to more effectively demonstrate the effects of the mascot on hand. As a result, the strategy of deck organization is enhanced and the interest of the game can be improved.

  Furthermore, in this embodiment, each character may be classified based on the character type. The character type is also set for each character as one item of the attribute. For example, players are classified as “fielders” or “pitchers” based on their defensive positions. The above-described classification based on the position is referred to as a position type (first type). Mascots are classified as “male” or “female” based on gender (second type).

  In this embodiment, the effect of a mascot may be demonstrated with respect to the player who has the position classification corresponding to the sex of a mascot. As an example, the ability value of a player incorporated in a deck is corrected upward when a gender mascot corresponding to the position type of the player is incorporated in the deck. More specifically, if the “fielder” classification corresponds to the “male” classification, and the “pitcher” classification corresponds to the “female” classification, the male mascot You may demonstrate the effect which raises the ability value of a fielder.

  In the present embodiment, the term “position” indicates one role played by one character in the deck, and is a minimum unit element constituting the deck. The “position” and the character are linked one-on-one. A deck may have multiple positions with the same role. As an example of “position”, a defensive position in baseball is assumed, but “position” should not be interpreted narrowly only as a defensive position in baseball, but “support a player”, which is carried by one mascot. This role is also included in one of the “positions”.

(About ability values)
In the baseball game, an ability value is set for each character. The ability value includes a physical ability parameter and an overall parameter. The physical ability parameter is a value representing the physical ability of the player to be exhibited in the battle. Specifically, the physical ability parameter is obtained by quantifying a player's skill for each skill required in baseball. In the present embodiment, for example, the physical ability parameters include hitting force, hitting force, fastest ball speed, ball control force, changing ball force, running force, defense force, pitching speed, and pitching accuracy.

  On the other hand, the overall parameter is a numerical value of the overall strength of the character regardless of the skill and skill, and is set for each character card. The general parameter is referred to by the battle progress unit 115 and the battle support unit 211 during the battle, and affects the progress of the battle. Specifically, the baseball game is a specification in which the battle progresses more advantageously as the overall parameters of the incorporated characters are higher in both the first deck and the second deck.

  The general parameters set for each player may be referred to when the pitcher and the batter face each other. For example, the battle progress unit 115 compares the batter's total parameter with the pitcher's total parameter at the start of one at-bat. Then, the physical ability parameter of the player with the lower overall parameter is negatively corrected during the time when the batting is progressing. For example, when the pitcher loses in comparison of the overall parameters, the battle progress unit 115 subtracts, for example, 10% of physical ability parameters (maximum ball speed and ball control force) related to the pitcher's pitch during the batting, respectively. In this way, appointing a player with a higher overall parameter leads to the advantageous advancement of each at-bat. In another example, when the pitcher loses by comparing the overall parameters, the batter's physical ability parameters (hitting power and hitting power) may be added by 10%, for example.

(Deck details)
FIG. 5 is a diagram illustrating an example of the data structure of the deck detailed information in the deck information. The detailed deck information shown in FIG. 5 is generated separately for each of the first deck and the second deck.

  In the present embodiment, one deck may be divided into a plurality of types of lower decks according to the roles of the players arranged. For example, the deck may be divided into two types, a fielder deck and a pitcher deck, based on the position of the player. Furthermore, the decks may be classified into two types, for example, a deck of a starting member and a deck of a refusal member, based on the timing of players entering the game. Accordingly, in the baseball game, each of the first deck and the second deck is composed of lower decks divided into four as follows.

  In this baseball game, for example, a lower deck including a starting member's fielder is referred to as a fielder starter deck, and a lower deck including a reserve member's fielder is referred to as a fielder bench deck. The starting member pitcher, that is, the lower deck including the starting pitcher is referred to as the pitcher starting deck, and the holding member pitcher, that is, the lower deck including the relief pitcher is referred to as the pitcher relief deck.

  As described above, the deck has a plurality of roles. For example, the role may be a defensive or attack position in the team, or a support position that assists or assists team members in these direct positions. One deck may have different positions one by one, or may have a plurality of similar positions. For example, a fielder starter deck has one kind of position one by one. The pitcher relief deck has multiple positions of the same type.

  The detailed deck information is information for managing the association between each position constituting the deck and the character that bears the position. As shown in FIG. 5, as an example, the deck of this game is composed of 27 positions. In the detailed deck information, one record is generated for each position, and a total of 27 characters are linked to each position.

  As shown in FIG. 5, the detailed deck information includes, for example, items of deck classification, position ID, position name, character ID, attribute, general parameter, and mascot effect correction. When the detailed deck information is that of the first deck, the own team effect correction item is not provided, or the value of the item takes a NULL value.

  “Deck classification” indicates to which of the above-mentioned four lower decks the position of the corresponding record belongs.

  “Position ID” is identification information for uniquely identifying each position in the deck. Since different position IDs are assigned to the same kind of positions, each record can be uniquely identified. “Position name” indicates the name of the position. By name, the user can identify each position in the deck.

  The “character ID” is identification information for uniquely identifying a card that is regarded as a player or a mascot. The character ID is associated with the position ID on a one-to-one basis. Thereby, the correspondence between the position of the deck and the character that bears the position is managed.

  “Attribute” indicates the attribute of the character who has reached the position of the corresponding record. As an example, the attributes include a character type and an affiliated team. “Character type” indicates a position type for classifying a fielder or a pitcher based on a position when the character is a player, and indicates a sex of male or female when the character is a mascot. “Affiliated team” indicates a team to which the character belongs among predetermined teams (for example, an existing professional baseball team, 12 teams).

  The “total parameter” indicates a total parameter set for each character. The value of the total parameter stored in the column is a basic value set for the character, and the correction value when the value is corrected is managed separately for the column.

  “Mascot effect correction” indicates a correction value of the overall parameter of each character that is corrected when the arrangement of the mascot in the deck satisfies a predetermined condition. In the example illustrated in FIG. 5, the correction value “50” indicates that 50 is added to the basic value of the general parameter stored in the left column.

  In the example shown in FIG. 5, for the sake of convenience, the fielder cheering position for placing the mascot male belongs to the fielder starter deck, and the pitcher cheering position for placing the mascot female is assumed to belong to the pitcher starting deck. It is managed. However, the present invention is not limited to this, and the fifth lower deck “mascot deck” may be generated in the detailed deck information, and a record of a position dedicated to the mascot may be provided there.

  As shown in FIG. 5, the detailed deck information of the second deck in the present embodiment further has an item “self-ball team effect correction”. “Self-ball team effect correction” indicates a correction value of an overall parameter of each character that is corrected when the arrangement of characters in the deck satisfies or does not satisfy a predetermined condition.

  In the present embodiment, the second deck has a property that the battle becomes more advantageous as more characters having the same team as the user's designated team are placed. Therefore, when the character of the designated team and the same team is arranged on the second deck, the battle progress unit 115 corrects the overall parameters of the character upward, and the characters of the team different from the designated team are arranged. If so, the overall parameter of the character is corrected downward. Specifically, for the own team effect correction item of FIG. 5, the value of the general parameter “+150” for the characters of the designated team and the same team, and the value of the general parameter “−150” for the characters of the different teams. Is stored in each record.

  When the detailed deck information generated by the battle progress unit 115 is stored in the storage unit 120 in accordance with the user's input operation, the battle progress unit 115 generates deck summary information based on the detailed deck information.

(Deck overview information)
FIG. 6 is a diagram illustrating an example of the data structure of the deck summary information in the deck information. The deck summary information shown in FIG. 6 is generated for each user, and a record is registered for each type of deck held by the user.

  As illustrated in FIG. 6, the deck summary information includes items of a deck ID, a deck type, a total parameter total value, a ball team degree, an added value, and a deck total parameter, for example. Among the deck summary information, for the record of the first deck, the value is a NULL value in the sub-item of the mascot bonus in the item of the own team and the item of the added value.

  “Deck ID” is identification information for uniquely identifying a deck held by the user. In this embodiment, two types of decks having different properties are held by the user, and deck IDs “D1” and “D2” are assigned to the respective decks.

  “Deck type” indicates the type of the deck. In the present embodiment, D1 is the first deck, specifically the character priority deck, and D2 is the second deck, specifically the own team priority deck.

  The “total parameter total value” indicates a value obtained by adding the corrected total parameters of each character incorporated in the deck. The corrected overall parameter is obtained by correcting the basic overall parameter originally set for the character incorporated in the deck based on the effect of the mascot incorporated in the same deck.

  “Own team degree” indicates the ratio of characters belonging to the same team as the user's designated team in the second deck. In the present embodiment, one deck includes 27 positions. Accordingly, the own team degree is represented by n / 27 (n is the number of characters belonging to the same team as the designated team arranged in the deck).

  The “added value” indicates a value that is temporarily added to the total parameter total value when the deck arrangement satisfies a predetermined condition. As an example, the added value includes a mascot bonus and a player bonus. The “mascot bonus” indicates a value added when the arrangement of one or more mascots satisfies a predetermined condition. In the present embodiment, the mascot bonus occurs when the deck type is the second deck. Therefore, the mascot bonus of the first deck takes a NULL value or a value of “0”. The “player bonus” indicates a value added when the arrangement of one or more players satisfies a predetermined condition. For example, there may be a player bonus to be added when the above-mentioned team degree satisfies a predetermined value or more.

  The “deck comprehensive parameter” is an index indicating the overall strength of the deck held by the user in the battle, and is assigned to each deck. The deck total parameter is calculated based on the corrected total parameter of each character arranged on the deck. More specifically, the deck total parameter is added based on the above-mentioned total parameter total value obtained by adding up the corrected total parameters of each character placed on the deck and the fact that the mascot is incorporated in the deck. And the added value (the mascot bonus described above). Therefore, the higher the overall parameter of each character in the deck, the higher the overall deck parameter is calculated. In the present embodiment, the battle progress unit 115 compares the deck general parameter of the user's deck with the deck general parameter of the opponent's deck, and advantageously proceeds with the battle if the value of the deck general parameter exceeds. Therefore, it can be considered that the higher the total deck parameter, the stronger the battle, and the more advantageous the battle. In this way, the user can enjoy the game further by collecting characters with high overall parameters or devising the arrangement of the decks so that many additional values can be obtained for the purpose of increasing the overall deck parameters. It becomes possible.

  As shown in FIG. 6, the deck summary information of the second deck in the present embodiment further includes items of the own team degree and the added value of the mascot bonus.

  The own team degree indicates how many players belonging to the same team as the designated team are placed among all positions on the deck. The battle progress unit 115 may add a player bonus when the player's own team degree satisfies the condition of “greater than or equal to a predetermined threshold”.

  Further, the mascot is set with a skill that has an advantageous effect on the player when placed on the second deck. Therefore, when a mascot having the same team as the user's designated team is assigned to the second deck, the battle progressing unit 115 activates the skills of the mascot so that the deck total in the second deck Correct the parameter significantly upwards. Specifically, the battle progress unit 115 may add a mascot bonus of a predetermined value every time one mascot identical to the designated team is placed.

  This prompts the user to collect characters belonging to his favorite team and, among other things, desires to acquire a mascot belonging to his favorite team. As a result, it is possible to give the user the joy of acquiring the mascot of the favorite team and the players belonging to the favorite team, the pleasure of collecting, and the pleasure of organizing the acquired character.

(Screen example)
FIG. 7 is a diagram illustrating an example of a deck selection screen displayed on the display unit 152 of the user terminal 100. The deck selection screen 400 is a screen for the user to select a type of deck to be organized in a game in which the user can have multiple types of decks. The deck selection screen 400 includes various deck information and a UI for selecting a deck. For example, the deck selection screen 400 includes status information 401 of the second deck as the own team priority deck and status information 402 of the first deck as the character priority deck. Furthermore, the deck selection screen 400 includes check boxes 403 and 404 of alternative selection type as UIs for the user to specify which deck to select.

  The status information 401 is generated based on the record D2 in the deck summary information shown in FIG. The status information 401 includes “own team degree”, “total value” indicating the total parameter total value, “addition value” obtained by adding up the mascot bonus and player bonus, the “total value”, and the “addition value”. And “deck comprehensive parameters”.

  The status information 402 is generated based on the record D1 in the deck summary information shown in FIG. The status information 402 includes a “total value” indicating a total parameter total value, an “addition value” obtained by totaling player bonuses, and a “deck total parameter” that is the sum of the “total value” and the “addition value”. including.

  The user operates the check boxes 403 and 404 while checking the status information of each deck described above, and selects a deck to be organized. Note that the battle progress unit 115 may display the deck selection screen 400 shown in FIG. 7 immediately before making a matching request to the server 200 and allow the user to select a deck to be used in the battle.

  FIG. 8 is a diagram showing an example of a fielder deck organization screen for arranging fielders in the deck organization screen. The fielder deck organization screen 500 includes a fielder starter deck 501 and a fielder bench deck 502 as an example. The fielder starter deck 501 has frames F2 to F9 corresponding to each of the eight defensive positions excluding the pitcher, and a frame F10 corresponding to the position of the designated batter. Furthermore, in this embodiment, the fielder starting deck 501 has a frame F1 corresponding to the fielder cheering position. As an example, the fielder bench deck 502 may have five frames corresponding to five positions of the reserve fielder.

  FIG. 9 is a diagram showing an example of a pitcher deck organization screen for arranging pitchers in the deck organization screen. The pitcher deck organization screen 550 includes a pitcher starting deck 551 and a pitcher relief deck 552 as an example. For example, the pitcher starting deck 551 may have five frames corresponding to the positions of five starting pitchers. For example, the pitcher relief deck 552 may have six frames corresponding to the positions of six relief pitchers.

  In the present embodiment, the pitcher deck organization screen 550 further includes a mascot display frame F16 corresponding to the pitcher support position. The pitcher support position is included in the pitcher starting deck 551 in terms of the data structure, but the frame F16 may be displayed outside the area of the pitcher starting deck 551 as shown in FIG.

  In the present embodiment, it is preferable that the battle progress unit 115 displays information on the placed character in a frame on the deck corresponding to the position. For example, the number at the upper right of the frame indicates the overall parameters of the arranged characters. To the right of the number, an arrow indicating an upward direction or a downward direction is displayed as necessary. The upward arrow indicates that the basic general parameters set for the character have been corrected upward. The upward correction is performed, for example, when the deck arrangement of each character satisfies a predetermined condition. A downward arrow indicates that the basic general parameters set for the character have been corrected downward. The downward correction is imposed, for example, as a penalty for the arrangement of the deck of each character not satisfying a predetermined condition. The logo on the lower left of the frame indicates the team of the arranged character. In addition, character rarity, character name, and the like may be displayed around the frame.

  Further, each deck organization screen may include a deck general parameter 503. An arrow indicating that the deck overall parameter is corrected upward or downward may be added. Further, each deck organization screen may include a UI 504 for calling up a list of mascot bonuses and player bonuses generated based on the current deck arrangement. In the present embodiment, since the parameter of the own team degree is not set in the first deck, when the deck organization screen shown in FIGS. 8 and 9 is the first deck, the own team degree 505 is Do not show.

  The user displays each deck organization screen on the display unit 152 and performs an input operation for linking a desired card on hand to each frame using the input unit 151. The battle progress unit 115 receives the above-described input operation via the operation reception unit 111, associates a position with a character based on the correspondence between the frame and the card, and generates detailed deck information.

<Character acquisition method using standard pack>
With reference to FIG. 10 to FIG. 14, how the standard pack is operated and the character is acquired by the user will be described.

(Screen example)
10 to 13 are diagrams showing an example of a game screen displayed on the display unit 152 of the user terminal 100 when the processes shown in steps S4 to S7 of FIG. 4 are being executed.

  FIG. 10 is a diagram illustrating an example of a pack notification screen 810 for notifying the user of a standard pack as a reward acquired by the user. The pack notification screen 810 is displayed on the display unit 152 in order to notify the user which type of pack has been given. The pack notification screen 810 includes, as an example, a standard pack 811 that is given as a reward for playing a battle. The display control unit 112 may display a reward notification screen (not shown) displayed immediately after the battle and a pack notification screen 810 shown in FIG. 10 simultaneously on one screen or sequentially in an arbitrary order.

  When the OK button 812 shown in FIG. 10 is pressed by a user operation, the card acquisition unit 116 displays a game screen for operating a pack, that is, a game screen including a slot in which the pack is placed (FIGS. 11 to 12). ) Is generated. The game screen generated by the card acquisition unit 116 is displayed on the display unit 152 by the display control unit 112. As an example, the card acquisition unit 116 generates the game screen illustrated in FIG. 11 and causes the display unit 152 to display the game screen.

  FIG. 11 is a diagram showing an example of a pack operation screen 820 for notifying the user of the progress of pack operation. The pack operation screen 820 includes a slot list 821 for listing the states of one or more slots owned by the user. In the example shown in FIG. 11, the user is provided with three slots 822-824 by default. In the present embodiment, the slots have an order, and the slot 823 and the slot 824 are displayed so that the leftmost slot 822 is at the top and the order is at the back as going to the right.

  A slot 822 shown in FIG. 11 indicates that the standard pack 811 (FIG. 10) just provided is placed in the slot 822. When a new standard pack 811 is given, the card acquisition unit 116 inserts the standard pack 811 into the first slot in the empty slot (slot 822 in the example shown in FIG. 11). Place automatically. Then, the standard pack 811 is made to wait in the slot 822 until the standard pack 811 transitions to a state where it can be opened. As described above, in this embodiment, the card pack is not in a state where pack points can be accumulated unless the card acquisition unit 116 is placed in the slot. Therefore, the slot is the first requirement that allows the card pack to transition to an openable state.

  Furthermore, in the present embodiment, the second requirement is set for the card pack to be in a state where the pack points can be accumulated. The second requirement imposes on the user to use a tool that allows the addition of pack points. As an example, the tool is provided to the user in the form of a scout man in the context of the baseball game. In this embodiment, as an example, the card acquisition unit 116 allocates one scout man per slot. In the present embodiment, by placing a card pack in a slot to which a scout man is assigned, pack points can be stored in the card pack. In other words, the card pack is placed in the slot as the first requirement and the scout man is assigned to the slot as the second requirement, and the pack points are added. The state shifts from a state where it cannot be performed (hereinafter referred to as “addition impossible state”) to a state where pack points can be added (hereinafter referred to as “addable state”).

  The addable state means a state in which the state of the card pack can be changed to satisfy a predetermined condition for opening. Specifically, it means a state in which pack points can be accumulated to reach the total of pack points set as conditions. On the contrary, the non-addable state means a state in which the state of the card pack cannot be changed so as to satisfy the above-described predetermined condition. Specifically, this means a state in which pack points cannot be stored, that is, a state in which points are not stored in association with card packs even if pack points are acquired.

  When a pack point is given to the user as a reward, the card acquisition unit 116 adds the given pack point to the card pack arranged in the slot to which the scout man is assigned. For example, it is assumed that 218 points of pack points are given after the match is over. In the example shown in FIG. 11, the slot 822 has a scout man 825 assigned thereto and a card pack is disposed. Therefore, the card acquisition unit 116 adds the assigned 218 points to the standard pack 811 arranged in the slot 822.

  When the card acquisition unit 116 adds the pack points to the standard pack 811 and the total of the pack points reaches a predetermined value, the card acquisition unit 116 transitions the standard pack 811 from the unopenable state to the openable state. Let Then, the card acquisition unit 116 may generate the game screen shown in FIG. 12 and display it on the display unit 152 in order to notify the user that the total pack points of the standard pack 811 satisfy the condition.

  FIG. 12 is a diagram showing another example of the pack operation screen 820 for notifying the user of the progress of pack operation. In the example illustrated in FIG. 12, the gauge 826 indicates that the accumulated pack points have reached the condition “800 pt” as a result of adding the pack points to the standard pack 811. After this screen is displayed, the card acquisition unit 116 executes processing for opening the standard pack 811, that is, based on the standard pack 811, the card acquisition unit 116 instructs the server 200 to specify the character card to be owned by the user. Request. Here, the standard pack 811 is consumed, and the slot is vacant.

  In this embodiment, when a slot is assigned to a scout man, there is a slot to which no scout man is assigned behind the empty slot, and a card pack is placed in the slot. It is assumed that Since there is no scout man, the card pack is in a state in which pack points are not accumulated and is simply waiting in the slot. In such a case, the card acquisition unit 116 places the card pack in the above-described empty slot. As a result, the card pack enters a state where pack points are accumulated.

  As shown in FIG. 12, when the gauge of the pack is full, the card acquisition unit 116 changes the pack to a state where it can be opened, and then opens the pack to allow the user to acquire a character. At this time, the card acquisition unit 116 may generate a game screen that produces a scene in which the pack is opened and the character card is about to be acquired, and may be displayed on the display unit 152. The game screen (not shown) includes, for example, an animation representing a scene in which the standard pack 811 is sealed and one or more predetermined number of cards are taken out in a state where the pattern is face down. Good.

  The card acquisition unit 116 receives a notification from the card providing unit 212 of the server 200 regarding the character to be owned by the user specified based on the opened pack. At this time, the card acquisition unit 116 may generate the game screen shown in FIG. 13 and display it on the display unit 152 in order to notify the user of the acquired character.

  FIG. 13 is a diagram illustrating an example of a character notification screen 830 for notifying the user of characters acquired by the user. For example, the character notification screen 830 includes cards 831 to 833 on which a character pattern acquired in exchange for an opened pack is shown. Each card includes, for example, information indicating a character image, a character name, a character team name, and a character rarity. When one of the cards is selected, detailed information may be displayed for the selected card. For example, various parameters related to the ability of the character may be displayed.

(Process flow)
FIG. 14 is a flowchart showing a flow of processing executed by the game system 1 based on the game program 131. In particular, the flow of processing from when the battle is progressed until the user acquires the character specified using the standard pack is shown. In the following, the process described as being executed by the user terminal 100 may be executed by the server 200, and conversely, the process described as being executed by the server 200 may be executed by the user terminal 100. . The series of processes shown in FIG. 14 corresponds to the processes in steps S2 to S7 shown in FIG.

  In step S <b> 1 illustrated in FIG. 4, the operation reception unit 111 of the user terminal 100 receives a user operation instructing the start of a battle via the input unit 151.

  In step S <b> 101, the battle progress unit 115 requests the server 200 for matching for starting a battle in response to the above-described instruction.

  In step S <b> 102, the battle support unit 211 of the server 200 receives the above request from the user terminal 100 via the communication IF 23. In response to this, the battle support unit 211 executes a matching process to search for a user's opponent. When an opponent is found and matching is established, the battle support unit 211 proceeds to step S103.

  In step S103, the battle support unit 211 causes the user terminals 100 that perform the battle to share information so that each matched user terminal 100 can advance the battle, performs synchronization control, and performs the battle. Assist. For example, the battle support unit 211 notifies the battle progress unit 115 that matching has been established, and provides the user terminal 100 of the user with information on the opponent and the opponent team.

  In step S104, the battle progress unit 115 communicates with the battle support unit 211 to advance the battle. The battle progress unit 115 may display a matching establishment screen (not shown) on the display unit 152 at the start of the battle. Then, the battle progress unit 115 transmits the pitching result D1 to the server 200 in the defensive times of the own team, and advances the pitching event in the mound, the defensive event in the field, and the like. The battle progress unit 115 may display a pitch screen (not shown) on the display unit 152 in the defensive round, for example. In addition, the battle progress unit 115 transmits the hit result D2 to the server 200 in the attack time of the own team, and advances the hitting event, the flying ball event, etc. in the batter box. The battle progress unit 115 may cause the display unit 152 to display, for example, an unillustrated batting screen in the attack times.

  In the case of YES in step S105, for example, when the progress of all innings is completed, in step S106, the battle support unit 211 determines a score. As an example, the battle support unit 211 uses the game information 132 recorded in the storage unit 220 while the battle is being executed, and wins, scores, strikeouts, hits, home runs, auto control usage rate, etc. Is read.

  In step S107, the battle support unit 211 calculates a reward to be given to the user who played the battle based on the determined battle score. In this embodiment, as an example, a standard pack, an experience value, gold, a pack point, and the like are given to the user as a reward for playing the battle. For example, the battle support unit 211 calculates a reward so that a higher grade pack or more pack points are awarded as the battle results are better.

  In step S108, the battle support unit 211 gives the calculated reward to the user. In the present embodiment, as an example, the reward (for example, standard pack) is stored as game information 132 in association with the above-described user identification information of the user. Alternatively, the battle support unit 211 adds the experience value, gold, and pack points as the reward for this time to the experience value, gold, and pack points before the battle, and obtains the game information 132 of the user. Update. Thereby, the above-mentioned reward can be acquired by the user. The battle support unit 211 may notify the user terminal 100 of the content of the reward given to the user.

  In step S109, when the battle progress unit 115 of the user terminal 100 receives the above-described notification, for example, a reward notification screen (not illustrated) and a pack notification screen 810 illustrated in FIG. 10 may be generated and displayed on the display unit 152. Good. The battle progress unit 115 updates the game information 132 in the storage unit 120 based on the notification related to the reward from the battle support unit 211 and causes the user to acquire the reward. When the pack is acquired, the card acquisition unit 116 operates the pack and executes a series of processes for causing the user to acquire the character.

  If YES in step S110, that is, if there is an empty slot in which no pack is arranged, in step S111, the card acquisition unit 116 arranges the assigned standard pack in the empty slot. In this embodiment, if even one slot owned by the user has a vacancy, the card acquisition unit 116 may automatically arrange the assigned standard pack in the vacant slot. For example, the card acquisition unit 116 may cause the display unit 152 to display the pack operation screen 820 shown in FIG.

  On the other hand, if NO in step S110, that is, if all slots owned by the user are already filled with packs, the card acquisition unit 116 places the standard pack newly given in step S109 in any slot. Can not do it.

  In this case, in step S112, the card acquisition unit 116 discards the newly assigned standard pack. That is, the digital data related to the standard pack disappears without being stored in the storage unit 120 or the storage unit 220.

  In another embodiment, the card acquisition unit 116 provides the user with an opportunity to immediately open the card pack without placing it in the slot for a pack that cannot be placed because there is no empty slot. May be. Specifically, the card acquisition unit 116 may cause the display unit 152 to display a message asking whether or not to open the card pack immediately on condition that it is exchanged for in-game value such as a predetermined consumption item. Good. Here, suggesting to open the card pack “immediately” means opening the card pack without waiting for the card pack to be placed in the slot or waiting for the pack point to reach the condition. It means giving the user an opportunity to do this. Therefore, the term “open immediately” should not be interpreted as being limited to opening as soon as the card pack is applied and opening as soon as the consumable item is consumed.

  In step S113, the card acquisition unit 116 adds the pack points granted in step S109 to the total of pack points associated with the card pack that is placed in the slot and to which the scout man is assigned. When the user possesses a plurality of slots in which the card packs are arranged, the card acquisition unit 116 assigns the assigned pack points to the card packs that satisfy both the first and second requirements. You may add and you may distribute the provided pack points to each card pack in a predetermined ratio. For example, the card acquisition unit 116 may cause the display unit 152 to display the pack operation screen 820 shown in FIG.

  In step S114, the card acquisition unit 116 determines whether or not the total of pack points of each pack satisfies a predetermined condition. If the pack point associated with the card pack does not satisfy the condition assigned to the card pack, the card acquisition unit 116 ends the series of processes. Specifically, step S114 corresponds to step S6 shown in FIG. 4, and the card acquisition unit 116 ends the series of processing from NO in step S6 (S114).

  On the other hand, if the sum of the pack points of any packs arranged in the slot has reached a predetermined value as a result of adding the pack points in step S113, the card acquisition unit 116 proceeds from YES in step S114 to step S115. Proceed to

  In step S115, the card acquisition unit 116 makes a transition to a state in which a standard pack that satisfies the pack point condition can be opened. Then, the card acquisition unit 116 transmits a character acquisition request to the server 200 based on the standard pack. Specifically, the card acquisition unit 116 requests the server 200 to specify a standard pack to be opened and to specify a character to be acquired by the user based on the type set in the pack.

  In step S116, the card providing unit 212 of the server 200 identifies the character to be provided to the user based on the grade and type set in the standard pack designated from the user terminal 100. In the present embodiment, the card providing unit 212 performs a predetermined lottery based on a probability table corresponding to the grade and type set in the standard pack described above, A character to be acquired by the user is specified from the set of characters. In the present embodiment, as an example, the card providing unit 212 may specify three character cards per pack. That is, the card providing unit 212 executes lottery three times. Further details of the pack opening process will be described with reference to another drawing.

  In step S117, the card providing unit 212 causes the user to acquire the specified three character cards. Specifically, the card providing unit 212 stores the three characters in the storage unit 220 as game information 132 in association with the user identification information. Thereby, the user can own these characters, and can use these characters to move the characters in the battle. The card providing unit 212 may notify the user terminal 100 of the three characters acquired by the user.

  In step S118, the card acquisition unit 116 of the user terminal 100, when receiving the above notification, causes the user to acquire a character. Specifically, the card acquisition unit 116 stores the notified character in the storage unit 120 as a character owned by the user. The card acquisition unit 116 may display the character notification screen 830 shown in FIG. 13 on the display unit 152 in order to notify the user of the acquired character. Here, the process up to step S7 shown in FIG. 4 is completed.

<Character acquisition method by purchasing a box>
(Box unpacking mechanism-overview)
An example of a mechanism for unpacking the box in the game system 1 will be described with reference to FIGS.

  FIG. 15 is a diagram illustrating a mechanism for purchasing a box and acquiring a character.

  The user performs an operation so that the second condition is satisfied in this game. Specifically, the user performs a purchase operation for purchasing the box 912 in exchange for a predetermined amount of valuable medium 914. Thus, when the second condition is satisfied, the box 912 containing at least one special pack is owned by the user. As a result, the user can acquire a special pack via the box 912.

  In this embodiment, certain requirements may be imposed to purchase the box 912. For example, the user may be permitted to purchase the box 912 in exchange for the ticket 913 (third right) that is the right to purchase the box 912. In this case, the box processing unit 214 satisfies the second condition based on the fact that the user has used the ticket 913 and then performed an operation for purchasing the box, that is, YES in step S8. You may judge.

  In the present embodiment, as an example, the ticket 913 may be given to the user together with the standard pack as a reward for the user playing the battle.

  In the present embodiment, the box processing unit 214 executes a process of unpacking the box 912 when the charging processing unit 213 completes the charging process and the box 912 is owned by the user. Then, the grade and type of the plurality of packs 910 associated with the box 912 are determined. The box processing unit 214 may determine the grade and type of each predetermined number of packs (for example, 5) by lottery based on a predetermined probability table. In the present embodiment, the box processing unit 214 determines the grade and type so that at least one of the five packs is a special pack.

  Based on the determined grade and type of each pack, the card providing unit 212 executes lottery for a predetermined number of times (for example, three times) for each pack 910 to identify each winning card. In the above example, the lottery is executed three times for each pack, and five packs are packed in one box, so that a total of 15 lotteries are executed and 15 cards 911 are specified.

  When the second condition is satisfied and the box 912 is purchased, the five packs 910 in the box 912 are already ready to be opened without waiting for the first condition to be satisfied. is there. For example, five packs 910 are opened immediately when their respective grades and types are determined.

  That is, in exchange for a ticket 913 and a predetermined amount of valuable medium 914, the user obtains a box 912 in which 15 cards can be obtained by lottery, and a service 915 that immediately obtains 15 cards (opens 5 packs immediately). And can receive.

(Unpacking mechanism-details)
FIG. 16 is a diagram illustrating an example of a data structure of management data. The management data is data for managing tickets held by the user. The management data is stored as game information 132 in the storage unit 120 of the user terminal 100, for example. The management data 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 management data, and the management data is managed for each user in the server 200.

  In the present embodiment, for example, one ticket may be given to the user every time the game is played ten times. Further, in the present embodiment, an expiration date may be set for the ticket. In the present embodiment, the number of tickets that the user can hold may be limited. For example, it is assumed that one user can hold up to 10 tickets with valid expiration dates at a time.

  The management data includes, as an example, items of “retention frame ID”, “remaining days”, and “use period”. “Holding frame ID” is identification information for uniquely identifying a ticket held by a user. In this embodiment, since up to 10 tickets can be held, 10 “reserved frame IDs” are provided. The “remaining days” is information indicating how many days remaining the ticket can be used. “Expiration date” is information indicating the expiration date set in the ticket.

  The battle progress unit 115 issues a ticket as a reward for the battle every 10 play times of the battle and causes the user to hold it. More specifically, the expiration date determined based on the ticket issuance date is stored in association with the vacant holding frame ID of the management data, and the remaining number of days obtained from the current date is stored.

  When there is no empty record in the management data, the battle progress unit 115 may discard the issued ticket as it is. Alternatively, the battle progress unit 115 may create a free record by discarding the ticket with the oldest issue date, that is, the ticket with the earliest expiration date in the management data. Then, the latest ticket just issued is stored in an empty record.

  The battle progress unit 115 discards the ticket whose usage period has passed. Specifically, each piece of ticket information is deleted from the record. The battle progress unit 115 consumes one ticket from the management data when the user performs a box purchase operation. Specifically, each piece of information on the ticket with the earliest use time limit is deleted from the record.

(Screen example)
The game screen shown in FIG. 17 is a ticket acquisition screen 600 that notifies the user that a ticket has been acquired. The battle progress unit 115 controls the UI control unit 113 and the animation generation unit 114 to generate the ticket acquisition screen 600 when the battle is played a predetermined number of times by the user. The ticket acquisition screen 600 may include an illustrated ticket 601 or may include guidance 602 regarding how to use the ticket 601.

  The ticket acquisition screen 600 may be displayed, for example, after the pack notification screen 810 shown in FIG. As a result, the user can recognize that the ticket has been acquired.

  The game screen shown in FIG. 18 is a menu screen 610 for inputting various instructions necessary for the user to play the game to the user terminal 100. The menu screen 610 includes a battle instruction button 611 as a UI for instructing the start of the battle. For example, when the user taps the battle instruction button 611, the operation reception unit 111 receives the tap operation. The battle progress unit 115 requests matching to the server 200 in response to the tap operation on the battle instruction button 611 being accepted.

  In the present embodiment, as an example, a UI for guiding to a box purchase screen (described later with reference to FIG. 19) that accepts a purchase operation for purchasing a box may be provided on the menu screen 610. The UI is, for example, a box icon 612.

  The user who operates the menu screen 610 has a high possibility of having an intention to play a battle, and it is considered that the desire to leave a good result in the battle is the highest. In other words, it seems that the desire to reinforce good cards and strengthen the team is the highest. At this point, it is possible to promote the purchase of the user's box most effectively by presenting the UI for guiding to the box purchase screen to the user.

  The game screen shown in FIG. 19 is a box purchase screen 620 for the user to perform a purchase operation for purchasing a box. The box purchase screen 620 is displayed on the display unit 152 when, for example, the box icon 612 on the menu screen 610 is operated.

  The box purchase screen 620 includes a purchase instruction button 621. The purchase instruction button 621 is a UI for allowing the user terminal 100 to allow the user terminal 100 to consume valuable media as a consideration for unpacking the box and acquiring a card, and instructing the purchase.

  The box purchase screen 620 may include a holding amount 622 as a UI indicating the quantity of valuable media currently held by the user. Since the user can consider purchasing the box while confirming the current possession, the convenience of the user is increased as a result.

  The box purchase screen 620 may further include a cancel button 623 for canceling the purchase and returning to the menu screen 610. The box purchase screen 620 may include an illustrated box 624. The box 624 may be an icon that provides detailed information about a product to be purchased (ie, a box).

  When the operation accepting unit 111 accepts a tap operation on the purchase instruction button 621, the card obtaining unit 116 transmits a box unpacking request to the server 200. At this time, the card acquisition unit 116 may generate an unillustrated unpacking effect screen that produces a scene for unpacking the box. Similarly to the opening effect screen, under the control of the card acquisition unit 116, a UI part is generated by the UI control unit 113, and an animation is generated by the animation generation unit 114. Thereby, the user can have a sense of expectation until the purchased box is unpacked and it becomes clear what kind of pack is contained.

  The game screen shown in FIG. 20 is an unpacking result screen 630 presenting the unpacking result of the box. When the server 200 determines the rank of each pack in the box, the server 200 notifies the user terminal 100 of the determined types of the five packs as the progress of unpacking as a response to the box unpacking request. The card acquisition unit 116 generates an unpacking result screen 630 for presenting the user with the types of the five packs packed in the box according to the notified progress of unpacking. As shown in FIG. 20, the five pack types, grade and type, may be presented by showing the appearance of the pack. According to the unpacking result screen 630 shown in FIG. 20, what was packed in the box is two packs of black grade and three packs of gold, one of the two black packs. It can be seen that this is a special pack of the type “determined by owning team rarity S or higher”.

  After displaying the unpacking result screen 630, the card acquisition unit 116 may display a scene in which five packs are opened on the display unit 152. Specifically, the card acquisition unit 116 controls the UI control unit 113, the animation generation unit 114, and the display control unit 112 to display an unillustrated opening effect screen for each pack, and subsequently, the opening result Is displayed, a character notification screen 830 shown in FIG. 13 is displayed. Then, the above process is repeated for 5 packs.

  For example, after the above processing is repeated for five packs, the card acquisition unit 116 may cause the display unit 152 to display a final result screen that presents all the cards acquired as a result of unpacking the box. . The game screen shown in FIG. 21 is a final result screen 640 that displays a list of opening results of all packs packed in the box. The final result screen 640 includes a list 641 that displays a list of all characters acquired by opening the box. Thereby, the user can list and confirm all the acquired cards, and as a result, the convenience for the user is improved. Final result screen 640 may include an OK button 642. When the OK button 642 is tapped, the card acquisition unit 116 may close the final result screen 640 and display the menu screen 610 on the display unit 152 again.

(Process flow)
FIG. 22 is a flowchart showing a flow of processing executed by the game system 1 based on the game program 131. In particular, a flow of processing from when a user operation for purchasing a box is received until the user acquires a specified character using a plurality of packs including at least one special pack is shown. That is, the series of processes shown in FIG. 22 corresponds to steps S8 to S10, S6, and S7 shown in FIG. The series of processing shown in the flowchart is started when the operation receiving unit 111 receives a user operation for instructing display of the menu screen 610 shown in FIG. 18, for example.

  When the second condition is satisfied in step S215, the battle progress unit 115 proceeds from YES in step S215 to step S216. The second condition is that a purchase operation is performed by the user. As an example, the purchase operation refers to touching the box icon 612 on the menu screen 610 shown in FIG. 18 and touching the purchase instruction button 621 on the box purchase screen 620 shown in FIG.

  When the purchase operation is received via the operation reception unit 111, in step S216, the card acquisition unit 116 refers to the management data illustrated in FIG. 16 and determines whether or not the user has an available ticket. judge.

  If a valid ticket is held, the card acquisition unit 116 proceeds from YES in step S216 to step S217. In step S217, card acquisition unit 116 consumes one valid ticket and transmits a box unpacking request to server 200.

  In step S218, billing processing unit 213 of server 200 may perform billing processing. Specifically, the billing amount when billing the user for the purchase is charged in the storage unit 220 in association with the user. Note that when the user has just purchased and owned the valuable medium, the charging process in step S218 may be omitted.

  In step S219, the box processing unit 214 executes a box unpacking process. Specifically, the grade and type of the five packs to be linked to the box are determined. During this time, in step S220, the card acquisition unit 116 of the user terminal 100 may display an unillustrated unpacking effect screen on the display unit 152.

  In step S221, the box processing unit 214 of the server 200 notifies the user terminal 100 of the grade and type of the five packs associated with the box as an unpacking result.

  In step S222, the card acquisition unit 116 of the user terminal 100 may display the unpacking result screen 630 shown in FIG. 20 on the display unit 152 based on the notified grades and types of the five packs.

  In step S223, the card providing unit 212 of the server 200 opens each pack whose grade and type are determined by the box processing unit 214, respectively. Specifically, the card providing unit 212 executes the lottery multiple times based on the probability table corresponding to the grade and type set in the pack, and specifies the character card to be won. Further details of the pack opening process will be described with reference to another drawing.

  In step S224, the card providing unit 212 notifies the user terminal 100 of the winning characters based on the five packs as a response to the box unpacking request. The process of step S224 is substantially the same as the process of step S117, except that the number of cards to be provided increases from 3 to 15.

  In step S225, the card acquisition unit 116 of the user terminal 100 executes processing for causing the user to acquire the winning character. The process in step S225 is substantially the same as the process in step S118 except that the number of cards to be provided is increased from 3 to 15.

  In the meantime, in step S226, the card acquisition unit 116 of the user terminal 100 may repeatedly display an unshown opening effect screen and a character notification screen 830 shown in FIG. 13 for each pack.

  In step S227, the card acquisition unit 116 may cause the display unit 152 to display the final result screen 640 illustrated in FIG. 21 as the final result of the box unpacking process. After the final result screen 640 is displayed, for example, when the operation reception unit 111 receives a user operation on the OK button 642, the battle progress unit 115 may return to step S201 and display the menu screen 610.

<Details of pack opening process>
Hereinafter, the pack opening process performed by the card providing unit 212 in step S116 illustrated in FIG. 14 or step S223 illustrated in FIG. 22 will be described in more detail.

(data structure)
FIG. 23 is a diagram illustrating an example of a data structure of a lottery database (hereinafter referred to as a lottery DB) that manages a population of characters to be selected in a lottery based on packs. The lottery DB is stored in the storage unit 220, for example, and can be read when the card providing unit 212 executes the lottery.

  In the lottery DB, for example, one record includes “card ID”, “character name”, “character type”, “rareness”, “team team”, and “winning time limit” items. “Card ID” is identification information for uniquely identifying the card of the character to be selected. One card ID is given to one character. “Character name” indicates the name of the character. “Character type” is one of the attributes of the character, and classifies the character as “pitcher” or “fielder” according to the defensive position set for the character. “Rareness” is one of the attributes of a character, and indicates the value of the character in favor of proceeding with the game. The rarity level can also be an index such as the high ability value or difficulty in obtaining the character. “Team” is one of the attributes of the character, and indicates the organization to which the character belongs, specifically, the team. “Winning deadline” indicates the winning deadline when the character is a limited character with a limited period for winning. If the item is a NULL value, or if a specific time limit is not stored in the item, it means that the character is not a limited character.

  The card providing unit 212 executes a lottery and selects a character to be acquired by the user from the characters registered in the lottery DB.

  FIG. 24 is a diagram illustrating an example of a data structure of a probability table indicating the winning probability of a character. The probability table is stored in the storage unit 220, for example, and can be read when the card providing unit 212 executes a lottery. In this embodiment, the winning probability is defined for each character in one probability table. Specifically, in the probability table, a winning probability is defined for each character rarity. Further, in the probability table, a winning probability may be defined for each character having a specific attribute. For example, the winning probability of a limited character may be defined, or the winning probability of a character belonging to a designated team specified by the user may be defined.

  In the present embodiment, the probability table is set for each lottery based on the pack. For example, in the present embodiment, two types of probability tables may be set for each type of pack, divided into at least one time and other times. The type of pack is uniquely identified by grade and type. As an example, two types of probability tables are a first probability table 701 that is referred to at the final lottery among a plurality of lotteries executed for one pack, and a second reference that is referred to at other lotteries. 2 probability table 702. The first probability table 701 corresponds to the added value set in the pack so that a character having a specific attribute is reliably won or won with a higher probability than other types of packs. Define the winning probability. The second probability table 702 defines a winning probability for each character rarity corresponding to at least a grade and a type set in the pack. In the figure, it is assumed that a winning probability with a number larger than 0% is stored in a place where the winning probability value is “**%”. “0%” indicates that the corresponding character is not won.

  In the present embodiment, as an example, the card providing unit 212 executes the final lottery based on the first probability table 701 among a plurality of lotteries executed for one pack, and the other lotteries. Is executed based on the second probability table 702. In the present embodiment, three lotteries are executed per pack. Therefore, the card providing unit 212 executes the lottery based on the second probability table 702 at the first and second lotteries, and executes the lottery based on the first probability table 701 at the third lottery. Therefore, the card providing unit 212 executes a lottery so that a character having a specific attribute wins in a third time, or in particular, with a high probability, for a pack with added value set. .

(Process flow)
FIG. 25 is a flowchart showing the flow of the pack opening process executed by the card providing unit 212. The series of processes shown in FIG. 25 corresponds to step S116 shown in FIG. 14 or step S223 shown in FIG.

  In step S <b> 301, the card providing unit 212 specifies a target pack that is a target of an opening process among packs associated with the purchased box.

  In step S302, card providing unit 212 identifies the grade and type set in the target pack. The setting of the grade and type has already been executed by the box processing unit 214.

  In step S303, the card providing unit 212 initializes the number of lotteries. For example, the card providing unit 212 determines the number of lotteries as “1 (first)”.

  In step S304, the card providing unit 212 determines whether or not the number of lotteries is the last time (for example, the third time). When the number of lotteries is not yet final (for example, the first time or the second time), the card providing unit 212 proceeds from NO in step S304 to step S305. When the number of lotteries is the final number (for example, the third time), the card providing unit 212 proceeds from YES in step S304 to step S310.

  In step S305, the card providing unit 212 reads the second probability table 702 from the storage unit 220 among the probability tables corresponding to the grade and type of the target pack. For example, in the case where the target pack is a special pack of the type “determined by the own team rarity S or higher” and the “limited period” type, the card providing unit 212 selects the second highest in the probability table shown in FIG. Read the probability table 702.

  In step S306, the card providing unit 212 executes a lottery based on the read second probability table 702. In the above example, according to the probability based on the second probability table 702 at the top, the card providing unit 212 specifies one character to be selected from the lottery DB shown in FIG. Specifically, the card providing unit 212 determines from the lottery DB all characters (including limited characters) with a rarity level SS, limited characters with a rarity level S (characters for which a winning deadline is set), and rarity levels. All characters of A and all characters of rarity B are extracted. The card providing unit 212 identifies one character to be won in accordance with the winning probability shown in the second probability table 702 from the extracted population.

  In step S307, the card providing unit 212 stores the character specified in association with the user identification information in the storage unit 220.

  In step S308, when the number of lotteries has not reached the final number, the card providing unit 212 proceeds from NO in step S308 to step S309.

  In step S309, the card providing unit 212 increments the number of lotteries by 1 (for example, increments from the second time to the third time), and returns to step S304.

  In step S310, the card providing unit 212 reads the first probability table 701 from the storage unit 220 among the probability tables corresponding to the grade and type of the target pack because it is the last time. Then, steps S306 to S307 are executed based on the first probability table 701. In the above example, based on the first probability table 701 at the top, the card providing unit 212 executes the final lottery. Specifically, the card providing unit 212 extracts, from the lottery DB, characters belonging to the same team as the designated team designated by the user from the characters (including limited characters) of the rarity SS. Furthermore, characters belonging to the same team as the user's designated team are extracted from the limited characters of the rareness S (characters for which the winning deadline is set). The card providing unit 212 identifies one character to be won in accordance with the winning probability shown in the first probability table 701 from the extracted population. The character won by this lottery is always a character of the own team's rarity S or higher, and the probability that the limited character wins will be significantly higher than other times. This lottery corresponds to the added value of “determined by own team rarity S or higher” and “limited period”.

  In step S308, if the number of lotteries is the final number, the card providing unit 212 proceeds from YES in step S308 to step S311.

  In step S311, the card providing unit 212 determines whether or not an unopened pack remains among the packs associated with the purchased box. If there is an unopened pack, card providing section 212 returns from YES in step S311 to step S301, and repeats the processing in steps S301 to S311 for a new pack. On the other hand, when all the packs are opened and the character to be acquired by the user is specified, the card providing unit 212 proceeds from NO in step S311 to step S312.

  In step S312, the card providing unit 212 outputs each pack and the winning character at each time to the user terminal 100 via the communication IF 23.

  According to the above-described method, a special pack that can be obtained by satisfying the second condition is provided to the user separately from the standard pack that can be obtained by satisfying the first condition. When a lottery is performed a plurality of times based on the special pack, a character having the same attribute as the attribute (a team) desired by the user is won at least once (for example, the final round). By using the special pack, it is guaranteed that the user can acquire at least one character of the desired attribute in at least one lottery among the lottery times, and in other times, further wins are won. You can face the lottery with high expectations. As a result, it is possible to respond to the user's desire to obtain a character having a desired attribute without impairing the interest of the lottery.

  As disclosed in Non-Patent Document 1, the conventional lottery method is a method of executing one lottery in which a character wins based on one instruction from a user. Since the user knows that the character with the desired attribute is hit, there is a problem that the user cannot find interest in this lottery. In this game, it is desirable to apply the lottery method according to the present embodiment without coexisting such a conventional lottery method. As a result, the user always operates the standard pack or purchases the special pack by charging to acquire the character. In the lottery based on the pack, it is guaranteed that the character with the desired attribute will win, but it is not possible to know all the lottery results in advance. Therefore, it is possible to make the user always fully expect, tension, excitement, joy, uplifting feeling, etc., especially when the characters are drawn.

[Modification]
There are a plurality of types of boxes depending on the types of added value to be provided, and the types of boxes acquired by the user may be determined by lottery. Then, the box processing unit 214 may determine the type of pack associated with the box according to the determined type of box. For example, for the first type box that provides the first added value that guarantees the winning of the same attribute game medium (character belonging to the designated baseball team) associated with the same attribute as the attribute designated by the user, At least one special pack with one added value is linked. In addition, the box processing unit 214 provides a second added value that guarantees the winning of a high rarity game medium (a character having a rarity level of S or higher) having a rarity level indicating a high value on the game. At least one special pack to which the second added value is added is associated with the second type box. In addition, the box processing unit 214 provides a third type of box that provides a third added value in which the winning probability of a limited game medium (limited character) with a limited winning period is higher than that of other types of packs. Thus, at least one standard pack or special pack to which the third added value is added is linked.

  In other words, the box processing unit 214 may commit a special pack type associated with the box, and may provide a plurality of types of boxes according to the committed special pack type. For example, the box processing unit 214 includes at least one special pack of the type “determined by S orchid team rarity S or higher” + “for a limited time” or a special pack of the type “determined by own team rarity S or higher by S” You may provide a user with a box as a box of the type “determined by the own team rarity S or higher” type. Alternatively, the box processing unit 214 includes a box that includes at least one special pack of the type “rareness S or higher determined” + “limited period” or a special pack of “rare degree S or higher determined” type. , It may be provided to the user as a box of the “determined rarity S or higher” type.

  The card acquisition unit 116 may notify the user of the box type before purchase or before unpacking. For example, on the box purchase screen 620 shown in FIG. 19, the card acquisition unit 116 may change the display mode of the box 624 for each type.

  The box processing unit 214 may randomly determine which type of box the user owns when a box is purchased in exchange for the ticket 913.

  Alternatively, a ticket as a battle reward may be provided for each type of box. The battle progress unit 115 may, for example, receive a “determined with a rarity degree S or higher” ticket and a “determined with a rarity degree S or higher” type as a right to purchase a “owner team rarity S or higher determined” type box A “determined rarity S or higher” ticket as a right to purchase may be given to the user separately from a normal ticket. In this case, the battle progress unit 115 may randomly determine which type of ticket is to be given to the user. The user can select a desired type of ticket and purchase a desired type of box. The billing processing unit 213 may vary the selling price for each box type.

[Example of software implementation]
Control blocks of the control unit 210 (particularly, the battle support unit 211, the card providing unit 212, the charging processing unit 213, and the box processing unit 214), and control blocks of the control unit 110 (particularly, the operation receiving unit 111 and the display control unit 112). The UI control unit 113, the animation generation unit 114, the battle progress unit 115, and the card acquisition unit 116) may be realized by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like, or a CPU ( It may be realized by software using a Central Processing Unit.

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

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

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

  (Item 1) The game program (131) has been described. According to an aspect of the present disclosure, the game program is executed by a computer (at least one of the user terminal 100 and the server 200) including a processor (10, 20) and a memory (11, 21). The game program stores the first right (standard pack) among the digital data used to acquire one or more game media (card, character) that can be used in a game based on the game program. In step S4, when the first condition (YES in S3) is satisfied, the second right (special pack) of the digital data is obtained in the game. In response to the step (S10) that is acquired by satisfying (YES) in step S1), and one of the first right or the second right is used, the lottery is executed a plurality of times, and each time a prize is won. The step of specifying the game content (S7, S116, S223, S306) and the step of specifying is based on the second right For multiple least one of the lottery rows, thereby winning the game contents are the same attribute as designated by the user is associated. Thereby, there is an effect that the user's desire to obtain a desired game medium can be met without impairing the interest of the lottery.

  (Item 2) In (Item 1), probability information (first probability table 701, second probability table 702) indicating the winning probability of the game content is stored in the memory, and the probability information includes It is set for each type of right and for each lottery based on the right, and the specifying step executes each lottery based on the probability information for each time set for the used right. May be.

  (Item 3) In (Item 2), the step of specifying is a first addition that guarantees winning of the same attribute game medium (character belonging to the user's designated team) associated with the same attribute as the attribute specified by the user Probability information (first probability table 701) is set so that the same attribute game medium wins at least one lot out of the plurality of lotteries based on the second right to which value is added. May be performed on the basis.

  (Item 4) In (Item 2) or (Item 3), the step of specifying is a high-rareness game medium (rareness S and SS of the rarity S and SS) in which a rarity indicating a high value on the game is equal to or higher than a predetermined The at least one lottery based on the second right added with the second added value that guarantees the winning of the character) is based on the probability information set so that the high rarity game medium is surely won. May be executed.

  (Item 5) In any one item from (Item 2) to (Item 4), in the step of specifying, there is a possibility that a limited game medium (limited character) having a limited winning period may be won. 3. A plurality of lotteries based on the first right and the second right with added value 3 are executed based on probability information set so that the winning probability of the limited game medium is higher than 0%. May be.

  (Item 6) In any one item from (Item 1) to (Item 5), the step of allowing the user to acquire the second right includes a plurality of rights when the second condition is satisfied. It is preferable that a user acquires a rights collection medium (box) associated with the user, and at least one second right is associated with the rights collection medium.

  (Item 7) In (Item 6), the step of acquiring the second right may cause the user to acquire the second right only when the user acquires the right aggregation medium.

  (Item 8) In (Item 7), the step of acquiring the first right determines that the first condition is satisfied based on the user playing the game, and the second right The step of acquiring a right may determine that the second condition is satisfied based on the user performing an operation for purchasing the right aggregate medium.

  (Item 9) In (Item 7), the game program causes the processor to acquire a third right (ticket) that is a right to purchase the rights collection medium when the first condition is satisfied in the game. ) Is executed by the user (S4), and the step of acquiring the second right is an operation for the user to use the third right and purchase the right aggregation medium. It may be determined that the second condition is satisfied based on the execution of the above.

  (Item 10) In any one item from (Item 6) to (Item 9), the game program stores, for each of a plurality of rights associated with the rights collection medium, the game program, (S219) is further executed, and the step of determining the type of right includes (1) distinction between the first right and the second right, and (2) increasing the winning probability of a specific game medium. At least one item of presence / absence of value, type of added value, and (3) a grade indicating the ease of winning a game medium having a high value on the game above a predetermined value. The type of the right may be determined by determining by lottery.

  (Item 11) In (Item 10), the rights collection medium has a plurality of types according to the type of added value to be provided, and the type of the rights collection medium acquired by the user is determined by lottery. The step of determining the type of right includes a first type of rights collection medium that provides a first added value that guarantees the winning of the same attribute game medium associated with the same attribute as the attribute specified by the user. A second for associating at least one second right to which the first added value is added, and guaranteeing the winning of a high rarity game medium having a rarity indicating a high value on the game of a predetermined value or more; At least one second right to which the second added value is added is associated with the second type of right aggregation medium that provides added value, and the winning probability of the limited game medium in which the winning period is limited is determined. From other types of rights The third kind of rights set medium for providing a third added value becomes higher, the first right and second right third added value is added may be attached at least one cord.

  (Item 12) In any one item from (Item 1) to (Item 11), the game medium is a character, and the game is against a team of one or more characters owned by the user. The game is a battle game to be played against a team, and the memory stores a first deck and a second deck having different formations of the team, and the second deck has the same attribute specified by the user. When one or more characters having an attribute are included, it may have a property of causing an advantageous effect in the battle. The user desires to collect more characters having the same attribute as the attribute specified by the user in the second deck. Therefore, the user's desire to obtain a desired game medium can be further met.

  (Item 13) A method for executing a game program has been described. According to an aspect of the present disclosure, the game program is executed by a computer including a processor, a memory, and an operation unit. The method is a method in which the processor executes each step described in (Item 1). The method according to (Item 13) has the same operational effects as the game program according to (Item 1).

  (Item 14) The information processing apparatus has been described. According to an aspect of the present disclosure, the information processing apparatus includes a storage unit (120, 220) that stores a game program according to (Item 1), and the information processing apparatus (user terminal 100) by executing the game program. And a control unit (110, 210) for controlling the operation of the server 200). The information processing apparatus according to (Item 14) has the same effects as the game program according to (Item 1).

1 game system, 2 network, 10,20 processor, 11,21 memory, 12,22 storage, 13,23 communication IF (operation unit), 14,24 input / output IF (operation unit), 15 touch screen (display unit, Operation unit), 17 camera (operation unit), 18 distance sensor (operation unit), 100 user terminal (information processing device), 110, 210 control unit, 111 operation reception unit, 112 display control unit, 113 UI control unit, 114 animation generation unit, 115 battle progress unit, 116 card acquisition unit, 120, 220 storage unit, 131 game program, 132 game information, 133 user information, 151 input unit (operation unit), 152 display unit, 200 server (information processing) Device), 211 battle support unit, 212 card providing unit, 213 billing processing unit, 14 Box processing unit, 1010 an object, 1020 controller (operation unit), 1030 storage medium

Claims (14)

A game program,
The game program is executed by a computer including a processor and a memory,
The game program is stored in the processor.
Of the digital data used to acquire one or more game media that can be used in a game based on the game program, the first right is acquired by the user when the first condition is satisfied in the game. Steps,
A step of causing the user to acquire a second right of the digital data when a second condition is satisfied in the game;
Executing a lottery multiple times in response to the use of one of the first right or the second right, and identifying a game medium to be won each time,
The identifying step is a game program for winning game media associated with the same attribute as the attribute designated by the user for at least one of a plurality of lotteries executed based on the second right. The memory stores probability information indicating the winning probability of the game content, and the probability information is set for each type of the right and for each lottery based on the right,
The game program according to claim 1, wherein the specifying step executes each lottery based on the probability information for each time set for the used right.   The identifying step includes at least one of the plurality of lotteries based on a second right added with a first added value that guarantees the winning of the same attribute game medium associated with the same attribute specified by the user. The game program according to claim 2, wherein one lottery is executed based on probability information set so that the same-attribute game medium is surely won.   The specifying step is based on the at least one based on the second right added with the second added value that guarantees the winning of the high rarity game medium having a rarity level indicating a high value on the game being a predetermined value or more. The game program according to claim 2 or 3, wherein the lottery is executed based on probability information set so that the high rarity game medium is surely won.   The specifying step includes a plurality of lotteries based on the first right and the second right added with the third added value that may be won by a limited game medium having a limited winable period, The game program according to any one of claims 2 to 4, which is executed based on probability information set so that a winning probability of the limited game medium is higher than 0%. The step of causing the user to acquire the second right causes the user to acquire a right aggregate medium in which a plurality of rights are linked when the second condition is satisfied,
The game program according to claim 1, wherein at least one of the second rights is associated with the rights collection medium.   The game program according to claim 6, wherein the step of acquiring the second right causes the user to acquire the second right only when the user acquires the right collection medium. The step of acquiring the first right determines that the first condition is satisfied based on the user playing the game,
The step of acquiring the second right determines that the second condition is satisfied based on the user performing an operation for purchasing the rights collection medium. Game program. The game program is stored in the processor.
Causing the user to acquire a third right that is a right to purchase the rights collection medium when the first condition is satisfied in the game;
The step of acquiring the second right satisfies the second condition based on the fact that the user uses the third right and then performs an operation for purchasing the right aggregation medium. The game program according to claim 7, wherein the game program is determined to have been played. The game program is stored in the processor.
A step of determining a right type for each of the plurality of rights associated with the rights collection medium;
The step of determining the type of the right comprises
(1) distinction between the first right and the second right;
(2) Presence / absence of added value that increases the winning probability of a specific game medium, the type of the added value, and
(3) The type of the right is determined by determining at least one item of a grade indicating the ease of winning a game medium having a high value on the game above a predetermined value by lottery. The game program according to any one of claims 6 to 9. The rights collection medium has a plurality of types according to the type of added value to be provided, and the type of the rights collection medium acquired by the user is determined by lottery,
The step of determining the type of the right comprises
The first type of right aggregation medium that provides the first added value that guarantees the winning of the same attribute game medium that is associated with the same attribute as the attribute designated by the user is the second added with the first added value. Tie at least one right
The second added value medium that provides the second added value that guarantees the winning of the high rarity game medium having a rarity level indicating a high value on the game of a predetermined value or more is included in the second added value medium. Linking at least one second right to which
The third added value is added to the third type of right aggregation medium that provides the third added value in which the winning probability of the limited game medium in which the winning period is limited is higher than other types of rights. The game program according to claim 10, wherein at least one first right or second right is associated. The game medium is a character, and the game is a battle game in which a team composed of one or more characters owned by the user is played against an opponent team,
The memory stores a first deck and a second deck, each having a different organization of the team.
The said 2nd deck has a property which activates an advantageous effect in a battle | competition, when one or more characters which have the attribute same as the attribute which the said user specified are included. Game program. A method for a computer to execute a game program,
The computer includes a processor and a memory,
The method by which the processor performs the steps of claim 1. An information processing apparatus,
The information processing apparatus includes:
A storage unit for storing the game program according to claim 1;
An information processing apparatus comprising: a control unit that controls the operation of the information processing apparatus by executing the game program.