JP7266982B2 - program - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Law From December 9, 2017 to August 29, 2018, the applicant Colopl Co., Ltd. posted information on the game program on its website, and the inventor Jiro Taoka The outline of the game by the invented game program was released.

Application of Patent Act Article 30, Paragraph 2 From December 14, 2017 to September 12, 2018, the game application "Dragon Project" Ver1.4.09 to Ver1.6.18 will be distributed on the application distribution platform. As a result, the outline of the game by the game program invented by the inventor Jiro Taoka was released.

The present invention relates to programs .

Conventionally, games are known in which a game character operated by a user performs various actions to exert effects on other objects (for example, Non-Patent Document 1).

“Tekken”, [online], [searched on September 5, 2018], Internet <https://iphoneac.com/review/201803/tekken.html>

However, in Non-Patent Literature 1, it is not determined whether or not another action is to be performed by the game character depending on the action of the action performed by the game character on the other object. There was a fear that the quality could not be improved.

The present invention has been devised in view of such circumstances, and its object is to provide a program capable of improving interest .

According to an aspect of an embodiment shown in the present disclosure, a program causes a computer to perform display means for displaying a user-operable character and other objects, input reception for receiving an input operation from a user , and means , and when the character is in the first state, the character performs a first action that exerts a greater effect than a normal action for exerting an effect on another object by receiving an input operation that is in a first mode; The control means causes the character to perform a larger action than the normal action by accepting an input operation that is in a second state different from the first state when the character is in the first state. A character is caused to perform a second action, which is an action that exerts an effect, and is different from the first action , and a predetermined condition is established based on the effect exerted on the other character by the second action, resulting in a second state. Thus, the character performs the same action as the first action without requiring the input operation of the first mode.

According to the present invention , interest can be improved.

It is a figure which shows the hardware constitutions of a game system. It is a block diagram which shows the functional structure of a server. 3 is a block diagram showing a functional configuration of a user terminal; FIG. FIG. 10 is a diagram showing an example of the progress of a game provided by the game system and the transition of the game space; FIG. 10 is a diagram showing an example of a display screen on which an example of a preparation space is drawn; FIG. 10 is a diagram showing an example of a display screen that depicts an example of a battle space; FIG. 11 is a diagram showing an example of a display screen that depicts another example of a battle space; FIG. 11 is a diagram showing an example of a display screen that depicts another example of a battle space; FIG. 10 is a diagram showing an example of a display screen that depicts yet another example of a battle space; FIG. 11 is a diagram showing an example of a display screen that depicts an example of a joint battle space; It is a flow chart which shows an example of attack processing.

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

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

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

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

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

Note that the controller 1020 may have the camera 17 and the ranging sensor 18 instead of or in addition to the user terminal 100 having the camera 17 and the ranging sensor 18 .

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

When the user terminal 100 communicates with a plurality of controllers 1020 , each user can hold each controller 1020 to communicate with the one user terminal 100 without communicating with other devices such as the server 200 via the network 2 . You can play multiplayer with. In addition, by connecting each user terminal 100 to each other for communication according to a wireless standard such as a wireless LAN (Local Area Network) standard (connecting for communication without going through the server 200), a plurality of user terminals 100 can realize local multiplay. You can also When the above-described multiplay is locally realized by one user terminal 100, the user terminal 100 may further include at least a part of various functions of the server 200, which will be described later. Also, in the case where multiple user terminals 100 locally implement the above-described multiplay, the multiple user terminals 100 may be provided with various functions of the server 200, which will be described later, in a distributed manner.

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

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

As shown in FIG. 1 , the user terminal 100 may receive the attachment of an external storage medium 1030 such as a memory card via the input/output IF 14 . This allows the user terminal 100 to read programs and data recorded on the storage medium 1030 . A program recorded in the storage medium 1030 is, for example, a game program.

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

As described above, the user terminal 100 includes the communication IF 13, the input/output IF 14, the touch screen 15, the camera 17, and the ranging sensor 18 as an example of a mechanism for inputting information to the user terminal 100. FIG. Each unit described above as an input mechanism can be regarded as an operation unit configured to receive a user's input operation.

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

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

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

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

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

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

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

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

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

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

The input unit 151 detects the position where the user's operation (mainly physical contact operation such as touch operation, slide operation, swipe operation, flick operation, and tap operation) is input on the input surface, and indicates the position. It has the ability to transmit information as an input signal. The input unit 151 may include a touch sensing unit (not shown). The touch sensing unit may employ any type of system, such as a capacitive system or a resistive film system.

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

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

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

Here, an example in which the user terminal 100 uses the camera 17 and the ranging sensor 18 to detect the object 1010 near the user terminal 100 and accepts the detection result as the user's input operation will be further described. The camera 17 and the ranging sensor 18 may be provided on the side of the housing of the user terminal 100, for example. A ranging sensor 18 may be provided near the camera 17 . As the camera 17, for example, an infrared camera can be used. In this case, the camera 17 may be provided with an illumination device that emits infrared light, a filter that blocks visible light, and the like. This makes it possible to further improve the object detection accuracy based on the image captured by the camera 17, regardless of whether it is outdoors or indoors.

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

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

<Game Overview>
The game system 1 is a system that executes a game that gives a user an event that can be played in the game. Here, granting a playable event means storing a right item representing the right to play the event in the memory in association with the user.

In this embodiment, the game system 1 is a system that executes a game in which an operation character (game character) operated by a user fights an enemy character (another object). Also, in this case, an example in which an example of an event is a joint battle will be described. A joint battle includes fighting a specific enemy character (for example, a boss character) together with another character. Hereinafter, an event in which a user is associated with a right item is also referred to as a joint battle possessed by the user.

The game system 1 is not limited to a specific genre, and may be a system for executing games of all genres. For example, sports-themed games such as tennis, table tennis, dodgeball, baseball, soccer and hockey, puzzle games, quiz games, RPGs, adventure games, shooting games, simulation games, breeding games, and action games. good too.

Also, the game system 1 may be a system for executing games of any play type, not limited to a specific play type. For example, a single-player game played by a single user, a multi-play game played by a plurality of users, and among multi-play games, a competitive game in which a plurality of users compete against each other, and a cooperative play game in which a plurality of users work together. may

<Functional Configuration of Game System 1>
(Functional Configuration of Server 200)
FIG. 2 is a block diagram showing the functional configuration of the server 200. As shown in FIG. The server 200 has a function of providing each user terminal 100 with various data and programs necessary for realizing the game. The server 200 has a function of collecting and managing game-related data from each user terminal 100 . The server 200 has a function of synchronizing a plurality of user terminals 100 .

In this embodiment, the server 200 identifies each user and the user terminal 100 with a pre-registered game account. The account registration method is not particularly limited. For example, the user terminal 100 or another device such as a personal computer may transmit the information necessary for registering the user's account to the server 200 according to the user's operation. Server 200 then creates and stores an account for each user based on the received information.

When the user terminal 100 logs into the network 2 of the game system 1 using one of the accounts, the server 200 recognizes the logged-in user terminal 100 . It should be noted that the login method and the processing related to login are not particularly limited. The server 200 and the user terminal 100 may perform conventionally known login methods and various kinds of processing related to login.

The server 200 functions as a control unit 210 and a storage unit 220 through cooperation of the processor 20, memory 21, storage 22, communication IF 23, input/output IF 24, and the like.

Storage unit 220 stores various data used by control unit 210 . Storage unit 220 stores game program 221 , game information 222 , and user information 223 .

The game program 221 is a program for realizing a game. The game information 222 and user information 223 are data referred to when the game program 221 is executed.

The game program 221 may include, in addition to the game program executed on the server 200 side, a program transmitted to the user terminal 100 and executed on the user terminal 100 side (game program 121 described later). Alternatively, the storage unit 220 may store both the game program 221 executed on the server 200 side and the program executed on the user terminal side.

The game information 222 is common information between accounts. Game information 222 may include, for example, information for defining various game spaces. A “game space” is a space in which an object of a playable character that can be operated by a user is arranged. The game information 222 includes background objects such as trees, rocks, and buildings placed in the game space, as well as non-player character (NPC) objects such as placement positions, sizes, colors, shapes, etc., which are common among accounts. can contain various configuration information about the object of The game information 222 may include setting values for various parameters of non-player characters. Game information 222 may include information related to quests. The game information 222 may include information regarding the probability of winning a lottery held within the game space. A quest is an in-game event for which conditions for achievement are set. An achievement condition may be set for each quest. Note that the quest may have a failure condition in addition to the achievement condition. Further, hereinafter, a character object placed in the game space may be simply referred to as a "character".

The user information 223 is information managed for each game account. The user information 223 includes, for example, information on operable characters (hereinafter referred to as operable characters), information on owned assets, information indicating the progress of the game, and joint battles (events) given in the lottery included in the game. It may include information about the holding status of the right to play, and the like. Examples of owned assets include in-game currency, items, and equipment for characters. A united battle is, for example, an event in which an operating character fights a specific enemy character (for example, a boss character) in a game space.

The control unit 210 controls various processes related to the game by executing the game program 221 stored in the storage unit 220 . Control unit 210 functions as transmission/reception unit 211 , data management unit 213 , and server processing unit 212 by executing game program 221 .

The transmitting/receiving unit 211 transmits/receives various data. For example, the transmitting/receiving unit 211 receives various data and program transmission requests from the user terminal 100 , synchronization requests and synchronization data for supporting the multi-play function, and sends them to the server processing unit 212 . For example, the transmission/reception unit 211 transmits various data and programs to the user terminal 100 according to instructions from the server processing unit 212 .

In the present embodiment, the "multi-play function" is a function for progressing the game in a state in which the progress of the game on multiple accounts is synchronized. The server 200 and the user terminal 100 of the game system 1 perform various processes for supporting the multiplay function when there are multiple accounts logged into the game system 1 .

The server processing unit 212 performs various determination processes related to game progress. The server processing unit 212 performs arithmetic processing necessary for providing the game. The server processing unit 212 executes arithmetic processing described in the game program 221 in response to a request from the user terminal 100 or the like.

For example, the server processing unit 212 instructs the data management unit 213 to add, update, or delete records of the game information 222 or the user information 223 . For example, the server processing unit 212 instructs the transmission/reception unit 211 to transmit various data or programs. For example, when the server processing unit 212 receives a synchronization request and synchronization data for supporting the multiplay function from the user terminal 100 via the transmitting/receiving unit 211, the server processing unit 212 sends the synchronization processing unit 214 a synchronization request for supporting the multiplay function. Instruct to process.

The data management unit 213 manages various data stored in the storage unit 220 according to instructions from the server processing unit 212 . For example, the data management unit 213 adds, updates, or deletes records of the game information 222 or the user information 223 according to instructions from the server processing unit 212 .

For example, the data management unit 213 reads at least one of the game information 222 and the user information 223 from the storage unit 220 according to an instruction from the server processing unit 212 and transmits it to the user terminal 100 via the transmission/reception unit 211 .

For example, the data management unit 213 reads from the storage unit 220 a program to be executed on the user terminal 100 side among the game programs 221 according to an instruction from the server processing unit 212 , and transmits the program to the user terminal 100 via the transmission/reception unit 211 . do.

The synchronization processing unit 214 performs synchronization processing for supporting the multi-play function of the game according to instructions from the server processing unit 212 . The synchronization processing unit 214 performs synchronization between user terminals by transmitting some information received from the user terminal 100 corresponding to each account to other user terminals 100 . When transmitting some information from the server 200 to a plurality of user terminals 100, the synchronization processing unit 214 transmits the information to each user terminal 100 in synchronization. Note that the synchronization processing unit 214 may receive synchronization timing, information to be synchronized, and the like from the server processing unit 212 . Thereby, for example, an in-game effect caused by an input operation performed on a certain user terminal 100 is synchronized and displayed on other user terminals 100 .

(Functional Configuration of User Terminal 100)
FIG. 3 is a block diagram showing the functional configuration of the user terminal 100. As shown in FIG. The user terminal 100 has a function as an input device that receives user input operations and a function as an output device that outputs game images and sounds. The user terminal 100 functions as a control unit 110 and a storage unit 120 through cooperation of the processor 10, memory 11, storage 12, communication IF 13, input/output IF 14, and the like.

Storage unit 120 stores game program 121 , game information 122 , and user information 123 . The game program 121 is a game program executed on the user terminal 100 side. The game information 122 is data referred to when the control unit 110 executes the game program 121 and includes information similar to the game information 222 of the server 200 . The user information 123 is data relating to the account of the user of the user terminal 100 and includes information similar to the user information 223 of the server 200 .

The control unit 110 comprehensively controls the user terminal 100 by executing the game program 121 stored in the storage unit 120 . For example, the control unit 110 defines the game space by referring to information for defining the game space stored in the game information 122 . The control unit 110 transmits and receives various data. For example, the control unit 110 receives from the server 200 various data, programs, data for synchronization for supporting the multi-play function, and the like. For example, the control unit 110 transmits to the server 200 a part or all of the game information 122 or the user information 123, or a synchronization request for supporting the multiplay function.

Control unit 110 controls game progress processing unit 111, input operation reception unit 112, camera arrangement control unit 113, display control unit 114, object control unit 115, lottery control unit 116, and point management unit 116 according to the description of game program 121. 117.

The input operation reception unit 112 detects and receives a user's input operation on the input unit 151 . The input operation reception unit 112 determines what kind of input operation has been performed from the user's action on the console via the touch screen 15 and other input/output IF 14, and sends the result to each element of the control unit 110. Output.

For example, when an input operation is performed on the input unit 151, the input operation reception unit 112 detects the coordinates of the input position and the type of operation. For example, the input operation reception unit 112 detects touch operations, slide operations, swipe operations, flick operations, tap operations, and the like. The input operation reception unit 112 detects that the contact input from the touch screen 15 is canceled when the continuously detected input is interrupted.

The game progress processing unit 111 performs various processes related to the progress of the game. For example, the game progress processing unit 111 interprets the contents of the user's instruction indicated by the coordinates of the input position of the input operation received by the input operation receiving unit 112 and the type of operation. For example, the game progress processing unit 111 adds, updates, or deletes the game information 122 or the user information 123 . For example, the game progress processing unit 111 performs various determination processes related to the progress of the game.

Also, the game progress processing unit 111 progresses the game by performing the following processes. The following processing is (a) a process of granting a joint battle to the user when a predetermined condition is satisfied, and (b) a first reward or a second reward to the user according to the completion of the given joint battle (c) a process of generating or beneficially changing an object that can be used in a joint battle based on the given first reward or second reward; (b) The process of imparting joint combat is executed using the lottery control unit 116, the details of which will be described later. Here, (b) the process of giving the first reward or the second reward, and (c) the process of generating or advantageously changing the object will be described in sequence.

The game progress processing unit 111 gives the first reward to the user when the first condition set for the joint battle is satisfied. The given first reward is stored in the storage unit 120 in association with the user. The first condition is a condition based on the joint combat play, and is, for example, success in defeating the enemy character through the joint combat play.

Also, the game progress processing unit 111 gives a second reward to the user when the second condition set for the joint battle is satisfied. The given second reward is stored in the storage unit 120 in association with the user. The second condition is a condition based on an operation that does not depend on joint combat play.

The second condition includes, for example, that an operation is performed to select the joint battle as a target for obtaining a second reward. In addition, the second condition includes, for example, the lapse of a predetermined time for a joint battle selected as a target for obtaining the second reward among the joint battles possessed by the user. In addition, the second condition includes, for example, that the joint battle selected as a target for obtaining the second reward satisfies a condition based on the play of another joint battle.

Specifically, the second condition is that the defeat points accumulated for the event selected as the target for obtaining the second reward reach a threshold. Hereinafter, selecting an object for obtaining the second reward is also referred to as "registering as an accumulation object for subjugation points". Also, the threshold to be reached by the subjugation points is also described as the required subjugation points. The required subjugation points are set according to the registered joint battle. Subjugation points are given for the registered joint battle, and the given subjugation points are accumulated by being added to the subjugation points already given to the joint battle. For example, subjugation points are granted over time. Also, for example, subjugation points are given based on the play of other cooperative battles. Processing related to subjugation points is executed by the point management unit 117, which will be described later. When the game progress processing unit 111 is notified by the point management unit 117 that the subjugation points have reached the threshold value, the game progress processing unit 111 executes a process of giving a second reward.

Also, the first reward has a higher value than the second reward in favorably advancing the game. Here, high value may include more types of rewards. High value may also include a greater number of rewards. In addition, when there are types of rewards for which rarity is set, high value may include rewards with a higher rarity. For example, part of the first reward may be the second reward. Alternatively, the first reward may include the first item and another type of item, and the second reward may include only the first item. In addition, both the first reward and the second reward include the first item and other types of items. It may be set higher.

Note that the first reward and the second reward definitely include the first item for the user to whom the joint battle has been granted. Also, the first reward may stochastically include the first item for other users operating other characters who have participated in the joint battle.

In other words, the user can obtain some kind of reward whether or not he or she plays the joint battle, but playing the game can obtain a reward of higher value. As a result, the user can enjoy playing the joint battles of interest without obtaining rewards for all the joint battles that the user possesses by using only non-playing techniques.

Here, the first item may be an item for generating an object that can be used in joint battle. In this embodiment, the first item is an essential item for generating such an object, and can be combined with other items to generate an object. Henceforth, the 1st item is also described as an essential material item. Other items are also simply referred to as material items. Objects that can be used in joint combat may be, for example, weapons, armor, and the like that can be equipped on the operating character. Hereinafter, objects that can be used in joint combat are also referred to as equipment items. The game progress processing unit 111 combines essential material items with other material items to generate equipment items.

Also, the game progress processing unit 111 advantageously changes the equipment item based on the essential material item. Advantageously changing the equipment item is hereinafter also referred to as enhancing the equipment item. A required material item that can be used to enhance an equipment item is not the required material item used to generate the equipment item, but another required material item that has been granted to the user and has not yet been used. . For example, the game progress processing unit 111 may convert essential material items into consumable items for enhancing equipment items, and enhance the equipment items using a predetermined amount of the converted consumable items. Also, the predetermined amount of consumable items required for enhancement may be determined according to the equipment item.

For example, a first reward given when a first condition is satisfied for a joint battle includes essential material items having values corresponding to the rarity of the joint battle. The game progress processing unit 111 generates an equipment item with a higher value as the value of the essential material item is higher. The higher the value of the equipment item, the greater the predetermined amount of consumable items required to enhance it.

In addition, the higher the value of the essential material item, the more valuable the consumable item may be for enhancing the equipment item. For example, it is assumed that an essential material item with a higher value can be converted into a consumable item H, and an essential material item with a lower value can be converted into a consumable item L. In this case, if 20 consumable items L are required to enhance a certain equipment item, 5 consumable items H may be required to enhance the same equipment item.

Also, a rarity level is set for the joint battle given to the user. The rarity level will be detailed later. The second condition is set according to the rarity of joint combat. For example, the higher the rarity of joint combat, the higher the difficulty of the second condition may be set. A higher degree of difficulty of the second condition may be, for example, a higher required subjugation point.

Also, the game progress processing unit 111 completes the joint battle when the first condition or the second condition is satisfied. That is, when the enemy character is successfully subjugated in the joint battle, or when the subjugation points for the joint battle reach the threshold value, the joint battle is completed. Henceforth, the completion of joint combat may also be referred to as the completion of subjugation.

In other words, the user can complete the subjugation regardless of whether the user plays the joint battle or not, but playing the game can obtain a reward of higher value. As a result, users are encouraged to enjoy completing subjugation by playing the joint battle they are interested in, instead of using only the method of completing subjugation without playing for all of the joint battles they possess. can be done. In addition, it is possible to prompt the user to complete the cooperative battle, in which it is difficult to satisfy the first condition through play, without playing. As a result, the user can obtain at least the necessary material items even in a joint battle in which it is difficult to satisfy the first condition through play, and use the necessary material items to generate or enhance equipment items. , you can play the next joint battle.

Further, when the subjugation is completed, the game progress processing unit 111 cancels the association between the right item for playing the joint battle and the user in the storage unit 120 . Resolving may be, for example, deleting information representing the rights item associated with the user from the storage unit 120 . In other words, the joint battle can be played again if the subjugation is not completed, and is no longer playable once the subjugation is completed.

As a result, it is possible to reduce the increase in the number of joint battles owned by the user, and reduce the user's burden due to many joint battles.

Further, after the second condition is satisfied, the game progress processing unit 111 causes the storage unit 120 to store the second reward in association with the user in accordance with the user's operation instructing receipt of the second reward. good too. In that case, if the user operation is accepted within a predetermined period of time after the second condition is satisfied, the game progress processing unit 111 associates an additional reward in addition to the second reward with the user. may be stored in memory. Additional remuneration corresponds to an example of the third remuneration in the present application. As a result, it is possible to prevent or deter the user from neglecting a cooperative battle in which subjugation is completed by a method that does not depend on the play.

The camera placement control unit 113 defines a virtual camera for designating an area to be presented to the user in the game space. The camera placement control unit 113 virtually places the virtual camera in the game space by defining the position and orientation of the virtual camera in the game space. Furthermore, the camera placement control unit 113 instructs the display control unit 114 to create an image in which the viewing area defined by the virtual camera and the objects placed in the viewing area are drawn.

Note that the camera placement control unit 113 may appropriately determine the position and orientation of the virtual camera for each game space. For example, based on the position and orientation of a specific object, the camera placement control unit 113 moves the virtual camera from the object at a certain direction, distance, and angle so that the object is captured in the center of the field of view with a specific orientation. may be placed. The specific object may be, for example, an object of a character operated by the user terminal 100, a dynamic object representing another character such as a non-player character, or a building, tree, stone, or the like. It can be a static object. Here, the dynamic objects in the game space include characters (for example, non-player characters, enemy characters, etc.) that act based on the game programs 121 and 221 and playable characters that act based on the user's operation. .

The display control unit 114 causes the display unit 152 to display an image. For example, the display control unit 114 generates an image in which an area of the field of view of the virtual camera defined by the camera arrangement control unit 113 and objects existing in the area are drawn in the game space, and causes the display unit 152 to display the image. . Further, the display control unit 114 may superimpose and draw objects related to UI (user interface) necessary for various operations of the game, such as icons, buttons, and menus showing various parameters, on such an image. .

The object control unit 115 arranges objects in the game space based on the object setting information included in the game information 122 . The object control unit 115 controls objects placed in the game space. For example, the object control unit 115 changes the position, orientation, shape, color, etc. of the object in the game space, or causes the object to perform a series of predetermined actions.

The lottery control unit 116 determines a united battle with a degree of difficulty corresponding to the abilities of the operating characters participating in the lottery from among a plurality of united battles stored in the game information 122 . Here, the difficulty level is an index that indicates the degree of difficulty in winning a battle with a boss character included in a joint battle. The difficulty level can be set based on, for example, the level of boss characters, the number of boss characters to be defeated, and the like. A winning probability is set for each united battle determined by the lottery control unit 116 . This winning probability is included in the game information 122, for example. The lottery control unit 116 determines one or a plurality of united battles based on this winning probability. The joint battle determined by the lottery control unit 116 is registered in the user information 123 by the game progress processing unit 111 in association with this operation character.

The point management unit 117 manages subjugation points accumulated for joint combat. For example, the process of managing subjugation points includes a process of registering a co-op battle selected by the user from among the co-op battles for which the user is given the right to play as an object for accumulation of subjugation points. Also, the process of managing subjugation points includes a process of imparting subjugation points when conditions for granting subjugation points are satisfied for joint battles registered as targets for accumulation of subjugation points. Also, the process of managing subjugation points includes a process of determining whether or not the cumulative value of subjugation points granted to a joint battle registered as an accumulation target for subjugation points has reached a threshold.

Here, the higher the rarity of the cooperative battle, the larger the required subjugation points are set, so it takes a long time to complete the subjugation by accumulating the subjugation points, or the play of many other joint battles is required. As a result, it is possible to encourage the user to enjoy playing in the joint battle space rather than registering the highly rare joint battle as an object for accumulating subjugation points. In addition, the user can be encouraged to register a low-rarity cooperative battle as an accumulation target for subjugation points rather than playing it.

On the other hand, it is assumed that the difficulty level of the first condition is set higher for a joint battle with a higher rarity level. That is, the higher the rarity of the joint battle, the more difficult it is to subdue the enemy character through play. In this case, the user can complete the subjugation and obtain the second reward by registering the cooperative battle in which it is difficult to subdue the enemy character through play as an accumulation target for subjugation points. As a result, the user can generate and strengthen equipment items using the essential material items obtained from the second reward relating to the joint battle with high rarity, and play the next joint battle.

Note that the game system 1 may be configured such that the server 200 has at least some of the functions that the user terminal 100 has. The game system 1 may be configured such that the user terminal 100 has at least some of the functions that the server 200 has. Furthermore, devices other than the user terminal 100 and the server 200 may be used as components of the game system 1 , and the hardware may be caused to perform part of the processing in the game system 1 . That is, the computer that executes the game programs 121 and 221 in this embodiment may be any of the user terminal 100, the server 200, and other devices.

(Game progress and game space transition)
FIG. 4 is a diagram showing an example of the progress of the game provided by the game system 1 and the transition of the game space.

The control unit 110 transitions the game space according to the progress of the game. In the following, a case where a plurality of game spaces such as a preparation space, a battle space, and a united battle space are defined will be described as an example. FIG. 4 shows a transition t1 from the preparation space to the battle space, a transition t2 from the battle space to the joint battle space, a transition t3 from the preparation space to the joint battle space, and a transition t4 from the joint battle space to the preparation space. It is

The preparation space is a game space in which enemy characters do not appear. The preparation space is a game space for making the user prepare for the quest. While the control unit 110 is progressing the game in the preparation space, when the user performs an input operation indicating a quest start instruction, the control unit 110 transitions the game space from the preparation space to the battle space (transition t1).

The preparation space is also a game space for receiving an operation for obtaining the right to play a joint battle with the operating character. While the control unit 110 is progressing the game in the preparation space, if the input operation reception unit 112 receives an input operation of the user requesting participation in the lottery, the control unit 110 extracts another You may make a transition to the lottery space which is the game space of .

The control unit 110 may cause the player to receive a reward that is given when, for example, the player successfully clears the quest and the joint battle game in the preparation space. When the input operation receiving unit 112 receives a predetermined input operation such as a map moving operation in the preparation space, the control unit 110 may transition the game space to the battle space without starting the quest. When the user issues an instruction to start a joint battle, the control unit 110 may transition the game space from the preparation space to the joint battle space (transition t3).

A battle space is a game space in which an operating character and an enemy character encounter and fight. The battle between the operating character and the enemy character will be detailed later.

When the server 200 receives information from the user terminal 100 or through the synchronization processing unit 214 and determines that a predetermined condition is satisfied, the user terminal 100 satisfying this condition is transferred from the battle space to a joint battle. Instruct to transition to space. Upon receiving this instruction, the control unit 110 of each user terminal 100 transitions the game space from the battle space to the joint battle space (transition t2). A predetermined condition for transitioning from the battle space to the joint battle space may be, for example, that a specific enemy character (eg, boss character) appearance condition is satisfied.

The joint battle space is a battle space where battles corresponding to the multiplayer function are performed. A joint battle space is a game space in which one or more operation characters and non-player characters fight against specific enemy characters (eg, boss characters). Hereinafter, one or more operating characters and non-player characters placed as objects in the same joint battle space will be collectively referred to as "ally characters". When a friendly character is defeated or won in a joint battle in the joint battle space, the battle ends. When the joint battle in the joint battle space ends, the game space is transitioned from the joint battle space to the preparation space (transition t4). When a joint battle with a specific enemy character is won, each user who participates in the joint battle can obtain a specific reward. This specific reward includes at least one of equipment items to be equipped by the operating character, material items for acquiring the equipment items, and enhancement items for enhancing the equipment items. A specific reward is given, for example, to each operating character that participates in a joint battle in the preparation space.

The object control unit 115 arranges the operating character and at least one boss character in the joint battle space. The number of ally characters fighting a specific enemy character may be a predetermined number. In the following, the case where the number of allied characters is four will be described as an example, but this is just an example, and the number may be set arbitrarily, such as two, three, nine, or eleven.

In this embodiment, the object control unit 115 arranges non-player characters so that there are four allied characters in total when the number of operating characters is less than four when transitioning to the joint battle space. That is, if the number of user-operated characters participating in the joint battle in the joint battle space is less than a predetermined number (for example, four), the object control unit 115 replaces the shortage with non-player characters that operate based on the game program. make up with

The joint battle space may be the same game space as the battle space. In other words, instead of transitioning the game space from the battle space to the united battle space, the control unit 110 changes the camera work and UI display of the virtual camera in the battle space to the camera work and UI display as the united battle space. By changing it, a joint battle space may be realized.

When the game progress processing unit 111 determines that the ally character has succeeded in defeating the boss character, the control unit 110 transitions the game space from the joint battle space to the battle space or the preparation space. Note that the control unit 110 may transition the game space to the battle space or the preparation space after a certain period of time has passed since the game progress processing unit 111 determined that the boss character was successfully subjugated. The control unit 110 may change the game space from the joint battle space to the preparation space or the battle space when a predetermined movement operation such as map movement is received while the game is progressing in the joint battle space.

In this embodiment, each user terminal 100 cooperates with the server 200 to perform game processing for supporting the multi-play function. In the game space defined by the control unit 110 of the user terminal 100, an operating character corresponding to an account logged in from the user terminal 100 and an operating character corresponding to an account logged in from another user terminal 100 can be arranged. In the following, several processing examples regarding game space transitions will be specifically described with reference to FIGS. 1 to 3. FIG.

The object control unit 115 arranges various objects including playable characters in the game space defined by the control unit 110 . When an input operation is performed by the user, the object control unit 115 moves the operation character at any time according to the input operation. Thereby, the control unit 110 can allow the user to search the game space through the operation character.

When the server 200 transmits to each user terminal 100 an instruction to transition the game space to a joint battle space, the server 200 puts together one or more operation characters and non-player characters into a group that fights against enemy characters based on predetermined conditions. good too. For example, the server 200 may group four playable characters in descending order of level into a group that fights against enemy characters. The server 200 may assign an identification number (identification number) to each group. The synchronization processing unit 214 transmits an instruction to each user terminal 100 used to operate the playable characters so that all the playable characters included in the group transition to the same united battle space.

The server processing unit 212 determines whether or not a predetermined condition for transitioning from the battle space to the joint battle space is satisfied. For example, the server processing unit 212 may determine whether or not a predetermined condition is satisfied in the battle space based on information related to synchronization from the user terminal 100 . Here, the information related to synchronization includes an identifier that uniquely indicates the battle space in which the playable character is placed, the position of the playable character in the battle space, and the control unit 110 of the user terminal 100 that transitions the game space to the battle space. Elapsed time since

The game progress processing unit 111 of the user terminal 100 may determine whether or not a predetermined condition is satisfied in the battle space. In this case, control unit 110 transmits information indicating the determination result to server 200 .

The synchronization processing unit 214 may limit the maximum number of user terminals 100 that transition to the same united battle space, that is, the maximum number of ally characters in the united battle space. Information indicating the maximum number is included in at least one of the game information 122 and 222 .

The object control unit 115 refers to the instruction from the server 200 and the game information 122, and arranges the operation characters in the joint battle space according to the maximum number of allied characters. If the number of allied characters is less than the maximum number when transitioning to the joint battle space, the object control unit 115 may arrange non-player characters in the number that is short of the maximum number.

(Battle between an operating character and an enemy character)
Combat in battle space and joint battle space will be described in detail. In the "battle" in the game according to the present embodiment, the characters operated by the user and other users and the enemy characters perform attack motions on each other. Since various processing and displays related to battle are common to the battle with the enemy character in the battle space and the battle with the boss character in the joint battle space, the battle with the enemy character will be described below.

Values of various parameters (for example, attack power, defense power, etc.) including at least physical strength are set for the operating character and the enemy character. The user information 123 includes the parameter setting values of the playable character, and the game information 122 includes the parameter setting values of the enemy character.

In the battle space, the object control unit 115 causes the control character corresponding to the account of the user terminal 100 used by the user to perform an attack motion according to the input operation received by the input operation receiving unit 112 . Then, the game progress processing unit 111 determines whether or not the attack of the character operated by the user hits any enemy character, that is, whether or not the attack was successful. Furthermore, when determining that the attack of the character operated by the user is successful, the game progress processing unit 111 calculates the damage value to be given to the enemy character targeted for the attack. Furthermore, the game progress processing unit 111 subtracts the calculated damage value from the physical strength value of the enemy character. Alternatively, the game progress processing unit 111 compares the total damage to the enemy character, including the calculated damage value, with the physical strength value of the enemy character.

When the physical strength value of the enemy character becomes 0 or less, or when the total damage to the enemy character becomes equal to or greater than the physical strength value of the enemy character, the game progress processing section 111 determines that the enemy character has been defeated.

In the battle space, the object control unit 115 causes the enemy character to perform an attack motion. The game progress processing unit 111 determines the success or failure of the attack action by the enemy character in the same manner as the attack action of the playable character, and also calculates the damage value when the attack against the playable character is successful.

When the physical strength value of the operating character becomes 0 or less, or the total damage to the operational character becomes equal to or greater than the physical strength value of the operating character, the game progress processing section 111 determines that the operational character is unable to fight. In this case, even if the input operation receiving unit 112 receives an input operation related to the playable character, the object control unit 115 does not allow the playable character to perform an action corresponding to the input operation.

(Specific example of preparation space)
FIG. 5 shows an example of a display screen on which the prepared space is drawn. State (A) of FIG. 5 shows an example of the display screen of the preparation space. State (B) of FIG. 5 shows an example of a display screen when a window W1 including a list L1 of quests is displayed in the preparation space. The state (C) of FIG. 5 includes a list L2 of prepared joint combat.

In the state (A) of FIG. 5, in addition to the background of the preparation space, the user's playable character x and the other user's playable characters y1 and y2 are displayed. In state (A) of FIG. 5, a non-player character z1 and a non-player character z2 that operate based on the game programs 121 and 221 are displayed. The non-player character z1 and the non-player character z2 each receive a predetermined input operation for starting the transition t1 from the preparation space to the battle space and the transition t3 from the preparation space to the joint battle space. In the example shown in FIG. 5A, an object z3 is provided to indicate the entrance to the lottery space. The object z3 receives a predetermined input operation for starting transition from the preparation space to the lottery space.

The object control unit 115 arranges the operation character x corresponding to the account logged in on the user terminal 100 in the preparation space. The object control unit 115 arranges the operation characters y1 and y2 of the other user terminals 100 in the preparation space. Furthermore, the object control unit 115 has placed a non-player character z1, a non-player character z2, and an object z3 in the preparation space. The non-player characters z1 and z2 are objects for receiving input operations instructing the selection and start of quests and the selection and start of joint battles. The object z3 is an object that receives an input operation for making the operating character participate in a lottery for obtaining the right to play joint combat.

The camera placement control unit 113 determines the position and orientation of the virtual camera in the preparation space based on the position and orientation of the playable character x. For example, the camera placement control unit 113 arranges the virtual camera in such a position and orientation that the playable character x is captured slightly below the center of the field of view and that the playable character x is obliquely seen from behind (rear) above. When the user performs an operation to change the position or orientation of the playable character x, the object control unit 115 arranges the playable character x at the changed position and orientation. Also, the camera placement control unit 113 changes the position and direction of the virtual camera to the position and direction corresponding to the changed position of the playable character x. Then, the display control unit 114 draws the preparation space and the operation character x within the visual field area of the virtual camera arranged at the changed position with the changed orientation. The same applies to the positions and orientations of the playable characters y1 and y2 that are operated by other users.

In the state (A) of FIG. 5, the menu M1 is displayed. The menu M1 displays the current level "Lv.40" and physical strength V1 of the user's operating character x. In addition, in state (A) of FIG. 5, buttons B1 and B2, which are UIs for user's input operations, are displayed.

In this way, the display control unit 114 may create an image in which the UI for the user's input operation is superimposed on the image in which the preparation space and objects in the preparation space are drawn. For example, the display control unit 114 may create an image in which the images of the buttons B1 and B2 are superimposed on the prepared space and the images of the various objects described above, as shown in FIG. The button B1 is a button for accepting a user's instruction to set a game or display a notification, and the button B2 is a button for accepting a user's map movement, equipment change, or the like.

When the user terminal 100 selects the non-player character z1, the game progress processing unit 111 instructs the display control unit 114 to draw a window W1 including a list L1 of user-selectable quests. The quests included in the list L1 are quests for which the user has the right to play. The display control unit 114 creates an image in which the window W1 is superimposed on the images of the preparation space and the object, as shown in state (B) of FIG. 5, and causes the display unit 152 to display the image. In the example shown in the state (B) of FIG. 5, the list L1 of the window W1 contains three quests. Then, for each quest, the quest name (such as "Subjugation of Monster AA"), achievement conditions (such as "Monster AA: 0/3"), map name (such as "Grassland 1"), and reward ("Reward: Copperplate ”, etc.) are described. Note that the display of the contents of each quest in the list L1 is an example, and is not limited to the description in the figure.

Here, the achievement condition "monster AA: 0/3" indicates that the number of monsters AA to be defeated is three. Note that the content of the quest achievement condition is not particularly limited. For example, the quest achievement condition may be to defeat a specific number of specific enemy characters, to collect a specific number of items obtained by defeating a specific enemy character, or the like.

The map name indicates the name of the battle space or joint battle space that transitions when the quest is selected. A reward indicates an article, function, information, or the like, which is given to the user's operating character or account by completing a quest, and enables the game to proceed more advantageously. For example, the reward may be in-game currency, items, equipment that improves the abilities of the playable character, skills of the playable character, and the like.

When the user terminal 100 selects the non-player character z2, the game progress processing unit 111 instructs the display control unit 114 to display on the display unit 152 a window containing a list L2 of joint battles that can be played by the user. The joint battles included in the list L2 are registered in the game information 122 as the joint battles determined by the lottery control unit 116 in association with the operating character x. In other words, the joint battles included in the list L2 are the joint battles in which the user who operates the operation character x is given the right to play. In the example shown in the state (C) of FIG. 5, the list L2 includes four quests of joint combat J1 to J4. For each joint battle, the name of the boss character K1 (such as "monster K1"), the level of the boss character (such as "Lv.50"), and the difficulty of the joint battle (such as "difficulty: m1") are described. ing. It should be noted that the display of the content of each joint battle in the list L2 is an example, and is not limited to the description in the figure.

Here, joint battles J1 to J4 are joint battles in which the operating character participates in a lottery and wins the lottery. This joint battle includes a battle with a specific boss character. The lottery control unit 116 determines a joint battle including a battle with a boss character whose level corresponds to the current level of the operating character x who participates in the lottery. The boss character's level may be, for example, a level within a predetermined range including the current level of the playable character x. The predetermined range may be, for example, the range of "current level value of playable character x"±"predetermined value". In the example shown in FIG. 5C, the lottery control unit 116 selects level Lv. For 40 operation characters x, level Lv. Joint battles including battles with boss characters of levels within the range of 30-50 are determined.

Each boss character that fights in a joint battle has a winning probability that is drawn in a lottery. In other words, there are boss characters with a high probability of winning and those with a low probability of winning. In the example shown in the state (C) of FIG. 5, in addition to the information about the boss characters to be fought in each united battle, an indication R indicating the probability of winning in the lottery is displayed. The display R displays information indicating the winning probability. As the information indicating the winning probability in stages, expressions such as D, C, B, A, S, SS, etc. may be used in descending order.

In the example shown in state (C) of FIG. 5, joint combat J3 is level Lv. 44 boss character K3, and joint battle J4 is level Lv. This is a joint battle including battles with 16 boss characters K3. Joint combat J4 is Lv. It was drawn in the lottery that I participated in when I was 18, and the joint battle J3 is Lv. I got it from a lottery I participated in when I was 40.

(Specific example of battle space)
FIG. 6 shows an example of a display screen that depicts a battle space. State (A) of FIG. 6 shows the display screen when the display unit 152 is oriented vertically, and state (B) of FIG. 6 shows the display screen when the display unit 152 is oriented horizontally. A display screen when the display unit 152 is oriented vertically is called a vertical screen, and a display screen when the display unit 152 is oriented horizontally is called a horizontal screen.

In the example shown in FIG. 6, a menu M2 is displayed in addition to the battle space. The menu M2 displays the current level "Lv.40", total physical strength "327", and physical strength V1 of the user's operating character x.

The camera placement control unit 113 determines the position and orientation of the virtual camera in the battle space based on the position and orientation of the playable character x, as in the preparation space. However, the camera placement control unit 113 defines a virtual camera having different visual field areas for the vertical screen and the horizontal screen. For example, the camera placement control unit 113 may make the field-of-view area of the virtual camera on the vertical screen longer than the field-of-view area of the virtual camera on the horizontal screen. When an operational character corresponding to another account is placed in a battle space with the same map name as the own terminal, or later placed in a battle space with the same map name, the object control unit 115 allows the other account to be placed in the battle space. The operation character y3 corresponding to is synchronously arranged.

The object control unit 115 arranges one or more enemy characters e1 with which the user's and other user's characters can fight in the battle space. The display control unit 114 may display a target marker t1 indicating which enemy character the operating character is attacking, superimposed on the enemy character. Then, when the character operated by the user subjugates the enemy character, the game progress processing unit 111 may cause the account corresponding to the operated character to acquire some kind of reward.

Note that the battle space may be composed of a plurality of game spaces. When the battle space consists of a plurality of game spaces, the display control unit 114 may display an object icon C2 or the like for accepting a user's instruction to move to another battle space.

When the input operation receiving unit 112 receives a predetermined operation while the game is progressing in the battle space, the display control unit 114 causes the predetermined operation to be input to the position on the touch screen 15 where the predetermined operation was input. display an object indicating that The predetermined operation includes a drag operation for moving the playable character x (hereinafter referred to as a "moving operation") and a tap operation for causing the playable character x to perform an attack motion (hereinafter referred to as an "attack operation"). ), a flick operation for avoiding an attack from an enemy character (hereinafter referred to as “avoidance operation”), and the like. The input operation reception unit 112 can receive a movement operation, an attack operation, or a flick operation at any position on the touch screen 15 . Accordingly, it is possible to avoid obstruction of the visual recognition of the operation character x and the enemy character by an indicator such as the user's finger.

The display control unit 114 may cause the touch screen 15 to display an object indicating the direction of the movement operation when the input operation reception unit 112 receives the movement operation. In the state (A) of FIG. 6, the display control unit 114 displays the elastic object w1 centered on the position p1. A position p1 is a position at which the input operation reception unit 112 has received a touch-on operation. A touch-on operation is an operation of bringing an indicator into contact with or close to the touch screen 15 . The indicator may be a user's finger or the like, or may be a stylus pen or the like.

Here, when the user performs a movement operation to move the pointer from position p1 to position p2, input operation reception unit 112 detects that the pointer has moved from position p1 to position p2. Based on this detection result, the display control unit 114 causes the touch screen 15 to display an elastic object w2 deformed to extend the elastic object w1 to the position p2. This allows the user to recognize the direction of the movement operation detected by the touch screen 15 .

When the input operation receiving unit 112 receives the input of the drag operation, the object control unit 115 moves the operation character x in the dragged direction according to the drag time or distance. When the input operation reception unit 112 receives a tap operation, the object control unit 115 causes the operation character x to perform an attack motion. Then, the game progress processing unit 111 determines the success or failure of the attack of the playable character x and calculates the damage value.

In the example shown in FIG. 6, buttons B1, B2, B3, B4, B5, and B6, which are UIs for user's input operations, are displayed.

In this manner, the display control unit 114 may draw a UI for user's input operation superimposed on the image depicting the battle space and the objects in the battle space described above. The button B3 is a special attack button for instructing the special attack of the operating character x. The button B4 is a "recovery button" for instructing recovery of the physical strength of the operating character x. The button B5 is a "chat button" for chatting between accounts corresponding to operation characters arranged in the same battle space. The button B6 is a "weapon switching button" for switching the weapon equipped by the operating character x.

The display control unit 114 may display a message according to the action of the operation character x according to the user's operation (not shown). For example, the display control unit 114 may display a message to notify the user when the playable character x moves from the preparation space to the battle space or when the playable character x obtains an item.

Note that the display control unit 114 can draw various display items (buttons, menus, and messages) related to the UI described above at fixed positions on the display screen of the display unit 152 regardless of the position and orientation of the virtual camera. desirable. The display control unit 114 desirably draws various display items related to the UI on the periphery of the display screen of the display unit 152 so as not to interfere with the input of instructions such as movement, attack, and recovery of the playable character. The display control unit 114 desirably changes the drawing positions of the various display objects related to the UI between the vertical screen and the horizontal screen.

In this embodiment, a one-handed sword, a two-handed sword, a spear, a twin sword, and a bow and arrow are prepared as weapons that the operating character x can possess. Also, each weapon is set to one of a plurality of predetermined types. A certain two-handed sword has a specific type of two-handed sword (hereinafter referred to as a specific two-handed sword) having an ax-shaped tip. 7 to 9 show other examples of display screens that depict the battle space. In this example, the playable character x possesses a specific two-handed sword bb1 and fights an enemy character e1.

In a battle scene between an operational character x holding a specific two-handed sword bb1 and an enemy character e1, the user performs a tap operation and a long tap operation on the display screen to perform a normal attack and a combination of the normal attack, for example. , a dive attack that is one of the special attacks, and a spin attack that is another one of the special attacks. Of these, the operating character x is invincible (a state in which it is not damaged by enemy attacks, etc.) for a predetermined period after the dive attack or the spinning attack is activated.

Note that the tap operation is a touch operation whose touch time is less than a predetermined time T1 (eg, 0.2 seconds), and the long tap operation is a touch time of a predetermined time T2 (eg, 0.2 seconds). This is the tap operation described above.

In the combo attack, the operating character x performs, for example, a horizontal slash as a first-stage normal attack, and performs, for example, a diagonal slash as a second-stage normal attack when the horizontal slash hits the enemy character e1. In the dive attack, the operating character x jumps and swings down the specific two-handed sword bb1 in the air. In the spinning attack, the operating character x rotates itself and swings the specific two-handed sword bb1 along with the rotation.

Note that FIG. 8 shows a state (a scene of a dive attack) immediately before the jumped operation character x swings down the specific two-handed sword bb1 against the enemy character e1. FIG. 9 shows an operation character x swinging a specific two-handed sword bb1 near an enemy character e1 (a scene of a spinning attack).

When the attack of the operating character x hits the enemy character e1, that is, when the action of the operating character x affects the enemy character e1, the enemy character e1 receives damage. The magnitude of damage increases, for example, in the order of normal attack, spin attack, and dive attack.

The number of taps is set to 0 at the beginning of the battle with the enemy character e1. When the user performs a tap operation, the number of taps is updated, and a normal attack corresponding to the updated number of taps is performed by the operating character x. As long as the normal attack continues to hit the enemy character e1, the number of taps is updated in the order of 1, 2, 1, 2, . . . according to the tap operation. As a result, the playable character x alternately performs horizontal slashing and diagonal slashing.

If the normal attack ends in failure, ie, if the action of the operating character x does not reach the enemy character e1, the tap number is reset to zero.

When the user performs a long-tap operation (a long-tap operation is detected) in a state where the number of taps indicates 2, that is, after the second normal attack hits the enemy character e1, the operated character x A dive attack is performed. Further, a long-tap operation is performed with the number of taps indicating 0 or 1, and when the long-tap operation is canceled, the operation character x performs a spinning attack.

As long as the spinning attack hits the enemy character e1, the spinning attack is repeatedly executed by the operating character x each time a tap operation is performed. When the spinning attack hits the enemy character e1 ten times in succession, it is determined that a predetermined condition regarding the spinning attack is met, and the operating character x executes a dive attack.

In this embodiment, the dive attack is defined as the first action for acting on the enemy character e1, and the spin attack is defined as the second action for acting on the enemy character e1. In the present embodiment, a state in which the number of taps is 0 is defined as a first state, and a state in which 10 consecutive spin attacks are performed is defined as a second state.

As described above, whether or not to execute a dive attack following a spinning attack is determined based on the action of the spinning attack on the enemy character e1. This makes the game more interesting.

(Specific example of joint battle space)
FIG. 10 shows an example of a display screen that depicts a joint battle space. State (A) of FIG. 10 shows the display screen when the display unit 152 is oriented vertically, and state (B) of FIG. 10 shows the display screen when the display unit 152 is oriented horizontally. The object control unit 115 arranges an object of the boss character K1 together with the operation character x in the joint battle space.

In the joint battle space, the camera placement control unit 113 may define the position and orientation of the virtual camera based on the positional relationship between the boss character K1 and the playable character x. For example, the camera arrangement control unit 113 arranges the virtual camera at an angle such that the boss character K1 is captured in the center of the field of view and the operation character x is captured. When the position of the boss character K1 or the operation character x changes, the camera placement control unit 113 changes the position and orientation of the virtual camera to the position and orientation according to the changed positions of the boss character K1 and the operation character x. Then, the display control unit 114 draws the joint battle space and each object based on the changed position and orientation of the virtual camera.

In the example of FIG. 10, the object control unit 115 displays the operation characters g1 and g2 corresponding to the other accounts and the non-player character y6 as friendly characters that fight the boss character K1 together with the operation character x. In FIG. 10, the physical strength value displayed near the non-player character y6 is labeled with [NPC] indicating that the character y6 is a non-player character (for example, [NPC]y6). Here, an example is shown in which each user who operates the operation characters x, g1, and g2 participates in the same joint battle, but the present invention is not limited to this. All friend characters other than the operating character x may be non-player characters.

In the joint battle space, when the boss character K1 is placed in the center of the field of view and the virtual camera is placed at such an angle that the control character x is captured, the operation of moving the control character x may be different from that in the battle space. For example, the upward movement operation may be an operation of advancing the playable character x toward the boss character K1, and the downward movement operation may be an operation of retreating the playable character x from the boss character K1.

When the ally character reduces the boss character K1 to a predetermined physical strength value of 0 or less, or inflicts damage exceeding the physical strength value of the boss character K1, the game progress processing unit 111 determines that subjugation of the boss character K1 has been completed. do. When the game progress processing unit 111 determines that the boss character K1 has been subdued, the game progress processing unit 111 may give the operating character or an account corresponding to the operating character a special reward that differs from that of a normal enemy character. In this case, the rewards may be different between the operating characters that participate in the battle.

The display control unit 114 may draw a UI for the user's input operation in the image of the joint battle space displayed on the display unit 152, as in the image of the battle space shown in FIG. The display control unit 114 may display a message according to the action of the ally character or the boss character. For example, the display control unit 114 determines that the game progress processing unit 111 has successfully executed an attack that exploits the weak point of the boss character, or that an allied operating character or non-player character has become unable to fight. In such a case, a message to that effect may be displayed. Alternatively, when the game progress processing unit 111 determines that the boss character is in a special state such as being unable to act, the display control unit 114 may display a message to that effect.

Note that the display control unit 114 draws various display items (buttons, menus, and messages) related to the UI described above so that they are positioned at fixed positions on the display screen of the display unit 152 regardless of the position and orientation of the virtual camera. It is desirable to The display control unit 114 provides various display items related to the UI such as input of instructions such as movement of the operating character, attack, recovery, etc., display of positions of allied characters, attack actions of the boss character, weak points of the boss character, etc. It is desirable to draw on the periphery of the display screen of the display unit 152 so as not to interfere with the display of important information in the battle with the character. It is desirable that the display control unit 114 also changes the drawing positions of various display items related to the UI according to the orientation of the display unit 152 .

<Processing flow and screen example>
Among the processes executed by the user terminal 100 based on the game program 121, the attack process in which the operating character x attacks the enemy character will be described with reference to the flowchart shown in FIG.

Note that the attack processing shown in FIG. 11 is executed by the game progress processing unit 111, the input operation reception unit 112, the display control unit 114, and the object control unit 115 when the operation character x is holding (equipping) the specific two-handed sword bb1. 3 shows an example of processing that is repeatedly executed by, for example. Also, at the time of starting the first attack process, the number of taps is set to 0, and the count value of a hit counter (not shown) (described later) is also set to 0.

Furthermore, in the following description, the flow of a series of processing steps described using flowcharts is described as being executed by the user terminal 100, but at least some of these processing steps are executed by the server 200. may be

In step S<b>01 , it is determined based on an input operation on the touch screen 15 whether or not the display screen has been touched. When it is determined that the display screen has not been touched, the current attack processing is ended, and when it is determined that the display screen has been touched, the process proceeds to step S02. In step S<b>02 , it is determined based on the input operation on the touch screen 15 whether the touch operation on the display screen corresponds to the tap operation.

When it is determined that the touch operation corresponds to the tap operation, the process proceeds to step S03. In step S03, the number of taps is updated, and the operating character x is made to perform a normal attack of a stage corresponding to the updated number of taps.

Specifically, if the number of taps before the tap operation is 0 or 2, the number of taps is updated to 1, and a horizontal slash is performed as the first normal attack. Also, if the number of taps before the tap operation is performed is 1, the number of taps is updated to 2, and a horizontal slash is performed as the second normal attack.

Also in step S03, it is determined whether or not the normal attack hits the enemy character. When the process of step S03 is completed, the current attack process ends.

When it is not determined in step S02 that the touch operation on the display screen corresponds to the tap operation, the process proceeds to step S04. In step S<b>04 , it is determined based on the input operation on the touch screen 15 whether the touch operation on the display screen corresponds to the long tap operation.

When it is determined that the touch operation is a long tap operation (when it is determined that the touch time has continued for the predetermined time T2), the process proceeds to step S05. In step S05, it is determined based on the number of taps whether or not the current state of the operating character x is the state after the second normal attack hits the enemy character.

When it is determined that the second normal attack hits the enemy character (that is, the number of taps is 2), the process proceeds to step S06 to make the operating character x perform a dive attack. As a result, the operating character x jumps and swings down the specific two-handed sword bb1 in the air. When the processing of step S06 is completed, the number of taps is returned to 0, and then the current attack processing is terminated.

If the long-tap operation continues even after the process of step S06 is completed, it is determined that the display screen has been touched in the next step S01, and the process proceeds to step S07 via steps S02, S04 and S05. In this case, in step S04, the timer for measuring the tap time is cleared in response to the start of the dive attack in step S06, and determination is made based on the newly measured tap time.

As a result, after the dive attack is performed in response to the long tap operation, the long tap operation is continued without being canceled, and the long tap operation is canceled after a predetermined time T2 has elapsed from the start of the dive attack. , a spinning attack is executed by the operating character x. That is, a spin attack is performed following a dive attack.

If it is not determined in step S05 that the second normal attack hits the enemy character, the process proceeds to step S07. In step S<b>07 , it is determined based on the input operation on the touch screen 15 whether or not the ongoing long tap operation has been cancelled. When it is determined that the long tapping operation has not been released, the process returns to step S07, and when it is determined that the long tapping operation has been released, the process proceeds to step S08.

In step S08, the operation character x is caused to execute a spinning attack. The playable character x rotates itself and swings the specific two-handed sword bb1 along with the rotation. In step S09, it is determined whether or not the spinning attack hits the enemy character based on various game parameters. When it is not determined that the spinning attack hits the enemy character, the process advances to step S14 to reset a hit counter for specifying the number of consecutive times the spinning attack hits the enemy character. That is, the count value of the hit counter is reset to zero. When the processing of step S14 is completed, the number of taps is returned to 0, and then the current attack processing is terminated.

When it is determined in step S09 that the spinning attack hits the enemy character, the process proceeds to step S10 to update the hit counter. Specifically, 1 is added to the current count value of the hit counter. In step S11, it is determined whether or not the count value is less than 10 based on the hit counter.

When it is determined that the count value is less than 10, the process proceeds to step S12. In step S<b>12 , it is determined based on the input operation on the touch screen 15 whether or not a tap operation has been performed within a predetermined time (for example, 0.1 seconds) from the previous spinning attack. When it is determined that the tap operation has been performed within the predetermined time, the process returns to step S08. On the other hand, when it is determined that the tap operation has not been performed within the predetermined time, the number of taps is returned to 0, and the current attack processing is terminated.

If it is not determined in step S11 that the count value of the hit counter is less than 10, the process proceeds to step S13. In step S13, the operation character x is made to perform a dive attack. When the processing of step S13 is completed, the number of taps is returned to 0, and then the current attack processing is terminated.

<Effects of this embodiment>
According to the present embodiment, in the first state (the number of taps=0), by accepting the input operation of the first mode, the playable character x is made to perform a dive attack. Input operations of the first mode include a tap operation for a first-stage normal attack, a tap operation for a second-stage normal attack (operation for a combo attack), and a long tap operation after a combo attack. A tap operation. Further, in the first state, by accepting the input operation of the second mode instead of the input operation of the first mode, the operation character x is made to perform a spinning attack. The input operation of the second mode refers to cancellation of the long tap operation.

When the count value of the hit counter reaches 10 by continuously hitting the enemy character with the spinning attack, and the second state (the state where the spinning attack hits 10 times in succession) is entered, the first mode is input. To make an operation character x perform the same attack as a dive attack without accepting an operation.

In this way, the dive attack is performed not only in response to a long tap operation after two tap operations for a combo attack, but also after the spinning attack hits the enemy character ten times in succession. become executable. That is, whether or not to execute a dive attack following a spinning attack is determined based on the effect of the spinning attack on the enemy character. As a result, depending on the progress of the game, it is possible to formulate a strategy such as whether to move to a dive attack via a combo attack, or to move to a dive attack after performing a spinning attack, and as a result, the interest of the game is improved. do.

Further, according to the present embodiment, a long tap operation (a touch operation that continues for a predetermined time T2 or more) is required to enable execution of either the dive attack or the first spin attack. However, the dive attack is executed when the touch operation continues for a predetermined time T2, and the first spin attack is executed when the touch operation continued for the predetermined time T2 or more is released. As a result, it is possible to improve the variety of attacks made to the playable character x while requesting a common touch operation.

Further, according to the present embodiment, in a state after a dive attack has been performed by receiving an input operation that is the first mode, the long tap operation that triggered the dive attack is continued without being canceled. Then, by canceling the state in which the touch time has reached the predetermined time T2, the operation character x is caused to perform a spinning attack. As a result, a spinning attack derived from a dive attack is realized.

Furthermore, according to the present embodiment, during execution of the spin attack, the spin attack is repeatedly executed each time a tap operation is received, and by continuing to hit, a dive attack is executed as a culmination of a series of attacks. As a result, it is possible to motivate the user to repeat the tap operation while simplifying the operation of the spinning attack for the second and subsequent times.

Further, according to the present embodiment, whether or not the spinning attack hits the enemy character is determined each time the spinning attack is performed. , the operating character performs the following spinning attack. On the other hand, when it is not determined that the enemy character has been hit, the operating character does not perform the next spinning attack regardless of the tap operation. This can motivate the user to hit the enemy character with the spinning attack.

<Modification>
Modified examples of the embodiment described above are enumerated below.

(1) In the above-described embodiment, the enemy character is hit with a dive attack that is executed after 10 successive hits of the spinning attack, thereby inflicting damage to the enemy character by the spinning attack and the diving attack for 10 times. can be done. In addition to this, benefits (coins, items, gems, skills, etc.) may be given to the user based on the fact that the dive attack hits the enemy character. As a result, the user can be motivated to perform a dive attack by hitting the spinning attack ten times in succession.

(2) In the above embodiment, if the spinning attack hits 10 times in succession, the dive attack is executed without waiting for an instruction from the user such as a tap operation. However, the dive attack may be executed in response to a specific instruction after 10 successive hits of the spinning attack. In this case, the specific instruction includes (a) a tap operation, (b) an operation by a specific voice uttered by the user, (c) an operation by shaking the user terminal 100, and (d) a gesture to the camera 17 ( For example, an operation by moving a finger or eyes in a specific mode, or blinking an eye in a specific mode, or (e) a drag operation that draws a specific trajectory (for example, "S") on the display screen can be considered. In addition, the above-described operations (a) to (e) are prepared as operations that enable execution of a dive attack after 10 consecutive hits of the spinning attack, and the dive attack is performed depending on which operation is performed. may determine the power of

(3) In the above embodiment, even if the spinning attack hits 10 times in succession, the user is not notified of this fact. However, when the spinning attack hits 10 times in a row, the user may be notified of this fact, or a count-up or count-down display may be made each time the spinning attack hits.

(4) In the above embodiment, another object is assumed to be an enemy character that fights with the operating character x. However, obstacles such as huge rocks and buildings may be assumed as other objects.

(5) In the above embodiment, the power of the first spin attack executed in response to releasing the long tap operation does not change according to the touch time. However, the longer the tap time is, the stronger (larger) the power of the spin attack may be.

(6) In the above embodiment, the power of the dive attack executed after 10 successive hits of the spinning attack does not change according to the battle situation. However, the power of the dive attack may be weakened as the physical strength of the operating character x weakens, or the power of the dive attack may be increased according to the skill that the user can exercise. Also, the total amount of damage to the enemy character when the spinning attack hits 10 times in succession may be displayed.

(7) In the above embodiment, in order to execute a dive attack following a spinning attack, it is necessary to hit the spinning attack 10 times in succession. However, the number of spin attacks that must be hit in succession may be increased as the level (strength) of the enemy character is higher.

(8) In the above embodiment, only one enemy character appears in the battle scene. However, a plurality of enemy characters may appear in the battle scene. In this case, the number of consecutive hits of the spinning attack, which is the condition for shifting from the spinning attack to the dive attack, may be decreased as the number of enemy characters increases. That is, if there are two enemy characters, a dive attack can be executed in response to a tap operation after the spinning attack hits five times in a row, and if there are three enemy characters, the spinning attack hits three times in a row. A dive attack may be made executable according to a later tap operation.

(9) In the above embodiment, on the condition that the spinning attack hits the enemy character, the operating character is made to perform the spinning attack up to 10 times in accordance with the tap operation. However, regardless of whether or not the spinning attack hits the enemy character, the operating character may be caused to perform spinning attacks up to 10 times in accordance with the tap operation. In this case, the predetermined condition may be satisfied when the tap operation is performed 10 times regardless of the number of hits, may be satisfied according to the number of hits (10 times), or may be satisfied at a rate corresponding to the number of hits. It may be something to do. When the predetermined condition is satisfied at a rate corresponding to the number of hits, for example, when the number of hits is 10, the predetermined condition is satisfied at a rate of 100%, and when the number of hits is 9, the predetermined condition is satisfied at a rate of 90%. is established, and the lower the number of hits, the lower the rate at which the predetermined condition is established. When the number of hits is zero, the predetermined condition may not be established.

(10) In the above embodiment, when a long-tap operation for executing a dive attack or a spinning attack is performed, regardless of whether or not an enemy character attacks during the long-tap operation, the dive attack Or a spinning attack is executed. However, if an enemy character attacks during the long tap operation, the dive attack or spin attack is stopped and the user is requested to redo the input operation for executing the dive attack or spin attack. may

(11) In the above embodiment, it is determined in step S12 whether or not a tap operation has been performed within a predetermined time (for example, 0.1 seconds) from the previous spin attack. However, after enabling the tap operation to be reserved, it may be determined in step S12 whether or not the tap operation is reserved. Specifically, when a tap operation is performed, a register (not shown) may be set to that effect, and whether or not the tap operation has been performed may be determined based on the setting of the register.

(12) In the above embodiment, the operation for the combo attack and the long tap operation after the combo attack are defined as the input operation of the first mode, and the cancellation of the long tap operation is defined as the input operation of the second mode. Define. However, another input operation (for example, an upward flick operation) may be defined as an input operation of the first mode, and another input operation (for example, a rightward flick operation) may be defined as a second mode input operation. .

(13) In the above embodiment, the attack executed when the spinning attack hits the enemy character ten times in a row is the same as the dive attack executed in response to the long tap operation after the combo attack. However, the attack executed when the spin attack hits 10 times in succession is not limited to the same attack as the dive attack, and may be similar to the dive attack. As similar attacks, the action (movement) of the operated character is the same, but the attack power is higher than the dive attack executed in response to the long tap operation after the combo attack, and the action is slightly different ( For example, different jump heights, etc.) are conceivable.

(14) In the above embodiment, the dive attack is executed when the touch operation continues for the predetermined time T2, and the first spin attack is performed when the touch operation continued for the predetermined time T2 or more is released. is executed by However, the time during which the touch operation is continued for executing the dive attack (first time) and the time during which the touch operation is continued for executing the first spin attack (second time) are different from each other. You may allow For example, the second time may be set to be longer than the first time. Therefore, when performing a spin attack by continuing the long-tap operation after performing a dive attack, the long-tap operation is continued after performing the dive attack but is canceled before the second time elapses. The spinning attack is not carried out when it is stuck, and is carried out only when it is continued until the second time elapses and is released. This makes it possible to enhance the interest of the game.

(15) In the above embodiment, if the long-tapping operation continues even after the processing of step S06 is completed, it is determined that the display screen has been touched in the next step S01, and the process proceeds to step S02. However, in step S01, it is determined whether or not the state in which the display screen is not touched has changed to the state in which it is touched. is determined), the current attack processing may be terminated without proceeding to step S02. In this case, once the touch operation is canceled after the dive attack in step S06, the first spin attack in step S08 can be executed.

(16) In the above embodiment, the actions to be executed by the playable character are assumed to be a dive attack (first action) and a spin attack (second action). An avoidance action (third action) for avoiding an attack or a wheel attack (fourth action) against an enemy character may be executed by the operating character. In this case, the avoidance action is executed by accepting a flick operation (input operation as a fourth mode) regardless of the state of the playable character. Further, the wheel attack is performed by accepting a long-tap operation (an input operation including a mode in which an input to the touch screen 15 is continued for a predetermined time T2 or more) within a predetermined time T3 after receiving the flick operation. , is executed.

The wheel attack may be activated without releasing the touch when the touch time reaches the predetermined time T2, or conversely may be activated in response to the release of the touch after the predetermined time T2. Further, when the wheel attack is activated without releasing the touch, the touch operation is continued even after activation, so the spinning attack may be performed in accordance with the release of the touch operation.

Further, as the avoidance action, when the flick operation is performed, the operation character is made to crouch down and roll in the flick operation direction to perform the first avoidance action. In some cases, it is conceivable to cause the operating character to perform a second avoidance action of making a large somersault instead of the first avoidance action. Furthermore, as the wheel attack, for example, an attack in which the operating character rolls forward, charges at an enemy character in front, and sticks out a specific two-handed sword bb1 can be considered. Also, the power of the wheel attack may be stronger than the normal attack and the spinning attack and weaker than the dive attack.

Furthermore, when setting the invulnerability time for the operated character according to the flick operation for the avoidance action, the invulnerability time set corresponding to the second avoidance action is set corresponding to the first avoidance action. You may make it differ from invincibility time. Also, the length of the predetermined time T3 when the second avoidance action is performed may be different from the length of the predetermined time T3 when the first avoidance action is performed. Furthermore, the power of the wheel attack executed after the second avoidance action may be made different from the power of the wheel attack executed after the first avoidance action.

(17) According to the above embodiment, after the dive attack is activated, if the touch operation that triggered the activation of the dive attack continues, the touch operation is canceled to continue the dive attack. A spinning attack can be activated. However, after the dive attack ends, the user may want to perform a normal attack or an evasive action instead of a spinning attack. Such a request can be met by controlling whether or not to perform a spinning attack after the dive attack is completed, according to the user's operation mode.

Specifically, the touch operation is continued until the action of the dive attack is completed, and if the touch operation is canceled after the action of the dive attack is completed, the rotation attack is considered to have the intention of performing the rotation attack. can be activated. On the other hand, if the touch operation is canceled before the action of the dive attack is completed, the spin attack is not activated because the player has no intention of performing the spin attack. As a result, after the dive attack ends, an action (various attacks including normal attack, evasive action, etc.) can be performed according to the subsequent operation mode of the user.

<Appendix>
The items described in each of the above embodiments will be added below.

(Appendix 1):
According to an aspect of one embodiment shown in the present disclosure, a game program executed in a computer (user terminal 100 in FIG. 1) comprising a processor, memory, and a touch screen, the game program being executed by the processor a first step of displaying a user-operable game character and other objects on the touch screen; a second step of accepting an input operation to the touch screen; = 0 state), the first action for exerting an effect on the other object ( a third step (S06) of causing the game character to perform a dive attack); a fourth step (S08, S09, S12, S14) of causing the game character to perform a second action (rotating attack) for exerting an effect on the other object by receiving a fourth step (S08, S09, S12, S14); A predetermined condition (hit counter = 10) is established based on the action exerted on the other character, and the second state (state after 10 successive hits of the spin attack) is established. A fifth step (S13) of causing the game character to perform the same action as the first action is executed without requiring an input operation as a mode.

(Appendix 2):
In (Appendix 1), each of the first aspect and the second aspect includes an aspect in which the input to the touch screen is continued for a predetermined time or more, and the third step is to continue the input to the touch screen. When the time reaches a first time, the first action is performed, and the fourth step cancels the input operation on the touch screen continued for a second time or longer, thereby performing the second action. to do

(Appendix 3):
In (Appendix 2), in the fourth step, in a state after the first action has been performed in the third step, without canceling the input to the touch screen that triggered the first action, The second action is caused to be performed by the game character by continuing it and canceling it when the second time is reached.

(Appendix 4):
In (Supplementary Note 1) or (Supplementary Note 2), the input operation that is the first mode is an input operation to be performed on the touch screen for a predetermined time or more after receiving the input operation that is the specific mode (two tap operations). The input operation that becomes the second mode is established by continuing the input to the touch screen for a predetermined time or more without accepting the input operation that becomes the specific mode.

(Appendix 5):
In any one of (Appendix 1) to (Appendix 3), in the fourth step, each time an input operation (tap operation) serving as a third mode is received during the second action, the second action is performed in the game. It includes repeat steps (S09, S12, S14) that allow the character to repeat.

(Appendix 6):
In (Appendix 5), the repeating step determines whether or not the second action has exerted an effect on the other object each time the second action is performed (S09). By being determined, it is possible to cause the game character to repeatedly perform the next second action according to the input operation (S12), and since it is not determined that the action has been exerted, the next action can be performed regardless of the input operation. The game character is made to perform a second action (S14).

(Appendix 7):
In (Appendix 5) or (Appendix 6), the predetermined condition includes a condition that is satisfied when the second action continues for a predetermined number of times.

(Appendix 8):
In any one of (Appendix 1) to (Appendix 7), the fifth step causes the same action as the first action to be performed by accepting a specific instruction when the second state is established.

(Appendix 9):
In any one of (Appendix 1) to (Appendix 8), the game program instructs the processor to provide the user with a benefit based on the action exerted on the other object by the action performed in the fifth step. is executed.

(Appendix 10):
In any one of (Appendix 1) to (Appendix 9), the game program causes the processor to accept an input operation (flick operation) as a fourth mode regardless of the state of the game character, thereby causing the other a seventh step of causing the game character to perform a third action (avoidance action) for avoiding the action from the object; a fourth action (wheel attack) for exerting an effect on the other object by receiving an input operation (long tap operation) including a mode of continuing input to the touch screen for a predetermined time or longer; to perform the eighth step.

(Appendix 11):
According to an aspect of one embodiment shown in the present disclosure, a game method performed by a computer (user terminal 100 in FIG. 1) comprising a processor, memory, and a touch screen, the game method comprising: a first step of displaying a user-operable game character and other objects on the touch screen; a second step of accepting an input operation to the touch screen; = 0 state), the first action for exerting an effect on the other object ( a third step (S06) of causing the game character to perform a dive attack); a fourth step (S08, S09, S12, S14) of causing the game character to perform a second action (rotating attack) for exerting an effect on the other object by receiving a fourth step (S08, S09, S12, S14); A predetermined condition (hit counter = 10) is established based on the action exerted on the other character, and the second state (state after 10 successive hits of the spin attack) is established. and a fifth step (S13) of causing the game character to perform the same action as the first action without requiring an input operation as a mode.

(Appendix 12):
According to an aspect of an embodiment shown in the present disclosure, an information processing device (user terminal 100 in FIG. 1), comprising a storage unit (120 in FIG. 3) storing a game program, and executing the game program A control unit (110 in FIG. 3) for controlling the operation of the information processing apparatus is provided, and the control unit causes the touch screen to display a game character operable by the user and other objects. 1 step, a second step of receiving an input operation on the touch screen, and when the game character is in the first state (the number of taps = 0), the input operation (two taps) in the first mode a third step (S06) of causing the game character to perform a first action (dive attack) for exerting an effect on the other object by receiving an operation and one long tap operation); In the first state, by accepting an input operation (long-tap release operation) as a second mode different from the first mode, a second action (rotation) for acting on the other object is received. A predetermined condition (hit counter=10) is established based on the fourth step (S08, S09, S12, S14) of causing the game character to perform an attack) and the action exerted on the other character by the second action. to the second state (the state after 10 consecutive hits of the spinning attack), so that the same action as the first action can be performed on the game character without requiring the input operation of the first mode. A fifth step (S13) is executed.

[Example of realization by software]
The control blocks of the control unit 210 (especially the transmission/reception unit 211, the server processing unit 212, the data management unit 213 and the synchronization processing unit 214) and the control blocks of the control unit 110 (especially the game progress processing unit 111, the input operation reception unit 112 , camera arrangement control unit 113, display control unit 114, object control unit 115, lottery control unit 116, and point management unit 117) are realized by logic circuits (hardware) formed in an integrated circuit (IC chip) or the like. Alternatively, it may be realized by software using a CPU (Central Processing Unit).

In the latter case, an information processing apparatus including control unit 210 or control unit 110, or both, includes a CPU that executes instructions of a program, which is software that implements each function, and a computer (or CPU) that stores the program and various data. A ROM (Read Only Memory) or storage device (these are referred to as a "recording medium") recorded so as to be readable by , a RAM (Random Access Memory) for developing the above program, and the like. The object of the present invention is achieved by a computer (or CPU) reading and executing the program from the recording medium. As the recording medium, a "non-temporary tangible medium" such as a tape, disk, card, semiconductor memory, programmable logic circuit, or the like can be used. Also, the program may be supplied to the computer via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. Note that one aspect of the present invention can also be implemented in the form of a data signal embedded in a carrier wave in which the program is embodied by electronic transmission.

The present invention is not limited to the above-described embodiments, but can be modified in various ways within the scope of the claims, and can be obtained by appropriately combining technical means disclosed in different embodiments. is also included in the technical scope of the present invention.

1 game system, 2 network, 10,20 processor, 11,21 memory, 12,22 storage, 15 touch screen, 151 input unit, 152 display unit, 17 camera, 18 ranging sensor, 1010 object, 1020 controller, 1030 storage Medium 100 User terminal 200 Server 120,220 Storage unit 121,221 Game program 122,222 Game information 123,223 User information 110,210 Control unit 111 Game progress processing unit 112 Input operation reception unit 113 camera arrangement control unit 114 display control unit 115 object control unit 116 lottery control unit 117 point management unit 211 transmission/reception unit 212 server processing unit 213 data management unit 214 synchronization processing unit.

Claims (10)

display means for displaying a character that can be operated by a computer and other objects;
input receiving means for receiving an input operation from the user ;
When the character is in the first state, the first action that exerts a larger effect than the normal action for exerting an effect on the other object is performed by receiving the input operation that is the first mode. a control means for causing the character to perform;
to make it work,
When the character is in the first state, the control means accepts an input operation in a second state different from the first state, thereby performing an action having a greater effect than the normal action. having the character perform a second action different from the first action ;
A predetermined condition is satisfied based on the action exerted on the other character by the second action, and the second state is entered, so that the input operation that becomes the first mode is not required, and the same action as the first action is performed. A program that causes the character to perform an action. Each of the first aspect and the second aspect includes an aspect in which the input operation from the user is continued for a predetermined time or longer,
The control means causes the first action to be performed when the duration of the input operation from the user reaches a first time ,
2. The program according to claim 1, causing said second action to be performed by canceling said user's input operation that has continued for a second time or more. In a state after the first action is performed, the control means continues without canceling the input operation from the user that triggered the first action until the second time is reached. 3. The program according to claim 2, causing said character to perform said second action by canceling said input operation in a state where said second action is performed. The input operation as the first aspect is established by continuing the input operation from the user for a predetermined time or more after receiving the input operation as the specific aspect,
3. The input operation according to claim 1 or 2, wherein the input operation as the second aspect is established by allowing the input operation from the user to continue for a predetermined time or longer without accepting the input operation as the specific aspect. program . wherein said control means makes it possible for said character to repeatedly perform said second action each time an input operation of a third mode is accepted during said second action; 4. The program according to any one of 3. The pre- control means determines whether or not the second action has exerted an effect on the other object each time the second action is performed, and responds to the input operation by determining that the effect has been exerted. and making it possible to cause the character to perform the next second action repeatedly, and to cause the character to perform the next second action regardless of the input operation because it is not determined that the action has been exerted. 6. The program of claim 5, wherein no. 7. The program according to claim 5, wherein said predetermined condition includes a condition that is satisfied when said second action continues for a predetermined number of times. 8. The program according to any one of claims 1 to 7, wherein said control means , when in said second state, causes said computer to perform the same action as said first action by accepting a specific instruction to said computer. Logogram. said computer
means for awarding a privilege to the user based on the action exerted on the other object by the action performed by the control means ;
9. The program according to any one of claims 1 to 8, which functions as a program. The control means is
causing the character to perform a third action for avoiding an action from the other object by accepting an input operation in a fourth mode regardless of the state of the character ;
By accepting an input operation including a mode in which the input from the user is continued for a predetermined time or more before a predetermined time elapses after receiving the input operation as the fourth mode, the other object 10. The program according to any one of claims 1 to 9 , causing the character to perform a fourth action for exerting an effect on the character.

Images