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

Description

Application of Patent Law Article 30, Paragraph 2 Application name: “Professional Baseball Versus” Application version and release/update date: Ver1.1.22 August 28, 2018 Ver1.1.23 September 11, 2018 Ver1.1.23 1.24 September 20, 2018 Ver1.1.25 September 28, 2018 Ver1.1.26 October 1, 2018 Ver1.1.27 October 11, 2018 Ver1.1.28 October 2018 October 16, 2018 Ver1.1.29 October 23, 2018 Ver1.1.30 October 30, 2018 Ver1.1.31 November 12, 2018 Ver1.1.32 November 20, 2018 Ver1.1 .33 November 26, 2018 Ver1.1.34 November 29, 2018 Ver1.1.35 November 30, 2018 Ver1.1.36 December 13, 2018 Ver1.1.37 December 2018 17th

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

Patent Literature 1 discloses a technique for visualizing a user who intentionally disconnects a line in order to prevent the loss from being reflected in the ranking when the competition situation in a game becomes unfavorable.

JP 2009-247479 A

Conventional competitive games have room for avoiding a decline in the user's motivation to play the game.

One aspect of the present disclosure provides room for avoiding a decline in the user's desire to play the game.

A game program according to the present disclosure is executed by a computer having a processor. The game program instructs the processor to proceed with a match between the user and the opponent based on the user's input to the computer and communication between the computer and the server; a step of detecting that a first error has occurred in the server; a step of invalidating the match in response to the occurrence of the first error in the server; determining the outcome of the match accordingly; and not updating the first parameter, which is updated to the disadvantage of the user in response to the user's failure to win the match, if the match is invalidated; and updating the first parameter based on the result of the match when the result of the match is determined.

According to one aspect of the present disclosure, there is an effect of avoiding a decline in the user's desire to play the game.

It is a figure which shows the hardware constitutions of a game system. 3 is a block diagram showing functional configurations of a user terminal and a server; FIG. FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; 4 is a flow chart showing the flow of processing executed in the game system based on the game program according to Embodiment 1. FIG. FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; 4 is a flow chart showing the flow of processing executed in the game system based on the game program according to Embodiment 1. FIG. It is a figure which shows an example of the data structure of game information. 4 is a flow chart showing the flow of processing executed in the game system based on the game program according to Embodiment 1. FIG. FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; FIG. 4 is a diagram showing a specific example of a game screen displayed on the display unit; 9 is a flow chart showing the flow of processing executed in the game system based on the game program according to Embodiment 2. FIG. 4 is a flow chart showing the flow of processing executed in the game system based on the game programs according to Embodiments 1 and 2;

[Embodiment 1]
A game system according to the present disclosure is a system for providing a game to multiple users. The game system will be described below with reference to the drawings. The present invention is not limited to these examples, but is indicated by the scope of the claims, and is intended to include all modifications within the meaning and scope of equivalents to the scope of the claims. be. In the following description, the same reference numerals are given to the same elements in the description of the drawings, and redundant description will not be repeated.

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

The server 200 (computer, information processing device) may be a workstation or a general-purpose computer such as 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 provided in the server 200 are electrically connected to each other by a communication bus.

The user terminal 100 (computer, information processing device) may be a mobile terminal such as a smart phone, a feature phone, a PDA (Personal Digital Assistant), or a tablet computer. The user terminal 100 may be a game device suitable for playing games. 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 range sensor 18. and These components provided in the user terminal 100 are electrically connected to each other by a communication bus. Note that the user terminal 100 may include an input/output IF 14 to which a display (display unit) configured separately from the user terminal 100 main body can be connected instead of or in addition to the touch screen 15 .

Also, as shown in FIG. 1, user terminal 100 may be configured to communicate with one or more controllers 1020 . The controller 1020 establishes communication with the user terminal 100 according to communication standards such as Bluetooth (registered trademark), for example. The controller 1020 may have one or more buttons or the like, and transmits to the user terminal 100 an output value based on the user's input operation on the buttons or the like. Also, the controller 1020 may have 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 have the camera 17 and the ranging sensor 18 instead of or in addition to the user terminal 100 having the camera 17 and the ranging sensor 18 .

The user terminal 100 preferably allows the user using the controller 1020 to input user identification information such as the user's name or login ID via the controller 1020, for example, at the start of the game. 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 can hold each controller 1020 to communicate with the one user terminal 100 without communicating with other devices such as the server 200 via the network 2 . You can play multiplayer with. In addition, by connecting each user terminal 100 to each other for communication according to a wireless standard such as a wireless LAN (Local Area Network) standard (connecting for communication without going through the server 200), a plurality of user terminals 100 can realize local multiplay. You can also When the above-described multiplay is locally realized by one user terminal 100, the user terminal 100 may further include at least a part of various functions of the server 200, which will be described later. Also, in the case where multiple user terminals 100 locally implement the above-described multiplay, the multiple user terminals 100 may be provided with various functions of the server 200, which will be described later, in a distributed manner.

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

Also, the controller 1020 may be detachable from the user terminal 100 . In this case, at least one surface of the housing of the user terminal 100 may be provided with a coupling portion for the controller 1020 . When the user terminal 100 and the controller 1020 are connected by wire through the connecting 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 attachment of an external storage medium 1030 such as a memory card via the input/output IF 14 . This allows the user terminal 100 to read programs and data recorded on the storage medium 1030 . A program recorded in the storage medium 1030 is, for example, a game program.

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

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 ranging sensor 18 as an example of a mechanism for inputting information to the user terminal 100. FIG. Each unit described above as an input mechanism can be regarded as an operation unit configured to receive a user's input operation.

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

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

<Hardware components of each device>
Processor 10 controls the overall operation of user terminal 100 . The processor 20 controls the operation of the server 200 as a whole. Processors 10 and 20 include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and a GPU (Graphics Processing Unit).

The processor 10 reads a program from a storage 12, which will be described later, and develops it in a memory 11, which will be described later. The processor 20 reads a program from a storage 22, which will be described later, and develops it in a memory 21, which will be described later. Processor 10 and processor 20 execute the expanded program.

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

The program in this embodiment may be a game program for realizing a game by the user terminal 100 . Alternatively, the program may be a game program for realizing the game through cooperation between user terminal 100 and server 200 . Note that the game realized by cooperation between the user terminal 100 and the server 200 may be, for example, a game executed on a browser activated on the user terminal 100 . Alternatively, the program may be a game program for realizing the game by cooperation of a plurality of user terminals 100 . Further, the various types of data include game-related data such as user information and game information, and instructions or notifications transmitted and received between the user terminal 100 and the server 200 or between a plurality of user terminals 100 .

Storages 12 and 22 are auxiliary storage devices. The storages 12 and 22 are composed of storage devices such as flash memories or HDDs (Hard Disk Drives). Various data related to the game are stored in the storage 12 and the storage 22 .

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

The input/output IF 14 is an interface for the user terminal 100 to receive data input, and 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 physical buttons, a camera, a microphone, or a speaker of the user terminal 100, for example. The input/output IF 24 of the server 200 is an interface for the server 200 to receive data input and an interface for the server 200 to output data. The input/output IF 24 may include, for example, an input section that is an information input device such as a mouse or a keyboard, and a display section that is a device for displaying and outputting images.

The touch screen 15 of the user terminal 100 is an electronic component in which an input section 151 and a display section 152 are combined. The input unit 151 is, for example, a touch-sensitive device, and is configured by, for example, a touch pad. 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 the position where the user's operation (mainly physical contact operation such as touch operation, slide operation, swipe operation, and tap operation) is input on the input surface, and inputs information indicating the position. It has a function to transmit as a signal. The input unit 151 may include a touch sensing unit (not shown). The touch sensing unit may employ any type of system, such as a capacitive system or a resistive film system.

Although not shown, the user terminal 100 may include one or more sensors for identifying the holding posture of the user terminal 100 . This sensor may be, for example, an acceleration sensor or an angular velocity sensor. If the user terminal 100 is equipped with a sensor, the processor 10 can identify 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 vertically, the processor 10 may display a vertically long image on the display unit 152 for vertical screen display. On the other hand, when the user terminal 100 is held horizontally, a horizontal screen display may be used in which a horizontally long image is displayed on the display unit. Thus, the processor 10 may be able to switch between vertical screen display and horizontal screen display according to the holding posture of the user terminal 100 .

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

The distance sensor 18 is a sensor that measures the distance to the object to be measured. The ranging 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 hits the measurement object and is reflected. The ranging sensor 18 may have a light source that emits directional light.

Here, an example in which the user terminal 100 uses the camera 17 and the ranging sensor 18 to detect the object 1010 near the user terminal 100 and accepts the detection result as the user's input operation will be further described. The camera 17 and the ranging sensor 18 may be provided on the side of the housing of the user terminal 100, for example. A ranging sensor 18 may be provided near 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. This makes it possible to further improve the object detection accuracy based on the image captured by the camera 17, regardless of whether it is outdoors or indoors.

The processor 10 may perform one or more of the following processes (1) to (5) on the image captured by the camera 17, for example. (1) The processor 10 performs image recognition processing on the captured image of the camera 17 to identify whether or not the captured image includes the user's hand. The processor 10 may use a technique such as pattern matching, for example, as the analysis technique employed in the image recognition processing described above. (2) The processor 10 also detects a user's gesture from the shape of the user's hand. For example, the processor 10 identifies the number of fingers of the user (the number of extended fingers) from the shape of the user's hand detected from the captured image. Processor 10 further identifies the gesture made by the user from the identified number of fingers. For example, when the number of fingers is five, processor 10 determines that the user has performed the "pa" gesture. In addition, when the number of fingers is 0 (no fingers are detected), the processor 10 determines that the user has performed the "goo" gesture. In addition, when the number of fingers is two, the processor 10 determines that the user has made the "Scissors" 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 a state in which only the index finger is raised or whether the user's finger is flicking. . (4) The processor 10 detects an object 1010 (such as a user's hand) near the user terminal 100 based on at least one of the image recognition result of the captured image of the camera 17 and the output value of the distance measuring sensor 18. ) and the user terminal 100 is detected. For example, the processor 10 determines whether the user's hand is close to the user terminal 100 (for example, a distance less than a predetermined value) or far away from the user terminal 100 (for example, a predetermined value or more distance). Note that 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) When it is found 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 waving his hand in the photographing direction of the camera 17 . When an object is detected or not detected by the ranging sensor 18, which has a stronger directivity than the imaging range of the camera 17, the processor 10 detects that the user is waving his hand in a direction orthogonal to the imaging direction of the camera. recognize.

In this way, the processor 10 determines whether or not the user is clenching his/her hand (a "goo" gesture or another gesture (for example, "pa") by image recognition of the captured image of the camera 17. or) is detected. The processor 10 also detects how the user is moving the hand together with the shape of the user's hand. The processor 10 also detects whether the user is moving his/her hand closer to or away from the user terminal 100 . Such operations can correspond to operations using a pointing device such as a mouse or a touch panel, for example. 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. The continuation of the selection operation corresponds to, for example, maintaining the state in which the mouse is clicked and pushed in, or maintaining the state of being touched after performing a touchdown operation on the touch panel. Further, when the user moves his/her hand while the user's gesture "goo" is detected, the user terminal 100 performs such a series of gestures as an operation corresponding to the swipe operation (or drag operation). can also recognize. Further, when the user terminal 100 detects a gesture such as flicking a finger based on the detection result of the user's hand from the captured image of the camera 17, the user terminal 100 detects the gesture by clicking the mouse or tapping the touch panel. may be recognized as an operation corresponding to

<Game Overview>
A game executed by the game system 1 (hereinafter referred to as the game) is a game in which different results can be obtained according to the user's operation contents (for example, operation speed, timing, technique, etc.).

This game is, for example, a competitive game, and in the competitive game, the course of the game, the score, and the outcome of the competition change according to the user's operation. This game may be, for example, a game in which a plurality of users compete for superiority in terms of time, score, battle record, and the like. Users typically play games because they want to win the competition. Therefore, by including elements of competition in the game and constructing the game system 1 so that superiority is determined according to the content of the operation, it is possible to encourage the user to master the operation.

Furthermore, the present competitive game may include, for example, a game part in which interpersonal competition progresses through competition between the user and other users. Note that the "competition" in this game is not limited to multi-competition (so-called PvP (Player vs Player) competition). For example, a battle (so-called COM battle or CPU battle) between a player character operated by a user (hereinafter referred to as PC (player character)) and a non-player character (hereinafter referred to as NPC (non player character)) is also performed in this battle game. Included in "Battle". The competition in this game may be, for example, a match in a sports game.

A game system 1 according to the present embodiment is, as an example, a system for executing a competitive baseball game in which PvP battles are performed (hereinafter sometimes referred to as the main game or the main baseball game). That is, in the game system 1, a team consisting of one or more characters controllable by the user operating one computer, a team consisting of one or more characters controllable by the opponent user operating the other computer, A system for playing a baseball game.

In the case of a competitive baseball game, each team is operated by the first user terminal 100 and the second user terminal 100 communicating via the server 200 . In the competitive baseball game, each inning progresses while the teams alternate between offense and defense. In the following, when it is necessary to distinguish between the user terminal 100 operating the defending team and the attacking user terminal 100 on the top or bottom of a given inning, the former is the pitching user terminal 100A, and the latter is the batting user terminal 100A. It is referred to as a side user terminal 100B. The user terminal 100 is simply referred to when there is no need to distinguish between the two. The user of the pitching-side user terminal 100A is called a pitching-side user, and the user of the batting-side user terminal 100B is called a batting-side user. However, when there is no particular need to distinguish between the two users, and when the distinction is clear, they are simply referred to as users. The pitching user uses the pitching user terminal 100A to operate the pitching by the pitcher character, and the attacking user uses the batting user terminal 100B to operate the batting by the batter character.

The pitching-side user terminal 100A determines the pitching result according to the pitching operation received from the pitching-side user, generates data including the pitching result (the pitching 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 batting user terminal 100B. The pitching operation is an operation performed by the pitching user on the input unit 151 of the pitching user terminal 100A in order to cause the pitcher character to pitch.

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

In this baseball game, if the user does not wish to control the character himself/herself, the user can operate the user terminal 100 to notify the server 200 of that fact. Upon receiving such a notification from the user terminal 100, the server 200 determines the action result (throwing result or batting result) of the character based on various information related to the ongoing battle according to the game program. Then, the determined action result is transmitted to the user terminal 100 of the opponent. That is, the server 200 controls the character instead of the user terminal 100. FIG.

Alternatively, in this baseball game, when the user operates the user terminal 100 to input that he/she does not want to control the character by himself/herself, the user terminal 100 participates in the ongoing match according to the game program. The action result (throwing result or batting result) of the character may be determined based on various information. In this case, the user terminal 100 transmits the determined action result to the opponent's user terminal 100 via the server 200 .

Hereinafter, the mode in which the user operates the user terminal 100 to control the character by himself/herself to progress the battle will be referred to as the manual progression mode, and the mode in which the user terminal 100 controls the character according to the game program to progress the battle. It may be called an auto advance mode.

Also, the auto advance mode may further include a plurality of modes. As an example, the auto progress mode includes a partial auto mode in which the character moves according to the game program, but the user can give instructions or change characters (player substitution), and a mode related to the progress of the match. There may also be a fully automatic mode (first mode) in which all controls are performed according to the game program.

In the baseball game, teams are created by the user incorporating one or more objects into a deck. An object is digital content that has some effect on the progress of a match in this baseball game, and the strength of each user's deck composed of one or more objects at least affects the progress of the match. An object is, for example, a character such as a player, and in this baseball game, a player is represented by a display form of a card, for example.

In this baseball game, as an example, a PvP game is played, and an evaluation result (competition result such as victory/loss, result, score, etc.) for the content of the play is output. Also, in this baseball game, a reward is given for the user's playing the PvP battle. The reward is, for example, rights data for giving the user the right to acquire one or more of the objects described above. Specifically, it is a pack containing a predetermined number of player cards. By opening the pack, the user can obtain the cards enclosed in the pack. Then, the obtained card is incorporated into the deck, and the player represented by the card can be used in the battle.

In this baseball game, as an example, a pack given as a reward is not opened just by being acquired by the user. A pack is set in a slot owned by the user, and can be opened when the points counted in association with the pack reach a predetermined value. Points are awarded to the user and allocated to each pack owned by the user each time the user plays a match, also as a reward for playing the match.

The more PvP battles the user plays, the more packs he obtains and the more points he earns. That is, the more PvP battles the user plays, the more packs the user can open and the more cards (players) he or she can possess. By incorporating stronger players into the deck, the deck as a whole can be strengthened and the match can be advanced advantageously.

In this baseball game, ranks are set for packs, and winning probability tables may be generated in advance for each pack rank. In the winning probability table by rank, it is preferable that the winning probability is set such that the higher the rank of the pack, the higher the probability of winning a card of a character with a higher rarity level.

<Functional Configuration of Game System 1>
FIG. 2 is a block diagram showing functional configurations of the server 200 and the user terminal 100 included in the game system 1. As shown in FIG. Each of the server 200 and the user terminal 100 may include a functional configuration required to function as a general computer (not shown) and a functional configuration required to realize known functions in the game.

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

The server 200 has a function of communicating with each user terminal 100 and assisting the user terminal 100 in progressing the game. When the game is a multiplayer game, the server 200 may have a function of communicating with each user terminal 100 participating in the game and mediating exchanges between the user terminals 100 . The server 200 functions as a control unit 210 and a storage unit 220 through cooperation of the processor 20, memory 21, storage 22, communication IF 23, input/output IF 24, and the like.

Storage unit 120 and storage unit 220 store a game program, game information 132 and user information 133 . The game program 131 is a game program executed by the user terminal 100 . The game program 231 is a game program executed by the server 200 . Game information 132 is data referred to when control unit 110 and control unit 210 execute a game program. User information 133 is data relating to a user's account. In the storage unit 220, game information 132 and user information 133 are stored for each user terminal 100. FIG.

(Functional Configuration of Server 200)
The control unit 210 comprehensively controls the server 200 by executing the game program 231 stored in the storage unit 220 . For example, the control unit 210 transmits various data, programs, etc. 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 . If the game is a multi-play game, the control unit 210 may receive a multi-play synchronization request from the user terminal 100 and transmit data for synchronization to the user terminal 100 .

The control unit 210 functions as a battle support unit 211 according to the description of the game program 231 . 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 match support unit 211 supports the progress of the match of the game in each user terminal 100 . Specifically, the match support unit 211 communicates with each user terminal 100 to mediate communication between the user terminals 100 . Furthermore, the match support unit 211 executes matching of opponents, synchronization control for synchronizing the progress of the match, and the like.

(Functional Configuration of User Terminal 100)
The control unit 110 comprehensively controls the user terminal 100 by executing the game program 131 stored in the storage unit 120 . For example, the control unit 110 progresses the game according to the game program 131 and user's operation. Further, while the game is progressing, the control unit 110 communicates with the server 200 as necessary to transmit and receive information.

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 , a battle progression unit 115 , and a time measurement unit 116 according to the description of the game program 131 . Note that 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 accepting unit 111 detects and accepts a user's input operation on the input unit 151 . The operation reception unit 111 determines what kind of input operation has been performed from 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. do.

For example, the operation reception unit 111 performs (1) “approach operation”, (2) “release operation”, (3) “tap operation”, (4) “double tap operation”, (5) “long press operation (long touch operation)”, (6) “drag operation (swipe operation)”, (7) “move operation”, (8) “flick operation”, and other user input operations. The user's input operation determined by the operation reception unit 111 is not limited to the above. For example, if the operation reception unit 111 has a mechanism capable of detecting the amount of pressure applied by the user to the touch screen 15, the operation reception unit 111 determines the amount of pressure applied by the user.

(1) The “approach operation” is an operation by which the user approaches the touch screen 15 with a finger or the like. The touch screen 15 detects that the user's finger or the like approaches (including that the user's finger or the like touches the touch screen 15 ), and sends a signal corresponding to the detected coordinates of the touch screen 15 to the operation reception unit 111 . Output. The operation reception unit 111 determines that the touch screen 15 is in the “touch-on state” when the user's finger or the like approaches the touch screen 15 from the state in which the touch screen 15 does not detect the approach.

(2) “Release operation” is an operation by which the user stops the touch-on state. For example, when the user touches the touch screen 15 with a finger or the like and removes the finger from the touch screen 15, the operation reception unit 111 determines that the user's operation is a “release operation”. The operation reception unit 111 determines that the state has changed from the “touch-on state” to the “touch-off state” when the state in which the approach of the user's finger or the like to the touch screen 15 is detected changes to the state in which the approach is not detected. discriminate.

(3) “Tap operation” means that after the user performs an approach operation of approaching the touch screen 15 with a finger or the like, a release operation is performed at the position of the approach operation. The operation reception unit 111 changes the output of the touch screen 15 from a state in which an approach operation is not detected (a state in which the user's finger or the like is away from the touch screen 15 and the touch screen 15 does not detect the approach of the user's finger or the like). , the detected coordinates are held as the "initial touch position". When the coordinates of the initial touch position and the coordinates of the release operation are substantially the same (when the coordinates of the release operation are detected within a certain range from the coordinates at which the approach operation is detected), the operation reception unit 111 First, the user's operation is determined as a "tap operation".

(4) A “double-tap operation” is an operation in which a user performs a tap operation twice within a certain period of time. For example, if the operation reception unit 111 determines that the user's operation is a tap operation and determines that the user's operation is a tap operation again using the coordinates of the tap operation within a certain period of time, the operation reception unit 111 determines that the user's operation is a "double-tap operation." do.

(5) A “long press operation” is an operation in which the user keeps pressing the touch screen 15 . The operation reception unit 111 detects the user's operation and determines the approach operation, and if the time at which the approach operation continues at the coordinates at which the approach operation is detected exceeds a certain period of time, the operation reception unit 111 accepts the user's operation. It is determined as a "long press operation". A “long-press operation” may also be referred to as a “long-touch operation”.

(6) A “drag operation” is an operation in which a user slides a finger or the like while maintaining a close state in which the finger or the like is brought close to the touch screen 15 . A “drag operation” may also be referred to as a “slide operation”.

(7) “Move operation” refers to a series of operations in which the user performs a release operation on the touch screen 15 while maintaining the approach operation and moving the position where the finger or the like approaches the touch screen 15 . A “move operation” may also be referred to as a “swipe operation”.

(8) "Flick operation" refers to an operation in which the user performs a move operation in a time shorter than a predetermined time. A flick operation is an operation like a user flicking a finger on the touch screen 15 .

The UI control unit 113 controls UI components to be displayed on the display unit 152 to construct the UI. The UI component is a tool for the user to make inputs necessary for progressing the game to the user terminal 100, or a tool for obtaining information output from the user terminal 100 during the progress of the game. Examples of UI components include, but are not limited to, icons, buttons, lists, and menu screens.

In addition, the UI control unit 113 controls the display mode of UI components for assisting the pitching operation or the batting operation during the match progressing. The UI components that support the batting operation include, for example, a timing hint object that indicates good batting timing, a ball thrown by the pitcher character, a direction hint object that indicates a change in the direction of the pitch, and a target position for the pitch. There are location hint objects, and a contact cursor for judging the contact between the bat and the ball. UI objects that support the pitching operation include, for example, a pitch selection object, a course presentation object, a course selection object, and a pitch timing object.

The animation generation unit 114 generates animation showing the motion of each object based on the control mode of various objects including the UI parts described above. For example, animation of a pitcher's pitching motion, animation of a batter's batting motion, animation of a bat swung by the batter, animation of a ball thrown by a pitcher, animation of a ball hit by a batter, animation of a runner stealing a base, etc. are generated. You may

The display control unit 112 outputs to the display unit 152 of the touch screen 15 a game screen on which the processing results executed by the elements described above are reflected. For example, the display control unit 112 causes the display unit 152 to display an operation character that can be operated by the user. Also, the display control unit 112 may display the 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 above-described UI object superimposed on the game screen.

The competition progression unit 115 transmits and receives data to and from the server 200 to progress the competition with the opponent user. In addition, the competition progression unit 115 controls the UI control unit 113, the animation generation unit 114, and the display control unit 112 to provide the user with the above-described UI necessary for the user to play the baseball game. The battle progression unit 115 causes the UI control unit 113 or the animation generation unit 114 to generate a game screen including UI components. The battle progression unit 115 causes the display control unit 112 to display the generated game screen on the display unit 152 . This implements a UI for the user to play the baseball game.

The time measurement unit 116 controls a counter (not shown) to measure the time that has elapsed since a certain event occurred during game play. As an example, if an error (first error) that disables communication between the user terminal 100 and the server 200 occurs while the match is in progress, the time measurement unit 116 can Measure elapsed time. The occurrence of the error is detected by the battle proceeding unit 115, for example. The battle progression unit 115 may detect the error by receiving the HTTP response status code “503 Service Unavailable”, for example. Also, the error is, for example, the occurrence of a so-called server down in the server 200 . Hereinafter, the error will be described assuming that the server is down.

In addition, the time measurement unit 116 determines whether or not a predetermined time (first time) has passed since the server down occurred.

Note that the functions of the server 200 and the user terminal 100 shown in FIG. 2 are merely examples. The server 200 may have at least some of the functions that the user terminal 100 has. Also, the user terminal 100 may have at least part of the functions of 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 perform part of the processing in the game system 1 . That is, the computer that executes the game program in this embodiment may be any of the user terminal 100, the server 200, and other devices, or may be realized by a combination of a plurality of these devices.

<Processing before battle>
When the user inputs a predetermined operation, for example, tapping an icon of the game displayed on the display unit 152 , the game starts on the user terminal 100 . As an example, control unit 110 displays a home screen (not shown) on display unit 152 . The home screen is a screen that is displayed first after starting the game, and is, for example, a screen that includes a UI that accepts a tap operation for starting each mode included in the game.

FIG. 3 is a diagram showing a specific example of a game screen displayed on the display unit 152 of the user terminal 100. As shown in FIG. As an example, when the operation reception unit 111 determines that a tap operation has been input to the UI for starting a PvP battle displayed on the home screen, the control unit 110 displays the battle start screen 310 shown in FIG. Displayed on the display unit 152 . Henceforth, when simply referring to a "match", the "match" refers to a PvP match.

In this game, before the start of the competition, a district to serve as a base for the own team (hereinafter referred to as a base district) may be selected from a plurality of districts. The multiple districts are, for example, 46 districts, each of which is 46 prefectures excluding Tokyo, out of the 47 prefectures in Japan, and 2 districts that divide Tokyo into districts 1 and 2. It can be a district. The user can arbitrarily select the district where his team is based from among the 48 districts. After a tap operation is input to the UI for starting a battle, the control unit 110 may display a screen that prompts the user to select a base district before displaying the battle start screen 310 .

The battle start screen 310 is an example in which the user has set Ibaraki Prefecture as the base district of his/her own team. As an example, each of the 48 districts has a ballpark set as a competition venue. A ballpark defines a virtual space in which a baseball game takes place. The match progresses in either the ballpark set in the base district selected by the user or by the opponent user. Ballpark specifications in at least some districts may be unique to each district. The specifications of the stadium are determined by various parameters that affect the progress of the match. Specifically, it is the size of the stadium, the presence or absence of a roof, the height of the roof, and the like. The width parameter affects the ease of hitting a home run. The parameters of the roof influence the trajectory of the hit ball, the hitting result, and the like.

In the present embodiment, 12 of the 48 districts may have stadiums modeled after franchise stadiums of actual professional league teams (hereinafter referred to as franchise stadiums). For some of the remaining 36 districts, ballparks imitating real ballparks with names may be set. A fictitious ballpark having common specifications may be set for the rest of the districts.

(matching)
As an example, when the base area of the own team is selected, it becomes possible to compete with other users. The battle start screen 310 includes a battle start UI 311, and when the operation reception unit 111 determines that a tap operation to the battle start UI 311 has been input, the battle progression unit 115 performs matching of opponents. Specifically, the match proceeding unit 115 transmits a matching request to the server 200 in response to the tap operation. A matching request is a message requesting the server 200 to search for another user terminal 100 as an opponent so that a match can be played with a user of another user terminal 100 .

The match support unit 211 of the server 200 searches for an opponent in response to the matching request. Matching (searching) of opponents is performed based on at least the rating (evaluation value) given to the user. Specifically, the match support unit 211 matches users with similar ratings. The rating is a value that is updated according to the match result. Therefore, by referring to the ratings, the match support unit 211 can basically match users whose abilities are evenly matched. Note that the match support unit 211 may be configured to perform matching based on another user information 133 in addition to the rating. The configuration will be detailed later.

(Rating)
As an example, the match support unit 211 increases or decreases the rating as follows according to the win or loss of the match.

The rating calculation and update processing may be executed by the battle support unit 211 of the server 200 or by the battle progression unit 115 of the user terminal 100 (client, computer). In any case, the latest rating given to the user is shared between the server 200 and the user terminal 100 .

In the following description, as an example, the server 200 updates the rating given to the user.

The match support unit 211 manages the rating referred to for matching the match against each user. The match support unit 211 updates the rating of each user after the match, for example, based on the difference value between the ratings of the users before the match and the win or loss of the match for the users who have played the match by matching.

The match support unit 211 sets, for example, a value of “1500” to each user as an initial value. When user X and user Y play a match, user X wins and user Y loses, the rating after the match is updated according to Equations 1 and 2 below.

[Formula 1] Rating of the user on the winning side (user X) after the match = Rating of the user on the winning side (user X) before the match + 32 + (Rating of the losing side (user Y) - Winning side (user X) rating) x 0.04
[Formula 2] Rating of the losing user (user Y) after the match = Rating of the losing user (user Y) before the match - 32 + (Rating of the losing side (user Y) - Victory side (user Y) X) rating) x 0.04
A range (upper limit and lower limit) may be provided for the rating that fluctuates before and after the match. For example, the range of varying ratings may be set to a maximum value of "64" and a minimum value of "4". If the difference in ratings between competing users is excessively large, and the ratings are calculated according to Equation 1 or Equation 2, the rating of the user with the higher rating will decrease despite winning, and the winning user will be dissatisfied. A situation can occur. Therefore, by setting the maximum and minimum values for the range of fluctuation from the rating before the battle, such a situation can be avoided and the user's sense of satisfaction can be improved.

Returning to the description of matching again. The match support unit 211 returns the matching result to the user terminal 100 . When an opponent is found and matching is established, the battle support unit 211 distributes the matching result to each of the user terminal 100 operated by the requesting user and the user terminal 100 operated by the opponent user. . The matching result contains the information of the opponent. When a time-out occurs without finding an opponent, the competition support unit 211 transmits a matching result including a notification that an opponent has not been found to the user terminal 100 of the user who made the request.

The match support unit 211 may be configured to execute matching based on the strength of the team (deck) in addition to the rating.

(deck)
A deck is, for example, a UI for organizing a team (hereinafter referred to as own team) to participate in a PvP battle. A user can form his or her own team by incorporating desired cards from the cards in hand into the deck. The decks in this baseball game are, for example, composed of two types of decks, a fielder's deck and a pitcher's deck, based on defensive position classification. In addition, in this embodiment, the decks of each division may be further divided by adopting the concept of main and sub. In this baseball game, for example, the main deck of the fielder deck is called the starting lineup deck, the sub-deck of the fielder deck is called the bench deck of the pitcher, the main deck of the pitcher deck is called the starting pitcher deck, and the sub-deck of the pitcher deck is called the pitcher relief deck.

The fielder starting lineup deck has slots corresponding to each of the eight defensive positions excluding the pitcher and slots corresponding to the designated hitter. A fielder's bench deck, as an example, may have five slots corresponding to five reserve players. A starting pitcher deck, as an example, may have five slots corresponding to five starting pitchers. A pitcher relief deck may have, as an example, six slots corresponding to six relief pitchers.

As an example, when the operation reception unit 111 determines that a tap operation has been input to the UI for starting deck formation displayed on the home screen, the control unit 110 displays the deck formation screen (not shown). Displayed on the display unit 152 . The deck formation screen for forming the fielder's deck and the deck formation screen for forming the pitcher's deck may be different screens. In this case, the user displays the other deck organization screen by, for example, inputting a predetermined operation to the input unit 151 while one deck organization screen is displayed (that is, the two deck organization screens can be switched). The user uses the input unit 151 to perform an input operation for linking a desired card in hand to each frame while the deck formation screen is displayed. The battle progression unit 115 receives the above-described input operation via the operation reception unit 111, associates the frame with the card, and generates the correspondence as deck information.

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

The rarity is a grade representing the rarity value of the player represented by the card. In general, a high rarity level is set for a player who brings good results in the game, especially in the play part, that is, a player who has high ability in a baseball game. In this embodiment, rarity levels are set by alphabets of "S", "A", "B", and "C" in descending order of rarity value.

Note that the rarity level may be correlated with, for example, the difficulty of obtaining a card, or the price in the case of paid acquisition. The higher the rarity of the card, the more difficult it is to obtain the card.

(strength of deck)
In this baseball game, an ability value is set for each player. Ability values include physical parameters by skill and general parameters. The skill-specific physical parameter is a value representing the physical ability of the player exhibited in the match. Specifically, the skill-specific physical parameters are values obtained by quantifying a player's skill for each skill required in baseball. In this embodiment, for example, physical parameters by skill include hitting power, hitting power, fastest ball speed, ball control power, breaking ball power, running power, defensive power, throwing speed, throwing accuracy, and the like.

On the other hand, the comprehensive parameter is a numerical value representing the comprehensive strength of the player represented by the card in the progress of the match regardless of the type of skill, and is set for each card. The comprehensive parameter is referred to by the battle progression unit 115 and the battle support unit 211 during the progress of the battle, and affects the progress of the battle. Specifically, in this baseball game, the higher the general parameters of the players included in the deck, the more advantageous the battle progresses.

After the deck information generated by the battle proceeding section 115 is saved in the storage section according to the user's input operation, the battle proceeding section 115 next generates deck meta information based on the deck information. Deck meta information includes at least overall deck parameters, which will be described later.

The deck meta information includes, for example, items such as overall deck parameters, average value, and number of S rares. Each of these items is determined by the battle progression unit 115 based on the deck information generated earlier.

A deck general parameter is a value calculated based on the general parameter of each player in the deck. The higher the general parameter of each player in the deck, the higher the calculated total deck parameter. Since it can be said that the higher the general parameter of each player, the stronger the deck (team) in the battle, the higher the overall deck parameter. The average value is the average value of the overall parameters of each player in the deck. The higher the average value, the more cards of strong players are placed in the deck. The number of S rare cards is a value indicating how many "S" cards with the highest card rarity rank exist in the deck. High ability values are set for players with S-ranked cards, allowing them to proceed with the match in an advantageous manner. If you place many such S-rank players in your deck, you can strengthen your deck accordingly.

As described above, the overall deck parameter, the average value, and the number of S rares can be used as an index representing the strength of the deck (hereinafter referred to as a deck strength index).

The match progressing unit 115 calculates deck general parameters based on the general parameters of each player included in the deck.

For example, the match proceeding unit 115 may calculate the total value of the general parameters of each player in the deck, and use the obtained total value of the general parameters as the deck general parameter. The match progressing unit 115 may calculate the overall deck parameter by summing the overall parameters of the players in all four types of decks, or by summing up only the overall parameters of the players in the main deck. may The main deck is, for example, a starting fielder deck and a starting pitcher deck.

Furthermore, the match progression unit 115 may identify the correlation between players based on other parameters set for the players included in the deck. Then, the match proceeding unit 115 may calculate the overall deck parameter by performing a plus or minus correction on the above total value based on the specified correlation. For example, when two players who are correlated with good compatibility are organized into a deck, the match progression unit 115 may calculate the overall deck parameter by adding a predetermined value to the above total value. Good (so-called combo). The overall deck parameter is a value that can be easily raised if the addition conditions are well matched, and matching such addition conditions also contributes to improving the interest of the game, especially deck formation.

Matching based on both rating and deck strength may be performed when the user is unskilled. The non-skilled player includes a beginner who has played a small number of matches, and an inexperienced player who has played many times but has not mastered the operations related to the match and has not improved his skills. Non-experts are given relatively low ratings. On the other hand, if the user is an expert, matching may be based solely on ratings. An expert refers to a user who has played many battles in this game, is accustomed to operations related to battles, and has improved his skills.

The user base where many non-experts gather (the group of users around the initial rating value) is a mixture of beginners who have just started playing and inexperienced players who have a lot of playing experience but cannot get out of the high rating group because they do not improve. are doing. Experienced novices, although their game skills are poor, are more likely to earn a lot of rewards and have a lot of strong players by playing a lot of times. Therefore, it is possible to organize a strong deck. On the other hand, a beginner who has just started the game has a limited number of players at the beginning of the game, and it is difficult to organize a strong deck. Due to the above circumstances, the disparity in deck strength is conspicuous among users around the initial rating value, where many beginners gather.

In such a group of non-experts, if matching is performed based only on ratings, there is a possibility that beginners will be matched with experienced novices. And such matching is likely to create a very large disparity in terms of deck strength.

In a competitive game such as this baseball game, in which the strength of the deck that is organized has some effect on the progress of the match, not only the user's game skill but also the strength of the deck is important in determining the result of the match. can be an important element. Therefore, unreasonable matching that causes a difference in deck strength discourages users whose deck strength is inferior even before the battle. Moreover, even if the battle actually progresses, it may become a one-sided game, which significantly reduces the interest of the game.

Matching based on both the rating and the strength of the deck when the user is an unskilled player can solve such problems. That is, for non-experts with a marked difference in decks, not only the ratings but also users with similar deck strengths are matched. As a result, it is possible to avoid unreasonable matching and prevent loss of interest in the game.

Specifically, it has the effect of avoiding unreasonable matching and avoiding disincentive of a user with an inferior deck in terms of strength before playing. This effect is particularly advantageous in a game such as this baseball game in which comparison results of deck strengths are presented before the start of a match. When the deck strength comparison result is presented immediately before the start of a battle, in a confrontation between users whose deck strengths are nearly even, each user assumes that their deck strengths are nearly even. It can be understood. Since each user starts a match with the understanding that victory or defeat is determined by skill, the user's motivation to play can be enhanced.

(Match record)
Referring to FIG. 3 again, the explanation of the battle start screen 310 will be resumed. The match start screen 310 may include a UI showing the user's match results. This user's match record may be accumulated for each district. The match record includes, for example, the number of current winning streaks (first parameter), the highest number of winning streaks, and the number of wins and losses.

The number of current winning streaks indicates the number of consecutive wins based on the region at the present time. Therefore, if you lose a battle while using this area as your base, the number of wins will be reset to 0. In addition, even if the game is tied in a state where the area is used as a base, the game may be reset to 0 wins. A UI 312 is a UI that indicates the current winning streak. In other words, the current winning streak can be expressed as a parameter that is updated to the user's disadvantage if the user fails to win the match.

Highest winning streak is the longest current winning streak ever recorded in that district. Therefore, the maximum winning streak will not be reset even if you lose. When the latest current winning streak exceeds the maximum winning streak, the maximum winning streak is updated to the latest current winning streak.

<Processing during battle>
FIG. 4 is a flow chart showing the flow of processing executed by each device included in the game system 1 based on the game program 131. As shown in FIG. In the flowchart shown in FIG. 4, the processing executed by the user terminal 100 is divided into processing executed by the pitching user terminal 100A and processing executed by the batting user terminal 100B. A series of processes shown in FIG. 4 is started when the server 200 establishes matching between the pitching user terminal 100A and the batting user terminal 100B.

In step S101, the battle support unit 211 of the server 200 initializes the situation information. The status information is information indicating the progress of the battle, and is particularly important information that determines the outcome of the battle. Examples of the status information include "Inning" indicating the inning in progress, "Score" indicating the score of each team, "Runner" indicating which base the runner is on, "Out Count", and "Ball Count". including. The initialized status information indicates the progress of the match at the start of the match. In step S102, the match support unit 211 transmits a notification that matching has been established and the initialized situation information to each user terminal 100, and starts the match.

At steps S103 and S104, the battle progression unit 115 of each user terminal 100 receives the initialized situation information and starts progressing the battle.

In step S105, the battle support unit 211 synchronizes the phase start. Along with this, the match progress unit 115 of the pitching-side user terminal 100A starts progress of the phase in step S106 and causes the display unit 152 to display the pitch screen.

In step S107, the operation reception unit 111 receives a pitching operation from the pitching user. In step S108, the match progressing unit 115 determines the type of pitch, the course, and the content of pitching, such as whether or not the pitch is good, based on the pitching operation. In step S<b>109 , a pitching result D<b>1 including information indicating the determined pitching content is generated, and the pitching result D<b>1 is transmitted to the server 200 .

(Throwing screen)
FIG. 5 is a diagram showing a specific example of a game screen displayed on the display unit of the user terminal. Specifically, the game screen is a pitching screen 600 representing a pitching scene of the pitcher character. The pitching screen 600 includes a pitching operation UI described below for receiving a pitching operation by the pitching side user when the ongoing phase is the manual progression mode.

Pitching operations include, for example, a slide operation for specifying the type of pitch, a drag operation for specifying the course, and a tap operation for allowing the pitching user to specify the timing for determining the quality of ball control. be The quality of the pitch is determined according to the quality of the input timing of the second tap operation. In other words, in the case of the manual progress mode, whether or not the pitching user can proceed with the match, especially the defense, depends on the skill of the tapping operation.

When one phase is started, first, the match proceeding unit 115 of the pitching user terminal 100A causes the UI control unit 113 to generate the pitch screen 600 shown in FIG.

The pitching screen 600 includes various objects placed in the virtual space. Specifically, it includes a batter character 601 and a bat 602 operated by the other user, a pitcher character 603 operated by the user, a home base 607 and a catcher character 605 .

The pitching screen 600 may include a switch button 613 for switching the next phase to the auto progress mode or the manual progress mode. In the example shown in FIG. 5, the phase is proceeding in manual progression mode. Therefore, the switch button 613 is superimposed and displayed on the pitching screen 600 as a button for switching the next phase to the auto advance mode.

The pitching screen 600 may include status information for each character in the duel. As an example, the pitching screen 600 may include status information 611 of the pitcher character of the own team and status information 612 of the batter character of the opposing team.

The pitching screen 600 may include status information indicating the current status of the match. As an example, the situation information includes inning information 631 indicating the current inning, runner information 632 indicating the presence or absence of runners at each base, score information 633 indicating the current score of each team, and count indicating the current ball count and out count. Information 634 may be included.

The pitching screen 600 may include, as a pitching operation UI, a pitch specification object 610 for the pitcher user to specify the pitch to be thrown by the pitcher character 603 .

As an example, the match progression unit 115 determines the type of pitch based on the user's slide operation on the pitch designation object 610 . As shown in FIG. 5, in the pitch type designation object 610, pitch type icons are arranged so as to surround the ball icon in a one-to-one correspondence with the pitch type. The pitch type icon includes text, an illustration, or the like indicating the associated pitch type. The UI control unit 113 may change the type of pitch listed in the pitch designation object 610 based on the ability of the pitcher character 603 .

As an example, the operation receiving unit 111 receives a sliding operation on the ball icon in a predetermined direction as an operation for specifying the type of pitch. The match progression unit 115 determines the pitch type corresponding to the pitch type icon arranged in the direction of the slide operation as the pitch type to be thrown by the pitcher character 603 . For example, in the example shown in FIG. 5, when the user slides the ball icon upward, the match progression unit 115 determines to have the pitcher character 603 throw a straight. The type of pitch is associated with parameters for specifying the movement path of the ball 604, the speed of the ball, and the like. The parameters of the type of pitch include information indicating the speed of the ball, the amount of change, and the direction of change. Also, the parameter of the type of pitch is associated with the identification information of the pitcher character 603 and stored in the storage unit 120 (not shown). The match progressing unit 115 reads out parameters of the determined pitch type from the parameters of the pitch type associated with the identification information of the pitcher character 603 from the storage unit 120, and includes them in the pitching result D1.

After the type of pitch is determined, the match proceeding unit 115 causes the display unit 152 to display the next pitch screen (not shown). In addition, hereinafter, the pitching screen may be referred to as a second pitching screen. The second pitch screen includes a course designation object instead of the pitch designation object 610 . The course designation object functions as a UI object for allowing the pitcher user to designate a course for the pitcher character 603 to pitch by combining with a cursor, which will be described later.

For example, the course designation object is obtained by dividing a rectangle corresponding to the strike zone into nine squares. Each square may be color-coded and displayed based on the ability of the pitcher character 603, specifically, a good course and a weak course.

The course designation object includes a cursor, which is an indicator indicating the expected position of the thrown ball. While the second pitching screen is being displayed, the operation accepting unit 111 accepts a drag operation for specifying the position of the cursor. When the operation reception unit 111 receives a drag operation for moving the cursor, the UI control unit 113 moves the cursor based on the touch position detected for the drag operation.

The operation reception unit 111 acquires the user's initial contact position (initial touch coordinates) on the touch screen 15 and the contact position (touch now coordinates) after the cursor movement operation. The UI control unit 113 determines the direction of change and the amount of change of the cursor position based on the direction of change and the amount of change obtained as a result of comparing the acquired coordinates. As a result, the UI control unit 113 can move the cursor in conjunction with the drag operation even if the cursor is not directly touched or even if the drag operation is accepted outside the display area of the course designation object. can. In this way, it is possible to prevent the cursor from being obstructed by the user's finger. The display control unit 112 displays the moving cursor on the second pitching screen in conjunction with the movement of the cursor executed by the UI control unit 113 .

The battle progression unit 115 determines the course by any method. For example, assume that the user continues to perform a strong pressing operation with a pressure equal to or greater than a predetermined threshold while maintaining contact based on the drag operation described above. The battle progression unit 115 determines the position of the cursor at the time when the pushing operation is accepted as the final course. Alternatively, a button (not shown) such as "Determine course" may be separately provided on the second pitching screen. The battle proceeding unit 115 may determine the course based on the position of the cursor when the button is tapped. Further, the battle progression unit 115 may determine the course based on the position of the cursor when the user releases the contact based on the drag operation described above. Further, the battle progression unit 115 may determine the course based on the position of the cursor when the user inputs the tap operation after canceling the contact based on the drag operation described above.

After the course is determined, the match progressing unit 115 causes the display unit 152 to display the next pitching screen (not shown). In addition, hereinafter, this pitching screen may be referred to as a third pitching screen. The third pitching screen includes a pass/fail judgment object. The quality determination object functions as a UI object for allowing the pitcher user to specify the timing for determining whether the pitcher character 603 is controlling the ball well or not.

As an example, the pass/fail judgment object is composed of an arcuate belt-shaped gauge. The pass/fail determination object includes within the gauge a slide bar that slides in the longitudinal direction of the strip, and first and second regions that define positions on the strip at which the slide bar stops.

The band-shaped gauge extends from the position of the pitcher character 603 toward the position of the catcher character 605 . The UI control unit 113 moves the slide bar in the longitudinal direction of the strip from the first position, which is the initial position, toward the second position, which is the final position. The animation generation unit 114 generates an animation such that the slide bar 621 passes through the second area after a predetermined time from the start of movement, passes through the first area, and finally reaches the position of the cursor.

For example, when the slide bar reaches a desired position on the band, the user performs a tap operation on the touch screen 15 so as to stop the slide bar at that position. The UI control unit 113 stops the slide bar at the position when the tap operation is accepted by the operation accepting unit 111 . The match progression unit 115 determines whether the ball control is good or bad according to the stop position of the slide bar. As an example, in the present embodiment, the match progression unit 115 determines that the pitcher character 603 has completely succeeded in controlling the ball when the slide bar stops in the first area, and determines that the slide bar has stopped in the second area. , it is determined that the ball has been thrown close to success, and if the ball is stopped in other areas, it is determined that the ball has failed to be controlled. Here, "completely successful in controlling the ball" means that the pitcher character 603 throws well and the ball moves in the virtual space according to the pitch type and course specified by the pitching user. "A nearly successful pitch is made" means that the ball moves in the virtual space based on the pitch type and course that are close to the pitch type and course specified by the throwing user. means. “Failing to control the ball” means that the pitcher character 603 misses the pitch and the ball moves in the virtual space with a pitch type and course that is far from the pitch type and course specified by the pitching user. do.

Note that the operation for stopping the slide bar is not limited to the tap operation. For example, if the operation for determining the course is a pushing operation, the operation for stopping the slide bar may be a releasing operation.

Moreover, it is preferable that the band-shaped gauge of the pass/fail judgment object 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 width of the band of the pass/fail judgment object is set so as to become thinner as it moves from the first position to the second position. In addition, the good/bad judgment object is arranged so that the portion of the gauge closest to the second position and where the width of the band is narrowest, i.e., the tip of the gauge, overlaps the cursor determined as the expected position of the ball to reach. preferably. As a result, the user intuitively understands the belt-shaped gauge as if it were a path along which the ball thrown by the pitcher character 603 moves toward the catcher character 605 arranged at the back of the screen. As described above, the pass/fail determination object according to the present embodiment is a UI added for the purpose of increasing the interest of the game, contrary to the purpose of reproducing real baseball. It contributes to producing a pitching scene that does not look out of place without diverging from the scene.

When the ball control is judged to be good or bad, the competition progressing unit 115 further determines the course on which the ball is pitched, the speed of the ball, and, if the type of pitch is a breaking ball, the amount of change, based on the judgment result of the quality of the claim. , are included in the pitching result D1, and the pitching result D1 is transmitted to the server 200. FIG. Next, the match proceeding unit 115 causes the display unit 152 to display the next pitch screen (not shown). In addition, hereinafter, this pitching screen may be referred to as a fourth pitching screen. The fourth pitching screen includes the pass/fail judgment result.

Referring back to FIG. 4, the explanation will return to the flow of processing of each device. In step S117, the animation generation unit 114 generates an animation of the pitcher character 603 pitching and an animation of the ball 604 moving. These animations are displayed on the display unit 152 by the display control unit 112 in step S118. Specifically, the animation is displayed on the fourth pitching screen. As a result, the ball 604 that has hitherto been in the glove of the pitcher character 603 may be rendered.

On the other hand, when the phase start is synchronized in step S105, the battle progression unit 115 of the batting user terminal 100B displays the batting screen on the display unit 152 in step S110. At this time, since the pitching motion of the pitcher character 603 has not been determined, the pitcher character 603 before throwing the ball and a contact cursor 704, which will be described later, are displayed on the batting screen. In step S<b>111 , the operation accepting unit 111 may accept a slide operation for moving the contact cursor 704 .

In step S112, the match support unit 211 receives the pitching result D1. Then, in step S113, the received pitching result D1 is transmitted to the batting user terminal 100B.

In step S<b>114 , the batting user terminal 100</b>B receives the pitching result D<b>1 from the server 200 . In step S115, the animation generation unit 114 of the batting user terminal 100B generates an animation of the pitcher character 603 pitching and an animation of the movement of the ball 604 based on the received pitching result D1. In step S<b>116 , display control unit 112 displays the generated animation on display unit 152 . Here, the UI control unit 113 may superimpose, on the batting screen, a UI object for assisting the batting user's batting operation, in addition to the hitting cursor 704 .

In step S119, the operation receiving unit 111 of the batting user terminal 100B receives a batting operation by the batting user. In step S120, match progress unit 115 determines the swing position, swing timing, and the like of bat 602 based on the accepted batting operation. In step S<b>121 , match progress unit 115 generates batting result D<b>2 including information on the determined swing position and swing timing, and transmits it to server 200 .

(Striking screen)
FIG. 6 is a diagram showing a specific example of a game screen displayed on the display unit of the user terminal. Specifically, the game screen is a batting screen 700 representing a batting scene of the batter character. The batting screen 700 is a screen displayed after the batting user terminal 100B receives the pitching result D1 (the screen displayed on the display unit 152 in step S116).

The hitting screen 700 includes various objects placed in the virtual space. Specifically, it includes a batter character 601 , a bat 602 , a pitcher character 603 operated by the opponent user, a ball 604 , and a home base 607 . As shown in FIG. 6, the batting screen 700 may include fielder characters (characters in defense) belonging to the opposing team.

The batting screen 700 may include the switching button 613 described above, status information (status information 708 and 709) of each character during the confrontation, and situation information indicating the current situation.

The batting screen 700 includes a batting operation UI described below for receiving a batting operation by the batting user in the manual progress mode when the ongoing phase is the manual progress mode. That is, the batting screen 700 may include a timing hint object 703, a contact cursor 704, a position hint object 705, a direction hint object 706, etc. as batting operation UIs.

The timing hint object 703 indicates to the user a good timing for causing the batter character 601 to swing the bat 602 . The hitting cursor 704 indicates to the user the intended position to be reached by the swung bat 602 as a region that can act on the ball 604 in the intersecting plane when the bat 602 is swung. In addition, the contact cursor 704 is also an area referred to by the battle progression unit 115 in order to determine the hit between the bat 602 and the ball 604 . The position hint object 705 indicates to the user the expected position of the ball 604 thrown by the pitcher character 603 on the intersection plane. A directional hint object 706 indicates to the user the change in direction of the thrown ball 604 .

In the present embodiment, the batting operation for determining the batting result D2 includes, for example, a slide operation for designating the position of the contact hitting cursor 704, and the timing of swinging the bat 602 toward the determined position of the contact hitting cursor 704. and a flick operation for specifying. In other words, the slide operation is an operation for designating the position to hit the pitched ball, and the flick operation is an operation for designating the timing of hitting, that is, the timing of swinging the bat 602 . In other words, in the case of the manual progress mode, whether or not the batting user can proceed with the match, especially the attack, depends on the skill of both the slide operation and the flick operation.

When the ball 604 is thrown by the pitcher character 603, the operation receiving unit 111 transitions to the state of waiting for the above-described batting operation on the batting screen 700. FIG. When the operation reception unit 111 receives a user's slide operation on the touch screen 15, the UI control unit 113 moves the meet cursor 704 according to the slide operation. Note that the user may determine the best position of the contact cursor 704 with reference to the position hint object 705 .

Subsequently, the match progressing unit 115 determines whether or not the ball 604 thrown by the pitcher character 603 has reached a predetermined range based on the intersection plane. That is, it is determined whether or not the thrown ball 604 has approached the intersecting plane set on the home plate 607 within a predetermined distance. If it is determined that the ball 604 has reached less than the predetermined distance from the intersecting plane, the UI control unit 113 may restrict at least part of the movement of the contact cursor 704 . The UI control unit 113 may change the display mode such as the color or pattern of the contact cursor 704 so as to indicate that movement is restricted.

On the hitting screen 700 , the animation generator 114 gives the thrown ball 604 an animation of moving toward the strike zone 701 or the ball zone 702 . The user follows the moving ball 604 with his/her eyes, and performs a flick operation to designate the start timing of the swing performed by the batter character 601 at the best timing when the ball 604 reaches the home plate 607. can be done.

The user can also refer to the timing hint object 703 to determine the best timing for the flick operation. The timing hint object 703 starts to be displayed when the ball 604 starts to be pitched, and an animation is generated such that the ball 604 shrinks toward the center of the ball 604 as it approaches the intersecting plane on the home plate 607 . 114. Furthermore, the animation is an animation in which the ball 604 shrinks to the same size as the outline of the ball 604 at the timing when the ball 604 reaches the intersecting plane. By confirming the size of the timing hint object 703, the user can determine the best timing for obtaining a good hitting result.

When the operation receiving unit 111 receives a flick operation, the match progressing unit 115 determines whether or not the batter character 601 hits the ball 604 based on at least the positional relationship between the ball 604 and the contact cursor 704 on the intersecting plane at that time. judge. That is, it is determined whether or not the bat 602 swung by the batter character 601 has hit the ball 604 based on the user's slide operation and flick operation. For example, it may be determined that the batter character 601 hit the ball 604 when the ball 604 at least partially overlaps the hitting cursor 704 in the intersecting plane.

Furthermore, the battle progression unit 115 may determine whether or not a blow has been applied based on the timing of the flick operation specified by the operation reception unit 111 . For example, even if the ball 604 and the contact cursor 704 on the intersecting plane are in a positional relationship suitable for hitting, the timing of the flick operation may be too early or too late with respect to the timing suitable for hitting the ball 604. If so, the match progress unit 115 may determine that the batter character 601 did not hit the ball 604 .

Also, the match progressing unit 115 calculates a movement path along which the hit ball 604 moves in the virtual space, based on at least the positional relationship described above. Specifically, the match progression unit 115 dynamically models the collision between the bat 602 and the ball 604 based on the positional relationship described above. In this case, the velocity vector, rotation axis, amount of rotation, and the like of ball 604 immediately after colliding with bat 602 may be obtained as initial conditions for moving ball 604 . For example, when the lower part of the ball 604 is hit with the upper part of the hitting cursor 704, the angle of the hit ball increases and the ball flies. Also, when the upper portion of the ball 604 is hit with the lower portion of the hitting cursor 704, the angle of the hit ball decreases and the ball hits a ground ball. Further, for example, in the case of a so-called just-meat, such as hitting the center of the ball 604 at the center position of the meat cursor 704 (core 707 in FIG. 10), the match progressing unit 115 moves the ball 604 so that it flies with a liner. Calculate route. On the other hand, if the hit is not just a hit, it may be determined that the hit is an average hit, and the movement path corresponding to the average hit may be calculated.

Referring back to FIG. 4, the explanation will return to the flow of processing of each device. In step S122, the match support unit 211 receives the batting result D2. Then, in step S123, the received batting result D2 is transmitted to the pitching side user terminal 100A.

When the pitching user terminal 100A receives the batting result D2 from the server 200, in step S124, the animation generation unit 114 generates a batting animation of the batter character 601 based on the received batting result D2. In step S<b>125 , the display control unit 112 displays the generated animation on the display unit 152 .

When the battle progression unit 115 determines that "the batter character 601 hits the bat 602 with the ball 604" based on the batting result D2, in step S126, field play calculation is performed. Specifically, the match progressing unit 115 performs calculations for moving the hit ball 604 on the field, calculations for making the fielder character defend (catching, throwing, etc.), and advancing the runner character. Or do calculations to get on base.

In step S<b>127 , the animation generation unit 114 may generate a field play animation according to the calculation result of the battle progression unit 115 . In step S<b>128 , the display control unit 112 may display the generated animation on the display unit 152 .

It should be noted that if the match progressing unit 115 determines that "the batter character 601 did not hit the bat 602 with the ball 604 (missed or overlooked)" based on the batting result D2, steps S126 to S128 are performed. The execution of each process of is omitted.

In step S129, the battle progression unit 115 updates the situation information based on the calculation results regarding the field play.

Alternatively, if steps S126 to S128 are omitted, the match progression unit 115 determines whether the position of the thrown ball 604 on the intersection plane is within the strike zone 701 or not, based on whether the situation information Update the ball count inside.

On the other hand, after step S121, the battle progression section 115 of the batting user terminal 100B executes steps S130 to S134. Steps S130 to S134 are performed in the same manner as steps S124 to S128 described above. The difference is that the hitting result D2 is not information transmitted from the server 200, but information generated by the own terminal in step S120.

The battle progression unit 115 updates the situation information 400 in step S135. The battle progression unit 115 transmits the updated status information to the server 200 .

When receiving the situation information generated at the same timing from each of the user terminals 100, the battle support unit 211 transfers the received situation information to each of the user terminals 100 of the opponents in step S136. That is, the situation information generated by the pitching user terminal 100A is supplied to the batting user terminal 100B, the situation information generated by the batting user terminal 100B is supplied to the pitching user terminal 100A, and the situation information is exchanged. be. In steps S137 and S138, each user terminal 100 receives the situation information generated by the user terminal 100 of the opponent.

One phase ends and a new phase starts. Specifically, each device included in the game system 1 executes the processes from steps S105 to S138 again. A battle (PvP battle) progresses by repeating the start and end of the phase.

<Processing after battle>
FIG. 7 is a flow chart showing the flow of processing executed by the user terminal 100 based on the game program 131. As shown in FIG. The processing shown in FIG. 7 is common to the pitching user terminal 100A and the batting user terminal 100B. Therefore, in the flowchart shown in FIG. 7, the processing executed by the pitching user terminal 100A and the processing executed by the batting user terminal 100B are collectively described as processing executed by the user terminal 100 without distinguishing between them. This also applies to the flowcharts in FIG. 7 and subsequent figures.

In step S701, when a predetermined condition is satisfied at the end of the phase, the battle progression unit 115 determines the result of the battle according to the progress of the battle, and ends the battle (ends normally). As an example, the match progressing unit 115 ends the match when the latest situation information indicates that the “inning” is the bottom of the final inning (for example, the 9th inning) and the “out count” is 3 outs. Also, for example, the match progression unit 115 determines that the latest situation information indicates that the “inning” is the table of the final inning (for example, 9 innings), the score of the defending team is higher than the score of the attacking team, and If the "out count" is 3 outs, the match ends.

In step S702, the battle progression unit 115 determines whether or not the team of the user of the own terminal (own team) has won the battle. Specifically, the match progression unit 115 determines whether or not the score of the own team is greater than the score of the opposing team, and determines that the match has been won when the score of the own team is greater than the score of the opposing team. On the other hand, the match proceeding unit 115 determines that the match has been lost when the score of the own team is less than the score of the opponent team.

If it is determined that the player's own team has won (YES in step S702), in step S703, the match progression unit 115 increments the user's winning streak (current winning streak) in the current base district by one. Subsequently, the match progression unit 115 determines whether or not the current winning streak has reached any one of a plurality of preset thresholds (first threshold). When it is determined that any of the thresholds has been reached, the battle progression unit 115 gives the user a reward corresponding to the reached threshold. As an example, the battle progression unit 115 refers to a table that associates the number of current winning streaks and rewards, which is stored in the storage unit 120 as the game information 132, and specifies the reward to be given to the user.

FIG. 8 is a diagram showing a specific example of the table. The table shown in FIG. 8 is composed of a "number of consecutive wins" column and a "reward" column. The "number of consecutive wins" column stores the plurality of threshold values described above. In the example of FIG. 8, 5, 10, 15 and 20 are stored. The "remuneration" column stores information indicating the remuneration given to the user. In the example of FIG. 8, information indicating first to fourth rewards is stored. That is, in the table shown in FIG. 8, when the team organized by the user wins 5 consecutive victories, 10 consecutive victories, 15 consecutive victories, and 20 consecutive victories in the base district, the first reward, the second reward, the third reward, and the fourth reward are given respectively. It indicates that it is given to the user. Note that the information indicating the threshold and the reward stored in the table is not limited to the example in FIG. 8 .

Further, it is assumed that the higher the ordinal number of the first reward to the fourth reward, the higher the value of the reward in the game. That is, the value in the game increases in the order of the first reward, second reward, third reward, and fourth reward. "High value in the game" means, for example, a large number, a high rarity, and a high degree of usefulness in the game, and may satisfy a plurality of these.

As an example, when the first to fourth rewards are packs, the higher the ordinal number, the higher the rank of the pack. Alternatively, the greater the ordinal number, the greater the number of packs awarded. Also, a reward with a higher ordinal number may satisfy both of "high pack rank" and "large number of packs given". For example, if the first reward is the pack with the lowest rank, at least one of the second to fourth rewards is the pack with the lowest rank, and the rest is the pack with the higher rank. , may be multiple packs. Also, at least one of the second to fourth rewards may be a plurality of packs composed only of higher rank packs.

In FIG. 7, as an example of the step of determining whether the current winning streak has reached any of a plurality of preset thresholds, whether the current winning streak is 5 (step S704); It describes whether or not the current winning streak is 10 (step S706). In other words, FIG. 7 omits the determination of whether the current winning streak is 15 or 20 for the purpose of simplifying the flow.

In the case of YES in step S704, the battle progression unit 115 gives the first reward to the user in step S705. If NO in step S704 and YES in step S706, the battle progression unit 115 gives the user a second reward, which has a higher in-game value than the first reward, in step S707.

In the case of NO in step S706, the battle progression unit 115 does not give the reward to the user. It should be noted that the case of NO in step S706 means that the current winning streak is not any of a plurality of preset threshold values. Then, the flow shown in FIG. 7 ends. The battle progression unit 115 may automatically transition the game screen to the home screen.

On the other hand, if it is determined in step S702 that the player's own team has lost (NO in S702), the match progression unit 115 resets the user's current winning streak in the current base district to 0 in step S708. In other words, the defeated user must start over from zero to increase the winning streak. For example, if the current winning streak is 19, the defeated user must win 20 matches in a row to earn the fourth reward.

(server down)
FIG. 9 is a flow chart showing the flow of processing executed by the user terminal 100 based on the game program 131. As shown in FIG. Specifically, it is a flowchart showing the flow of processing executed by the user terminal 100 when the server 200 goes down.

In step S901, the battle progression unit 115 detects a server down. A known method may be used as a server down detection method. The match progression unit 115 determines the maximum waiting time in step S902 according to the number of innings when the server down is detected, and suspends the match in step S903. The maximum waiting time is the maximum value of the waiting time for the server 200 to return. As an example, when detecting that the server is down at the end of the match, the match progress unit 115 may set the maximum waiting time longer than when detecting that the server is down at the beginning of the match. good. For example, if the match progressing unit 115 detects that the server has gone down when the inning is 1 to 4, it suspends the match with the maximum waiting time of 5 minutes. On the other hand, if the match progressing unit 115 detects that the server has gone down when the inning is 5 to 9, it suspends the match by setting the maximum waiting time to 10 minutes.

Note that the length of the maximum waiting time may be fixed (for example, 5 minutes) regardless of the battle situation. In this example, the process of step S902 is not executed.

FIG. 10 is a diagram showing a specific example of the game screen displayed on the display unit of the user terminal. The game screen is the battle start screen 310 described with reference to FIG. 3, but the battle start screen 310 shown in FIG. It is different from the battle start screen 310 shown.

When the battle is interrupted, the battle progression unit 115 causes the display unit 152 to display, as an example, a battle start screen 310 shown in FIG. 10 instead of the game screen during the battle. The text 313 is a text that informs the user that the competition has been interrupted due to the occurrence of a server down. The contents of the text 313 are not limited to those shown in FIG. 10, as long as it is possible to notify the user that the competition has been interrupted due to the occurrence of a server down.

In steps S904 and S905, the battle proceeding unit 115 waits for the server 200 to return until the maximum waiting time has elapsed. Specifically, the battle progression unit 115 displays the battle start screen 310 shown in FIG. 10 on the display unit 152 until the maximum waiting time elapses.

(Resume match)
If the recovery of server 200 is detected before the maximum waiting time elapses (YES in step S904), battle progression unit 115 notifies the user of recovery of server 200 in step S907.

FIG. 11 is a diagram showing a specific example of the game screen displayed on the display unit of the user terminal. The game screen is the match start screen 310 described with reference to FIG. 3, but the match start screen 310 shown in FIG. , differs from the battle start screen 310 shown in FIG.

When detecting the recovery of server 200, match progression unit 115 updates, for example, match start screen 310 shown in FIG. 10 to match start screen 310 shown in FIG. 11, and notifies the user of server 200's return. The text 315 is text that notifies the user that the server 200 has recovered from a server down. The contents of the text 315 are not limited to those shown in FIG. 11 as long as the user can be notified that the server 200 has recovered from a server down.

In steps S<b>908 and S<b>909 , the battle progression unit 115 enters a state of waiting for an input (first input) of an operation for resuming the battle by the user and the opponent user. A battle resume operation is an operation for resuming (resuming) an interrupted battle, and is, for example, a tap operation on the battle resume UI 314 included in the battle start screen 310 shown in FIG. 11 .

When the operation accepting unit 111 determines that a match restart operation has been input (YES in step S908), the match progress unit 115 transmits a match restart notification to the user terminal 100 of the other user via the server 200. The match restart notification is to notify the user terminal 100 of the other user that the tap operation on the match resume UI 311 has been accepted, that is, that the user is about to resume the match.

The match progressing unit 115 identifies the input of the match restart operation by the opponent user by receiving the match restart notification. If the match restart notification has been received (YES in step S909), that is, if both the user and the opponent user have input the match restart operation, in steps S910 and S911, the match progressing unit 115 restarts the match according to the waiting time. After automatically progressing, restart the match. The waiting time is the time required from the suspension of the match to the resumption of the match, in other words, after the server 200 has gone down (or the user terminal 100 has detected that the server has gone down). ), until both the user and the opponent user input the operation to resume the match.

As an example, the battle progression unit 115 advances the battle based on the status information received from the server 200 . Specifically, the game support unit 211 of the server 200 determines the average time from the start to the end of one inning, which is stored in advance in the storage unit 220 as the game information 232, and the standby time described above. to determine the amount to automatically advance the match. More specifically, the wait time divided by the average time determines the inning (how many and whether it is heads or tails) after which the automatic progress is made. The average time may be calculated, for example, based on the time from the start to the end of one inning in a plurality of games played in the past in this baseball game. Alternatively, the average time may be calculated based on the time from the start to the end of one inning in an actual game (for example, a plurality of professional baseball games this year).

The match support unit 211 further determines characters (cards) participating in the match, batter characters, scores, runners, out counts, and ball counts. The match support unit 211 may, for example, determine all the batting results D2 in the automatically progressed period, and determine the score based on the batting results D2. Further, the match support unit 211 may cause a character on the bench to participate in the match instead of the character who is the starting member, assuming that there is a player change during the automatically progressed period. Note that the characters that are the starting members are cards included in the main deck. A benched character is a card included in a sub-deck. In other words, "in place of the character who is participating in the game, let a player on the bench participate in the game." It is to change the card IDs in the main deck so as to be associated with the frame identification numbers of the frames constituting the main deck.

The match support unit 211 may randomly determine runners, out counts, and ball counts within a range that does not deviate from the rules of baseball in this baseball game. For example, the match support unit 211 may generate situation information such as "runner on 2nd base, 2 outs, 2 balls and 1 strike". As a result, the match is restarted not from the beginning of an inning, but from the middle, that is, with runners on second base, two outs, two balls and one strike.

The match support unit 211 transmits the generated situation information to both user terminals 100 . As a result, both user terminals 100 resume the competition under the same conditions.

FIG. 12 is a diagram showing a specific example of the game screen displayed on the display unit of the user terminal. Specifically, the game screen is a game screen displayed when the battle is restarted. FIG. 12 shows a pitching screen 600 as an example of this game screen. Note that the game screen displayed when the match is resumed is determined according to the inning after the match is automatically progressed. may be displayed.

Here, it is assumed that while the pitching screen 600 shown in FIG. 5 is being displayed, the server 200 goes down and the match is interrupted. In other words, it is assumed that the game is interrupted at the bottom of the fourth inning (see FIG. 5).

As shown in FIG. 12, on the pitching screen 600 displayed after the match is resumed, the inning information 631 is "6th bottom", indicating that the bottom of the 6th inning. That is, the match is restarted after automatically progressing from the bottom of the 4th inning to the bottom of the 6th inning. Also, in the pitching screen 600 shown in FIG. 12, the score information 633 is "S1-3D". In other words, one point is added to each team in the course of the match progressing automatically. In this way, by automatically progressing the battle before resuming the battle, it is possible to prevent the lengthening of the time required for the battle. As a result, it is possible to prevent the user from losing motivation to continue the match due to restarting the match from the point of interruption.

After restarting the battle, the flowchart shown in FIG. 9 proceeds to step S701 of the flowchart shown in FIG. That is, the match ends after progressing based on the flowchart shown in FIG. 4 after the restart.

(Invalid match)
If the maximum waiting time has elapsed without detecting the return of the server 200 (NO in step S904 and YES in step S905), the maximum waiting time will be (NO in step S908 and YES in step S905), or after the server 200 returns and the maximum waiting time elapses without receiving a battle resumption notification (NO in step S909 and YES in step S905), the match progression unit 115 terminates the match as an invalid match in step S906. When the match ends as an invalid match, the match progressing unit 115 maintains the number of winning streaks before the match.

FIG. 13 is a diagram showing a specific example of the game screen displayed on the display unit of the user terminal. The game screen is the battle start screen 310 described with reference to FIG. 3, but the battle start screen 310 shown in FIG. 3 is different from the battle start screen 310 shown in FIG.

When the match ends as an invalid match, the match progressing unit 115 updates, for example, the match start screen 310 shown in FIG. 11 to the match start screen 310 shown in FIG. to notify. The text 317 is text that notifies the user that the match has become an invalid match. In addition, the text 317 includes content to notify the user that the number of consecutive wins before the battle will be maintained. This allows the user to easily understand that the winning streak is not updated due to the invalid match. In other words, the user terminal 100 can prevent the user from having anxiety that the winning streak will be reset (becomes 0) due to the invalid match. Note that the content of the text 317 is not limited to that shown in FIG. 13, as long as it can notify the user that the match has become an invalid match. For example, the text 317 may not include content to notify the user that the winning streak before the match will be maintained.

With this, the flow shown in FIG. 9 ends. The battle progression unit 115 may automatically transition the game screen to the home screen after executing the process in step S906.

(effect)
As described above, in this embodiment, the user terminal 100 is configured to execute the following steps based on the game program 131 . Specifically, based on user input to the user terminal 100 and communication between the user terminal 100 and the server 200, the user terminal 100 advances an interpersonal match between the user and the other user; a step of detecting that the server 200 has gone down while the match is in progress; a step of ending the interpersonal match as an invalid match in response to the occurrence of the server down in the server 200; If not, a step of determining the result of the match according to the progress of the match; and updating the current winning streak based on the results.

In this manner, the user terminal 100 disables the interpersonal competition and terminates the interpersonal competition in response to the occurrence of the server down of the server 200 . On the other hand, if the interpersonal competition is not invalidated, for example, if the interpersonal competition ends normally, the result of the competition is determined according to the progress of the interpersonal competition. When the result of the match is determined, the current winning streak is updated, but when the interpersonal match is invalidated, the current winning streak is not updated. As a result, it is possible to prevent the user's desire to play the game from decreasing due to the user's winning streak being stopped even though the match ended in the middle due to no fault of the user.

Also, as an example, the user terminal 100 can be used in the game when the current winning streak updated according to the user's victory in the match reaches one of a plurality of thresholds based on the game program 131. A further step of awarding a reward to the user may be performed.

The awarding step may also award a reward of higher in-game value if the current winning streak reaches a higher threshold.

In this way, a reward is given to the user by accumulating a winning streak. Moreover, the rewards become more valuable as the winning streak continues. In other words, in this baseball game, continuing the winning streak is important for the user, and stopping the winning streak is a great disadvantage for the user. In other words, if the match ends in the middle and the user's winning streak is stopped due to no fault of the user, such as server down of the server 200, the user's motivation to play the game is greatly reduced.

In particular, in this baseball game, the rating value increases by winning the battle. This means that as the number of consecutive wins increases, the strength of the opposing user who competes increases. In other words, it is difficult to continue the winning streak in this baseball game. For this reason, in this baseball game, if the match ends in the middle and the user's winning streak stops due to no fault of the user, such as server down of the server 200, the opponent is determined not based on the rating. Compared to , the user's motivation to play the game is greatly reduced.

In response to such a problem, the user terminal 100 according to the present embodiment does not update the user's current win streak when the match ends due to a server down, but maintains the current win streak before the match. It is possible to prevent the user's desire to play the game from greatly decreasing. This effect can be said to be particularly remarkable in a game such as this baseball game in which opponents are determined based on ratings.

Further, as an example, the user terminal 100 may be configured to further execute a step of interrupting the interpersonal match in response to the occurrence of a server down in the server 200 . In this example, the user terminal 100 may invalidate the inter-personal competition when the inter-personal competition is not restarted until the maximum waiting time elapses after the server 200 is down. As a result, it is possible to prevent the interpersonal match from immediately becoming invalid due to a server down.

Further, as an example, the user terminal 100 detects that the server 200 has recovered from the server down, and the server 200 recovers from the server down before the maximum waiting time elapses after the server down occurs in the server 200. and resuming the interpersonal competition in response to both the user and the opponent user inputting a competition resuming operation to the input unit 151 before the maximum waiting time elapses. may be configured to Thereby, if the user and the opponent user have the desire to resume the match after the match is interrupted, the match can be resumed. Therefore, it is possible to increase the possibility that the user who wishes to resume the match and the opponent user will be satisfied.

Further, as an example, the user terminal 100 may restart the interpersonal competition after automatically progressing the interpersonal competition in the above-described resuming step.

As a result, it is possible to prevent the time required for the match from increasing due to the suspension of the match. As a result, it is possible to avoid a decrease in the user's desire to continue the match due to the restart of the match from the point of interruption.

Note that the user terminal 100 may automatically progress the interrupted interpersonal match by the amount of progress determined based on the time required from the time the match was interrupted to the time it was restarted. Alternatively, the interrupted interpersonal match may be automatically progressed by a predetermined amount of progress. In other words, the amount of progress may be fixed.

Further, as an example, in the step of disabling the user terminal 100, even if the server 200 recovers from the server down before the maximum standby time elapses, the user terminal 100 If at least one of the user and the opponent user does not input a battle restart operation to the input unit 151, the interpersonal battle may be ended.

Thus, when both the user and the opponent user lose motivation to continue the competition due to the suspension of the competition, the user terminal 100 ends the competition. This can prevent unnecessary continuation of the battle.

Also, as an example, the user terminal 100 may further execute a step of determining the length of the maximum waiting time based on the competition situation when a server down occurs based on the game program 131 . This allows the user to wait for the restart of the match to be appropriate.

In the determining step described above, as an example, the length of the maximum waiting time may be determined depending on whether the inning at the time when the server went down occurred, from the first inning to the final inning. For example, in the above-described determining step, if it is detected that the server is down at the end of the match (for example, 5-9 times), it is detected that the server is down at the beginning of the match (for example, 1-4 times). The maximum waiting time may be longer than in the case of

When the match is interrupted at the end of the game, users who had an advantage at the time of interruption (for example, users whose own team is winning at the time of interruption) strongly desire to resume the match. Therefore, if it is detected that the server has gone down at the end of the match, the match can be restarted by increasing the maximum waiting time compared to when it is detected at the beginning of the match. The possibility can be increased, and the possibility that the user who wishes to resume the match will be satisfied can be increased.

[Embodiment 2]
Other embodiments of the invention are described below. For convenience of description, members having the same functions as those of the members described in the above embodiments are denoted by the same reference numerals. Moreover, since such a member has already been described in the first embodiment, the description thereof will not be repeated in the present embodiment.

FIG. 14 is a flow chart showing the flow of processing executed by the user terminal 100 based on the game program 131. As shown in FIG. Specifically, it is a flowchart showing the flow of processing executed by the user terminal 100 when the server 200 goes down. Note that the flow shown in FIG. 14 is the flow after steps S901 to S904 shown in FIG. 9 are executed.

If the recovery of server 200 is detected before the maximum waiting time elapses, battle progression unit 115 notifies the user of recovery of server 200 in step S1401. The battle proceeding unit 115 updates, for example, the battle start screen 310 shown in FIG. 10 to the battle start screen 310 shown in FIG. 11 and notifies the user of the return of the server 200 .

In step S1402, the battle progression unit 115 waits for reception of a battle start notification.

If the battle start notification has been received (YES in step S909), in step S1403, the battle proceeding unit 115 automatically advances the battle according to the waiting time. The waiting time here is the time required from when the server 200 goes down to when the battle start notification is received.

In step S1404, the battle progression unit 115 enters a state of waiting for input of a battle restart operation by the user.

If the operation accepting unit 111 determines that a match restart operation has been input (YES in step S1404), the match progress unit 115 restarts the manual progress mode or partial auto mode interpersonal match in step S1405. For example, if the interpersonal competition was in the manual progress mode when the interpersonal competition was interrupted, the competition progression unit 115 restarts the interpersonal competition in the manual progression mode, and if it was in the partial auto mode at the time of the interruption, resumes the interpersonal competition in the partial auto mode. good. Alternatively, the battle proceeding unit 115 may restart the interpersonal battle in the manual progression mode regardless of which mode it was in when it was interrupted.

On the other hand, if the operation receiving unit 111 does not determine that the match restart operation has been input (NO in step S1404), in step S1406 the match progressing unit 115 restarts the automatically progressed interpersonal match in the fully automatic mode. let it resume. That is, the battle progressing unit 115 causes the characters of the user's team to act according to the game program 131 without the user's operation input, and progresses the battle.

While progressing the battle, the battle proceeding unit 115 waits for the user to input a battle restart operation until the battle ends (step S1407). If the user has input a match restart operation before the match ends (YES in step S1407), that is, if the operation reception unit 111 determines that the match restart operation has been input before the match ends, the match progress unit 115 In step S1408, the portion progressed in the complete auto mode is maintained, and the interpersonal battle is resumed in the manual progress mode or the partial auto mode.

On the other hand, if the user does not input a battle restart operation by the time the battle ends (NO in step S1407), the flowchart shown in FIG. 14 proceeds to step S701 of the flowchart shown in FIG. That is, the match progressing unit 115 updates the current winning streak according to the results of the interpersonal match progressed in the fully automatic mode.

Note that the processing of step S1402 and the processing of step S1404 may be performed simultaneously. In this case, the battle progression unit 115 executes the process of step S1403 when the battle restart notification is received, or when the operation reception unit 111 determines that the battle restart operation has been input. Then, the interpersonal match is resumed while waiting for the execution of the one of the reception of the match restart notification and the input of the match restart operation that has not been executed.

Note that when the operation reception unit 111 determines that the user has input a match restart operation and the match progress unit 115 has not received the match restart notification, that is, when the opponent user has not input a match restart operation. , the user's user terminal 100 resumes the interpersonal competition in the manual progress mode or the partial auto mode, and the other user's user terminal 100 resumes the interpersonal competition in the complete auto mode. That is, in the game system 1 according to the present embodiment, one of the user and the opponent user inputs a competition restart operation to the input unit 151 before the maximum waiting time elapses, and the other inputs a competition restart operation. is not performed on the input unit 151, the interpersonal battle is resumed in a mode (first mode) in which the other player does not perform an operation input. The ``mode in which the other side progresses without operation input'' means that, on the user terminal 100 that has input the battle restart operation, the battle resumes in the manual progress mode or the partial auto mode, and the battle restart operation is performed. At the user terminal 100 on the side that did not make the input, the match is restarted in the fully automatic mode.

(effect)
As described above, in the present embodiment, the user terminal 100, based on the game program 131, restores the server 200 from the server shutdown before the maximum standby time elapses, and returns to the server 200 before the maximum standby time elapses. When only one inputs a match resuming operation to the input unit 151, the user terminal 100 that has input the match resuming operation restarts the match in the manual progression mode or the partial auto mode, and the user terminal 100 receives the input of the match resuming operation. In the user terminal 100 on the side that did not participate in the battle, the battle resumes in the complete auto mode. Then, if the restarted interpersonal competition ends without being invalidated, the current winning streak is updated according to the result of the interpersonal competition.

As a result, if the user inputs a match restart operation, the match will not become an invalid match, so that the user who wishes to resume the match, for example, the user who had an advantage at the time of interruption can be satisfied. In addition, if the user wins this match, the user can extend the current winning streak. On the other hand, if a match restart operation is not input and if the opponent user has input a match resume operation, the interpersonal match resumes in the complete auto mode, and the current winning streak is updated based on the result of the match. Therefore, the user does not want to lose the match and the current winning streak becomes 0, and actively tries to input the operation to resume the match. As a result, it is more likely that the match after the server 200 has recovered from a server failure can be resumed as an interpersonal match.

[In the case of a communication error not caused by the server 200]
Here, the flow of processing when a communication error (second error) not caused by the server 200 occurs will be described. FIG. 15 is a flow chart showing the flow of processing executed by the user terminal 100 based on the game program 131. As shown in FIG. Specifically, it is a flowchart showing the flow of processing executed by the user terminal 100 when a communication error not caused by the server 200 occurs. A communication error not caused by the server 200 means, for example, that the user or the other user inputs an operation to the user terminal 100 to disable communication between the user terminal 100 and the server 200, or It occurs when the other user moves out of the communication range while holding the user terminal 100, or when a failure occurs in the communication equipment of the wireless communication carrier, but the cause of the communication error is not limited to this example. . Hereinafter, a communication error not caused by the server 200 will simply be referred to as a "communication error".

In step S1501, the battle progression unit 115 detects a communication error. A known method may be used as a communication error detection method. The battle progression unit 115 suspends the battle in step S1502.

In steps S1503 and S1505, the battle progression unit 115 waits for resolution of the communication error until a predetermined maximum waiting time (second time) elapses. The battle progression unit 115 may display the battle start screen 310 on the display unit 152 until the maximum waiting time elapses. This competition start screen 310 may include, for example, text indicating that the competition has been interrupted due to a communication error. Also, the maximum waiting time may be variable. For example, the match proceeding unit 115 may determine the maximum waiting time according to the number of innings when the communication error is detected.

If it is detected that the communication error has been resolved before the maximum waiting time elapses (YES in step S1503), the battle progression unit 115 notifies the user that the server 200 is back in step S1506. Subsequent steps S1507 to S1510 are the same as steps S908 to S911 shown in FIG. 9, respectively, so description thereof will not be repeated here.

On the other hand, if the maximum waiting time elapses without detecting the resolution of the communication error (NO in step S1503 and YES in step S1504), the maximum waiting time is reached without receiving the battle restart operation after the communication error is resolved. If the time has elapsed (NO in step S1507 and YES in step S1504), or if the maximum waiting time has elapsed without receiving a battle restart notification after the communication error was resolved (NO in step S1508, Also, YES in step S1504), in step S1505, the battle progression unit 115 determines the result of the battle based on the situation at the time of interruption. As an example, the match progression unit 115 determines that the team that has scored more points at the time of interruption wins. Note that, if the scores at the time of interruption are the same, the match proceeding unit 115 may draw the match.

After the battle result is determined, the flowchart shown in FIG. 15 proceeds to step S701 of the flowchart shown in FIG. 7, and the battle ends. Then, the battle progression unit 115 updates the current winning streak according to the result of the battle.

(effect)
As described above, the user terminal 100 according to Embodiments 1 and 2 detects, as an example, that a communication error not caused by the server 200 (hereinafter simply referred to as a "communication error") has occurred while the interpersonal match is in progress. may be configured to further perform the step of Then, in this example, the user terminal 100 does not invalidate the interpersonal competition in response to the occurrence of the communication error.

Further, in this example, the user terminal 100 according to Embodiments 1 and 2 may be configured to further execute a step of interrupting the interpersonal competition in response to occurrence of a communication error. Then, if the communication error is not resolved before the maximum waiting time elapses after the occurrence of the communication error, the user terminal 100 determines the result of the interpersonal competition based on the situation at the time when the interpersonal competition is interrupted. good too.

In other words, if a match ends due to an error caused by the server 200, such as a server failure, the match ends in the middle because the user is not at fault, so the match is invalidated and the number of current winning streaks is affected. On the other hand, when the interpersonal match ends due to a communication error not caused by the server 200, the match is not invalidated, the result of the match is determined according to the situation at the time of interruption, and the current winning streak is updated. In other words, in the case of an abnormal end in which there is no fault on the management side of the game, the current winning streak is updated without invalidating the battle.

As a result, it is possible to prevent a user who is in a bad match situation from intentionally cutting off communication and forcibly ending the match.

[Modification]
In each of the above-described embodiments, the game executed by the game system 1 has been described as a competitive baseball game. The game is not limited to this example as long as the game progresses between the user and the opponent based on communication between 100 and server 200 . For example, the game may be based on sports other than baseball (tennis, table tennis, dodgeball, baseball, soccer, hockey, etc.). Also, for example, it may be a puzzle game, a quiz game, an RPG, an adventure game, a shooting game, a simulation game, a breeding game, and an action game.

Furthermore, the competition between the user and the opponent is not limited to interpersonal competition. For example, the match may be a CPU match. Also, the number of users participating in the interpersonal competition and the number of opponent users may be three or more. That is, the interpersonal competition may be one-on-many or multi-on-many.

In addition, in this baseball game, the parameter updated according to the result of the match is not limited to the current winning streak. The parameter may be, for example, the user's rating. In addition, in this baseball game, if the user loses the match, a parameter that is different from the parameter that is updated to the disadvantage of the user may be updated according to the result of the match.

Moreover, the cause of the state in which communication with the server 200 is impossible, which is detected by the user terminal 100, may be caused by a malfunction of the server 200, which is different from a server down.

In this baseball game, if a match ends in the middle due to a problem with the server 200, the user may be notified of the match with a result different from the invalid match. For example, the user may be notified that the competition is a draw. However, in this example, parameters such as the number of consecutive victories are not updated based on the result of the battle regardless of the result of the notification.

The user terminal 100 may assume that the match has been established when the match is terminated in the middle due to a malfunction of the server 200 and the innings at the time when the match was interrupted satisfy a predetermined condition. Considering that a match has been established means that parameters such as the number of consecutive wins are updated according to the result of this match. For example, the user terminal 100 may consider that the match has been established when the number of innings at the time the match is interrupted is the sixth inning or later.

The reward given to the user when a parameter, such as the number of consecutive wins, that is updated to the user's disadvantage when the user loses a match reaches a predetermined threshold, is not limited to packs.

Determination of the length of the maximum waiting time based on the situation of the match is not limited to determination based on the inning at the time when a problem occurred in the server 200 (that is, when the match was interrupted). For example, it may be determined based on whether or not the point difference at that time exceeds a predetermined threshold. Specifically, when the point difference at that time exceeds a predetermined threshold, the length of the maximum waiting time may be longer than when the point difference does not exceed the predetermined threshold.

Further, in the above-described embodiment, since the baseball game has been exemplified and explained, the maximum waiting time is determined depending on whether the inning at the time when the server 200 malfunctions (server down) occurs, from the first inning to the final inning. determined the length of the On the other hand, if the game executed by the game system 1 is a game other than a baseball game and includes a game part in which a battle is performed consisting of a plurality of phases, the processor 10 of the user terminal 100: The length of the maximum waiting time may be determined according to which of the plurality of phases the first phase that includes the time point at which the server 200 malfunctions occurs. Examples of multiple phases include the first and second halves of a soccer match in a soccer-themed game, each set of tennis in a tennis-themed game, each round in a fighting game or a boxing-themed game, and the like, but are not limited to these.

When detecting that the server is down at the end of the match, the match progressing unit 115 may shorten the maximum waiting time compared to detecting that the server is down at the beginning of the match.

When communication with the server 200 becomes impossible due to a problem with the server 200, the battle progression unit 115 of each user terminal 100 may continue the battle as a CPU battle without interrupting the battle. The CPU battle may proceed in manual progress mode, partial auto mode, or complete auto mode. Further, in this example, if the server 200 recovers from a server down before the maximum waiting time elapses, and the user and the opponent user input a competition restart operation to the input unit 151 before the maximum waiting time elapses, The battle progression unit 115 may restart the interpersonal battle. However, with respect to the portion progressed in the CPU game, both user terminals 100 are not synchronized. It is desirable to reset the part that has occurred and restart the interpersonal match from the time when communication with the server 200 becomes impossible.

Alternatively, for the part that progressed in the CPU game, the part on the user side that previously input the game restart operation to the input unit 151 may be adopted. Specifically, when receiving battle resumption notifications from both user terminals 100, the battle support unit 211 of the server 200 transmits a situation information transmission instruction to the user terminal 100 that previously transmitted the battle resumption notification. . The user terminal 100 that has received the transmission instruction transmits the situation information to the server 200 , and the battle support unit 211 transmits the situation information to the other user terminal 100 . The other user terminal 100 updates the progressed portion of the CPU battle based on the received status information.

Further, in this example, even if the server 200 recovers from a server failure before the maximum waiting time elapses, neither the user nor the opponent user performs the competition restart operation until the maximum waiting time elapses. If no input is made to the input unit 151, the match proceeding unit 115 may end the match as an invalid match.

Further, in this example, if the server 200 recovers from a server down before the maximum waiting time elapses, and only the user inputs a game restart operation to the input unit 151 before the maximum waiting time elapses, The match progressing unit 115 may continue the CPU match, and after the CPU match ends, update the winning streak according to the result of the CPU match. The competition progression unit 115 transmits information indicating the result of the CPU competition to the user terminal 100 of the opponent user via the server 200 . The user terminal 100 of the other user updates the winning streak based on the received information.

Further, even if the server 200 recovers from the server down before the maximum waiting time elapses, at least one of the user and the opponent user performs a match resuming operation on the input unit 151 before the maximum waiting time elapses. If no input is made, the battle progression unit 115 may end the interpersonal battle. In other words, the battle proceeding unit 115 may end the interpersonal battle unless both the user and the opponent user input operations to resume the battle through the input unit 151 before the maximum waiting time elapses.

When the user terminal 100 detects that the server 200 has recovered from a server down, the user terminal 100 may notify the user of the recovery of the server 200 by push notification. Such a configuration eliminates the need for the user to keep the application of the baseball game running.

[Example of realization by software]
The control block of the control unit 210 and the control block of the control unit 110 may be implemented by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like, or may be implemented using a CPU (Central Processing Unit). may be realized by software.

In the latter case, the information processing apparatus having the functions of the control unit 210 or the control unit 110, or both, includes a CPU that executes instructions of a program, which is software for realizing each function, and a computer (or A ROM (Read Only Memory) or a storage device (these are referred to as a "recording medium") readable by a CPU), a RAM (Random Access Memory) for developing the above program, and the like are provided. The object of the present invention is achieved by a computer (or CPU) reading and executing the program from the recording medium. As the recording medium, a "non-temporary tangible medium" such as a tape, disk, card, semiconductor memory, programmable logic circuit, or the like can be used. Also, the program may be supplied to the computer via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. Note that one aspect of the present invention can also be implemented 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, but can be modified in various ways within the scope of the claims, and can be 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 of one aspect of the present invention are listed below.

(Item 1) The game program was explained. According to one aspect of the present disclosure, the game program (131) is executed by a computer (user terminal 100) having a processor (10). The game program instructs the processor to proceed with a match between the user and the opponent based on the user's input to the computer and communication between the computer and the server (200); a step of detecting that a first error that makes it impossible has occurred in the server (step S901); determining the result of the match according to the progress of the match if it is not invalidated; While not updating the first parameter to be updated as above, if the result of the battle is determined, the step of updating the first parameter (steps S703, S708, S906) is executed based on the result of the battle.

(Item 2) In (Item 1), the game program causes the processor to further execute a step (step S903) of interrupting the battle in response to the occurrence of the first error in the server. In the invalidation step, the competition is invalidated in response to the fact that the competition has not been resumed within a first period of time after the occurrence of the first error in the server.

(Item 3) In (Item 2), the competition is based on communication between the user and one or more opponent users operating one or more other computers (user terminals 100) via a server. It is a battle. The game program instructs the processor to detect that the first error has been resolved in the server (step S904); and a step of resuming the battle (step S911) in response to the fact that at least one of the user and the opponent user has made a first input for resuming the battle before the first time elapses. Let

(Item 4) In the step of resuming in (Item 3), it is determined that one of the user and the other user has made the first input and the other has not made the first input before the first time elapses. In response, the battle is resumed in the first mode in which the other side progresses without any operation input.

(Item 5) In (item 3) or (item 4), in the resuming step, the competition is resumed after the competition is automatically progressed for the interruption.

(Item 6) In any one of items (Item 3) to (Item 5), in the step of resuming the match, the match is interrupted by the amount of progress determined based on the time required for the match to be resumed after the match was interrupted. Advance minutes automatically.

(Item 7) In any one of (Item 2) to (Item 6), the game program causes the processor to further execute a step of detecting that the first error has been resolved in the server (S904). In the disabling step, the first error has not been resolved within a first period of time after the first error occurred in the server, or the first error has occurred after the first error occurred in the server. Even if the first error is resolved before the time elapses, the match is invalidated in response to the fact that the first input for resuming the match is not performed before the first time elapses. and

(Item 8) In any one item from (Item 2) to (Item 7), the game program instructs the processor to determine the length of the first time based on the battle situation when the first error occurs in the server. The step of determining the height (step S902) is further executed.

(Item 9) In (Item 8), in the advancing step, a battle composed of a plurality of phases is advanced. In the determining step, the length of the first time period is determined according to which of the plurality of phases the first phase includes the point in time when the first error occurred in the server.

(Item 10) In (Item 9), in the determining step, the length of the first time when the first phase is the final phase of the match compared to when the first phase is the early phase of the match. lengthen the

(Item 11) In the step of progressing in (Item 9) or (Item 10), a baseball game is progressed as a competition. In the determining step, as the first phase, the length of the first time period is determined depending on whether the inning at the time when the first error occurred in the server is from the first to the last inning.

(Item 12) In any one of items (Item 1) to (Item 11), the game program instructs the processor during the progress of the match that communication necessary for the progress of the match is not possible without being caused by the server. A step of detecting that a second error has occurred (step S1501) is further executed. In the invalidating step, the match is not invalidated in response to the occurrence of the second error in the server.

(Item 13) In (Item 12), the game program causes the processor to further execute a step of interrupting the battle in response to the occurrence of the second error (step S1502). In the determining step, if the second error has not been resolved within a second time after the occurrence of the second error, the outcome of the match is determined based on the situation at the time when the match was interrupted.

(Item 14) In any one item from (Item 1) to (Item 13), the game program instructs the processor that the first parameter updated in response to the user winning the battle satisfies the first condition. If so, the step of giving the user a reward that can be used in the game (steps S705 and S707) is further executed.

(Item 15) In (item 14), the first parameter is the number of winning streaks indicating the number of matches the user has won in a row. In the giving step, as a first condition, when the number of consecutive wins reaches one of a plurality of first thresholds, a reward is given to the user, and when the number of consecutive wins reaches a higher first threshold, the value in the game gives higher rewards.

(Item 16) The information processing apparatus has been described. According to one aspect of the present disclosure, an information processing device (user terminal 100) includes a storage unit (120) that stores a game program (131), and a controller that controls the operation of the information processing device by executing the game program. a part (110); The control unit progresses the battle between the user and the opponent based on the user's input to the information processing device and the communication between the information processing device and the server (200), and prevents communication failure during the progress of the battle. Detecting that a possible first error has occurred in the server, invalidating the match in response to the occurrence of the first error in the server, and if the match is not invalidated, restarting the match according to the progress of the match If the match is invalidated, the first parameter updated to disadvantage the user in response to the user's failure to win the match is not updated, while the result of the match is determined. If so, update the first parameter based on the result of the match.

(Item 13) The method of executing the game program has been described. According to one aspect of the present disclosure, the game program (131) is executed by a computer (user terminal 100) having a processor (10). The method comprises the steps of: the processor advancing a match between the user and the opponent based on the user's input to the computer and communications between the computer and the server (200); a step of detecting that a first possible error has occurred in the server (step S901); a step of invalidating the match in response to the occurrence of the first error in the server (step S906); If not, the step of determining the result of the match according to the progress of the match; and updating the first parameter based on the result of the battle when the result of the battle is determined while not updating the first parameter (steps S703, S708, S906).

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 ranging sensor (operation unit), 100 user terminal (information processing device), 110, 210 control unit, 111 operation reception unit, 112 display control unit, 113 UI control unit, 114 animation generation unit 115 competition progression unit 116 time measurement unit 120, 220 storage unit 131, 231 game program 132 game information 133 user information 151 input unit (operation unit) 152 display unit 200 server, 211 match support unit, 310 match start screen, 311 match start UI, 312, 316 UI, 313, 315, 317 text, 314 match restart UI, 600 pitching screen, 601 batter character, 602 bat, 603 pitcher character, 604 ball, 605 catcher character, 607 home base, 610 pitch designation object, 611, 612, 708, 709 status information, 613 switching button, 631 inning information, 632 runner information, 633 score information, 634 count information, 700 batting screen, 701 strike zone, 702 ball zone, 703 timing hint object, 704 meet cursor, 705 position hint object, 706 direction hint object, 1010 object, 1020 controller (operation unit), 1030 storage medium

Claims (14)

A game program executed by a computer with a processor,
The game program causes the processor to:
advancing a match between the user and an opponent based on user input to the computer and communications between the computer and a server;
a step of detecting that a first error that renders the communication impossible has occurred in the server during the progress of the match;
invalidating the match in response to the occurrence of the first error in the server;
determining a result of the match according to the progress of the match if the match is not voided;
If the match is invalidated, the result of the match is determined while not updating a first parameter that is updated to the disadvantage of the user in response to the user's failure to win the match. a step of updating the first parameter based on the result of the match , wherein
The game program further causes the processor to suspend the match in response to the occurrence of the first error in the server;
The competition is a competition between the user and one or more opponent users operating one or more other computers based on communication between the computers via the server,
The game program causes the processor to:
detecting at the server that the first error has been resolved;
The first error is resolved before the first time elapses after the first error occurs in the server, and at least one of the user and the other user is detected before the first time elapses further executing a step of resuming the battle in response to performing a first input for resuming the battle;
The game program, wherein in the restarting step, situation information common to the user and the opponent user is generated, and after automatically proceeding with the interruption of the competition based on the situation information, the competition is resumed. 2. The step of invalidating invalidates the match in response to the fact that the match has not been restarted within a first time after the occurrence of the first error in the server. The game program described in . In the resuming step, in response to one of the user and the other user performing the first input and the other not performing the first input before the first time elapses, the 3. The game program according to claim 1 , wherein the competition is resumed in the first mode in which the other player does not perform an operation input. 4. Any one of claims 1 to 3 , wherein in the step of resuming, the competition is automatically progressed by a progress amount determined based on the time required for the competition to resume after being interrupted. The game program described in the paragraph. The game program further causes the processor to detect that the first error has been resolved at the server;
In the invalidating step, the first error has not been resolved within the first time after the occurrence of the first error in the server, or the first error has occurred in the server. Even if the first error is resolved before the first time elapses after occurrence of the first error, the first input for resuming the match is made before the first time elapses. 5. The game program according to any one of claims 1 to 4 , wherein the match is invalidated in response to the failure to break. A game program executed by a computer with a processor,
The game program causes the processor to:
advancing a match between the user and an opponent based on user input to the computer and communications between the computer and a server;
a step of detecting that a first error that renders the communication impossible has occurred in the server during the progress of the match;
invalidating the match in response to the occurrence of the first error in the server;
determining a result of the match according to the progress of the match if the match is not voided;
If the match is invalidated, the result of the match is determined while not updating a first parameter that is updated to the disadvantage of the user in response to the user's failure to win the match. a step of updating the first parameter based on the result of the match, wherein
The invalidation step invalidates the battle in response to the fact that the battle has not been restarted within a first time after the occurrence of the first error in the server;
The game program further causes the processor to determine the length of the first time period based on the situation of the battle when the first error occurs in the server. In the progressing step, progressing the battle composed of a plurality of phases,
3. The determining step determines the length of the first time according to which of the plurality of phases the first phase including the point in time when the first error occurred in the server is. 7. The game program according to 6 . In the determining step, when the first phase is the final phase of the match, the length of the first time is increased compared to when the first phase is the early phase of the match, The game program according to claim 7 . In the advancing step, a baseball game is advanced as the competition,
In the determining step, the length of the first time is determined according to whether the inning at the time when the first error occurs in the server as the first phase is from the first inning to the final inning. 9. A game program according to claim 7 or 8 , for determining. The game program further executes a step of causing the processor to detect that a second error, not caused by the server, has occurred during the progress of the match, which makes communication necessary for the progress of the match impossible. let
10. The game program according to any one of claims 1 to 9 , wherein said invalidating step does not invalidate said competition in response to occurrence of said second error in said server. The game program causes the processor to further execute a step of interrupting the match in response to the occurrence of the second error;
In the determining step, if the second error has not been resolved within a second time after the occurrence of the second error, the result of the match is determined based on the situation at the time when the match was interrupted. 11. A game program according to claim 10 , which determines. The game program causes the processor to provide a reward that can be used in the game to the user when the first parameter updated in response to the user winning the match satisfies a first condition. 12. The game program according to any one of claims 1 to 11 , further causing the execution of The first parameter is a winning streak number indicating the number of matches the user is currently winning in a row,
In the granting step,
As the first condition, when the number of consecutive wins reaches one of a plurality of first thresholds, the reward is given to the user,
13. The game program product of claim 12 , wherein if the winning streak reaches a higher first threshold, a reward of higher in-game value is awarded. An information processing device,
The information processing device is
a storage unit that stores a game program;
a control unit that controls the operation of the information processing device by executing the game program;
The control unit
progressing a match between the user and an opponent based on user input to the information processing device and communication between the information processing device and a server;
detecting that a first error has occurred in the server during the progress of the match, which makes the communication impossible;
invalidating the match in response to the occurrence of the first error in the server;
if the match is not invalidated, determine the result of the match according to the progress of the match;
If the match is invalidated, the result of the match is determined while not updating a first parameter that is updated to the disadvantage of the user in response to the user's failure to win the match. In this case, the information processing device updates the first parameter based on the result of the battle ,
Further, the control unit interrupts the match in response to the occurrence of the first error in the server,
The competition is a competition between the user and one or more opponent users operating one or more other information processing devices based on communication between the information processing devices via the server,
Furthermore, the control unit
detecting that the first error has been resolved at the server;
The first error is resolved before the first time elapses after the first error occurs in the server, and at least one of the user and the other user is detected before the first time elapses resuming the match in response to performing a first input for resuming the match;
generating situation information common to the user and the opponent user when resuming the match, automatically progressing the interrupted part of the match based on the situation information, and then resuming the match; device .

Images