JP7638709B2 - program - Google Patents

Description

An embodiment of the present invention relates to a program.

Games are known in which characters and other objects are placed in a virtual game space, and the characters take action in response to the player's operations. The player causes the character to take a desired action by inputting commands or performing touch operations. For example, in a game in which the playable character battles enemy characters encountered in the game space, the player performs operations such as having the playable character attack the enemy character or evade the enemy character's attacks.

Here, in the game space, it is possible that the playable character will be surrounded by enemy characters from all sides and will be attacked by one of the surrounding enemy characters. In such a case, a player who is concentrating on controlling the playable character on the two-dimensional display may not be able to respond appropriately to the attacks of the surrounding enemy characters. Even if the player is skilled in controlling the playable character, it is difficult to avoid such attacks, and even if the player strengthens the parameters of the playable character, such as the defensive power, unexpected damage cannot be avoided.

In order to notify the player in advance of attacks from around the controlled character, a technology has been proposed that displays an alert marker on the game screen that indicates the approximate location of the enemy character that has locked on to the controlled character (see, for example, non-patent document 1).

Game Strategy Complete Guide, Dolls Order (Dolloda) Strategy Wiki, [online], searched on November 10, 2020, Internet <URL: https://www.dopr.net/dolls-order/lock-on>

However, Non-Patent Document 1 displays an alert marker at either the top, bottom, left, or right edge of the game screen, and is unable to accurately indicate the position of enemy characters in a 360-degree direction. If the positions of enemy characters were displayed in a 360-degree direction, the number of markers would be enormous, making the display cumbersome. In addition, when displayed at the edge of the game screen, it is difficult to easily perceive the positional relationship between the controlled character and enemy characters.

In addition, for a player who is concentrating on controlling a playable character, controlling the playable character while staring at alert markers at the top, bottom, left, and right of the game screen not only causes the player to neglect controlling the playable character, but also causes eye fatigue. This can result in a decrease in the player's immersion in the game.

This invention was made with the above in mind, and its purpose is to provide a technology that presents players with displays that enhance their sense of immersion in the game.

To solve the above problem, a first aspect of the present invention is a program executed by a computer, which causes the computer to display a first object controlled by a player, and to display a third object within a predetermined range from the first object, indicating the presence of a second object attempting to attack the first object.

According to the program according to the first aspect of the present invention, a third object is displayed within a predetermined range from a first object operated by a player, indicating the presence of a second object attempting to attack the first object. This allows the player to intuitively perceive the relationship between the first object and the second object operated by the player from the third object, thereby enhancing the player's sense of immersion in the game.

FIG. 1 is a diagram showing an example of the overall configuration of a game system related to a game program according to an embodiment. FIG. 2 is a diagram illustrating an example of a functional configuration of the server in the game system illustrated in FIG. FIG. 3 is a diagram showing an example of a functional configuration of a user terminal in the game system shown in FIG. FIG. 4 is a diagram showing a first example of a game screen realized by a game program according to an embodiment. FIG. 5 is a flowchart showing an example of an information processing operation of the user terminal shown in FIG. FIG. 6 is a flow chart showing the details of the enemy determination process among the processes shown in FIG. FIG. 7 is a flowchart showing the details of the risk determination process of the processes shown in FIG. FIG. 8A shows a second example of a game screen realized by a game program according to an embodiment. FIG. 8B shows a third example of a game screen realized by a game program according to an embodiment. FIG. 8C shows a fourth example of a game screen realized by a game program according to an embodiment. FIG. 8D shows a fifth example of a game screen realized by a game program according to an embodiment. FIG. 9 shows a sixth example of a game screen realized by a game program according to an embodiment. FIG. 10 shows a seventh example of a game screen realized by a game program according to an embodiment. FIG. 11 shows a modified example of the display mode of the aiming UI realized by the game program according to one embodiment.

Below, an embodiment of the present invention will be described with reference to the drawings. In the following, elements that are the same or similar to elements already described will be given the same or similar reference numerals, and duplicated descriptions will generally be omitted. For example, when there are multiple identical or similar elements, a common reference numeral may be used to describe each element without distinguishing between them, and a subnumber may be used in addition to the common reference numeral to describe each element with distinction between them.

[One embodiment]
The program according to one embodiment is a program for implementing a game on a terminal device (hereinafter referred to as a "user terminal") used by a game player (hereinafter referred to as a "user"). Hereinafter, the program according to one embodiment will be referred to as a game program, to distinguish it from programs for implementing the functions of a general computer.

The game realized by the game program according to one embodiment may be any type of game, such as a role-playing game (RPG), action game, adventure game, simulation game, training game, shooting game, sports game, puzzle game, etc. The game realized by the game program according to one embodiment may also be a part of such a game (mini-game, quest, event, etc.).

A game program according to one embodiment places a game character as a first object and an enemy object as a second object in a game space, and realizes a game in which the enemy object and the game character battle each other. An example of a game character is a playable character. An example of an enemy object is an enemy character.

The game character as the first object is not limited to a human or anthropomorphized character, but may be any object capable of performing an action in response to a user's operation. The game character may avoid an attack by an enemy object, or attack or counterattack an enemy object, in accordance with the user's operation.

The enemy object as the second object is also not limited to a character, and may be any object that inflicts damage on the in-game parameters of the first object. The second object may be a player character operated by another user, or an NPC (Non Player Character) that does not accept operation by the player. The second object may also be an object such as a trap.

The game program according to one embodiment further displays a user interface (UI) as a third object within a predetermined range from a first object on the game screen, the third object indicating the presence of a second object attempting to attack the first object. Hereinafter, this third object is referred to as an "aiming UI." The aiming UI is intended to allow the user to intuitively perceive the presence of an enemy object. The aiming UI may include a fourth object having a shape indicating the direction in which the second object is located.

A game program according to one embodiment may be a game program that realizes a game locally on one user terminal, a game program that realizes a game in cooperation with a user terminal and a server, a game program that realizes a game in cooperation with multiple user terminals (either via the server or not), and so on. As a mere example, the following describes a game system in which a server comprehensively manages game programs, transmits game programs and related data in response to requests from user terminals, and the actual game progress is realized mainly on user terminals. In addition, the following mainly describes a game expressed with a three-dimensional (3D) game space and 3D objects, but the present invention is not limited to this and the present embodiment can also be applied to a game expressed with a two-dimensional (2D) game space and 2D objects.

(1) Configuration (1-1) Game System FIG. 1 is a diagram showing an example of the overall configuration of a game system related to a game program according to an embodiment.
The game system 1 includes a plurality of user terminals 100 and a server 200. Each user terminal 100 is capable of communicating with the server 200 via a network NW. Any number of user terminals 100 can be connected to the server 200, but for simplicity, the detailed configuration of only one user terminal 100 will be illustrated and described.

The network NW is, for example, the Internet, and may include access networks such as a LAN (Local Area Network), a WAN (Wide Area Network), a mobile communication network, a wired telephone network, an FTTH (Fiber To The Home), and a CATV (Cable Television) network.

The user terminal 100 is a terminal used by a user to play a game, and executes a game program according to one embodiment to realize the game and output display information of the game screen according to the progress of the game. The user terminal 100 is, for example, a mobile terminal such as a smartphone, a tablet terminal, or a notebook personal computer. The user terminal 100 may be a stationary computer such as a desktop personal computer. The user terminal 100 may also be a dedicated game terminal suitable for game play. In the following, as an example, the user terminal 100 will be described as being a smartphone equipped with a touch screen.

The server 200 is a device operated and managed by, for example, a game developer, etc., and comprehensively manages the game program and user information according to one embodiment, and supports the progress of the game on the user terminal 100. The server 200 may be a general-purpose computer such as a workstation or a personal computer. For example, the server 200 accepts user information and various requests from the user terminal 100 via the network NW, and transmits the game program and related data to the user terminal 100 via the network NW. The server 200 can simultaneously send and receive information to multiple user terminals 100, and can support the progress of the game on multiple user terminals 100 in parallel.

The user terminal 100 may receive the game program and necessary setting data from the server 200 at once, and thereafter proceed with the game without communicating with the server 200. Alternatively, the user terminal 100 may communicate with the server 200 as the game progresses, and receive the necessary game program or data from the server 200 each time.

(1-2) Hardware Configuration (1-2-1) Server As shown in FIG. 1, the server 200 comprises, as hardware, a processor 2001, a memory 2002, a storage 2003, a communication interface (communication I/F) 2004, and an input/output interface (input/output I/F) 2005, which are electrically connected to each other via a bus 2006.

The processor 2001 controls the operation of the entire server 200. The processor 2001 includes, for example, a general-purpose processor such as a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit). The processor 2001 is not limited to a general-purpose processor, and may be a dedicated processor such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array).

Memory 2002 is a main storage device and includes ROM (Read Only Memory) and RAM (Random Access Memory), etc.

Storage 2003 is an auxiliary storage device, and includes a non-volatile storage device such as a hard disk drive (HDD) or a solid state drive (SSD). Storage 2003 stores programs executed by processor 2001, setting data required for executing the programs, and the like. Part of the programs may be stored in ROM.

The processor 2001 can realize the processing functions described below by reading a program from the storage 2003, expanding it in the memory 2002, and interpreting and executing the expanded program.

The communication interface (communication I/F) 2004 is a module for communicating with external devices such as the user terminal 100 via the network NW, and includes a signal processing circuit for transmission and reception, an optical connector, etc. The communication interface 2004 may include, for example, an optical communication module.

The input/output interface (input/output I/F) 2005 takes in operation data input by an operator via input devices such as a keyboard or mouse, and outputs output data to output devices such as a liquid crystal or organic EL (Electro Luminescence) display or a speaker.

(1-2-2) User Terminal As shown in FIG. 1, the user terminal 100 comprises, as hardware, a processor 1001, a memory 1002, a storage 1003, a sensor 1004, a communication interface (communication I/F) 1005, an input/output interface (input/output I/F) 1006, and a touch screen 1007, which are electrically connected to each other via a bus 1008.

The processor 1001 controls the overall operation of the user terminal 100. The processor 1001 includes, for example, a general-purpose processor such as a CPU, an MPU, or a GPU. The processor 1001 is also not limited to a general-purpose processor, and may be a dedicated processor such as an ASIC or an FPGA.

Memory 1002 is a main storage device and includes ROM, RAM, etc.

Storage 1003 is an auxiliary storage device, and includes built-in or external semiconductor memory (e.g., flash memory), etc. Storage 1003 stores programs executed by processor 1001, setting data required for executing the programs, etc. Part of the programs may be stored in ROM.

The processor 1001 can realize the processing functions described below by reading a program from the storage 1003, expanding it in the memory 1002, and interpreting and executing the expanded program.

The sensor 1004 is, for example, an image sensor, an acceleration sensor, an angular velocity sensor, a geomagnetic sensor, a GPS sensor, a proximity sensor, an ambient light sensor, etc. The sensor 1004 converts various sensed information into an electrical signal and outputs it.

The communication interface (communication I/F) 1005 is a module for communicating with external devices such as the server 200 via the network NW, and includes a signal processing circuit for transmission and reception, an antenna, a LAN terminal, etc. The communication interface 1005 may include, for example, a module for mobile communication, a module for wireless/wired LAN, a module for short-range wireless communication, etc.

The input/output interface (input/output I/F) 1006 takes in input data from an external device and outputs output data to an external device. The input/output interface 1006 may include, for example, a physical button on the user terminal 100, a speaker built into the user terminal 100, a USB (Universal Serial Bus) port, etc.

The touch screen 1007 includes an input unit 1071 and a display unit 1072, and has the function of accepting input operations from the user and presenting display information to the user.

The input unit 1071 is, for example, a capacitive or resistive touch panel. The input unit 1071 detects the position touched by the user's finger or a touch pen (stylus pen) and generates information indicating that position.

The display unit 1072 is, for example, a liquid crystal display or an organic EL display, and displays various display information including the game screen.

The user terminal 100 can also accept user operations from an external input device such as a keyboard, mouse, or controller connected via the input/output interface 1006. The user terminal 100 can also acquire game programs and related data from an external storage device such as a memory card connected via the input/output interface 1006. The user terminal 100 can also output display information to an external output device such as a display or speaker connected via the input/output interface 1006. The user terminal 100 can use an external storage device such as a memory card connected via the input/output interface 1006 as storage 1003. The user terminal 100 can also accept signals from the sensor 1004 as user operations.

(1-3) Functional Configuration (1-3-1) Server Fig. 2 is a diagram showing an example of the functional configuration of the server 200 in the game system 1 shown in Fig. 1. Note that illustrations and descriptions of the functional configuration of a general computer and well-known configurations necessary to realize a game are omitted.

The server 200 has a function of communicating with each user terminal 100 and supporting the progress of the game in the user terminal 100. For example, the server 200 has a function of transmitting a game program, related data required for executing the game program, and the like to each user terminal 100 in response to a request from each user terminal 100.
The server 200 includes a control unit 210 and a storage unit 220 .

The memory unit 220 can be realized by the storage 2003, and includes a game program memory unit 221, a game information memory unit 222, and a user information database (DB) 223.

The game program storage unit 221 stores a game program according to one embodiment.

The game information storage unit 222 stores various game information that is referenced when executing a game program according to one embodiment.

The user information database (DB) 223 is a database that stores information about users associated with each user terminal 100, for example, user account information.

The control unit 210 is realized by the processor 2001 and the memory 2002, and controls the overall functions of the server 200. According to one embodiment, the control unit 210 can function as a reception control unit 211, a transmission control unit 212, and a game progression unit 213 by executing a game program stored in the game program storage unit 221.

The reception control unit 211 receives, from each user terminal 100, user information, requests to send programs or related data, information regarding the progress of the game on each user terminal 100, etc.

The transmission control unit 212 transmits the requested program or related data, or an updated program, etc., to each user terminal 100. The transmission control unit 212 may also request each user terminal 100 to transmit information regarding the progress of the game.

The game progression unit 213 refers to the game information stored in the game information storage unit 222 and the account information stored in the user information database 223 according to the code written in the game program, and manages the progress of the game on each user terminal 100. The game progression unit 213 can also determine whether or not it is necessary to collect information from each user terminal 100, and whether or not it is necessary to transmit data to each user terminal 100.

For example, the control unit 210 receives a request to transmit a game program from the user terminal 100 via the reception control unit 211, determines the game program and related data to be transmitted to the user terminal 100 via the game progression unit 213, and transmits the determined game program and related data to the user terminal 100 via the transmission control unit 212.

(1-3-2) User Terminal Fig. 3 is a diagram showing an example of the functional configuration of a user terminal 100 that can be used in the game system 1 shown in Fig. 1. Note that illustrations and descriptions of the functional configuration of a general computer and well-known configurations necessary to realize a game are omitted.
The user terminal 100 includes a control unit 110 and a storage unit 120 .

The memory unit 120 can be realized by the storage 1003, and includes a game program memory unit 121, a game information memory unit 122, and a UI information memory unit 123.

The game program storage unit 121 stores a game program according to one embodiment.

The game information storage unit 122 stores various game information that is referenced when executing a game program according to one embodiment. The game information includes, for example, information about objects placed in the game space. The game space may be a space related to the entire game realized by the game program or a space related to a part of the game. The object information may include field information such as the terrain of the game space, position information of enemy characters that appear in the game space, attribute information of enemy characters (e.g., attack power, defense power, skill), and action modes that appearing enemy characters can take (e.g., non-attack mode, attack mode).

The UI information storage unit 123 stores UI information necessary to generate UI objects used in the game, including an aiming UI. The UI information may include, for example, information for generating an aiming UI according to the danger level and attack state of an enemy character.

The control unit 110 is realized by the processor 1001 and the memory 1002, and controls the overall functions of the user terminal 100. According to one embodiment, the control unit 110 can function as an operation reception unit 111, a game progression unit 112, a position information acquisition unit 113, an enemy determination unit 114, a danger level determination unit 115, a UI control unit 116, a virtual camera control unit 117, and a display control unit 118 by executing a game program stored in the game program storage unit 121.

The operation reception unit 111 receives operations input from the user via the input unit 1071, and, for example, generates a command in response to the user's operation and passes it to the game progression unit 112.

The game progression unit 112 refers to the game information stored in the game information storage unit 122 according to the code written in the game program, and performs processing to place objects in the game space and progress the game. When the game progression unit 112 receives a user operation, it determines the action corresponding to the user operation and the result of that action, and passes it to the display control unit 118 to generate display information.

The position information acquisition unit 113 acquires position information of the playable character and enemy character in the game space from the game information storage unit 122. The position information of the playable character and enemy character is expressed, for example, as two-dimensional or three-dimensional position coordinates in the game space. The position information acquisition unit 113 calculates the latest position coordinates of the playable character in cooperation with the game progression unit 112, for example, based on the information stored in the game information storage unit 122.

The enemy determination unit 114 calculates the distance between the operation character and the enemy character based on the position information of the operation character and the enemy character acquired by the position information acquisition unit 113. The enemy determination unit 114 also determines whether or not an enemy character is present within a certain range from the operation character based on the calculated distance. The certain range in which the enemy determination unit 114 determines the presence or absence of an enemy character is set, for example, as an area inside a circle or sphere of a certain radius centered on the position coordinates of the operation character. The certain radius may be set arbitrarily by a game designer or the like. The certain range may also be an area inside another shape, such as a square or cube centered on the operation character. The certain range may be wider or narrower than the game space represented by the game screen displayed on the display unit 1072. The enemy determination unit 114 further acquires various information related to the enemy character determined to be within a certain range from the operation character, and performs processing to pass the information to the danger level determination unit 115.

The danger level determination unit 115 determines the danger level of the enemy character based on the information about the enemy character received from the enemy determination unit 114, and passes the determined danger level to the UI control unit 116.

Here, the danger level represents the degree of danger that the playable character faces from an attack by an enemy character. For example, when the playable character is attacked by an enemy character, parameters such as stamina decrease, or a status abnormality occurs. The danger level determination unit 115 may determine the danger level, for example, based on whether the enemy character is in attack mode or non-attack mode. Here, attack mode refers to a state in which the enemy character aims an attack at the playable character and is in an attack preparation state in which the enemy character's attack will be launched within a short, predetermined time. Non-attack mode refers to a state in which an attack from the enemy character will not be launched within a predetermined time. In one embodiment, the danger level determination unit 115 determines the danger level in four stages: "high," "medium," "low," and "0 (zero)." The determination of the danger level by the danger level determination unit 115 will be described further below.

The UI control unit 116 performs processing to generate an aiming UI to be displayed on the game screen by referencing information stored in the UI information storage unit 123. According to one embodiment, the UI control unit 116 generates an aiming UI indicating the presence of an enemy character based on the determination result of the enemy determination unit 114. The UI control unit 116 can also control the display mode of the aiming UI depending on the determination result of the danger level determination unit 115.

The virtual camera control unit 117 controls the shooting range (field of view) of a virtual camera (not shown) placed in the game space. The virtual camera control unit 117 controls the position, orientation, and number of virtual cameras of the virtual camera according to instructions from the operation reception unit 111 or the game progression unit 112. The virtual camera control unit 117 passes shooting information of the game space captured by the virtual camera to the display control unit 118.

The display control unit 118 generates display information for the game screen based on the shooting information received from the virtual camera control unit 117, the object information received from the game progression unit 112, and the UI information received from the UI control unit 116, and outputs it to the display unit 1072.

(1-4) Overview of the Aiming UI Fig. 4 shows an example of a game screen including an aiming UI realized by a game program according to an embodiment. In the example of Fig. 4, a game screen 50 includes a playable character 10, enemy characters 30A, 30B, and 30C (collectively referred to as "enemy characters 30"), and an aiming UI 20, which are arranged in a game space.

The playable character 10 is depicted here as a swordsman object holding a sword. The playable character 10 can be displayed approximately in the center of the game screen 50.
The enemy character 30 is depicted here as a monster object that can attack the playable character 10. The enemy character 30 is placed in the game space and displayed within the game screen 50 under the control of the game progression unit 112.

The aiming UI 20 is displayed within a predetermined range from the playable character 10 to indicate the presence of the enemy character 30. The predetermined range from the playable character 10 may be any range that is within the user's field of vision when the user gazes at the playable character 10, and may be set arbitrarily by a game designer or the like. For example, the aiming UI 20 is displayed along a range provided below the playable character 10. An example of a range provided below the playable character 10 is near the feet of the playable character 10. In FIG. 4, as an example, the aiming UI 20 is displayed along a 360-degree virtual circle (a circular or ring-shaped range) approximately centered on the position coordinates of the playable character 10 near the feet of the playable character 10. The aiming UI 20 may include arc-shaped portions 21A, 21B, 21C, and 21D (collectively referred to as "arcs 21") indicating the presence of the enemy character 30, and protruding portions 22A, 22B, 22C, and 22D (collectively referred to as "protrusions 22") indicating the direction of the enemy character 30. The protrusions 22 are an example of a fourth object having a shape indicating the direction in which the enemy character 30 exists. In this example, the arc-shaped portions 21B, 21C, and 21D are combined to form one arc. The protruding portions 22A, 22B, 22C, and 22D are disposed approximately at the center of the arc-shaped portions 21A, 21B, 21C, and 21D, respectively. The protruding portion 22A indicates the direction of the enemy character 30A. The protruding portion 22B indicates the direction of the enemy character 30B. The protruding portion 22C indicates the direction of the enemy character 30C. The protruding portion 22D indicates the direction of an enemy character 30 that is not displayed on the game screen 50 but exists within a certain range. The aiming UI 20 may include either the arc 21 or the protrusion 22. For example, the aiming UI 20 may indicate the direction of the enemy character 30 by changing the color or shape of the arc 21.

The aiming UI 20 continues to point at the enemy character 30 with at least one of the arc 21 or the protrusion 22. The aiming UI 20 moves on the circumference of a circle approximately centered on the playable character 10 in accordance with changes in the positional relationship between the playable character 10 and the enemy character 30, and can continue to indicate the direction of the enemy character 30 as seen by the playable character 10 in real time. As an example, the aiming UI 20 is displayed so that the position coordinates of the playable character 10, the position coordinates of the protrusion 22, and the position coordinates of the enemy character 30 pointed to by the protrusion 22 are always aligned approximately in a straight line.

The aiming UI 20 may further be displayed in a color according to the danger level of the enemy character 30. In the example of FIG. 4, the arc-shaped portion 21A and the protruding portion 22A are darker hatched, indicating that the enemy character 30A is more dangerous. The arc-shaped portion 21B and the arc-shaped portion 21C and the protruding portion 22B and the protruding portion 22C are lighter hatched, indicating that the enemy characters 30B and 30C are less dangerous than the enemy character 30A. The arc-shaped portion 21D and the protruding portion 22D are not hatched, indicating that the enemy character 30 not displayed on the game screen 50 is less dangerous than the enemy characters 30A, 30B, and 30C. The display mode according to the danger level is not limited to color, and may be expressed in various ways, such as the thickness of the arc 21, the size of the protrusion 22, or the brightness of the entire aiming UI 20.

This aiming UI 20 allows the user to easily and intuitively perceive the presence of enemy characters 30 that may attack the playable character 10 and the level of danger for each of them, enhancing the user's immersion in the game.

(2) Operation FIG. 5 is a flowchart showing an example of an information processing operation of the user terminal 100 shown in FIG.
The premise for the following operations is that the control unit 110 and memory unit 120 of the user terminal 100 work together to progress the game in accordance with the codes written in the game program, and generate display information for the game screen.

(2-1) Acquisition of Position Information First, in step S1, the position information acquisition unit 113 acquires position information (e.g., position coordinates in the game space) of the playable character 10 and enemy characters 30 in the game space from the game information storage unit 122. The position information acquisition unit 113 acquires position information of all enemy characters 30 present in the game space. The position information acquisition unit 113 passes the acquired position information to the enemy determination unit 114.

(2-2) Enemy Determination Process In step S2, the enemy determination section 114 performs enemy determination process to determine whether or not an enemy character 30 is present within a certain range from the operated character 10.

Figure 6 is a flowchart showing the details of the enemy determination process in step S2.

In step S201, the enemy determination unit 114 calculates the distance between the playable character 10 and a specific enemy character 30 based on the position information of the playable character 10 and the enemy character 30 received from the position information acquisition unit 113.

In step S202, the enemy determination unit 114 determines whether the calculated distance is equal to or less than a preset first threshold. If the calculated distance is equal to or less than the first threshold (YES), the process proceeds to step S203. If the calculated distance is greater than the first threshold (NO), the process proceeds to step S205.

In step S203, the enemy determination unit 114 determines that the enemy character 30 is within a certain range from the playable character 10.

In step S204, the enemy determination unit 114, in cooperation with the game progression unit 112, obtains information on the enemy character 30 determined to be within a certain range (hereinafter, "enemy information") from the game information storage unit 122. The obtained enemy information may include information on the enemy character 30's operation mode, status, skills, etc. The operation mode also includes information on whether the enemy character 30 is in attack mode or non-attack mode, whether the enemy character 30 has begun an attack, whether the enemy character 30 has noticed the playable character 10, and whether the enemy character 30 is asleep or fallen. The enemy determination unit 114 passes the obtained enemy information together with the position information of the enemy character 30 to the danger level determination unit 115 at any timing.

On the other hand, in step S205, the enemy determination unit 114 determines that the enemy character 30 is not within a certain range from the playable character 10.

In step S206, the enemy determination unit 114 determines whether or not all enemy characters are present within a certain range from the playable character 10. If there is an enemy character 30 that has not yet been determined (NO), the enemy determination unit 114 proceeds to step S201 and repeats the processing of steps S201 to S205. When determination has been completed for all enemy characters 30 (YES), the enemy determination unit 114 ends the enemy determination process.

(2-3) Danger Level Determination Processing In step S3, the danger level determination section 115 performs a danger level determination process to determine the danger level of the enemy character 30 determined to be within a certain range from the playable character 10 based on the enemy information received from the enemy determination section 114.

Figure 7 is a flowchart showing the details of the danger level determination process in step S3. As an example, the danger level determination process based on the movement mode of the enemy character 30 will be described here.

In step S301, the danger level determination unit 115 determines whether the enemy character 30 is in attack mode. If the enemy character 30 is in attack mode (YES), the process proceeds to step S302. If the enemy character 30 is not in attack mode (non-attack mode) (NO), the process proceeds to step S305.

In step S302, the danger level determination unit 115 determines whether or not the enemy character 30 has begun an attack. If the enemy character 30 has not begun an attack (NO), the process proceeds to step S303. If the enemy character 30 has begun an attack (YES), the process proceeds to step S304.

In step S303, the danger level determination unit 115 determines that the enemy character 30 is "danger level = medium" and proceeds to step S308. In this example, "danger level = medium" means that the enemy character 30 is within a certain range of the playable character 10 and is in attack mode, but has not yet started attacking.

In step S304, the danger level determination unit 115 determines that the enemy character 30 is "high danger level" and proceeds to step S308. In this example, "high danger level" means that the enemy character 30 is within a certain range of the playable character 10, is in attack mode, and has begun an attack.

On the other hand, if the enemy character 30 is not in the attack mode, in step S305, the danger level determination unit 115 determines whether or not there is a possibility that the enemy character 30 will transition to the attack mode. For example, if the enemy character 30 notices the playable character 10, the danger level determination unit 115 determines that there is a possibility that the enemy character 30 will transition to the attack mode. For example, if the enemy character 30 does not notice the playable character 10, if the enemy character 30 has reached zero vitality and is collapsed, or if the enemy character 30 is asleep, the danger level determination unit 115 determines that there is no possibility that the enemy character 30 will transition to the attack mode. The rules for determining the possibility of transitioning to the attack mode may be arbitrarily set in advance by a game designer or the like. If it is determined that there is a possibility that the enemy character 30 will transition to the attack mode (YES), the process proceeds to step S306. If it is determined that there is no possibility that the enemy character 30 will transition to the attack mode (NO), the process proceeds to step S307.

In step S306, the danger level determination unit 115 determines that the enemy character 30 is "danger level = low", and proceeds to step S308. In this example, "danger level = low" means that the enemy character 30 is within a certain range of the playable character 10 but is not in attack mode, and will not immediately attack the playable character 10, but may switch to attack mode.

In step S307, the danger level determination unit 115 determines that the enemy character 30 has a "danger level = 0 (zero)" and proceeds to step S308. Note that "danger level = 0" is merely a convenient expression to indicate that the danger level is below a predetermined level, and is not intended to be limited to the numerical value "0". In this example, "danger level = 0" (danger level below a predetermined level) means that the enemy character 30 is within a certain range of the playable character 10 but is not in attack mode and is not likely to switch to attack mode.

In step S308, the danger level determination unit 115 determines whether or not the danger level determination process has been completed for all enemy characters 30 determined by the enemy determination unit 114 to be within a certain range of the playable character 10. If there are enemy characters 30 for which determination has not yet been performed (NO), the process proceeds to step S301, and the processes of steps S301 to S307 are repeated. When determination has been completed for all enemy characters 30 (YES), the danger level determination process ends. The danger level determination unit 115 passes the determined danger level to the UI control unit 116 along with information on each enemy character 30.

The danger level determination process flow shown in FIG. 7 is merely an example, and the danger level determination unit 115 may determine the danger level using other criteria. For example, the danger level determination unit 115 may determine the danger level based on the distance between the enemy character 30 and the playable character 10 as an alternative to or in addition to whether the enemy character 30 is in attack mode or non-attack mode. As an example, the danger level determination unit 115 may use a second threshold value smaller than the first threshold value used by the enemy determination unit 114 to determine that if the distance between the enemy character 30 and the playable character 10 is equal to or less than the second threshold value, the danger level is high, and if the distance is greater than the second threshold value, the danger level is low. The danger level determination unit 115 may determine the danger level based on status information such as the attack power and defense power of the enemy character 30 acquired as enemy information. As an example, the danger level determination unit 115 may determine the danger level as "high" if the attack power of the enemy character 30 is equal to or greater than an arbitrary third threshold, and may determine the danger level as "low" if the attack power of the enemy character 30 is less than the third threshold. Alternatively, the danger level determination unit 115 may determine the danger level based on the ratio between the attack power of the enemy character 30 and the defensive power of the playable character 10. Such determination criteria may be used in combination.

(2-4) UI Display In step S4 of FIG. 5, the UI control unit 116 generates an aiming UI indicating the presence of the enemy character 30, with reference to the information stored in the UI information storage unit 123, based on the determination results of the enemy determination unit 114 and the determination results of the danger level determination unit 115. As described above, the aiming UI may reflect the position and danger level of the enemy character 30 in addition to the presence of the enemy character 30. The UI control unit 116 passes information about the generated aiming UI to the display control unit 118. Based on the information received from the UI control unit 116, the display control unit 118 generates display information for displaying the aiming UI within a predetermined range from the playable character 10 within the game screen 50, and outputs the display information to the display unit 1072.

As an example, the aiming UI 20 is displayed in red when "risk level = high", in orange when "risk level = medium", in yellow when "risk level = low", and is removed from the game screen (not displayed) when "risk level = 0". In the example shown in FIG. 4, the arc-shaped portion 21A and the protruding portion 22A are displayed in red, the arc-shaped portion 21B and the arc-shaped portion 21C and the protruding portion 22B and the protruding portion 22C are displayed in orange, and the arc-shaped portion 21D and the protruding portion 22D are displayed in yellow.

The above steps S1 to S4 are repeated at intervals (e.g., T = 1/30 seconds) that enable smooth display of the movements of the playable character 10 and enemy character 30 during a quest or battle event related to the display of the aiming UI 20. Even if the enemy character 30 is determined to be within a certain range of the playable character 10 at a certain time (t = _t1 ), if it is determined that the enemy character 30 is not within the certain range of the playable character 10 at the next time (t = _t2 = _t1 + T), the aiming UI pointing to that enemy character 30 will be displayed at time t = _t1 but will not be displayed at time t = _t2 .

FIG. 8A shows a second example of a game screen realized by a game program according to one embodiment. In the example of FIG. 8A, a game screen 50 includes a playable character 10, an enemy character 30, and an aiming UI 20. In FIG. 8A, the playable character 10 is depicted as a swordsman object riding on a winged animal.

The aiming UI 20 is displayed along a ring-shaped range surrounding the playable character 10 near the feet of the playable character 10. The aiming UI 20 indicates the presence and position of the enemy character 30 by arranging an arc between the playable character 10 and the enemy character 30 and pointing a protrusion at the enemy character 30. In FIG. 8A, the enemy character 30 is not in attack mode, but is aware of the playable character 10 and is in a state where it can enter attack mode. Therefore, the aiming UI 20 is displayed with "Danger level = low" (step S306) (no hatching).

Figure 8B shows a third example of a game screen realized by a game program according to one embodiment. In the game screen 50 of Figure 8B, the enemy character 30 has transitioned to attack mode and is preparing to attack the playable character 10. Therefore, the aiming UI 20 is displayed with a "Danger Level = Medium" (step S303) (light hatching), which is a slightly increased level of warning to the user.

Figure 8C shows a fourth example of a game screen realized by a game program according to one embodiment. In the game screen 50 of Figure 8C, the enemy character 30 has begun an attack on the playable character 10. Therefore, the aiming UI 20 is displayed with the maximum user warning level of "Danger Level = High" (step S304) (dark hatching). Furthermore, as an option, in the game screen 50 of Figure 8C, the aiming UI 20 is displayed dynamically spreading towards the enemy character 30 in conjunction with the enemy character 30's attack.

The display mode of the aiming UI 20 according to the danger level may be designed in various ways. The above-mentioned colors (yellow, orange, red) are merely examples, and other colors may be used. Alternatively, the aiming UI 20 may be highlighted by the size of the protrusion, the thickness of the arc, brightness, blinking, bordering, animation display, etc.

Figure 8D shows a fifth example of a game screen realized by a game program according to one embodiment. In the game screen 50 of Figure 8D, the playable character 10 counterattacks the enemy character 30, defeating it, and as a result, the enemy character 30 is no longer likely to switch to attack mode, and "danger level = 0" is set (step S307). Therefore, the aiming UI has been removed from the game screen 50. This can also be said to be because, in step S1 of Figure 5, the enemy character 30 has disappeared from the game space, and its position information is no longer acquired.

There are various possible display modes for the aiming UI 20. For example, when there are multiple enemy characters 30 around the playable character 10, the same number of aiming UIs 20 as the number of enemy characters 30 may be displayed. As a first example, as shown in FIG. 4, the multiple aiming UIs 20 may be arranged on the circumference of the same circle centered on the playable character 10 in the game space.

9 shows a sixth example of a game screen realized by a game program according to an embodiment. In the game screen 50 of FIG. 9, two aiming UIs 20E and 20F corresponding to two enemy characters (not shown on the game screen 50), respectively, are displayed overlapping in the height direction along a virtual circle substantially centered on the playable character 10. The multiple aiming UIs 20 may be arranged and displayed so that the more dangerous the target, the higher the target. This allows the user to more easily visually recognize the presence of an enemy character with a higher level of danger. The multiple aiming UIs 20 may also be displayed so that the more enemy characters that appear later in time are displayed overlapping. Alternatively, the multiple aiming UIs 20 may be displayed on concentric circles of different radii, substantially centered on the position coordinates of the playable character 10. Alternatively, the aiming UIs 20 may be displayed by increasing only the number of protrusions 22.

According to a game program according to one embodiment, the aiming UI 20 is displayed on the circumference of a 360-degree virtual circle centered approximately on the position coordinates of the playable character 10. The virtual circle may be arranged to surround the playable character 10 at any height of the playable character 10. The aiming UI 20 may be displayed near the feet of the playable character 10 as shown in FIG. 4, or may be displayed near the knees or waist of the playable character 10. When the playable character 10 moves, the aiming UI 20 moves with the playable character 10 while pointing at the enemy character 30. At this time, the aiming UI 20 may be displayed slightly above the ground (terrain object) in the game space without being affected by the terrain, or may be displayed deformed to follow the terrain.

Figure 10 shows a seventh example of a game screen realized by a game program according to an embodiment. In the game screen 50 of Figure 10, the aiming UI 20 is displayed deformed to follow the surface shape of the terrain object near the feet of the playable character 10 while indicating the enemy character 30.

The aiming UI 20 is not limited to a display format along the range of a virtual circle roughly centered on the playable character 10, but may be displayed along the range of a polygon surrounding the playable character 10. The protrusion 22 is not limited to a sharp protrusion as shown in the figure, but may be a triangular protrusion, a rounded convex protrusion, or an arrow-shaped protrusion.

In addition, as another example, a situation may be considered in which the playable character 10 moves in the vertical direction, such as when the playable character 10 is lifted up in reaction to a counterattack against an enemy character 30, or when the playable character 10 is attacked by the enemy character 30, or when the playable character 10 climbs over a step. In such a case, the aiming UI 20 may be displayed while maintaining the same height from the ground in the game space, or may be displayed in conjunction with the playable character 10's movement in the vertical direction.

Figure 11 is a diagram showing a modified display mode of the aiming UI 20 realized by a game program according to one embodiment. On the left side of Figure 11, the aiming UI 20 is displayed near the feet of the playable character 10. For example, when the playable character 10 swings down a sword in response to a user's operation, the playable character 10 may rise slightly into the air in recoil, and in conjunction with this rising movement, the aiming UI 20 may also be displayed floating in the air, as shown on the right side of Figure 11.

(3) Effects As described above in detail, according to a game program according to one embodiment, the aiming UI 20 (third object) indicating the presence of an enemy character (second object) 30 attacking the operation character 10 is displayed within a predetermined range from the operation character (first object) 10 operated by the user. The UI 20 may include a protrusion 22 indicating the direction in which the enemy character 30 is located. Furthermore, the UI 20 may have a display form that reflects the danger level of the enemy character 30. The UI 20 is displayed along a virtual circle surrounding the operation character 10, and continues to point to the enemy character 30 as the operation character 10 and/or the enemy character 30 move.

This allows the user to intuitively sense the presence of an enemy character 30 attempting to attack the playable character 10 with a simple UI display, giving the user a greater sense of immersion in the game.

The simple UI provides the user with an excellent gaming experience without placing a strain on the limited computing power of the user terminal 100. The simple UI also conserves battery power on the user terminal. Furthermore, the game program itself is not overly complicated, which reduces the load on the server as well as execution by the user terminal.

[Other embodiments]
It should be noted that the present invention is not limited to the above-described embodiment.
For example, the configurations of the server 200 and the user terminal 100 may be replaced with other configurations capable of implementing the game program according to the embodiment. The configurations of the server 200 and the user terminal 100 may be omitted, distributed among a plurality of devices, and replaced with similar configurations. Each functional unit of the server 200 and the user terminal 100 may be implemented by using a circuit. The circuit may be a dedicated circuit that implements a specific function, or may be a general-purpose circuit such as a processor.

Furthermore, the process flow described using the flowchart is not limited to the procedure described, and the order of some steps may be changed, or some steps may be performed simultaneously in parallel. In addition, the series of processes described above do not need to be performed consecutively in time, and each step may be performed at any timing.

At least a part of the processing of each of the above embodiments can be realized by using, for example, a processor installed in a general-purpose computer as basic hardware. The program that realizes the above processing may be provided by being stored in a computer-readable recording medium. The program is stored in the recording medium as a file in an installable format or an executable format. Examples of the recording medium include magnetic disks, optical disks (CD-ROM, CD-R, DVD, etc.), magneto-optical disks (MO, etc.), and semiconductor memories. Any recording medium can be used as long as it can store a program and is computer-readable. In addition, the program that realizes the above processing may be stored on a computer (server) connected to a network such as the Internet, and downloaded to a computer (client) via the network.

In addition, the method of determining whether an enemy character 30 is present within a certain range from the playable character 10, the method of determining the danger level of the enemy character 30, etc. can be modified in various ways without departing from the gist of this invention. As an example, the danger level of the enemy character 30 may be determined based only on the distance between the playable character 10 and the enemy character 30. This can reduce the processing load on the control unit 110 of the user terminal 100 (particularly the enemy determination unit 114 and the danger level determination unit 115).

Note that this invention is not limited to the above-described embodiment, and various modifications can be made in the implementation stage without departing from the gist of the invention. The embodiments may also be implemented in appropriate combination, in which case the combined effects can be obtained. Furthermore, the above-described embodiment includes various inventions, and various inventions can be extracted by combinations selected from the multiple constituent elements disclosed. For example, if the problem can be solved and an effect can be obtained even if some constituent elements are deleted from all the constituent elements shown in the embodiment, the configuration from which these constituent elements are deleted can be extracted as an invention.

1...game system, 10...operable character, 20...aiming UI, 21...arc, 21A, 21B, 21C, 21D...arc-shaped portion, 22...protrusion, 22A, 22B, 22C, 22D...protrusion-shaped portion, 30...enemy character, 50...game screen, 100...user terminal, 110...control unit, 111...operation reception unit, 112...game progression unit, 113...position information acquisition unit, 114...enemy determination unit, 115...danger level determination unit, 116...UI control unit, 117...virtual camera control unit, 118...display control unit, 120...storage unit, 121...game program storage unit, 122...game information storage unit, 123...UI information storage unit, 200...server, 211...reception control unit, 212...transmission control unit, 213...game progression unit, 220...storage unit, 221...game program storage unit, 222...game information storage unit, 223...user information database, 1001...processor, 1002...memory, 1003...storage, 1004...sensor, 1005...communication interface, 1006...input/output interface, 1007...touch screen, 1008...bus, 1071...input unit, 1072...display unit, 2001...processor, 2002...memory, 2003...storage, 2004...communication interface, 2005...input/output interface, 2006...bus.

Claims (10)

Computer,
a first display means for displaying a first object operated by a player;
a program that functions as a second display means for displaying a third object indicating the presence of the second object within a predetermined range from the first object based on a result of a determination as to whether or not a second object is present within a certain range from the first object,
the predetermined range is a range provided below the first object, the third object is displayed in the range provided below , and when the first object moves, the third object moves with the first object while pointing to the second object;
program. The program according to claim 1, wherein the predetermined range is displayed as a virtual circle provided below the first object, and the third object is displayed along the virtual circle. the first object is a game character;
the second object is an enemy object that attacks the game character,
The third object indicates a direction in which the enemy object exists.
The program according to claim 1. the third object includes a fourth object having a shape indicating a direction in which the enemy object exists;
The program according to claim 3. The program according to any one of claims 1 to 4, wherein the third object is displayed on a substantially straight line connecting the first object and the second object. the second display means changes a display mode of the third object according to a degree of danger posed by the second object to the first object;
The program according to any one of claims 1 to 5. The program according to claim 6, wherein the degree of danger is determined based on the distance between the first object and the second object. The program according to claim 6, wherein the danger level is determined based on whether the second object is in attack mode. The computer,
functioning as a determination means for determining whether the degree of risk has changed to a predetermined threshold value or less;
the second display means, when it is determined that the degree of danger has changed to a predetermined threshold or less, removes the display of the third object.
The program according to any one of claims 6 to 8. the second display means displays a plurality of the third objects indicating the plurality of second objects, respectively, when a plurality of the second objects are present;
The program according to any one of claims 1 to 9.