JP2024060722A - Game system, game controller and program - Google Patents

Abstract

To enhance the excitement of a game that moves a mobile object to aim at a target area.SOLUTION: Specific area setting means sets specific areas, each divided into a plurality of small three-dimensional areas, within a three-dimensional game space where a mobile object can move. Mobile object movement means moves the mobile object according to user commands. Identifying means identifies the small areas that lie on the path along which the mobile object moves.SELECTED DRAWING: Figure 15

Description

The present invention relates to a game system, a game control device, and a program.

Conventionally, games have been known in which a user operates a character to move a moving object such as a ball and hit the moving object with a flat target panel. To increase the interest of the game, some games move multiple panels to the right or left to make it more difficult to hit the moving object (for example, Patent Document 1).

JP 2021-176421 A

In the above conventional games, each target panel is flat, and the user only has to think about hitting the front of the panel with a moving object, which can easily make the game monotonous. Therefore, there is a need for innovations that can make the game more interesting.

Therefore, one of the objectives of the present invention is to increase the interest of a game in which a player moves a moving object to aim at a target area.

A game system according to one aspect of the present invention is a game system that provides a game in which a moving object moves within a three-dimensional game space, and includes a specific area setting means for setting a specific area within the three-dimensional game space that is divided into a plurality of three-dimensional small areas, a moving object moving means for moving the moving object based on a user operation, and a specifying means for specifying the small areas that exist on the trajectory along which the moving object moves.

A game control device according to another aspect of the present invention is a game control device that provides a game in which a moving object moves within a three-dimensional game space, and includes a specific area setting means for setting a specific area within the three-dimensional game space that is divided into a plurality of three-dimensional small areas, a moving object moving means for moving the moving object based on a user operation, and a specifying means for specifying the small area that exists on the trajectory along which the moving object moves.

1 is a schematic block diagram showing an example of the configuration of a game system according to an embodiment of the present invention. FIG. 13 is a diagram showing an example of an event deck setting screen. FIG. 13 is a diagram showing an example of a screen listing abilities of development players. FIG. 13 is a diagram showing an example of a basic game screen. FIG. 2 is a diagram for explaining a plurality of blocks constituting a block group. FIG. 13 is a diagram for explaining movement of a block group. FIG. 13 is a diagram showing an example of a game screen after a pitch type is selected. FIG. 13 is a diagram showing an example of adjustment of a target pitch position. FIG. 13 is a diagram showing an example of a game screen in which a ball is moving. 11A to 11C are three views showing an example of the positional relationship between the trajectory of a pitched ball and a group of blocks. FIG. 13 is a diagram showing an example of a block to be erased. FIG. 13 is a diagram showing an example of a basic game screen after pitching (before the next pitch). FIG. 13 is a diagram illustrating an example of a target confirmation screen. FIG. 13 is a diagram illustrating an example of a target confirmation screen. FIG. 2 is a schematic functional block diagram showing an example of the functional configuration of the game system. FIG. 2 is a diagram showing an example of a data configuration of game management data. FIG. 2 is a schematic functional block diagram showing an example of the functional configuration of the game system. 13 is a flowchart illustrating an example of a process of the game system. 13 is a flowchart illustrating an example of a process of the game system. 13 is a flowchart illustrating an example of a process of the game system.

An example of an embodiment of the present invention will be described below with reference to the drawings.

[1. Game System Configuration]
1 is a schematic block diagram showing an example of the configuration of a game system 1 according to an embodiment of the present invention. This game system 1 includes a plurality of game terminals 10-n (n is a positive integer, 10-1, 10-2, ...) and a server 30. The game terminals 10-n and the server 30 in the game system 1 are connected to each other so as to be able to communicate data with each other via a network N such as the Internet. Here, since the plurality of game terminals 10-n have the same configuration, when no particular distinction is required, they will be simply referred to as "game terminals 10" in the following description.

The network N in this embodiment is not limited to the Internet, but may be, for example, a dedicated line, a public line (telephone line, mobile communication line, etc.), a wired LAN (Local Area Network), a wireless LAN, etc., as long as it can connect the game terminals 10-n and the server 30 in the game system 1 to each other so that they can communicate with each other, or it may be a combination of these with the Internet.

The game terminal 10 operated by the user is a computer that the user uses to play a game. Examples of game terminals 10 include home game consoles (fixed or portable), personal computers, smartphones, mobile phone terminals, PHS (Personal Handy-phone System) terminals, personal digital assistants (PDAs), tablet computers, multi-function television receivers (so-called smart TVs), and commercial game machines installed in gaming facilities, etc.

The server 30 is, for example, a server computer. The server 30 associates information about the user's game with a user ID for uniquely identifying each user, and stores and manages the information in, for example, a database DB. The database DB may be constructed within the server 30, or may be constructed in a server computer separate from the server 30.

Game system 1 allows for computer matches (also called CPU matches) and communication matches. In a communication match, for example, user A operating game terminal 10-1 and user B operating game terminal 10-2 can play a match game via network N. In the case of a communication match, for example, game terminal 10-1 and game terminal 10-2 matched by server 30 can directly communicate with each other via a P2P (Peer to Peer) connection or the like to play a match. Alternatively, data can be exchanged between game terminal 10-1 and game terminal 10-2 via server 30 to play a communication match. Either method may be used to play a communication match.

Communication between game terminal 10-n and server 30 can be achieved, for example, by using HTTP (Hyper Text Transfer Protocol), which runs on TCP/IP (Transmission Control Protocol/Internet Protocol), as the base protocol, and implementing the application protocol defined by this system at a higher level.

On the other hand, communication between game terminals 10-1 and 10-2 connected by P2P or the like can be realized by, for example, UDP (User Datagram Protocol), a communication protocol on the transport layer of the OSI reference model that is mainly implemented on the IP protocol. The above-mentioned UDP is a communication method in which data is simply sent to the other game terminal without confirming data delivery or correcting errors, so it has the advantage of low data reliability but high data transfer speed. Of course, it is also possible to use existing protocols other than UDP for communication between game terminals 10-1 and 10-2, or to use new protocols that will be newly defined in the future.

In addition, for example, in a game terminal 10-n that has a short-range wireless communication function using a specific frequency band (e.g., a 2.4 GHz frequency band), multiple game terminals 10-n can communicate directly with each other to play competitive games, etc.

(Game device hardware configuration)
The gaming terminal 10 mainly comprises a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an auxiliary storage device 14, a communication section 15, an operation section 16, a display section 17, and an audio output section 18, which are interconnected via bus lines including an address bus, a data bus, a control bus, etc. Note that, if necessary, an interface circuit, an image processing section, a sound processing section, etc. are interposed between the bus line and each component, but are not shown here.

The CPU 11 interprets and executes the commands of the game program, and controls the entire game terminal 10. The ROM 12 stores programs and data necessary for basic operational control of the game terminal 10. The RAM 13 stores various programs and data, and secures a working area for the CPU 11.

The auxiliary storage device 14 is a storage device that stores game programs, various data, etc. As the auxiliary storage device 14, for example, a non-volatile semiconductor memory, a hard disk drive, a solid state drive, etc. can be used.

The communication unit 15 has a communication interface (not shown) and has a communication control function for communicating data when the game is being played. Here, the communication control function for data communication includes, for example, an Internet connection function, a wireless LAN (Local Area Network) connection function, and a short-range wireless communication function using a specific frequency band (for example, a 2.4 GHz frequency band). The communication unit 15 transmits a connection signal for connecting the game terminal 10 to the network N based on an instruction from the CPU 11, and also receives information sent from the communication partner and supplies it to the CPU 11.

The operation unit 16 allows the user to input various operation commands to the game terminal 10. Examples of the operation unit 16 include a position input unit with a touch interface (a component of a touch panel), a physical button, a controller, an analog stick, a keyboard, a pointing device, etc. In addition, the operation unit 16 may be configured to allow voice input by identifying voice input from a voice input unit such as a microphone.

The display unit 17 is driven based on an image display command from the CPU 11 to display a game screen or the like. Various known display devices such as a liquid crystal display and an organic EL (Electro-Luminescence) display can be applied to the display unit 17. The display unit 17 can also be a touch panel in which a display device such as a liquid crystal display is combined with a position input unit having a touch interface. When the display unit 17 is configured as a touch panel, the game terminal 10 includes a touch input detection unit (not shown). When a pointer such as a finger or a pen touches the screen, the touch input detection unit detects the contact position coordinates on the screen and supplies a coordinate signal to the CPU 11. This allows the contact position on the screen of the display unit 17 to be recognized by the CPU 11. The display unit 17 does not need to be integrated with the game terminal 10, and may be, for example, a television monitor externally connected to the game terminal 10. In this way, when the display unit 17 is an externally connected television monitor or the like, the display unit 17 is not included in the configuration of the game terminal 10.
The audio output unit 18 generates an analog audio signal based on a sound generation instruction from the CPU 11 and outputs the sound or the like from a speaker.

The game terminal 10 may also be equipped with a recording medium drive. Examples of recording medium drives include DVD-ROM drives, CD-ROM drives, hard disk drives, optical disk drives, flexible disk drives, silicon disk drives, and cassette media readers. In this case, the recording medium may be a DVD-ROM, CD-ROM, hard disk, optical disk, flexible disk, or semiconductor memory. The recording medium drive reads image data, audio data, and program data from the recording medium, and supplies the read data to the RAM 13, etc. via a decoder.

(Server hardware configuration)
The server 30 mainly comprises a CPU 31, a ROM 32, a RAM 33, an auxiliary storage device 34, and a communication unit 35, which are interconnected via bus lines including an address bus, a data bus, a control bus, etc. Note that, although an interface circuit is interposed between the bus line and each component as necessary, the interface circuit is not shown here.

The CPU 31 interprets and executes commands from the system software and application software, and controls the entire server 30. The ROM 32 stores programs and the like necessary for basic operational control of the server 30. The RAM 33 stores various programs and data, and secures a working area for the CPU 31. The auxiliary storage device 34 is a storage device that stores programs, various data, and the like. For example, a hard disk drive or a solid state drive can be used as the auxiliary storage device 34.

The communication unit 35 has a communication interface (not shown) and controls communication with each game terminal 10-n via the network N. The communication unit 35 also controls communication with other servers (not shown) connected to the network N. For example, if the server 30 is configured as a system incorporated into a social networking service (SNS), the communication unit 35 of the server 30 controls communication with the SNS server. Also, for example, the server 30 controls communication with a video distribution server that distributes game videos played by users to spectators. The server 30 can also be provided with a video distribution function.

The server 30 can be configured as a single computer, but can also be configured as a functionally distributed type in which the functions of the server 30 are distributed across multiple servers. Alternatively, a load-distribution type configuration can be achieved by providing multiple servers 30 on the network N for redundancy (multiplexing). The server 30 can also be configured as a cloud server that utilizes cloud computing technology.

The programs and data are supplied to the game terminal 10 or the server 30 from a remote location via the network N and stored in the RAM 13, the auxiliary storage device 14, the RAM 33, or the auxiliary storage device 34. The game terminal 10 or the server 30 may be provided with components (e.g., an optical disk drive or a memory card slot) for reading the programs and data stored in an information storage medium (e.g., an optical disk or a memory card). The programs and data may then be supplied to the game terminal 10 or the server 30 via the information storage medium.

In the following, it is assumed that the game terminal 10 is a smartphone or tablet computer equipped with a touch panel. Various operations such as touching, sliding, and touching off the screen are performed with a pointing object such as a finger or a pen, but the following explanation will be given assuming operations using a finger.

[2. Overview of an Example Game]
An example of a game is outlined below.
In the game system 1, various games can be executed, such as sports games based on baseball, soccer, tennis, volleyball, etc. Note that the games may be executed by the game terminal 10 performing data communication between the server 30 or another game terminal 10, or may be executed by the game terminal 10 alone. In the following, a baseball game based on baseball will be described as an example of a game executed in the game system 1, and other games will also be mentioned as necessary.

The baseball game of this embodiment includes various game modes, such as a training mode, a team training mode, a lottery acquisition mode, an strengthening mode, a CPU battle mode, a real-time battle mode, a sub-game mode, and a tournament mode.

The training mode is a character training mode in which the user trains a character to be trained and creates their own original game character. In this embodiment, in the training mode, a pitcher or fielder (including a catcher) character can be trained. Hereinafter, a game character created by the user in the training mode will be referred to as a "trained player." A trained player can be used in other game modes such as team training mode, CPU battle mode, real-time battle mode, sub-game mode, and tournament mode. The team training mode is a game mode in which a team consisting of multiple player characters is trained.

The lottery acquisition mode is a game mode in which an "event character" (described later) that can be used as an auxiliary object when training a character to be trained in the training mode can be obtained by lottery. In this lottery acquisition mode, for example, a lottery (so-called gacha) is held to select an event character to be given to a user from among all event characters in the game. In order for a user to execute the lottery acquisition mode, for example, a predetermined amount of in-game points, paid items, etc. may be required.
The strengthening mode is a mode in which the level of an event character can be increased and strengthened by, for example, combining event characters obtained in the lottery obtaining mode.

The CPU battle mode is also called a computer battle mode. For example, the CPU battle mode may be named "stadium" or the like. In this CPU battle mode, the user performs batting operations, pitching operations, defensive operations, etc. of the player characters of his/her own team, which is made up of training players trained in the training mode, and plays against an opponent team automatically controlled by the CPU. For example, the opponent team automatically controlled by the CPU is a team made up of training players trained in the training mode by another user.
The real-time battle mode is a mode in which a user can play a game online against another user in a remote location via the network N.

The sub-game modes include various games that can be played using training players that the user has trained in the training mode, or event characters that are used as auxiliary objects even in the training mode.
The tournament mode is a mode in which users participating in a tournament compete for ranking based on the results of the training mode and/or the results of the sub-game mode.

Below, we will first explain the game in the training mode, and then explain an example of a game in which the user can use a training player that he or she has trained in the training mode.
In the training mode, the main character to be trained practices baseball at a high school and is trained to become a pitcher or fielder through various events. Note that in the training mode of this embodiment, multiple scenarios are prepared, and the user can select one of them.
When a scenario is selected, the user first determines basic information for the main character, including the name, position, dominant arm, batting form, and pitching form for pitchers. The position can be selected from pitcher, catcher, first baseman, second baseman, third baseman, shortstop, and outfielder.

Once the basic information for the main character has been determined, the event deck is then set up. The event deck is a deck for setting event characters who will be teammates with the main character and practice together at the high school he or she will attend. An event character is a character that affects the development of the main character (has a beneficial effect on the user) when an event occurs during the development process of the main character. Each event character is associated with a specific event that can occur during the progression of the scenario. Additionally, each event character is set with the same ability parameters as a development player (see Figure 3 for pitchers).

Event characters can be acquired as a winning reward in the CPU battle mode or real-time battle mode, or by lottery in the lottery acquisition mode mentioned above. Event characters acquired by a user in the game are associated with the user ID as characters owned by the user, stored in a storage device (database DB, auxiliary storage device 14, auxiliary storage device 34, etc.), and managed by game system 1.

The user selects an event character to be set in the event deck from among the event characters owned by the user. By setting an event character in the event deck, an event associated with the event character can occur during the progression of the scenario.
Furthermore, before starting a scenario in the training mode, the user can raise the level of the event character in advance in the strengthening mode, thereby giving the main character an advantage in training.

2 shows an example of the setting screen G100 of the event deck. The display area A112 displays the event characters selected by the user. For example, up to six event characters can be set in the event deck. Note that the event characters are selected from the event characters owned by the user, but some of them can be selected from the event characters owned by other users (for example, other users associated with the user).
The display area A111 displays the rarity of each event character. Rarity indicates how difficult it is to obtain, and the higher the rarity, the greater the benefit when training the main character when an event occurs. In addition, the display area A113 displays the level of the event character.

In addition, each event character may be associated with a favorite practice, and when the event character practices that favorite practice together with the main character, the main character may learn tips on abilities from the event character, or an event may occur in which a special practice is performed. A list of the event character's favorite practices is displayed in display area A114.

When the setting of the event character in the event deck is completed, the scenario will start. Before explaining the contents of the scenario, various parameters of the development player developed in the development mode will be explained. FIG. 3 shows an example of a development player ability list screen G200 when the main character is developed as a pitcher. The image of the development player is displayed in the display area A210. The name of the development player is displayed in the display area A211. The position number of the development player is displayed in the display area A212. The pitching form and dominant arm of the development player are displayed in the display area A213. The user can select the pitching form of the main character to be developed from multiple pitching forms (e.g., overhand, three-quarter, sidearm, underhand, etc.). If the pitching form or dominant arm is different, the trajectory of the ball will be different even if the same type of curveball is thrown. In addition, the position of the development player is displayed in the display area A214.

Display area A215 displays the basic ability related to "pitch speed," and displays the maximum pitch speed when a straight pitch is thrown. The basic abilities displayed in display areas A216 and A217 are displayed in eight levels of ranking, from highest to lowest, S, A, B, C, D, E, F, and G, with an ability score of 90 or above being S, 80-89 being A, 70-79 being B, 60-69 being C, 50-59 being D, 40-49 being E, 20-39 being F, and 19 or below being G.

Display area A216 displays basic abilities related to "control," and the higher the "control" ability, the less likely a pitcher is to make a bad pitch and the easier it is to pitch the ball to the intended course. For example, the higher the "control" ability, the wider the nice pitch zone, which will be described later. Display area A217 displays basic abilities related to "stamina," and the higher the "stamina" ability, the less likely a pitcher will tire and the less likely his abilities will decline in the latter half of a match.

In addition to the straight pitch, display area A218 also shows the type and amount of change in breaking balls that the main character has mastered. The five arrows displayed in display area A218 indicate the direction of the change in trajectory of a breaking ball thrown by a right-handed pitcher as seen from the batter facing the pitcher. Depending on the direction in which the ball's trajectory changes, breaking balls are classified into six types that differ in angle of approximately 45 degrees: straight pitches, sliders that change to the right (horizontally to the right), curves that change to the lower right, forks that change downward (vertically), sinkers that change to the lower left, and shoots that change to the left (horizontally to the left).

Straight curveballs include the two-seam, moving fastball, and super slowball. Slider curveballs include the slider, H slider (high-speed slider), and cutball. Curve curveballs include the curve, slow curveball, drop, drop curve, slurve, and knuckle curve. Fork curveballs include the fork, palm, changeup, V (Vertical) slider, knuckle, and SFF (Split Finger Fastball). Sinker curveballs include the sinker, screw, H sinker (high-speed sinker), and circle change. Shoot curveballs include the shoot, H shoot (high-speed shoot), and sinking two-seam. In addition, original pitches with unique trajectories may be created within the game.

A development player may be allowed to learn only one breaking ball that belongs to the same category of breaking balls that change direction. For example, if a development player learns a "slider" as a breaking ball that changes direction to the right, he or she may not be allowed to learn other breaking balls that change direction to the right, such as an "H slider" or a "cut ball." However, this is just one example, and a development player may be allowed to learn two or more breaking balls that change direction, even if they are breaking balls that change direction.

In the example shown in FIG. 3, the development player has mastered the changeups "slider", "curve", "fork", "sinker" and "shoot" in addition to the straight pitch. In other words, when using the development player in another game, the user can pitch any type of pitch selected from the options of "straight", "slider", "curve", "fork", "sinker" and "shoot".

The five arrows displayed in the display area A218 also function as a gauge that indicates the amount of change in each curveball. Here, the amount of change in a curveball is one of the ability parameters of a development player, and indicates the amount of curvature of the curveball. In other words, it indicates the amount of change in the trajectory of the ball when the development player throws a curveball. The amount of change is indicated on a seven-level scale from "1" to "7," with "1" being the smallest amount of change and "7" being the largest amount of change.
In the example shown in Figure 3, the development player is shown to have the ability of a "slider" change of "5," a "curve" change of "3," a "fork" change of "4," a sinker change of "7," and a "shoot" change of "6."

A list of pitcher-related special abilities possessed by the development player is displayed in the display area A219. In the example shown in Fig. 3, the development player possesses the special abilities of "heavy ball" and "strikeout". In other words, the development player is capable of throwing heavy balls and striking out batters easily.
The display area A220 displays the extended abilities associated with the development player. The extended abilities include the abilities of "rank" and "ability to attract customers." The abilities of "rank" and "ability to attract customers" are each represented by an ability value ranging from 0 to 100.

In the example shown in FIG. 3, the main character is a pitcher, so the basic abilities of a pitcher and parameters related to breaking balls are displayed. If the main character is a fielder, the basic abilities of a fielder (e.g., trajectory, hitting, power, running ability, arm strength, defensive ability, catching, etc.) and special abilities are displayed.

In the training mode of this embodiment, the user advances through a scenario consisting of a predetermined number of turns, selecting practice content and letting the main character rest for each turn. In addition, various events occur while the scenario progresses. Based on the practice content selected by the user and the results of events that occur, the user can acquire experience points necessary to train the main character. The user can spend the acquired experience points to improve the main character's basic abilities, acquire a curveball, increase the amount of change in a curveball, and acquire special abilities. Within the range of the acquired experience points, the user considers which basic ability to improve, which curveball to acquire, and to what extent to increase the amount of change in the acquired curveball.

In addition, the main character's basic abilities and variation may improve, he or she may learn a curveball, or he or she may acquire a special ability, depending on the practice content and event results selected by the user, without going through experience points.

Basically, the end of one scenario completes the training of the main character, and the character becomes a "trained player." A trained player whose training has been completed in training mode is registered in association with the user ID as a character that the user can use in game modes other than training mode. After the scenario ends, a different trained player can be created by starting the scenario from the beginning again and training the main character. In other words, by repeating training in training mode, the user can create multiple trained players with various abilities. For example, by repeatedly playing the training mode, the user can create a variety of pitcher characters as trained players, with different types of pitches, number of pitches, amount of change for each pitch, etc.

Next, an example of a game (e.g., a game in the sub-game mode described above) in which a development player, a pitcher character developed in the development mode, can be used will be described. For example, in this game, in addition to development players, an event character owned by the user (associated with the user ID) or a predetermined pitcher character (e.g., a predetermined character prepared by the game management side) may be made available for use.

In this game, a "block group," which is an object divided into multiple blocks, is basically placed in a virtual three-dimensional game space. In this game, the user throws the ball and hits the block group, which acts as a target, to eliminate the blocks and gain points. In this game, the block group placed in the virtual three-dimensional game space and each of the multiple blocks that make up the block group are three-dimensional solid objects, giving the game a distinctive gameplay quality.

Figure 4 is a diagram showing an example of a basic game screen G300 of this game using a pitcher character. The virtual three-dimensional game space displayed on the game screen G300 represents a baseball ground. In the virtual three-dimensional game space, a pitcher character PC, a catcher character CC, a block group BG, and the like are arranged. Here, the three-dimensional game space is represented by coordinate axes of the horizontal x-axis, the vertical y-axis, and the z-axis in the direction in which the pitched ball moves (the direction connecting the pitcher character PC and the catcher character CC), which intersect perpendicularly to each other. In this embodiment, the depth direction of the game screen G300 is the direction of the z-axis. The image displayed on the game screen G300 (and other game screens) is a field of view image generated from virtual three-dimensional space data of a predetermined range from a predetermined reference position in the virtual three-dimensional space based on the virtual three-dimensional space data. Here, the predetermined reference position is the position of a virtual camera arranged in the virtual three-dimensional space, and corresponds to the position of a virtual viewpoint in the virtual three-dimensional space. Also, the predetermined range corresponds to the field of view seen from the virtual camera (virtual viewpoint). For example, the field of view image can be generated by converting the coordinates of the points that make up each object, which are shown in the spatial coordinate system (three-dimensional coordinate system) of the virtual three-dimensional space, into the screen coordinate system (two-dimensional coordinate system) by performing a perspective projection transformation based on the position of the virtual camera.

The pitcher character PC is a character to be operated. At the start of the game, a training player arbitrarily selected from at least one pitcher training player trained by the user can be set as the pitcher character PC to be operated.
Alternatively, the operation target may be an event character arbitrarily selected from at least one pitcher event character owned by the user. Alternatively, the operation target may be a pitcher character arbitrarily selected by the user from a plurality of predetermined pitcher characters (for example, those prepared by the game management side). Alternatively, the operation target may be a pitcher character arbitrarily selected by the user from a training player, an event character, or a plurality of predetermined pitcher characters.

The catcher character CC is a non-player character (NPC) that catches the ball pitched by the pitcher character PC.
In the game of this embodiment, since the pitcher character PC does not play against the batter, the batter character is not placed (not displayed) in the three-dimensional game space, but the batter character may be placed. Also, the NPCs who play defense other than the catcher character CC are not placed in the three-dimensional game space, but the fielder characters who play defense at each position may be placed.

The block group BG is a translucent object that serves as a target, and is placed between the pitcher character PC and the catcher character CC in the three-dimensional game space. The block group BG is a rectangular parallelepiped with the ratio of "x-axis length:y-axis length:z-axis length = 1:1:4" (see the three-sided view in Figure 10). In other words, it is a rectangular parallelepiped that is longer in the depth direction along which the ball moves. Therefore, the area of the faces on the depth side (the faces of the block group BG that exist on the xz plane and the yz plane) of the block group BG that exist on the xy plane is larger than the front side of the block group BG that exists on the xy plane. This increases the importance of making the ball touch the depth side of the block group BG, not just the front side.

The block group BG may be placed anywhere between the pitcher character PC and the catcher character CC. If the ball pitched by the pitcher character PC is a curveball, it will go straight for a while after it is released from the pitcher character PC (the trajectory will not change), and then the trajectory will change in a direction according to the rotation direction and rotation speed of the ball. Therefore, it is desirable to place the block group BG so as to include at least the "area where the ball's trajectory may change (the area after the ball's trajectory starts to change)". The timing at which the ball's trajectory changes will vary depending on the pitch type and ball speed. The timing at which the trajectory changes will also vary depending on the pitcher character PC's ability (such as the sharpness of the ball). Therefore, for example, a specific area for placing the block group BG may be set based on the pitch type (such as a slow curveball) that causes the ball's trajectory to change the earliest. For example, the block group BG is placed in an area closer to the catcher character CC than the midpoint between the pitcher character PC and the catcher character CC. In this embodiment, the position of the end of the block group BG in the z-axis direction (the end on the catcher character CC's side) is near the home base (strike zone) in front of the catcher character CC.

The block group BG is divided into multiple blocks B (an example of a small object). In this embodiment, the block group BG includes a total of 27 blocks B, divided into three in each of the x-axis, y-axis, and z-axis directions. The block group BG is divided evenly into 27 blocks, and each of the 27 blocks B is a rectangular parallelepiped with the same shape and volume, with the ratio of "x-axis length:y-axis length:z-axis length = 1:1:4".

As shown in Fig. 5, the 27 blocks B constituting the block group BG are managed by block IDs (=B1 to B27) that uniquely identify each block. Note that for the sake of explanation, in Fig. 5, the block group BG is divided into three in the y-axis direction, and the first column (B1 to B9), the second column (B10 to B18), and the third column (B19 to B27) are shown separately, but in reality there are no gaps between the first and second columns, and between the second and third columns.
In other words, a block group BG consisting of a plurality of blocks B1 to B27 gathered together with no gaps is placed between the pitcher character PC and the catcher character CC in the three-dimensional game space.

The shape of the block group BG or block B is not limited to the rectangular parallelepiped described above, and can be any shape. Details of variations in the shape of the block group BG or block B (or the shape of a specific area formed by the block group BG or multiple blocks B) will be described later. In addition, the number of blocks B constituting the block group BG and the division method are also not limited to the above, and can be determined arbitrarily, and details of the variations will be described later.

As shown in FIG. 6, the block group BG moves linearly in the left-right direction (x-axis direction) and the up-down direction (y-axis direction). The start point, end point, movement width, movement speed, etc., of the block group BG moving back and forth left-right or up-down are determined in advance. The block group BG also moves in rotation (both forward and reverse rotation) around a central axis in the z-axis direction.

(Game Stage)
In this game, the user can operate a pitcher character PC to throw four balls at one block group BG in one stage. If the thrown ball touches a block B constituting the block group BG, the touched block B is erased. For each pitch, a score according to the number of blocks B that have been erased (erasure score, described below) and a score according to the number of predetermined lines formed by erasing blocks B (line score, described below) can be obtained. In addition, various bonuses, described below, are also added. After throwing four balls, the user proceeds to the next stage. At the start of a new stage, a new block group BG in an initial state in which no blocks B have been erased is placed. This is done for three stages, so a total of 12 balls can be thrown in one game.

As the stage progresses, the movements (linear and rotational movements) of the block groups BG become more complex, increasing the difficulty of the user's operations.
To give a specific example, in the first stage, the block group BG only moves left and right (moves back and forth in the x-axis direction).
Then, in the second stage, the block group BG moves up and down (moves back and forth in the y-axis direction) in addition to moving left and right (moving back and forth in the x-axis direction). That is, the number of movement patterns increases. For example, the movement in the left and right direction or the up and down direction is randomly determined for the first ball in the second stage. The movement direction of the block group changes with each pitch, such that the second ball in the second stage moves in a different direction from the first ball. Alternatively, the movement direction of the block group BG may be switched between left and right and up and down every predetermined period (for example, every 5 seconds). In this case, the block group BG moves left and right and up and down from the first ball onwards.

In the third stage, the block group BG moves left and right and up and down, as well as rotating as described above. For example, in the third stage, the block group BG moves left and right or up and down while simultaneously rotating around the central axis in the z-axis direction. Note that the rotational movement may be such that the block group BG only rotates without moving left and right or up and down.

(Score)
The scores that a user can earn include an "elimination score" and a "line score." An elimination score is a score that can be earned for each block B that is eliminated by contact with the thrown ball. Since one block group BG is made up of 27 blocks B, a maximum of 27 elimination scores can be earned in one stage.

The line score is a score that can be obtained for each line formed by removing three consecutive blocks B vertically or horizontally in the block group BG. The lines in the x-axis direction, the y-axis direction, and the z-axis direction are each valid. In the example of FIG. 5, the lines in the x-axis direction are nine lines, such as the lines of blocks B1, B2, and B3, the lines of blocks B10, B11, and B12, and the lines of blocks B19, B20, and B22. The lines in the y-axis direction are nine lines, such as the lines of blocks B1, B4, and B7, the lines of blocks B10, B13, and B16, and the lines of blocks B19, B22, and B25. The lines in the z-axis direction are nine lines, such as the lines of blocks B1, B10, and B19, the lines of blocks B3, B12, and B21, and the lines of blocks B5, B14, and B23. Thus, a maximum of 27 lines of line scores can be obtained in one block group BG (one stage).
Diagonal lines are not valued in the game, but diagonal lines may be enabled.

The "deletion score" and "line score" reflect at least one parameter of the pitcher character PC. Therefore, the "deletion score" and "line score" may differ depending on the parameters (status) of the pitcher character PC used. In this embodiment, the score unit price of the "deletion score" when one block B is deleted is calculated based on the parameters of the "ball speed" and "rank" of the pitcher character PC to be operated. In addition, the score unit price of the "line score" when one line is achieved is calculated based on the parameters of the "control" and "attraction" of the pitcher character PC. The higher the value of each parameter, the higher the score unit price of each of the "deletion score" and "line score". The user can use the development player created in the development mode as the operation target, so it is more advantageous to create a development player of a pitcher with high parameters in the development mode.

(Bonus)
There are three bonuses (benefits) that can increase the "elimination score" and "line score" that can be earned with each pitch: the "first selection bonus," the "breaking ball bonus," and the "nice pitch bonus."

The "first selection bonus" is a bonus that occurs when each pitch type (each of the pitchers' character PC's pitches) is used for the first time in each stage. For example, the "clearance score" and "line score" that can be obtained by pitching a pitch that selects the pitch type that is the subject of the first selection bonus can be increased by a specified factor (for example, 100%). Each stage starts in a state where the first selection bonus can be applied to all pitch types in the pitcher character PC's pitches. If a pitch type has been used once in a certain stage, the first selection bonus will not occur if that pitch type is used again in the same stage. Note that when proceeding to the next stage, the first selection bonus will be restored for pitches used in the previous stage.

By providing this first-time selection bonus, it is possible to motivate the user to select various types of balls. This effectively prevents the game from becoming one-sided, with players being biased towards selecting a specific type of ball.

The "curve ball bonus" is a bonus that occurs according to the amount of change in the curve ball of the pitcher character PC used by the user. Unlike the first selection bonus described above, the curve ball bonus does not disappear no matter how many times the same curve ball type is used. The curve ball bonus applies to pitches other than straight pitches. The "clearance score" and "line score" that are obtained by pitching a pitch type that is the target of the curve ball bonus can be increased by a predetermined multiplier. The larger the value of the parameter for the amount of change in the curve ball, the larger the multiplier of the curve ball bonus.
Since the user can use the development player created in the development mode as the control object, the more the user creates a development player who is a pitcher with a greater amount of change in the development mode, the more advantageous it will be.

The "Nice Pitch Bonus" is a bonus based on operations using the timing gauge, which will be described later, and will be explained in more detail below.

Now, let us return to the game screen G300 in FIG. 4 to continue the explanation. The game screen G300 displays a pitcher information display area A301, a score display area A302, a remaining pitch count display area A303, an auxiliary information display area A304, a time button P305, a target confirmation button P306, a pitch type selection area A307, etc.

The pitcher information display area A301 displays the pitcher character PC's player name and basic ability parameters (evaluation ranks for "pitch speed,""control," and "stamina"), etc. The score display area A302 displays the current score.
The remaining pitch count display area A303 displays the remaining number of pitches for each stage that can be thrown before the game ends.
The auxiliary information display area A304 displays information on the current stage, the number of blocks erased in the current stage, and the number of lines achieved in the current stage.

Furthermore, by the user tapping the time button P305, a time menu is displayed, allowing the user to check how to play the game and detailed information (such as ability parameters) about the pitcher character PC being operated.
Furthermore, the target confirmation button P306 is a button for changing the viewpoint in order to confirm the current state of the block group BG. Details of the screen that is displayed when the target confirmation button P306 is pressed will be described later.

In this embodiment, the operations related to pitching include a pitch type selection operation (an example of a user operation, an example of a selection operation), a pitch position designation operation (an example of a user operation), and a pitch start timing input operation (an example of a user operation, an example of a timing operation). These three pitching operations can be performed by three touch operations, or by a single consecutive touch operation (a consecutive operation of touch, slide, and touch off). For example, at the start of a game, the user may be able to select between a pitch type resulting from the three touch operations (first pitch type) and a pitch type resulting from the single touch operation (second pitch type).

First, an example of pitching based on three touch operations will be described.
A pitch selection area A307 is displayed on the game screen G300. This pitch selection area A307 includes pitch selection buttons P311 to P316 and parts P322 to P326 that indicate the amount of change in each curveball, etc.
The pitch selection buttons P311 to P316 are options for selecting one pitch to be thrown from among multiple pitches that the pitcher character PC can throw, that is, from among his or her balls. Here, we will explain the case where the selected pitcher character PC is a right-handed pitcher. Note that if the pitcher character PC is a left-handed pitcher, there will be differences in the names of some pitches and the direction of change in curveballs.

The pitch selection button P311 is a part for selecting a "straight" pitch from among the pitches possessed by the pitcher character PC.
In addition, if the pitcher character PC has a straight curveball (such as a two-seam fastball) as his or her ball, a pitch type selection button for selecting a straight curveball and a part indicating the amount of change in the curveball will be displayed next to the pitch type selection button P311.

The pitch type selection button P312 is a part for selecting a "slider type curveball" from among the pitches of the pitcher character PC. In the example of Fig. 5, the pitch of the pitcher character PC is a "slider", so "slider" is displayed on the pitch type selection button P312, but if another slider type curveball (e.g., H slider) is included in the pitch, the name of that ball is displayed.
Part P322 is a part that indicates the direction and amount of change of a "slider-type curveball." In the example of Fig. 4, the arrow indicates that the curveball is changing to the left and the amount of change is "5." Note that the direction of change here indicates the direction of the trajectory change of a curveball thrown by a right-handed pitcher as seen from the pitcher's side toward the strike zone (the same applies below).

The pitch type selection button P313 is a part for selecting a "curve type breaking ball" from among the pitches of the pitcher character PC. In the example of Fig. 4, the pitch type selection button P313 displays the pitcher character PC's pitch "curve", but if another curve type breaking ball (e.g., a slow curve) is a pitch, the name of that ball is displayed.
Part P323 is a part that indicates the direction and amount of change of a "curveball." In the example of Fig. 4, the arrow indicates that the ball will change to the lower left and that the amount of change is "3."

The pitch type selection button P314 is a part for selecting a "fork type curveball" from among the pitches of the pitcher character PC. In the example of Fig. 4, the pitch type selection button P314 displays the pitcher character PC's pitch "fork," but if another fork type curveball (e.g., a changeup) is included as a pitch, the name of that pitch is displayed.
The part P324 is a part that indicates the direction and amount of change of the "fork-type curveball." In the example of Fig. 4, the arrow indicates that the curveball will change downward, and the amount of change is "4."

The pitch type selection button P315 is a part for selecting a "sinker type curveball" from among the pitches of the pitcher character PC. In the example of Fig. 4, the pitch type selection button P315 displays the pitcher character PC's pitch "sinker", but if the pitcher character PC has another sinker type curveball (e.g., a screwball), the name of that pitch is displayed.
Part P325 is a part that indicates the direction and amount of change of the "sinker-type curveball." In the example of Fig. 4, the arrow indicates that the curveball will change to the lower right and the amount of change is "7."

The pitch type selection button P316 is a part for selecting a "shoot type curveball" from among the pitches of the pitcher character PC. In the example of Fig. 4, the pitch type selection button P316 displays the pitcher character PC's pitch "shoot", but if another shoot type curveball (e.g., H-shoot) is included as a pitch, the name of that ball is displayed.
The part P326 is a part that indicates the direction and amount of change of the "shoot-type curveball." In the example of Fig. 4, the arrow indicates that the curveball will change to the right, and the amount of change is "6."

Note that pitch type selection buttons P312 to P316 and parts P322 to P326 that do not correspond to the pitches possessed by the pitcher character PC are not displayed. For example, if the pitcher character PC only has two types of breaking balls, a "slider type breaking ball" and a "curve type breaking ball," pitch type selection buttons P314 to P316 and parts P324 to P326 are not displayed on the game screen G300. Alternatively, pitch type selection buttons that do not correspond to the pitches possessed may be displayed on the screen but not selectable (for example, they may be grayed out).

When at least one of the aforementioned "first selection bonus" and "curve ball bonus" is applied to the pitch type of the pitcher character PC, the bonus notification label P330 is displayed on the pitch type selection buttons P311 to P316. The bonus notification label P330 displayed for each pitch type displays a multiplier that is the sum of the multiplier of the "first selection bonus" and the multiplier of the "curve ball bonus" applied to that pitch type. As mentioned above, the first selection bonus is a bonus that is generated only when each pitch type is used for the first time in each stage. Therefore, the bonus notification label P330 corresponding to a pitch type that has been used once in the current stage displays a multiplier that is the first selection bonus multiplier (100%) subtracted from it. Note that the curve ball bonus does not apply to a straight pitch type, so if a straight pitch is thrown once in the current stage, the bonus notification label P330 corresponding to the straight pitch will be erased for that stage.

The user can select a pitch by tapping one of the pitch selection buttons P311 to P316 (touching the screen with a finger and then lifting the finger from the screen). When this pitch selection operation is performed, the screen transitions to game screen G400 in FIG. 7. Note that in game screen G400 in FIG. 7, components that overlap with game screen G300 in FIG. 4 are given the same component numbers and descriptions thereof are omitted (the same applies to subsequent drawings).

In game screen G400 of FIG. 7, the target confirmation button P306 and pitch selection area A307 are no longer present, but instead a predicted trajectory PT, display area A401, button P402, and timing gauge P410 are displayed. The currently selected pitch is displayed in display area A401. By tapping button P402, the user can return to game screen G300 of FIG. 4 and reselect the pitch.

The predicted trajectory PT is information about the possible trajectory of the ball after pitching that is displayed on the screen before the pitcher character PC pitches the ball, and is information that allows the user to predict in advance the trajectory of the ball after pitching. The predicted trajectory PT corresponds to the type of pitch currently selected, and the predicted trajectory PT differs if the type of pitch selected by the user is different. Furthermore, even for the same type of pitch, the predicted trajectory PT differs if the change amount parameter is different.

Immediately after transitioning to the game screen G400, the target pitch position is initially set to the center of the strike zone. The tip PT1 of the predicted trajectory PT on the catcher character CC side indicates the target pitch position. Therefore, the tip PT1 of the predicted trajectory PT is initially placed at a reference position in the center of the strike zone. The target pitch position (an example of a target arrival position of a moving object) can be adjusted by user operation.

The operation of specifying the target pitching position can be performed, for example, by the following sliding operation. That is, the tip PT1 of the predicted trajectory PT can be moved by touching a finger to any position on the game screen G400 in FIG. 7 (excluding the positions where the time button P305 and button P402 are located) and performing a sliding operation without removing the finger from the screen.

Figure 8 illustrates a state in which the tip PT1 of the predicted trajectory PT is moved by sliding the finger F on the screen. For convenience of explanation, the block group BG and the like are omitted in Figure 8 for simplification. The tip PT1 of the predicted trajectory PT moves in conjunction with the displacement of the finger F accompanying the slide operation while maintaining a relative positional relationship with the finger F touching the screen. The user can move the target pitch position, which is the tip PT1, by touching and sliding the finger F to a position on the screen different from the tip PT1 of the predicted trajectory PT without directly touching the tip PT1 of the predicted trajectory PT. The predicted trajectory PT itself also changes as the target pitch position of the tip PT1 of the predicted trajectory PT is moved by the slide operation. In this way, when the user performs an operation to move the target pitch position, the predicted trajectory PT also changes in real time in conjunction with the movement of the target pitch position, so that the user can recognize the change in the predicted trajectory PT while moving the target pitch position. This allows the user to fine-tune the target pitching position while checking the changes in the predicted trajectory PT, realizing a user interface with good operability. As a variation, the target pitching position may be adjusted by operating a button or joystick instead of the slide operation.

In FIG. 8, the designation of the target pitching position is finalized by releasing the sliding finger F from the screen. This starts the movement of part P4106 of the timing gauge P410 shown in FIG. 7, and the operation proceeds to the pitching start timing designation. The movement of the moving block group BG is temporarily suspended during the period in which the pitching start timing designation operation is performed. In other words, the block group BG, which was performing a predetermined movement until the designation of the target pitching position was finalized, stops moving when the designation of the target pitching position is finalized. The paused movement of the block group BG then resumes when the user performs a pitching start timing input operation, which will be described below, i.e., when the pitcher character PC begins his pitching motion.

Here, the operation of inputting the pitch start timing using the timing gauge P410 will be described. The timing gauge P410 includes a part P4106 that moves at a constant speed from an initial position P4100 to an end position P4105. When the user touches the screen, the movement of the part P4106 stops, and the pitch start timing can be input. After this input, the pitcher character PC starts the pitching motion. The timing gauge P410 is divided (e.g., color-coded) into four areas E4101-E4104 lined up from the initial position P4100 side. Depending on which area E4101-E4104 the moving part P4106 is stopped in, the presence or absence of a nice pitch bonus and the presence or absence of a loss of control are determined.

The area E4103 is the nice pitch zone, and touching the screen while the part P4106 passes through the nice pitch zone E4103 generates the aforementioned nice pitch bonus, which increases the points acquired (for example, by 50%). Also, if the part P4106 can be stopped in the nice pitch zone E4103, there will be no loss of control (or there will be a high probability that there will be no loss of control). In other words, if the timing input operation can be performed so that the part P4106 stops in the nice pitch zone E4103, the ball can be pitched according to the predicted trajectory PT (or there will be a high probability that the ball can be pitched according to the predicted trajectory PT).

For the next pitch after the part P4106 is able to stop in the nice pitch zone E4103, the width of the nice pitch zone E4103 may be narrowed. In this case, for the next pitch after the nice pitch bonus occurs, the period during which the part P4106 can stop in the nice pitch zone E4103 will be shorter, making it harder for the nice pitch bonus to occur consecutively. In this case, it is desirable to set a lower limit for the width of the nice pitch zone E4103.

Alternatively, the width of the nice pitch zone E4103 may be made wider for the next pitch after the part P4106 is able to stop in the nice pitch zone E4103. In this case, the period during which the part P4106 can stop in the nice pitch zone E4103 will be longer for the next pitch after the nice pitch bonus has occurred, making it easier for the nice pitch bonus to occur. In this case, it is desirable to set an upper limit on the width of the nice pitch zone E4103.

If part P4106 is stopped in areas E4101, E4102, or E4104 other than the nice pitch zone E4103, deviation from the specified target pitching position, i.e., loss of control, occurs (or the probability of loss of control occurring is higher than if the part is stopped in the nice pitch zone E4103). If deviation from the specified target pitching position occurs, the ball will be pitched on a trajectory that deviates from the predicted trajectory PT, making it harder for the ball to hit the intended block B. There is a higher probability that the target pitching position will deviate and/or the amount of deviation is greater in area E4101, which is farther from the nice pitch zone E4103, than in area E4102.

If part P4106 is stopped in area E4104, past the nice pitch zone E4103, it will be a bad pitch, and even if a curveball is thrown, the ball will have almost no change in trajectory and will be thrown near the center of the strike zone. Alternatively, if part P4106 is stopped in area E4104, it may be arranged so that the deviation from the target pitch position is greater than if it were stopped in another area.

When the pitch start timing input operation is performed, a known algorithm is applied to calculate the trajectory of the pitched ball based on the selected pitch type, the specified target pitching position, and the input timing. The pitch start timing input operation also starts the pitching action of the pitcher character PC, and the ball is released from the pitcher character PC. Then, a video of the released ball moving through the three-dimensional game space is displayed on the screen.

In addition, when the pitch start timing input operation is performed (when the operation is recognized by the CPU 11), the movement of the stopped block group BG resumes.

Figure 9 is a diagram showing an example of a game screen G500 in which the ball BL is moving. When the ball BL is released by the pitcher character PC, parameters such as the position and angle of the virtual camera are changed. For example, as the ball BL moves, the virtual camera also moves in the direction in which the ball BL is moving. The virtual camera is then fixed at a position and angle that allows an image of the collision of block groups BG with block groups BG to be captured from a slightly diagonal upward angle.

With a conventional two-dimensional target, it is sufficient to be able to confirm whether the ball has hit the front of the target or not. In contrast, this game uses three-dimensional block groups BG, so the virtual camera parameters are changed to make it easier to see that the ball BL has hit the surface in the depth direction of the block group BG.

When the ball BL comes into contact with a block B, an effect occurs in which the color of the block B changes, and then the block B that came into contact is erased.
Even if the ball BL comes into contact with the block B, the ball BL passes through the small area in which the block B exists without decreasing its moving speed or changing its trajectory due to the contact.

Figure 10 is a three-dimensional view showing an example of the trajectory of a thrown ball BL and the relative positional relationship between a group of blocks BG. The arrows in Figure 10 indicate the trajectory of the ball BL as it moves through the three-dimensional game space. In the example of Figure 10, as shown in Figure 11, the ball BL comes into contact with five blocks B with changed colors, "B8", "B17", "B22", "B25", and "B26", and these five blocks B are erased. In this example, the two blocks B, "B25" and "B26", are targets for elimination because the ball BL has come into contact with the depth planes (xz plane, yz plane) rather than with the front plane (xy plane).

In this game, one of the important factors for progressing advantageously in this game is to develop a pitcher character PC with a curveball that changes its trajectory in a diagonal direction and use it in this game. Also, curveballs that change their trajectory diagonally tend to have more selectable blocks than curveballs that change their trajectory horizontally or vertically, and are therefore advantageous. On the other hand, to eliminate multiple blocks lined up in the horizontal or vertical direction, a curveball that changes its trajectory horizontally or vertically is required. Therefore, one of the important factors for progressing advantageously in this game is to develop a pitcher character PC with a curveball that changes its trajectory in various directions and use it in this game.

After the ball is thrown, the score acquired by the user is calculated based on the number of blocks B erased and the number of lines achieved, and by applying the various bonuses mentioned above.
12 is a diagram showing an example of a basic game screen G300 after pitching (before the next pitch). This game screen G300 displays a block group BG including blocks B that have not been erased by previous pitches. The block group BG may also move in a direction different from that of the previous pitch.

Because the target block group BG is three-dimensional, it may be difficult to see the remaining blocks B (or the positions of the erased blocks B) on the basic game screen G300. Therefore, the basic game screen G300 is provided with a target confirmation button P306. When the user taps the target confirmation button P306, a target confirmation screen G700 as shown in FIG. 13 is displayed. On this target confirmation screen G700, a block group BG of the left viewpoint, which is captured from the left side obliquely from above and in front, a left viewpoint switching button P701, a right viewpoint switching button P702, a back button G703, and the like are displayed. Since the block group BG of the left viewpoint is displayed in FIG. 13, if the block group BG of the right viewpoint is to be confirmed, the right viewpoint switching button P702 is tapped. This switches to the target confirmation screen G700 as shown in FIG. 14, and a block group BG of the right viewpoint, which is captured from the right side obliquely from below and in front, is displayed. On the target confirmation screen G700 of FIG. 13 or FIG. 14, tapping the back button G703 returns to the basic game screen G300 of FIG. 12.

Next, we will explain an example of pitching in which three operations - pitch type selection, pitch position designation, and pitch start timing input - are performed with a single touch operation (continuous operations of touch, slide, and touch off).

The pitch selection operation is performed by touching one of the pitch selection buttons P311 to P316 with a finger on the basic game screen G300 in FIG. 4. Note that when pitching with three touch operations, it is necessary to lift the finger from the screen after touching one of the pitch selection buttons P311 to P316, but when pitching with one touch operation, the finger is not lifted from the screen.

When the above pitch type selection operation is performed, the screen transitions to game screen G400 in FIG. 7 with the finger still in contact with the screen. In this game screen G400, the user slides their finger while maintaining contact with the screen, thereby moving the tip PT1 of the predicted trajectory PT and adjusting the target pitching position. In addition, at the timing of transition to game screen G400 in FIG. 7, movement of part P4106 of timing gauge P410 begins. Furthermore, at the timing of transition to game screen G400 in FIG. 7, movement of block group BG is temporarily stopped. In other words, the predetermined movement of block group BG is temporarily stopped during the period for inputting the pitch start timing.

When the user performs a touch-off operation on game screen G400 by removing their finger from the screen, the position of the tip PT1 of the predicted trajectory PT (= the target pitching position) is finalized and the movement of part P4106 of the timing gauge P410 stops. In other words, the slide operation and touch-off operation described above are operations for specifying the pitching position, and the touch-off operation is an operation for inputting the pitching start timing.

When the touch-off operation simultaneously specifies the target pitching position and inputs the pitching start timing, the pitcher character PC starts pitching, and the paused block group BG resumes the specified movement. The process thereafter is the same as in the case of three touch operations.

In this way, when pitching with a single touch operation, the operation of selecting the pitch type, the operation of specifying the pitching position, and the operation of inputting the pitching start timing are all possible through a series of operations from touching the screen once to touching off. When pitching with a single touch operation, the pitch can be thrown quickly. On the other hand, when pitching with three touch operations, each operation can be performed carefully.

The game may be modified so that the pitcher character PC automatically starts pitching and throws the ball once the pitch type selection operation and pitch position designation operation are completed, omitting the pitch start timing input operation. In this case, as described above, there is no need to temporarily suspend the movement of the block group BG in the middle of the game (i.e., there is no need to temporarily suspend the movement of the block group BG during the period for inputting the pitch start timing).

As described above, in the game of this embodiment, the block group BG arranged in the virtual three-dimensional game space and each of the multiple blocks B that make up the block group BG are three-dimensional solid objects, and the game has a gameplay that makes the user aware of the actual trajectory of the ball moving through the three-dimensional game space. Since there are many possible trajectories of the ball when it comes into contact with the multiple blocks B that make up the target block group BG, including in the depth direction, the method of winning the game becomes complex, which can increase the user's interest.

In the above game, a solid object called a block group BG divided into multiple blocks B is placed in a three-dimensional game space, but the three-dimensional "specific area" where the block group BG was located may itself be regarded as the target without placing the block group BG. Even if the block group BG is not placed in the "specific area," the "specific area" itself can become a three-dimensional target by devising the display state, for example, by making the "specific area" a translucent color different from other areas. A game similar to the above game can be realized by identifying a small area on the trajectory of the ball that moves when thrown based on user operation for a "specific area" that is divided into multiple three-dimensional small areas.

[3. Functional configuration of the game system]
Fig. 15 is a schematic functional block diagram showing an example of the functional configuration of the game system 1. As shown in Fig. 15, the game system 1 includes a data storage unit 100. For example, the data storage unit 100 is realized by at least one of a database DB, a ROM 12, a RAM 13, an auxiliary storage device 14, a ROM 32, a RAM 33, and an auxiliary storage device 34. The data storage unit 100 stores data necessary for providing a game.

For example, various data for executing the game stored in the data storage unit 100 may be stored in the database DB or the auxiliary storage device 34 of the server 30, and when the game terminal 10 accesses the server 30, the necessary data may be downloaded to the RAM 13 or the auxiliary storage device 14 of the game terminal 10. Information on the results of the game executed on the game terminal 10 and changes to the data may be transmitted from the game terminal 10 to the server 30 in real time or at a predetermined timing, and the data stored in the database DB or the auxiliary storage device 34 of the server 30 may be updated as appropriate. Also, for example, necessary data may be stored in the auxiliary storage device 14 of the game terminal 10 so that at least a part of the game can be executed offline on each user's game terminal 10 without logging in to the server 30.

As a specific example of data stored in the data storage unit 100, the data necessary to provide the baseball game described above will be described. The data storage unit 100 stores a user information table TBL101 and game management data DT102, etc. Although omitted in FIG. 15, the data storage unit 100 also stores a character table that stores information on all characters used in the game, etc.

User information table TBL101 stores information about all users registered in game system 1. For example, user information table TBL101 stores, in association with each user's user ID, the user's name, the user's game level, information about training players, information about event characters owned, information about items owned, information about points owned, and the like. The training player information includes the character ID, player name, and ability parameter information (for a pitcher character, ball speed, control, stamina, types of balls that can be pitched (balls in possession), amount of change in each ball in possession, special abilities, and extended abilities) of the training player created by the user in the training mode.

The game management data DT 102 includes various data necessary for managing the progress of the game. Fig. 16 shows an example of the data structure of the game management data DT 102 in a game in which blocks are eliminated by pitching a ball.
The game management data DT102 includes pitcher data DT1021, score unit cost data DT1022, bonus data DT1023, block management data DT1024, block group movement pattern data DT1025, stage data DT1026, remaining pitch count data DT1027, score data DT1028, and the like.

The pitcher data DT1021 is information on the pitcher character selected by the user to be used in the game. The score unit price data DT1022 is information on the unit price of the elimination score that can be obtained when one block B is eliminated, and information on the unit price of the line score that can be obtained when one line is achieved. The bonus data DT1023 is information on the multipliers for the "first selection bonus," "curveball bonus," and "nice pitch bonus."

The block management data DT1024 is information indicating whether each of the multiple blocks B that make up the block group BG has been erased. For example, a flag of "1" is associated with the block ID of an unerased block B, and a flag of "0" is associated with the block ID of an erased block B.

The block group movement pattern data DT1025 is information indicating the pattern in which the block group BG currently displayed on the game screen moves in the three-dimensional game space. In this embodiment, various movement patterns of the block group BG are predefined, such as a left-right movement pattern, an up-down movement pattern, a high-speed left-right movement pattern, a high-speed up-down movement pattern, a left-right movement + forward rotation pattern, a left-right movement + reverse rotation pattern, an up-down movement + forward rotation pattern, and an up-down movement + reverse rotation pattern. Each movement pattern is managed by a movement pattern ID that uniquely identifies it.

The stage data DT1026 is information indicating the current stage. The remaining balls data DT1027 is information indicating the number of remaining balls that the user can throw in the current stage. The score data DT1028 is information indicating the score (points) that the user has earned by clearing block B and completing the line.

The game system 1, server 30, or game terminal 10 of this embodiment provides a game in which a moving object moves within a three-dimensional game space. In the baseball game example described above, a game is provided in which a ball that can be thrown using a variety of different pitches can be thrown toward a three-dimensional target group of blocks BG.

Here, a "three-dimensional game space" is a virtual space in which objects such as characters are placed, and is a three-dimensional space in which three coordinate axes are associated. In the "three-dimensional game space", for example, player characters, NPCs, objects such as buildings, or background objects can be placed. In the example of a baseball game, a virtual space in which player characters, a ball, a home base, a stadium fence, and other objects used in the game are placed corresponds to an example of a "three-dimensional game space".

Moreover, a "moving object" is a game element that can move in a three-dimensional game space. A "moving object" can move, for example, in the air, on the ground, underground, on water, or underwater. In the example of baseball, soccer, or other ball games, a ball that moves in the air or rolls on the ground when a player character throws, kicks, or hits it with a bat or racket is an example of a "moving object." In addition, objects such as bows and arrows, cannonballs, missiles, discs, monsters, and torpedoes used in various games such as action games are also examples of "moving objects."
A "moving object" may be, for example, a ball, which moves via a moving object-dispatched object such as a pitcher character, or it may be, for example, a disc or a monster, which moves without the aid of a moving object-dispatched object.

As shown in FIG. 15, the game system 1 includes a control unit 110. The control unit 110 is realized by the CPU 11 of the game terminal 10 or the CPU 31 of the server 30 executing a game program stored in a storage device (ROM 12, RAM 13, auxiliary storage device 14, ROM 32, RAM 33, auxiliary storage device 34, etc.). Some of the functions of the control unit 110 may be realized by the game terminal 10, and the remaining functions may be realized by the server 30. Alternatively, all of the functions of the control unit 110 may be realized by the server 30, or all of the functions of the control unit 110 may be realized by the game terminal 10.

The control unit 110 includes a specific area setting unit 111 (an example of a specific area setting means), a mobile body moving unit 112 (an example of a mobile body moving means), and a determination unit 113 (an example of a determination means).

The specific area setting unit 111 has the function of setting a specific area within the three-dimensional game space, the specific area being divided into a number of three-dimensional small areas.

Here, the "specific area" refers to a specific three-dimensional area that exists within the three-dimensional game space. The "specific area" is divided into a plurality of three-dimensional small areas. In other words, a three-dimensional area that is composed of a plurality of three-dimensional small areas is a "specific area."
The "specific region" may be a three-dimensional region in which multiple small regions are gathered together without any gaps. Alternatively, the "specific region" may not be a single region, and one or more of the multiple small regions constituting the "specific region" may be separated from the other small regions. For example, a three-dimensional region consisting of multiple dispersed small regions may be the "specific region".

An object such as a three-dimensional block may be placed in the "specific area", or the object may not be placed therein.
It is desirable to enable a user to visually recognize the "specific area" even if no object such as a block is placed in the "specific area." For example, it is desirable to make the "specific area" display in a different state from other areas (for example, by making the color, density, transparency, blinking state, etc. of the area different).

The "specific region" can be any three-dimensional shape. When the "specific region" is a single three-dimensional region, it can be set to, for example, a rectangular parallelepiped, a cube, a triangular pyramid, an octahedron, other polyhedrons, a sphere, a cylinder, or any other various three-dimensional shapes.
In addition, each of the multiple "small regions" that make up the "specific region" can also be made into any three-dimensional shape. The multiple "small regions" that make up the "specific region" may all have the same shape, or one or more of the multiple "small regions" may have a shape different from the others.

For example, when dividing a "specific region" into multiple "small regions", it is possible to divide the "small regions" evenly so that all the "small regions" have the same shape. For example, if the "specific region" is a block of a rectangular parallelepiped, all the "small regions" that make up the "specific region" are divided evenly into rectangular parallelepipeds of the same volume and shape.
In addition, when the "specific region" is a solid cylinder, for example, it may be divided into concentric circles around the axis of the cylinder so that the volumes and shapes of the "small regions" are non-uniform. In the case of a "specific region" that is a solid polyhedron or sphere, it may also be divided so that the "small regions" are non-uniform and have various shapes.

In addition, the shapes of at least some of the multiple "small regions" that make up the "specific region" may differ from the others, but the volumes of the multiple "small regions" may all be the same.

Also, for example, even in the case of a "specific area" in which one or more "small areas" are separated (for example, in the case where multiple "small areas" are dispersed), the multiple "small areas" that make up the "specific area" may all have the same shape, or one or more of the multiple "small areas" may have a different shape from the others.

The "specific area" may also be made not to move (i.e., its position within the three-dimensional game space may be fixed). Alternatively, the entire "specific area" or at least one of the multiple "small areas" that make up the "specific area" may be made to move (more details on this will be given later).

In the baseball game example mentioned above, the specific area setting unit 111 has the function of setting a specific area between the pitcher character PC and the catcher character CC in the three-dimensional game space, in which a block group BG, which is divided into multiple three-dimensional blocks B, is arranged.

The moving body moving unit 112 has a function of moving the moving body based on a user operation. Here, a "user operation" is an operation performed by a user to move a moving body. For example, an operation for determining a movement parameter of a moving body corresponds to an example of a "user operation". This user operation may be an operation of selecting one option from a plurality of options, or may be an operation that does not involve the option.

For example, in a baseball game, pitches such as a straight, curve, slider, and fork correspond to movement parameters that indicate the trajectory change of a ball as an example of a moving object, and "the operation of selecting one of a number of pitches" corresponds to an example of the user operation. Note that the operation may not involve options, and may directly specify, for example, the direction of rotation or number of rotations of the ball by touch operation or numerical input.

In addition, an operation for determining a movement parameter related to a destination position of a moving object may be included in the "user operation." In the baseball game example, an "operation for specifying a pitching position (position coordinates) in the strike zone and its surrounding area" corresponds to an example of the user operation.
Furthermore, an operation for determining a movement parameter related to the moving speed of a moving object may be included in the "user operation." In the baseball game example, an "operation for specifying a ball speed by inputting a numerical value or the like" corresponds to an example of the user operation. Also, since the ball speed differs depending on the type of ball, such as a straight or curve, selecting one of a plurality of ball types results in selecting the ball speed associated with the selected type of ball. Therefore, an "operation for selecting one of a plurality of ball types" corresponds to an example of a user operation for determining a movement parameter related to the moving speed.
Furthermore, a timing operation for specifying the timing at which the moving object starts moving may be included in the “user operation.” The timing operation will be described in detail later.

Furthermore, the user operation may be, for example, an operation of a physical button, a touch input operation on a touch interface, an operation using a pointing device, or an operation by voice input, etc.

In the baseball game example described above, the mobile object moving unit 112 has a function of causing the pitcher character PC to pitch the ball based on user operations including a pitch type selection operation, a pitching position designation operation, or a pitching start timing input operation.

The determination unit 113 also has a function of determining the small area present on the trajectory along which the moving object moves. Here, "trajectory" refers to the path along which the moving object moves in the three-dimensional game space. In the example of a baseball game, the path of the ball moving through the three-dimensional game space while changing depending on the type of pitch, such as a straight, curve, slider, or fork, is an example of a "trajectory". In the example of a soccer game, the path of the ball moving through the three-dimensional game space while changing depending on the type of spin applied when kicking is an example of a "trajectory".

In addition, "identifying a small area" means, when a moving body passes through at least a part of a specific area while moving, determining which of the multiple small areas that make up the specific area is located on the trajectory along which the moving body moves.
For example, determining a small area present on the path along which a moving body moves by performing a collision detection between the moving body and the outer circumferential surface of the small area corresponds to an example of "identifying a small area". In addition, in the case where a small object corresponding to the small area (i.e., a small object having the same shape as the small area) is arranged in each of the multiple small areas constituting a specific area, the following may be performed. That is, a small object present on the path along which the moving body moves may be identified by performing a collision detection between the moving body and the small object, thereby identifying the small area corresponding to the small object. Note that the above-mentioned collision detection can be performed by applying known algorithms such as contact detection, overlap detection, and collision detection.
The small area is a three-dimensional solid shape, and if the moving object comes into contact with any part of the outer circumferential surface of the solid shape, the small area is identified as existing on the trajectory along which the moving object moves.

For example, determining the overlap between the trajectory line of the moving body and a three-dimensional small area to determine the small area that exists on the trajectory along which the moving body moves corresponds to an example of "identifying a small area." Here, the trajectory line of the moving body may be, for example, a line of the path of the center point of the moving body, or a line with a width whose cross-sectional area is a plane (xy plane) perpendicular to the moving direction (z-axis direction) of the moving body.

The process of "identifying small areas" may be executed when the moving object actually comes into contact with each small area, or may be executed before the contact if the movement of the moving object and small areas can be calculated internally before the contact. As an example, in the case of a baseball game, when the ball, which is an example of a moving object, is released from the pitcher character PC, the trajectory of the ball is calculated and determined internally. Furthermore, the movement of a specific area (e.g., an area formed by the block group BG) may also be predetermined (or the specific area may not move). In this case, the process of identifying small areas present on the trajectory along which the ball moves may be executed before the ball reaches the specific area (e.g., calculated internally at the time the ball is released).

In the baseball game example mentioned above, the identification unit 113 has a function of identifying block B that exists on the trajectory of the pitched ball by determining whether the ball hits block B (thereby identifying a small area that corresponds to block B).

It is preferable that the specific area setting unit 111 sets the specific area as a group of a plurality of the small areas. In this case, the identification unit 113 can continuously identify adjacent small areas that exist on the trajectory along which the moving body moves.

Here, "a specific area consisting of multiple small areas" refers to a single three-dimensional area in which the multiple small areas that divide the specific area are gathered in one place with no gaps. Since adjacent small areas are in contact with each other with no gaps, when a moving object passes through the specific area, it is possible to continuously identify adjacent small areas that exist in the trajectory of the moving object.

In the example of the baseball game mentioned above, the specific area setting unit 111 sets a specific area in the three-dimensional game space in which a group of blocks BG, consisting of a number of blocks B packed together with no gaps, is placed. This allows the identification unit 113 to continuously identify adjacent blocks B that exist on the trajectory of the pitched ball (and thereby continuously identify adjacent small areas that correspond to the blocks B).

With the above configuration, the entire trajectory of the ball as it passes through the block group BG is used to continuously identify multiple adjacent blocks B without any gaps, so the user needs to consider the entire trajectory of the ball as it passes through the block group BG when throwing the ball, making the game more interesting.

The specific area setting unit 111 preferably places a number of small objects corresponding to the number of small areas. Here, a "small object" is an object that corresponds to each of the multiple small areas that make up the specific area and has the same shape as the small area. The outer peripheral surface of the "small object" coincides with the outer peripheral surface of the small area. Furthermore, when a small area moves, the "small object" corresponding to that small area also moves. Therefore, identifying a "small object" that exists on the trajectory along which the moving body moves can be equivalent to identifying a small area that corresponds to the "small object."

A "small object" is a game element that is visible to the user, such as a translucent block. A "small object" may be erased or otherwise affected when it comes into contact with a moving object or when a moving object passes over it, or the moving object may pass over it without any effect being applied.

In the baseball game example described above, each block B constituting the block group BG corresponds to a "small object." The specific area setting unit 111 places multiple blocks B corresponding to multiple small areas in the three-dimensional game space. With this configuration, multiple corresponding blocks B are placed in the multiple small areas constituting the specific area, making it easier for the user to aim at the blocks B.

As shown in FIG. 17, the control unit 110 of the game system 1 can be configured to include an action unit 114 (an example of an action means). This action unit 114 has a function of exerting an action on the small object corresponding to the small area identified by the identification unit 113.

Here, "acting on a small object" means to have some effect on the small object. For example, erasing a small object, destroying it, moving it to another location, changing its color, changing its transparency, changing its blinking state, etc. are examples of "acting on a small object." Also, if rewards such as points are awarded according to one or more small objects that have been acted upon, putting the small object in a state in which the reward can be obtained is an example of "acting on a small object."

In the baseball game example described above, the action unit 114 exerts an action of erasing the block B identified by the identification unit 113. With this configuration, the game can be developed according to whether or not an action has been applied to the block B, or according to the distribution of the block B to which an action has been applied (or which remains without an action being applied), thereby improving the playability of the game.

As shown in FIG. 17, the control unit 110 of the game system 1 can be configured to include an area moving unit 115 (an example of an area moving means). This area moving unit 115 has a function of moving the entire specific area or a part of the multiple small areas that make up the specific area.

Here, "moving the entire specific area" means, in the case of a specific area that is a collection of multiple small areas, moving that specific area in the three-dimensional game space (i.e., changing the position coordinates in the three-dimensional game space). Movement of the specific area includes horizontal movement, vertical movement, diagonal movement, rotational movement (forward rotation: clockwise, reverse rotation: counterclockwise, including both forward and reverse rotations), back and forth movement, zigzag movement in random directions, and movement that combines multiple of these types of movement (or movement directions). In the case of rotational movement, it may be rotational movement around the central axis of the specific area, rotational movement around an axis offset from the central axis, or rotational movement around an arbitrary point.

In addition, the way in which the specific area moves (such as the direction of movement) may be changed each time the moving object is moved. As an example, in a baseball game, when the nth ball (n is a natural number equal to or greater than 1) is pitched, the specific area may move back and forth, for example, in the horizontal direction, and when the (n+1)th ball is pitched, the specific area may move back and forth in a direction different from the above, for example, in the vertical direction.

For example, every 5 seconds, the direction of movement of the specific area is switched between left and right (horizontal back and forth movement) and up and down (vertical back and forth movement). Note that the "predetermined period" does not need to be constant (fixed); the length of the "predetermined period" may vary, for example, so that left and right movement lasts 3 seconds and up and down movement lasts 5 seconds.

In addition, in the case of a specific area in which one or more small areas are separated (for example, in the case of a specific area in which multiple small areas are dispersed), moving all of the multiple small areas that make up the specific area corresponds to an example of "moving the entire specific area." In this case, the multiple small areas that make up the specific area may all move in the same way, or each of the multiple small areas may move separately. As one example, some of the multiple small areas that make up the specific area may move back and forth in the horizontal direction, other parts may move back and forth in the vertical direction, and still other parts may move in a rotational motion, for example. In other words, at least one of the multiple small areas that make up the specific area may move differently from the others.

Regarding the movement speed of the specific area, the movement speed may be constant (fixed) at all times during movement, or the movement speed may be changed during movement. In addition, the movement speed of the specific area may be constant (fixed) no matter how many times the moving body is moved, or the movement speed of the specific area may be changed each time the moving body is moved. As an example, in a baseball game, the difficulty level may be changed by increasing the movement speed of the specific area as the stage progresses after a certain number of pitches, or as the number of pitches increases in the same stage.

When multiple small objects (such as block B) are arranged in correspondence with multiple small regions that make up a specific area, moving the entire specific area or parts of the multiple small regions that make up the specific area also means moving the corresponding small objects.

In addition, "moving a portion of a plurality of small regions" means partially moving a portion (at least one) of the plurality of small regions that make up a particular region in the case of a particular region in which one or more small regions are separated (for example, in the case of a particular region in which multiple small regions are dispersed). The movement of the small region to be moved is the same as the movement of the particular region described above.

In the baseball game example mentioned above, the area movement unit 115 has a function of linearly or rotationally moving the block group BG that forms the specific area. This configuration makes it possible to change the difficulty level of the game. In addition, the user is required to move the ball while being conscious of the behavior of the block group BG and the trajectory of the ball, which enhances the playability of the game.

The area movement unit 115 may also complicate the movement of the entire specific area or the movement of a portion of the multiple small areas constituting the specific area as the game stage progresses each time the moving body is moved a predetermined number of times by the moving body movement unit 112, or as the number of times the moving body is moved by the moving body movement unit 112 increases.

Here, increasing the types of movement (or directions of movement) for the entire specific area of the moving object, or for the movement of parts of multiple small areas that make up the specific area, is an example of "complicating the movement". Increasing the speed of movement of the moving object is an example of "complicating the movement". Changing the speed of movement of the moving object rather than keeping it constant is an example of "complicating the movement".

In the baseball game example mentioned above, the area moving unit 115 complicates the movement of the block group BG forming the specific area as the game stage progresses, which progresses every time the moving body moving unit 112 moves the ball (pitches) a predetermined number of times (for example, four times). Note that, even within the same game stage, the movement of the block group BG may be made more complex as the number of pitches increases. Also, instead of a game stage system in which stages progress, the game may be one in which a predetermined number of pitches are made in one game. In this case, too, it is preferable to complicate the movement of the block group BG as the number of pitches increases.

According to the above configuration, the movement of the block group BG becomes more complicated as the game stage progresses or the number of balls thrown increases, increasing the difficulty of user operation. This can make the game more interesting.

The user operation may include a selection operation for selecting one of a plurality of options regarding a trajectory, where the "options regarding a plurality of trajectories" refer to options selectable by a user operation for determining a trajectory of a moving object that can move along a plurality of trajectories.
For example, in a baseball game, pitches such as a straight, curve, slider, and fork correspond to movement parameters that indicate the trajectory change of a ball as an example of a moving object. Therefore, "an operation of selecting one of a plurality of pitches that the pitcher character PC can pitch" corresponds to an example of "a selection operation of selecting one of a plurality of options related to trajectories (hereinafter, simply referred to as a "selection operation"). Also, for example, the way of gripping the ball differs depending on the pitch, and if the way of gripping the ball changes, the rotation applied to the ball changes, which changes the trajectory of the ball, so the way of gripping the ball is an element that causes the trajectory change. Therefore, "an operation of selecting one of a plurality of ways of gripping the ball" also corresponds to an example of the "selection operation". Also, since the trajectory of the ball changes depending on the rotation direction or the number of rotations of the ball, the rotation direction or the number of rotations of the ball is an element that causes the trajectory change, and "an operation of selecting one of a plurality of rotation directions or numbers of rotations of the ball" also corresponds to an example of the "selection operation".

For example, in a soccer game, if the type of kick affects the rotation of the ball, which in turn affects the ball's trajectory, then the type of kick is an element that changes the trajectory, and an "operation of selecting one of a number of kick types" is an example of the "selection operation."

As illustrated in FIG. 17, the control unit 110 of the game system 1 can be configured to include a bonus granting unit 116 (an example of a bonus granting means). This bonus granting unit 116 has a function of granting a predetermined bonus for each of the multiple trajectory options when the number of times the option selected by the user has been selected is within a predetermined number of times.

Here, a "benefit" may be anything that can be recognized as having value by the game provider or user. For example, game points, in-game currency, game items, game characters, or rights related to the game are examples of "benefits." Rights related to the game include, for example, the right to play a specific game mode, or the right to participate in an event such as a tournament held within the game. Furthermore, a "benefit" does not have to be something used within the game, and may be, for example, a prize or a gift.

The "benefit" is set with a condition that the number of times an option selected by the user is selected is within a predetermined number. The predetermined number may be "1", or may be "2" or more, and can be set to any number. For example, if the predetermined number is set to "1", the benefit is only given the first time each option is selected. Since the benefit is not given for options selected more than the predetermined number of times, the user can be motivated to select various options (e.g., types of pitches).
In the example of the baseball game mentioned above, the bonus granting unit 116 has the function of granting the user a "first selection bonus" for each of the multiple "types of pitches" that the pitcher character PC can throw only when the user selects each of them once (i.e., only the first selection).

The multiple trajectory options may be one of the parameters associated with the control object that moves the moving object. Here, the "control object" is an object such as a character that is the object to be controlled by the user in the game. The "control object" includes game characters that represent people such as athletes, living things such as animals, fictional characters or living things such as monsters, and non-living things such as robots. In the example of a baseball game, a pitcher character that throws the ball, which is an example of a moving object, corresponds to an example of an "control object". Also, in the example of a soccer game, a player character that kicks the ball, which is an example of a moving object, corresponds to an example of an "control object".

The "parameters" mentioned above are information about the operation object associated with the operation object. The "parameters" include multiple options regarding trajectories. In the baseball game example, information about the balls (multiple types of pitches that can be thrown) associated with the pitcher character PC of the operation object corresponds to an example of "multiple options regarding trajectories" as one parameter.

The parameter of the operation target may be changed or set in a second game different from the game. Here, with respect to the "second game different from the game," the game and the second game may each be a part of a certain game, or may be separate games. That is, the game and the second game may each be a part of a game executed by a certain game program, or the game may be executed by a first game program, and the second game may be executed by a second game program.

Moreover, the term "changing a parameter" refers to changing a parameter set for a character. For example, improving or decreasing a parameter set for a character is an example of "changing a parameter." In the example of a pitcher character in a baseball game, improving the value of the amount of change in a curveball is an example of "changing a parameter."
Moreover, the above-mentioned "setting a parameter" means, for example, setting a parameter that has not yet been set for a character to that character. For example, adding a capability or the like that the character did not have to that character (for example, associating a new option related to trajectory with the character) is an example of "setting a parameter". In the example of a pitcher character in a baseball game, adding a new pitch type that the pitcher character does not have (has not mastered) is an example of "setting a parameter".

In the baseball game example mentioned above, the pitcher character PC to be operated has had the parameters of his or her balls changed or set in a training mode game that is different from the game in which the block group BG is the target. As a result, the number of selectable pitches and the amount of change for each pitch may differ depending on the control object created in training mode. By creating a pitcher character PC to be operated in training mode that has a large number of selectable pitches and various amounts of change, the user can progress through the game with an advantage. This can motivate the user to play the game in training mode.

As illustrated in FIG. 17, the control unit 110 of the game system 1 can be configured to include a predicted trajectory display unit 117 (an example of a predicted trajectory display means). The predicted trajectory display unit 117 has a function of displaying a predicted trajectory for predicting the trajectory of the moving body after it has moved before the moving body starts to move. Here, the "predicted trajectory" is information on the trajectory that the moving body may take after it has been moved, which is displayed on the screen before the moving body starts to move, and is information for the user to predict in advance the trajectory of the moving body after it has moved. In the example of a baseball game, after the user specifies the type of ball and/or the target pitching position, and before the ball is released, information on the trajectory corresponding to the type of ball and/or the target pitching position corresponds to an example of the "predicted trajectory". In the example of a soccer game, after the user specifies the type of kick (type of spin) and/or the target position of the shot, and before the ball is kicked, information on the trajectory corresponding to the type of kick and/or the target position of the shot corresponds to an example of the "predicted trajectory".

In the baseball game example mentioned above, as shown in Figures 7 and 8, the predicted trajectory display unit 117 has a function of displaying a predicted trajectory PT on the screen to predict the trajectory of the ball after pitching before the pitcher character PC starts the pitching motion or before the ball is released by the pitcher character PC. The predicted trajectory PT corresponds to the type of pitch selected by the user. In addition, when the user performs an operation to move the target pitching position, the predicted trajectory PT also changes in conjunction with the movement of the target pitching position.

The above configuration allows the user to perform user operations for pitching while visually checking the predicted trajectory PT that is displayed before the ball is released by the pitcher character PC, thereby improving user operability.

The user operation may also include a timing operation that specifies the timing at which the moving object starts moving. In the baseball game example described above, the user operation includes a "pitching start timing input operation" using the timing gauge P410 shown in FIG. 7. Here, the "timing operation" is one of the operations performed by the user before the moving object starts moving, and is an operation that specifies the timing at which the moving object starts moving. However, there may be cases where the moving object does not start moving based on the timing at which the timing operation is performed. For example, if the timing operation is not performed within the time limit for starting the movement, the moving object may start moving after the time limit has elapsed.

The moving body moving unit 112 may then change the trajectory along which the moving body moves from the predicted trajectory based on the timing of the timing operation. Here, "changing the trajectory along which the moving body moves from the predicted trajectory" refers to changing the trajectory along which the moving body moves from the predicted trajectory based on the timing of a timing operation performed by the user, thereby causing a deviation in the trajectory. Depending on the timing of the timing operation, the trajectory may not be changed from the predicted trajectory. For example, if a timing operation is performed during a specific period, the trajectory may not be changed from the predicted trajectory, and the trajectory may be changed from the predicted trajectory only when a timing operation is performed outside the specific period. In this case, for example, the deviation from the predicted trajectory may be increased as the timing of the timing operation is farther from the specific period.

In the example of the baseball game mentioned above, the moving body moving unit 112 changes the trajectory of the ball released from the pitcher character PC from the predicted trajectory PT displayed before the pitch, based on the timing of the pitch start timing input operation using the timing gauge P410. Specifically, if the pitch start timing input operation is not performed at the timing when the part P4106 passes through the nice pitch zone E4103 (referred to as the "nice pitch timing"), the ball's trajectory is made to deviate from the predicted trajectory PT displayed before the pitch. Alternatively, if the pitch start timing input operation is not performed at the nice pitch timing, the probability that the ball's trajectory will deviate from the predicted trajectory PT is made higher than when the pitch start timing input operation is performed at the nice pitch timing.

With the above configuration, depending on the timing of the pitch start timing input operation, deviation from the predicted trajectory PT displayed before the pitch may occur, and the ball may not move along the trajectory intended by the user. Therefore, the user is required to input the timing accurately, which can improve the playability of the game.

4. Processing
Next, an example of the processing executed by the game system 1 of this embodiment will be described below. Here, an example of the processing executed by the game system 1 when executing the above-mentioned baseball game will be described.

Figures 18 to 20 are flowcharts showing an example of processing of the game system 1. The processing described below is realized by the control unit 110 (CPU 11 of the game terminal 10 or CPU 31 of the server 30) executing a game program stored in a storage device (ROM 12, RAM 13, auxiliary storage device 14, ROM 32, RAM 33, auxiliary storage device 34, etc.).

First, the process is started by the user selecting a game in which a block group BG is cleared by pitching. The user can select the pitch type before the game starts (or immediately after the game starts). Pitch types include the previously mentioned "pitching type with three touch operations" or "pitching type with one touch operation." Here, an example of the process when the "pitching type with three touch operations" is selected will be described.

At S100 in FIG. 18, the control unit 110 performs a player selection process. Specifically, the control unit 110 displays a selection screen for multiple pitching characters that can be used in the game on the display unit 17. The selection screen displays multiple pitcher development players that the user has developed in the development mode, pitcher event characters owned by the user, and predetermined pitcher characters (e.g., a specified character prepared by the game management side). The control unit 110 stores information about the pitching character selected by the user on the selection screen as used pitcher data DT1021 in FIG. 16.

In S102, the control unit 110 performs a process of calculating the unit cost of a score. Specifically, the control unit 110 calculates the unit cost of an "elimination score" based on the parameters of the "pitch speed" and "rank" of the pitcher character PC used. The control unit 110 also calculates the unit cost of a "line score" based on the parameters of the "control" and "attraction" of the pitcher character PC used. The control unit 110 stores information on the calculated unit cost of each score as the unit cost of a score data DT1022 in FIG. 16.

In S104, the control unit 110 sets the remaining number of blocks, i.e., the number of stages, to a predetermined value ("3" in this embodiment), and stores this as stage data DT1026 in FIG. 16. In S106, the control unit 110 displays the block group BG in the initial state in which none of the blocks B have been erased, in the three-dimensional game space, as shown in FIG. 4.

In S108, the control unit 110 performs a process of setting a bonus multiplier. Specifically, the control unit 110 sets the multiplier of a "breaking ball bonus" to be applied to each type of pitch owned by the pitcher character PC in use according to the amount of change in each type of pitch. The control unit 110 also sets the multiplier of a "first selection bonus" to be applied to each type of pitch. The control unit 110 stores information on the multiplier of each bonus as bonus data DT1023 in FIG. 16.
In S110, the control unit 110 sets the number of balls that can be thrown for each block group (each stage) to a predetermined value ("4" in this embodiment) and stores it as remaining ball count data DT1027 in FIG.

In S112, the control unit 110 determines the movement pattern of the block group BG. As described above, the possible movement patterns differ for each stage, and the movement patterns become more complex as the stage progresses. In a stage where multiple movement patterns exist, the movement pattern is selected at random, for example. Alternatively, the movement pattern to be applied for each pitch may be determined in advance. The control unit 110 stores information on the determined movement pattern as block group movement pattern data DT1025 in FIG. 16.
In S114, the control unit 110 moves the block group BG in the determined movement pattern. The movement of the block group BG continues until the movement of the block group BG is temporarily stopped in S126 described below.

In S116, the control unit 110 performs a pitch selection process. Specifically, as shown in FIG. 4, the control unit 110 displays pitch selection buttons P311-P316 and parts P322-P326 indicating the amount of change in each curveball in the pitch selection area A307 of the game screen G300. The control unit 110 then stores information about the pitch selected by the user on the game screen G300 in the game management data DT102.

In the subsequent S118, the control unit 110 displays a predicted trajectory PT according to the selected pitch type, as illustrated in FIG. 7. The predicted trajectory PT is initially set so that the target pitch position is in the center of the strike zone, for example. Note that the initial setting of the target pitch position does not have to be the center of the strike zone, and any position can be set as the initial position. The predicted trajectory PT is calculated by applying a known algorithm based on the selected pitch type, the amount of change of that pitch type, the target pitch position (initial setting position), etc. The control unit 110 stores the predicted trajectory PT information in the game management data DT102.

Although this is omitted from the flowchart, if the user performs an operation to reselect the pitch type, the process returns to S116. In other words, the user can look at the predicted trajectory PT displayed on the screen and decide whether or not to change the pitch type.

In S120 of FIG. 19, the control unit 110 determines whether an operation to move the target pitching position has been performed. In this embodiment, the control unit 110 determines whether the user has slid the finger F touching the screen as shown in FIG. 8. If the sliding operation has been performed (YES in S120), the control unit 110 changes the predicted trajectory PT by moving the target pitching position (i.e., the end PT1 of the predicted trajectory PT on the catcher character CC side) in conjunction with the displacement of the finger F accompanying the sliding (S122). The user can check the change in the predicted trajectory PT in real time while moving the target pitching position, and fine-tune the target pitching position. The processes of S120 and S122 are repeated until the target pitching position is confirmed (YES in S124).

In S124, the control unit 110 determines whether an operation to confirm the target pitching position has been performed. In this embodiment, the control unit 110 determines whether the user has performed a touch-off operation in which the user removes his/her finger from the screen. If the user has performed a touch-off operation (YES in S124), the control unit 110 stores the position of the end PT1 of the predicted trajectory PT at the time of touch-off in the game management data DT102 as information on the target pitching position specified by the user (S126). The control unit 110 also stores information on the predicted trajectory PT that has been changed due to the movement of the target pitching position in the game management data DT102 (S126).

The control unit 110 also temporarily stops the movement of the block group BG when the operation to confirm the target pitching position (the touch-off operation) is performed (S128). Furthermore, the control unit 110 moves the part P4106 of the timing gauge P410 illustrated in FIG. 7 at a constant speed (S130). This allows the user to input the pitching start timing. During the period when the pitching start timing input operation is possible, the movement of the block group BG is temporarily stopped. If the user performs the pitching start timing input operation (YES in S132), the control unit 110 executes the next process based on the timing. That is, the control unit 110 determines whether the pitching start timing input operation was performed when the part P4106 was passing through the nice pitch zone E4103 (S134), and if YES, proceeds to S136, and if NO, proceeds to S138.

In S136, the control unit 110 generates a nice pitch bonus, and stores information on the bonus rate as bonus data DT1023 in Fig. 16. Also, when input at the timing of a nice pitch, it is possible to prevent the trajectory of the actual pitch from deviating from the predicted trajectory PT without causing any disturbance in control (deviation from the target pitch position).
It is possible to allow deviation from the target pitch position to occur based on a certain probability, but if the pitch is input at the timing of a nice pitch, the probability of such deviation occurring is lower than if the pitch is not input at that timing, and the range of deviation is also made smaller.

On the other hand, in S138, the control unit 110 generates a deviation from the predicted trajectory PT due to a loss of control (deviation from the target pitching position). For example, the control unit 110 makes the deviation from the target pitching position larger (or the range of deviation larger) when the input is made at the timing of region E4101 in FIG. 7 than when the input is made at the timing of region E4102. Also, for example, when an input is made at the timing of region E4104, the deviation from the target pitching position is made the largest (or the range of deviation is made the largest, or the pitch is made to be near the center of the strike zone regardless of the target pitching position). Due to the occurrence of the deviation in the pitching position, the control unit 110 changes the target pitching position specified by the user stored in S126 to the actual pitching position and stores it in the game management data DT102. Accordingly, the control unit 110 also changes the trajectory of the ball to be actually pitched from the predicted trajectory PT and updates (overwrites) it, and stores the updated information in the game management data DT102.

In addition, when the timing to start pitching is input (YES in S132), the control unit 110 causes the pitcher character PC to start pitching (S140) and also causes the movement of the block group BG, which had been temporarily stopped, to resume (S142).

Then, in S144 of FIG. 20, the control unit 110 moves the ball released by the pitcher character PC in the three-dimensional game space based on the predicted trajectory PT information stored in the game management data DT102 (or the updated information if updated).

In S146, the control unit 110 identifies a block B on the trajectory of the ball moving in the three-dimensional game space. For example, the control unit 110 executes a process to determine a block B that comes into contact with the ball. In S148, the control unit 110 erases the identified contact block B. Then, the control unit 110 updates the block management data DT1024 in FIG. 16.

In S150, the control unit 110 calculates the score acquired by the user based on the number of erased blocks B and the number of completed lines, and applies the multiplier of the applicable bonus, and reflects this on the game screen. The control unit 110 also updates the score data DT1028 in FIG. 16.

In S152, the control unit 110 cancels the initial bonus for the type of ball used this time, and updates the bonus data DT1023.
In S154, the control unit 110 reduces the number of balls for each block group by one and updates the remaining ball count data DT1027. In S156, the control unit 110 determines whether the number of balls for each block group is greater than 0. If the number of balls for each block group is greater than 0 (YES in S156), the process returns to S112 in Fig. 18, where the control unit 110 determines the movement pattern of the block group BG for the next pitch, and thereafter executes each of the processes described above.

On the other hand, if the number of balls for each block group is 0 (NO in S156), the current stage ends, and the control unit 110 judges whether the remaining number of blocks in the block group is greater than 0 (S158). If the remaining number of blocks in the block group is greater than 0 (YES in S158), the control unit 110 displays the results for each stage on the screen (S160). Then, the control unit 110 erases the block group BG currently displayed on the screen (S162). The control unit 110 also reduces the number of balls for each block group by one and updates the stage data DT1026 (S164). After that, the process returns to S106 in FIG. 18, and the control unit 110 displays the block group BG in the initial state in which no blocks B have been erased for the next stage, and thereafter executes each of the above-mentioned processes.
Furthermore, if the remaining number of blocks is 0 (NO at S158), the control unit 110 executes an ending process, such as displaying the total score or giving the user a reward according to the score (S166), and ends the game.

［５． Summary］
Conventionally, the target is flat (two-dimensional), and it is not taken into consideration whether the ball has contacted the target at any point other than the front, so the user only needs to think about hitting the front of the target. In contrast, in the game system 1 according to the embodiment described above, the target is a specific area formed by a three-dimensional block group BG that is divided into a plurality of three-dimensional small areas (blocks B). By making the target solid (three-dimensional), the user becomes aware of the actual trajectory of the ball, and an unprecedented interest is obtained. In other words, when the ball contacts (or passes through) the three-dimensional block group BG, there are many possible trajectories, including the depth, and the user's strategy for attacking the target becomes more complicated, which can improve the interest of the game compared to conventional games.

[6. Modifications]
The present invention is not limited to the above-described embodiment.
[6-1] In the above, an example was shown in which the pitcher character PC used in the game is selected by the user from among a training player, an event character, and a predetermined pitcher character, but the present invention is not limited to this. For example, the pitcher character used in the game may be predetermined (for example, every user always uses a specific character prepared by the game management side).

[6-2] In the above, the "game of eliminating block B by pitching a ball" has been described as one of multiple games that can be executed by the game system 1 or the game terminal 10, but the game may be a standalone game that does not include other games.

[6-3] In the above, three game stages are provided, each of which allows four balls to be thrown, but the number of balls thrown per stage and the number of stages can be set arbitrarily. The game end condition may be determined by a time limit, rather than the number of balls thrown. For example, any number of balls may be thrown within the time limit. As the game end condition, both a time limit and an upper limit on the number of balls thrown may be set, and the game may end when either of the conditions is met. The game may be designed to compete for the time it takes to erase all of the blocks B constituting the block group BG. Alternatively, the game may be designed to compete for the number of balls required to erase all of the blocks B constituting the block group BG. Alternatively, the game may be designed to compete for the number of blocks B that can be erased within the time limit. Furthermore, multiple types of blocks B may be provided, and the score obtained may be changed depending on the blocks B. Furthermore, even if a block B present on the trajectory of the thrown ball is identified, the identified block B may not be erased, and a score according to the identified block B may be given, for example. In this way, various game specifications can be applied to games that identify "three-dimensional small areas" that exist on the trajectory of a moving object, such as a ball, moving through a three-dimensional game space.

[6-4] In the above, the specification for making the pitcher character PC pitch the ball based on user operations including the pitch type selection operation, the pitch position designation operation, and the pitch start timing input operation has been described, but is not limited to this. As described above, the pitch start timing input operation can be omitted. In this case, steps S128 to S138 and S142 in the flowchart of FIG. 19 can be omitted.
In addition, the operation of specifying the pitching position may be omitted, and the pitcher may be able to pitch only by selecting the type of ball. In this case, the target pitching position may be a predetermined position (for example, the center of the strike zone, etc.), or may be deviated from the predetermined position depending on the parameters (control ability) of the pitcher character PC used.
Alternatively, the pitcher may be able to pitch by performing two operations: a pitch type selection operation and a pitch start timing input operation. In this case, the target pitch position is a predetermined position (for example, the center of the strike zone, etc.), but as described above, the target pitch position may be shifted depending on the timing of the pitch start timing input operation.
Alternatively, the pitch type selection operation may be omitted, and the pitch type may be selected at random from the pitches possessed by the pitcher character PC, for example.
These are just examples, and in the case of a baseball game, the user operations may include at least one of a pitch type selection operation, a pitch position designation operation, and a pitch start timing input operation.

Also, instead of the pitch type selection operation described above, for example, a ball swiping operation (specifically, an operation of tracing the screen with a finger (one example of a pointer) to specify the ball's trajectory) may be applied. Also, while the ball's trajectory is specified by swiping the ball with a finger, the target pitching position may be specified by removing the finger from the screen. This ball swiping operation makes it possible to specify the ball's trajectory and the target pitching position substantially simultaneously with a single touch operation on the screen.
Similarly, in a soccer game, for example, it may be possible to select a trajectory and specify a shooting course by swiping the ball as a moving object (specifically, by tracing the screen with a finger to specify the trajectory of the ball and then lifting the finger from the screen to specify the shooting course (target position)).

[6-5] In the above, an example has been described in which the movement of the block group BG is temporarily stopped during the period for inputting the pitch start timing when the pitch start timing input operation is included in the user operations. In this case, the user is required to perform an operation when the movement of the block group BG stops at a timing when the pitch start timing input operation becomes possible (for example, the timing of the pitch position designation operation in the case of a "pitching type with three touch operations" or the timing of the ball type selection operation in the case of a "pitching type with one touch operation"). However, since the movement of the block group BG is temporarily stopped during the subsequent pitch start timing input operation, the user can concentrate on operating at the timing of a nice pitch.

Without being limited to the above, even if the pitch start timing input operation is included in the user operation, the block group BG may continue to move without pausing. In this case, not only does it become necessary to input the pitch start timing while taking into account the behavior of the block group BG, but it also becomes necessary to time a nice pitch, making the game significantly more difficult.

Even if the pitch start timing input operation is included in the user operations, if there is no need to aim for the timing of the nice pitch mentioned above and the predicted trajectory is not changed depending on the input timing, there will be less need to temporarily suspend the block group BG.

[6-6] It may be possible to select a pitch type that does not have a set direction of change in trajectory (such as a knuckleball). For this type of pitch, the direction of change is determined randomly from a number of possible directions when the ball is pitched.

[6-7] Although the above mainly describes an example of a baseball game, the present invention can also be applied to other games. For example, the present invention can be applied to a variety of games, regardless of the game format or genre, as long as they are "games in which a moving object moves within a three-dimensional game space," such as other sports games (games themed around soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), fighting games, role-playing games, simulation games, adventure games, or training games.

[6-8] The game terminal 10 and the server 30 can communicate with each other to send and receive various data. Both are information processing devices (computers) equipped with a CPU, ROM, RAM, auxiliary storage device, communication unit, etc., and basically have the same hardware configuration. Therefore, some of the various functions described above may be realized by the CPU 11 of the game terminal 10, and the rest by the CPU 31 of the server 30. Alternatively, all of the various functions described above may be realized by the CPU 11 of the game terminal 10. Alternatively, all of the various functions described above may be realized by the CPU 31 of the server 30.

[6-9] Regarding the configuration having a storage control function for storing various information in a storage device, the storage device itself is not included in the configuration, and may be installed anywhere, whether inside or outside the game system 1. For example, the storage device may be a storage device within the game system 1 (e.g., RAM 13, auxiliary storage device 14, RAM 33, auxiliary storage device 34, database DB, etc.), or a file server (online storage) configured separately from these.

[6-10] The computer-readable program according to this embodiment is recorded on various computer-readable recording media such as a hard disk, optical disk (CD-ROM, DVD-ROM, etc.), flexible disk, and semiconductor memory, and is read from the recording media and executed by the CPU of the computer that constitutes the game system 1 or the game control device. In addition, the means for providing the program to the computer is not limited to the recording media mentioned above, and can also be via a communication network such as the Internet.

[7. Notes]
From the above description, the present invention can be understood, for example, as follows: In order to facilitate understanding of the present invention, reference numerals in the accompanying drawings are conveniently placed in parentheses, but the present invention is not limited to the illustrated embodiments.

1) A game system (1) according to one aspect of the present invention provides a game in which a moving object (e.g., a ball) moves within a three-dimensional game space, and includes a specific area setting means (111) for setting a specific area (e.g., an area where a group of blocks exists) within the three-dimensional game space, each of which is divided into a plurality of three-dimensional small areas (e.g., an area where blocks exist), a moving object moving means (112) for moving the moving object based on a user operation, and a specifying means (113) for specifying the small areas that exist on the trajectory along which the moving object moves.

11) A game control device (10 or 30) according to one aspect of the present invention provides a game in which a moving object (e.g., a ball) moves within a three-dimensional game space, and includes a specific area setting means (111) for setting a specific area (e.g., an area where a group of blocks exists) within the three-dimensional game space, each of which is divided into a plurality of three-dimensional small areas (e.g., an area where blocks exist), a moving object moving means (112) for moving the moving object based on a user operation, and a specifying means (113) for specifying the small areas that exist on the trajectory along which the moving object moves.

12) A program according to one aspect of the present invention is a program for causing a computer to function as a game system (1) described in any one of 1) to 10) or a game control device (10 or 30) described in 11).

13) An information storage medium according to one aspect of the present invention is a computer-readable information storage medium having the program described in 12) recorded thereon.

14) A method for controlling a game system (1) or a game control device (10 or 30) according to one aspect of the present invention is a method for controlling a game system (1) or a game control device (10 or 30) that provides a game in which a moving object (e.g., a ball) moves within a three-dimensional game space, and includes a specific area setting step (S106) for setting a specific area (e.g., an area in which a group of blocks exists) in the three-dimensional game space, each of which is divided into a plurality of three-dimensional small areas (e.g., an area in which blocks exist), a moving object moving step (S144) for moving the moving object based on a user operation, and a specifying step (S146) for specifying the small areas that exist on the trajectory along which the moving object moves.

Conventionally, the target is flat (two-dimensional), and whether or not the moving object has come into contact with the target other than in front of it is not taken into consideration, so the user only needs to think about hitting the moving object with the front of the target. In contrast, according to the above aspects 1), 11) to 14), the target is a "three-dimensional specific area" divided into "multiple three-dimensional small areas". Then, if the moving object moved based on the user's operation comes into contact with (or passes through) at least a part of the "three-dimensional specific area" as the target, the "three-dimensional small area" existing on the trajectory of the moving object is specified. In other words, each of the multiple small areas constituting the specific area can be a solid (three-dimensional) target. In this way, by making the target three-dimensional (three-dimensional), the user becomes aware of the actual trajectory of the moving object while it is moving, and an unprecedented interest is obtained. In other words, when the moving object comes into contact with (or passes through) the "specific area divided into multiple three-dimensional small areas," the trajectory of the moving object can be considered in many ways, including the three-dimensional depth of the small areas and the specific area. This makes the strategy for the user to move the moving object so that it touches (or passes through) a "specific area that is divided into multiple three-dimensional small areas" more complex, making the game more interesting than ever before.

2) In one aspect of the present invention, in the aspect described in 1) or 11) above, the specific area setting means (111) may set the specific area as a group of a plurality of the small areas (e.g., an area in which a group of blocks exists), and the identification means (113) may be capable of continuously identifying adjacent small areas that exist on the trajectory along which the moving body moves.

According to the aspect described in 2) above, the specific area is set so that multiple small areas come together to form a single mass without being separated. In other words, there are no gaps between adjacent small areas, and adjacent small areas that exist on the trajectory of a moving object moved by a user operation can be identified continuously. As a result, the entire trajectory of the moving object as it passes through the specific area is used to continuously identify multiple adjacent small areas without any gaps, so the user needs to move the moving object while considering the entire trajectory of the moving object passing through the specific area, which increases the interest of the game.

3) In one aspect of the present invention, in the aspect described in 1) or 2) above, the specific area setting means (111) may be configured to place a plurality of small objects (e.g., blocks) corresponding to a plurality of the small areas.

According to the aspect described in 3) above, a plurality of small objects corresponding to each of the plurality of small areas constituting the specific area are arranged in the plurality of small areas, so that the user can easily aim at the small objects.

4) In one aspect of the present invention, the aspect described in 3) above may further include an action means (114) that acts on the small object corresponding to the small area identified by the identification means (e.g., erases a block).

According to the aspect described in 4) above, an action such as erasure is applied to small objects corresponding to a small area specified by the trajectory of a moving object moved based on a user operation. This allows a game to be played according to whether or not an action has been applied to the small objects, or according to the arrangement of small objects to which an action has been applied (or which remain without an action being applied), thereby further enhancing the playability of the game.

5) In one aspect of the present invention, in any of the aspects described in 1) to 4) above, the present invention may further include an area moving means (115) for moving the entire specific area or a part of the multiple small areas that make up the specific area.

According to the aspect described in 5) above, the difficulty level of the game can be changed by moving the entire specific target area or parts of multiple small areas that make up the specific target area. In addition, the user must move the moving object while being conscious of the behavior of the specific area or small areas and the trajectory of the moving object, which further enhances the playability of the game.

6) In one aspect of the present invention, in the aspect described in 5) above, the area moving means (115) may be configured to complicate the movement of the entire specific area or the movement of a part of the multiple small areas constituting the specific area as the game stage progresses each time the moving body is moved a predetermined number of times by the moving body moving means (112) or as the number of times the moving body is moved by the moving body moving means (112) increases.

According to the aspect described in 6) above, as the game stage progresses or the number of times the moving object moves increases, the movement of the entire specific area or part of the small area becomes more complicated, and the difficulty of the user's operation increases. This can further increase the interest of the game.

7) In one aspect of the present invention, in the aspect described in any of 1) to 6) above, the user operation includes a selection operation for selecting one of a plurality of trajectory options (e.g., a plurality of pitch types), and may further include a bonus granting means (116) for granting a predetermined bonus (e.g., a first selection bonus) for each of the plurality of trajectory options when the number of times the option selected by the user is selected is within a predetermined number of times.

According to the aspect described in 7) above, the user selects multiple trajectory options and moves the moving object. Here, a condition for granting a bonus is set such that the number of times the "trajectory options" selected by the user are selected is within a predetermined number of times. Therefore, even if the moving object is moved based on a "trajectory option" that has been selected more than the predetermined number of times, no bonus is granted. This can motivate the user to select various trajectory options.

8) In one aspect of the present invention, in the aspect described in any of 1) to 7) above, the user operation includes a selection operation for selecting one of a plurality of trajectory options (e.g., a plurality of pitch types), the plurality of trajectory options being one of parameters associated with an operational object (e.g., a pitcher character) that moves the moving object, and the operational object may have the parameter changed or set in a second game (e.g., a training mode game) different from the game.

According to the aspect described in 8) above, the number of selectable "trajectory options" may vary depending on the control object whose parameters have been changed or set in the second game. The user can advance through the game to an advantage by creating a control object in the second game that has a large number of selectable "trajectory options" (by changing or setting parameters to create such a control object). This can motivate the user to play the second game.

9) In one aspect of the present invention, in any of the aspects described in 1) to 8) above, a predicted trajectory display means (117) may be further provided for displaying a predicted trajectory (PT) for predicting the trajectory of the moving body after the moving body starts to move before the moving body starts to move.

According to the aspect described in 9) above, the user can perform user operations to move the moving object while visually checking the predicted trajectory displayed before the moving object starts to move, thereby improving the operability for the user.

10) In one aspect of the present invention, in the aspect described in 9) above, the user operation may include a timing operation that specifies a timing for starting the movement of the moving body, and the moving body moving means (112) may change the trajectory along which the moving body moves from the predicted trajectory (PT) based on the timing of the timing operation.

According to the aspect described in 10) above, depending on the timing operation that specifies the timing when the moving object starts moving, deviation from the predicted trajectory displayed before the moving object starts moving may occur, and the moving object may not move on the trajectory that the user intended. Therefore, the user is required to perform timing operations accurately, which can further enhance the playability of the game.

The specific embodiments or examples given in the description of the invention are merely intended to clarify the technical content of the invention, and should not be interpreted in a narrow sense as being limited to such specific examples. Various modifications can be made within the scope of the technical concept of the invention and the claims.

1...game system, N...network, DB...database, 10...game terminal, 11...CPU, 13...RAM, 14...auxiliary storage device, 17...display unit, 30...server, 31...CPU, 33...RAM, 34...auxiliary storage device, 100...data storage unit, 110...control unit, 111...specific area setting unit, 112...moving object movement unit, 113...identification unit, 114...action unit, 115...area movement unit, 116...benefit granting unit, 117...predicted trajectory display unit, TBL101...user information table, DT102...game management data, B...block, BG...block group, PT...predicted trajectory, PC...pitcher character, CC...catcher character, P410...timing gauge

Claims (12)

A game system for providing a game in which a moving object moves within a three-dimensional game space, comprising:
a specific area setting means for setting a specific area in the three-dimensional game space, the specific area being divided into a plurality of three-dimensional small areas;
a moving body moving means for moving the moving body based on a user operation;
A specifying means for specifying the small area existing on a trajectory along which the moving object moves;
A game system including: the specific area setting means sets the specific area as a group of a plurality of the small areas;
2. The game system according to claim 1, wherein the specifying means is capable of successively specifying adjacent small areas existing on the trajectory along which the moving object moves. The game system according to claim 1 , wherein the specific area setting means arranges a plurality of small objects corresponding to a plurality of the small areas. and further comprising an action unit for exerting an action on the small object corresponding to the small area identified by the identification unit.
The game system according to claim 3. The game system according to claim 1 , further comprising area moving means for moving the entire specific area or a part of the plurality of small areas constituting the specific area. The game system according to claim 5, wherein the area moving means complicates the movement of the entire specific area or the movement of a portion of a plurality of small areas constituting the specific area as the game stage progresses each time the moving body is moved a predetermined number of times by the moving body moving means, or as the number of movements of the moving body by the moving body moving means increases. the user operation includes a selection operation of selecting one from a plurality of trajectory options;
The game system according to claim 1 , further comprising a bonus awarding unit that awards a predetermined bonus when the number of times an option selected by the user has been selected for each of the plurality of trajectory options is within a predetermined number of times. the user operation includes a selection operation of selecting one from a plurality of trajectory options;
the option regarding the plurality of trajectories is one of parameters associated with an operation object that moves the moving body,
The game system according to claim 1 , wherein the parameter of the operation target is changed or set in a second game different from the game. 2. The game system according to claim 1, further comprising a predicted trajectory display means for displaying a predicted trajectory for predicting a trajectory of the moving object after the moving object starts to move before the moving object starts to move. the user operation includes a timing operation for designating a movement start timing of the moving object,
10. The game system according to claim 9, wherein the moving object moving means changes a trajectory along which the moving object moves from the predicted trajectory based on the timing of the timing operation. A game control device for providing a game in which a moving object moves within a three-dimensional game space,
a specific area setting means for setting a specific area, the specific area being divided into a plurality of three-dimensional small areas within the three-dimensional game space;
a moving body moving means for moving the moving body based on a user operation;
A specifying means for specifying the small area existing on a trajectory along which the moving object moves;
13. A game control device comprising: A program for causing a computer to function as the game system described in any one of claims 1 to 10 or the game control device described in claim 11.

Images