JP7448607B2 - program - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act October 5, 2017 By posting information regarding game programs on its website (https://www.youtube.com/watch?v=IbNwHwp_0Vk), COLOPL Co., Ltd. , published an overview of the game based on the game program invented by Jiro Taoka and Masayuki Inoue.

Application of Article 30, Paragraph 2 of the Patent Act August 9, 2017 Colopl Co., Ltd. posted information about the game program on its website (https://twitter.com/Drgnpj_colopl), thereby disclosing Jiro Taoka and Masayuki Inoue. Published an overview of the game based on the game program invented by.

This disclosure relates to programs.

2. Description of the Related Art Game programs are known that cause a computer to execute a game in which events are provided to the user so that they can be played. In such a game, when a condition set for an event is satisfied by the user's play, a reward is given to the user. For example, Non-Patent Document 1 describes a game in which users are challenged to take on quests in which various missions are imposed, and rewards are given to the users in accordance with clearing the quests.

Monster Hunter Explore Official Strategy Summary, “How to read the screen”, [on line], “Searched on August 28, 2016”, Internet <http://wiki.famitsu.com/mhexplore/%E7%94%BB%E9 %9D%A2%E3%81%AE%E8%A6%8B%E6%96%B9＞

In a game where events are given to the user, the user may be in a situation where he or she owns a plurality of events. In such a situation, if users could not only get rewards by playing events but also get rewards from events by means that do not require play by the user, users would be able to focus on playing events that interest them and play games. can proceed. Therefore, in such games, there is a need to diversify the means for obtaining rewards from events.

One aspect of the present disclosure aims to support user progress by diversifying the means of obtaining rewards.

The program according to the present disclosure causes the computer to store playable events in association with the user, and when a first condition is satisfied in response to play of the event, stores a first reward in association with the user. When the second condition, which is not related to the play of the event, is satisfied, the storage means has a value in favor of advancing the game even if the event is not played and the first condition is not satisfied. A second reward lower than the first reward is stored in association with the user.

A method according to the present disclosure is a method in which a computer executes a program. The method includes a processor performing the steps recited in claim 1.

An information processing device according to the present disclosure includes a storage unit that stores the above-described program, and a control unit that controls the operation of the information processing device by executing the program.

According to one aspect of the present disclosure, it is possible to support the user's progress by diversifying the means for obtaining rewards.

1 is a diagram showing a hardware configuration of a game system. FIG. 2 is a block diagram showing the functional configuration of a server. FIG. 2 is a block diagram showing the functional configuration of a user terminal. FIG. 3 is a diagram illustrating the progress of a game provided by the game system and an example of transition of a game space. FIG. 3 is a diagram showing an example of a display screen depicting a preparation space. FIG. 3 is a diagram showing an example of a display screen depicting a battle space. FIG. 3 is a diagram showing an example of a display screen depicting a collaborative battle space. FIG. 6 is a diagram illustrating an example of a display screen for explaining operation input for participating in a lottery and acquiring the right to play a joint battle. FIG. 7 is a diagram illustrating an example of a display screen for explaining an operation input for a user to start a joint battle. It is a figure which shows the example of a display screen showing the reward provided when subjugation is completed by play. FIG. 7 is a diagram illustrating an example of a display screen for registering a joint battle as a target for points accumulation. FIG. 7 is a diagram illustrating an example of a display screen showing points accumulated for registered cooperative battles. FIG. 6 is a diagram illustrating an example of a display screen showing rewards given when a joint battle is completed by accumulating points. 12 is a flowchart illustrating the flow of processing for registering a joint battle as a point accumulation target. It is a flowchart which shows the flow of processing which completes a joint battle by playing. 12 is a flowchart showing the flow of processing for completing a joint battle by accumulating points.

A game system according to the present disclosure is a system for providing a game to a plurality of users. The game system will be described below with reference to the drawings. It should be noted that the present invention is not limited to these examples, but is indicated by the scope of the claims, and it is intended that all changes within the meaning and range equivalent to the scope of the claims are included in the present invention. Ru. In the following description, the same elements are given the same reference numerals in the description of the drawings, and overlapping 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. As illustrated, the game system 1 includes a plurality of user terminals 100 and a server 200. Each user terminal 100 is connected to a server 200 via a network 2. The network 2 includes the Internet and various mobile communication systems constructed by wireless base stations (not shown). Examples of this mobile communication system include so-called 3G, 4G mobile communication systems, LTE (Long Term Evolution), and wireless networks (for example, Wi-Fi (registered trademark)) that can be connected to the Internet through predetermined access points. It will be done.

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

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

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

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

It is desirable that the user terminal 100 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, when starting the game. This makes it possible for the user terminal 100 to link the controller 1020 and the user, and identify which user the received output value belongs to based on the source (controller 1020) of the received output value. be able to.

When the user terminal 100 communicates with a plurality of controllers 1020, by each user holding each controller 1020, the user terminal 100 can communicate with the one user terminal 100 without communicating with other devices such as the server 200 via the network 2. Multiplayer can be realized. In addition, each user terminal 100 communicates with each other using a wireless standard such as a wireless LAN (Local Area Network) standard (communicates without going through the server 200), thereby realizing local multiplayer with multiple user terminals 100. You can also. When the above-described multiplayer is locally implemented using one user terminal 100, the user terminal 100 may further include at least some of the various functions provided by the server 200, which will be described later. Moreover, when the above-mentioned multiplayer is realized locally by a plurality of user terminals 100, the plurality of user terminals 100 may have various functions provided in the server 200, which will be described later, in a distributed manner.

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

Further, the controller 1020 may be configured to be detachable from the user terminal 100. In this case, a coupling portion with the controller 1020 may be provided on at least one surface of the casing of the user terminal 100. When the user terminal 100 and the controller 1020 are connected via a wire via the coupling section, the user terminal 100 and the controller 1020 transmit and receive signals via the wire.

As shown in FIG. 1, the user terminal 100 may accept attachment of a storage medium 1030 such as an external 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. The program recorded on the storage medium 1030 is, for example, a game program.

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

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

For example, when the operation unit is configured with at least one of the camera 17 and the distance measurement 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, a marker with a predetermined shape, or the like is detected as the object 1010, and an input operation is specified based on the color, shape, movement, type, etc. of the object 1010 obtained as a detection result. Ru. More specifically, when the user's hand is detected from the captured image of the camera 17, the user terminal 100 converts the gesture (a series of movements of the user's hand) detected based on the captured image into the user's input operation. be identified and accepted as such. Note that the photographed image may be a still image or a moving image.

Alternatively, when the operation unit is configured with 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 with the communication IF 13, the user terminal 100 identifies and receives a signal (for example, an output value) transmitted from the controller 1020 as a user's input operation. Alternatively, when the operation unit is configured with the input/output IF 14, a signal output from an input device (not shown) connected to the input/output IF 14 and different from the controller 1020 is identified and accepted as the user's input operation.

<Hardware components of each device>
Processor 10 controls the overall operation of user terminal 100. Processor 20 controls the overall operation of server 200. 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 expands it into a memory 11, which will be described later. The processor 20 reads a program from a storage 22, which will be described later, and expands it into 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 that the processor 10 reads from a storage 12, which will be described later. The memory 11 also temporarily stores various data generated while the processor 10 is operating according to a program. The memory 21 provides a work area for the processor 20 by temporarily storing various programs and data that the processor 20 reads from a storage 22, which will be described later. The memory 21 also temporarily stores various data generated while the processor 20 is operating according to a program.

In this embodiment, the program may be a game program for realizing a game on the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation between the user terminal 100 and the server 200. Note that the game realized through cooperation between the user terminal 100 and the server 200 may be, for example, a game executed on a browser started on the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation of a plurality of user terminals 100. Further, the various data include data related to games 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 comprised of storage devices such as flash memory or HDD (Hard Disk Drive). The storage 12 and the storage 22 store various data related to the game.

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 is an interface for the user terminal 100 to output data. The input/output IF 14 may input/output data via a USB (Universal Serial Bus) or the like. The input/output IF 14 may include, for example, a physical button, a camera, a microphone, or a speaker of the user terminal 100. 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 that displays and outputs images.

The touch screen 15 of the user terminal 100 is an electronic component that combines an input section 151 and a display section 152. The input unit 151 is, for example, a touch-sensitive device, and includes, 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 operations such as touch operation, slide operation, swipe operation, and tap operation) is input on the input screen, and inputs information indicating the position. Equipped with a function to transmit as a signal. The input unit 151 may include a touch sensing unit (not shown). The touch sensing section may employ any method such as a capacitance method or a resistive film method.

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. When the user terminal 100 includes a sensor, the processor 10 can also 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. 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. In this way, the processor 10 may be able to switch between vertical screen display and horizontal screen display depending on the holding posture of the user terminal 100.

The camera 17 includes an image sensor and the like, and generates a captured image by converting incident light that enters 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 distance measurement sensor 18 includes, for example, a light source that emits pulse-converted light and a light receiving element that receives the light. The distance sensor 18 measures the distance to the object to be measured based on the timing of light emission from the light source and the timing of reception of reflected light generated when the light emitted from the light source hits the object and is reflected. The distance sensor 18 may include a light source that emits light with directivity.

Here, an example will be further described in which the user terminal 100 uses the camera 17 and the ranging sensor 18 to receive a detection result of detecting an object 1010 in the vicinity of the user terminal 100 as a user's input operation. The camera 17 and the ranging sensor 18 may be provided, for example, on the side surface of the housing of the user terminal 100. A distance measuring 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 a lighting device that emits infrared rays, a filter that blocks visible light, and the like. This makes it possible to further improve the accuracy of object detection based on images captured by the camera 17, regardless of whether the object is outdoors or indoors.

The processor 10 may perform, for example, one or more of the following processes (1) to (5) on the captured image of the camera 17. (1) The processor 10 performs image recognition processing on the image taken by the camera 17 to identify whether or not the user's hand is included in the image taken. The processor 10 may use a technique such as pattern matching, for example, as an analysis technique employed in the image recognition process described above. (2) The processor 10 also detects the user's gestures from the shape of the user's hands. 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 photographed image. The processor 10 further identifies the gesture performed by the user from the identified number of fingers. For example, if the number of fingers is five, the processor 10 determines that the user has made a "pa" gesture. Furthermore, when the number of fingers is 0 (no fingers are detected), the processor 10 determines that the user has made a "goo" gesture. Further, if the number of fingers is two, the processor 10 determines that the user has made a "choki" 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 where only the index finger is held up or whether the user's finger is in a flicking motion. . (4) The processor 10 determines whether an object 1010 (such as a user's hand, ) 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, at a distance less than a predetermined value) or far away (for example, at a distance less than a predetermined value), depending on the size of the shape of the user's hand identified from the captured image of the camera 17. 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) If it is found that the distance between the user terminal 100 and the user's hand has changed while the user's hand has been detected based on the image recognition result of the image taken by 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 stronger directivity than the shooting range of the camera 17, the processor 10 detects that the user is waving his/her hand in a direction perpendicular to the shooting direction of the camera. recognize.

In this way, the processor 10 determines whether the user is clasping his/her hands (a "goo" gesture or another gesture (for example, "paa") by image recognition of the image taken by the camera 17. ). The processor 10 also detects the shape of the user's hand and how the user moves the hand. The processor 10 also detects whether the user is moving his hand closer to or away from the user terminal 100. Such an operation can correspond to, for example, an operation using a pointing device such as a mouse or a touch panel. For example, the user terminal 100 moves the pointer on the touch screen 15 according to the movement of the user's hand, and detects the user's gesture “goo”. In this case, the user terminal 100 recognizes that the user is continuing the selection operation. Continuation of the selection operation corresponds to, for example, the mouse being clicked and kept pressed in, or the mouse being touched after a touch down operation is performed on the touch panel. Further, when the user further moves his/her hand while the user's gesture "goo" is being detected, the user terminal 100 detects a series of such gestures as an operation corresponding to a swipe operation (or drag operation). It can also be recognized. Further, when the user terminal 100 detects a gesture such as a flick of the user's finger based on the detection result of the user's hand based on the captured image of the camera 17, the user terminal 100 converts the gesture into a mouse click or a tap operation on the touch panel. It may be recognized as an operation corresponding to .

<Game Overview>
The game system 1 is a system that executes a game that provides playable events to the user in the game. Here, granting a playable event means storing in memory a rights item representing the right to play the event in association with the user.

In this embodiment, an example will be described in which the game system 1 is a system that executes a game in which a playable character operated by a user fights an enemy character. Further, in this case, an example in which an example of the event is a joint battle will be described. The cooperative battle includes the operated character fighting a specific enemy character (for example, a boss character) together with other characters. Hereinafter, an event in which a right item is associated with a user will also be referred to as a joint battle held by the user.

Note that the game system 1 is not limited to a specific genre, and may be a system for executing games of any genre. For example, games based on sports such as tennis, table tennis, dodgeball, baseball, soccer, and hockey, puzzle games, quiz games, RPGs, adventure games, shooting games, simulation games, training games, and action games. Good too.

Furthermore, the game system 1 is not limited to a specific play mode, and may be a system for executing games of any play mode. For example, there are single-play games played by a single user, multi-play games played by multiple users, and among multi-play games, competitive games played by multiple users, and cooperative play games played by multiple users. It's okay.

<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. The server 200 has a function of providing each user terminal 100 with various data and programs necessary to realize 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 performing synchronization processing between a plurality of user terminals 100.

Note that in this embodiment, the server 200 identifies each user and the user terminal 100 using a game account registered in advance. The method of registering an account is not particularly limited. For example, the user terminal 100 or another device such as a personal computer may transmit information necessary for registering the user's account to the server 200 in accordance with the user's operation. Then, the server 200 may create and save 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 any account, the server 200 recognizes the logged-in user terminal 100. Note that there are no particular limitations on the login method and processing related to login. The server 200 and the user terminal 100 may perform conventionally known login methods and various processes 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.

The storage unit 220 stores various data used by the control unit 210. The storage unit 220 stores a game program 221, game information 222, and user information 223.

The game program 221 is a program for realizing a game. Game information 222 and user information 223 are data referenced when game program 221 is executed.

In addition to the game program executed on the server 200 side, the game program 221 may include a program (game program 121 described below) that is transmitted to the user terminal 100 and executed on the user terminal 100 side. 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.

Game information 222 is information common between accounts. The game information 222 may include, for example, information for defining various game spaces. The "game space" is a space in which objects of playable characters that can be operated by the user are arranged. The game information 222 is common between accounts, such as the location, size, color, and shape of background objects such as trees, rocks, and buildings, and non-player character (NPC) objects placed in the game space. may include various configuration information regarding the object. The game information 222 may include setting values for various parameters of the non-player character. 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 with achievement conditions set. Achievement conditions may be set for each quest. Note that failure conditions may be set for the quest in addition to achievement conditions. Furthermore, 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 regarding playable characters (hereinafter referred to as playable characters), information regarding owned assets, information indicating the progress of the game, and cooperative battles (events) awarded in lottery included in the game. It may include information regarding the ownership status of the right to play. Here, examples of held assets include in-game currency, items, character equipment, and the like. A joint battle is, for example, an event that includes a playable character fighting 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. The control unit 210 functions as a transmitting/receiving unit 211 , a data management unit 213 , and a server processing unit 212 by executing a game program 221 .

The transmitting/receiving unit 211 transmits and receives various data. For example, the transmitting/receiving unit 211 receives requests for sending various data and programs from the user terminal 100, requests for synchronization to support a multiplayer function, data for synchronization, etc., and sends them to the server processing unit 212. For example, the transmitting/receiving 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 "multiplay function" is a function that allows the game to progress while synchronizing the progress of the game in multiple accounts. The server 200 and user terminal 100 of the game system 1 perform various processes to support 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 to provide the game. The server processing unit 212 executes arithmetic processing described in the game program 221 in response to requests from the user terminal 100 and the like.

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

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 in response 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 in accordance with an instruction from the server processing unit 212, and transmits it to the user terminal 100 via the transmission/reception unit 211.

For example, in accordance with instructions from the server processing unit 212 , the data management unit 213 reads out of the game program 221 a program to be executed on the user terminal 100 side from the storage unit 220 and transmits it to the user terminal 100 via the transmission/reception unit 211 . do.

The synchronization processing unit 214 performs synchronization processing to support the multiplay 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. Even 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, etc. from the server processing unit 212. As a result, the in-game action caused by, for example, an input operation performed on one user terminal 100 is synchronized and shown 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. The user terminal 100 has a function as an input device that receives input operations from a user, and a function as an output device that outputs images and sounds of the game. The user terminal 100 functions as a control unit 110 and a storage unit 120 through cooperation of the processor 10, memory 11, storage 12, communication IF 13, input/output IF 14, and the like.

The storage unit 120 stores a 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 that the control unit 110 refers to when executing the game program 121, and includes information similar to the game information 222 of the server 200. The user information 123 is data related to the account of the user of the user terminal 100 and includes the same information as 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 various data, programs, data for synchronization to support a multiplay function, etc. from the server 200. For example, the control unit 110 transmits to the server 200 some or all of the game information 122 or user information 123, and a request for synchronization to support the multiplayer function.

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

The input operation accepting unit 112 detects and accepts a user's input operation on the input unit 151. The input operation reception unit 112 determines what type of input operation has been performed based on the action exerted by the user on the console via the touch screen 15 and other input/output IF 14, and transmits 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 a touch operation, a slide operation, a swipe operation, a tap operation, and the like. When the continuously detected input is interrupted, the input operation receiving unit 112 detects that the contact input from the touch screen 15 is released.

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 content of the user's instruction indicated by the coordinates of the input position and the type of operation of the input operation received by the input operation reception unit 112. 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.

Further, the game progression processing unit 111 advances the game by performing the following processing. The following processing is (a) a process of granting a cooperative battle to the user when a predetermined condition is met, and (b) a process of granting the user a first reward or a second reward depending on the completion of the granted cooperative battle. (c) A process of generating or advantageously changing an object that can be used in a joint battle based on the first reward or the second reward that has been granted. (B) The process of granting joint battles 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 sequentially explained.

The game progress processing unit 111 provides a first reward to the user when a first condition set for a joint battle is satisfied. The granted first reward is stored in the storage unit 120 in association with the user. The first condition is a condition based on the play of a joint battle, and is, for example, that the player succeeds in defeating the enemy character through the play of a joint battle.

Further, the game progress processing unit 111 provides a second reward to the user when a second condition set for a joint battle is satisfied. The granted second reward is stored in the storage unit 120 in association with the user. The second condition is a condition based on operations that are not based on cooperative battle play.

The second condition includes, for example, that an operation is performed to select the cooperative battle as a target for obtaining a second reward. Further, the second condition includes, for example, that a predetermined period of time has elapsed for a cooperative battle selected as a target for obtaining the second reward among cooperative battles held by the user. Further, the second condition includes, for example, that a condition based on the play of another cooperative battle is satisfied for the cooperative battle selected as a target for obtaining the second reward.

Specifically, the second condition is that the subjugation points accumulated for the event selected as a target for obtaining the second reward reach a threshold value. Hereinafter, selection as a target for obtaining a second reward will also be referred to as "registering as a target for accumulating subjugation points." Further, the threshold value that the subjugation points should reach is also described as the required subjugation point. The required subjugation points are set according to the registered joint battle. Subjugation points are given for the registered cooperative battle, and the given subjugation points are accumulated by being added to the subjugation points that have already been given to the cooperative battle. For example, subjugation points are awarded over time. Further, for example, subjugation points are awarded 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, it executes a process for providing a second reward.

Furthermore, the first reward has a higher value than the second reward in terms of advancing the game advantageously. Here, high value may include more types of rewards. Moreover, high value may include a larger number of rewards. Furthermore, when there is a type of reward with a set rarity level, "high value" may include a reward with a higher rarity level. 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, but the first reward is better than the second reward in terms of the type, number, and rarity of the other items. It may be set high.

Note that the first reward and the second reward definitely include the first item for the user to whom the cooperative battle is given. Further, the first reward may include the first item stochastically for another user who operates another character who participated in the joint battle.

In other words, the user can obtain some kind of reward whether or not he or she plays the cooperative battle, but the user can obtain a more valuable reward if he or she plays the cooperative battle. As a result, the user can enjoy playing the cooperative battles that interest him without obtaining rewards by using only the non-play method for all cooperative battles that he owns.

Here, the first item may be an item for generating an object that can be used in a joint battle. In this embodiment, it is assumed that the first item is an essential item for generating such an object, and can be combined with other items to generate the object. Hereinafter, the first item will also be described as an essential material item. Further, other items are simply referred to as material items. Further, the objects that can be used in joint battles may be, for example, weapons, armor, etc. that can be equipped to the operated character. From now on, objects that can be used in cooperative battles will also be referred to as equipped items. The game progress processing unit 111 generates equipment items by combining essential material items with other material items.

Furthermore, the game progress processing unit 111 changes the equipment items advantageously based on the essential material items. Hereinafter, changing an equipped item to an advantageous state will also be referred to as strengthening the equipped item. The essential material items that can be used to strengthen equipment items are not the essential material items used to generate the equipment item, but other essential material items that have been given to the user and have not yet been used. . For example, the game progress processing unit 111 may convert essential material items into consumable items for strengthening equipment items, and use a predetermined amount of the converted consumable items to strengthen the equipment items. Furthermore, the predetermined amount of consumable items required for reinforcement may be determined depending on the equipped item.

For example, the first reward given when the first condition is satisfied for a certain cooperative battle includes an essential material item having a value according to the rarity of the cooperative battle. The game progress processing unit 111 generates a more valuable equipment item as the value of the essential material item is higher. The higher the value of the equipped item, the greater the predetermined amount of consumable items required to strengthen it.

Furthermore, the higher the value of the essential material item, the more it may be convertible into a consumable item that is more valuable in strengthening 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, when the number of consumable items L required to strengthen a certain equipment item is 20, the number of consumable items H required to strengthen the same equipment item may be five.

Further, a rarity level is set for a cooperative battle given to a user. Details regarding rarity will be described later. The second condition is set depending on the rarity of joint battle. For example, the second condition may be set to have a higher degree of difficulty as the degree of rarity of the joint battle increases. The higher difficulty level of the second condition may mean, for example, that the required subjugation points are higher.

Further, the game progress processing unit 111 completes the cooperative battle when the first condition or the second condition is satisfied. That is, when the enemy character is successfully subjugated in the cooperative battle, or when the subjugation points for the cooperative battle reach a threshold value, the cooperative battle is completed. From now on, the completion of a joint battle is sometimes referred to as the completion of a subjugation.

In other words, the user can complete the subjugation whether or not he/she plays the cooperative battle, but if he/she plays the battle, he or she can obtain a more valuable reward. As a result, users are encouraged to enjoy completing the subjugation by playing the cooperative battles they are interested in, rather than using only the method of completing the subjugation without playing for all the cooperative battles they own. Can be done. Furthermore, it is possible to encourage the user to complete a joint battle in which it is difficult to satisfy the first condition through play, without relying on play. As a result, the user can obtain at least essential material items through play even in cooperative battles in which it is difficult to satisfy the first condition, and can use the essential material items to generate or strengthen equipment items. , you can play the following cooperative battles.

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

As a result, it is possible to reduce the increase in the number of cooperative battles held by the user, and to reduce the user's sense of burden due to the large number of cooperative battles.

Further, after the second condition is satisfied, the game progress processing unit 111 associates the second reward with the user and stores it in the storage unit 120 in response to a user operation instructing to receive the second reward. Good too. In that case, if the user operation is accepted within a predetermined period after the second condition is met, the game progress processing unit 111 associates an additional reward with the user in addition to the second reward. It may also be stored in memory. The additional reward corresponds to an example of the third reward in the present application. Thereby, it is possible to prevent or suppress the user from abandoning a cooperative battle in which the subjugation is completed using a method that does not depend on the play.

The camera placement control unit 113 defines a virtual camera for specifying an area of the game space to be presented to the user. 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. Further, the camera placement control unit 113 instructs the display control unit 114 to create an image depicting the viewing area defined by the virtual camera and the object placed in the viewing area.

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, the camera placement control unit 113 uses the position and orientation of a specific object as a reference, and moves the virtual camera at a certain direction, distance, and angle from the object so that the object is reflected in the center of the viewing area in a specific direction. 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, a building, a tree, a stone, etc. It may be a static object. Here, the dynamic objects in the game space include characters that operate based on the game programs 121 and 221 (for example, non-player characters, enemy characters, etc.) and operated characters that operate based on operations by the user. .

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

The object control unit 115 arranges objects in the game space based on 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 predetermined series of actions.

The lottery control unit 116 determines, from among the plurality of cooperative battles stored in the game information 122, a cooperative battle having a difficulty level according to the ability of the operated character participating in the lottery. Here, the difficulty level is an index indicating 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 the boss character, the number of boss characters to be defeated, and the like. Note that the winning probability is set for each joint 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 more joint battles based on this winning probability. The cooperative 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 operated character.

The point management unit 117 manages subjugation points accumulated for joint battles. For example, the processing for managing subjugation points includes processing for registering a cooperative battle selected by the user among cooperative battles to which the user is granted the right to play, as a target for accumulating subjugation points. Further, the processing for managing subjugation points includes processing for providing subjugation points when granting conditions are met for cooperative battles registered as targets for accumulating subjugation points. Further, the processing for managing subjugation points includes processing for determining whether the cumulative value of subjugation points given has reached a threshold value for cooperative battles registered as targets for accumulating subjugation points.

Here, the higher the rarity of the cooperative battle, the larger the required subjugation points are set, so it takes a longer time to complete the subjugation by accumulating the subjugation points, or requires playing many other cooperative battles. As a result, it is possible to encourage the user to enjoy playing in the cooperative battle space rather than registering the rare cooperative battle as a target for accumulating subjugation points. Furthermore, it is possible to encourage users to register cooperative battles with low rarity as targets for accumulating subjugation points rather than playing them.

On the other hand, it is assumed that the higher the rarity of a joint battle, the higher the difficulty level of the first condition is set. In other words, the higher the rarity of a joint battle, the more difficult it is to defeat 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 subjugate the enemy character through play as a target for accumulating subjugation points. As a result, the user can generate and strengthen equipment items using the essential material items obtained from the second reward related to the highly rare cooperative battle, and can play the next cooperative 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 execute a 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 the progress of the game provided by the game system 1 and an example of transition of the game space.

The control unit 110 changes 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 joint 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. has been done.

The preparation space is a game space where enemy characters do not appear. The preparation space is a game space for allowing the user to prepare for a quest. When the user performs an input operation indicating an instruction to start a quest while the control unit 110 is progressing the game in the preparation space, the control unit 110 causes the game space to transition from the preparation space to the battle space (transition t1).

The preparation space is also a game space in which an operation for acquiring the right to play a joint battle by the operating character is accepted. When the input operation reception unit 112 receives an input operation from a user requesting to participate in the lottery while the control unit 110 is progressing the game in the preparation space, the control unit 110 selects a lottery entry from the preparation space. You may also make the transition to a lottery space which is a game space.

The control unit 110 may cause the player to receive a reward that is given when the player successfully clears a quest or a cooperative battle in the preparation space. When the input operation reception unit 112 receives a predetermined input operation such as a map movement 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 cooperative battle, the control unit 110 may transition the game space from the preparation space to the cooperative battle space (transition t3).

The battle space is a game space where the playable character and the enemy character encounter and fight. The battle between the operated character and the enemy character will be described in detail later.

When the server 200 receives information from the synchronization processing unit 214 or the user terminal 100 and determines that a predetermined condition is satisfied, the server 200 transfers the game space from the battle space to the cooperative battle to the user terminal 100 that satisfies the condition. 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 collaborative battle space (transition t2). The predetermined condition for transitioning from the battle space to the collaborative battle space may be, for example, that a condition for the appearance of a specific enemy character (for example, a boss character) is satisfied.

The cooperative battle space is a battle space where battles compatible with the multiplayer function are conducted. The cooperative battle space is a game space in which one or more playable characters and non-player characters fight against a specific enemy character (for example, a boss character). Hereinafter, one or more playable characters and non-player characters placed as objects in the same cooperative battle space will be collectively referred to as "ally characters." When an ally character loses or wins 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 participated in the joint battle can earn a specific reward. This specific reward includes at least one of an equipment item that the operating character is equipped with, a material item for acquiring the equipment item, and a strengthening item for strengthening the equipment item. For example, a specific reward is given to each operated character that participates in a joint battle in the preparation space.

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

In this embodiment, if the number of operated characters is less than four when the transition to the cooperative battle space occurs, the object control unit 115 arranges the non-player characters so that the number of ally characters is four in total. That is, if the number of user-operated characters participating in a cooperative battle in the cooperative battle space is less than a predetermined number (for example, four), the object control unit 115 replaces the missing characters with non-player characters that operate based on the game program. Make up for it.

The cooperative battle space may be the same game space as the battle space. In other words, the control unit 110 does not transition the game space from the battle space to the cooperative battle space, but changes the camera work of the virtual camera and the UI display in the battle space to the camera work and UI display of the cooperative battle space. By changing it, a collaborative 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 cooperative 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 determines that the boss character has been successfully defeated. When the control unit 110 receives a predetermined movement operation such as map movement while the game is progressing in the collaborative battle space, the control unit 110 may transition the game space from the collaborative battle space to the preparation space or the battle space.

In this embodiment, each user terminal 100 cooperates with the server 200 to perform game processing to support the multiplayer function. In the game space defined by the control unit 110 of the user terminal 100, a playable character corresponding to an account logged in from that user terminal 100 and a playable character corresponding to an account logged in from another user terminal 100 can be arranged. Hereinafter, some processing examples related to the transition of the game space will be specifically explained with reference to FIGS. 1 to 3.

The object control unit 115 arranges various objects including the playable character in the game space defined by the control unit 110. When the user performs an input operation, the object control unit 115 moves the operated character as needed in accordance with the input operation. Thereby, the control unit 110 can allow the user to explore the game space via the playable character.

When transmitting an instruction to each user terminal 100 to transition the game space to a cooperative battle space, the server 200 collects one or more playable characters and non-player characters into a group to fight against enemy characters based on predetermined conditions. Good too. For example, the server 200 may group four playable characters in descending order of level as a group to fight 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 cooperative battle space.

The server processing unit 212 determines whether a predetermined condition for transitioning from a battle space to a joint battle space is satisfied. For example, the server processing unit 212 may determine whether 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 where the playable character is placed, the position of the playable character in the battle space, and the information when the control unit 110 of the user terminal 100 transitions the game space to the battle space. This includes the elapsed time since then.

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

The synchronization processing unit 214 may limit the maximum number of user terminals 100 to be transitioned to the same cooperative battle space, that is, the maximum number of ally characters in the cooperative 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 instructions from the server 200 and the game information 122, and arranges the playable characters in the cooperative battle space according to the maximum number of ally characters. If the number of ally characters is less than the maximum number when transitioning to the cooperative battle space, the object control unit 115 may arrange as many non-player characters as the number that is short of the maximum number.

(Battle between the operating character and enemy character)
Combat in the battlespace and cooperative battlespace will be explained in detail. In the "battle" in the game according to the present embodiment, the user's and other user's operated characters and enemy characters perform attack actions against each other. Note that various processes and displays related to battle are the same for battles with enemy characters in the battle space and battles with boss characters in the cooperative battle space, so the battles with enemy characters will be described below.

Values of various parameters (for example, attack power, defense power, etc.) including at least a physical strength value are set for the playable character and the enemy character. The parameter settings of the playable character are included in the user information 123, and the parameter settings of the enemy character are included in the game information 122.

In the battle space, the object control unit 115 causes the playable character corresponding to the account of the user terminal 100 used by the user to perform an attack action in response to the input operation received by the input operation reception unit 112. Then, the game progress processing unit 111 determines whether the attack of the character operated by the user hits any enemy character, that is, whether the attack is successful. Furthermore, when the game progress processing unit 111 determines that the attack of the character operated by the user is successful, it calculates the damage value inflicted on the enemy character targeted for attack. Further, 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 unit 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 also determines the success or failure of the attack movement by the enemy character in the same way as the attack movement of the playable character, and also calculates the damage value if the attack against the playable character is successful.

When the physical strength value of the playable character becomes 0 or less, or when the total damage to the playable character exceeds the physical strength value of the playable character, the game progress processing unit 111 determines that the playable 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 depicting the preparation space. State (A) in FIG. 5 shows an example of the display screen of the preparation space. State (B) in FIG. 5 shows an example of a display screen when a window W1 including a quest list L1 is displayed in the preparation space. State (C) in FIG. 5 includes a list L2 of preparation joint battles.

In state (A) of FIG. 6, in addition to the background of the preparation space, the user's playable character x and the other users' playable characters y1 and y2 are displayed. Furthermore, in state (A) of FIG. 6, 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 accept a predetermined input operation that starts a transition t1 from the preparation space to the battle space and a transition t3 from the preparation space to the joint battle space. In the example shown in FIG. 6A, an object z3 indicating an entrance to the lottery space is provided. Object z3 accepts a predetermined input operation that starts transition from the preparation space to the lottery space.

The object control unit 115 arranges the playable character x corresponding to the account logged into the user terminal 100 in the preparation space. The object control unit 115 arranges the playable characters y1 and y2 of the other user terminals 100 in the preparation space. Further, the object control unit 115 arranges 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 for instructing the selection and start of a quest, and the selection and start of a joint battle. The object z3 is an object that accepts an input operation for making the operated character participate in a lottery for acquiring the right to play a joint battle.

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 at a position and orientation such that the operated character x is reflected slightly below the center of the field of view and is viewed diagonally from above the rear (back surface) of the operated character x. 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 in the changed position and orientation. Furthermore, the camera placement control unit 113 changes the position and orientation of the virtual camera to a position and orientation corresponding to the changed position of the playable character x. Then, the display control unit 114 draws the preparation space and the playable character x within the field of view of the virtual camera, which is placed at the changed position and in the changed orientation. The same applies to the positions and orientations of the playable characters y1 and y2 that move according to operations by other users.

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

In this manner, the display control unit 114 may create an image in which a UI for user input operations is superimposed on an image depicting the preparation space and objects in the preparation space described above. 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 images of the preparation space and the various objects described above, as shown in FIG. Button B1 is a button for accepting game settings and notification display instructions from the user, and button B2 is a button for accepting map movement, equipment changes, etc. from the user.

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 that includes a list L1 of quests that can be selected by the user. The quests included in the list L1 are quests that the user is given the right to play. The display control unit 114 creates an image in which the window W1 is superimposed on the image of the preparation space and the object, and causes the display unit 152 to display the image, as shown in state (B) of FIG. In the example shown in state (B) of FIG. 5, the list L1 of the window W1 includes three quests. For each quest, the name of the quest (such as "Defeating Monster AA"), achievement conditions (such as "Monster AA: 0/3"), map name (such as "Grassland 1"), and reward (such as "Reward: Copperplate ” etc.) are listed. 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 conditions 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 specific enemy characters, or the like.

The map name indicates the name of the battle space or collaborative battle space to which the quest is selected. Rewards refer to goods, functions, information, etc. that are given to the user's operated character or account upon completion of the quest and that enable the game to progress more advantageously. For example, the reward may be in-game currency, items, equipment that improves the abilities of the operated character, skills of the operated 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 cooperative battles that the user can play. The cooperative battles included in the list L2 are registered in the game information 122 in association with the playable character x as cooperative battles determined by the lottery control unit 116. In other words, the cooperative battles included in the list L2 are cooperative battles for which the user who operates the operating character x is given the right to play. In the example shown in state (C) of FIG. 5, the list L2 includes four quests of joint battles 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 level of the joint battle (such as "Difficulty level: m1") are recorded. ing. Note that the display of the contents of each joint battle in the list L2 is an example, and is not limited to the description in the figure.

Here, the cooperative battles J1 to J4 are cooperative battles in which the operated character participates in a lottery and wins in the lottery. This collaborative 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 playable character x participating in the lottery. The level of the boss character may be, for example, a level included in a predetermined range that includes the current level of the playable character x. The predetermined range may be, for example, a range of "the level value of the current playable character x"±"a predetermined value". In the example shown in FIG. 5C, the lottery control unit 116 controls the level Lv. For 40 operating characters x, level Lv. A joint battle including a battle with a boss character whose level is in the range of 30 to 50 has been decided.

Each boss character that fights in a joint battle has a winning probability set in a lottery. That is, some boss characters have a high probability of winning, while others have a low probability of winning. In the example shown in state (C) of FIG. 5, in addition to information regarding the boss character to compete in each joint battle, a display R indicating the high or low probability of winning in the lottery is displayed. Display R displays information indicating the probability of winning. As information indicating the winning probability in stages, expressions such as D, C, B, A, S, SS, etc. may be used in descending order of winning probability.

In the example shown in state (C) of FIG. 5, the cooperative battle J3 is at level Lv. This is a joint battle including a battle with 44 boss characters K3, and the joint battle J4 is a battle with a boss character K3 of level Lv. This is a joint battle including a battle with 16 boss characters K3. Joint battle J4 is Lv. I won it in a lottery I participated in when I was 18 years old, and the joint battle J3 was Lv. I won it in a lottery I entered when I was 40 years old.

(Specific example of battle space)
FIG. 6 shows an example of a display screen depicting a battle space. State (A) in FIG. 6 shows a display screen when the display section 152 is oriented vertically, and state (B) in FIG. 6 shows a display screen when the display section 152 is oriented horizontally. Note that the display screen when the display section 152 is oriented vertically is referred to as a vertical screen, and the display screen when the display section 152 is oriented horizontally is referred to as 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", the total physical strength value "327", and the physical strength value 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, similarly to the preparation space. However, the camera placement control unit 113 defines virtual cameras that have different viewing areas for the vertical screen and the horizontal screen. For example, the camera placement control unit 113 may make the viewing area of the virtual camera on the vertical screen longer than the viewing area of the virtual camera on the horizontal screen. When the operated character corresponding to another account is placed in a battle space with the same map name as the own terminal, or is later placed in a battle space with the same map name, the object control unit 115 controls the operation of the other account in the battle space. The playable character y3 corresponding to is placed synchronously.

The object control unit 115 arranges one or more enemy characters e1 that can be fought by the user and the other user's operated characters in the battle space. The display control unit 114 may display a target marker t1 that indicates which enemy character the operated character is attacking, superimposed on the enemy character. Then, when the user's operated character defeats an 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 receiving an instruction from the user to move to another battle space.

When the input operation reception unit 112 receives a predetermined operation while the game is progressing in the battle space, the display control unit 114 displays the input operation at the position on the touch screen 15 where the predetermined operation was input. Display an object to indicate what has been done. The predetermined operations include a drag operation for moving the playable character x (hereinafter referred to as a "movement operation") and a tap operation for causing the playable character x to perform an attack action (hereinafter referred to as an "attack operation"). ) etc. The input operation reception unit 112 can receive movement operations and attack operations at any position on the touch screen 15. Thereby, it is possible to avoid obstructing the visual recognition of the operated character x and the enemy character due to the pointing object such as the user's finger.

The display control unit 114 may display an object indicating the direction of the movement operation on the touch screen 15 when the input operation reception unit 112 receives the movement operation. In state (A) of FIG. 6, the display control unit 114 displays an elastic object w1 centered at the position p1. The position p1 is a position where the input operation reception unit 112 has received a touch-on operation. The touch-on operation is an operation in which an indicator is brought 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.

Here, when the user performs a movement operation to move the indicator from position p1 to position p2, the input operation reception unit 112 detects that the indicator 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 that has been deformed so as to stretch the elastic object w1 to a 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 a drag operation, the object control unit 115 moves the operated character x in the dragged direction according to the time or distance of the drag. When the input operation receiving unit 112 accepts the tap operation, the object control unit 115 causes the operated 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 UI for user input operations, are displayed.

In this manner, the display control unit 114 may draw a UI for user input operations superimposed on the above-described image depicting the battle space and objects in the battle space. Button B3 is a special attack button for instructing the operated character x to perform a special attack. Button B4 is a "recovery button" and is used to instruct the operating character x to recover its physical strength. Button B5 is a "chat button" and is used to chat between accounts corresponding to playable characters placed in the same battle space. Button B6 is a "weapon switching button" and is used to switch the weapon equipped by the operating character x.

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

Note that the display control unit 114 can draw the various display objects (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. It is desirable for the display control unit 114 to draw various display objects related to the UI on the periphery of the display screen of the display unit 152 so as not to interfere with inputting instructions for movement, attack, recovery, etc. of the operated character. It is desirable that the display control unit 114 change the drawing positions of various display objects related to the UI described above between the vertical screen and the horizontal screen.

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

In the cooperative 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 placement control unit 113 places the virtual camera at an angle such that the boss character K1 is reflected in the center of the field of view and the playable character x is also reflected. When the position of the boss character K1 or the playable character x changes, the camera placement control unit 113 changes the position and orientation of the virtual camera to a position and orientation corresponding to the changed positions of the boss character K1 and the playable 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. 7, the object control unit 115 displays the playable characters g1 and g2 corresponding to another account and the non-player character y6 as ally characters that fight with the playable character x against the boss character K1. In FIG. 7, 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 has been shown in which the respective users who operate the operating characters x, g1, and g2 participate in the same cooperative battle, but the present invention is not limited to this. All ally characters other than the playable character x may be non-player characters.

In the cooperative battle space, when the virtual camera is arranged at an angle such that the boss character K1 is reflected in the center of the field of view and the operated character x is reflected, the operation for moving the operated character x may be different from that in the battle space. For example, the upward movement operation may be an operation that causes the playable character x to move forward toward the boss character K1, and the downward movement operation may be an operation that causes the playable character x to retreat from the boss character K1.

If an ally character lowers the predetermined physical strength value of the boss character K1 to 0 or less, or inflicts damage that exceeds the physical strength value of the boss character K1, the game progress processing unit 111 determines that the subjugation of the boss character K1 has been completed. do. Note that when the game progress processing unit 111 determines that the boss character K1 has been subjugated, the game progress processing unit 111 may provide the operated character or the account corresponding to the operated character with a special reward different from that for a normal enemy character. In this case, the rewards may be different between the playable characters that participate in the battle.

The display control unit 114 may also draw a UI for user input operations in the image of the collaborative battle space displayed on the display unit 152, similarly to the image of the battle space shown in FIG. The display control unit 114 may display a message according to the actions of the ally character or the boss character. For example, the display control unit 114 determines that the game progress processing unit 111 has determined that the operated character has successfully attacked the boss character's weak point, or that the ally operated character or non-player character has become unable to fight. In this case, a message may be displayed to notify that fact. Alternatively, when the game progress processing section 111 determines that the boss character is in a special state such as being unable to take action, the display control section 114 may display a message notifying the boss character to that effect.

Note that the display control unit 114 draws the various display objects (buttons, menus, and messages) related to the UI described above so that they are located 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 do so. The display control unit 114 displays various display items related to the UI, such as inputting instructions for movement, attack, recovery, etc. of the operated character, as well as displaying the positions of ally characters, attack movements 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 battle with the character. It is desirable that the display control unit 114 also change the drawing positions of various display objects related to the UI described above depending on the orientation of the display unit 152.

(Participate in the lottery to obtain the right to play joint battles)
FIG. 8 is an example of a display screen for explaining operation input for participating in a lottery and acquiring the right to play a joint battle. State (A) in FIG. 8 is an example of a display screen that is displayed when an input operation for wishing to participate in the lottery is performed. State (B) in FIG. 8 is an example of a display screen that is displayed when a certain cooperative battle is won by lottery. State (C) in FIG. 8 is an example of a display screen in which a joint battle drawn in a lottery is added to a list of joint battles that the user has the right to play.

When the input operation reception unit 112 receives an input operation for wishing to participate in the lottery, it instructs the display control unit 114 to display the display screen shown in state (A) of FIG. 8 on the display unit 152. The display control unit 114 may display images of menu M5, menu M6, display R, button B6, and button B7 as shown in FIG.

Menu M5 in state (A) of FIG. 8 shows the number of items currently owned by the user. Menu M6 indicates the number of items to be consumed each time a player participates in a lottery.

In the example shown in state (A) of FIG. 8, a boss character K5 that can be drawn by lottery is further displayed, although the probability of winning is low. Note that instead of the boss character K5, a boss character with the same or lower probability of winning may be displayed. In this way, the attractiveness of participating in the lottery may be shown by showing the appearance of the boss character fighting in a joint battle where the probability of winning is low. In the example shown in state (A) of FIG. 8, "S" indicating the winning probability of the boss character K5 is displayed on the display R. In the example shown in state (A) of FIG. 8, button B6 is used to transition to a page that introduces items that can be obtained when the game is successfully cleared in a cooperative battle including a battle with boss character K5. Button B7 is for accepting an instruction to start a lottery.

When the input operation reception unit 112 receives an input operation to the button B7, the lottery control unit 116 determines a joint battle from among the plurality of joint battles according to the level of the operated character participating in the lottery.

The display control unit 114 displays displays D1, D2, D3, D4, etc., as shown in state (B) of FIG. Displays D1 to D4 display information regarding the boss character K6 that will fight in the joint battle determined by the lottery control unit 116. In the example shown in state (B) of FIG. 8, display D1 shows the winning probability of boss character K6, display D2 shows the level of boss character K6 "Lv.42", and display D3 shows the name of boss character K6 "Monster K6". ", and the figure of the boss character K6 is displayed on the display D4.

In the example shown in state (B) of FIG. 8, buttons B9 and B10, which are UI for user input operations, are displayed. Button B9 accepts an input operation by the user to return to the display screen displaying the preparation space shown in state (A) of FIG. Button B10 accepts an input operation by the user to immediately start a joint battle for which the player has acquired the right to play in the lottery.

The joint battle including the battle with the boss character K6 assigned by the user is registered in the user information 123 by the game progress processing section 111. As shown in state (C) of FIG. 8, the registered cooperative battle is displayed in the list L2 as a cooperative battle J5 that can accept the user's input operation for starting the cooperative battle.

In addition, the game progress processing unit 111 provides the following information to users who have won the right to play cooperative battle J5 (rare event) whose winning probability is lower than a predetermined winning probability (for example, "S" and "SS"). The right to play cooperative battles J6 to J7 related to the won cooperative battle may be granted. In this case, the difficulty level of the joint battle related to the winning joint battle may be higher than the difficulty level of the winning joint battle. Note that the number of cooperative battles related to cooperative battle J5 that is granted to the user who has won the right to play cooperative battle J5 may be one or multiple.

For example, as shown in state (C) of FIG. 8, a user who has won the right to play cooperative battle J5 that includes a battle with boss character K6 with a winning probability of You are also granted the right to play two joint battles J6 to J8. The difficulty levels m6 to m8 of cooperative battles J6 to J8 related to the winning cooperative battle J5 are higher than the difficulty level m6 of the winning cooperative battle. For example, the game progress processing unit 111 may provide the operating character with an equipment item to be equipped by the operating character and a material item for acquiring the equipment item as a reward for successfully clearing the game of cooperative battle J5. On the other hand, the reward for successfully clearing the game of cooperative battles J6 to J7 may be a reinforcement item for strengthening the equipment item acquired when the game of cooperative battle J5 is successfully cleared. By setting rewards in this way, it is possible to appropriately increase the appeal of cooperative battles, provide rational motivation for further challenging cooperative battles related to cooperative battles, and improve the interest of the game. Can be done.

(Start of joint battle)
FIG. 9 is an example of a display screen for explaining operation input by the user to start a joint battle. Here, an example will be described in which a user who operates the playable character x starts a joint battle in a joint battle space together with a user who operates the playable character g1 and a user who operates the playable character g2.

When the user performs an input operation to start a joint battle in the preparation space, a screen as shown in FIG. 9 is displayed on the user terminal 100 used by the user.

In joint battles, characters operated by other accounts can also participate as ally characters. The input operation for instructing to start a joint battle may be, for example, an operation for selecting the aforementioned non-player character z2. 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 a list L2 including cooperative battles J1, J2, J3, J4, etc. that can be selected by the user. (See state (C) in FIG. 5). The cooperative battles included in the list L2 are cooperative battles for which the user is given the right to play.

In state (C) of FIG. 5, if the user desires to start the joint battle J1, the user may select the joint battle J1. When cooperative battle J1 is selected, the control unit 110 changes the display screen shown in state (C) of FIG. 5 to the display screen shown in FIG. 9. For example, the input operation accepting unit 112 accepts a touch operation for selecting cooperative battle J1. The touch operation for selecting a cooperative battle may be a touch operation on a position where each cooperative battle included in the list L2 is displayed.

FIG. 9 is a display screen for making preparations before starting the joint battle J1 and for making other users who wish to participate in this joint battle prepare to participate. In the example shown in FIG. 9, "Monster K1", which is the name of the boss character K1 to be defeated in the joint battle J1, may be displayed in the title T. The identification number "Identification No. P" of this cooperative battle may be displayed on the menu M4.

Note that when recruiting other users who wish to participate in a joint battle, the user may set conditions for allowing participation. The condition for permitting participation may be an upper limit or a lower limit of the ability of the character operated by another user. For example, if the level of the character operated by a user who wishes to participate in a joint battle is lower than a predetermined level, the user may not be allowed to participate. Alternatively, inputting an identification number may be a condition for permitting participation. In this case, participation can be permitted only to users who have been informed in advance of the identification number of this joint battle by the user who starts the joint battle. The conditions for permitting participation input by the user are associated with each joint battle, and are stored in the user information 123 by the game progress processing unit 111.

In the example shown in FIG. 9, an object of the playable character x is displayed in this cooperative battle J1, an object of the playable character g1 of another user is displayed next to it, and an object of the playable character g2 of another user is displayed next to it. is drawn. In the example shown in FIG. 9, both the operated characters g1 and g2 have finished preparing to depart for the joint battle J1, and the words "participate" are superimposed on them. Note that when the playable characters g1 and g2 are not yet ready to start a joint battle, the words "Preparing" may be superimposed on the object of the playable character g1.

In the example shown in FIG. 9, one column next to the playable character g2 is blank. This indicates that even if the playable characters x, g1, and g2 participate, one more playable character can participate.

In the example shown in FIG. 9, buttons B9, B10, and B11, which are UI for user input operations, are further displayed. Button B9 is a "weapon switching button" and is used to switch the weapon equipped by the operating character g1 before participating in the joint battle J1. As shown in FIG. 9, the display control unit 114 recovers the name Q1, level Q2, equipment Q3, total health value Q4, attack and defense ability value Q5 of each operated character, and the other operated characters. It may be configured to display the ability value Q6 or the like. By referring to such a display, the user can participate in a battle after knowing the abilities of the ally character.

Button B10 is an "exit button" and is used to cancel the start of joint battle J1 and return to the display screen shown in state (C) of FIG. 5. When the user performs a touch operation on the button B10, the user can reselect a cooperative battle that he or she wishes to start.

The button B11 is a "departure button" and is used to move the character x to the joint battle space of the joint battle J1. In the example shown in FIG. 9, when the user performs a touch operation on the button B11, in addition to the playable character x, the playable characters g1 and g2 also appear in the joint battle space of the joint battle J1 (see FIG. 7). In this case, as shown in FIG. 7, the number of playable characters that moved to joint battle J1 is three (character x and playable characters g1 and g2), and the last ally character is non-player character y6. be.

(Specific example of reward screen based on play results)
FIG. 10 is a diagram showing an example of a reward screen. This reward screen is displayed by the display control unit 114 when the enemy character has been defeated through play in the cooperative battle space. This reward screen includes information representing the first reward. The first reward to be displayed is determined for the cooperative battle, and is specified by the game progress processing unit 111. The example in FIG. 10 is a screen displayed when the cooperative battle J2 shown in FIG. 5(C) is played in the cooperative battle space and the monster K2 is subjugated. The first reward displayed on the reward screen includes acquired experience value A1, virtual currency A2, and item reward A3. The acquired experience value A1 represents an increase in the experience value given as a first reward to the operated character who participated in the joint battle. Virtual currency A2 represents the amount of in-game virtual currency given to the user as a first reward. The item reward A3 represents the amount of the essential material item K2 and other items given to the user as a first reward. The essential material item K2 represents an essential material item associated with the monster K2 to be subjugated. Further, other items are consumable items here.

In this example, the first reward definitely includes the essential material item K2, and the other rewards are included stochastically. Specifically, the amount of virtual currency A2 may be an amount drawn based on a lottery probability determined for this joint battle. Further, the items other than the essential material item K2 among the item rewards A3 may be items selected based on a lottery probability from among one or more items of a type determined for this cooperative battle.

(Cooperative battle registered as a target for accumulating subjugation points)
Collaborative battles for which the user is given the right to play can be registered as targets for accumulating subjugation points. The point management unit 117 registers the cooperative battle selected by the user among the cooperative battles for which the user is given the right to play, as a target for accumulating subjugation points. At this time, the number of joint battles that can be subject to accumulation of subjugation points at the same time is up to a predetermined upper limit.

However, this upper limit number increases when additional conditions are met. Further, the upper limit number may be increased only within a predetermined validity period after the additional condition is satisfied. The additional condition may be, for example, exchange for a consumable item such as virtual currency. The consumable item for satisfying the additional condition may be something (for example, virtual currency) that is given to the user by accepting billing processing. In this case, the upper limit may increase as the amount of consumable items to be exchanged increases. Further, the larger the amount of consumable items to be exchanged, the longer the validity period of the increase in the upper limit number may be. Thereby, the user can register the cooperative battles that he or she wants to complete by accumulating subjugation points within the upper limit, and enjoy playing in the cooperative battle space for the remaining cooperative battles that are not registered. Furthermore, if the additional conditions are met and the upper limit is increased, the user can complete subjugation in more collaborative battles while enjoying playing in the collaborative battle space. Further, since the user attempts to accumulate more subjugation points within the validity period during which the upper limit number is increased, it is possible to encourage the user to play other cooperative battles.

(Example of registration screen)
FIG. 11A is an example of a registration screen for registering joint battles as targets for accumulating subjugation points. This registration screen is displayed by the display control unit 114 when the input operation reception unit 112 accepts an operation instructing the display of the screen. In this example of the registration screen, the number of joint battles that can be simultaneously subject to accumulation of subjugation points is managed by registration frames H1 to H5. The registration frame H1 is a frame in which one cooperative battle can be registered without any additional conditions. In other words, the upper limit number of joint battles that can be registered simultaneously without additional conditions is 1 in this example. Furthermore, the registration frame H2 becomes valid when additional conditions are met, and one joint battle can be registered. Further, the registration frame H3 becomes valid when an additional condition is further satisfied while the registration frame H2 is valid, and one joint battle can be registered. Similarly, each of the registration frames H4 to H5 becomes valid when an additional condition is satisfied while the registration frame one above is valid, and one joint battle can be registered for each. In other words, each time the additional conditions are met, the maximum number of joint battles that can be registered at the same time increases by one, up to a maximum of five. Further, the valid period of the registration frame that becomes valid when the additional conditions are satisfied is 24 hours in this example.

FIG. 11(B) is an example of a selection screen for selecting a joint battle to be registered as a target for accumulating subjugation points. This selection screen is displayed by the display control unit 114 when the input operation reception unit 112 accepts an operation for the registration frame H1 in FIG. 11(A). In this example of the selection screen, cooperative battles J2, J3, J5, and J6 for which the user is given play rights are displayed. These joint battles are joint battles in the list L2 shown in Figures 5(C) and 8(C) for which subjugation has not been completed at the time the example screen in Figure 11(B) is displayed. I am assuming that. The display of each joint battle includes information representing the winning probability R (any one of D, C, B, A, S, or SS), the level and name of the enemy character, the required subjugation points, and the time until subjugation. The winning probability display represents the winning probability when the right to play each cooperative battle is given to a user by lottery. In other words, the lower the winning probability of a joint battle, the higher the rarity. Hereinafter, the winning probability R will also be referred to as the rarity R. Note that the higher the rarity R of a joint battle, the higher the difficulty of achieving the first condition. The display of the level and name of the enemy character represents the level and name of the enemy character who will be the opponent in the joint battle. The required subjugation points are values depending on the difficulty of subjugation. The time until subjugation is a value depending on the required subjugation points. Note that the time until subjugation represents the time from registration to completion of subjugation when subjugation points are accumulated only by the passage of time.

FIG. 11C is an example of a detailed screen showing details of a joint battle to be registered as a target for accumulating subjugation points. This detailed screen is displayed by the display control unit 114 when the input operation reception unit 112 accepts an operation for any one of the list of cooperative battles displayed in FIG. 11(B). In this example, since the operation for the cooperative battle J2 has been accepted, a detailed screen regarding the cooperative battle J2 is displayed. This detailed screen includes information A4 regarding the required subjugation points, information A5 regarding the second reward, and a registration button B13.

Information A4 includes information representing the value of required subjugation points determined for this joint battle and the time until subjugation. Information A5 represents the second reward given to the user when the subjugation is completed by the cumulative total of subjugation points reaching the required subjugation points. This second reward has a lower value than the first reward that is given when the subjugation is completed by playing this cooperative battle. As a specific example, it will be compared with the first reward when the subjugation is completed by playing in the cooperative battle space. As shown in FIG. 10, the first reward when the subjugation is completed by playing in the cooperative battle space includes acquired experience points A1, virtual currency A2, and item reward A3. The second reward when the subjugation is completed by accumulating subjugation points includes the item reward A5 and does not include the acquired experience value A1 and the virtual currency A2, as shown in FIG. 11(C). Furthermore, item reward A3 and item reward A5 both include the essential material item K2, but item reward A3 includes 10 consumable items, whereas item reward A5 includes 1 consumable item. Thus, the second reward is less valuable than the first reward.

In FIG. 11C, when the input operation reception unit 112 accepts the operation on the registration button B13, the joint battle is registered in the corresponding registration frame as a target for accumulating subjugation points. Hereinafter, a joint battle registered as a target for accumulating subjugation points will be simply referred to as a joint battle of the registration frame.

In this way, when a user completes a certain cooperative battle by accumulating subjugation points, the user can obtain the same essential material items as when completing the subjugation by playing in the cooperative battle space. However, in this case, the user cannot acquire acquired experience points and virtual currency. In other words, for cooperative battles in which the user wants to obtain experience points and virtual currency, the user may choose to play in the cooperative battle space, and for cooperative battles in which the user only needs to obtain the same required material item reward, the user can accumulate subjugation points. You can choose to register as a target.

Note that, as described above, at least a portion of the second reward may be dynamically determined upon completion of the subjugation. In this case, the display of the item reward A5 in FIG. 11(C) may include information representing the type of item that can be dynamically determined upon completion of the subjugation.

(Conditions for granting subjugation points)
The conditions for granting subjugation points to cooperative battles that are registered as targets for accumulating subjugation points are configured by conditions that are not related to the play of the cooperative battle. In this embodiment, conditions for granting subjugation points include (1) a condition based on the passage of time, and (2) a condition based on completion of subjugation in another joint battle. In other words, for cooperative battles registered as targets for accumulating subjugation points, subjugation points are given at least (1) over time. Furthermore, subjugation points are also awarded when subjugation is completed in other joint battles.

In the case of (1), a predetermined amount of subjugation points are given to a joint battle registered as a subjugation point accumulation target every time a unit of time elapses after registration as a subjugation point accumulation target. For example, 1 pt of subjugation points may be provided every time 6 seconds pass. Note that pt represents the unit of subjugation points. In this case, if the required subjugation points are 1200 pts, even if the condition (2) is not satisfied after registration, the cumulative total of the subjugation points given will reach 1200 pts after a maximum of 2 hours have elapsed. The "time until subjugation" displayed in Figures 11 (B) and (C) indicates that when subjugation points are accumulated only under the conditions of the passage of time, the cumulative total of subjugation points given will reach the required subjugation point. It represents the time until.

In the case of (2), when a cooperative battle that is not registered as a target for accumulating subjugation points is played in the cooperative battle space and the subjugation is completed, subjugation points will be awarded for the cooperative battle that is registered as a target for accumulating subjugation points. Ru. In other words, when the condition (2) is met, the time required for subjugation will be shortened for cooperative battles that are registered as targets for accumulating subjugation points.

At this time, the amount of subjugation points to be given may be set to be larger, for example, as the rarity of other cooperative battles in which subjugation has been completed through play is higher. In addition, there are cases where multiple joint battles are registered as targets for accumulating subjugation points. In this case, subjugation points may be awarded to each cooperative battle in an amount corresponding to the rarity of the cooperative battle in which the subjugation has been completed through play. For example, assume that when a subjugation is completed in a cooperative battle with a rarity level of S, 100 pts are determined as subjugation points to be given. At this time, if one cooperative battle is registered as a target for accumulating subjugation points, 100 pt of subjugation points will be given to the cooperative battle. Furthermore, at this time, if a plurality of joint battles are registered as targets for accumulating subjugation points, 100 pt of subjugation points will be given to each joint battle.

By preparing the above-mentioned (1) and (2) as conditions for granting subjugation points in this way, the user enjoys the following merits. In other words, by registering a cooperative battle that the user has the right to play as a target for accumulating subjugation points, the user can complete the subjugation by waiting for time to pass without playing the cooperative battle in the cooperative battle space. can. Furthermore, the user can shorten the time required to complete the subjugation in the registered cooperative battle by playing another cooperative battle and completing the subjugation.

FIG. 12A is a list screen showing a list of joint battles registered as targets for accumulating subjugation points. This list screen is displayed by the display control unit 114 when the input operation reception unit 112 accepts an operation instructing the display of the screen. In FIG. 12(A), the registration frame H1 includes information regarding a cooperative battle registered without any additional conditions. The registration frame H1 includes a cumulative total of subjugation points awarded A6, an interrupt button B14, and a time A7 until completion of the subjugation. The cumulative total A6 represents the cumulative value of subjugation points and the ratio of the cumulative value to the required subjugation points. In this example, it is shown that a total of 148 pts have been given to the required subjugation points of 600 pts at this point. The time A7 until subjugation is a time corresponding to the remaining 452 pts required to reach the required subjugation points.

In FIG. 12A, when the input operation reception unit 112 accepts the operation on the interrupt button B14, the registration of the cooperative battle as a target for accumulating subjugation points is canceled. In this case, the right to play the unregistered cooperative battle remains granted to the user. After the cancellation, the registration frame H1 becomes empty, and when an operation for the registration frame H1 is accepted again, the cooperative battle selection screen shown in FIG. 11(B) is displayed.

Furthermore, in this specific example, the screen showing the list of joint battles shown in FIG. 12(A) also functions as a registration screen for performing additional registration. When the input operation reception unit 112 accepts the operation for the registration frame H2, a consent screen (not shown) is displayed asking whether the additional conditions are satisfied. In this specific example, the additional condition is "exchange for five consumable items." It is assumed that the consumable items necessary for exchange are stored in the storage unit 120 in association with the user. Here, the consumable item required for exchange may be the same type of consumable item as the consumable item that can be included in the first reward or the second reward and given to the user, or it may be a different type of consumable item. It's okay. In addition, if an operation to agree to meet the additional conditions is accepted on the consent screen, five consumable items will be consumed and the cooperative battle selection screen as shown in Figure 11(B) will be selected. be done. Thereafter, when an operation on the registration button B13 is accepted on the cooperative battle details screen as shown in FIG. 11(C), the cooperative battle is registered in the registration frame H2.

FIG. 12(B) is an example of a screen where a joint battle is registered for the registration frame H2. The registration frame H2 includes information regarding cooperative battles registered by satisfying additional conditions. Like the registration frame H1, the registration frame H2 includes a total of subjugation points A6, an interrupt button B14, and a time A7 until completion of the subjugation. Furthermore, the registration frame H2 includes an indication of the validity period A10. This validity period A10 represents the remaining time of the validity period after the registration frame H2 becomes valid by satisfying the additional conditions. If the subjugation points for a cooperative battle registered in registration frame H2 have not reached the required subjugation points at the time of the expiry of the validity period, that cooperative battle will be canceled from registration frame H2 as the subjugation has not been completed. Ru. In this case, the right to play the unregistered cooperative battle remains granted to the user. Additionally, if the cooperative battle is canceled from the registration frame H2 by operating the interrupt button B14, a new cooperative battle will be registered for the registration frame H2 before the expiry of the registration frame H2. Is possible.

Further, the screen showing the list of joint battles shown in FIG. 12(B) also functions as a registration screen for performing additional registration. In FIG. 12(B), the process when the operation on the registration frame H3 is accepted is the same as the process when the operation on the registration frame H2 is accepted in FIG. 12(A), so a detailed explanation will be provided. Do not repeat.

FIG. 12(C) is an example of a screen displaying a joint battle in which subjugation has been completed due to accumulation of subjugation points. In FIG. 12(C), the cumulative total of subjugation points for cooperative battles registered in the registration frame H1 has reached the required subjugation points of 600 pt. The registration frame H1 includes information A8, elapsed time A9, and a button B15 for receiving the second reward. Information A8 indicates that the subjugation has been completed. The elapsed time A9 represents the time elapsed since the cumulative total of subjugation points reached the required subjugation points. The second reward receiving button B15 is a button that accepts an operation for receiving the second reward for this cooperative battle.

(Specific example of reward screen based on subjugation points)
FIG. 13 is an example of a reward screen that is displayed when the subjugation points reach the required subjugation points. This reward screen is displayed by the display control unit 114 when the input operation reception unit 112 receives an operation on the second reward receiving button B15 in FIG. 12(C).

This reward screen includes an item reward A12 that is a second reward, an additional reward A11, and a receive button B16. The item reward A12 is displayed in the same way as the item reward A5 that was displayed before registering this cooperative battle in FIG. 11(C). However, as mentioned above, if the item reward A5 includes a dynamically determined reward, the contents of the item reward A12 in FIG. including those determined by

The additional reward A11 is displayed when the button B15 for receiving the reward is operated before the elapsed time A9 in FIG. 12(C) reaches a predetermined period. That is, if the user performs an operation to receive the second reward within a predetermined period after the subjugation is completed by accumulating the subjugation points, an additional reward is given to the user. If the operation to receive the second reward is performed after the predetermined period has elapsed, a reward screen from which the display of the additional reward A11 is removed from the reward screen of FIG. 13 is displayed.

(Giving parameters to improve grades)
Here, the first reward given when the subjugation is completed by playing in the cooperative battle space may include a performance parameter that increases the user's performance. In this case, the second reward given when the subjugation is completed by accumulating subjugation points also includes the same performance parameter. The user's score is the user's score in the tasks set in the game. In addition, such challenges include, for example, when a user completes a subjugation in a joint battle during a predetermined event period, points (performance parameters) are given to the user according to the difficulty level, and results based on the total points are shared between users. It may be something that you compete against.

In this case, for a certain cooperative battle, the points awarded when the subjugation is completed through play may be the same as the points awarded when the subjugation is completed due to accumulation of subjugation points. Thereby, it is possible to increase the user's motivation to complete subjugation in more cooperative battles by utilizing both the play in the cooperative battle space and the accumulation of subjugation points.

<Processing flow and screen example>
The flow of processing executed by the user terminal 100 based on the game program 131 will be explained using the flowcharts of FIGS. 14 to 16. Note that in the following description, a series of processing steps explained using a flowchart are described as being executed by the user terminal 100, but at least some of these processing steps may be executed by the server 200. may be done.

(Process flow for registering joint battles for which subjugation points are to be accumulated)
FIG. 14 is a flowchart showing the flow of operations of the user terminal 100 that registers a joint battle as a target for accumulating subjugation points.

In step S101, the display control unit 114 displays a screen for registering targets for accumulating subjugation points in response to user operations. The displayed registration screen is, for example, the screen shown in FIG. 11(A), FIG. 12(A) to (C), etc.

In step S102, the input operation accepting unit 112 accepts an operation for the registration frame. For example, an operation is accepted for the registration frame H1 in FIG. 11(A), the registration frame H2 in FIG. 12(A), and the registration frame H3 in FIGS. 12(B) and (C).

In step S103, the point management unit 117 determines whether the registration frame for which the operation has been accepted is valid. In other words, the point management unit 117 determines whether it is necessary to satisfy additional conditions for registration in the registration frame. In this embodiment, satisfying the additional condition means exchanging for a consumable item. The registration slot H1 is always determined to be valid. Registration slots H2 to H5 are determined to be invalid if they have never been exchanged for a consumable item. Further, the registration slots H2 to H5 are determined to be invalid if the validity period has passed since they were last exchanged with a consumable item. Furthermore, the registration slots H2 to H5 are determined to be valid if they are within the valid period since they were last exchanged with a consumable item. Note that in this embodiment, it is assumed that operations for registration slots in which joint battles have already been registered will not be accepted. In other words, the registration frame for which the operation was accepted in step S102 is empty.

If the registration frame is valid, step S106, which will be described later, is executed. If the registration frame is not valid, step S104 is executed.

In step S104, the point management unit 117 exchanges the registration frame for a consumable item in order to make the registration frame valid. At this time, the point management unit 117 may display a confirmation screen asking whether or not to accept the exchange with the consumable item, and if the operation to accept is accepted, the process of this step may be executed. If an operation that is not approved is accepted, the process ends.

In step S105, the point management unit 117 validates the registration frame and starts counting the validity period.

In step S106, the point management unit 117 extracts registrable cooperative battles for the registration frame for which the operation has been accepted. The extracted cooperative battle is a cooperative battle that the user has been given the right to play at this point. Then, the display control unit 114 displays a list screen of the extracted joint battles. The displayed list screen is, for example, the screen shown in FIG. 11(B).

In step S107, the input operation accepting unit 112 accepts an operation for selecting a joint battle from the list screen.

In step S108, the point management unit 117 generates a detailed screen for the selected joint battle, and causes the display control unit 114 to display it. The detailed screen displayed is, for example, the screen shown in FIG. 11(C).

In step S109, the input operation accepting unit 112 accepts an operation for registering the selected joint battle.

In step S110, the point management unit 117 registers the joint battle in the registration frame as a target for accumulating subjugation points.

(Flow of processing to complete subjugation by playing cooperative battle)
FIG. 15 is a flowchart illustrating the flow of operations of the user terminal 100 that completes subjugation by playing a joint battle. The process described below is executed for each joint battle that is not registered as a target for accumulating subjugation points.

In step S201, the game progress processing unit 111 determines whether or not the play of the cooperative battle has ended. If not completed, the process of step S201 is repeated. If finished, the process of step S202 is executed.

In step S202, the game progress processing unit 111 determines whether the enemy character has been defeated through play. If not defeated, the action ends. When defeated, step S203 is executed.

In step S203, the game progress processing unit 111 completes the subjugation by accumulating subjugation points for the joint battle of the registration frame. Further, the game progress processing unit 111 deletes the cooperative battle from the cooperative battles held by the user.

In step S204, the game progress processing unit 111 gives a first reward to the cooperative battle in which the subjugation is completed. The first reward is determined to be given when subjugation is completed through play in this cooperative battle, and includes essential material items corresponding to the cooperative battle.

(Flow of processing to complete subjugation by accumulating subjugation points)
FIG. 16 is a flowchart illustrating the flow of operations of the user terminal 100 that completes a subjugation by accumulating subjugation points. The process described below is executed for each joint battle registered as a target for accumulating subjugation points.

In step S301, the point management unit 117 determines whether or not the registration slot is within its validity period regarding the joint battle for the registration slot. For example, in FIG. 12(A), no valid period is set for the registration frame H1. Therefore, the point management unit 117 always determines that the cooperative battle registered in the registration slot H1 is within its validity period. Further, for example, in FIG. 12(B), the registration frame H2 is set to have a valid period of 24 hours. Then, the point management unit 117 counts the time that has passed since the time when the joint battle was registered in this registration frame H2. Therefore, the point management unit 117 determines whether or not the elapsed time has exceeded 24 hours for the joint battle registered in the registration slot H2. If it is not within the validity period, step S210 is executed. The process of step S210 will be described later. If it is within the validity period, step S302 is executed.

In step S302, the point management unit 117 determines whether conditions for granting subjugation points are satisfied for the registered joint battle. In the present embodiment, the granting conditions include conditions based on the passage of time or conditions based on the completion of subjugation in other joint battles. Therefore, the point management unit 117 determines that the granting conditions are satisfied for this registered joint battle if a unit time has elapsed since the previous unit time was granted after the subjugation point was granted. Further, the point management unit 117 determines that the granting condition is satisfied even when the subjugation is completed by playing another cooperative battle. If the granting conditions are not met, the processing from step S301 is repeated. If the granting conditions are met, step S303 is executed.

In step S303, the point management unit 117 grants subjugation points according to the granting conditions to the joint battle of the registration frame. In this embodiment, the point management unit 117 gives 1 pt of subjugation point to the joint battle of the registration frame when the unit time has passed. Further, when the subjugation is completed by playing another cooperative battle, the point management unit 117 gives subjugation points corresponding to the difficulty level of the other cooperative battle to the cooperative battle of the registered frame.

In step S304, the point management unit 117 determines whether the cumulative total of subjugation points given to the cooperative battles being registered is equal to or greater than the required subjugation points. Here, if the cumulative total of subjugation points is not equal to or greater than the required subjugation points, the processing from step S301 is repeated. If the cumulative total of subjugation points is equal to or greater than the required subjugation points, step S305 is executed.

In step S305, the game progress processing unit 111 completes the subjugation by accumulating subjugation points for the joint battle of the registration frame. Further, the game progress processing unit 111 deletes the cooperative battle from the cooperative battles held by the user. If the screen displayed at this point is a list of registration frames as shown in FIGS. 12(A) and 12(B), the display control unit 114 may All you have to do is display that the subjugation has been completed in the registration frame of the joint battle that has been completed. Additionally, if the screen being displayed at this point is the preparation space, battle space, or joint battle space, the display control unit 114 displays the message “Suppression is completed due to accumulation of subjugation points” on the screen currently displayed at this point. A UI object that instructs the display of collaborative battles may be displayed. In this case, when the input operation reception unit 112 accepts the operation for the UI object, the display control unit 114 displays a list of registered frames including registered frames for which subjugation has been completed, as shown in FIG. 12(C). should be displayed.

In step S306, the point management unit 117 determines whether the input operation reception unit 112 has accepted an operation for receiving a reward for the cooperative battle in which the subjugation has been completed by accumulating the subjugation points. If the operation for receiving the reward has not been accepted, the process of this step is repeated. If the operation for receiving the reward is accepted, step S307 is executed.

In step S307, the point management unit 117 determines whether the operation for receiving the reward has been performed within a predetermined period from the time when the subjugation points become equal to or greater than the required subjugation points. If it has been performed within the predetermined period, step S308 is executed. If the process is performed after the predetermined period has elapsed, step S309 is executed.

In step S308, the point management unit 117 grants the second reward and additional reward to the user. The second reward is a mandatory reward included in the first reward, although it is lower in value than the first reward, which is determined to be given when the subjugation is completed by play for the cooperative battle of this registration frame. Contains material items.

In step S309, the point management unit 117 grants the second reward to the user. In this case, no additional rewards will be given.

In step S310, the point management unit 117 cancels the joint battle for this registration frame from the registration frame. This step is also executed when it is determined in step S301 that the validity period has passed.

In this way, in this embodiment, for cooperative battles that the user is given the right to play, it is possible not only to earn rewards by playing in the cooperative battle space, but also to register in the registration frame and earn subjugation points. It is possible to earn rewards by accumulating them. As a result, the user can focus on playing cooperative battles that are more interesting, such as highly rare cooperative battles, while also gaining subjugation points from other cooperative battles, such as less rare cooperative battles, without having to play. You can earn rewards by accumulating. As a result, the present embodiment can support the user's progress in the game.

Furthermore, in this embodiment, for cooperative battles for which the user is given the right to play, it is possible to not only complete the subjugation by playing, but also to complete the subjugation by registering in the registration frame and accumulating subjugation points. possible. As a result, users can complete cooperative battles that are difficult to complete by playing, by accumulating subjugation points without playing, and can strengthen equipment items based on the second reward obtained. , you can play the following cooperative battles. As a result, even if the user is given a cooperative battle in which it is difficult for the user to complete the subjugation, the user's motivation to continue playing the game can be improved.

[Modified example]
In the present embodiment, an example has been described in which the upper limit number of joint battles that can be simultaneously registered as targets for accumulating subjugation points can be increased to 5 if additional conditions are met.

At this time, the point management unit 117 may vary the amount of subjugation points that are awarded when the granting conditions are met for at least one of the plurality of registration frames. For example, the point management unit 117 may increase the amount of subjugation points given each unit of time for a registration frame that has increased due to exchange with more consumable items, compared to other registration frames. .

Further, the point management unit 117 may vary the second reward that is given when the cumulative total of subjugation points reaches or exceeds the required subjugation points for at least one of the plurality of registration frames. For example, the point management unit 117 sets the lottery probability of the item reward that is dynamically determined upon completion of the subjugation more advantageously for the registration frame that has increased due to the exchange with more consumable items, compared to other registration frames. You may. Setting the lottery probability advantageously may mean setting the winning rate of an item that allows the game to proceed more advantageously to be higher than that of other registration slots.

Furthermore, in the present embodiment, an example has been described in which the first reward is higher in value than the second reward. However, the first reward and the second reward may be of equal value. Alternatively, in the present embodiment, an example has been described in which the essential material item included in the first reward is also included in the second reward. However, the essential material items included in the first reward do not necessarily have to be included in the second reward. In other words, the first reward and the second reward do not need to have overlapping contents. Even in these cases, the user is required to complete cooperative battles in which it is difficult to defeat enemy characters through play by accumulating defeat points, strengthen equipment items based on the second reward, and then move on to the next battle. It can encourage players to play cooperative battles.

Furthermore, in the present embodiment, an example has been described in which the association with the user is canceled in the storage unit 120 for a joint battle in which subjugation has been completed. Not limited to this, in the present embodiment, the game progress processing unit 111 disassociates the cooperative battle in which the subjugation has been completed from the user as an uncompleted cooperative battle, and treats the cooperative battle as a playable completed cooperative battle to the user. may be stored in the storage unit 120 in association with. However, in this case, the game progress processing unit 111 does not award the first reward even if the first condition is satisfied for the completed joint battle. Further, the point management unit 117 excludes completed joint battles from being registered in the registration frame. As a result, the user can enjoy playing the cooperative battle once again, although no reward is given for the cooperative battle once completed, and the user's motivation to continue playing the cooperative battle does not decrease.

Further, in this embodiment, at least a part of the processing described as being executed by the control unit 110 of the user terminal 100 may be executed by the control unit 210 of the server 200. Furthermore, in this embodiment, at least a portion of the information described as being stored in the storage unit 120 of the user terminal 100 may be stored in the storage unit 220 of the server 200.

[Example of implementation using software]
The control blocks of the control unit 210 (especially the transmitting/receiving 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 section 113, display control section 114, object control section 115, lottery control section 116, and point management section 117) are realized by logic circuits (hardware) formed on 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, the information processing device equipped with the control unit 210 or the control unit 110, or both, includes a CPU that executes instructions of a program that is software that implements each function, and a computer (or CPU) that executes the instructions of a program that is software that implements each function. The computer is equipped with a ROM (Read Only Memory) or a storage device (these are referred to as a "recording medium") in which readable data is recorded, a RAM (Random Access Memory) for expanding the program, and the like. Then, the object of the present invention is achieved by the computer (or CPU) reading the program from the recording medium and executing it. As the recording medium, a "non-temporary tangible medium" such as a tape, a disk, a card, a semiconductor memory, a programmable logic circuit, etc. can be used. Furthermore, the program may be supplied to the computer via any transmission medium (communication network, broadcast waves, etc.) that can transmit the program. Note that one aspect of the present invention can also be realized in the form of a data signal embedded in a carrier wave, in which the program is embodied by electronic transmission.

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

[Additional notes]
The contents related to one aspect of the present invention are listed below.

(Item 1) The game programs (121, 221) were explained. According to an aspect of the present disclosure, a game program includes a computer (user terminal 100, server 200, ) is executed. The game program includes the step of causing the processor to store in the memory an event that can be played in a game based on the game program in association with a user; When a second condition that can be achieved without playing the event is satisfied, the value for advancing the game advantageously becomes the first one. and storing a second reward lower than the reward in the memory in association with the user.

With this configuration, the user can obtain the first reward of higher value for the event that he/she wants to enjoy playing, so that the user can feel the benefits of playing the event. Furthermore, for other events, the user can feel the benefit of being able to obtain rewards regardless of play, even if the second reward is of lower value. As a result, users can focus on playing the events they want to enjoy without reducing their motivation to play events, and receive secondary rewards for other events regardless of their play. You can encourage them to do so. In this way, this configuration can support the user's progress in the game by diversifying the means for obtaining rewards.

(Item 2) In (Item 1), the game program may further cause the processor to perform a step of completing the event when the first condition or the second condition is satisfied. Thereby, the user can focus on playing and completing the event that he/she wants to enjoy playing, while completing other events without depending on the play. In this way, this configuration can support the user's progress in the game.

(Item 3) In (Item 1) or (Item 2), the memory may store a rarity level representing the value of the first reward in advancing the game more advantageously in association with the event. In this case, the step of storing the second reward uses a condition according to the rarity associated with the event as the second condition. As a result, users can focus on playing events with a high degree of rarity, while not having to play events with a low degree of rarity. You can get rewards.

(Item 4) In any one item from (Item 1) to (Item 3), the step of storing the first reward includes including the first item associated with the event in the first reward; The step of storing the reward may include the first item in the second reward. In this case, the game program further causes the processor to generate an object usable in play of the event using at least the first item. As a result, the first item required to generate an object that can be used in play is included in the second reward as well as the first reward. Therefore, it is possible to encourage the user to obtain the second reward without playing events other than those that the user wants to enjoy playing.

(Item 5) In (Item 4), the game program may further cause the processor to perform a step of changing the object using the first item so that the game can proceed more advantageously. Thereby, the user can also obtain another first item, which is used to advantageously change the object generated using the first item, from the second reward without playing the event. In this way, the user can effectively utilize the object to advantageously change the object used in the event he/she wants to enjoy without playing other events.

(Item 6) In any one of (Item 1) to (Item 5), the step of memorizing the second reward includes using a second condition including a condition regarding the passage of time as the second condition. Good too. As a result, while the user is enjoying playing an event in which he or she wants to obtain a first reward of higher value, the second condition for another event is that the time elapses and the second reward is obtained. can. As a result, it becomes easier for the user to progress through the game.

(Item 7) In any one of (Item 1) to (Item 6), the step of memorizing the second reward is a second condition that can be achieved without playing the event. A second condition may be used that includes a condition based on the play of the event. As a result, the user can satisfy the second conditions for other events and obtain the second reward by enjoying the play of the event in which the user wants to obtain the first reward of higher value. As a result, it becomes easier for the user to progress through the game.

(Item 8) In any one of (Item 1) to (Item 7), the step of storing the second reward is performed by the user who instructs to receive the second reward after the second condition is satisfied. Depending on the operation, the second reward may be associated with the user and stored in the memory. In this case, the step of storing the second reward includes storing a third reward in addition to the second reward if the user operation is accepted within a predetermined period after the second condition is satisfied. , to be stored in memory in association with the user. Thereby, it is possible to prevent the user from neglecting the event after the second condition is satisfied regardless of play, and it is possible to encourage the user to continue playing.

(Item 9) In any one of (Item 1) to (Item 8), the game program causes the processor to select an event for which a second reward is to be obtained from among the events stored in the memory in association with the user. You may further perform the step of selecting based on a user operation. In this case, the step of storing the second reward includes, as a second condition that can be achieved without playing the event, that a user operation to select the event as a target event has been received. Use the following conditions. Thereby, the user can select an event for which he/she wants to obtain the second reward regardless of play.

(Item 10) In (Item 9), the selecting step may select up to an upper limit number of events as target events. This allows the user to be encouraged to play events that exceed the upper limit.

(Item 11) In (Item 10), the step of selecting may increase the upper limit number by consuming a consumable item. Thereby, the user can obtain the second reward for more events other than the event that the user wants to enjoy playing, regardless of the play.

(Item 12) In (Item 11), the selecting step may increase the upper limit number only within the validity period by consuming the consumable item. Thereby, the user can be urged to proceed with the game so that the second condition is satisfied within the validity period.

(Item 13) Explained how to run a game program. According to an aspect of the present disclosure, a game program is executed by a computer including a processor and a memory. This method is a method in which a processor executes each step described in (Item 1). The method according to (Item 13) has the same effect as the game program according to (Item 1).

(Item 14) The information processing device (user terminal 100) was explained. According to an aspect of the present disclosure, the information processing device includes a storage unit (120) that stores the game program according to (item 1), and a storage unit (120) that stores the game program according to (item 1), and the information processing device (user terminal 100) by executing the game program. and a control section (110) that controls the operation. The information processing device according to (Item 14) has the same effect as the game program according to (Item 1).

1 game system, 2 network, 10, 20 processor, 11, 21 memory, 12, 22 storage, 15 touch screen, 151 input section, 152 display section, 17 camera, 18 ranging sensor, 1010 object, 1020 controller, 1030 memory 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 section, 114 Display control section, 115 Object control section, 116 Lottery control section, 117 Point management section, 211 Transmission/reception section, 212 Server processing section, 213 Data management section, 214 Synchronization processing section

Claims (9)

computer,
Functioning as a storage means for storing a playable event in association with the user, and storing a first reward in association with the user when a first condition is satisfied according to the play of the event,
If the second condition is satisfied by performing an operation for associating a reward without playing the event , the storage means may give the game an advantage even if the event is not played and the first condition is not satisfied. A program that causes a second reward having a lower value than the first reward to be stored in association with the user. The program according to claim 1, wherein the second condition is satisfied when a predetermined time period elapses after an operation for associating a reward without playing the event is performed . computer,
The program according to claim 1 or 2, which functions as a completion means for completing the event when the first condition or the second condition is satisfied. The first reward includes a first item associated with the event,
The second reward includes the first item,
computer,
The program according to any one of claims 1 to 3, which functions as a generation unit that uses at least the first item to generate an object that can be used in playing the event. computer,
5. The program according to claim 4, which causes the object to function as a changing means that uses the first item to change the object so that the game can proceed more advantageously. After the second condition is satisfied and the second reward can be stored, the storage means stores the second reward in response to a user operation instructing to receive the second reward. is stored in association with the user, and if the user's operation is accepted within a predetermined period after the second reward becomes memorizable, a third reward is received in addition to the second reward. The program according to any one of claims 1 to 5, wherein a reward is stored in association with the user. 7. The program according to claim 1, wherein an upper limit is set for the number of events for which the second reward can be stored when the second condition is satisfied. computer,
8. The storage device functions as an increasing means for increasing the upper limit number of events for which the second reward can be stored when the second condition is satisfied by consuming the consumable item. program. 9. The program according to claim 8, wherein the increasing means increases the upper limit number only within a valid period by consuming the consumable item.

Images