Programs and Use

Abstract

To enhance interest. [Solution] When an enemy object with predetermined parameters defeats the player, the predetermined parameters are improved when the player next battles the enemy object.

Description

Technical Field

[0001] This disclosure relates to a program and a system.

Background Art

[0002] Patent Document 1 describes that defeating a weak enemy character causes a strong enemy character to appear, and Patent Document 2 describes fighting a boss character at a level corresponding to the current level of the controlled character. That is, conventionally, there has been something that causes stronger enemy characters to appear as the player becomes stronger by repeating battles.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the conventional case, since it becomes a battle with an enemy character corresponding to the strength of the player, there is a risk of becoming routine and causing boredom.

[0005] An object of the present invention is to improve the interestingness.

Means for Solving the Problems

[0006] To solve the above problems, the program according to the present invention causes a computer to improve a predetermined parameter when the player fights an enemy object again after the enemy object having the predetermined parameter defeats the player.

Effects of the Invention

[0007] According to the present invention, interest can be improved. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows the hardware configuration of a system according to an embodiment of the present invention. [Figure 2] This block diagram shows the functional configuration of the user terminals and servers included in the above system. [Figure 3] This figure shows an example of a screen displaying a field space, which is a type of game space. [Figure 4] This figure shows an example of a screen displaying the above-mentioned field space during combat. [Figure 5] This is a diagram showing the data structure of character data. [Figure 6] This flowchart shows an example of the combat processing flow in the system described above. [Figure 7] This figure shows an example of an enemy character table in the system described above. [Figure 8] This flowchart shows an example of the flow of the lottery distribution process in the system described above. [Modes for carrying out the invention]

[0009] The system disclosed herein is a system for providing a virtual space for deploying games and other content to multiple users. Below, as an example of a virtual space, a system for providing a virtual space for deploying games will be described with reference to the drawings. However, the present invention is not limited to these examples, and is defined by the claims, with all modifications within the meaning and scope of equivalence to the claims being intended to be included in the present invention. In the following description, the same elements in the drawings will be denoted by the same reference numerals, and redundant descriptions will not be repeated.

[0010] <System 1 Hardware Configuration> Figure 1 shows the hardware configuration of System 1. As shown in the figure, System 1 includes multiple user terminals 100 and a server 200. Each user terminal 100 is connected to the server 200 via Network 2. Network 2 consists of the Internet and various mobile communication systems, etc., constructed by wireless base stations (not shown). Examples of these mobile communication systems include so-called 4G and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks (e.g., Wi-Fi®) that can connect to the Internet via designated access points.

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

[0012] The user terminal 100 (computer, information processing device) may be a mobile terminal such as a smartphone, feature phone, PDA (Personal Digital Assistant), or tablet computer. The user terminal 100 may also be a game device suitable for gameplay. As shown in the figure, the user terminal 100 includes a processor 10, memory 11, storage 12, communication interface (IF) 13, input / output IF 14, touchscreen 15 (display unit), camera 17, and distance measuring sensor 18. These components of the user terminal 100 are electrically connected to each other by a communication bus. In addition, the user terminal 100 may have an input / output IF 14 to which a display (display unit) configured separately from the user terminal 100 body can be connected, instead of or in addition to the touchscreen 15.

[0013] Furthermore, as shown in Figure 1, the user terminal 100 may be configured to communicate with one or more controllers 1020. The controller 1020 establishes communication with the user terminal 100 according to a communication standard such as Bluetooth®. The controller 1020 may have one or more buttons, and transmits output values ​​to the user terminal 100 based on user input operations to such buttons, etc. The controller 1020 may also have various sensors such as an acceleration sensor and an angular velocity sensor, and transmits output values ​​from these sensors to the user terminal 100.

[0014] Alternatively, instead of the user terminal 100 being equipped with a camera 17 and a distance measuring sensor 18, or in addition to that, the controller 1020 may also be equipped with a camera 17 and a distance measuring sensor 18.

[0015] It is desirable that the user terminal 100, for example at the start of a game, prompt the user using the controller 1020 to input user identification information such as the user's name or login ID via the controller 1020. This allows the user terminal 100 to associate the controller 1020 with the user, and to identify which user the received output value belongs to based on the source of the output value (controller 1020).

[0016] When the user terminal 100 communicates with a plurality of controllers 1020, by each user gripping each controller 1020, it is possible to realize multiplayer on the single user terminal 100 without communicating with other devices such as the server 200 via the network 2. Also, when each user terminal 100 communicates with each other according to a wireless standard such as the wireless LAN (Local Area Network) standard (communicates without going through the server 200), it is also possible to realize local multiplayer with a plurality of user terminals 100. When realizing the above-described multiplayer locally with a single user terminal 100, the user terminal 100 may further have at least a part of various functions described later provided in the server 200. Also, when realizing the above-described multiplayer locally with a plurality of user terminals, the plurality of user terminals 100 may have the various functions described later provided in the server 200 distributedly.

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

[0018] <着脱可能な構成であるとしてもよい。この場合、ユーザ端末100の筐体における少なくともいずれかの面に、コントローラ1020との結合部が設けられていてもよい。該結合部を介して有線によりユーザ端末100とコントローラ1020とが結合している場合は、ユーザ端末100とコントローラ1020とは、有線を介して信号を送受信する。 Also, 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 any one surface of the housing of the user terminal 100. When the user terminal 100 and the controller 1020 are coupled by wire via the coupling portion, the user terminal 100 and the controller 1020 transmit and receive signals via the wire.

[0019] As shown in Figure 1, the user terminal 100 may accept the insertion of an external storage medium 1030, such as a memory card, via the input / output IF 14. This allows the user terminal 100 to read the program and data recorded on the storage medium 1030. The program recorded on the storage medium 1030 is a program for providing a virtual space, for example, a program for providing a virtual space in which a game is played (hereinafter also simply referred to as a game).

[0020] The user terminal 100 may store programs acquired by communicating with an external device such as a server 200 in its own memory 11, or it may store programs acquired by reading them from a storage medium 1030 in its own memory 11.

[0021] As described above, the user terminal 100 includes, as an example of a mechanism for inputting information to the user terminal 100, a communication IF 13, an input / output IF 14, a touchscreen 15, a camera 17, and a distance measuring sensor 18. Each of the above-mentioned parts, which act as input mechanisms, can be considered as an operation unit configured to accept user input operations.

[0022] For example, if the operating unit consists of at least one of the camera 17 and the distance measuring sensor 18, the operating unit detects an object 1010 in the vicinity of the user terminal 100 and identifies an input operation from the detection result of the object. As an example, the user's hand, a marker of a predetermined shape, etc., may be detected as the object 1010, and the input operation is identified based on the color, shape, movement, or type of the object 1010 obtained as a detection result. More specifically, if the user terminal 100 detects the user's hand from the image captured by the camera 17, it identifies and accepts the gesture (a series of movements of the user's hand) detected based on the captured image as the user's input operation. The captured image may be a still image or a video.

[0023] Alternatively, if the operation unit consists of a touchscreen 15, the user terminal 100 identifies and accepts user operations performed on the input unit 151 of the touchscreen 15 as user input operations. Alternatively, if the operation unit consists of a communication IF 13, the user terminal 100 identifies and accepts signals (e.g., output values) transmitted from the controller 1020 as user input operations. Alternatively, if the operation unit consists of an input / output IF 14, it identifies and accepts signals output from an input device (not shown) different from the controller 1020 connected to the input / output IF 14 as user input operations.

[0024] <Hardware components of each device> Processor 10 controls the operation of the entire user terminal 100. Processor 20 controls the operation of the entire server 200. Processors 10 and 20 include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and a GPU (Graphics Processing Unit).

[0025] Processor 10 reads the program from storage 12 (described later) and loads it into memory 11 (described later). Processor 20 reads the program from storage 22 (described later) and loads it into memory 21 (described later). Processors 10 and 20 execute the loaded programs.

[0026] Memory 11 and 21 are main memory. Memory 11 and 21 consist of storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). Memory 11 provides a workspace to the processor 10 by temporarily storing programs and various data read by the processor 10 from storage 12 (described later). Memory 11 also temporarily stores various data generated by the processor 10 while it is operating according to the program. Memory 21 provides a workspace to the processor 20 by temporarily storing various programs and data read by the processor 20 from storage 22 (described later). Memory 21 also temporarily stores various data generated by the processor 20 while it is operating according to the program.

[0027] In this embodiment, the program may be a program for implementing a game on the user terminal 100. Alternatively, the program may be a program for implementing the game through cooperation between the user terminal 100 and the server 200. The game implemented through cooperation between the user terminal 100 and the server 200 may, for example, be a game executed on a browser launched on the user terminal 100. Alternatively, the program may be a program for implementing the game through cooperation between multiple user terminals 100. Furthermore, various data includes game-related data such as user information and game information, as well as instructions or notifications transmitted between the user terminal 100 and the server 200 or between multiple user terminals 100.

[0028] Storage devices 12 and 22 are auxiliary storage devices. Storage devices 12 and 22 consist of storage devices such as flash memory or HDDs (Hard Disk Drives). Various data related to the virtual space in which the game is played are stored in storage devices 12 and 22.

[0029] Communication IF13 controls the transmission and reception of various data on the user terminal 100. Communication IF23 controls the transmission and reception of various data on the server 200. Communication IFs13 and 23 control communication using, for example, wireless LAN (Local Area Network), wired LAN, wireless LAN, or mobile phone network internet communication, as well as short-range wireless communication.

[0030] The input / output IF14 is an interface for the user terminal 100 to receive data input and for the user terminal 100 to output data. The input / output IF14 may perform data input and output via USB (Universal Serial Bus) or the like. The input / output IF14 may include, for example, physical buttons, a camera, a microphone, or a speaker on the user terminal 100. The input / output IF24 of the server 200 is an interface for the server 200 to receive data input and for the server 200 to output data. The input / output IF24 may include, for example, an input unit which is an information input device such as a mouse or keyboard, and a display unit which is a device that displays and outputs an image.

[0031] The touchscreen 15 of the user terminal 100 is an electronic component that combines an input unit 151 and a display unit 152. The input unit 151 is, for example, a touch-sensitive device, and is composed of, for example, a touchpad. The display unit 152 is composed of, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display.

[0032] The input unit 151 has the function of detecting the position where a user operation (mainly physical contact operations such as touch, slide, swipe, and tap operations) is input to the input surface, and transmitting information indicating the position as an input signal. The input unit 151 only needs to include a touch sensing unit (not shown). The touch sensing unit may employ any method, such as a capacitive or resistive touch sensor. The object used to perform input operations on the touchscreen 15 is not particularly limited. For example, the object may be the user's finger or a stylus pen.

[0033] Although not shown in the diagram, the user terminal 100 may be equipped with one or more sensors for determining the holding orientation of the user terminal 100. These sensors may be, for example, an accelerometer or an angular velocity sensor. If the user terminal 100 is equipped with sensors, the processor 10 can determine the holding orientation of the user terminal 100 from the sensor output and perform processing according to the holding orientation. For example, when the user terminal 100 is held vertically, the processor 10 may display a vertically oriented image on the display unit 152. On the other hand, when the user terminal 100 is held horizontally, the processor 10 may display a horizontally oriented image on the display unit. Thus, the processor 10 may be able to switch between vertical and horizontal screen display depending on the holding orientation of the user terminal 100.

[0034] The camera 17 includes an image sensor and other components, and generates an image by converting incident light entering from the lens into an electrical signal.

[0035] The distance measuring sensor 18 is a sensor that measures the distance to an object to be measured. The distance measuring sensor 18 includes, for example, a light source that emits pulsed light and a light receiving element that receives the light. The distance measuring sensor 18 measures the distance to an object to be measured based on the timing of light emission from the light source and the timing of receiving the reflected light generated when the light emitted from the light source strikes the object to be measured and is reflected. The distance measuring sensor 18 may also have a light source that emits directional light.

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

[0037] The processor 10 may perform one or more of the following processes on the image captured by the camera 17: (1) The processor 10 performs image recognition processing on the image captured by the camera 17 to determine whether or not the user's hand is included in the image. The processor 10 may use techniques such as pattern matching as the analysis technique employed in the above-mentioned image recognition processing. (2) The processor 10 also detects the user's gesture from the shape of the user's hand. For example, the processor 10 determines the number of fingers (the number of extended fingers) of the user from the shape of the user's hand detected from the captured image. The processor 10 further determines the gesture performed by the user from the determined number of fingers. For example, if the number of fingers is 5, the processor 10 determines that the user performed a "paper" gesture. Also, if the number of fingers is 0 (no fingers were detected), the processor 10 determines that the user performed a "rock" gesture. Furthermore, if the number of fingers is two, the processor 10 determines that the user has made a "scissors" gesture. (3) The processor 10 performs image recognition processing on the image captured by the camera 17 to detect whether the user's fingers are in a state where only the index finger is extended, or whether the user's fingers have made a flicking motion. (4) The processor 10 detects the distance between the user terminal 100 and an object 1010 (such as the user's hand) in the vicinity of the user terminal 100, based on the image recognition result of the image captured by the camera 17 and at least one of the output values ​​of the distance measuring sensor 18. For example, the processor 10 detects whether the user's hand is in the vicinity of the user terminal 100 (for example, less than a predetermined distance) or far away (for example, greater than a predetermined distance) based on the size of the shape of the user's hand identified from the image captured by the camera 17. If the captured image is a video, the processor 10 may also detect whether the user's hand is approaching or moving away from the user terminal 100. (5) Based on the image recognition results of the image captured by camera 17, if it is determined that the distance between the user terminal 100 and the user's hand is changing while the user's hand is detected, the processor 10 recognizes that the user is waving their hand in the direction of the camera 17's shooting.In the distance measuring sensor 18, which has a stronger directionality than the shooting range of the camera 17, if an object is detected or not, the processor 10 recognizes that the user is waving their hand in a direction perpendicular to the camera's shooting direction.

[0038] In this way, the processor 10 detects whether the user is clenching their fist ("rock" gesture or another gesture, such as "open hand") by image recognition of the image captured by the camera 17. The processor 10 also detects how the user is moving their hand, along with the shape of the user's hand. Furthermore, the processor 10 detects whether the user is moving their hand closer to or further away from the user terminal 100. Such operations can be made to correspond to operations using a pointing device such as a mouse or touch panel. For example, the user terminal 100 moves the pointer on the touchscreen 15 in response to the user's hand movement and detects the user's "rock" gesture. In this case, the user terminal 100 recognizes that the user is continuing a selection operation. Continuing a selection operation corresponds to, for example, the mouse being clicked and held down, or the touching state being maintained after a touch-down operation on a touch panel. Furthermore, if the user terminal 100 detects the user's "fist" gesture and the user moves their hand further, it can recognize this series of gestures as an operation corresponding to a swipe (or drag) operation. In addition, if the user terminal 100 detects a gesture such as the user flicking their fingers based on the image captured by the camera 17, it may recognize this gesture as an operation corresponding to a mouse click or a tap on a touch panel.

[0039] <Game Overview> The game implemented by System 1 is a game in which character objects (hereinafter simply referred to as "characters") are placed in a game space, and these characters are made to move in response to user input within the game space (an example of a virtual space). A game based on System 1 may be a 3D game represented by a three-dimensional game space and three-dimensional objects, or a 2D game represented by a two-dimensional game space and two-dimensional objects. Hereafter, the character that moves in response to user input will be referred to as the "player character (an example of a player)" or the "operable character."

[0040] As will be explained in more detail later, in a game implemented by System 1, the user controls a player character and progresses through the game by having that character engage in combat (an example of a battle) with enemy characters (an example of enemy objects) placed in the same game space. In addition, in a game implemented by System 1, the user can participate in a lottery to acquire characters.

[0041] One example of a game that System 1 can implement is an open-world game in which the user can freely control and move and engage in combat with characters placed in a virtual game space. In this embodiment, as an example, we will describe the case in which System 1 implements an open-world RPG (Role-Playing Game).

[0042] Furthermore, the game implemented by System 1 may be multiplayer capable. For example, the game may be an MMORPG (Massively Multiplayer Online Role-Playing Game) in which multiple users simultaneously operate their player characters in the same game space via their respective user terminals 100 to progress through the game. However, the genre and content of the game implemented by System 1 are not limited to the types described above.

[0043] <Functional Configuration of System 1> Figure 2 is a block diagram showing the functional configuration of the server 200 and user terminal 100 included in System 1. Each of the server 200 and user terminal 100 may include a functional configuration necessary for functioning as a general computer (not shown), and a functional configuration necessary for implementing known functions in a game.

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

[0045] The server 200 has the function of communicating with each user terminal 100 and assisting the user terminal 100 in progressing through the game. For example, it may perform tasks such as selling valuable data or providing services. If the game is a multiplayer game, the server 200 may also have the function of communicating with each user terminal 100 participating in the game and mediating interactions between the user terminals 100. The server 200 functions as a control unit 210 and a storage unit 220 through the cooperation of the processor 20, memory 21, storage 22, communication IF 23, and I / O IF 24, etc.

[0046] Memory units 120 and 220 store program 231, game information 232, and user information 233. Program 231 is a program executed by the user terminal 100 and the server 200.

[0047] Game information 232 is data that control unit 110 and control unit 210 refer to when executing program 231.

[0048] User information 233 is information stored for each user account. User information 233 for a given account is associated with at least one user terminal 100. In this embodiment, an example in which one account is associated with one user terminal 100 will be described. The storage unit 120 stores the user information 233 of the account corresponding to the user terminal 100. On the other hand, the storage unit 220 stores the user information 233 collected from each user terminal 100 together. User information 233 includes character data 233A. Character data 233A is data about the characters owned by the user. Details of character data 233A will be described later.

[0049] (Functional configuration of Server 200) The control unit 210 comprehensively controls the server 200 by executing the program 231 stored in the memory unit 220. For example, the control unit 210 transmits various data and programs to the user terminal 100. If the game is a multiplayer game, the control unit 210 may receive a request for multiplayer synchronization from the user terminal 100 and transmit synchronization data to the user terminal 100.

[0050] The control unit 210 functions as a transmitting / receiving unit 211, a server processing unit 212, and a data management unit 213, depending on the description in the program 231. Depending on the nature of the game being executed, the control unit 210 can also function as other functional blocks (not shown) to support the progress of the game on the user terminal 100.

[0051] The transmitting / receiving unit 211 receives various data and requests from the user terminal 100. For example, the transmitting / receiving unit 211 receives some or all of the game information 232 or user information 233 from the user terminal 100. The transmitting / receiving unit 211 may also receive character data 233A from the user terminal 100 as part of the user information 233. The transmitting / receiving unit 211 may also receive a request to execute a lottery from the user terminal 100.

[0052] The transmitting / receiving unit 211 transmits various data and requests to the user terminal 100. For example, the transmitting / receiving unit 211 may transmit the lottery result to the user terminal 100, which is the source of the lottery execution request. Alternatively, the transmitting / receiving unit 211 may transmit the updated character data 233A to the user terminal 100, which is the source of the lottery execution request.

[0053] The server processing unit 212 performs the calculations necessary to provide the game. The server processing unit 212 instructs the transmission / reception unit 211 to transmit various data. The server processing unit 212 instructs the data management unit 213 to add, update, or delete various information contained in the game information 232 and user information 233. The server processing unit 212 may also perform processing related to the lottery.

[0054] The data management unit 213 manages the data stored in the storage unit 220. The data management unit 213 adds, updates, or deletes various types of information contained in the game information 232 and user information 233 in accordance with instructions from the server processing unit 212. The data management unit 213 may also read at least one of the game information 232 and user information 233 from the storage unit 220 in accordance with instructions from the server processing unit 212. The data management unit 213 may also read the portion of the program 231 that will be executed on a particular user terminal 100 from the storage unit 220 and transmit it to the user terminal 100 via the transmission / reception unit 211 in accordance with instructions from the server processing unit 212.

[0055] (Functional configuration of user terminal 100) The control unit 110 comprehensively controls the user terminal 100 by executing the program 231 stored in the memory unit 120. For example, the control unit 110 advances the game according to the program 231 and the user's operations. Also, while the game is in progress, the control unit 110 communicates with the server 200 to send and receive information as needed.

[0056] The control unit 110 functions as an operation reception unit 111, a game progress unit 112, a camera placement control unit 113, an object control unit 114, a display control unit 115, and a communication unit 116, depending on the description in the program 231. Depending on the nature of the game being played, the control unit 110 can also function as other functional blocks (not shown) to advance the game.

[0057] The operation reception unit 111 detects and accepts user input operations to the input unit 151. The operation reception unit 111 determines what kind of input operation was performed based on the user's actions to the console via the touchscreen 15 and other input / output IFs 14, and outputs the result to each element of the control unit 110.

[0058] For example, the operation reception unit 111 receives an input operation to the input unit 151, detects the coordinates of the input position of the input operation, and identifies the type of the input operation. The operation reception unit 111 identifies the type of input operation as, for example, a touch operation, a slide operation, a swipe operation, and a tap operation. Furthermore, when the input that has been continuously detected is interrupted, the operation reception unit 111 detects that contact input has been released from the touchscreen 15.

[0059] The communication unit 116 transmits various data and requests to the server 200. For example, the communication unit 116 transmits part or all of the game information 232 or user information 233 to the server 200. For example, the communication unit 116 transmits a request to the server 200 to execute a lottery. The communication unit 116 may also transmit character data 233A as part of the user information 233 to the server 200.

[0060] The communication unit 116 receives various data and requests from the server 200. For example, the communication unit 116 receives some or all of the game information 232 or user information 233 from the server 200. The communication unit 116 may also receive information indicating the lottery results from the server 200. The communication unit 116 may also receive updated character data 233A from the server 200.

[0061] The game progress unit 112 performs various processes related to the progress of the game. For example, the game progress unit 112 identifies the user's instructions based on the coordinates of the input operation received by the operation reception unit 111, the type of operation, and the game's progress. The game progress unit 112 also performs various determination processes related to the progress of the game. Furthermore, the game progress unit 112 adds, updates, or deletes various information contained in the game information 232 and user information 233 stored in the memory unit 120. The game progress unit 112 includes a battle processing unit 112A, a lottery unit 112B, and a monster granting unit 112C.

[0062] The battle processing unit 112A executes processing related to battles between the player character and the automated battle character and the enemy character. Furthermore, if predetermined conditions are met as a result of the battle, the battle processing unit 112A determines which character to assign to the user. Once the battle processing unit 112A has determined which character to assign, it notifies the monster assignment unit 112C of that character.

[0063] The lottery unit 112B executes processing related to a lottery for acquiring a character. The method of the lottery is not particularly limited. For example, the lottery unit 112B may refer to the cabinet (lottery data table) included in the game information 232 in response to a predetermined input operation by the user, and determine the lottery result based on the table. The lottery unit 112B notifies the monster granting unit 112C of the lottery result, i.e., the character to be granted to the user.

[0064] The monster granting unit 112C grants the user a character that has been determined to be granted as a result of the processing by the battle processing unit 112A or the lottery by the lottery unit 112B. When the battle processing unit 112A or the lottery unit 112B determines which character to grant, the monster granting unit 112C reads the initial data of the character corresponding to that character from the game information 232 and adds that data to the character data 233A in the user information 233.

[0065] The camera placement control unit 113 defines a virtual camera for specifying the 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 its position and orientation within the game space. The camera placement control unit 113 instructs the display control unit 115 to create an image that renders the field of view defined by the virtual camera and the objects placed within that field of view. The camera placement control unit 113 may change the position and orientation of the virtual camera at any time.

[0066] The object control unit 114 places objects in the game space based on the object setting information contained in the game information 232. The object control unit 114 also controls the objects placed in the game space. For example, the object control unit 114 changes the position, orientation, shape, color, etc., of objects in the game space, or makes objects perform a predetermined series of actions. For example, the object control unit 114 moves the player character in the direction, speed, and distance determined by the game progress unit 112.

[0067] The display control unit 115 causes the display unit 152 to display an image. For example, the display control unit 115 generates an image that includes the field of view of a virtual camera defined by the camera placement control unit 113 within the game space, and the objects present in that field, and displays it on the display unit 152.

[0068] The object control unit 114 may place objects for constructing a user interface (UI) (UI objects) in the game space and control said UI objects. The display control unit 115 may also superimpose images related to the UI necessary for various game operations, such as icons, buttons, lists, and menu screens (UI images), onto an image. UI images and UI objects are tools for the user to make necessary inputs to the user terminal 100 during game progression. Furthermore, UI images and UI objects are tools for the user to obtain information output from the user terminal 100 during game progression.

[0069] Note that the functions of the server 200 and user terminal 100 shown in Figure 2 are merely examples. The server 200 may have at least some of the functions of the user terminal 100. Similarly, the user terminal 100 may have at least some of the functions of the server 200. Furthermore, other devices besides the user terminal 100 and server 200 may be components of system 1, and these other devices may be made to execute some of the processing in system 1. In other words, the computer that executes the program in this embodiment may be the user terminal 100, the server 200, or other devices, or it may be realized by a combination of these multiple devices.

[0070] (Game space and object placement) The game progress unit 112 of the user terminal 100 starts a game based on program 231. When the game starts, the object control unit 114 constructs a predetermined game space according to the instructions of the game progress unit 112 and places predetermined player characters in the game space. The object control unit 114 may also place background objects such as trees, rocks, and buildings in the game space. The object control unit 114 also places enemy characters, who are the opponents of the player characters, at predetermined placement locations within the game space.

[0071] In this embodiment, as an example of a game implemented by System 1, we will describe an example in which the user selects one character from among the playable characters they own and controls that character. However, in a game implemented by System 1, the user may be able to control multiple characters at once (for example, a human character and a mountable monster, or multiple human characters, as described later). Furthermore, instead of all movements of each character being controlled by the user's input, only some movements, such as the timing of attacks and the direction of movement, may be controlled by the user (so-called semi-automatic operation).

[0072] In this embodiment, as an example, a game space (referred to as the field space) corresponding to an outdoor space such as a grassland is constructed by the object control unit 114 at the start of the game, and player characters and enemy characters are placed in the field space.

[0073] The game spaces that the object control unit 114 can construct include, in addition to the field space described above, game spaces corresponding to indoor spaces (so-called dungeons) and game spaces corresponding to spaces with different themes (for example, a space in the real world, a space in the other world, etc.). For example, the object control unit 114 constructs one of these game spaces in response to instructions from the game progress unit 112, places player characters and enemy characters in that space, and proceeds with the game in that game space. For example, if the operation reception unit 111 receives an input operation instructing the player to enter a dungeon, the game progress unit 112 may instruct the object control unit 114 to construct a dungeon space and place player characters in that space. Furthermore, the game progress unit 112 may instruct the object control unit 114 to construct a specific type of game space (for example, a game space corresponding to the other world) and place player characters in that space when special conditions are met.

[0074] Figure 3 shows an example of a screen depicting a field space of the type corresponding to an outdoor space, among several types of field spaces (game spaces). At least one player character is placed in the field space. State (A) in Figure 3 shows a state in the field space where a human character 301 is placed with the character's weapon 302 on its back.

[0075] Here, "human character" refers to a type of playable character. Note that "human character" is merely an example of a name; human character 301 does not necessarily have to be a human or humanoid character. Also, weapon 302 is not required.

[0076] (Mountable monsters and auto-battle monsters) State (B) in Figure 3 shows the state in the field space where human character 301 is mounted on mount monster 303. Mount monster 303 is a type of controllable character and is a type of character that becomes a companion (i.e., an ally in battle) of human character 301. Mount monster 303 may also participate in battle in place of human character 301.

[0077] Human character 301 can ride mount monster 303. In other words, mount monster 303 is a character that serves as a mount for human character 301. A "character participating in combat" is a character that is placed in the game space during combat with an enemy character (described later) and is an ally of the user's player character during that combat. A character participating in combat does not necessarily have to perform actions such as attacks against the enemy character. Also, a character participating in combat does not have to receive actions from the enemy character. For example, even if human character 301 is riding mount monster 303, and only mount monster 303 performs various actions such as attacks based on input commands, human character 301 is still considered to be participating in combat.

[0078] When a user specifies a mountable monster 303 and inputs an instruction to mount it, the operation reception unit 111 receives these operations, and the game progress unit 112 associates the human character 301 with the specified mountable monster 303. Furthermore, the game progress unit 112 notifies the object control unit 114 that the human character 301 and the mountable monster 303 have been associated. Upon receiving this notification, the object control unit 114 positions the human character 301 in a posture and location where it is mounted on the mountable monster 303. This allows the user to enjoy the game by changing the association of a particular human character 301 with the mountable monster 303 as a vehicle. Thus, the enjoyment of the game is enhanced.

[0079] The combat processing unit 112A of the game progression unit 112 may, if it has mounted a mountable monster 303, prevent the mounted human character 301 from performing actions such as attacking or defending in subsequent battles. In other words, the combat processing unit 112A may have both the mountable monster 303 and the human character 301 participate in the battle, but may only allow one of them to perform input operations related to various actions in battle.

[0080] The game progression unit 112 may also release the human character 301 from its mounted state in response to a predetermined user input. In this case, the mounted monster 303 is removed from the field space, and only the human character 301 remains in that space.

[0081] The apparent relationship between the human character 301 and the mountable monster 303 according to the present invention is not limited to "riding," and may be determined as appropriate depending on the appearance of the mountable monster 303. For example, if the human character 301 is associated with a bird-type mountable monster 303, the mountable monster 303 may grab the human character 301 and fly away.

[0082] Furthermore, if the operation reception unit 111 receives an input operation to associate the user's auto-battle monster 304 with a player character (to summon the auto-battle monster 304), the game progress unit 112 may associate the auto-battle monster 304 with a player character (human character 301 or mountable monster 303). The game progress unit 112 may then instruct the object control unit 114 to place the auto-battle monster 304 in the field space. The object control unit 114 may then place the auto-battle monster 304 in the field space.

[0083] Auto-battle monster 304 is a type of character that cannot be controlled by the user. Unlike mountable monster 303, auto-battle monster 304 cannot be ridden by human character 301. In the battle described later, the game progress unit 112 and object control unit 114 move auto-battle monster 304 according to a predetermined action pattern, causing auto-battle monster 304 to automatically participate in the battle. In the following explanation, mountable monster 303 and auto-battle monster 304 will be collectively referred to as "monsters".

[0084] Furthermore, it is desirable that the virtual camera in the field space be positioned such that the user's player character (human character 301 or mounted monster 303) is displayed approximately in the center of the user terminal 100. This ensures that an area for the user to touch the touchscreen 15 is available on the display screen of the display unit 152 (for example, area A in states (A) and (B) of Figure 3).

[0085] (battle) Figure 4 shows an example of a screen depicting the battle field space. The user moves within the battle field space by controlling a human character 301 or a mounted monster 303. Meanwhile, enemy characters are placed within the battle field space at predetermined timings and perform actions such as movement according to predetermined behavior patterns. When the positional relationship (e.g., distance and orientation of each character) between the human character 301 (and mounted monster 303) and the enemy character satisfies the first condition, the battle processing unit 112A determines that the human character 301 (and mounted monster 303) has encountered the enemy character 305 and a battle has begun, and starts various processes related to the battle. On the other hand, when the enemy character is defeated (removed from the battle field space), or when the human character 301 (and mounted monster 303) is defeated by the enemy character, or when the positional relationship between the human character 301 (and mounted monster 303) and the enemy character satisfies the second condition, the battle processing unit 112A may determine that the battle has ended and terminate the various processes related to the battle.

[0086] Furthermore, the combat processing unit 112A may not define the start and end of combat, and may allow combat to begin seamlessly from movement in the field space. In this case, the combat processing unit 112A may start various combat-related processes when the operation reception unit 111 receives an input operation instructing a human character 301 or mounted monster 303 to perform a predetermined action (for example, an attack).

[0087] State (A) in Figure 4 shows the state in which combat between human character 301 and enemy character 305 has begun. If the combat processing unit 112A determines that combat has begun, the object control unit 114 may adjust the positions of human character 301 and weapon 302 so that human character 301 is holding weapon 302 as shown in the figure.

[0088] Enemy character 305 is a character that is not controlled by any user and is an NPC (non-player character) whose actions are controlled by the combat processing unit 112A according to a predetermined action pattern. Enemy character 305 may have the same appearance and abilities (movement and attack methods, etc.) as a mountable monster 303 or a type of automatic combat monster 304.

[0089] The combat processing unit 112A advances the battle between the human character 301 and the enemy character 305 in response to input operations such as attack, defense, dodge, and movement received by the operation reception unit 111. For example, if the operation reception unit 111 receives an input operation to command an attack, the combat processing unit 112A calculates the damage to be dealt to the enemy character 305 based on the attack power value of the human character 301 and the defense power value of the enemy character 305. The object control unit 114 controls the placement, movement, and pose of the human character 301, weapon 302, and enemy character 305 in response to the various processes carried out by the combat processing unit 112A.

[0090] Figure 4 (B) shows a state in which human character 301 is riding a mountable monster 303 and is in combat with enemy character 305. As described above, when human character 301 rides a mountable monster 303, he becomes unable to perform actions such as attacking, and the mountable monster 303 performs these actions on his behalf.

[0091] For example, in response to user input, the mounted monster 303 attacks the enemy character 305 using an attack method appropriate to its appearance and abilities, as shown in the illustration. This allows the mounted monster 303 to perform actions appropriate to its type, thereby increasing the strategic depth of combat. Consequently, the enjoyment of the game can be enhanced.

[0092] The combat processing unit 112A proceeds with the battle between the mounted monster 303 and the enemy character 305 according to the mounted monster's abilities. If an automated combat monster 304 is deployed, the combat processing unit 112A also executes the processing related to the battle between the automated combat monster 304 and the enemy character 305.

[0093] State (C) in Figure 4 shows the state after a battle has been won. For example, as shown in the figure, suppose a human character 301 fights alone and wins against an enemy character 305. In this case, the battle processing unit 112A grants the user reward items according to the content or result of the battle. Specifically, the battle processing unit 112A increases the value indicating the number of such reward items included in the user information 233. The battle processing unit 112A may also change the type and number of reward items granted according to the type and level of the enemy character 305, etc. Furthermore, the object control unit 114 or the display control unit 115 may place and display a UI object 306 or UI image 306 that indicates the type and number of reward items obtained (granted to the user) by the user.

[0094] As will be explained in more detail later, the combat processing unit 112A may determine which character to assign to the user if the number of reward items the user possesses exceeds a predetermined number after assigning the reward item. The assigned character may be any of the human character 301, mountable monster 303, or automatic combat monster 304, but it is preferable that it be either a mountable monster 303 or an automatic combat monster 304.

[0095] Human character 301, mountable monster 303, and automated combat monster 304 each have pre-set abilities specific to their individual characteristics. These ability settings are stored in the memory unit 120 as character data 233A.

[0096] On the other hand, if a player character such as human character 301 is defeated by enemy character 305, the data management unit 213 updates the number of players defeated by the enemy character 305 according to the content or result of the battle, improves the values ​​of various combat parameters (battle parameters) of the enemy character 305, and performs battle parameter update-related processing so that the improved battle parameters can be used when a player character (including a player character controlled by another user) next battles the enemy character 305. The battle parameter update-related processing will be described later.

[0097] (Character data) Figure 5 shows the data structure of character data 233A used to identify characters owned by a user. As shown in the figure, character data 233A is data in which an identification code that uniquely identifies a single character is associated with information indicating the type of character, its name, its rarity, the values ​​of various combat parameters (combat parameters), and information indicating the equipment that the character is equipped with (associated with the character). One record of character data 233A represents one single character. Note that character data 233A may include monsters with the same name. In other words, a user may possess multiple monsters with the same appearance.

[0098] The character type is information indicating whether the character is a human character, a mountable monster, or an auto-battle monster. The character name indicates the name of the character. In this embodiment, characters with the same name have the same appearance. Rarity indicates the difficulty of obtaining the character (so-called rarity). In the illustrated example, D has the lowest rarity and A has the highest rarity. Combat parameters are parameters that the combat processing unit 112A refers to during combat to execute combat-related processing.

[0099] The information indicating equipment shows the equipment associated with the character (i.e., the equipment the character is wearing). In the illustrated example, only human characters are shown wearing equipment, but mountable monsters and auto-battle monsters may also be able to wear equipment. When equipment is associated with a character, the combat processing unit 112A also refers to the parameters of the equipment, such as its attack power or defense power, when performing combat-related processing. For example, the combat processing unit 112A uses the value obtained by adding the attack power of the equipment to the character's attack power when calculating damage for the character's attack. Information indicating the equipment owned by the user and the parameters of that equipment is included in the user information 233.

[0100] (Combat procedures) In the game implemented by System 1, the user is granted a monster when either the combat granting process or the random granting process, as described below, is executed. In the game implemented by System 1, processes related to updating combat parameters may also be executed.

[0101] Figure 6 is a flowchart showing an example of the combat processing flow in System 1. When the game progress unit 112 of the user terminal 100 starts the game, the object control unit 114 places the player character and enemy characters, etc., in predetermined positions in a predetermined game space (for example, the field space), and the game progress unit 112 and the object control unit 114 operate the player character in response to the user's input (S100). Thereafter, the game progress unit 112 performs actions such as moving the player character, mounting a mount, and summoning an automatic combat monster 304 in response to the user's input. The object control unit 114 also places and operates enemy characters in the game space where the player character is placed, in positions determined according to the enemy character, in accordance with instructions from the game progress unit 112. In System 1, the type and number of enemy characters placed may be changed depending on the time of day, and the strength of the enemy characters (combat parameters described later) may also be changed depending on the time of day.

[0102] The game progress unit 112 and object control unit 114 execute the above-described control until the battle processing unit 112A determines that the player character has encountered an enemy character (NO in S102). If the relative positions of the player character and the enemy character satisfy the first condition, the battle processing unit 112A determines that the player character has encountered an enemy character (YES in S102). In this case, the battle processing unit 112A proceeds with various processes related to the battle and causes the player character (and automatic battle monsters) to fight the enemy character (S104). In the battle, the battle continues until a predetermined condition (second condition) is met (NO in S105). If there are multiple enemy characters, the battle processing unit 112A continues the battle between the player character and the other enemy characters.

[0103] If the second condition is met and the battle ends (YES in S105), the battle processing unit 112A determines whether the player character has defeated the enemy character (S106). If it is determined that the player character has defeated the enemy character (YES in S106), the process proceeds to S107. The processing of S107 and S108 will be explained after the processing of S109 and S110, and the battle assignment processing from S115 onwards will be explained first. Note that defeated enemy characters may be placed again in the game space played by the user who defeated them after a predetermined amount of time has elapsed, or they may not be placed in the game space played by the user when the number of times the enemy character has been defeated reaches a predetermined number (in this case, they may be moved to another game space).

[0104] In S115, the user is given reward items according to the outcome of the battle in which the player character won. Furthermore, the battle processing unit 112A determines whether a predetermined number of reward items have been accumulated (S116). If the predetermined number of reward items has not been accumulated (NO in S116), the battle processing unit 112A does not perform any further processing. On the other hand, if the predetermined number of reward items has been accumulated (YES in S116), the battle processing unit 112A consumes the predetermined number of reward items held by the user (S117) and determines the monster to be given to the user according to the reward items (S118). For example, the battle processing unit 112A determines the monster to be given to the user according to the type of reward item. The monster giving unit 112C gives the determined monster to the user (S119).

[0105] In this way, by granting users characters acquired through battle, a motivation for users to engage in combat can be provided. Furthermore, characters that can be granted to users through battle (characters that users can acquire) can participate in battle. Therefore, a motivation can be provided for users to try to use the characters they have acquired in battle, that is, to engage in further battles. Depending on the outcome of those battles, even more characters may be granted to the user. In this way, the two objectives of acquiring monsters and engaging in battle can be presented to the user in a cyclical manner, thus keeping users engaged and preventing them from getting bored.

[0106] Furthermore, by granting monsters when a certain number of reward items are accumulated, users can be motivated to repeatedly engage in battles and collect reward items.

[0107] Furthermore, it is desirable that the type of reward item corresponds one-to-one with the type of enemy character (for example, the name of the enemy character). For example, if a mountable monster appears as an enemy character, it is desirable that the combat processing unit 112A grants the reward item corresponding to that mountable monster. When a predetermined number or more of these reward items have been accumulated, the combat processing unit 112A may decide that the mountable monster appearing as an enemy character is the monster to be granted to the user.

[0108] This allows users to acquire enemy characters when they win battles. Therefore, it is easy to determine which characters can be acquired through battle.

[0109] Returning to S106, if it is determined that the player character has not won in S106, that is, if it is determined that the player character has been defeated by an enemy character, then in S109, it is determined whether or not the enemy character was of a specific type. A specific type of enemy character is a subset of all possible enemy characters, and is not limited to, for example, a mid-boss character or a final boss character, rather than a so-called "minion" character. Furthermore, if the player character is defeated in combat with multiple types of enemy characters at once, in S109, it may be determined whether or not a specific type of enemy character is included among those multiple types of enemy characters, whether or not the enemy character that delivered the final blow was of a specific type of enemy character, or whether or not the enemy character that dealt the most damage to the player character was of a specific type of enemy character.

[0110] In S109, if the enemy character that defeated the player character is not determined to be of a specific type, the combat process ends. On the other hand, if the enemy character that defeated the player character is determined to be of a specific type in S109, combat parameter update-related processing is performed in S110. In the combat parameter update-related processing, for example, information including combat parameters associated with the enemy character is updated to make it stronger or weaker for the player.

[0111] Figure 7 illustrates an enemy character table used to identify information associated with enemy characters that may be placed in the game space. The enemy character table is included in game information 232. Therefore, the data management unit 213 will perform actions such as adding, updating, or deleting the enemy character table included in game information 232 in response to instructions from the server processing unit 212 based on information from the user terminal. The updated enemy character table is sent to and stored on the user's terminal when the user logs in.

[0112] Figure 7(a) shows an example of an enemy character table in its initial state (when no user has yet played). As shown in the figure, the enemy character table is data that associates an identification code that uniquely identifies each enemy character with information indicating the type of enemy character, its name, a kill counter indicating the number of players it has defeated, its placement location (the type of game space in which it is placed and the coordinates in that game space), and the values ​​of various combat parameters (combat parameters). Among these, the information indicating the type of enemy character includes, for example, A indicating a final boss character, B indicating a mid-boss character, and C indicating a regular enemy character. In S109 of Figure 6, it is determined that the information indicating the type of enemy character is either A or B, but it is not limited to this. Also, since it is the initial state, the kill counter for all enemy characters is 0, and when a player character controlled by any user is defeated, the kill counter for the defeated enemy character is updated by 1. Note that the kill counter may be updated in association only with specific types of enemy characters. It should be noted that the enemy character table contains numerous enemy characters in addition to those shown in the illustration.

[0113] Figure 7(b) shows an example of the enemy character table after the combat parameter update process in S110 of Figure 6 has been performed, for example, when player character A, controlled by user A, is defeated by the Flame Dance Dragon with identification code A0001. In the combat parameter update process, the kill count counter of the Flame Dance Dragon that defeated player character A is updated from 0 to 1, and the combat parameters of the Flame Dance Dragon are improved so that it becomes stronger for the player as a result of defeating player character A. After defeating a player character, the enemy character is then repositioned with its damage and other stats reset (recovered) and becomes available for battle again. Furthermore, in subsequent battles, the combat processing unit 112A, not only for user A but also for other users playing, refers to the updated combat parameters to perform various battle-related processing. Therefore, regardless of which user controls the player character, the combat parameters when battling the Flame Dance Dragon are improved, making it a more challenging opponent for the player. This creates a situation where enemy characters become stronger even though the player character hasn't, which can evoke a sense of fear or disparity in the user and enhance their interest.

[0114] Furthermore, the combat processing unit 112A may refer to the updated combat parameters and kill count counter and change the display manner of the enemy characters placed in the game space according to these values. In the example in Figure 7(b), the display manner of the Flame Dance Dragon, whose kill count counter and combat parameters have been improved, may be changed to the state before the improvement. Specifically, the display color of the Flame Dance Dragon may be changed to a color closer to bright red, or the display size of the Flame Dance Dragon may be changed to a larger size. This allows the user to grasp the degree of improvement of the enemy character from its display manner.

[0115] Furthermore, while the combat parameter update process in the example shown in Figure 7(b) is updated to improve the combat parameters each time the kill count counter is incremented by 1, it is not limited to this. For example, the combat parameters may be updated to improve each time the kill count counter is updated (reaches) a predetermined number. For instance, instead of improving the combat parameters when the kill count counter is only updated by 1, the system may be set up to improve the combat parameters each time the kill count counter is incremented by a predetermined number, such as 5, as shown in Figure 7(c). In this case, the display of the enemy character may be changed each time the combat parameters improve.

[0116] Furthermore, the examples in Figures 7(b) and 7(c) show an example where, for all users, a single enemy character table is updated during the combat parameter update process, and the updated combat parameters and kill count counter are referenced by the combat processing unit 112A. However, it is also possible to have an enemy character table for each user, and during the combat parameter update process, the enemy character table of the defeated user is updated, so that the updated combat parameters and kill count counter are referenced by the combat processing unit 112A during the user's subsequent play. Alternatively, all users may belong to one of several groups, and as shown in Figure 7(d), an enemy character table may be set up for each group, and during the combat parameter update process, the enemy character table of the group to which the defeated user belongs is updated, so that the updated combat parameters and kill count counter are referenced by the combat processing unit 112A during the subsequent play of any user belonging to that group. All users may also be assigned to one of the groups by random draw. Furthermore, all users may be assigned to a group according to their skill level or proficiency (e.g., level). In this case, for example, users at levels 1-10 may be assigned to Group A, and users at levels 11-15 may be assigned to Group B. Alternatively, users at various levels may be evenly distributed so that the average level of users in each group is the same or similar.

[0117] Furthermore, in the combat parameter update process, if the combat parameters are increased without limit according to the value of the kill counter, there is a risk that the combat parameters will become too high, and the feeling of despair from being unable to win will outweigh the increased excitement due to the sense of fear and gap. For this reason, for example, an upper limit may be predetermined for each type of enemy character, and in the combat parameter update process, the value of the combat parameters may not increase beyond the upper limit determined for each enemy character, or the value of the combat parameters may be reduced to weaken the enemy character when the upper limit is reached. This prevents the feeling of despair from continuing due to being unable to win. When reducing the value of combat parameters, the combat parameters of enemy characters that have reached the upper limit may be returned to the initial state shown in Figure 7(a), or reduced to a value below the initial state. Also, the timing of reducing the value of combat parameters may be, for example, when the upper limit is reached, or when a predetermined period has elapsed since the upper limit was reached (for example, when one week has elapsed, or when a predetermined number of battles with the player character have been reached while the upper limit was reached).

[0118] We have explained an example of setting an upper limit, but instead of this, or in addition to this, if the upper limit is reached, the game space in which the enemy character that has reached the upper limit is located may be forcibly moved to a different game space. An example of this case will be explained using S107 and S108 in Figure 6. In S107, it is determined whether the enemy character defeated by the player character is a specific type of enemy character and whether its combat parameters have reached the upper limit. If it is determined in S107 that it is not a specific type of enemy character, or if it is a specific type of enemy character but its combat parameters have not reached the upper limit, the process proceeds to S115.

[0119] On the other hand, if it is determined in S107 that a specific type of enemy character has reached its upper limit in combat parameters, then in S108, a process is performed to reduce the value of the combat parameters so that the enemy character becomes weaker. The process of reducing the value of the combat parameters to make the character weaker may, for example, be a process to return to the initial state shown in Figure 7(a), or a process to reduce the value to a value below the initial state.

[0120] Furthermore, the enemy character in question has reached its upper limit within the current game space and has caused trouble for the player character. Therefore, in S108, the character may be forcibly moved to another game space. Specifically, if the character was placed in a game space corresponding to an outdoor space, it may be forcibly moved to a game space corresponding to an indoor space (a so-called dungeon), the surface world space, or the underworld space. In this case, the information of the enemy character's placement in the enemy character table is updated to specify the destination space and the coordinates in which it should be placed within that space. This allows enemy characters that have reached their upper limit to be used in other game spaces as well, giving the user an incentive to play in other game spaces.

[0121] [Effects of the Embodiment] According to the above embodiment, when an enemy character having predetermined parameters, namely combat parameters and a kill count counter, defeats the player, a process may be performed to improve the combat parameters for the next time the player battles the enemy character. This creates a phenomenon where the enemy character becomes stronger even though the player character has not, which can evoke a sense of fear or disparity in the user and enhance their interest. Furthermore, by changing the display of the enemy character according to the improved combat parameters, the user can grasp the degree of improvement of the enemy character from its display.

[0122] Furthermore, the combat parameters of enemy characters that have been improved by defeating a player character are referenced not only in battles against the player character controlled by the defeated user, but also in battles against player characters controlled by all other users, as shown in Figures 7(b) and (c). This allows the improved combat parameters to be shared among users, thereby enhancing the game's appeal. Note that the other users who share these parameters may not be limited to all users, but rather to users belonging to the same group as the defeated user, as shown in Figure 7(d), which is an example of a user who has a specific relationship with the defeated user. In this case, a sense of unity can be shared among the groups. Also, if the enemy character table is managed per user, the impact of one user being defeated will not be reflected in other users, allowing each user to progress through the game at their own pace.

[0123] Furthermore, the enemy characters eligible for improvement are limited to specific types of enemy characters that meet certain conditions. This allows for a greater variety of battles against specific types of enemy characters.

[0124] Furthermore, while certain types of enemy characters improve their combat parameters each time they defeat a player character, a process may be implemented to decrease the enemy character's combat parameters once they reach their upper limit, as shown in, for example, S107 and S108 in Figure 6. This prevents enemy characters from becoming too strong, leading to a prolonged sense of despair and making victory impossible.

[0125] Furthermore, player characters and enemy characters can be placed in any of several types of game spaces (virtual spaces). As shown in S106-S108 of Figure 6, enemy characters that have been defeated by a player character in the first type of virtual space and whose combat parameters have reached their upper limit, thus meeting certain conditions, can be moved to the second type of virtual space. If the combat parameters of an enemy character being moved have been improved, a process may be performed to decrease those combat parameters. This allows enemy characters that have reached their upper limit to be used in other game spaces as well, providing users with an incentive to play in other game spaces.

[0126] [Differentiation] In Figure 7(d) of the above embodiment, users belonging to the same group are shown as examples of users who share the improved combat parameters of a specific type of enemy character. However, this is not limited to users who have a specific relationship with the defeated user. Users who have a specific relationship with the defeated user may include, for example, users who are friends with the defeated user, users who follow or are followers of the defeated user, or users who share items with each other.

[0127] In the above embodiment, specific types of enemy characters were given as examples of enemy characters that can improve combat parameters by defeating the player character, but this is not limited to any enemy character that meets specific conditions. For example, enemy characters that meet specific conditions may be enemy characters that only appear in the game space during a specific period (e.g., during a festival, or during a specific time of day such as evening). Furthermore, the specific conditions are not limited to predetermined ones, but may change depending on whether it is a specific period or whether the current time of day is a specific time such as evening. This can further enhance the game's appeal.

[0128] In the above embodiment, the improvement value of the combat parameters of an enemy object that is improved by defeating a player character is illustrated in Figure 7(b), etc. However, the improvement value may be a predetermined value, a value that changes depending on the initial state of the combat parameters of the enemy object (for example, the higher the combat parameters, the greater the improvement value, and the lower the combat parameters, the smaller the improvement value), a value that changes depending on the skill level of the defeated user (player character) (for example, the higher the level, the greater the improvement value, and the lower the level, the smaller the improvement value), or a value that changes depending on the related information associated with the enemy object (for example, the more times the enemy object's name contains strong-sounding specific words such as "fire" or "lightning", the greater the improvement value, and the more times the enemy object's name contains weak-sounding specific words such as "small" or "sleep", the smaller the improvement value). This can further enhance the entertainment value.

[0129] In the above embodiment, an example of moving an enemy character to another game space was shown in S106 of Figure 6. However, for the player character, it may be possible to select the game space to play in from a menu screen or the like, or to enable play in other game spaces when special conditions are met. Special conditions may be met, for example, by reaching a predetermined level, completing a predetermined scenario by progressing through the game, or defeating an enemy character that has reached its upper limit, similar to S107 in Figure 6. This can provide the user with an incentive to progress through the game. Furthermore, if a specific condition is met by defeating an enemy character that has reached its upper limit, similar to S107 in Figure 6, the user who defeated the enemy character may be allowed to move to the game space to which the enemy character was forcibly moved and play there, enabling them to fight the enemy character again. This can provide the fun of chasing and fighting the enemy character.

[0130] In the above embodiment, an example was described in which the combat parameters of an enemy character are improved by defeating the player character. However, the system is not limited to this, and for example, the combat parameters may be improved overall by increasing the number of enemy characters deployed when the number of defeated enemy characters reaches a predetermined number after defeating the player character. In addition to or instead of defeating the player character, the combat parameters of enemy characters fighting against the player character controlled by the user may be improved or decreased based on the user's login status. Specifically, for example, when the percentage of time the user is logged in or the average number of logins per day is above a predetermined value, the combat parameters of enemy characters fighting against the player character controlled by the user may be decreased, and when the percentage of time the user is logged in or the average number of logins per day is below a predetermined value, the combat parameters of enemy characters fighting against the player character controlled by the user may be improved. This can encourage users to log in.

[0131] In the embodiments described above, Figure 7(b) shows an example where the predetermined condition for improving the combat parameters of an enemy character is met each time the player character is defeated, and Figure 7(c) shows an example where the predetermined condition is met each time the number of times the enemy character has been defeated reaches a predetermined number. However, the invention is not limited to these examples, and the predetermined condition may be made to change depending on the number of times the parameters have been improved. For example, when the number of times an enemy character's combat parameters have been improved is less than a predetermined number (e.g., 5), the predetermined condition may be met each time the player character is defeated. When the number of times an enemy character's combat parameters have been improved reaches a predetermined number (e.g., 5), the predetermined condition may be met each time the number of times the enemy character has been defeated reaches a predetermined number. This allows for a higher frequency of improvement in the initial stages, and then a gradual decrease in frequency after a certain level of improvement has been achieved.

[0132] (Character assignment by lottery) Next, we will explain the lottery-based monster distribution process. The lottery-based monster distribution process is the process of distributing monsters to the user according to the lottery results. Figure 8 is a flowchart showing an example of the flow of the lottery-based monster distribution process in System 1. The lottery-based monster distribution process shown in Figure 8 is started in the game when the user makes an input operation to instruct the lottery at any time of their choosing.

[0133] The operation reception unit 111 of the user terminal 100 receives an input operation to instruct a lottery (S200). When the operation reception unit 111 receives the input operation, the lottery unit 112B determines the monster to be given to the user by lottery (S202). The monster giving unit 112C gives the user the monster determined by the lottery unit 112B (S204). That is, the monster giving unit 112C adds the data of the monster determined by the lottery unit 112B (1 record in Figure 3) to the character data 233A contained in the user information 233 of the user terminal 100. Finally, the game progress unit 112 notifies the display control unit 115 of the lottery result in S202, and the display control unit 115 creates an image showing the lottery result and displays it on the display unit 152 (S206).

[0134] Furthermore, the user may be required to pay some kind of compensation in order to perform the lottery. For example, the game progress unit 112 may execute the process from S202 onwards if the user possesses a predetermined number or more of the predetermined lottery items, and may not execute the process from S202 onwards if the user does not possess a predetermined number or more of the predetermined lottery items. In addition, when the game progress unit 112 performs the process from S202 onwards, it may reduce the number of the lottery items stored in the user information 233 of the storage unit 120 by the predetermined number. That is, when the game progress unit 112 performs the process from S202 onwards, it may consume a predetermined number of lottery items.

[0135] In this way, by assigning characters determined by lottery to users, a motivation for users to participate in the lottery can be provided. Furthermore, characters that can be assigned to users through the lottery (characters that users can acquire) can participate in battles by associating them with the player character. Therefore, a motivation can be provided for users to try to use the characters they have acquired in battles, that is, to engage in battles further. Then, depending on the outcome of the battle, characters are assigned to the user as shown in Figure 6. In this way, by having users acquire monsters through lottery, a motivation can also be provided for users to control the player character and engage in battles. Therefore, a continuous goal can be given to users, and the game can be kept engaging and prevent them from getting bored.

[0136] Through the above process, users can experiment and change the actions performed in response to consecutive input operations. As a result, users can enjoy a variety of game developments in response to consecutive operations, further enhancing the game's appeal.

[0137] [Examples of implementation using software] The control blocks of the control unit 110 and the control unit 210 may be implemented by logic circuits (hardware) formed on an integrated circuit (IC chip) or the like, or by software.

[0138] In the latter case, the information processing device, which includes a control unit 210 or a control unit 110, or both, includes a computer that executes instructions for a program, which is software that realizes each function. This computer includes, for example, one or more processors and a computer-readable recording medium that stores the program. The object of the present invention is achieved when the processor reads the program from the recording medium and executes it in the computer. For example, a CPU (Central Processing Unit) can be used as the processor. As the recording medium, a "tangible medium that is not temporary," such as ROM (Read Only Memory), can be used, as well as tape, disk, card, semiconductor memory, programmable logic circuit, etc. It may also further include RAM (Random Access Memory) for deploying the program. Furthermore, the program may be supplied to the computer via any transmission medium capable of transmitting the program (such as a communication network or broadcast wave). In one aspect of the present invention, the program can also be realized in the form of a data signal embedded in a carrier wave, which is embodied by electronic transmission.

[0139] Furthermore, some or all of the means implemented by the program can also be implemented by hardware such as integrated circuits. Additionally, the program may be provided by being recorded on a non-transient recording medium readable by a computer. Recording mediums include, for example, hard disks, SD cards, DVDs, and servers on the internet.

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

[0141] [Note] The following summarizes some of the features of the present invention.

[0142] [assignment] The present invention aims to improve interest and appeal.

[0143] [Solution] (1) To the computer, A program that, when an enemy object having predetermined parameters defeats the player, improves those predetermined parameters when the player next battles the enemy object.

[0144] (2) If the enemy object defeats a player, the predetermined parameters for when another player next battles the enemy object are also improved.

[0145] (3) The other players are all other players that are different from the aforementioned player.

[0146] (4) The other player is a player who has a specific relationship with the player, among all other players different from the player.

[0147] (5) The enemy objects that are subject to improvement are enemy objects that meet specific conditions.

[0148] (6) The aforementioned specific conditions are conditions that change depending on the time of day.

[0149] (7) Each time the enemy object defeats a player, the predetermined parameters of the enemy object are improved. On the computer, The parameters of an enemy object that have been improved will be reduced once the specified parameters reach their upper limit.

[0150] (8) The improvement value of a predetermined parameter of an enemy object that is improved when the enemy object defeats the player is made to differ according to the relevant information associated with the enemy object.

[0151] (9) Each time the enemy object defeats a player, the predetermined parameters of the enemy object are improved. The aforementioned player and enemy object can be placed in any of several types of virtual spaces. On the computer, In the first type of virtual space, enemy objects that have been defeated by the player and whose specific conditions have been met can be moved from the first type of virtual space to the second type of virtual space. When a predetermined parameter of an enemy object whose position is being changed has been improved, that predetermined parameter of the enemy object is then decreased.

[0152] (10) By fulfilling special conditions, the player is moved from the first type of virtual space to the second type of virtual space, enabling him to fight against the enemy object whose predetermined parameters have been reduced.

[0153] (11) Even if the player's parameters do not improve, the predetermined parameters of the enemy object that defeated the player are improved.

[0154] (12) The display mode of the enemy object is changed according to the predetermined parameters of the improved enemy object.

[0155] (13) The predetermined parameters of the enemy object to be improved include the number of such enemy objects to be placed.

[0156] (14) Depending on the player's login status, the predetermined parameters when the player is fighting the enemy object may also be improved.

[0157] (15) To the computer, The predetermined parameters of an enemy object that has been defeated by the aforementioned player and whose specific conditions have been met are reduced to levels lower than those at the time the specific conditions were met.

[0158] (16) When an enemy object having predetermined parameters defeats the player and a predetermined condition is met, the predetermined parameters are increased when the player next battles the enemy object. The aforementioned predetermined conditions change depending on the number of times the improvement has been performed.

[0159] (17) The predetermined parameters that have been improved by defeating the aforementioned player shall not be improved for any other player other than the aforementioned player.

[0160] (18) The aforementioned enemy character is a non-player character.

[0161] (19) If an enemy object having predetermined parameters defeats the player, the predetermined parameters are increased when the player next battles the enemy object.

[0162] [Effects and Effects] According to the above solutions (1) to (19), by creating a phenomenon where enemy objects become stronger even though the player's strength does not increase, it is possible to create a certain sense of fear or disparity in the player, thereby improving the level of interest.

[0163] Furthermore, by changing the display mode of an enemy object according to its improved parameters, the player can understand the degree of improvement of the enemy object from its display mode.

[0164] Furthermore, the ability to share improved parameters among players can enhance the overall enjoyment of the game.

[0165] Furthermore, it allows for a wider variety of battles against specific enemy objects. It also prevents situations where certain enemy objects become too strong, leading to players feeling frustrated and unable to win.

[0166] Furthermore, enemy objects that have reached their upper limit can be utilized in other virtual spaces, providing players with an incentive to play in those other virtual spaces as well. [Explanation of symbols]

[0167] 1 System, 2 Network, 10,20 Processor, 11,21 Memory, 12,22 Storage, 13,23 Communication IF (Operation Unit), 14,24 Input / Output IF (Operation Unit), 15 Touchscreen (Display Unit, Operation Unit), 17 Camera (Operation Unit), 18 Distance Sensor (Operation Unit), 100 User Terminal (Information Processing Device), 110,210 Control Unit, 111 Operation Reception Unit, 112 Game Progression Unit, 113 Camera Placement Control Unit, 114 Object Control Unit, 115 Display Control Unit, 120,220 Memory Unit, 151 Input Unit (Operation Unit), 152 Display Unit, 200 Server, 211 Transmit / Receive Unit, 212 Server Processing Unit, 213 Data Management Unit, 231 Program, 232 Game Information, 233 User Information, 233A Character Data, 1010 Object, 1020 Controller (operating unit), 1030 storage medium

Claims

1. On the computer, A program that, when an enemy object having predetermined parameters defeats the player, improves those predetermined parameters when the player next battles the enemy object.

2. The program according to claim 1, wherein if the enemy object defeats a player, the predetermined parameters for when another player next battles the enemy object are also improved.

3. The program according to claim 2, wherein the other players are all other players different from the aforementioned player.

4. The program according to claim 2, wherein the other player is a player that has a specific relationship with the player among all other players different from the player.

5. The program according to claim 1, wherein the enemy object to be improved is an enemy object that satisfies specific conditions among the enemy objects.

6. The program according to claim 5, wherein the aforementioned specific condition is a condition that changes depending on the time of day.

7. Each time the aforementioned enemy object defeats the player, the predetermined parameters of the enemy object are improved. On the computer, The program according to claim 1, wherein, on the condition that the improved parameters of an enemy object reach an upper limit, the parameters of the enemy object are reduced.

8. The program according to claim 1, wherein the improvement value of a predetermined parameter of an enemy object, which is improved when the enemy object defeats the player, is made to differ according to the relevant information associated with the enemy object.

9. Each time the aforementioned enemy object defeats the player, the predetermined parameters of the enemy object are improved. The aforementioned player and enemy object can be placed in any of several types of virtual spaces. On the computer, In the first type of virtual space, enemy objects that have been defeated by the player and whose specific conditions have been met can be moved from the first type of virtual space to the second type of virtual space. The program according to claim 1, which, when it has improved a predetermined parameter of an enemy object whose position is to be changed, lowers the predetermined parameter of said enemy object.

10. The program according to claim 9, which, by fulfilling special conditions, rearranges the player from the first type of virtual space to the second type of virtual space, enabling them to battle against the enemy object whose predetermined parameters have been reduced.

11. The program according to claim 1, which improves predetermined parameters of an enemy object that defeated the player, even if the player's parameters do not improve.

12. The program according to claim 1, which changes the display mode of an enemy object according to predetermined parameters of the improved enemy object.

13. The program according to claim 1, wherein the predetermined parameters of the enemy object to be improved include the number of such enemy objects to be placed.

14. The program according to claim 1, further improving the predetermined parameters when a player battles an enemy object, depending on the player's login status.

15. On the computer, The program according to claim 1, which lowers predetermined parameters of an enemy object that has been defeated by the player and for which specific conditions have been met, to a level lower than that before the specific conditions were met.

16. When an enemy object with predetermined parameters defeats the player and a predetermined condition is met, the predetermined parameters are improved when the player next battles the enemy object. The program according to claim 1, wherein the predetermined conditions change according to the number of times the improvement has been made.

17. The program according to claim 1, wherein a predetermined parameter improved by defeating the aforementioned player is not improved for other players different from the aforementioned player.

18. The program according to claim 1, wherein the enemy object is a non-player character.

19. A system that, when an enemy object having predetermined parameters defeats a player, improves those predetermined parameters when the player next battles the enemy object.

Images