Program and information processing system

The program facilitates easy object status checking in games by allowing user-controlled movement of one object and autonomous movement of another, improving gameplay efficiency.

JP7744452B2Active Publication Date: 2025-09-25COLOPL
View PDF 10 Cites 0 Cited by

Patent Information

Application Number
JP2024023887
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2024-02-20
Publication Date
2025-09-25
Estimated Expiration
2041-03-04

AI Technical Summary

Technical Problem

Conventional games require users to manually move their player character close to objects to check their status, which is inefficient and cumbersome.

Method used

A program that allows a first object to move in response to user operation and a second object to move without user operation, displaying a first image of the game space including the first object and live video of the second object in a predetermined area of the first image.

Benefits of technology

Enables easy and efficient checking of the state of objects placed in a game space without manual movement, enhancing user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007744452000001
    Figure 0007744452000001
  • Figure 0007744452000002
    Figure 0007744452000002
  • Figure 0007744452000003
    Figure 0007744452000003
Patent Text Reader

Abstract

To provide a technique capable of easily confirming a state of an object disposed in a game space.SOLUTION: A program executed by a computer allows the computer to execute: disposal of a first object that can be operated according to a user's operation and a second object that can be operated regardless of the user's operation in a game space; display of a first image in the game space including the first object; and display of live video of the second object within the game space in a predetermined area of the first image.SELECTED DRAWING: Figure 6
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] An embodiment of the present invention relates to a program. [Background technology]

[0002] There are known games in which a user (player) develops a game object in a virtual game space. As the game object (hereinafter simply referred to as "object") is developed, its status, such as its level and abilities, changes.

[0003] There are also known games in which multiple objects are placed in a large game space and can be developed simultaneously. In such games, a technique is known in which the player character controlled by the user picks up each object, displaying the status information of each object and allowing the user to check the state of the object (see Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] "Guild LV1's Blog", Ameba Blog [online], September 15, 2017, searched January 13, 2021, Internet<URL: https: / / ameblo.jp / yoshiaki0303 / entry-12310889826.html> Summary of the Invention [Problem to be solved by the invention]

[0005] However, with conventional technology, in order to check the state of each object, the user needs to operate the player character to move close to each object and perform actions such as picking it up.

[0006] The present invention has been made in light of the above circumstances, and its object is to provide a technique that makes it possible to easily check the state of objects placed in a game space. [Means for solving the problem]

[0007] In order to solve the above problem, one aspect of the present invention is a program executed by a computer, which causes the computer to place in a game space a first object that can move in response to user operation and a second object that can move without the user operation, display a first image of the game space including the first object, and display live video of the second object in the game space in a predetermined area of ​​the first image. [Effects of the Invention]

[0008] A program according to one aspect of the present invention can make it possible to easily check the state of an object placed in a game space. [Brief explanation of the drawings]

[0009] [Figure 1] 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. [Figure 2] FIG. 2 is a diagram illustrating an example of a functional configuration of the server in the game system illustrated in FIG. [Figure 3] FIG. 3 is a diagram illustrating an example of a functional configuration of a user terminal in the game system illustrated in FIG. [Figure 4] FIG. 4 is a diagram showing an example of the configuration of a game realized by a game program according to an embodiment. [Figure 5] FIG. 5 is a flowchart showing an example of the information processing operation of the user terminal shown in FIG. [Figure 6] FIG. 6 is a diagram showing a first example of a game image realized by a game program according to an embodiment. [Figure 7] FIG. 7 is a diagram showing a second example of a game image realized by a game program according to an embodiment. [Figure 8] FIG. 8 is a diagram showing a third example of a game image realized by a game program according to an embodiment. [Figure 9] FIG. 9 is a diagram showing a first example of a game image to which a transition can be made from the game image of FIG. [Figure 10] FIG. 10 is a diagram showing a second example of a game image to which a transition can be made from the game image of FIG. [Figure 11] FIG. 11 is a diagram showing a first example of a game image to which a transition can be made from the game image of FIG. [Figure 12] FIG. 12 is a diagram showing a second example of a game image to which a transition can be made from the game image of FIG. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Hereinafter, elements that are identical or similar to elements already described will be designated by the same or similar reference numerals, and duplicate 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, or a subnumber may be used in addition to the common reference numeral to describe each element distinctly.

[0011] [One embodiment] A program according to one embodiment is a program for running 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 running general computer functions.

[0012] The game realized by the game program is a game in which a user can raise an object in a game space. The game realized by the game program may be, for example, a raising game, a simulation game, a role-playing game, an action game, an adventure game, a shooting game, a sports game, or a puzzle game, but is not limited to these. The game may also be a part of such a game (such as a mini-game or an event).

[0013] A game program can place various objects in a game space to realize a game. The game space is a space for placing various objects realized by the game program. The game program can create a different game space for each part of the game. In the following description, the game space is mainly described as a three-dimensional space, and the objects placed in the game space are also mainly displayed in three dimensions, but this embodiment can also be applied to two-dimensional game spaces and objects.

[0014] The various objects include character objects. Characters are, for example, but not limited to, human characters, animal characters, or anthropomorphized characters. Character objects are objects that move (act). Character objects include character objects that can be controlled by the user and NPC (Non Player Character) objects that cannot be controlled by the user. The various objects include tool objects. Tool objects are objects that can be used by character objects. Tool objects are, for example, items and equipment. The various objects also include background objects. Background objects are objects that make up the background of the game, such as trees, rocks, grass, sky, rivers, ponds, buildings, and facilities. The various objects include visible objects and invisible objects.

[0015] Various objects have setting values ​​arbitrarily determined by game designers or the like. Setting values ​​are various pieces of information, such as position, size, shape, color, ability, attribute, and so on, expressed as numerical values ​​(also called "parameters"). Here, the setting values ​​possessed by character objects are particularly referred to as status. Status includes, but is not limited to, information such as ability values ​​(e.g., level, stamina, attack power, defense power), health status, attributes (e.g., gender, age, occupation), possessed skills, possessed items, or possessed money. Status includes status that can change through training and status that does not change. An example of a status that changes through training is an ability value. Training can also be described as strengthening an ability value.

[0016] The objects placed in the game space by the game program include a first object that can move in response to a user's operation and a second object that can move without a user's operation. One example of a game realized by the game program is a game in which a user raises a second object in the game space by operating the first object. An example of the first object is a player character object (hereinafter referred to as a "player character"). An example of the second object (object to be raised) is a monster character object (hereinafter simply referred to as a "monster"). The monster is, for example, a fictional creature character.

[0017] The game program may be a game program that runs a game locally on one user terminal, a game program that runs a game in cooperation with a user terminal and a server, a game program that runs a game in cooperation with multiple user terminals (either via the server or not), etc. As an example, the following describes a game system in which a server comprehensively manages game programs and transmits game programs and related data in response to requests from user terminals, and the actual game progress is mainly run on the user terminals.

[0018] (1) Composition (1-1) Game System FIG. 1 shows an example of the overall configuration of a game system 1 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's sake, the detailed configuration of only one user terminal 100 will be illustrated and described.

[0019] 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, FTTH (Fiber To The Home), and a CATV (Cable Television) network.

[0020] The user terminal 100 is a terminal used by a user to play a game. The user terminal 100 executes a game program to realize a game, and displays game images according to the progress of the game to realize a game screen. The game images may include images depicting a game space. The images depicting a game space may include images of multiple objects arranged in the game space. The game images include still images or moving images. The game images may also include images of UI (User Interface) components expressed in two or three dimensions. The user terminal 100 may be, for example, a mobile terminal such as a smartphone, a tablet terminal, or a notebook personal computer. The user terminal 100 may also 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 description, the user terminal 100 is assumed to be a smartphone with a touch screen, as an example.

[0021] The server 200 is a device operated and managed by, for example, a game developer. The server 200 comprehensively manages game programs and user information and supports the progress of the game on the user terminals 100. The server 200 may be a general-purpose computer such as a workstation or personal computer. For example, the server 200 receives user information and various requests from the user terminals 100 via the network NW, and transmits game programs and related data to the user terminals 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.

[0022] The user terminal 100 may receive the game program and necessary setting data from the server 200 at one time, 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.

[0023] (1-2) Hardware configuration (1-2-1) Server As shown in FIG. 1, the server 200 includes, 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.

[0024] The processor 2001 controls the overall operation of the server 200. The processor 2001 includes, for example, a general-purpose processor such as a central processing unit (CPU), a micro processing unit (MPU), or a graphics processing unit (GPU). The processor 2001 is not limited to a general-purpose processor, and may be a dedicated processor such as an application specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

[0025] The memory 2002 is a main storage device and includes a ROM (Read Only Memory) and a RAM (Random Access Memory).

[0026] The storage 2003 is an auxiliary storage device and includes a nonvolatile storage device such as a hard disk drive (HDD) or a solid state drive (SSD). The storage 2003 stores programs executed by the processor 2001, setting data required for executing the programs, etc. Part of the programs may be stored in a ROM.

[0027] The processor 2001 can implement the processing functions described below by reading a program from the storage 2003, loading it into the memory 2002, and interpreting and executing the loaded program.

[0028] 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.

[0029] An 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 speaker.

[0030] (1-2-2) User terminal As shown in FIG. 1, the user terminal 100 includes, 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.

[0031] 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.

[0032] The processor 1001 can implement the processing functions described below by reading a program from the storage 1003, loading it into the memory 1002, and interpreting and executing the loaded program.

[0033] The memory 1002 is a main storage device and includes a ROM, a RAM, and the like.

[0034] The storage 1003 is an auxiliary storage device and includes an internal or external semiconductor memory (for example, a flash memory), etc. The storage 1003 stores programs executed by the processor 1001, setting data required for executing the programs, etc. Part of the programs may be stored in a ROM.

[0035] The sensor 1004 is, for example, an image sensor, a sound 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 electrical signals and outputs them.

[0036] 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 a module for mobile communication, a module for wireless / wired LAN, a module for short-range wireless communication, etc.

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

[0038] 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 displaying various images to the user.

[0039] The input unit 1071 is, for example, a capacitive or resistive touch panel. The input unit 1071 detects the contact position of the user's finger or touch pen (stylus pen), and generates coordinate information of the contact position.

[0040] The display unit 1072 is, for example, a liquid crystal display or an organic EL display, and displays various images based on the display data. The display unit 1072 realizes a game screen by displaying game images.

[0041] The user terminal 100 can also accept user operations from external input devices 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 external storage devices such as memory cards connected via the input / output interface 1006. The user terminal 100 can also output display information to external output devices such as displays and speakers connected via the input / output interface 1006. The user terminal 100 can also use external storage devices such as memory cards connected via the input / output interface 1006 as storage 1003. The user terminal 100 can also accept signals from sensors 1004 as user operations.

[0042] (1-3) Functional configuration (1-3-1) Server Fig. 2 shows 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 required to implement a game are omitted.

[0043] The server 200 has a function of communicating with each user terminal 100 and supporting the progress of the game on the user terminal 100. For example, the server 200 has a function of transmitting a game program and related data required to execute the game program 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.

[0044] The storage unit 220 is mainly realized by the storage 2003. The storage unit 220 includes a game program storage unit 221, a game information storage unit 222, and a user information database (DB) 223.

[0045] The game program storage unit 221 stores a game program.

[0046] The game information storage unit 222 stores various pieces of game information that are referenced when a game program is executed.

[0047] The user information database (DB) 223 is a database that stores information about users associated with each user terminal 100, such as user account information.

[0048] The control unit 210 is mainly realized by the processor 2001 and the memory 2002. The control unit 210 controls the overall functions of the server 200. 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.

[0049] The reception control unit 211 receives, from each user terminal 100, user information, a request to send a program or related data, information about the progress of the game on each user terminal 100, and the like.

[0050] 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.

[0051] The game progression unit 213, in accordance with code written in the game program, references the game information stored in the game information storage unit 222 and the account information stored in the user information database 223, 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 send data to each user terminal 100.

[0052] For example, the control unit 210 receives a request to send a game program from the user terminal 100 via the reception control unit 211, determines the game program and related data to be sent to the user terminal 100 via the game progression unit 213, and sends the determined game program and related data to the user terminal 100 via the transmission control unit 212.

[0053] (1-3-2) User terminal Fig. 3 shows 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 required to implement a game are omitted.

[0054] The user terminal 100 includes a control unit 110 and a storage unit 120 . The storage unit 120 is mainly realized by the storage 1003. The storage unit 120 includes a game program storage unit 121, a game information storage unit 122, and a UI information storage unit 123.

[0055] The game program storage unit 121 stores a game program.

[0056] The game information storage unit 122 stores various game information that is referenced when a game program is executed. The game information includes, for example, setting values ​​of various objects placed in the game space and various other information related to the game space. The game information includes information about the monsters to be raised, such as their names, statuses, and growth conditions.

[0057] The UI information storage unit 123 stores information about various UI components used in generating game images.

[0058] The control unit 110 is mainly realized by the processor 1001 and memory 1002. The control unit 110 controls the overall functions of the user terminal 100. By executing a game program stored in the game program storage unit 121, the control unit 110 can function as a game progression unit 111, an object control unit 112, a display control unit 113, a virtual camera control unit 114, a firm management unit 115, and an operation reception unit 116.

[0059] The game progression unit 111 refers to the game information stored in the game information storage unit 122 in accordance with code written in the game program, and performs processing to place objects in the game space and progress the game. The game progression unit 111 may reflect coordinate information related to user operations from the operation reception unit 116 and user instructions identified from the user operations in the progress of the game. The game progression unit 111 places in the game space a first object (player character) that can move in response to user operations, and a second object (monster) that can move regardless of user operations.

[0060] The object control unit 112 controls the actions or status of various objects arranged in the game space. For example, the object control unit 112 causes a player character to move in response to a user's operation. The user can move the player character or cause the player character to perform an action by inputting an operation to the input unit 1071. The player character's actions include actions that involve movement of position and actions that do not involve movement of position. The object control unit 112 also causes monsters to move in response to code written in the game program, regardless of user operation. The object control unit 112 can also cause monsters to move in response to a user's operation. The monster's actions include actions that involve movement of position and actions that do not involve movement of position.

[0061] The display control unit 113 generates display data for displaying various images on the display unit 1072. The display data generated by the display control unit 113 includes display data for displaying an image (first image) of a game space including a player character (first object). In one embodiment, the first image is an image in which an image of a UI widget is superimposed on a live video (first live video) of the player character in the game space. The display data generated by the display control unit 113 also includes display data for displaying a live video (second live video) of a monster (second object) in the game space in a predetermined area of ​​the first image. The predetermined area of ​​the first image may be an area arbitrarily set by a game designer or the like. The predetermined area is, for example, located on the right side of the first image as seen by a user playing the game.

[0062] Here, live footage refers to images of the game space displayed in real time or near real time. Live footage is, for example, images (video) captured by a virtual camera movably positioned corresponding to each character. For example, the first live footage is an image captured by a virtual camera tracking a player character, and the second live footage is an image captured by a virtual camera tracking a monster. The first live footage does not need to include the entire player character, but may be an image including only a part of the player character, such as the face or upper body. The second live footage also does not need to include the entire monster, but may be an image including only a part of the monster, such as the face or upper body. In one embodiment, the live footage is realized as a combination of multiple still images obtained from each virtual camera.

[0063] The display data generated by the display control unit 113 also includes display data for displaying first information representing the status of a monster (second object) when a user operation to select the above-mentioned predetermined area is accepted. The display data generated by the display control unit 113 also includes display data for displaying, in place of the first image, a second image including a video corresponding to a live video of the monster and the first information representing the status of the monster when a user operation to select the above-mentioned predetermined area is accepted. In other words, the display control unit 113 has a function of switching the display from the first image to the second image when a predetermined operation is accepted from the user.

[0064] The user's operation of selecting a predetermined area of ​​the first image includes an operation of the user tapping on the predetermined area or its periphery via touch screen 1007. The operation of selecting a predetermined area of ​​the first image can also be described as an operation of selecting a monster or an operation of selecting live video.

[0065] The display data generated by the display control unit 113 also includes data for displaying second information indicating that the monster has transitioned to a specific state. The second information includes, for example, text, symbols, pictures, animations, icons, or pictograms. The second information is displayed in association with the live video. The specific state includes, for example, a state in which the monster's ability value has increased, a state in which the monster is carrying a gift, or a state in which the monster is ill. The second information may include a third image that visually indicates that the monster has transitioned to a specific state. The third image is, for example, a pictogram or an icon. The third image may include text information. The data for displaying the second information may include information for erasing the display of the second information after displaying the second information for a certain period of time.

[0066] The virtual camera control unit 114 places multiple virtual cameras in the game space and acquires images captured by each virtual camera. A virtual camera is a virtual camera for acquiring images from the game space. The virtual camera acquires images depicting objects placed in the game space. "Capturing" includes the meaning of capturing an image. The virtual cameras include a virtual camera movably positioned corresponding to the player character. The virtual cameras also include a virtual camera movably positioned corresponding to each monster. For example, the virtual camera control unit 114 moves each virtual camera corresponding to each capture target by setting each virtual camera as an associated object (child element) of each capture target. The virtual camera control unit 114 controls, for example, the position (X, Y, Z) of each virtual camera in the world coordinate system of the virtual space or the rotation angle on each axis (roll, pitch, yaw). The virtual camera control unit 114 can control the movement of each virtual camera according to conditions set for each capture target, such as the distance range from each capture target, the angle range relative to the midsagittal plane or horizontal plane, or the viewpoint of each capture target. The movement of the virtual camera is not limited to tracking the subject from behind, but includes any manner of movement corresponding to the subject, such as tracking the eyes or face of the subject from the front, or moving on the surface of a sphere centered on the subject while facing the center of the sphere. Tracking may also be referred to as tracing or following. The virtual camera control unit 114 can also control the position, zoom, tilt, focus, angle of view, magnification, and the relative distance or angle between each subject and each virtual camera in response to user operations. The virtual camera may also be referred to as a virtual viewpoint. The virtual camera includes a virtual camera that is fixed in the game space and does not track the subject.

[0067] The farm management unit 115 manages information about a farm field (hereinafter simply referred to as "farm") as an example of a game space. The farm is a game space where the user can raise monsters. The farm may include a virtual outdoor space (for example, a space simulating a grassland or farm) or a virtual indoor space (for example, a space simulating a facility such as a gymnasium). The farm management unit 115 manages the status of each monster in cooperation with the object control unit 112. The farm management unit 115 also manages the environment within the farm (for example, weather, day / night, seasons), facilities within the farm (for example, training facilities, feeding areas, items), and other events within the farm.

[0068] The operation receiving unit 116 receives user operations input via the input unit 1071. Hereinafter, the term "user operation" refers to a user operation input via the input unit 1071. The user operation includes various types of operations via the input unit 1071, such as a tap operation and a flick operation. A tap operation is an example of an operation in which a single contact position is detected on the input unit 1071 and then becomes undetectable within a predetermined time. A tap operation is input, for example, by a user lightly touching the touch screen with a fingertip and then immediately releasing the fingertip. A flick operation is an example of an operation in which a single contact position on the input unit 1071 is moved chronologically in a short period of time. A flick operation is input, for example, by a user touching the touch screen with a fingertip and then lightly flicking the finger in any direction while still touching the touch screen.

[0069] When the operation reception unit 116 receives a user operation, it determines, based on the position coordinates of the operation, which object in the image displayed on the display unit 1072 the operation is for. As an example, when the operation reception unit 116 receives a tap operation at the position of the image of one of the UI components, it generates a command indicating that the UI component has been selected and outputs the command to the game progression unit 111, the object control unit 112, the display control unit 113, the virtual camera control unit 114, or the firm management unit 115. The operation reception unit 116 also receives a user operation within a predetermined range of the image as an operation for moving the player character. For example, when the operation reception unit 116 receives a flick operation at a position in the periphery of the player character, it receives the flick operation as a movement operation in a direction corresponding to the start position and end position of the flick operation.

[0070] The object control unit 112 also controls the behavior and status of each monster placed in the farm in cooperation with the farm management unit 115. The object control unit 112 randomly selects an action from multiple actions, such as running, playing, walking, and sleeping, and causes each monster to act according to the corresponding program code without user interaction. The object control unit 112 can also change the behavior of each monster depending on the passage of time or changes in the farm's status. The object control unit 112 may reflect the individual characteristics of each monster when selecting an action mode, such as increasing the proportion of monsters that run. The object control unit 112 may also reflect the farm's environment in the behavior of each monster, such as making the monster more active on sunny days.

[0071] The object control unit 112 causes a monster set to "training" to perform a preset action (for example, a strength training action, a meditation action, etc.). "Training" is set for each monster by user selection. The object control unit 112 also changes the ability values ​​of a monster set to "training." For example, the object control unit 112 increases parameters such as attack power and defense power according to the set conditions.

[0072] The object control unit 112 can also control the behavior or status of a monster in response to a user's operation. For example, if a monster is given food by a player character through a user's operation, the object control unit 112 causes the monster to perform a happy behavior for a certain period of time, thereby increasing a parameter (friendship parameter) representing the monster's level of affection (friendship level) or a parameter (mood parameter) representing the monster's mood. In addition to the monster's own behavior, the object control unit 112 can also control whether or not to display effects such as heart marks or musical note marks representing the monster's mood. For example, if a user does not give food to a monster for a certain period of time, the object control unit 112 causes the monster to perform an angry behavior, thereby decreasing the monster's affection parameter or mood parameter.

[0073] The object control unit 112 also controls the state transition of each monster. The object control unit 112 monitors the status of each monster and causes a state transition between a "normal state" and a "specific state" when a predetermined condition is met. For example, if the affection parameter exceeds a predetermined threshold, the object control unit 112 transitions the monster to a specific state of "having a present," and if the affection parameter is equal to or less than the predetermined threshold or if the present is received by the user, the object control unit 112 transitions the monster to the normal state of "not having a present." The present is, for example, an item that is advantageous for progressing through the game.

[0074] The object control unit 112 repeatedly executes the above-described control at regular time intervals (for example, every 1 / 30 seconds). The control results by the object control unit 112 are passed to the display control unit 113 for image display, to the virtual camera control unit 114 for virtual camera control, and stored in the storage unit 120.

[0075] (1-4) Game Structure 4 shows an example of a game configuration realized by a game program. The game includes a training part 2 and a quest part 3. The game program creates or uses a first game space for the training part 2 and a second game space for the quest part 3.

[0076] Breeding Part 2 includes the "farm" element and the "breeding" element. In the second part of the game, the user can raise monsters within the farm (the farm element). The user can own one or more monsters in the game and raise them by placing them on the farm. Monsters placed on the farm change their status over time, for example. Status changes include changes in ability scores, changes in possessed items, changes in health, etc. The user can also perform various operations on the monsters placed on the farm, such as feeding them. The user can also set training for the monsters in the farm. Setting training for a monster greatly improves the monster's ability scores. There is an upper limit on the number of monsters that can be placed on the farm. There is also an upper limit on the ability scores of each monster. Therefore, the user can strategically choose whether to place the monsters they own on the farm (to be raised) or to keep them on standby.

[0077] In the second breeding part, the user can breed multiple monsters to create new monsters in the breeding field (breeding element). The farm and the breeding field are included in the first game space. The farm and the breeding field may be realized as a single game space or as separate game spaces. For example, the user can breed monsters whose ability values ​​have reached their upper limit, and can grow the newly created monsters through breeding on the farm.

[0078] Quest Part 3 is an adventure part in which the player aims to achieve some kind of goal, and includes an "action" element and a "monster acquisition" element. In Quest Part 3, the user can control the player character in the second game space to perform actions (e.g., having the player character fight an enemy character, having the player character acquire an item, or having the player character avoid a trap or gimmick) (action element). Also, in Quest Part 3, the user can have the player character acquire a monster in the second game space (monster acquisition element). For example, the user can have the player character fight a monster as an enemy character and acquire the monster by winning the battle. Or, for example, the user can have the player character acquire a special item and acquire the monster as a reward for acquiring the special item.

[0079] Training Part 2 and Quest Part 3 are interrelated. The user can use the monsters trained in Training Part 2 in Quest Part 3. For example, the user can control a monster together with or instead of the player character and have it perform actions. Similarly, the user can train a monster acquired in Quest Part 3 in Training Part 2. The user can switch between Training Part 2 and Quest Part 3 by operating a UI component displayed on the game screen. The first game space for Training Part 2 and the second game space for Quest Part 3 are separate game spaces. In other words, the game realized by the game program allows a monster acquired in a quest in a second game space different from the first game space to be trained in the first game space. However, the first game space and the second game space may be an integrated game space. The following description mainly relates to Training Part 2 (first game space), and particularly to the farm portion.

[0080] (2) Operation FIG. 5 is a flowchart showing an example of the information processing operation of the user terminal 100 shown in FIG. The following operations are premised on the assumption that the control unit 110 and memory unit 120 of the user terminal 100 work together to progress the game in accordance with the code written in the game program, and generate display data. The game progression unit 111 places various objects, including the player character and monsters to be raised, in the game space (farm). Under the control of the virtual camera control unit 114, the game progression unit 111 also places a movable virtual camera in the game space corresponding to the player character, and movable virtual cameras corresponding to one or more monsters. The object control unit 112 also controls the behavior and status of the monsters, and stores the latest information.

[0081] In step S1, the control unit 110 acquires information about objects in the game space through cooperation between the object control unit 112 and the display control unit 113. The acquired object information may include position information and status information about the player character and position information and status information about monsters. The position information is expressed, for example, as position coordinates in the game space. If multiple monsters are placed in the farm, the control unit 110 acquires information about each of the multiple monsters.

[0082] In step S2, the control unit 110, in cooperation with the display control unit 113 and the virtual camera control unit 114, generates display data for displaying a first image of the game space including the player character and displays the first image on the display unit 1072. In one embodiment, the first image is an image in which an image of a UI widget is superimposed on live video from a virtual camera movably positioned in correspondence with the player character. For example, the virtual camera control unit 114 controls the virtual camera to track the player character from a position a predetermined distance behind the player character, with its viewpoint set on the player character's head. The virtual camera captures images at a predetermined frame rate and passes them to the display control unit 113. As a result, a live video of the player character from a so-called third-person perspective, in which the player character is viewed from behind, is obtained.

[0083] Next, in steps S3 to S5, control unit 110 repeats the process of displaying an image including a live video of the monster in a predetermined area of ​​the first image for each monster in the farm. First, in step S3, the control unit 110, in cooperation with the display control unit 113 and the virtual camera control unit 114, generates and displays display data for displaying live video of the monsters in a predetermined area within the first image. The live video is live video from a virtual camera movably positioned in the game space corresponding to one or more monsters. For example, each virtual camera is controlled by the virtual camera control unit 114 to track each monster from a position a predetermined distance directly in front of the monster, with its viewpoint set on the head of the monster. Each virtual camera captures images at a predetermined frame rate and passes the images to the display control unit 113. As a result, live video including a portion of each monster's face is obtained. The frame rate of the virtual camera capturing the player character and the frame rate of each virtual camera capturing the monsters may be the same or different.

[0084] 6 shows a first example of a game image realized by a game program according to an embodiment. Game image 50A in FIG. 6 is a first example of a first image and is displayed on display unit 1072 of user terminal 100. Game image 50A includes an image of a game space including player character 11. Game image 50A also includes images of UI widgets 51A, 51B, and 51C, UI widget 52, and UI widgets 71A, 71B, 71C, and 71D.

[0085] In the game image 50A, the image of the game space including the player character 11 is an image captured by a virtual camera tracking the player character 11 within the game space. In the game image 50A, the player character 11 is placed in a farm with the appearance of a grassland, and is displayed together with background objects such as grass, trees, rocks, fences, mountains, and the sky. The player character 11 is an example of a first object that can move in response to a user's operation, and is represented in the game image 50A as a human game character.

[0086] UI components 51A, 51B, and 51C are operation buttons that perform a predetermined function when selected by the user. For example, tapping UI component 51A switches to a dedicated image (not shown) for configuring farm settings, allowing the user to configure the farm. Farm settings include, for example, configuring monsters to be placed on the farm, training the monsters placed on the farm, and configuring other objects to be placed on the farm (e.g., trainers to assist with training, training equipment, toys, etc.). For example, tapping UI component 51B switches to a breeding field image (not shown), allowing the user to play the game with a breeding element. For example, tapping UI component 51C switches to a dedicated image (not shown) for configuring various settings, allowing the user to configure various settings such as screen display and volume. The number, appearance, display position, and function of UI components 51A, 51B, and 51C can be arbitrarily set by the game designer.

[0087] The UI element 52 has a scene title function and includes a display that explains the scene displayed by the game image 50A. In FIG. 6, the UI element 52 includes the word "farm," indicating that the player character 11 is on a farm. The scene title 52 can also be set arbitrarily by the game designer.

[0088] UI components 71A, 71B, 71C, and 71D are arranged in a predetermined area 70 of the game image 50A. As an example, the predetermined area 70 is located on the right side of the game image 50A as seen by a user playing the game. The right area of ​​the game image 50A is an example of an area that is easy to tap with the right hand when the user holds both ends of the user terminal 100 in both hands in the longitudinal direction. The predetermined area 70 may be located elsewhere in the game image 50A.

[0089] UI components 71A, 71B, 71C, and 71D have the function of displaying live video footage 20A, 20B, 20C, and 20D of monsters, respectively (collectively referred to as "live video footage 20"). Hereinafter, UI components 71A, 71B, 71C, and 71D will be referred to as "wipe UIs" respectively, and will also be referred to collectively as "wipe UIs 71." Furthermore, images related to wipe UIs 71, including live video footage 20, will be referred to collectively as wipe images.

[0090] In FIG. 6, wipe UIs 71A, 71B, 71C, and 71D respectively display live images 20A, 20B, 20C, and 20D of four different monsters 21A, 21B, 21C, and 21D (collectively referred to as "monsters 21") placed in the farm. The live images 20 are images captured by a virtual camera that tracks each monster 21 in the game space. The monsters 21 are an example of a second object that can move without user operation, and are represented as characters of imaginary creatures in FIG. 6. The monsters 21 may also be able to move in response to user operation. Each monster 21 is a monster selected by the user as a target for raising and placed in the farm.

[0091] The appearance, shape, number, size, and position of the wipe UIs 71 may be set arbitrarily. The number of wipe UIs 71 may be fixed or may change during the course of the game. For example, the number of wipe UIs 71 may change during the course of the game according to the number of monsters 21 placed in the farm, or may be a fixed number equal to the maximum number of monsters 21 that can be placed in the farm. Similarly, the size of the wipe UIs 71 displayed during the course of the game may be fixed or may change. The wipe UIs 71 may be displayed side by side in a predetermined area 70 as shown in FIG. 6, or may partially overlap each other. For example, in FIG. 6, when the monster 21A is removed from the target of breeding (no longer placed in the farm), the display of the wipe UI 71A may be erased, the live video within the wipe UI 71A may be replaced with a dummy image, or only the outline of the wipe UI 71A may be maintained so that the first live video can be seen through it. When wipe UI71A is removed from the display, the position and size of the remaining wipe UI71B, 71C, and 71D may be maintained, or their position, size (height), or spacing may be changed so that they are evenly spaced within the specified area 70.

[0092] The player character 11 can move (e.g., walk around) within the farm in response to user operations. When the player character 11 moves near one of the monsters 21 within the game space, the monster 21 also appears in an image captured by a virtual camera tracking the player character 11, and the monster 21 is displayed together with the player character 11 in the game image 50A. The user can communicate with the monster 21 through the game image 50A. However, if the farm is large, the operation of moving the player character 11 near the monster 21 can be cumbersome. If multiple monsters 21 are placed within the farm, the user must first identify the monster 21 of interest and then identify the location of that monster 21, which can make the operation of moving the player character 11 near the monster 21 of interest even more cumbersome.

[0093] In one embodiment, as shown in game image 50A, a list of wipe UI 71 is displayed together with live video of the player character 11, and live video of each monster 21 is displayed within the wipe UI 71. This allows the user to grasp the current state of each monster 21 at a glance while controlling the player character 11 without performing any complicated operations.

[0094] For example, in FIG. 6, a wipe UI 71A displays live video 20A of a monster 21A, allowing the user to visually see the monster 21A walking around the farm while controlling the player character 11. A wipe UI 71B displays live video 20B of a monster 21B, allowing the user to visually see the monster 21B with its eyes closed. A wipe UI 71C displays live video 20C of a monster 21C, showing a musical note mark 22 displayed as an effect according to the monster's mood, allowing the user to visually see that the monster 21C is in a good mood. A wipe UI 71D displays live video 20D of a monster 21D, allowing the user to visually see the monster 21D sitting.

[0095] It should be noted that if the player character 11 is near one of the monsters 21, the monster 21 may appear in the live video of the player character 11 and may also appear in the wipe UI 71. The player character 11 itself may also appear in the live video within the wipe UI 71. Similarly, if two or more monsters 21 are near each other, two or more monsters 21 may appear in one wipe UI 71, or the same monster 21 may appear overlappingly in two or more wipe UIs 71.

[0096] Next, in step S4, the control unit 110, in cooperation with the object control unit 112 and the farm management unit 115, etc., determines whether each monster 21 has transitioned to a specific state. If it is determined that the monster 21 has transitioned to a specific state (YES), the process proceeds to step S5, and if it is determined that the monster has not transitioned to a specific state (NO), the process ends. As described above, each monster 21 placed in the farm has two states, a "normal state" and a "specific state," and undergoes a state transition when a predetermined condition is met.

[0097] An example of the specific state is a state in which the monster 21 is holding a present. In this example, the normal state is a state in which the monster 21 is not holding a present. For example, when the monster 21 is given food on the farm, its affection parameter increases, and when the affection parameter reaches a certain value, the monster 21 transitions to a state in which it is holding a present (a specific state). The user receives the present from the monster 21, for example, via the player character 11, thereby acquiring the item contained in the present. When the user receives the present from the monster 21, the monster 21 transitions to the normal state.

[0098] Another example of a specific state is when the monster 21 is sick (unhealthy). In this example, the normal state is when the monster 21 is not sick (healthy). For example, the monster 21 is configured to lower its mood parameter when certain conditions are met, such as when it is not fed for a certain period of time, when it is not taken to quest part 3 for a certain period of time, when it is simply placed on the farm for a certain period of time, or when it is left alone with training set for a certain period of time. The mood parameter may also be configured to change due to the frequency of communication with the player character 11 or changes in the environment within the farm. If the mood parameter remains below a certain value for a certain period of time, the monster 21 transitions to a sick state with a certain probability. If the sick state continues for a certain period of time, the monster 21's ability value will decrease, or the monster 21 will no longer be able to be taken to quest part 3. The user can make the sick monster 21 recover from its illness by, for example, feeding the sick monster 21 via the player character 11, taking it to quest part 3, administering medicine to it, or increasing communication with it. When a predetermined recovery condition is met, the monster 21 transitions to a normal state.

[0099] Another example of a specific state is a state in which the ability value of the monster 21 is increased. In this example, the normal state is a state in which the ability value of the monster 21 is not increased. For example, if "training" is set in the farm and the ability value has not reached the upper limit, the monster 21 transitions to a state in which the ability value is increased. If the ability value of the monster 21 reaches the upper limit or if the "training" of the monster 21 is canceled, the monster 21 transitions to the normal state. The ability value includes HP (hit points) representing physical strength, SP (skill points) representing the ability to use skills (special techniques), attack power, defense power, attack hit rate, luck, attack evasion rate, movement speed, etc. The state in which the ability value is increased may include a state in which the monster 21 is about to acquire a new skill or has acquired a new skill.

[0100] Each monster 21 may transition to different specific states at the same time. In the above example, each monster 21 may simultaneously be in a combination of two or more of the following states: a state in which the monster 21 has a present, a state in which the monster 21 is sick, or a state in which the ability value of the monster 21 has increased.

[0101] Next, in step S5, the control unit 110 causes the display control unit 113 to generate and display display data for displaying transition information indicating that the monster 21 has transitioned to a specific state. The transition information is an example of second information. The transition information may include text such as "present," "disease," "defense power increasing," "attack power increasing," or "new skill acquired." The transition information may include an image (third image) visually indicating that the monster 21 has transitioned to a specific state, such as a picture of a gift box, a skull mark, or an arrow mark. The display control unit 113 generates display data for displaying the transition information by, for example, reading out UI widgets that meet certain conditions from the UI information storage unit 123. The transition information is displayed in association with each live video 20 or each wipe UI 71. For example, the transition information may be displayed as a badge on the frame of the wipe UI 71, superimposed on the wipe UI 71, or near the wipe UI 71.

[0102] 5 is executed repeatedly at regular intervals (for example, every 1 / 30 seconds). In one embodiment, the frame rate of the virtual camera that captures the player character or each monster is set to a value (for example, 1 / 10 seconds) that minimizes the processing load and allows for smooth live video.

[0103] Figure 7 shows a second example of a game image realized by a game program according to an embodiment. Game image 50B in Figure 7 is a second example of the first image. Game image 50B in Figure 7 is similar to game image 50A in Figure 6 except that it includes a display of transition information, so the following will mainly describe the differences from Figure 6.

[0104] 7 includes a present display 72 and an illness display 73. The present display 72 and the illness display 73 are each an example of a transition information display.

[0105] The present display 72 indicates that the monster 21 has transitioned to a state in which it is holding a present. In FIG. 7, the present display 72 is an image including a picture of a present box. In FIG. 7, the present display 72 is displayed superimposed on the frame of the wipe UI 71A in the form of a so-called badge display, and indicates that the monster 21A is holding a present for the player character 11. The present display 72 also suggests to the user that an operation to receive the present from the monster 21A is required.

[0106] The gift display 72 is continuously displayed while the monster 21 is in a state in which it has a gift. For example, when the user moves the player character 11 near the monster 21A and performs an operation to receive a gift from the monster 21A, the monster 21A transitions from the "specific state" to the "normal state." Therefore, in the processing of the next cycle, if the determination in step S4 is NO, the processing ends without displaying the gift display 72. If the determination in step S4 is "NO," a process of "erasing the display of any transition information that has already been displayed" may be executed.

[0107] The illness display 73 indicates that the monster 21D has transitioned to an ill state. In FIG. 7, the illness display 73 is an image including a skull and crossbones. In FIG. 7, the illness display 73 is also displayed in the form of a badge display superimposed on the frame of the wipe UI 71D, indicating that the monster 21D is ill. The illness display 73 also suggests to the user that an operation is required to cure the monster 21D from its ill state.

[0108] The illness display 73 is continuously displayed while the monster 21 is in an ill state. For example, if the user moves the player character 11 near the sick monster 21D and performs an operation to give medicine to the monster 21D, the monster 21D transitions from a "specific state" to a "normal state." Therefore, when the next cycle of processing is performed, if the determination in step S4 is "NO," the processing ends without displaying the illness display 73. Again, if the determination in step S4 is "NO," the processing of "erasing the display of any transition information that has already been displayed" may be performed.

[0109] The gift display 72 or the illness display 73 may include text information or may consist of text only. The gift display 72 or the illness display 73 may be displayed within the wipe UI 71 or outside the wipe UI 71. The gift display 72 or the illness display 73 may have a function to display text information that explains the state of the monster 21 or what operation the user should perform, for example, when tapped by the user.

[0110] Figure 8 shows a third example of a game image realized by a game program according to an embodiment. Game image 50C in Figure 8 is a third example of the first image. Game image 50C in Figure 8 is similar to game image 50A in Figure 6 except that it includes a display of transition information, so the following will mainly describe the differences from Figure 6.

[0111] 8 includes a first ability increase display 74 and a second ability increase display 75. The first ability increase display 74 and the second ability increase display 75 are each an example of a display of transition information (second information or third image).

[0112] The first ability increase display 74 indicates that the monster 21 has transitioned to a state in which its ability value has increased. The first ability increase display 74 may include a picture of an upward arrow and the character "Defense" as an abbreviation for defensive power. In FIG. 8, the first ability increase display 74 is displayed within the wipe UI 71B and the wipe UI 71C, respectively, and indicates that the defensive powers of the monsters 21B and 21C have increased.

[0113] The second ability increase display 75 also indicates that the monster 21 has transitioned to a state in which its ability value is increasing. The second ability increase display 75 may include a picture of an upward arrow and the character "attack" as an abbreviation for attack power. In FIG. 8, the second ability increase display 75 is displayed within the wipe UI 71C and indicates that the attack power of the monster 21C has increased.

[0114] According to one embodiment, when the monster 21 transitions to a specific state, the display control unit 113 starts displaying the transition information and starts a timer, and when a certain time (e.g., 3 seconds, 5 seconds, 10 seconds, etc.) has elapsed since the start of displaying the transition information, the display control unit 113 performs processing to erase the display of the transition information (or displays an image not including the transition information). Whether the display of the transition information continues while the monster 21 is in a specific state or is erased after a certain time from the start of display may be set for each piece of transition information. When erasing the display after a certain time, the time until erasure may also be set for each piece of transition information. As an example, the first ability increase display 74 and the second ability increase display 75 are erased after being displayed for a certain time. The first ability increase display 74 and the second ability increase display 75 may be continuously displayed while the ability value of the monster 21 is increasing.

[0115] As shown in FIGS. 7 and 8 , in one embodiment, the first image further displays transition information indicating that the monster 21 (second object) displayed in a predetermined area 70 has transitioned to a specific state. The transition information includes text or an image and is superimposed and displayed in the predetermined area 70. The transition information is particularly displayed in the frame of each wipe UI 71, within each wipe UI 71, or around each wipe UI 71 within the predetermined area 70, and can indicate which monster 21 has transitioned to a specific state. This allows the user, while operating the player character 11, to know at a glance whether each monster 21 has transitioned to a specific state without performing any complicated operations.

[0116] In one embodiment, the wipe UI 71 further functions as an operation button that accepts a user operation. When a tap operation on any of the wipe UIs 71 is accepted, the control unit 110, under the control of the display control unit 113, displays detailed status information of the monster 21 associated with the tapped wipe UI 71. The tap operation on the wipe UI 71 is an example of an operation for selecting a predetermined area 70.

[0117] For example, while the process shown in FIG. 5 is periodically executed and the process of displaying the first image (and live video) is being executed, the control unit 110 monitors, via the operation reception unit 116, whether or not the user has performed an operation of tapping on the wipe UI 71. For example, when the position of the tap operation is included in any of the wipe UIs 71, the operation reception unit 116 determines that an operation of tapping on the wipe UI 71 has been detected. When an operation of tapping on any of the wipe UIs 71 is detected, the control unit 110 interrupts the process of FIG. 5 and, under the control of the display control unit 113, generates a second image including an image corresponding to the live video of the monster 21 related to the tapped wipe UI 71 and first information indicating its status, and displays the second image in place of the first image. The image corresponding to the live video includes an enlarged image of the live video displayed in the first image, or an image in which the live video displayed in the first image is displayed on the entire game screen.

[0118] FIG. 9 shows a first example of a game image to which a transition can be made from the game image of FIG. 6. The game image 60A of FIG. 9 is an example of a game image displayed on the display unit 1072 of the user terminal 100, particularly when a tap operation on the wipe UI 71A is received. The game image 60A of FIG. 9 is a first example of a second image, and is displayed in place of the game image 50A (first image) of FIG. 6. Note that a similar game image may also be displayed when the wipe UI 71A shown in FIG. 7 or FIG. 8 is tapped. The game image 60A of FIG. 9 includes live video of the monster 21A and UI components 52, 53, 54A, 55A, 56A, 57, and 58.

[0119] The live video of the monster 21A included in the game image 60A (second image) is video corresponding to the live video of the monster 21A included in the game image 50A (first image). The live video included in the second image is live video from a virtual camera tracking the monster 21A, similar to the live video in the wipe UI 71A. The live video included in the second image can also be described as an enlarged version of the live video displayed in the tapped wipe UI 71A. The game image 60A displays the monster 21A walking around the farm.

[0120] The UI component 54A displays first status information. The first status information includes the name of the monster 21A, "Monster A," a symbol indicating the gender, "male," and the level of the monster 21A, "Level 20." The UI component 55A displays second status information. The second status information includes information indicating the friendliness level of the monster 21A, "Level 3," its mood, "Good (smiley face)," and its training setting status, "Not selected." The UI component 56A displays third status information. The third status information includes information indicating the ability values ​​of the monster 21A, such as "HP 445," "SP 100," "Attack Power 80," and "Defense Power 70." The first status information, second status information, and third status information are examples of first information representing the status of the monster 21A (second object). The first status information, second status information, and third status information do not need to be displayed separately as in FIG. 9 and may be displayed together in a single UI component, for example. Furthermore, the first status information, the second status information, and the third status information are merely examples, and some of the information may be omitted, some of the information may be replaced with other information, or other information may be added. While Fig. 9 shows an example in which the first information is superimposed on the live video, the first information and the live video may be displayed in other ways, for example, side by side, one above the other, or side by side.

[0121] 6, the UI widget 52 has a scene title function and includes a display that explains the scene displayed in the game image 60A. In this example, the UI widget 52 includes the word "monster," indicating that the scene displays a monster 21. The UI component 53 is an operation button having a so-called "back" function, and when a tap operation is received, it switches the game image 60A to the image that was displayed immediately before (for example, the game image 50A). The UI component 57 is an operation button having a "swap" function, and when a tap operation is received, the UI component 57 switches to an image for performing processing to swap the monster 21A. The UI component 58 is an operation button having a "give food" function, and when a tap operation is received, the UI component 58 switches to an image for carrying out a process of giving food to the monster 21A.

[0122] FIG. 10 shows a second example of a game image to which a transition can be made from the game image of FIG. 6. Game image 60B of FIG. 10 is an example of a game image displayed on the display unit 1072 of the user terminal 100, particularly when a tap operation on wipe UI 71B is received. Game image 60B of FIG. 10 is a second example of a second image, and is also displayed in place of game image 50A (first image) of FIG. 6. Note that a similar game image may also be displayed when wipe UI 71B shown in FIG. 7 or FIG. 8 is tapped. Game image 60B of FIG. 10 includes an image corresponding to live video of monster 21B and UI components 52, 53, 54B, 55B, 56B, 57, and 58. Differences from FIG. 9 will be mainly described below.

[0123] The live video of the monster 21B included in the game image 60B (second image) is a video corresponding to the live video of the monster 21B included in the game image 50A (first image). The live video included in the second image is a live video of a virtual camera tracking the monster 21B, similar to the live video in the wipe UI 71B. The live video included in the second image can also be described as an enlarged version of the live video displayed in the tapped wipe UI 71B. The game image 60B shows the monster 21B meditating with his eyes closed on the farm.

[0124] UI component 54B displays first status information. The first status information includes the name of monster 21B, "Monster B," a symbol indicating the gender, "♀," and the level of monster 21B, "Level 1." UI component 55B displays second status information. The second status information includes information indicating monster 21B's affection level, "Level 5," mood, "Good (smiley face)," and training setting status, "Meditation." UI component 56B displays third status information. The third status information includes information indicating monster 21B's ability values, "HP 270," "SP 55," "Attack Power 45," and "Defense Power 40." The first status information, second status information, and third status information are examples of first information representing the status of monster 21B (second object). The first status information, second status information, and third status information do not need to be displayed separately as in FIG. 10 and may be displayed together in a single UI component, for example. Furthermore, the first status information, second status information, and third status information are merely examples, and some of the information may be omitted, some of the information may be replaced with other information, or other information may be added.

[0125] As shown in UI component 55B, monster 21B is set to "meditation" training. "Training" is not limited to "meditation," and other training content may be selectable. Ability values ​​may be set to change differently depending on the training content. For example, when "meditation" is set, monster 21's "defense power" is set to increase by a certain value every certain time. Game image 60B may also include a first ability increase display 74, as illustrated in FIG. 8.

[0126] The above describes an example in which the second image is displayed in place of the first image when a tap operation on the wipe UI 71 (an operation of selecting a predetermined area 70) is received. The second image includes information indicating the status of each monster and an image corresponding to a live video of each monster, and may also enable control over each monster. Additionally or alternatively, when a tap operation on the wipe UI 71 is received, the player character 11 may be configured to automatically move within the game space to a position close to the monster 21 displayed on the tapped wipe UI 71.

[0127] Fig. 11 shows a first example of a game image to which a transition can be made from the game image of Fig. 9. Game image 61 of Fig. 11 is an example of a game image displayed on display unit 1072 of user terminal 100 when an operation of tapping UI widget 57 in Fig. 9 is accepted. Game image 61 includes UI widget 52, UI widget 53, UI widget 62, UI widget 63, UI widget 64, UI widget 65, and UI widget 66.

[0128] The UI widget 52 has a scene title function, and indicates that the game image 61 is a scene after the UI widget 57 having the "swap" function has been selected. The UI component 53 has a so-called "back" function, and when it receives a tap operation, it switches the game image 61 to the image that was displayed immediately before (for example, the game image 60A). The UI component 62 includes information about the currently selected monster. In this example, the UI component 62 displays an image of the monster 21A and various pieces of information about the monster 21A (the same information as that displayed in FIG. 9).

[0129] The UI component 63 has a "remove" function, and when a tap operation is received, the UI component 63 performs a process of removing the monster 21A from the targets for raising. For example, the user selects "remove" when the ability value of the monster 21 reaches the upper limit. When the monster 21A is removed from the targets for raising, a vacancy occurs in the slot for a monster that can be placed on the farm.

[0130] The UI component 64 includes information about the monsters possessed by the player character 11. Monsters marked "In formation" are monsters currently placed in the farm. For example, by tapping one of the UI components 64, the user can swap the currently selected monster 21A with the tapped monster. The UI component 62 displays the status of the tapped monster instead of the monster 21A.

[0131] The UI widget 65 has a "cancel" function. For example, when the user taps the UI widget 65, the process that was just performed in the game image 61 is canceled. The UI widget 66 has an "OK" function. For example, when the user taps the UI widget 66, the monster displayed in the UI widget 62 is placed on the farm. In this way, the "swap" function allows you to swap monsters placed on the farm. In other words, the "swap" function allows you to swap monsters 21 displayed in the live video 20 within the wipe UI 71.

[0132] Fig. 12 shows a second example of a game image to which a transition can be made from the game image of Fig. 9. Game image 67 of Fig. 12 is an example of an image displayed on display unit 1072 of user terminal 100 when an operation to tap UI component 58 in game image 60A of Fig. 9 is received. Game image 67 includes live video of monster 21A, and UI components 52, 53, 68, 81, 82, 83A, 83B, 83C, 83D, and 83E.

[0133] The UI widget 52 has a scene title function, and the game image 67 shows a scene after the UI widget 58 having the "give food" function has been selected. The UI component 53 has a so-called "back" function, and when it receives a tap operation, it switches the game image 67 to the image that was displayed immediately before (for example, the game image 60A). The UI component 68 includes information about the currently selected monster. In this example, the UI component 68 includes information about the "familiarity" and "mood" parameters of the monster 21A's status. The UI component 68 may further include an upward arrow mark 69, which indicates that the "familiarity" and "mood" parameters are increasing. In the game image 67, a musical note mark 22 and a heart mark 23 are superimposed on the live video of the monster 21A as visual effects indicating that the "familiarity" and "mood" parameters are increasing, respectively. Such visual effects may also be reflected in the live video within the wipe UI 71.

[0134] UI components 83A, 83B, 83C, 83D, and 83E function as operation buttons that allow the user to give food objects to monster 21A. For example, if the user selects one of UI components 83A-83E and then drags and drops it near monster 21A or a specific part of monster 21A, the food object represented by that UI component is given to monster 21A. Alternatively, simply tapping a UI component 83A-83E may be sufficient to give the food object represented by that UI component to monster 21A. When a monster 21A is given a food object, its "friendship" or "mood" parameter increases. In FIG. 12, UI component 83C, surrounded by a solid line, is selected. UI component 83C corresponds to a cake object. As a result of being given the cake object, the "friendship" and "mood" parameters of monster 21A increase. Food objects are set to have different parameter increase rates depending on the type or number of food objects.

[0135] UI widgets 81 and 82 are examples of UI widgets for changing the display range of UI widgets 83A to 83E. For example, when the user taps UI widget 81, UI widget 83E, which is currently displayed at the right end, disappears, the display positions of UI widgets 83A to 83D each shift to the right, and UI widgets (not yet displayed) to the left of UI widget 83A are newly displayed. When the user taps UI widget 83, UI widget 83A, which is currently displayed at the left end, disappears, the display positions of UI widgets 83B to 83E each shift to the left, and UI widgets (not yet displayed) to the right of UI widget 83E are newly displayed. The change in display range when UI widget 81 and UI widget 82 are tapped may be in other ways, such as a shift in the opposite direction.

[0136] (3) Effects As described above in detail, according to the game program of one embodiment, live video images 20 of monsters (second objects) 21 that can move without user operation are displayed in a predetermined area 70 of a first image of a game space that includes a player character (first object) 10 that moves in response to a user operation. When a plurality of monsters 21 are placed in the game space, a plurality of live videos 20 corresponding to each monster 21 are displayed. This allows the user to easily check the current status of the monsters 21 as a list while operating the player character 10.

[0137] Furthermore, by using images captured by a virtual camera that captures each monster 21 as the live footage 20, the user can easily and intuitively understand not only the movements of each monster, but also information such as the type of game space the monster is in (grassland, rocky area, forest), and the mood it is in (whether or not there are any special effects such as musical note marks).

[0138] Furthermore, when an operation to select a wipe UI 71 displayed in a predetermined area 70 is received, the status of the monster 21 displayed in the wipe UI 71 is displayed. This allows the player character 11 to easily grasp the monster's development status without the need for complicated operations such as moving the player character 11 close to the monster 21 or having the player character 11 pick up the monster 21.

[0139] Therefore, according to one embodiment, a technique is provided that allows the state of an object placed in a game space to be easily confirmed.

[0140] [Other embodiments] The present invention is not limited to the above-described embodiment. For example, the first image does not need to include an image of the first object (player character 11) itself, but may include an image reflecting the field of view of the first object. In other words, the first object may be replaced by a virtual camera. When the first object is replaced by a virtual camera, the user can operate the position, direction, shooting range, focus, etc. of the virtual camera. In this case, the first image may be replaced by an image captured by the virtual camera without explicitly displaying the virtual camera as the first object.

[0141] In the above embodiment, the second image is displayed instead of the first image when the wipe UI 71 is tapped. However, the present invention is not limited to this. First information indicating the status of the monster 21 in the tapped wipe UI 71 may be superimposed on the first image.

[0142] The second object or the object to be raised is not limited to a monster character, but may be a living or inanimate object as long as it can be a subject of raising (can bring about some kind of change in the game as a result of raising).

[0143] 6 to 12 are merely examples, and some components may be omitted or replaced, or other components may be added. For example, UI components 51A, 51B, 51C, and 52 in FIG. 6 may be omitted or replaced with other components.

[0144] A display corresponding to the state of illness may be displayed around the sick monster 21. Also, a display that allows distinction between a sleeping state and a meditative state may be displayed. By projecting such a display onto the live video, combined with the display of transition information, it becomes easier to understand the current state of the monster 21.

[0145] Although a touch panel has been described as an example of the input unit 1071, the input unit 1071 is not limited to this. The input unit 1071 may be a controller having a plurality of buttons. The user's operation on the input unit 1071 may be replaced with an operation via the buttons on such a controller, or a keyboard or a mouse. For example, a tap operation may be rephrased as a click operation.

[0146] The operation acceptance unit 116 can also accept a signal from the sensor 1004 as a user operation. For example, the operation acceptance unit 116 can detect a user's facial expression or gesture via an image sensor or a gesture sensor and accept the detected signal as an operation. Alternatively, the operation acceptance unit 116 can detect a user's voice via a sound sensor and accept the detected signal as an operation.

[0147] 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. Furthermore, the series of processes described above do not need to be performed consecutively, and each step may be performed at any timing.

[0148] 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 across multiple devices, and replaced with similar configurations. Each functional unit of the server 200 and the user terminal 100 may be implemented 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.

[0149] 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. A program that realizes the above processing may be provided by being stored on a computer-readable recording medium. The program is stored on the recording medium as an installable file or an executable file. Examples of recording media include magnetic disks, optical disks (CD-ROMs, CD-Rs, DVDs, etc.), magneto-optical disks (MOs, etc.), semiconductor memories, etc. Any recording medium can be used as long as it can store the program and is computer-readable. Furthermore, 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.

[0150] It should be noted that this invention is not limited to the above-described embodiments, and various modifications can be made in the implementation stage without departing from the spirit of the invention. Furthermore, the embodiments may be implemented in appropriate combinations, in which case the combined effects can be obtained. Furthermore, the above-described embodiments include various inventions, and various inventions can be extracted by combining selected elements from the disclosed elements. For example, if the problem can be solved and the desired effect can be obtained even if some elements are deleted from all elements shown in the embodiments, the configuration from which these elements are deleted can be extracted as an invention. [Explanation of symbols]

[0151] 1...game system, 100...user terminal, 110...control unit, 111...game progression unit, 112...object control unit, 113...display control unit, 114...virtual camera control unit, 115...firm management unit, 116...operation reception 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

1. Computer, a means for displaying, in a predetermined area of ​​a first image in a virtual space, a plurality of live images captured by a virtual camera that tracks each of a plurality of objects that can be operated without user operation in the virtual space; a display control means for, when a specific object among the plurality of objects operable without user operation has transitioned to a specific state, displaying information indicating that the specific object has transitioned to the specific state in association with a live video image captured by a virtual camera that tracks the specific object among the plurality of live videos displayed in the predetermined area; To function as, program.

2. The display control means When the specific object has transitioned to a specific state, the information indicating that the specific object has transitioned to the specific state is superimposed on the specific area in association with a live video image captured by a virtual camera that tracks the specific object, among the plurality of live videos displayed in the specific area. The program according to claim 1.

3. a means for displaying, in a predetermined area of ​​a first image in a virtual space, a plurality of live images captured by a virtual camera that tracks each of a plurality of objects that can be operated without user operation in the virtual space; a display control means for, when a specific object among the plurality of objects operable without user operation has transitioned to a specific state, displaying information indicating that the specific object has transitioned to the specific state in association with a live video image captured by a virtual camera that tracks the specific object among the plurality of live videos displayed in the predetermined area; Equipped with Information processing system.

Citation Information

Patent Citations

  • JP1231889826A

  • Method for displaying game screen, recording medium and game device

    JP2002085827A

  • Program, information storage medium, game machine, and server device

    JP2005152318A

  • Game system, game device, game program, and image generation method

    JP2012252516A

  • Information processing program, information processor, control method for information processor, and information processing system

    JP2015230682A