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

Abstract

To enhance game amusement.SOLUTION: A game program (131) causes processors (10, 20) to execute a step (S5) for generating a cooperation team composed of one or more players each selected from among the players owned by each of a plurality of users and the players are as digital contents and a step (S8) for advancing the match between the cooperation team and the opponent team that has the match with the cooperation team. In the step in which the match is advanced, the user who owns the player determines the operation of the player in his/her turn according to the input operation to be executed to a computer operated by the user.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.

  Various businesses provide game programs that display characters such as players in a virtual space on the game and allow the user to operate the players to advance the game. For example, games on the subject of competitions such as tennis, table tennis, dodgeball, baseball, soccer and hockey are provided.

  In particular, team competitions such as baseball or soccer where teams composed of a plurality of players face each other are often taken up as the subject of a battle game. In the competitive game, the user operates each player in the team and the battle progresses. Specifically, in the battle game, there is a communication battle game in which each of a plurality of users exchanges information using a terminal and thereby advances the battle (for example, Patent Documents 1 and 2).

JP 2006-263069 A (released on October 5, 2006) Japanese Patent Laid-Open No. 2003-010549 (released on January 14, 2003)

  As described above, a communication battle game between one user and an opponent is widely provided. On the other hand, it has been difficult to realize a communication cooperative battle game between a plurality of users and an opponent in which a plurality of users cooperate to operate one team and battle against other teams.

  In particular, it is very difficult to maintain fairness among users, such as participation opportunities or rewards, when each user brings players owned by the user to participate in a cooperative battle.

  An object of one embodiment of the present disclosure is to realize a communication cooperation battle game with high interest.

The game program according to the present disclosure is executed by one or a plurality of computers including a processor and a memory. The game based on the game program is a battle game in which teams composed of a plurality of players face each other, and an opportunity to perform a predetermined action is given to one or a plurality of players in order and progresses It is a battle game to play. The game program generates, on at least one of the processors, a cooperation team composed of one or more players selected from among players owned by each of a plurality of users as digital contents. And a step of advancing a battle between the cooperation team and the opponent team that battles the cooperation team. In the step of proceeding with the battle, the action of the player whose turn has been determined is determined by the user who owns the player according to the input operation performed on the computer operated by the user.

A game program according to the present disclosure is executed by a server including a processor and a memory. A game based on a game program is a battle game in which teams composed of a plurality of players battle each other, and the battle game includes a first game element in which a cooperation team operated in cooperation with a plurality of users battles with an opponent team. Including at least. The memory is configured to store, for each user, a player as digital content owned by each user who plays the game based on the game program. The game program includes grouping a plurality of users cooperating in a battle based on at least one of a play history of each user in a battle game and a player owned by each user. A step of generating a cooperation team composed of one or more players selected from among players owned by each of the plurality of users and a step of proceeding a battle between the cooperation team and the opponent team are executed. In the step of proceeding with the battle, the operation of the player in the battle is determined by the user who owns the player according to the input operation performed on the computer operated by the user.

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

It is a figure which shows the hardware constitutions of a game system. It is a block diagram which shows the functional structure of a user terminal and a server. It is a figure which shows an example of the data structure of user information. 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 deck organization screen displayed on a display part. It is a figure which shows an example of the deck organization screen displayed on a display part. It is a figure which shows an example of the data structure of deck information. It is a figure which shows an example of the data structure of contribution player information. It is a figure which shows an example of the data structure of order information. It is a figure which shows an example of the data structure of order information. It is a flowchart which shows the flow of a process when the battle progress part of a user terminal produces | generates a cooperation team. It is a figure which shows the specific example of the grouping result screen displayed on a display part. It is a figure which shows the specific example of the pitching screen displayed on a display part. It is a figure which shows the specific example of the pitching screen displayed on a display part. It is a figure which shows the specific example of the pitching screen displayed on a display part. It is a figure which shows the specific example of the defensive times screen displayed on a display part. It is a figure which shows the specific example of the batting screen displayed on a display part. It is a figure which shows the specific example of the total screen displayed on a display part.

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). As this mobile communication system, for example, a so-called 3G, 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.

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

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

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

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

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

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

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

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

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

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

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

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

<Game overview>
A game executed by the game system 1 based on a game program (hereinafter referred to as a main game or a baseball game) is, for example, a battle game in which teams composed of a plurality of players battle each other and have a predetermined operation. This is a battle game in which one or more players are given the opportunity to proceed in order. As an example, the battle proceeding in the battle game is a baseball game.

In this game, at least a plurality of user terminals 100 communicate with each other, a cooperation team including players as digital contents owned by each of the plurality of users is generated, and this cooperation team battles with the opponent team. A game element (first game element) is included. The cooperation team is a player as digital content owned by each of a plurality of users, and is composed of one or more players selected from among the players owned by each of the plurality of users. Furthermore, this game may include an element of a communication interpersonal battle game (second game element) in which each user terminal 100 operated by each user communicates and battles each user's team. .

  Below, the battle between teams of each user in the elements of the communication versus person battle game is referred to as an interpersonal battle. A battle performed between a cooperation team and another opponent team in the elements of the communication cooperative battle game is referred to as a cooperative battle. When there is no need to distinguish between the two, it is simply described as a battle.

In the baseball game communication person-to-person game, each team is operated by the first user terminal 100 and the second user terminal 100 communicating via the server 200. A team is defined by a deck. The deck has a predetermined number of frames in which positions as roles within the team are set for each role constituting the team, and the roles are set for the objects by associating the objects with the frames (that is, positions). It has a data structure that can Specifically, a team is generated by a user incorporating one or more objects into a deck. An object is digital content that has some effect on the progress of a battle in this game, and the strength of each user's deck organized by one or more objects affects at least the progress of the battle. The object is, for example, a character such as a player. In this game, the player is represented by a display form called a card as an example.

  A baseball game progresses while the team's offense and defense are switched between the front and back for each inning. Hereinafter, in the front or back of a certain inning, when it is necessary to distinguish the user terminal 100 operating the defensive team and the attacking user terminal 100 from each other, the former is the pitching user terminal and the latter is the batting side It is called a user terminal. When it is not necessary to distinguish between the two, the user terminal 100 is simply referred to. The user of the pitching user terminal is referred to as the pitching user, and the user of the hitting user terminal is referred to as the hitting 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, and the attacking user operates the hit by the batter character using the hitting user terminal.

  The pitching user terminal 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 the data to the server 200. The pitching result D1 is transmitted via the server 200 to the opponent's hitting user terminal. The pitching operation is an operation performed by the pitching user on the input unit 151 of the pitching user terminal in order to cause the pitcher character to pitch.

  The batting user terminal determines the batting result according to the batting operation received from the batting user, generates data including the batting result (hitting result D2 shown in FIG. 1), and transmits the data to the server 200. The batting result D2 is transmitted to the opponent's pitching user terminal 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 in order to cause the batter character to hit the ball.

  In the element of the communication cooperative battle game of the baseball game, one cooperation team is generated when a predetermined number (for example, three) of user terminals 100 that cooperate with each other communicate via the server 200. The generation of the cooperation team may be performed by one representative of the predetermined number of user terminals 100 described above, or may be performed by the server 200 serving as a relay between the user terminals 100. When it is necessary to distinguish one representative of the user terminals 100 from other user terminals 100, the representative one is referred to as a main user terminal (for example, the main user terminal 100A in FIG. 1) and cooperates with other users. Terminal 100 is referred to as a sub-user terminal (for example, sub-user terminals 100B and 100C in FIG. 1).

  The cooperation team is generated by selecting each of the users who cooperate with each other from the players arranged in the respective decks. The generated cooperation team information is shared by the predetermined number of user terminals 100 described above via the server 200, and each player of the cooperation team is operated by each user terminal 100. In this embodiment, as an example, the operation of the player whose turn has been turned is operated by the user who owns the player using the user terminal 100 of the user. For example, when the pitching order of the pitchers owned by the user A of the main user terminal 100A (hereinafter referred to as the climbing order) is turned, the main user terminal 100A determines the pitching result according to the pitching operation received from the user A. . Then, the main user terminal 100A generates a pitching result D1 that is information indicating the above-mentioned pitching result, and transmits the pitching result D1 to the sub-user terminals 100B and 100C of the users B and C, who are cooperators, via the server 200. To do. In another example, when the batting order owned by the user B of the sub user terminal 100B comes, the sub user terminal 100B determines the batting result according to the batting operation received from the user B. And the sub user terminal 100B produces | generates the hit result D2 which is the information which shows the above-mentioned hit result, The main user terminal 100A of the user A who is a collaborator, and the sub user terminal 100C of the user C via the server 200 Send. Each user terminal 100 advances a battle being executed on each user terminal 100 based on the received pitching result D1 or hitting result D2.

  As described above, the pitching result D1 and the hitting result D2 are shared between the user terminals 100 that cooperate with each other, so that the cooperative battle being executed on each user terminal 100 can proceed with the same content.

  In this baseball game, when the user does not wish to control the player himself, the user can operate the user terminal 100 to notify the server 200 of that fact. When receiving such a notification from the user terminal 100, the server 200 determines an action result (throwing result or hitting result) of the player based on various information related to the ongoing battle according to the game program. Then, the determined operation result is transmitted to the user terminal 100 of the opponent or cooperator. That is, the server 200 controls the player instead of the user terminal 100. A mode in which the player's operation result is determined according to the user's input operation is referred to as a manual mode, and a mode in which the player's operation result is determined by execution of a program by the server 200 is referred to as an auto mode. For example, when the user cannot release his / her hand due to other affairs and cannot operate the player even if his / her player's turn comes around, the user switches from manual mode to auto mode. It can be performed.

  The game executed by the game system 1 according to the present embodiment is not limited to baseball, and may be a system for executing a battle game of any team competition. For example, the competitive game executed in the game system 1 includes softball, soft baseball, cricket, curling, soccer PK game, and team games (Judo, table tennis, ski jump, gymnastics, relay) of all other competitions, etc. It is assumed that the game is a competition game in which a plurality of players perform in turn in a predetermined order. Alternatively, an imaginary competition battle game in which a plurality of players perform in turn in a predetermined order may be executed in the game system 1, even if it is not an actual competition.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  The server 200 communicates with each user terminal 100 and has a function of supporting each user terminal 100 to advance the communication battle game. 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.

(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 the battle support unit 211 according to the description of the game program 131. The control unit 210 can also function as other functional blocks (not shown) in order to support the progress of the game on the user terminal 100 according to the nature of the game to be executed.

  The battle support unit 211 assists each user terminal 100 to advance a battle in this game. Specifically, the battle support unit 211 communicates with each user terminal 100 that fights or cooperates, and mediates exchanges between the user terminals 100. Furthermore, the battle support unit 211 executes matching of opponents, grouping of cooperators, synchronization control for synchronizing the progress of the battle, and the like. In the present embodiment, the cooperation team is generated by the battle progress unit 115 of the user terminal 100 described later, but in another embodiment, the battle support unit 211 may generate the cooperation team.

(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 functions as an operation reception unit 111, a display control unit 112, a UI control unit 113, an animation generation unit 114, and a battle progress unit 115 according to the description of the game program 131. The control unit 110 can also function as other functional blocks (not shown) in order to advance the game according to the nature of the game to be executed.

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

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

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

  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 hitting animation, a bat's swinging bat animation, a ball thrown by a pitcher, a ball hit by a 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. Also, the battle progress unit 115 controls the UI control unit 113, the animation generation unit 114, and the display control unit 112 to display the above-described UI necessary for the user to play the baseball game and the game screen including the UI. To provide.

  Each illustrated game screen referred to below is configured by a UI component generated by the UI control unit 113, an animation generated by the animation generation unit 114, or a combination thereof. The game screen generated by the UI control unit 113 or the animation generation unit 114 is displayed 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 ”.

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.

<User information>
FIG. 3 is a diagram illustrating an example of the data structure of the user information 133. The user information 133 is data for managing information related to the user referred to in the battle, and is created for each user. User information 133 is stored in the storage unit 120. The user information 133 may also be stored in the storage unit 220 of the server 200.

  The user information includes a plurality of items. As an example, at least the user name and rating items are included.

  “User name” indicates the name of the user. The user name is used by other users to identify the user. Further, the user information may include a “user ID” for each device of the game system 1 to identify the user. “Rating” indicates a rating set for the user. The rating is an index representing the strength of the user in the battle. The rating is updated based on a result of a battle between users (for example, victory or defeat) and a difference between ratings of each user before the battle based on a predetermined arithmetic expression. Specifically, the rating of the user who won the battle is increased, and the rating of the defeated user is decreased. Therefore, it can be assumed that the higher the rating, the stronger the user is in the battle.

  The user information may further include an item “deck comprehensive parameter”. The deck comprehensive parameter is an index of strength in a battle of the deck (the entire team) managed in association with the user. The deck total parameter is calculated based on the total parameter of each player arranged on the deck. Although described in detail later, the general parameter is a value indicating the overall strength of the player. The higher the overall parameter of each player in the deck, the higher the overall deck parameter is calculated. In the present embodiment, it can be considered that the deck (the entire team) is stronger in the battle as the overall deck parameter is higher.

<Processing flow: Overall>
FIG. 4 is a flowchart showing a flow of processing executed by one or more computers constituting the game system 1 based on the game program 131. In general, a method for a computer to execute the game program 131 of the baseball game is a cooperative team composed of players as digital contents, each of which is selected from one or more players owned by each of a plurality of users. And a step (S8) of advancing a battle between the cooperation team and the opponent team that battles the cooperation team. In the step of proceeding with the battle, the action of the player whose turn has been determined is determined by the user who owns the player according to the input operation performed on the computer operated by the user. In the present embodiment, as an example, the steps illustrated in FIG. 4 are described as being executed by the user terminal 100. However, the present invention is not limited to this, and each step shown in FIG. 4 may be executed by being shared by a plurality of computers.

  In step S <b> 1, the operation receiving unit 111 receives a user input operation for instructing the start of the cooperative battle via the input unit 151.

  In step S <b> 2, the battle progress unit 115 transmits an entry request to the server 200. The entry request is a message for requesting the server 200 to form a group of users who cooperate with each other to play a cooperative battle, and to have the user enter the group. The entry request includes, for example, a user ID, a rating (evaluation value), a deck general parameter, deck information indicating the arrangement of the user's deck, and the like of the requesting user.

  In step S3, the grouping result is received from the server 200. The grouping result includes success or failure of the grouping, and information on other users in the group when the grouping is successful. In the present embodiment, as an example, one group is formed by three users. Therefore, information regarding the other two users is included in the grouping result and provided to the user terminal 100. The information regarding the user is, for example, a user name, a rating, a deck general parameter, and deck information.

  In the present embodiment, as an example, the main user terminal 100A in the group executes the following steps S4 to S6.

  In step S4, the battle progress unit 115 of the main user terminal 100A reads the rating and deck information of each user in the group including the user of the own terminal from the storage unit 120.

  In step S5, the battle progress unit 115 generates a cooperation team based on the acquired rating and deck information. Specifically, the battle progress unit 115 selects players constituting the cooperation team from each user's deck, or determines the turn order (hereinafter referred to as an order) for each selected player. The battle progress unit 115 generates order information indicating the selected player and the order determined for each player. The order information is a deck that defines a cooperation team.

  In step S6, the battle progress unit 115 distributes the generated order information to the other user terminals 100 (for example, the sub user terminals 100B and 100C) via the server 200.

  In step S <b> 7, the battle progress unit 115 displays a game screen on the display unit 152 for presenting the grouping result received from the server 200 and the order information generated by the user to the user before starting the battle.

  In step S <b> 8, the battle progress unit 115 communicates with the other user terminals 100 via the server 200 and advances the cooperative battle while synchronizing. In this step, when the turn of the player organized in the cooperation team comes, the operation result of the player is determined according to the input operation of the user who owns the player. Moreover, in this step, what kind of activity each player played during the match is stored in at least the storage unit 120 of the main user terminal 100A.

  In the case of YES in step S9, for example, when the baseball game is ended due to the end of the prescribed inning or the like, the battle progress unit 115 calculates the activity level of each user in consideration of the game content in step S10. . The activity level of the user is calculated according to what result the player operated by the user gave in the game.

  In step S <b> 11, the battle progress unit 115 determines a reward for each user according to the game win / loss and the calculated activity level. The battle progression unit 115 determines a reward so that a higher reward is given as the activity level is higher.

In step S12, the battle progress unit 115 grants a reward to each user. For example, giving a reward as digital content to the user A of the terminal itself is to change the status of the digital content managed in association with the user A from unusable to usable. May be. Alternatively, the digital content may be stored in at least one of the memories (memory 11 and memory 21) included in the game system 1 in association with the user identification information or the user ID. Giving a reward to other users of the user terminal 100 (for example, the user B and the user C) who are collaborators, as an example, the content of the determined reward via the server 200 and the sub user terminal 100B. It may be notified to 100C. The sub-user terminals 100B and 100C that have received the notification related to the content of the reward, like the main user terminal 100A, store the digital content as the notified reward in the memory or change the digital content state to be usable. I will let you.

  According to the above-described method, it is possible to realize a highly cooperative communication cooperative battle game in a battle game in which the order of performing a baseball game or the like is determined.

<Deck information>
5 and 6 are diagrams illustrating examples of the deck organization screen displayed on the display unit 152 of the user terminal 100. FIG. The deck defines a team of users who participate in the battle. The deck organization screen includes UI parts for the user to organize the deck. By using the UI parts, the user can form a team to compete by incorporating desired cards from the cards on hand into the deck. As an example, the deck in this baseball game is composed of two types of decks, a fielder deck and a pitcher deck, based on the defensive position division. In the present embodiment, the respective decks may be further divided using the concept of main and sub. In the baseball game, as an example, the main deck of the fielder deck is referred to as a fielder starter deck, the fielder deck sub deck is referred to as a fielder bench deck, the pitcher deck main deck is referred to as a pitcher starting deck, and the pitcher deck subdeck is referred to as a pitcher relief deck.

  The deck organization screen shown in FIG. 5 is a deck organization screen 500 for organizing a fielder deck. The deck organization screen 500 includes a fielder starting 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 designated hitter. As an example, the fielder bench deck 502 may have five frames corresponding to five reserved players.

  The deck organization screen shown in FIG. 6 is a deck organization screen 550 for organizing a pitcher deck. As an example, the deck organization screen 550 includes a pitcher starting deck 551 and a pitcher relief deck 552. As an example, the pitcher starting deck 551 may have five frames corresponding to five starting pitchers. For example, the pitcher relief deck 552 may have six frames corresponding to six relief pitchers.

  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 input operation described above via the operation reception unit 111, associates the frame with the card, and generates the correspondence as deck information.

  FIG. 7 is a diagram illustrating an example of the data structure of the deck information. The deck information is generated by the battle progress unit 115 of the user terminal 100 and stored as game information 132 in the storage unit 120 of the user terminal 100 and the storage unit 220 of the server 200.

The deck information is information indicating the correspondence between each frame in which a card (player) can be placed and the card. As an example, the deck information has a data structure in which a frame identification number for identifying each frame constituting the deck and a card ID for identifying a card are associated with each other. Further, the deck information may include items of general parameters and rarity in association with the card ID. Details of the general parameters will be described later.

  The rarity is a grade that represents the rarity value of the player represented by the card. In general, a high degree of rarity is set for a player who has a good result in a game, in particular, a player who has a high ability related to a baseball game. In the present embodiment, the degree of rarity is set by alphabets “S”, “A”, “B”, and “C” in order from the class with the highest rarity value.

  Note that the rarity is correlated with, for example, the difficulty of obtaining a card, more specifically, the degree of difficulty of a mission when it is obtained as a mission clear reward, or the price of a paid acquisition. Good. The higher the rarity of the card, the higher the difficulty of obtaining the card.

<About ability values>
In the present embodiment, the ability values set for each player include, for example, skill-specific body parameters and comprehensive parameters. The skill-specific body parameter is a value representing the physical ability of the player to be exhibited in the battle. Specifically, the skill-specific body parameter is obtained by quantifying a player's skill for each skill required in baseball. In the present embodiment, for example, as the skill-specific body parameters, there are a hitting force, a hitting force, a fastest ball speed, a ball control force, a changing ball force, a running force, a defensive force, a ball throwing force (ball throwing speed, ball throwing accuracy, etc.).

  Among the above-described skill-specific body parameters, the numerical values related to the defensive action (throwing) are the fastest ball speed, the ball control force, and the changing ball force. The higher the skill-specific body parameters of the player who functions as the pitcher (hereinafter referred to as the pitcher), the more the battle progresses.

  Among the above-described skill-specific body parameters, numerical values related to the attack action (hitting) are the hitting power and the hitting power. The higher the skill-specific body parameters of the fielder, the more advantageous the phase proceeds for the attacker. For example, the higher the hitting force, the faster the hit ball 704 is thrown away. Such a hitting result can be said to be advantageous to the attacking side. Alternatively, the higher the skill-specific body parameter of a player who functions as a fielder (hereinafter referred to as a fielder), the higher the probability that the pitcher will miss. Alternatively, the higher the body parameter by skill of the fielder, the larger the size of the meat cursor that is an object that assists the user's batting operation. As a result, the user can easily perform a batting operation for the at-bat, and an advantageous result for the attacking side can be easily obtained.

  There is a skill-specific body parameter that affects the progress of the battle, other than the defensive action or the attack action described above. For example, running power, defensive power and throwing power. The higher these skill-specific body parameters of each player constituting a team, the easier it is to obtain results that are advantageous to the team. For example, the higher the running power of the attacking player, the higher the success rate of the player's encounter and theft. For example, the higher the defensive or throwing power of the defensive player, the lower the success rate.

  The general parameter is a numerical value of the overall strength of the player regardless of the skill type, and is set for each player. The overall parameter may be referenced, for example, to compare strength between organized teams at the start of a match. Alternatively, when the confrontation between the pitcher and the batter progresses, reference may be made to compare the strength between the confronting players on a one-to-one basis. The battle may proceed in an advantageous manner against the team or the player whose overall parameter exceeds.

The battle progress unit 115 sums up the total parameters of each player constituting the team, that is, incorporated in the deck, calculates the total value of the total parameters, and based on the total value, as an index of the strength of the team , Deck general parameter Deck general parameter is calculated. The deck overall parameter may be obtained simply by summing up the overall parameters of each player placed on the deck. Alternatively, the battle progress unit 115 may obtain the deck total parameter by increasing or decreasing the total value of the above-described reference based on various factors. For example, the deck general parameters may be added by incorporating specific players having good compatibility into the deck (so-called combo). Further, for example, a deck general parameter may be added by placing a player having suitability for a specific position at that position. The deck overall parameter is a value that can be easily increased by matching the addition conditions well. The user can be urged to strategize and organize the deck so that such addition conditions are met. As a result, adopting the concept of the total deck parameter that can be increased as an element of deck organization contributes to improving the fun of the game.

<Contributor information>
FIG. 8 is a diagram illustrating an example of a data structure of the contributing player information. In the present embodiment, the contributing player information is generated by the battle progress unit 115 of the main user terminal 100A, and is stored as game information 132 in the storage unit 120 of the main user terminal 100A and the storage unit 220 of the server 200. In addition, the sub-user terminals 100B and 100C in the same group are also supplied via the server 200.

  The contributing player information has a list of contributing players for each user who is a group member. In the present embodiment, for example, a group in which a cooperative battle is performed includes three users. Accordingly, the contributing player information has three lists, a list 31, a list 32, and a list 33. As an example, list 31, list 32, and list 33 are lists of players contributed from the decks of user A, user B, and user C, respectively.

  Each list is associated with a user name or a user ID. Furthermore, each user's rating may be tied.

  The list of contributors 31 to 33 includes items of a selection frame, a card ID, and an attribute. In the present embodiment, it is preferable that the number of players contributed from each user's deck is equal and fixed. Thereby, a cooperation team can be formed fairly, and it can avoid that another user is dissatisfied by a player contributing to a specific user biased. In the present embodiment, as an example, the cooperation team includes nine fielders and six pitchers. Accordingly, the battle progress unit 115 selects three fielders and two pitchers from the decks of the group members.

  The selection frame is information for identifying a frame for arranging a player in the list of contributing players. As described above, since three fielders and two pitchers are selected for each user, in this embodiment, as an example, there are five frames of fielders 1, 2, 3 and pitchers 1, 2 as selection frames. Is provided.

  The card ID is identification information of a card representing a player. That is, the player is uniquely identified by the card ID.

  The attribute is information indicating the attribute of the player. The attribute is, for example, a position as a role in the team. In this baseball game, as an example, nine types of fielder positions including a designated batter (DH) are determined. There are two types of pitcher positions: starting and relief.

The attribute in the list of contributing players indicates in which position the player was placed in the original user's deck. For example, it is assumed that the fielder starter deck 501 shown in FIG. A catcher (player name “Yamada”) is arranged in the frame F2 corresponding to the position of the catcher.

  When the match progression unit 115 selects this catcher as the first fielder of the user A in the cooperation team, the card ID “AF1” of the catcher is displayed in the “fielder 1” frame in the list 31 shown in FIG. Store the position “catcher” as the catcher attribute. The “catcher” is a position corresponding to the frame F <b> 2 where the catcher is arranged in the fielder starter deck 501 of the user A.

  The battle progression unit 115 randomly selects players to be included in the cooperation team from a plurality of players owned by each user. For example, the battle progress unit 115 randomly selects three fielders from the fielder starter deck 501 of the user A. Also, for example, the battle progress unit 115 randomly selects two pitchers from the pitcher deck of the user A.

  As described above, in this game, a position is determined as a role in the team, and a deck for associating the position with the player is managed in association with each user. For at least a part of the cooperation team, it is preferable to randomly select players from each user's deck so that their roles do not overlap.

  Specifically, the user's own team consisting of players owned by the user and the cooperation team are defined by the deck. The deck has a predetermined number of frames in which roles constituting the team are set for each role constituting the team, and the roles of the players are set by linking players to the frames in the deck. is there. The battle progress unit 115 associates players with all the roles of the cooperation team so that the same role as the role set in the user's deck is set for the player in the cooperation team's deck. It is preferable to select a player from each user's deck.

  For example, “at least a part of the cooperation team” is a fielder frame in the cooperation team. As described above, in this baseball game, the cooperative battle is a baseball game, and the deck includes a fielder deck for linking a fielder's position and a player, specifically, a fielder starting deck 501. Yes. Therefore, the battle progress unit 115 sets the positions of the starting members (for example, nine types including the designated batter) of the fielder constituting the cooperation team in each fielder in the fielder starting deck 501 of each user. However, a fielder is selected from each fielder starting deck 501 of each user so as not to overlap in the cooperation team deck.

  Specifically, as shown in FIG. 8, it is assumed that the battle progress unit 115 randomly selects three players at each position of the catcher, the first, and the light from the fielder starter deck 501 of the user A. In this case, the battle progress unit 115 randomly selects three players from positions other than the catcher, first, and right from the fielder starter deck 501 of the user B (for example, third, center, and left). Finally, the battle progress unit 115 selects players from positions not selected so far from the fielder starter deck 501 of the user C. In the above-described example, the battle progress unit 115 selects each player of the second, designated batter, and short positions. The battle progress unit 115 randomly determines which fielder of the fielders 1 to 3 in the list is assigned to each fielder of the three types of positions.

As described above, in this baseball game, the decks defining the above-mentioned user's unique team are a pitcher starting deck 551 (starting pitcher deck) having a predetermined number of starting pitchers and a pitcher relief having a predetermined number of relief pitchers. And deck 552 (relief pitcher deck). The battle progress unit 115 selects one starting pitcher in the cooperation team from any one of the pitcher starting decks 551 of each user, and selects one or more relief pitchers in the cooperation team from the pitcher relief deck 552 of each user. To do.

  Specifically, the battle progress unit 115 randomly determines a user who contributes the starting pitcher from among the users A to C of the group members. In other words, the battle progress unit 115 randomly selects one deck from which the first pitcher is selected from the pitcher first decks 551 of the three users. For example, it is assumed that the user A is determined as a user who contributes the starting pitcher. In this case, the battle progress unit 115 selects one pitcher from the pitcher starting deck 551 of the user A and assigns it to the selection frame “pitcher 1” in the list 31. Then, the pitcher attribute is set to “starter”. Also, the battle progress unit 115 selects one pitcher from the pitcher relief deck 552 of the user A and assigns it to the selection frame “pitcher 2” in the list 32. Then, the attribute of the pitcher is set to “relief”. For user B and user C, two pitchers are selected from the pitcher relief deck 552 of each user.

  Finally, the battle progress unit 115 generates contribution player information including the lists 31 to 33 generated as described above and stores the contributed player information in the storage unit 120, as shown in FIG.

  According to the above-described configuration, the battle progress unit 115 randomly determines players to be selected as cooperation teams from the deck. That is, the user cannot freely control the players who contribute to the cooperation team. According to such a specification, the user is urged to acquire strong players without any bias in various positions or to strengthen players in various positions uniformly. This is because, in order to contribute a desired player with high ability to the cooperation team, it is more common to have a player with a certain ability or more in all positions in the deck than to bias and strengthen a specific player in a specific position. This is because it is more effective to arrange them without any problems.

  In this way, the user can be given a goal of gathering strong players in all positions, and as a result, the motivation for playing the user's game can be enhanced.

<Order information>
9 and 10 are diagrams illustrating an example of the data structure of the order information. In the present embodiment, the order information is generated by the battle progress unit 115 of the main user terminal 100A, and is stored as game information 132 in the storage unit 120 of the main user terminal 100A and the storage unit 220 of the server 200. In addition, the sub-user terminals 100B and 100C in the same group are also supplied via the server 200.

  In this baseball game, as an example, the attack times in the game proceed with the opportunity to perform a batting action while standing at the batting order in order to the selected nine fielders. Therefore, the battle progress unit 115 generates order information related to the order in which the fielder performs the batting action (hereinafter, batting order). The order information shown in FIG. 9 is order information related to the batting order.

  As shown in FIG. 9, the order information related to the batting order includes an item of a number indicating the batting order and an item of a card ID for identifying a fielder whose turn comes around in the batting order. The third column shown in FIG. 9 shows, as supplementary information, which user is in which position in which selection frame of which user in order to facilitate understanding of the invention. Therefore, the order information related to the batting order may not actually have the items in the third column.

In this baseball game, as an example, the defensive times in the game proceed by giving the opportunity to perform a pitching action while standing on the mound in order to the six pitchers selected. Therefore, the battle progress part 1
15 generates order information related to the order in which the pitcher performs the pitching operation (hereinafter referred to as the climbing order). The order information shown in FIG. 10 is order information related to the order of climbing.

  As shown in FIG. 10, the order information related to the climbing order includes an item of a number indicating the order of climbing and an item of a card ID for identifying a pitcher whose turn comes in the order of climbing. The third column shown in FIG. 10 shows, as supplementary information, which user is in which position in which selection frame of which user in order to facilitate understanding of the invention. Therefore, the order information related to the climbing order may not actually have the items in the third column.

  In this game, each user has a rating that is increased or decreased based on the result of a one-to-one person-to-person battle between users. Therefore, the battle progress unit 115 is configured so that a turn for performing a predetermined action (a hitting action or a throwing action) circulates among players owned by each user, and based on the set rating. The order of performing each operation may be determined. As an example, the battle progress unit 115 may determine the batting order so that the player with the higher rating comes first.

  The battle progress unit 115 may further determine the order of actions in consideration of attributes associated with each player. The attribute may be, for example, a parameter (for example, the above-described skill-specific body parameter) associated with each player and representing the ability of the player. Alternatively, the attribute may be, for example, a role (position) in a team assigned to the player.

  The battle progress unit 115 determines the batting order, specifically, as follows. First, the battle progress unit 115 determines the order of users based on the rating of each user. The battle progress unit 115 determines the rank so that a user with a high rating comes to the top. In the example illustrated in FIG. 8, the battle progress unit 115 determines first place: user C, second place: user A, third place: user B. Next, the battle progress unit 115 determines the batting order so that the higher the ranking of the user, the player's turn that the user owns comes first, and the user moves around for each owner's user. In the example illustrated in FIG. 8, the battle progress unit 115 first determines the fielder of the user C, then the fielder of the user A, and finally the fielder of the user B based on the above-described order, and makes three turns in this batting order. Decide that. That is, the battle progress unit 115 assigns the fielder contributed by the user C to the first, fourth, and seventh of the batting order, assigns the fielder contributed by the user A to the second, fifth, and eighth. , 6 and 9 are assigned fielders contributed by user B.

  The battle progression unit 115 may assign the batting order from No. 1 to No. 3 to the fielder with high running ability among the body parameters by skill. Also, the battle progressing unit 115 may assign a batting order from No. 4 to No. 6 to a fielder with high hitting power and hitting power.

  Specifically, the battle proceeding unit 115 first has a fielder having the highest skill-specific body parameters of hit power and batting power among the fielders 1 to 3 contributed by the user C (for example, the designated hitter shown in FIG. 8). No. 2 is assigned to the batting order No. 4. Next, the batting order No. 1 is assigned to the fielder with the highest running ability (for example, the short fielder 3 shown in FIG. 8). Finally, the batting order No. 7 is assigned to the remaining fielder (second fielder 1 shown in FIG. 8). The battle progression unit 115 assigns batting order to the fielders contributed by the remaining users A and B in the same manner based on the skill-specific body parameters.

  Thereby, while receiving all restrictions in order to generate a cooperation team fairly, the battle progress part 115 can determine the effective batting order according to the capability of each player in it. As a result, the possibility that the battle with the opponent team can be advantageously advanced can be increased, and the interest of the cooperative battle can be further enhanced.

  Note that, by determining the middle batting order (No. 4 to No. 6) based on the hitting force and the batting force, it is possible to preferentially assign players with high ability in the order of the important batting order related to the score.

  The battle progress unit 115 determines the order of climbing, specifically, as follows. First, regardless of the rating, the battle progress unit 115 assigns the first climbing order to the players selected as the starting pitchers, and the second or subsequent climbing order to each player selected as the relief pitcher based on the ratings. Assign. In the example illustrated in FIG. 8, the pitcher attribute of the selection frame “Pitcher 1” of the user A is the starter. Therefore, the battle progress unit 115 assigns the first climbing order to the pitcher 1 of the user A. That is, in determining the first climbing order, the battle progress unit 115 takes positions (starters) rather than taking into consideration the ranking based on the rating and circulating the operation opportunities equally for each owner user. Or relief). The battle progression unit 115 assigns the second and subsequent climbing orders to the relief pitchers contributed from the pitcher relief deck 552 of each user. In determining the climbing order for No. 2 and beyond, the battle progress unit 115 determines the climbing order so that the operation opportunities circulate evenly for each owner user, taking into account the rank based on the rating of each user. To do. In the example shown in FIG. 8, in the first round, the climbing order is determined in the order of user A's starting pitcher, user C's relief pitcher, and user B's relief pitcher. In the second round, the order of climbing is determined in the order of the relief pitcher of user C, the relief pitcher of user A, and the relief pitcher of user B.

  First, regarding the batting order, according to the above-described configuration, the batting order of each fielder is determined so that there are three players owned by each user and the operation opportunity circulates for each user. Therefore, all group members are given the opportunity to operate their fielders three times in a fair and orderly manner.

  Next, regarding the climbing order, according to the above-described configuration, the pitching order of each pitcher is determined so that two players owned by each user and the operation opportunity circulates for each user. Therefore, all group members are given the opportunity to operate their pitchers twice.

  On the other hand, in games such as baseball where the end condition of the game is fixed regardless of whether the batting order or the order of climbing is the same number of times, the earlier the order, the more likely the turn will be Is expensive. For example, in a baseball game, when the game ends when the player has reached the third player in the batting order, the player after the batting order No. 4 will have one turn less than the player until the third batting order. Therefore, it is difficult to make the number of appearances perfectly fair.

  Therefore, according to the above-described configuration, the batting order is determined such that the higher the rating, the earlier the player's turn is owned by the user. A high rating means that you have improved your skills. Also, it can be estimated that the user has a lot of experience in the battle depending on the height of the rating. Thus, giving a lot of operation opportunities to a user who is good at a game leads to an advantageous advancement of a cooperative battle in the cooperation team, and it is easy to obtain understanding and satisfaction from each user. Therefore, it is possible to eliminate an unfair feeling that cannot be excluded from the viewpoint of the number of times of turn.

  Regarding the order of climbing, according to the above-described configuration, only the starting pitcher has an advantage of being assigned the first climbing order, but the user who contributes the starting pitcher is randomly determined. This specification is not based on the ranking of ratings, and can give each user enjoyment from which user the starting pitcher is selected. Further, since it is not known when the starting pitcher is selected from his / her deck, the user is always urged to strengthen both the starting pitcher and the relief pitcher. As a result, the user's willingness to play a game in order to strengthen the players without bias is increased.

<Processing flow: Processing to create a cooperation team>
FIG. 11 is a flowchart illustrating a processing flow when the battle progress unit 115 of the user terminal 100 generates a cooperation team. A series of processes shown in FIG. 11 corresponds to step S5 shown in FIG.

  In step S101, the battle progress unit 115 selects a fielder from the fielder starter deck 501 of each user in the group including the user of the terminal itself. For example, the battle progress unit 115 selects players for nine positions other than the pitcher including the designated batter, that is, nine fielders. For example, the battle progress unit 115 selects three fielders from the fielder starting deck 501 of three users in the group so that positions do not overlap.

  In step S102, the battle progress unit 115 is determined by the user who contributes the starting pitcher. For example, the battle progress unit 115 randomly determines one user (for example, user A) to contribute the starting pitcher from among the group members, the user A, the user B, and the user C.

  In step S103, the battle progress unit 115 randomly selects one starting pitcher, for example, from the pitcher starting deck 551 of the user who contributes the starting pitcher. In step S104, the battle progress unit 115 randomly selects one relief pitcher, for example, from the pitcher relief deck 552 of the user (user A).

  In step S105, the battle progress unit 115 selects, for example, two relief pitchers at random from each pitcher relief deck 552 for the remaining users (user B and user C). Thus, each user who is a group member contributes three fielders and two pitchers from their own decks.

  In step S <b> 106, the battle progress unit 115 generates contributing player information (for example, FIG. 8) based on a total of 15 players selected from each user's deck.

  In step S107, the battle progress unit 115 determines the rank of the users based on the rating of each user. In the example shown in FIG. 8, it is determined that 1st place: user C, 2nd place: user A, 3rd place: user B.

  In step S108, the battle progress unit 115 acquires physical ability parameters of each selected fielder. The physical ability parameter is stored in the storage unit 120 as game information 132 in association with each player's card. The battle progress unit 115 acquires, for example, the hitting power, the striking power, and the running power of each fielder.

  In step S109, the battle progress unit 115 determines the batting order based on the user rank and the attributes of each fielder. As an example, the fielder attribute is a physical ability parameter of the fielder. Specifically, the battle progress unit 115 sets the batting order for each user in the order of user C, then user A, and finally user B for the batting order from No. 1 to No. 9. Are assigned in order. In addition, the battle progress unit 115 assigns the middle batting order (Nos. 4 to 6) of each user to a fielder having a high hitting force and hitting force. Also, the battle progress unit 115 assigns each user's first batting order (No. 1 to 3) to a fielder with high running ability. The battle progress unit 115 assigns the last batting order (7th to 9th) of each user to the remaining fielders.

In step S110, the battle progress unit 115 determines a climbing order based on the attributes of each pitcher and the rank of the user. As an example, the pitcher's attribute is a position as a role. Here, the pitcher's position is “starter” or “relief”. For example, for the first round in the climbing order, the battle progress unit 115 assigns pitchers in preference to the pitcher attributes over the user rank. Specifically, the battle progress unit 115 assigns the first climbing order to the pitcher 1 of the user A selected as the starting pitcher. The battle progress unit 115 assigns the remaining climbing orders 2 to 3 to any of the remaining pitchers of the remaining users C and B in the order of the users. The battle proceeding unit 115 assigns the climbing orders 4 to 6 in the second round to the remaining relief pitchers of each user in the order of the users.

  In step S111, the battle progress unit 115 generates order information including the batting order determined in step S109 (for example, FIG. 9) and the climbing order determined in step S110 (for example, FIG. 10). The generated order information is distributed to the user terminals 100 of other group members in step S6 of FIG. 4 and shared by each user in the group.

<Screen example>
FIG. 12 is a diagram illustrating an example of a game screen displayed on the display unit 152 of the user terminal 100. The game screen shown in FIG. 12 is a grouping result screen 600 displayed by the battle progress unit 115 in step S7 shown in FIG. The result screen 600 is a screen displayed on the main user terminal 100A of the user A as an example.

  The result screen 600 includes user information 601 to 603 for each user grouped by the server 200. Specifically, the user information 601 to 603 may include the user name and rating of each user. Thus, the user can understand that the grouping is established and the battle is started, and can confirm the information of the group members fighting together.

  When the display period of the result screen 600 expires, the battle progress unit 115 switches to the battle screen and starts progress of the battle. The battle screen that is initially displayed may include, for example, a UI for providing the user with the order information shown in FIGS. 9 and 10.

  13 to 17 are diagrams illustrating an example of the game screen displayed on the display unit 152 of the user terminal 100. FIG. The game screens shown in FIGS. 13 to 17 are battle screens displayed by the battle progress unit 115 in step S8 shown in FIG.

  FIGS. 13 to 15 show a pitching screen 700 displayed when the pitching order of pitchers contributed by the user comes around in the defensive times of the cooperation team in the battle screen. The pitching screen 700 includes a pitching operation UI described below for receiving a pitching operation by the pitching side user when the pitching order of the pitcher 703 contributed by the user is set and the manual mode is set.

  In the present embodiment, as an example, the pitching operation for determining the pitching result D1 includes a slide operation for designating a ball type, a drag operation for designating a course, and a quality control for determining pass / fail. And a tap operation that allows the pitching user to specify the timing. The quality of the pitching is determined according to the quality of the input timing of the tap operation. In other words, whether or not the pitching user can advantageously advance the battle, especially the defensive times, depends on the skill of the tap operation in the manual mode.

  When one phase (a period in which one pitching operation and a single batting operation including an oversight) is started, the battle proceeding unit 115 of the pitching user terminal first performs the first operation shown in FIG. One pitching screen 700 is generated by the UI control unit 113 and displayed on the display unit 152.

The first pitch screen 700 includes various objects arranged in the virtual space. Specifically, it includes a batter 701, a bat 702, a pitcher 703 operated by the user himself, a home base 707, and a catcher 705.

  The first pitching screen 700 may include a switching button 713 for switching the next phase to auto progress or manual progress. In the example shown in FIG. 13, the phase proceeds in the manual mode. Therefore, the switching button 713 is superimposed on the pitching screen 700 as a button for switching the next phase to auto progress.

  The first pitch screen 700 may include status information of each player who is confronting in the phase. As an example, status information 711 of the pitcher of the own team and status information 712 of the batter of the opponent team may be included.

  The first pitching screen 700 may include a ball type designation object 710 for the pitching side user to designate a ball type to be thrown by the pitcher 703 as a UI object that supports the pitching operation.

  The battle progress unit 115 determines the ball type based on the user's slide operation on the ball type designation object 710. As shown in FIG. 13, in the ball type designation object 710, ball type icons in which the ball types are associated one-to-one are arranged so as to surround the ball icon. The ball type icon includes text or an illustration showing the corresponding ball type. The UI control unit 113 may vary the types of the ball types listed in the ball type designation object 710 based on the ability of the pitcher 703.

  The operation reception unit 111 receives a slide operation in a predetermined direction with respect to the ball icon as an operation for designating a ball type. The battle progress unit 115 determines the ball type corresponding to the ball type icon arranged in the direction of the slide operation as the ball type to be thrown by the pitcher 703. For example, in the example illustrated in FIG. 13, when the user slides the ball icon upward, the battle progress unit 115 determines to cause the pitcher 703 to throw a straight. The ball type is associated with parameters for specifying the moving route of the ball 704, the ball speed, and the like. The ball type parameter includes information indicating the ball speed, the amount of change, and the direction of change. Further, the parameters of the ball type are associated with the identification information of the pitcher 703 and stored in the storage unit 120 (not shown). The battle progress unit 115 reads the determined ball type parameter from the storage unit 120 among the ball type parameters associated with the identification information of the pitcher 703, and includes it in the pitch result D1.

  When the ball type is determined, the battle progress unit 115 then causes the display unit 152 to display the second pitching screen 700 shown in FIG. The second pitch screen 700 includes a course designation object 714 instead of the ball type designation object 710. The course designation object 714 functions in combination with the cursor 715 as a UI object for causing the pitching user to designate a course (inner angle higher, lower, etc.) to be thrown by the pitcher 703.

  As an example, the course designation object 714 is obtained by dividing a rectangle corresponding to the strike zone into nine cells. Each square may be displayed in different colors on the basis of the ability of the pitcher 703, specifically, a good course and a poor course.

  The course designation object 714 includes a cursor 715 that is a sign indicating the expected arrival position of the thrown ball. While the second pitching screen 700 is displayed, the operation accepting unit 111 accepts a drag operation for designating the position of the cursor 715. When the operation receiving unit 111 receives a drag operation for moving the cursor 715, the UI control unit 113 moves the cursor 715 based on the touch position detected for the drag operation.

  The operation reception unit 111 acquires the first contact position (initial touch coordinates) of the user with respect to the touch screen 15 and the contact position (touch now coordinates) after the cursor movement operation. The UI control unit 113 determines the change direction and the change amount of the position of the cursor 715 based on the change direction and the change amount obtained as a result of comparing the acquired coordinates. As a result, the UI control unit 113 moves the cursor 715 in conjunction with the drag operation even if the cursor 715 is not touched directly or a drag operation is accepted outside the display area of the course designation object 714. Can be made. In this way, it is possible to avoid that the visual recognition of the cursor 715 is hindered by the user's finger. The display control unit 112 displays the moving cursor 715 on the second pitching screen 700 in conjunction with the movement of the cursor 715 executed by the UI control unit 113.

  The battle progress unit 115 finalizes the course by an arbitrary method. For example, it is assumed that the user continues to push strongly with a pressure equal to or higher than a predetermined threshold while the contact based on the drag operation is maintained. The battle progress unit 115 determines the position of the cursor 715 at the time when the push-in operation is accepted as a final course. Alternatively, a button (not shown) such as “Confirm Course” may be separately provided on the second pitching screen 700. The battle progress unit 115 may determine the course based on the position of the cursor 715 when the button is tapped.

  When the course is confirmed, the battle progress unit 115 next causes the display unit 152 to display the third pitching screen 700 shown in FIG. The third pitch screen 700 includes a pass / fail determination object 720. The pass / fail determination object 720 functions as a UI object for allowing the pitching user to specify the timing for determining pass / fail of the pitcher 703.

  As an example, the pass / fail judgment object 720 is formed of an arcuate belt-like gauge. The pass / fail determination object 720 includes, within the gauge, a slide bar 721 that slides in the longitudinal direction of the band, and a first area 722 and a second area 723 that define positions on the band where the slide bar 721 stops.

  The band-shaped gauge extends from the position of the pitcher 703 (hereinafter referred to as the first position) toward the position of the catcher 705 (hereinafter referred to as the second position).

  The UI control unit 113 moves the slide bar 721 from the first position (for example, the broken line frame in FIG. 15) as the initial position to the second position (for example, the position of the cursor 715 in FIG. 15) as the final position. , And move in the longitudinal direction of the band (the direction of the arrow). The animation generation unit 114 performs the animation so that the slide bar 721 passes through the second area 723 after a predetermined time from the start of movement, passes through the first area 722, and finally reaches the position of the cursor 715. Generate.

When the slide bar 721 reaches a desired position on the belt, the user performs a tap operation on the touch screen 15 so as to stop the slide bar 721 at that position. The UI control unit 113 stops the slide bar 721 at the position when the tap operation is received by the operation receiving unit 111. The battle progress unit 115 determines whether or not the ball is controlled according to the stop position of the slide bar 721. As an example, in this embodiment, the battle progress unit 115 determines that the pitcher 703 has succeeded in controlling the ball completely when the slide bar 721 stops in the first region 722, and the slide bar 721 moves in the second region 723. When it is stopped, it is determined that a pitch that is close to success has been made, and when it is stopped in other areas, it is determined that the ball control has failed. Here, “the ball is completely successfully controlled” means that the pitcher 703 makes a good pitch and the ball moves in the virtual space according to the ball type and course designated by the pitching user. “Throwing close to success” means that the ball does not follow the ball type and course specified by the pitching user, but the ball moves in the virtual space based on the ball type and course close to it. means. “Succeeded in ball control” means that the pitcher 703 has thrown away and the ball moves in the virtual space in a ball type and course that are far from the ball type and course specified by the pitching user. .

  If it is determined whether or not the ball control is good, then the battle progress unit 115 causes the display unit 152 to display a fourth pitching screen 700 (not shown). The fourth pitch screen 700 includes a pass / fail determination result. Further, on the fourth pitching screen 700, an animation in which the pitcher 703 starts pitching may be given, and the ball 704 that has been held in the pitcher 703's glove so far may be drawn. Thereby, the pitching user can immediately receive feedback regarding his / her operation performed on the third pitching screen 700.

  Note that the band-shaped gauge of the pass / fail judgment object 720 preferably has a shape such as a bow or an arch, and imitates a parabola drawn by a thrown ball. Moreover, it is preferable that the band width of the pass / fail determination object 720 is determined so as to become narrower as the band moves from the first position to the second position. Further, in the gauge, the pass / fail judgment object 720 is arranged such that the portion closest to the second position and the width of the band is the smallest, that is, the tip of the gauge overlaps the cursor 715 determined as the expected arrival position of the ball. Is preferably arranged. Thereby, the user intuitively understands the band-shaped gauge as if the ball thrown from the pitcher 703 is a path along which the ball moves toward the catcher 705 disposed at the back of the screen. From the above, the pass / fail judgment object 720 according to the present embodiment is a UI added for the purpose of enhancing the fun of the game, contrary to the purpose of reproducing the actual baseball, but the throwing screen 700 is displayed on the actual screen. It contributes to producing a throwing scene that does not feel uncomfortable without being deviated from the throwing scene.

  As described above, in the pitching-side user terminal of the pitching-side user who has reached the pitching order, the battle progress unit 115 determines the pitching operation of the pitcher 703 based on the pitching operation of the pitching-side user. The pitching result D1 indicating the determined pitching operation is supplied to the server 200 and the user terminals 100 of other users in the group.

  FIG. 16 shows the defensive times screen 800 displayed when the pitch of the pitcher contributed by the user is not the turn in the defensive times of the cooperation team in the battle screen. The defensive times screen 800 shown in the figure is a screen that is displayed on the sub-user terminal 100B of the user B during the period when the pitcher of another user (for example, the user C) is on the turn. First, a functional configuration of the user terminal 100 for generating the defensive times screen 800 will be described.

  As described above, in this embodiment, the battle progress unit 115 defines a virtual space imitating a stadium in step S8 shown in FIG. 4 and arranges objects such as each player, bat, and ball on the virtual space. , To advance the baseball game. Furthermore, in this embodiment, the battle progress unit 115 arranges a virtual camera in the above-described virtual space.

  The virtual camera is a virtual object for setting a visual field area that allows the user to visually recognize the virtual space. The virtual camera has attributes of position (XYZ coordinates), orientation, and angle of view (field of view) in the virtual space. In the present embodiment, the battle progress unit 115 can change the field of view to be visually recognized by the user by changing the position and orientation of the virtual camera. The angle of view may be fixed.

The battle progress unit 115 sets the view area based on the position and orientation of the virtual camera controlled by the battle progress unit 115 and a predetermined angle of view. Then, the battle progress unit 115 generates a view image (including a still image and a moving image) based on the view region, and displays the view image on the display unit 152. Specifically, the battle progress unit 115 causes the animation generation unit 114 to generate a view image in which an object included in the view field set in the virtual space is projected. The generated view field image is output to the display control unit 112. Under the control of the battle progress unit 115, if there is a UI part generated by the UI control unit 113, the display control unit 112 arranges it on the above-mentioned defense game screen 800 side by side or overlaid with the view image. Finally, the display control unit 112 displays the defensive screen 800 including the above-described view field image on the display unit 152.

  In the present embodiment, the battle progress unit 115 can change the position and orientation of the virtual camera based on the positions, orientations, and movements of various objects arranged in the virtual space, and the user's input operation. . The various objects include all objects arranged in the virtual space, such as players, bats, and balls.

  The defensive times screen 800 shown in FIG. 16 includes a view field image 801 as an example. The defensive times screen 800 may further include a viewpoint switching button 802, operation main information 803, and a player icon 804 as UI parts. The main operator information 803 indicates which user in the group is operating the pitcher who has come in the turn. The main operation information 803 is displayed during a period in which another user is in turn. The player icon 804 indicates who is operating each player in the view image 801. A fielder 805 to which a player icon 804 of “you” is assigned is a player operated by a user (for example, user B) of the user terminal 100 on which the defense screen 800 is displayed. With this player icon 804, the user can recognize at a glance the player that he / she is operating. The player icon 804 includes a user name and may be given to another user's player. Thereby, the user can recognize at a glance which player is operated by which user.

  The field-of-view image 801 shown in the figure is an image obtained based on a virtual camera arranged in association with a player (specifically, a fielder 805) contributed by the user B. In the present embodiment, the battle progress unit 115 may control the virtual camera based on the progress of the game. Specifically, in the present embodiment, the battle progress unit 115 controls the position and orientation of the virtual camera based on at least one of the player position and the player action. As an example, the battle progress unit 115 may determine the position and orientation of the virtual camera so as to match the viewpoint of the player. Alternatively, the battle progress unit 115 may determine the position and orientation of the virtual camera based on the position of the player so that at least a part of the player's figure is included in the view field region. The battle progress unit 115 may determine the orientation of the virtual camera so that the ball is included in the view field area from the position of the virtual camera determined based on the position of the player. That is, the battle progress unit 115 can change the position and orientation of the virtual camera following the moving player or the moving ball. According to the configuration of the battle progress unit 115 described above, the user is not only waiting for the turn, but also waiting for the turn, even if the other player's player is on the turn and the player is not operated. While I was there, I can feel the presence of participating in the game as one of the players. As a result, it is possible to realize a communication cooperation battle game with high interest.

  In this embodiment, three fielders are selected from the deck of one user. Therefore, it is preferable that the user can arbitrarily switch the position of the viewpoint based on the position of the desired fielder among the three fielders.

  Therefore, the battle progress unit 115 provides a viewpoint switching button 802 for switching the position of the virtual camera on the defense screen 800. The viewpoint switching button 802 is a UI component for the user to perform an input operation for switching the viewpoint. The operation accepting unit 111 accepts the input operation as, for example, a tap operation.

  The battle progress unit 115 switches the player serving as a reference for the position of the virtual camera based on the acceptance of the tap operation on the viewpoint switching button 802. In the example illustrated in FIG. 8, the user B contributes the 3rd base, the middle hand, and the left wing as a fielder. Therefore, each time the tap operation is performed, the battle progress unit 115 switches the reference player in order of the third baseman, the middle-ranked hand, and the left-winged hand. The viewpoint switching button 802 may include information on the position of the player currently selected as the reference.

  The battle progress unit 115 determines the position and orientation of the virtual camera based on the position and orientation of the player selected by the tap operation and, if necessary, the current position of the ball. The battle progress unit 115 causes the display unit 152 to display a view field image corresponding to the determined position and orientation of the virtual camera.

  Scenes that determine important aspects of the game often exist around the position of the ball. Therefore, the user wants to see the current movement of the battery rather than watching the game from the perspective of the player he contributed (eg, the center far from the mound) while the other user's pitcher is throwing. It can be thought of as desired. Therefore, in the present embodiment, the battle progress unit 115 may determine the position of the virtual camera based on the positions of the pitchers or catchers of other users who are climbing in addition to the positions of the players who contributed. Good. For example, when the user selects the view image 801 based on the position of another user's pitcher, the battle progress unit 115 displays the pitch screen 700 shown in FIG. 13 in a state where UI parts related to the pitch operation are not displayed. Then, it is displayed on the display unit 152. For example, when the user selects to use the position of the catcher of another user as a reference, the battle progress unit 115 arranges the virtual camera so as to face the pitcher from behind the catcher (the position of the referee) A field-of-view image 801 showing the battery may be generated.

  Thereby, in addition to the scene relevant to the position of the player to whom he contributed, the user can watch in detail the scene where the pitcher throws (throwing scene). Therefore, while waiting for a turn, it is possible to share a scene with a group member and play with a sense of unity between the group members who cooperate with each other without missing an important aspect of the game. In this case, the battle progress unit 115 switches the reference player based on the viewpoint switching button 802, and in the user terminal 100 of the user B, for example, the third baseman, the middle-ranked hand, the left-winged hand, and the current pitcher. You may go.

  FIG. 17 shows a batting screen 900 that is displayed when the batting order of the fielder contributed by the user comes around in the attack time of the cooperation team in the battle screen. The batting screen 900 is a batting order of the fielder (batter 701) contributed by the user, and when the manual mode is set, the batting operation UI described below for accepting the batting operation by the batting side user is displayed. Including.

  When one pitch is started and the pitching operation of the pitcher 703 of the opponent team proceeds, the pitching result D1 generated by the pitching user terminal or the server 200 correspondingly does not reach the hitting user terminal and the batting order. It is supplied to the user terminal 100 of another group member. When the batting user terminal receives the pitching result D1, the battle proceeding unit 115 of the batting user terminal, for example, causes the UI control unit 113 to generate the batting screen 900 shown in FIG. .

The battle progress unit 115 arranges a home base 707 between the first position and the second position in the stadium as a virtual space. The battle progression unit 115 sets an intersecting surface extending in a direction intersecting the direction from the first position toward the second position on the home base 707. The battle progress unit 115 determines whether or not the batter 701 hits the ball 704 based on the intersection plane. As described above, the intersecting surface may include, for example, a strike zone 901 and a ball zone 902 disposed outside the strike zone 901.

  When the operation accepting unit 111 accepts an operation for designating the swing timing from the user at the timing when the ball 704 thrown by the pitcher 703 arrives at the intersection, the batter 701 swings the bat 702 to cause the ball 704 to move. A hitting action can be given to the ball 704. A ball 704 shown in FIG. 17 is an example of the ball 704 that is being moved toward the intersection after being pitched by the pitcher 703.

  As shown in FIG. 17, the hitting screen 900 may include various objects in addition to the above. In particular, it is preferable to include a UI object for supporting the user's hitting operation. Examples of UI objects that support the batting operation include a timing hint object 903, a meet cursor 904, a position hint object 905, a direction hint object 906, and the like.

  The timing hint object 903 indicates to the user a good timing for the batter 701 to swing the bat 702. The meat cursor 904 indicates to the user the expected arrival position of the swung bat 702 as an area that can act on the ball 704 at the intersection when the bat 702 is swung. The meet cursor 904 is also an area referred to by the battle progress unit 115 in order to determine the hit between the bat 702 and the ball 704. The position hint object 905 indicates to the user the expected arrival position of the ball 704 thrown by the pitcher 703 on the intersection plane. A direction hint object 906 indicates to the user a change in the direction of travel of the thrown ball 704.

  In the present embodiment, as an example, the batting operation for determining the batting result D2 includes a slide operation for designating the position of the meet cursor 904 and a timing for swinging the bat 702 toward the determined position of the meet cursor 904. And a flick operation for specifying. That is, the slide operation is an operation for designating a position at which a ball is hit with respect to the pitch, and the flick operation is an operation for designating a timing for hitting, that is, a timing for swinging the bat 702. In other words, whether or not the hitting user can advantageously advance the battle, in particular, the time of the attack, depends on the skill of both the slide operation and the flick operation in the manual mode.

  When the ball 704 is thrown from the pitcher 703, the operation receiving unit 111 transitions to a state of waiting for the above-described batting operation on the batting screen 900. When the operation receiving unit 111 receives a user slide operation on the touch screen 15, the UI control unit 113 moves the meet cursor 904 in accordance with the slide operation. Note that the user may determine the best position of the meet cursor 904 with reference to the position hint object 905.

  Subsequently, the battle progress unit 115 determines whether or not the ball 704 thrown from the pitcher 703 has reached a predetermined range based on the intersection plane. That is, it is determined whether or not the thrown ball 704 has approached the intersection set on the home base 707 to a distance less than a predetermined distance. When it is determined that the ball 704 has reached less than a predetermined distance from the intersection, the UI control unit 113 may limit at least a part of the movement of the meet cursor 904. The UI control unit 113 may change the display mode such as the color or pattern of the meet cursor 904 so as to indicate that the movement is restricted.

On the hitting screen 900, an animation that moves toward the strike zone 901 is given to the thrown ball 704 by the animation generation unit 114. The user can follow the moving ball 704 with his / her eyes and perform a flick operation to designate the start timing of the swing performed by the batter 701 at the best timing when the ball 704 is deemed to have reached the home base 707. it can.

  The user can further refer to the timing hint object 903 in order to measure the best timing of the flick operation. The timing hint object 903 is displayed when the ball 704 starts to be thrown, and an animation is generated such that the ball 704 contracts toward the center of the ball 704 as it approaches the crossing surface on the home base 707. Part 114. Further, the animation is an animation that is reduced to the same size as the outline of the ball 704 at the timing when the ball 704 reaches the intersecting plane. By checking the size of the timing hint object 903, the user can measure the best timing at which a good hitting result can be obtained.

  When the operation accepting unit 111 accepts the flick operation, the battle progress unit 115 determines whether or not the batter 701 has hit the ball 704 based on at least the positional relationship between the ball 704 and the meat cursor 904 on the crossing surface at that time. judge. That is, it is determined whether or not the bat 702 swung by the batter 701 hits the ball 704 based on the user's slide operation and flick operation. For example, when the ball 704 is at least partially overlapped with the meet cursor 904 on the intersection plane, it may be determined that the batter 701 has hit the ball 704.

  Furthermore, the battle progress unit 115 may determine whether or not a hit has been given based on the timing of the flick operation specified by the operation reception unit 111. For example, even when the ball 704 and the meet cursor 904 in the crossing plane are in a positional relationship suitable for hitting, the timing of the flick operation is too early or too late relative to the timing suitable for hitting the ball 704. When doing so, the battle progress unit 115 may determine that the batter 701 did not hit the ball 704.

  Further, the battle progress unit 115 calculates a movement path when the hit ball 704 moves in the virtual space based at least on the above-described positional relationship. Specifically, the battle progress unit 115 dynamically models the collision between the bat 702 and the ball 704 based on the positional relationship described above. In this case, the velocity vector, rotation axis, rotation amount, and the like of the ball 704 immediately after colliding with the bat 702 may be acquired as initial conditions for moving the ball 704. For example, when the lower part of the ball 704 is hit with the upper part of the meet cursor 904, the angle of the hit ball is increased and the ball is fly. In addition, when the upper part of the ball 704 is hit with the lower part of the meet cursor 904, the angle of the hit ball is lowered. Further, for example, in the case of a so-called just meat where the battle progress unit 115 hits the center of the ball 704 at the center position of the meat cursor 904 (core 707 in FIG. 17), the movement such that the ball 704 flies with the liner. Calculate the route. On the other hand, in cases other than just meat, it may be determined that the hit is a hit and the movement route corresponding to the hit may be calculated. The battle progression unit 115 determines the skill-specific body parameters set in the batter 701, particularly the hitting force and the hitting force, when determining the velocity vector (such as initial velocity), the rotation axis, and the rotation amount of the ball 704. You may refer to it.

  In accordance with the movement route calculated by the battle progression unit 115, the animation generation unit 114 generates an animation of the ball 704 flying along the calculated movement route. The display control unit 112 displays the generated animation of the flying ball 704 on the display unit 152.

As described above, in the batting user terminal of the batting user whose batting order has been turned, the battle progress unit 115 determines the batting operation of the batter 701 based on the batting operation of the batting user. The hitting result D2 indicating the determined hitting action is supplied to the server 200 and the user terminals 100 of other users in the group.

  After the ball 704 moves on the field in the virtual space according to the movement route calculated based on the hit result D2, the battle proceeding unit 115 of each user's user terminal 100 follows the game program 131 in the virtual space. The movement of the ball 704, the fielder's movement to defend, the movement of the advancing runner, etc. are calculated. Then, based on the calculation result, each object is moved in the virtual space to advance the field play scene. The UI control unit 113 and the animation generation unit 114 may generate an image or animation corresponding to the calculated field play scene and display it on the display unit 152.

  Note that when the batter 701 determines that the batter 701 did not hit the ball 704, the battle progress unit 115 may omit the calculation of the movement path of the ball 704. In this case, an animation in which the batter 701 swings the ball 704 is generated by the animation generation unit 114, and the animation is displayed on the display unit 152 by the display control unit 112.

  The batting screen 900 may include status information of each character that is confronting in the ongoing phase. As an example, status information 908 of the batter 701 of the own team and status information 909 of the pitcher 703 of the opponent team may be included.

  Although not shown in the drawing, the battle progress unit 115 of the user terminal 100 of the user does not appear on the display unit 152 in the attack time of the cooperation team, while the fielder contributes the user. An attack times screen including a view field image 801 from the camera may be displayed. For example, it is possible to watch the game from the viewpoint of a fielder who is advancing to one of the bases as a runner, a fielder in the next batters circle, or a fielder on a bench. Thereby, even if it is a period when a player of another user's player turns and does not operate his / her player, the user not only waits for the turn but also waits for the turn. You can experience the realism of participating in the game as one of them. As a result, it is possible to realize a communication cooperation battle game with high interest.

  When the battle progress unit 115 displays the attack times screen including the view image 801 from the viewpoint of the runner on the display unit 152, a UI component for inputting an instruction for causing the runner to steal is displayed on the attack times screen. It may be displayed in a superimposed manner. Thereby, even if it is a period which is not a player's batting order which he operates, a user can not only wait for the turn of a hit but can taste a sense of reality participating in a game as a runner. As a result, it is possible to realize a communication cooperation battle game with high interest.

  Further, the battle progress unit 115 may further determine the position of the virtual camera based on the positions of the batters of other users standing at the batting table in addition to the positions of the contributed players. For example, when the user selects the view image 801 based on the position of the batter of another user, the battle progress unit 115 displays the batting screen 900 shown in FIG. 17 in a state where UI parts related to the batting operation are not displayed. Then, it is displayed on the display unit 152.

  Thereby, in addition to the scene related to the position of the player to whom he contributed, the user can watch in detail the scene related to the position of the batter standing at the bat (that is, the batting scene). Therefore, while waiting for a turn, it is possible to share a scene with a group member and play with a sense of unity between the group members who cooperate with each other without missing an important aspect of the game.

  FIG. 18 is a diagram illustrating an example of a game screen displayed on the display unit 152 of the user terminal 100. The game screen shown in FIG. 18 is an activity level totaling screen 620 displayed by the battle progress unit 115 at an arbitrary timing after step S10 shown in FIG.

  The aggregation screen 620 includes at least activity level information 621 indicating the activity level of each user in the group. Furthermore, the aggregation screen 620 may include rank information 622 indicating the order of descending activity. In addition, on the aggregation screen 620, the user name, the activity level information 621, and the rank information 622 may be arranged in order from the user with the highest activity level. As a result, the user can know how many points each group member including himself has gained as a result of the cooperative battle, and know his / her rank in the group activity level. Can do.

<About degree of activity>
In step S10 shown in FIG. 4, the battle progress unit 115 calculates the activity level of each group member in accordance with the content of the cooperative battle. The activity level is a numerical value indicating how much each user has contributed to producing a favorable result for the cooperation team. Specifically, the battle progress unit 115 calculates the activity level according to how the player operated by each user played an active part in the game. In the present embodiment, the activity level is calculated as follows as an example.

  For example, the battle progress unit 115 may calculate the activity level for each player owned by the user according to the player's game results, and may calculate the total activity level of each player as the user activity level. For example, in the case of a fielder, the fielder's activity may be calculated according to the number of hits, batting points, batting ratio, number of successful steals in the game, and the like. Furthermore, the battle progressing unit 115 adds a predetermined score for each hit, adds a predetermined score for each home run, and adds a score to the activity according to the batting result brought by the fielder during the match. May be calculated. Furthermore, the battle progress unit 115 may employ a deduction method for calculating the activity level, such as deducting a predetermined score for each strike and deducting a predetermined score for each double play. In other words, the activity level of each player may take a negative value, and the final activity level of the user obtained by summing up the activity levels of each player may also take a negative value. possible.

<About reward>
In step S <b> 11 shown in FIG. 4, the battle progress unit 115 determines a reward to be given to the user in accordance with the winning / losing of the game and the activity level of each user. In this embodiment, as an example, the reward is an in-game value that can be used on the game. The in-game value as a reward is, for example, a point. In the baseball game, specifically, the point is an opening point that satisfies a condition that allows a pack containing a player's card to be opened to be opened by storing a certain amount. In other words, in this baseball game, if more opening points are acquired, the opening points are accumulated earlier, the pack can be opened earlier, and if more packs are opened earlier, more players' cards are collected. The specification is acquired by the user.

  The points as rewards are not limited to the above example, but may be experience values for raising the user's level, virtual currency that can be exchanged for various items on the game, and others , It may function as an in-game value used to advantageously advance the game.

The battle progress unit 115 gives the above-described opening point to the user as a reward for playing the cooperative battle. The battle progress unit 115 determines an opening point for each user as follows. In the following, the opening point and the amount finally given to the user will be referred to as “
Rewards points ”.

  In this embodiment, the reward points are composed of basic points and bonus points as an example. The basic points are points that are uniformly given to each user and are points that do not vary from user to user.

  As an example, the battle progress unit 115 determines a basic point based on the winning or losing of the game by the cooperation team. For example, the battle progress unit 115 determines the basic points so that when the cooperative team wins the opponent team, it becomes the largest, and when it defeats the opponent team, it becomes the smallest. When the cooperation team draws with the opponent team, the battle progress unit 115 may determine the basic points so that the amount is between the above cases.

  In the present embodiment, it is preferable that the basic point does not take a negative value even when the cooperation team loses. Thereby, a negative reward point is not given to the user as a play reward. Therefore, it is possible to prevent the user from being exposed to the risk that the number of opening points accumulated so far will be reduced by the play of the cooperative battle. The risk that the user's willingness to play is eliminated is eliminated. Rather, it can be guaranteed that the number of opening points will increase if the user plays, so that the motivation to play the cooperative battle can be maintained and strengthened.

  Bonus points are points added for each user if the content is good according to the contribution of each user in the game. As an example, the battle progress unit 115 determines a bonus point for each user based on the activity level calculated for each user. In the present embodiment, it is preferable that the battle progress unit 115 determines the bonus points so that the bonus points do not take a negative value. Thereby, the above-mentioned risk can be eliminated and the motivation to play a cooperative battle can be maintained and strengthened.

  In the present embodiment, as an example, the battle progress unit 115 determines the sum of the activity level and the rank bonus as a bonus point. Since the activity progression unit 115 takes a negative value, it is preferable to determine the bonus point as 0 when the total becomes negative.

  After calculating the activity level for each user, the battle progress unit 115 ranks the users according to the activity level. In the present embodiment, the battle progress unit 115 gives each user the first, second, and third ranks in descending order of the activity level. Then, the battle progress unit 115 determines a rank bonus according to the rank assigned to each user. Specifically, the highest ranking bonus is associated with the first user, the second highest ranking bonus with the second ranking user, and the lowest ranking bonus with the third ranking user.

  The battle progress unit 115 adds the ranking bonus and the activity level for each user, and determines a bonus point for each user. Finally, the battle progress unit 115 adds bonus points for each user to the basic points, and determines reward points for each user.

  According to the above-described configuration, the battle progress unit 115 uniformly distributes the most reward points to each user when winning a match in a cooperative battle. On the other hand, the battle progress unit 115 allows the user to acquire a greater degree of activity as the user operates the player well and plays an active role in the game, and thus causes the user to acquire more reward points.

The more the player plays an active role and the more the player wins, the more opening points are accumulated, the conditions are satisfied more quickly, and the pack can be opened to obtain the player's card. As a result, in order to open the pack and take out the player's card, the user aims to obtain more opening points, and has a strong desire to play an active part in the game and win the game. You can work on it.

  In addition, giving users strong motivation for success and victory works positively for the entire cooperation team, and can match the interests of the users in the group. As a result, it can be avoided that the users are countered and the interest of the game is impaired. In addition, the mechanism of giving more rewards to users who contribute is easier to gain understanding from users, is fair in terms of the correlation between contributions and rewards, and avoids complaints from users within the group it can.

<Problems and effects to be solved by this embodiment>
As described above, the communication cooperative battle game has been difficult to realize in order to maintain fairness. For example, in a battle game based on a team game in which the opportunity to perform a predetermined action such as baseball, softball, and other various team events is given to one or more players in order It was particularly difficult to realize a cooperative battle game.

  In particular, in a battle game in which the order in which actions are performed is determined, a method for determining team formation and turn order, a method for sharing real-time information during the battle, and a method for evenly distributing rewards Etc. have not been established, and it has been difficult to realize a highly interesting communication cooperation battle game.

  In addition, when each user brings together a player who has been nurtured by the user in the process of playing the game and wants to participate in a cooperative match, maintain fairness among users, such as participation opportunities or rewards. Is very difficult.

  In response to these problems, according to the game system 1 according to the present embodiment, the battle progress unit 115 gives the number of times that the turn comes around evenly to each user, but may possibly increase the turn. The higher order is assigned to users with higher ratings. Thereby, it is possible to give each user a chance to participate fairly from the viewpoint of correlation between the strength of the user and the number of appearances.

  In addition, according to the game system 1 according to the present embodiment, the battle progress unit 115 distributes a part of the reward fairly to each user, but the remaining part of the reward has a higher contribution to the user. Grant so that you can earn many rewards. Thereby, a reward can be imparted to each user fairly from the viewpoint of the correlation between the contribution and the reward.

  In addition, by playing the game, as a reward, a player's card, a pack containing the player's card, or an item that can strengthen the player, etc. The game is played by the user. Therefore, if the user is satisfied by acquiring or strengthening a target card, the willingness to play the game is reduced, and the game may not be played gradually. In a game developed with the intention of allowing the user to play for a long time, how to deal with the problem of the user getting bored with the game is important.

In response to this problem, according to the game system 1 according to the present embodiment, the battle progress unit 115 randomly selects players to be organized into a cooperation team from the user's deck. A player in any position may be selected from the deck, and the user cannot contribute a player in any position. Thereby, so that any player may be elected by the user, it is possible to nurture a willingness to collect strong players or strengthen players without being biased in all positions. As a result, it becomes possible to maintain or further enhance the motivation of play.

[Embodiment 2]
In a communication cooperative battle game in which a plurality of users cooperate to play against an opponent team, how to group users who cooperate with each other is a very important problem from the viewpoint of improving the fun of the game. If there is a large disparity in the strength of the user's battle game, there is a possibility that dissatisfaction will be generated from both strong and weak users. Strong users may be paired with weak users and think that they can't produce good results as they think, and may lose interest in cooperative battles. On the other hand, weak users may get better results than their own ability when paired with strong users, but if their contribution to the results is low, they may get a sense of accomplishment in cooperative battles. As a result, there is a possibility that the interest of cooperative fighting may be impaired.

  Such a problem is not limited to a battle game in which an opportunity to perform a predetermined action is given to one or a plurality of players in sequence, but occurs in a battle game in general where teams of a plurality of players battle each other. is there.

  Therefore, in the present embodiment, the server 200 executes the following steps based on the game program 131. As a premise, the game based on the game program 131 is a battle game in which teams composed of a plurality of players battle each other, and the battle game is a cooperative battle in which a cooperation team operated by a plurality of users in cooperation with an opponent team plays. At least. The memory 21 of the server 200 is configured to store, for each user, players (cards) as digital contents owned by each of the users who play the game based on the game program 131. In general, the server 200 executes the game program 131 of the baseball game in such a way that a plurality of users who cooperate in the cooperative battle are at least one of a play history of each user's battle game or a player owned by each user. A step of grouping based on, a step of generating a cooperation team including at least one player owned by each of the plurality of grouped users, and a step of proceeding a battle between the cooperation team and the opponent team . In the step of proceeding with the battle, the operation of the player in the battle is determined by the user who owns the player according to the input operation performed on the computer operated by the user.

  Specifically, in step S <b> 2 shown in FIG. 4, the battle support unit 211 of the server 200 accepts the entry request transmitted by the battle progress unit 115 of the user terminal 100.

  The battle support unit 211 receives entry requests from a plurality of user terminals 100 and groups three users into one group (grouping step). The battle support unit 211 groups the three users based on the user's play history of the baseball game and at least one of the players owned by each user.

  The entry request includes at least a user ID, and based on the user ID, the battle support unit 211 reads out the play history of the requesting user and player information owned by the user from the storage unit 220. be able to. The play history is, for example, a user's battle history in at least one of an interpersonal battle and a cooperative battle of the baseball game.

  The battle history is, for example, a rating given to each user. The battle support unit 211 groups users whose assigned ratings are close within a predetermined range.

The battle history is, for example, at least one of the number of times a user has played a battle (cooperative battle, battle between humans or both), the number of wins / losses, and the win rate determined based on the number of wins / losses The numerical value which shows may be sufficient. The battle support unit 211 groups users whose numerical values satisfy a predetermined condition. For example, a user who has played a match more than a predetermined number of times has a certain level of strength, and it is estimated that there is no variation in strength among such user groups. Therefore, as an example, the battle support unit 211 may group users who have played a battle more than a predetermined number of times.

  Or the battle | competition support part 211 may group a user based on the player which each user owns. Specifically, the battle support unit 211 may group users whose strengths of players included in the deck are close within a predetermined range among players owned by each user.

  The strength of the player incorporated in the deck is, for example, the “deck comprehensive parameter” described above, and means the strength of the deck (team). As described above, each player has a comprehensive parameter that quantifies the overall strength of the player, apart from the physical parameters for each skill related to physical abilities such as shoulder strength, running power, and striking power. . As described above, the deck total parameter is obtained by basically adding up the total parameters of the players incorporated in the deck. The battle support unit 211 may group users whose deck general parameter values are close within a predetermined range based on the user's deck general parameters included in the entry request.

  Alternatively, the strength of the player incorporated in the deck may be measured, for example, by the number of cards set with a high degree of rarity among the cards of the players incorporated in the deck. Specifically, the battle support unit 211 may group users with a similar number of “S” rarity cards incorporated in the deck.

  Thereby, since users with similar strengths in a battle can be grouped, it is possible to prevent the formation of a group with a poor balance of strength (a large strength disparity). In addition, since users who are close to each other can cooperate with each other and fight against the opponent team, the user can enjoy a cooperative battle while enjoying a sense of unity and achievement. As a result, it is possible to realize a communication cooperation battle game with high interest.

  The step of progressing the battle executed by the battle support unit 211 is specifically a step of supporting each user terminal 100 that advances the battle. In the step of supporting, for example, the battle support unit 211 mediates communication of each user terminal 100, controls synchronization in the progress of the battle, and supports each user terminal 100 to advance the battle. More specifically, in order to determine the action of the player in the battle, the user who owns the player performs an input operation on the user terminal 100 operated by the user. In this case, the battle support unit 211 receives, from the user terminal 100, the operation result (the pitching result D1 or the batting result D2) indicating the operation of the above-mentioned player determined based on the input operation, and other group members To the user terminal 100. Thereby, it is implement | achieved in the step to assist according to the input operation which the user who owns this player performed with respect to the user terminal 100 which this user operates performed in the step to assist.

[Modification]
Of the series of processes shown in FIG. 4, the steps S <b> 4 to S <b> 6 related to the process of generating a cooperation team may be executed by the battle support unit 211 of the server 200. In this case, the battle support unit 211 receives entry requests from the plurality of user terminals 100 and groups three users. When the grouping is established, the battle support unit 211 acquires rating and deck information included in each user's entry request in step S4. In step S5, a cooperation team is generated based on the ratings and deck information of the three users. That is, a series of processing shown in FIG. 11 is executed. In step S111, the battle support unit 211 generates the order information related to the cooperation team, and distributes the generated order information to each user terminal 100 of each grouped user in step S6 shown in FIG. Here, the battle support unit 211 also distributes the rating and deck information of other group members other than the user to each user terminal 100 of the user.

  Further, the battle support unit 211 may execute steps S10 to S12 illustrated in FIG. 4 instead of the battle progress unit 115 of the main user terminal 100A.

  According to the above-described configuration, it is possible to reduce the processing load on some user terminals 100 (for example, the main user terminal 100A) in the group and to prevent uneven processing loads among the user terminals 100. Further, it is possible to reduce the communication between the user terminals 100 via the server 200 as much as possible and reduce the risk of communication errors.

[Example of software implementation]
The control block of the control unit 210 (particularly the battle support unit 211) and the control block of the control unit 110 (particularly the operation reception unit 111, the display control unit 112, the UI control unit 113, the animation generation unit 114, and the battle progress unit 115). ) May be realized by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like, or a CPU (Central Processing)
Unit) and may be realized by software.

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

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

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

(Item 1) The game program (131) has been described. According to an aspect of the present disclosure, the game program is executed by a computer (user terminal 100, server 200) including a processor (10, 20) and a memory (11, 21). The game based on the game program is a battle game in which teams composed of a plurality of players battle each other, and an opportunity to perform a predetermined operation is a battle game in which one or a plurality of players are sequentially given and proceed. The game program generates, in at least one of the processors, a cooperation team composed of one or more players selected from among players owned by each of a plurality of users as digital contents. Step (S5), and a step (S8) of advancing a battle between the cooperation team and the opponent team that battles the cooperation team. In the step of proceeding with the battle, the operation of the player whose turn has arrived is determined by the user who owns the player according to the input operation performed on the computer operated by the user. Thereby, there exists an effect that the communication cooperation battle game with high interest property can be implement | achieved.

  (Item 2) In (Item 1), in the generating step, players to be included in the cooperation team may be selected at random from a plurality of players owned by each user.

  (Item 3) In (Item 2), the user's own team composed of players owned by the user and the cooperation team are defined by decks, and the deck has a predetermined number of frames for each role constituting the team. And the player's role is set by associating the player with the frame in the deck, and in the generating step, the player's deck is set in the cooperation team's deck. A player may be selected from each user's deck so that the same role as the role is set for the player and so that the player is linked to all the frames of the role constituting the cooperation team.

  (Item 4) In (Item 3), the battle proceeding in the battle game is a baseball game, and the deck defining the unique team has a frame necessary for constituting a fielder starting member. In the step of generating including the fielder deck, the starting member of the fielder in the cooperation team is determined so that the fielder position set for each player in each fielder deck of each user does not overlap in the deck of the cooperation team. In addition, it is preferable to select from each fielder deck.

  (Item 5) In (Item 4), the deck defining the unique team includes a starting pitcher deck having a predetermined number of starting pitchers and a relief pitcher deck having a predetermined number of relief pitchers, and is generated as described above. In the step, one starting pitcher in the cooperation team is selected from any one of the starting pitcher decks of each user, and one or more relief pitchers in the cooperation team are selected from the relief pitcher deck of each user. It is preferable.

  (Item 6) In any one item from (Item 1) to (Item 5), the battle game is a team operated by the user in addition to the first game element in which the cooperation team battles the opponent team. And a second game element that a team operated by another user battles, and each user is set with an evaluation value that is increased or decreased based on the result of the battle in the second game element, In the generating step, the order of performing the predetermined operation is determined based on the set evaluation value so that the turn of performing the predetermined operation circulates among players owned by each user May be.

  (Item 7) In (Item 6), the battle proceeding in the battle game is a baseball game, and in the generating step, the batting order is determined so that the player with the higher evaluation value comes first. May be.

  (Item 8) In (Item 6) or (Item 7), in the generating step, the order is further determined in consideration of an attribute associated with each player, and the attribute is the ability of the player And at least one of a role in the team set for the player may be included.

(Item 9) In (Item 8), in the generating step, the first pitching order is assigned to the starting pitcher in the cooperation team, and the second and later are assigned to the plurality of relief pitchers in the cooperation team based on the evaluation value. You may assign a climbing order.

  (Item 10) In any one item from (Item 1) to (Item 9), in the step of proceeding with the battle, each player of the cooperation team and the opponent team's Each player and a virtual camera are arranged, and based on the position and orientation of the arranged virtual camera, a visual field area to be visually recognized by the user is set, and a visual field image generated based on the visual field area is Displayed on a display unit of a computer operated by a user, the virtual camera is arranged in the virtual space based on at least the position and orientation of any player owned by the user arranged in the virtual space. May be.

  (Item 11) The game program (131) has been described. According to an aspect of the present disclosure, the game program is executed by a computer (server 200) including a processor (20) and a memory (21). The game based on the game program is a battle game in which teams composed of a plurality of players face each other, and the battle game is a first game element in which a cooperation team operated in cooperation with a plurality of users battles with an opponent team. The memory is configured to store, for each user, a player as digital content owned by each user who plays the game based on the game program, and the game program is stored in the processor. Grouping a plurality of users who cooperate in the battle based on the play history of each user in the battle game and at least one of the players owned by each user, and the grouped users Select one or more players from each player In the step of generating a cooperation team composed of the selected players (S5) and a step of proceeding with the battle between the cooperation team and the opponent team, and in the step of proceeding with the battle, the movement of the players in the battle Is determined according to the input operation performed on the computer operated by the user. Thereby, there exists an effect that the communication cooperation battle game with high interest property can be implement | achieved.

  (Item 12) In (Item 11), the battle game further includes a second game element in which a team operated by a user and a team operated by another user battle each other, and the play history includes the first game It may be a battle history of a battle in at least one of the game element and the second game element.

  (Item 13) In (Item 12), the battle history is an evaluation value that is set for each user in the second game element and is increased or decreased based on a battle result. In the grouping step, Users with similar evaluation values may be grouped.

  (Item 14) In (Item 12), the battle history is a numerical value indicating at least one of the number of times the battle is played, the number of wins / losses of the battle, and the win rate of the battle, and the grouping In the step of performing, the users who satisfy the predetermined numerical condition may be grouped.

  (Item 15) In any one item from (Item 11) to (Item 14), in the grouping step, among the players owned by each user, one or more players incorporated in the user's deck Users with similar strengths may be grouped together.

  (Item 16) In (Item 15), in the grouping step, a value of a deck general parameter that means the strength of the deck calculated based on the strength of one or more players incorporated in the deck. Users who are close to each other may be grouped.

(Item 17) 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 (10, 20) and a memory (11, 21). The method is a method in which the processor executes each step described in (Item 1). The method according to (Item 17) has the same effects as the game program according to (Item 1).

  (Item 18) 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 18) has the same effects as the game program according to (Item 1).

  (Item 19) 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 server (200) including a processor (20) and a memory (21). The method is a method in which the processor executes each step described in (Item 11). The method according to (Item 19) has the same effects as the game program according to (Item 11).

  (Item 20) The information processing apparatus has been described. According to an aspect of the present disclosure, the information processing apparatus operates the storage unit (220) that stores the game program according to (Item 11) and the information processing apparatus (server 200) by executing the game program. And a control unit (210) for controlling. The information processing apparatus according to (Item 20) has the same effects as the game program according to (Item 11).

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 (computer, information processing device), 100A Main user terminal (computer, information processing device), 100B, 100C Sub-user terminal ( Computer), 110, 210 control unit, 111 operation reception unit, 112 display control unit, 113 UI control unit, 114 animation generation unit, 115 battle progress unit, 120, 220 storage unit, 131 game program, 132 game information, 133 user Information, 151 Input unit (operation unit), 152 Display unit, 200 server (computer, information processing device), 211 battle support unit, 1010 object, 1020 controller (operation unit), 1030 storage medium

Claims (18)

A game program,
The game program is executed by one or more computers including a processor and a memory,
The game based on the game program is a battle game in which teams composed of a plurality of players battle each other, and an opportunity to perform a predetermined operation is a battle game in which one or a plurality of players are sequentially given and proceed.
The game program is stored in at least one of the processors,
Generating a cooperation team consisting of one or more players each selected from among players owned by each of a plurality of users as digital content;
A step of proceeding a battle between the cooperation team and an opponent team that competes with the cooperation team; and
In the step of proceeding with the battle, a game program in which the operation of the player whose turn has been determined is determined by the user who owns the player according to an input operation performed on a computer operated by the user.   The game program according to claim 1, wherein in the generating step, players to be included in the cooperation team are randomly selected from a plurality of players owned by each user. The user's own team consisting of players owned by the user and the cooperation team are defined by a deck, and the deck has a predetermined number of frames for each role constituting the team, and the deck includes the predetermined number of frames. The role of the player is set by linking the player,
In the step of generating, the player is assigned to the same role as the role set in the user's deck in the deck of the cooperation team, and in all frames of the roles constituting the cooperation team. The game program according to claim 2, wherein a player is selected from each user's deck so as to be linked. The battle proceeding in the battle game is a baseball game, and the deck defining the unique team includes a fielder deck having a frame necessary for constituting a fielder starting member,
In the generating step, the starting members of the fielder in the cooperation team are assigned to each fielder deck so that the fielder positions set for each player in each fielder deck of each user do not overlap in the deck of the cooperation team. The game program according to claim 3, which is selected from the following. The deck defining the unique team includes a starting pitcher deck having a predetermined number of starting pitchers and a relief pitcher deck having a predetermined number of relief pitchers,
In the generating step, one starting pitcher in the cooperation team is selected from any one of the starting pitcher decks of each user, and one relief pitcher in the cooperation team is selected from the relief pitching deck of each user. The game program according to claim 4, wherein a plurality are selected. The battle game further includes a second game element in which a team operated by a user and a team operated by another user battle in addition to a first game element in which the cooperation team battles with the opponent team, Each user is set with an evaluation value to be increased or decreased based on the result of the battle in the second game element,
In the generating step, the order of performing the predetermined action is determined so that the turn of performing the predetermined action circulates among the players owned by each user and based on the set evaluation value. The game program according to claim 1, wherein the game program is determined. The battle proceeding in the battle game is a baseball game,
The game program according to claim 6, wherein in the generating step, a batting order is determined so that a player with a high evaluation value comes first. In the generating step, the order is further determined in consideration of attributes associated with each player,
The game program according to claim 6 or 7, wherein the attribute includes at least one of a parameter representing the ability of the player and a role in the team set for the player.   9. In the generating step, a first climbing order is assigned to a starting pitcher in the cooperation team, and a second and subsequent climbing order is assigned to a plurality of relief pitchers in the cooperation team based on the evaluation value. The game program described. In the step of proceeding the battle,
In the virtual space where the battle proceeds, each player of the cooperation team, each player of the opponent team, and a virtual camera are arranged,
Based on the position and orientation of the placed virtual camera, set the viewing area to be visually recognized by the user,
Displaying a view image generated based on the view area on a display unit of a computer operated by the user;
The virtual camera is arranged in the virtual space based on the position and orientation of at least one of the players owned by the user arranged in the virtual space. The game program described in. A game program,
The game program is executed by a server including a processor and a memory,
The game based on the game program is a battle game in which teams composed of a plurality of players face each other, and the battle game is a first game element in which a cooperation team operated in cooperation with a plurality of users battles with an opponent team. Including at least
The memory is configured to store, for each user, a player as digital content owned by each user who plays the game based on the game program,
The game program is stored in the processor.
Grouping a plurality of users who cooperate in the battle based on the play history of each user in the battle game and at least one of the players owned by each user;
Generating a cooperation team comprising one or more players selected from among the players owned by each of the plurality of users grouped;
Advancing a battle between the cooperation team and the opponent team,
In the step of proceeding with the battle, a game program in which the operation of the player in the battle is determined by a user who owns the player according to an input operation performed on a computer operated by the user. The battle game further includes a second game element in which a team operated by a user and a team operated by another user battle each other,
The game program according to claim 11, wherein the play history is a battle history of a battle in at least one of the first game element and the second game element. The battle history is an evaluation value that is set for each user in the second game element and is increased or decreased based on a battle result.
The game program according to claim 12, wherein in the grouping step, users having similar evaluation values are grouped. The user's own team of players owned by the user and the cooperation team are defined by the deck,
The grouping step groups users having similar deck total parameter values indicating the strength of the deck calculated based on the strength of one or more players incorporated in the deck. The game program according to any one of 11 to 13. 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. A method for a server to execute a game program,
The computer includes a processor and a memory,
12. A method in which the processor performs the steps of claim 11. An information processing apparatus,
The information processing apparatus includes:
A storage unit for storing the game program according to claim 11;
An information processing apparatus comprising: a control unit that controls the operation of the information processing apparatus by executing the game program.