Program and system

Abstract

To provide a game program, a game method, and an information processing device that can prevent a decline in the sense of participation in a game.SOLUTION: A first game part is executed in which an object whose state can be changed is placed in a virtual space and the state of the object is changed to a state advantageous to a user. The travel distance by the user who owns an information terminal device in a real space is specified. In the first game part, the in-game time in the first game part progresses on the basis of the travel distance, and the state of the object is changed to a state advantageous for the user, on the basis of the progress of the in-game time.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to a program and a system. [Background technology]

[0002] Conventionally, city-building games have been known in which the game progresses through a cycle in which objects such as buildings are placed within a game field, and over time, the objects are completed, value (coins, items, etc.) is generated for the objects, and new objects are placed using that value. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2019-69081 A Summary of the Invention [Problem to be solved by the invention]

[0004] But traditional games leave room for improvement.

[0005] The present invention has been devised in view of the above circumstances, and has as its object to provide a program and system for moving a character associated with a user to a specific object in accordance with the characteristics of the character. [Means for solving the problem]

[0006] According to one aspect of an embodiment disclosed herein, a program is provided for causing a computer to move a character associated with a user playing a location-based game to a specific object located in a virtual space according to the characteristics of the character when the user reaches a specific location.

[0007] According to one aspect of an embodiment disclosed herein, a system includes a means for, when a user playing a location-based game reaches a specific location, moving a character associated with the user to a specific object located in a virtual space according to characteristics of the character.

[0008] According to one aspect of an embodiment disclosed herein, an information terminal device having a processor, a memory, and a display unit executes the following steps: placing an object whose state can change in a virtual space, and executing a first game part in which the state of the object is changed to a state advantageous to the user; and determining a distance traveled in real space by a user possessing the information terminal device, wherein the step of executing the first game part includes a step of progressing in-game time in the first game part based on the distance traveled, and a step of changing the state of the object to a state advantageous to the user based on the progression of the in-game time. Effect of the Invention

[0009] According to the present invention, a user may be moved to a particular object depending on the characteristics of a character associated with the user. [Brief description of the drawings]

[0010] [Figure 1] FIG. 2 is a diagram illustrating a hardware configuration of the game system. [Diagram 2] (A) and (D) are diagrams showing an example of a display screen displayed on a touch screen during a location-based game, (B) and (E) are diagrams showing an example of a display screen displayed on a touch screen during a city-building game, and (C) is a diagram showing an example of the purchase price of an object, the in-game time required from placement on the game field to completion, and the distance traveled required for the in-game time to pass. [Diagram 3]13A shows an example of the display when a user checks into a portal while taking a resident character with them as a companion, and FIG. 13B shows the resident character's characteristics, episodes, and release conditions. [Figure 4] FIG. 11 is a diagram for explaining a flowchart of a location information game related process. [Diagram 5] FIG. 13 is a diagram for explaining a flowchart of processing related to a city-building game. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

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

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

[0015] 1, the user terminal 100 may be configured to be able to communicate with one or more controllers 1020. The controller 1020 establishes communication with the user terminal 100 in accordance with a communication standard such as Bluetooth (registered trademark). The controller 1020 may have one or more buttons, etc., and transmits output values ​​based on user input operations on the buttons, etc., to the user terminal 100. The controller 1020 may also have various sensors, such as an acceleration sensor and an angular velocity sensor, and transmits output values ​​of the various sensors to the user terminal 100.

[0016] Instead of or in addition to the user terminal 100 being equipped with the camera 17 and the distance measurement sensor 18, the controller 1020 may have the camera 17 and the distance measurement sensor 18.

[0017] For example, at the start of a game, the user terminal 100 desirably causes the user using the controller 1020 to input user identification information, such as the user's name or login ID, via the controller 1020. This enables the user terminal 100 to link the controller 1020 with the user, and to identify which user the output value belongs to based on the source (controller 1020) of the received output value.

[0018] When the user terminal 100 communicates with multiple controllers 1020, each user holds a controller 1020, and the single user terminal 100 can realize a multiplay without communicating with other devices such as the server 200 via the network 2. Also, the user terminals 100 can realize a multiplay locally by connecting to each other via a wireless standard such as a wireless LAN (Local Area Network) standard (connecting to communicate without going through the server 200). When the above-mentioned multiplay is realized locally by a single user terminal 100, the user terminal 100 may further include at least a part of various functions of the server 200, which will be described later. Also, when the above-mentioned multiplay is realized locally by multiple user terminals 100, the multiple user terminals 100 may include various functions of the server 200, which will be described later, in a distributed manner.

[0019] Even when the above-mentioned multiplay is realized locally, the user terminal 100 may communicate with the server 200. For example, information indicating a play result such as the score or win / loss in a certain game may be associated with user identification information and transmitted to the server 200.

[0020] Furthermore, the controller 1020 may be configured to be detachable from the user terminal 100. In this case, a coupling unit for the controller 1020 may be provided on at least one surface of the housing of the user terminal 100. When the user terminal 100 and the controller 1020 are coupled to each other via the coupling unit by a wire, the user terminal 100 and the controller 1020 transmit and receive signals via the wire.

[0021] 1, the user terminal 100 may accept the attachment of a storage medium 1030 such as an external memory card via the input / output IF 14. This allows the user terminal 100 to read programs and data recorded in the storage medium 1030. The program recorded in the storage medium 1030 is, for example, a game program.

[0022] The user terminal 100 may store in the memory 11 of the user terminal 100 a game program acquired by communicating with an external device such as the server 200, or may store in the memory 11 a game program acquired by reading it from the storage medium 1030.

[0023] As described above, the user terminal 100 includes the communication IF 13, the input / output IF 14, the touch screen 15, the camera 17, and the distance measurement sensor 18 as examples of mechanisms for inputting information to the user terminal 100. Each of the above-mentioned units as input mechanisms can be considered as an operation unit configured to receive an input operation by the user.

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

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

[0026] <Hardware components of each device> The processor 10 controls the overall operation of the user terminal 100. The processor 20 controls the overall operation of the server 200. The processors 10 and 20 each include a central processing unit (CPU), a micro processing unit (MPU), and a graphics processing unit (GPU).

[0027] The processor 10 reads a program from a storage 12 (to be described later) and loads it in a memory 11 (to be described later). The processor 20 reads a program from a storage 22 (to be described later) and loads it in a memory 21 (to be described later). The processors 10 and 20 execute the loaded programs.

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

[0029] In this embodiment, the program may be a game program for realizing a game by the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation between the user terminal 100 and the server 200. Note that the game realized through cooperation between the user terminal 100 and the server 200 may be, for example, a game executed on a browser launched in the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation between a plurality of user terminals 100. In addition, the various data include data related to the game, such as user information and game information, as well as instructions or notifications transmitted and received between the user terminal 100 and the server 200 or between a plurality of user terminals 100.

[0030] The storages 12 and 22 are auxiliary storage devices. The storages 12 and 22 are configured with storage devices such as flash memories or HDDs (Hard Disk Drives). The storages 12 and 22 store various data related to games.

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

[0032] The input / output IF 14 is an interface through which the user terminal 100 receives input of data, and is also an interface through which the user terminal 100 outputs data. The input / output IF14 may input and output data via a USB (Universal Serial Bus) or the like. The input / output IF14 may include, for example, a physical button, a camera, a microphone, or a speaker of the user terminal 100. The input / output IF24 of the server 200 is an interface through which the server 200 accepts input of data, and is also an interface through which the server 200 outputs data. The input / output IF24 may include, for example, an input unit that is an information input device such as a mouse or a keyboard, and a display unit that is a device that displays and outputs an image.

[0033] The touch screen 15 of the user terminal 100 is an electronic component that combines an input unit 151 and a display unit 152. The input unit 151 is, for example, a touch-sensitive device, and is configured, for example, by a touch pad. The display unit 152 is, for example, a liquid crystal display, an organic EL (Electro-Luminescence) display, or the like.

[0034] The input unit 151 has a function of detecting a position where a user operation (mainly a physical contact operation such as a touch operation, a slide operation, a swipe operation, or a tap operation) is input on the input surface, and transmitting information indicating the position as an input signal. The input unit 151 may include a touch sensing unit (not shown). The touch sensing unit may adopt any type of method, such as a capacitive type or a resistive film type.

[0035] Although not shown, the user terminal 100 may include one or more sensors for identifying the holding posture of the user terminal 100. The sensor may be, for example, an acceleration sensor or an angular velocity sensor. When the user terminal 100 includes a sensor, the processor 10 may identify the holding posture of the user terminal 100 from the output of the sensor and perform processing according to the holding posture. For example, when the user terminal 100 is held vertically, the processor 10 may perform a portrait screen display in which a vertically long image is displayed on the display unit 152. On the other hand, when the user terminal 100 is held horizontally, the processor 10 may perform a landscape screen display in which a horizontally long image is displayed on the display unit. In this way, the processor 10 may be capable of switching between portrait screen display and landscape screen display according to the holding posture of the user terminal 100.

[0036] The camera 17 includes an image sensor and the like, and generates a captured image by converting incident light entering through a lens into an electrical signal.

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

[0038] Here, an example will be further described in which the user terminal 100 receives a detection result of an object 1010 in the vicinity of the user terminal 100 using the camera 17 and the distance measurement sensor 18 as an input operation from the user. The camera 17 and the distance measurement sensor 18 may be provided, for example, on a side surface of the housing of the user terminal 100. The distance measurement sensor 18 may be provided near the camera 17. For example, an infrared camera may be used as the camera 17. In this case, a lighting device that irradiates infrared rays and a filter that blocks visible light may be provided in the camera 17. This can further improve the accuracy of object detection based on an image captured by the camera 17, regardless of whether the location is outdoors or indoors.

[0039] The processor 10 may perform, for example, one or more of the following processes (1) to (5) on the captured image of the camera 17. (1) The processor 10 performs an image recognition process on the captured image of the camera 17 to determine whether or not the captured image includes a user's hand. The processor 10 may use, for example, a pattern matching technique as an analysis technique employed in the above-mentioned image recognition process. (2) The processor 10 also detects a gesture of the user from the shape of the user's hand. For example, the processor 10 determines the number of fingers of the user (the number of extended fingers) from the shape of the user's hand detected from the captured image. The processor 10 further determines the gesture made by the user from the determined number of fingers. For example, when the number of fingers is five, the processor 10 determines that the user has made a "paper" gesture. When the number of fingers is zero (no fingers are detected), the processor 10 determines that the user has made a "rock" gesture. Furthermore, when the number of fingers is two, the processor 10 determines that the user has made a "scissors" gesture. (3) The processor 10 detects whether the user's fingers are in a state where only the index finger is raised or whether the user's fingers are flicking by performing an image recognition process on the image captured by the camera 17. (4) The processor 10 detects the distance between the object 1010 (such as the user's hand) near the user terminal 100 and the user terminal 100 based on at least one of the image recognition result of the image captured by the camera 17 and the output value of the distance measuring sensor 18. For example, the processor 10 detects whether the user's hand is near the user terminal 100 (e.g., a distance less than a predetermined value) or far away (e.g., a distance equal to or greater than a predetermined value) based on the size of the shape of the user's hand identified from the image captured by the camera 17. Note that when the captured image is a video, the processor 10 may detect whether the user's hand is approaching or moving away from the user terminal 100. (5) If the user's hand is detected based on the image recognition results of the image captured by camera 17, and it is determined that the distance between user terminal 100 and the user's hand is changing, processor 10 recognizes that the user is waving his or her hand in the direction of the camera 17.When the distance measuring sensor 18, which has a stronger directivity than the imaging range of the camera 17, detects an object in some cases but not in other cases, the processor 10 recognizes that the user is waving his / her hand in a direction perpendicular to the imaging direction of the camera.

[0040] In this way, the processor 10 detects whether the user has clenched his / her hand (whether it is a "rock" gesture or another gesture (e.g., "paper")) by image recognition of the image captured by the camera 17. The processor 10 also detects how the user is moving the hand along with the shape of the user's hand. The processor 10 also detects whether the user is moving the hand closer to or farther away from the user terminal 100. Such an operation can correspond to an operation using a pointing device such as a mouse or a touch panel. For example, the user terminal 100 moves a pointer on the touch screen 15 in response to the movement of the user's hand and detects the user's gesture of "rock". In this case, the user terminal 100 recognizes that the user is continuing the selection operation. The continuation of the selection operation corresponds, for example, to the mouse being clicked and kept pressed, or to the touch panel being kept touched after a touchdown operation. Furthermore, when the user moves his / her hand further while the user terminal 100 has detected the user gesture "rock", the user terminal 100 can recognize such a series of gestures as an operation corresponding to a swipe operation (or a drag operation). Furthermore, when the user terminal 100 detects a gesture of the user flicking fingers based on the detection result of the user's hand from the image captured by the camera 17, the user terminal 100 may recognize the gesture as an operation corresponding to a mouse click or a tap operation on a touch panel.

[0041] <Game Overview> Games executed by the game system 1 according to the present embodiment include location-based games and city-building games. Location-based games are games in which a user actually moves through a real space, moves on a map image corresponding to the real space according to the user's position in the real space, and checks in to a portal located on the map image to obtain a reward corresponding to the portal (e.g., in-game currency, a souvenir item corresponding to the portal, etc.).

[0042] On the other hand, city-building games involve placing buildings and other objects in a virtual space in response to user input, evolving those objects (for example, completing buildings, generating value, leveling up, etc.) as time passes in the game, and associating resident characters with the virtual space in response to the placement of objects, thereby developing and growing the user's city.

[0043] The location information game and the city building game are different types of games. However, the in-game time for evolving buildings and the like in the city building game elapses (progresses) according to the distance traveled by the user in the location information game. In this embodiment, for example, the in-game time can elapse 10 minutes by the user moving 1 km in the real space, but this is not limited thereto, and the in-game time can elapse 1 minute by moving 100 m.

[0044] In addition, rewards (in-game currency) acquired in the location-based game can be used to newly purchase and place objects in the city-building game. Furthermore, a resident character associated with a virtual space in the city-building game can be moved as a companion to the user in the location-based game, and when the user checks in to a portal, the resident character can be used to automatically check in to other portals without the user having to move, and acquire rewards for those portals.

[0045] For this reason, for example, a game cycle can be provided to the user in which: acquire a benefit in the location information game → place an object such as a building in the city building game → move in the location information game → evolve the building in the city building game (develop the city) and associate a resident character with the building → double the benefit acquired by taking the resident character to a portal check-in in the location information game → further evolve the building in the city building game (further develop the city)... In the following, the location information game and the city building game will each be described in detail.

[0046] First, the location information game will be described. When the location information game is started, the user terminal 100 uses information from a location registration system, a GPS (Global Positioning System) module of the user terminal 100, and the like to identify the current location information (e.g., address information, latitude and longitude information, etc.) of the user terminal 100, and displays a map of the surroundings of the current location of the user terminal 100 (the user who owns the terminal) in the real space based on the current location information. When displaying the map, for example, the current location information is transmitted to the server 200 to request the transfer of map data of the surroundings of the current location. The server 200 acquires map data of the surroundings of the user terminal 100 from another service providing device (server) that provides map data via a network, and also acquires portal information (information for identifying the location of the portal, the type of the portal, etc.) related to portals arranged in the vicinity of the user terminal 100, and transmits the portal information to the user terminal 100 together with the map data of the surroundings of the user terminal 100.

[0047] The user terminal 100 displays a map image based on the map data on the touch screen 15, and displays a portal superimposed at a predetermined position on the map image based on the portal information received together with the map data. Specifically, a map image of a part of the map image based on the map data, the area being centered on the user's position in real space, is displayed on the touch screen 15. The portal is displayed at a position specified by the portal information in a manner that allows the type of portal to be specified. Also, a current position image indicating the user's current position in real space and a circle image indicating a predetermined range (for example, a radius of 200 m) from the current position are superimposed and displayed on the map image on the touch screen 15.

[0048] Fig. 2(A) is a diagram showing an example of a display screen displayed on the touch screen 15 during a position information game. Fig. 2(A) illustrates an example in which the user who owns the user terminal 100 is located around Ebisu Station, southwest of the station. A map image 201 of the area around the station is displayed on the touch screen 15, and portals P1 to P4, a current position image U, and a circle image C are displayed superimposed on the map image 201.

[0049] Each of the portals P1 to P4 is displayed with an image indicating the type of the portal. As portals that can be arranged on the map image, various types of portals are provided, such as parks, coffee shops, supermarkets, department stores, ramen shops, temples, schools, amusement parks, factories, banks, stadiums, mountains, oceans, rivers, fields, apartment buildings, laboratories, power plants, and police stations. As an image indicating the type of the portal, a photo image or the like that allows the user to recall the type is displayed. In FIG. 2(A), the name of the type is shown instead of a photo image. For example, the portal P1 is displayed with a photo image of a tent and a hammock suggesting that it is a type belonging to leisure, and the portal P4 is displayed with a photo image of a temple suggesting that it is a type belonging to temple. In this embodiment, an example in which a photo image or the like is displayed in correspondence with the portal will be described, but the present invention is not limited to this. By tapping on a portal, a photo image or the like according to the type of the portal that is the target of the tapping operation may be displayed.

[0050] In the location-based game, a player can check in to a portal placed within the circle image C by performing a touch operation on the portal (or an image (photo image) showing the type of the portal displayed corresponding to the portal). In the example of FIG. 2(A), a player can check in to a portal by performing a touch operation on portal P1 or portal P3 placed within the circle image C.

[0051] When a user checks in to a portal, the user can acquire a benefit according to the type of the portal. For example, the user can acquire an amount of in-game currency according to the type of portal, or a souvenir item according to the type of the checked-in portal. The souvenir item is, for example, an item related to local gourmet food or famous products of the area where the portal is located. In a location-based game, the user can acquire a benefit by actually moving through the real space and checking in to a portal located on the map image. Information for identifying the acquired benefit is stored in the memory 11.

[0052] Furthermore, when the user moves, the user terminal 100 transmits current location information to the server 200 again and acquires portal information around the user terminal 100 and map data around the user terminal 100. A map image based on the map data is displayed on the touch screen 15, and portals are displayed superimposed on the map image based on the portal information. That is, the map image and portals on the touch screen 15 are updated as the user who owns the user terminal 100 moves.

[0053] In addition, in the location information game, movement distance information capable of identifying the movement distance that the user has moved in real space toward the desired portal is stored in the memory 11. In the location information game, movement at a predetermined speed (e.g., 100 m / min) or less, such as walking or jogging, is counted as the user's movement, and movement at a speed exceeding the predetermined speed (e.g., by car or train) is excluded from the counting.

[0054] Next, a city building game will be described. In the city building game, a user builds a city by placing objects owned by the user in a game field, which is a virtual space, based on input operations by the user. In the city building game, objects can be purchased by consuming in-game currency, and then owned and placed. Information for identifying owned objects, placed objects, and their placement positions is stored in memory 11.

[0055] Fig. 2(B) is a diagram showing an example of a display screen displayed on touch screen 15 during a city-building game. The example shown in Fig. 2(B) shows a screen that is displayed when placing a purchased object, in which a game field is displayed in a first area 202 that occupies most of touch screen 15, and objects 204, 205 owned by the user are displayed in a second area 203 at the bottom of touch screen 15.

[0056] The user can place a desired object at a desired position in the game field by dragging the object shown in the second area 203 and dropping it at the desired position in the game field. In Fig. 2(B), a plurality of objects have already been placed to form the user's town T1, and a state is shown in which the user is about to place a new owned object 204.

[0057] A number of types of objects are provided corresponding to buildings that may exist in the real world, such as parks, coffee shops, supermarkets, department stores, ramen shops, temples, schools, amusement parks, factories, banks, stadiums, mountains, oceans, rivers, fields, apartment buildings, laboratories, power plants, and police stations.

[0058] When an object is placed on the game field, it first goes into construction state, and the in-game time required to complete it is determined for each type of object. The remaining in-game time required to complete an object in construction state is displayed superimposed on the object by, for example, tapping the object.

[0059] After the in-game time required for completion has elapsed and the object is in a completed state, the object exerts an effect corresponding to the object each time a predetermined time in-game time (e.g., the time required for production to be completed) has elapsed. Therefore, the completion of the object increases the degree of advantage for the user in town building. The time required to exert an effect and the effect exerted are determined for each type of object. For example, fields, coffee shops, ramen shops, etc. are associated with the effect of producing food, mountains, oceans, factories, etc. are associated with the effect of producing resources, department stores, banks, etc. are associated with the effect of issuing funds (in-game currency), and schools, buildings, laboratories, etc. are associated with the effect of development. A town generated in a town building game is evaluated based on, for example, the total value or ratio of food, resources, funds, and development, which can be specified from the number and type of objects placed. In a town building game, for example, the greater the total value of food, resources, funds, and development, and the better the balance of the four items, the richer the town is evaluated to be.

[0060] Further, for an object in a completed state, a level of the object is set. The level of the object affects, for example, the magnitude of the effect to be exerted and the time required to exert the effect, and the higher the level of the object, the greater the effect to be exerted and the shorter the time required to exert the effect. This increases the degree of advantage for the user in town development. For an object in a completed state, for example, an in-game time required to reach the next level is set. The in-game time required to exert the next effect and the in-game time required to reach the next level are superimposed on the object by, for example, tapping the object. Information for identifying the state of the object (under construction, completed, exerted effect, level, etc.), the total value and ratio of each of food, resources, funds, and development in the entire town, and a value indicating the wealth of the town are stored in the memory 11.

[0061] As mentioned above, the in-game time that affects the completion, effect, and level improvement of objects elapses according to the distance traveled by the user in the location-based game. In addition, the in-game currency required to purchase objects can also be acquired by the user checking in to a portal in the location-based game.

[0062] FIG. 2(C) shows an example of the purchase price of an object, the in-game time required from placement on the game field to completion, and the travel distance required to pass the in-game time. As shown in FIG. 2(C), a park object can be purchased by spending "25" in-game currency, and is completed when 10 in-game minutes have passed since placement. Therefore, when the travel distance reaches 1 km, 10 in-game minutes have passed and the placed park object can be completed. Similarly, the purchase price, the in-game time from placement to completion, and the travel distance required are also determined for a coffee shop object and a factory object. In addition, for each object, the in-game time required to exert an effect once after completion, and the in-game time required to reach the next level are determined. This allows the user to play a location information game and to be encouraged to move after placing an object in a city building game or after exerting an effect. Information that can specify the remaining in-game time required to improve the degree of advantage, such as completion, exertion of an effect, and level up, is stored in memory 11 for each object.

[0063] FIG. 2(D) illustrates a case where a user who owns a user terminal 100 walks from around Ebisu Station (for example, FIG. 2(A)) to a place located northwest of Shibuya Station during a location-based game. A map image 210 of the area around the station is displayed on the touch screen 15, and portals P5 to P7 arranged on the map image 210 are displayed superimposed on the map image 210, along with a current location image U and a circle image C. The user can check in to any of the portals P5 to P7 by moving to a position within the circle image C and touching the portal. This allows the user to acquire in-game currency according to the type of the portal. In addition, the user can acquire a souvenir item according to the type of the portal by spending the in-game currency owned by the user.

[0064] Furthermore, in location-based games, the in-game time in a city-building game can be advanced by updating the distance traveled information as the user moves. As a result, in the city-building game, in-game currency is consumed to purchase and place objects, and the in-game time is advanced based on the distance traveled information to complete the objects, exert their effects, level up, etc., and the user's city can be developed and grown as shown in Fig. 2(E). Fig. 2(E) shows how the city T1 shown in Fig. 2(B) is developed and grown into a larger city by further placing many objects in it.

[0065] In a city-building game, resident characters are associated with a user's city in response to the development and growth of the city by placing objects. Resident characters K1 to K7 are associated with the city shown in FIG. 2(E). As resident characters that can be associated with a virtual space, a plurality of types of characters with different characteristics such as hobbies and tastes are provided, and characters having characteristics according to the type of object placed in the virtual space are associated. For example, when a museum object is placed, characters having a characteristic of liking art such as paintings are associated at a higher rate than when the museum object is not placed. Also, when a ramen shop object is placed, characters having a characteristic of liking ramen are associated at a higher rate than when the ramen shop object is not placed.

[0066] Also, the number of resident characters increases or decreases depending on, for example, the wealth of the user's town. For example, the larger the total value of food, resources, funds, and development, and the more balanced they are, the more resident characters are associated. In FIG. 2(E), in the second area 203, a pie chart shows the balance of food, resources, funds, and development, and the number of resident characters associated with the user's town is shown in the center of the pie chart. In the example of FIG. 2(E), it is shown that food is 40%, resources are 30%, funds are 20%, and development is 10%, and there are seven resident characters. Information that enables identification of the resident characters and characteristics associated with the user's town is stored in the memory 11.

[0067] A resident character associated with the town can be taken out as a companion to the user in the location-based game. The resident character and the number of characters to be taken out as a companion are specified by selection by the user when starting the location-based game.

[0068] FIG. 3(A) is a display example when a user checks into portal P1 with resident characters K1 to K7 as companions. Resident characters K1 to K7 each have characteristics. As shown in FIG. 3(B), resident character K1 has a characteristic of liking B-grade gourmet food, resident character K2 has a characteristic of liking visiting coffee shops, and resident character K3 has a characteristic of exploring history. Although not shown, resident characters K4 to K7 also have similar characteristics.

[0069] On the other hand, as shown in Fig. 3(A), around the portal P1, there are arranged a ramen portal P2 which has a commonality with B-grade gourmet food, a coffee portal P3 which has a commonality with coffee shop hopping, and a temple portal P4 which has a commonality with historical exploration. In this case, as shown in Fig. 3(A), among the resident characters K1 to K7 taken out as companions, a display is made in which the resident character K1 moves to the portal P2, the resident character K2 moves to the portal P3, and the resident character K3 moves to the portal P4, and each checks in to the portal with which it has a commonality.

[0070] In this way, when a user checks in to a portal, the resident character identifies a type of portal other than the portal the user checked in to that has a high degree of commonality with the resident character's characteristics, and checks in to that portal. The range in which the resident character can check in is set to a range larger than the circle image C (for example, a radius of 500 m). This allows the user to earn in-game currency corresponding to each of the portals P2 to P4, even if the user himself does not check in to the portals P2 to P4.

[0071] When a resident character checks in to a portal, a question is displayed as to whether or not to purchase a souvenir item corresponding to the portal, and the user can acquire the souvenir item of the portal by selecting purchase using in-game currency. Note that, for the resident characters K4 to K7 taken along as companions, if there is no portal that has characteristics in common with the resident characters, the resident characters may not check in to any portal, and may check in to any portal even if there is no portal that has characteristics in common with the resident characters.

[0072] Furthermore, as shown in FIG. 3(B), each resident character is assigned an episode and an unlocking condition (viewing condition) for that episode. An episode is associated with each resident character and is a narrative presentation related to that resident character. The unlocking condition for an episode is met when the user acquires a specific souvenir item according to the characteristics of the resident character and gives (consumes) that souvenir item to that resident character. The unlocking condition for an episode may also be met when the user acquires a specific souvenir item. Information for identifying the title and unlocking condition of a resident character's episode is stored in memory 11.

[0073] As shown in FIG. 3B, the resident character K1 is associated with EP1 and EP2 as episodes, and a release condition is set by giving a souvenir item of fried rice or steamed buns that can be purchased at a portal corresponding to XX restaurant. EP1 is set to have a story that explains why the resident character K1 likes XX restaurant. The resident character K2 is associated with EP3 and EP4 as episodes, and a release condition is set by giving a souvenir item of cookies or coffee beans that can be purchased at a portal corresponding to Cafe △△. In this way, items that are related to the characteristics of the resident character are set as specific souvenir items that can satisfy the release condition of the episode. Similarly, specific episodes and release conditions are set for other resident characters. The episode titles and release conditions of the resident characters are displayed in a list when selecting a resident character to be taken out as a companion during a location-based game. In addition, when the episode titles and release conditions are displayed in a list, the location of the portal where the souvenir item that satisfies the release condition can be obtained and the distance to the portal are also displayed. This allows the user to confirm the portal that should be reached in order to unlock an episode for a desired resident character, and motivates the user to move to that portal.

[0074] Next, the process for playing the location information game and the city building game will be described. Fig. 4 is a diagram for explaining a flowchart of the location information game related process included in the process for playing the location information game. The location information game related process is executed by the user terminal 100, but is not limited to this, and some of the process may be executed by the server 200 and the process result may be transmitted to the user terminal 100.

[0075] In step S01, when starting a location-based game, a resident character to be taken along as a companion is determined. Specifically, the user refers to the titles and release conditions of the episodes of the resident characters displayed in a list when starting a location-based game, and selects the resident character to be taken along as a companion while checking the souvenir items that satisfy the release conditions and the distance to the portal.

[0076] In step S02, the moving distance information is updated according to the moving distance based on the user's position in the real space. The moving distance may be, for example, a straight line distance from the user's position when the position information game is started to the user's current position, or may be a distance traveled by the user from the user's position when the position information game is started to the user's current position.

[0077] In step S03, it is determined whether or not the user has checked in to any portal in the circle image C. If it is not determined that the user has checked in, it is assumed that the user is moving, and the process proceeds to step S02, where the travel distance is updated according to the user's movement. During this time, the map image and portals on the touch screen 15 are updated according to the user's movement.

[0078] On the other hand, when it is determined that the user has checked in, in step S04, the in-game currency corresponding to the portal that the user checked in to is granted to the user. In step S05, souvenir items are granted in accordance with the consumption of the in-game currency owned by the user. Specifically, when the user checks in to a portal, the granted in-game currency is notified, and then a list of souvenir items that can be purchased at that portal is displayed, and the souvenir items can be purchased according to the user's selection operation.

[0079] In step S06, it is determined whether or not the resident character is accompanied by a companion. If it is not determined that the resident character is accompanied by a companion, the process proceeds to step S10. On the other hand, if it is determined that the resident character is accompanied by a companion, the process proceeds to step S07, where a process is performed to determine a portal to which the resident character will check in. In step S07, the portal to be the check-in destination is determined based on the characteristics of the resident character taken as a companion and the commonality with the types of portals arranged around the portal where the user checked in. Portals that can be the check-in destination are not limited to portals within the circle image C, but include portals arranged in a wider area than the circle image C. For the resident character for which the check-in destination has been determined, a display is displayed to move to the determined portal and check in.

[0080] In step S08, the in-game currency corresponding to the checked-in portal is granted. In step S09, souvenir items are granted in accordance with the consumption of the in-game currency owned by the user. Specifically, when a resident character checks in to a portal, the granted in-game currency is notified, and then a confirmation window is displayed in which the resident character is asked to confirm whether or not it is OK to purchase a souvenir item available at that portal. When the user indicates that it is OK to purchase, the resident character is permitted to purchase the souvenir item, and the souvenir item can be purchased. In this case, the souvenir item to be purchased may be selected according to a selection operation by the user, or may be selected randomly based on the characteristics of the resident character.

[0081] In step S10, a souvenir item for unlocking an episode of a resident character is acquired, and the souvenir item is given (consumed) to the resident character, thereby unlocking the episode related to the resident character. This allows the resident character's episode to be viewed.

[0082] 5 is a diagram for explaining a flowchart of a city-building game-related process included in the process for playing the city-building game. The city-building game-related process is executed by the user terminal 100, but is not limited to this. A part of the process may be executed by the server 200, and the process result may be transmitted to the user terminal 100. When starting the city-building game, in step S20, the in-game time is elapsed according to the travel distance based on the travel distance information updated in the location information game. Specifically, 10 minutes of the in-game time is elapsed for every 1 km.

[0083] In step S21, it is determined whether or not the time to improve the degree of advantage of the placed object has elapsed based on the elapsed in-game time. The time to improve the degree of advantage of the object includes the time required for the object to change from a construction state to a completed state, the time required for the object to be effective, the time required for the object to be leveled up, etc. If it is not determined that the time to improve the degree of advantage of the object has elapsed, there is no object whose state will change, so the process proceeds directly to step S26.

[0084] On the other hand, when it is determined that the time for improving the degree of advantage of the object has elapsed, the degree of advantage of the object that is the subject of the determination is improved in step S22. Specifically, when the object is in a construction state, the object is updated to a completed state, an effect is exerted, or the object is leveled up.

[0085] In step S23, the wealth of the town is identified based on the total value or ratio of each of food, resources, funds, and development by the objects placed in the user's town. In step S24, it is determined whether or not to newly associate a resident character with the town according to the wealth of the town. For example, it may be determined that a new resident character is associated with the town every time the total value of each of food, resources, funds, and development in the entire town increases by a predetermined value. When it is determined that a new resident character is associated, in step S25, a resident character having a characteristic according to the type of object placed in the town is associated. As described above, when a museum object is placed, a character having a characteristic of liking art such as paintings is associated at a higher rate than when a museum object is not placed.

[0086] In step S26, it becomes possible to purchase and place new objects such as buildings using the in-game currency acquired in the location information game. This allows the user's town to grow and develop, and encourages the user to start the location information game again to move in real space in order to complete the newly placed object or to improve the advantage of the object already placed.

[0087] <Effects of this embodiment> According to this embodiment, as shown in step S20 of Fig. 5, in-game time for improving the degree of advantage of objects and growing and developing the city in a city-building game progresses based on the distance traveled by the user in real space in a location-based game. This makes it possible to encourage the user to move in order to progress the in-game time, and prevents a decline in the user's motivation to participate in the game.

[0088] In addition, the degree of advantage of the object increases as a predetermined time for each object passes, as shown in step S21 and step S22 of Fig. 5. Therefore, the user can be prompted to move in order to advance the predetermined time.

[0089] In a city-building game, as shown in steps S23 to S25 of FIG. 5, a resident character can be associated with a city by growing and developing the city. In a location-based game, as shown in steps S06 to S09 of FIG. 4, a user can take a resident character out as a companion, move the resident character, and check in to a portal to obtain a benefit corresponding to the portal. Furthermore, a user can obtain a benefit by automatically moving the resident character taken out as a companion to another portal and checking in the resident character. As a result, the more resident characters there are, the more benefits the user can obtain efficiently. As a result, the user can be motivated to grow and develop the city in order to associate more resident characters taken out as companions with movements in the location-based game.

[0090] Also, as shown in step S07 of FIG. 4, the check-in destination of the resident character is determined based on the characteristics of the resident character from portals arranged within a range wider than the circle image C. Therefore, the user can check in to portals that are not arranged within the circle image C without actually moving. As a result, it is possible to generate an incentive to associate more resident characters. Also, the characteristics of the resident character associated with the town are determined according to the type of object arranged, as shown in step S25 of FIG. 5. Also, the number of resident characters is determined according to the wealth of the town specified from the objects arranged, as shown in steps S23 and S24 of FIG. 5. Therefore, it is possible to provide the fun of deciding what type of object to arrange in the town building game.

[0091] The rewards obtained by portal check-in include in-game currency for purchasing objects in the city-building game. Therefore, more in-game currency is needed to grow and develop the city, which encourages the user to move around in the location-based game and motivates the user to check in to the portal.

[0092] As shown in FIG. 3(B), each resident character is assigned a specific episode and a release condition for releasing the episode. The release condition is met by granting (consuming) a specific souvenir item corresponding to the resident character's characteristics to the resident character. This can motivate the user to move toward a portal where the souvenir item for releasing the resident character's episode can be acquired. The souvenir item can be acquired by checking in to the portal and then consuming in-game currency. This can further encourage the user to check in to the portal to acquire in-game currency.

[0093] <Modification> Modifications of the above-described embodiment are listed below.

[0094] (1) Distance traveled and in-game time The above embodiment has been described with reference to an example in which the travel distance information updated in step S02 of FIG. 4 is reflected in the in-game time of the city-building game in step S20 of FIG. 5 regardless of whether the user has checked in to a portal. However, the travel distance information updated in step S02 of FIG. 4 may be reflected in the in-game time of the city-building game by checking in to a portal, and may not be reflected in the in-game time even if the user has moved at a stage when the user has not checked in to a portal. This can further encourage the user to check in to a portal. In this case, the travel distance information may be updated not by the distance actually traveled by the user, but by the distance (straight-line distance, or distance traveled along a predetermined route) from the user's position when the position information game is started to the checked-in portal. This can reduce the processing load for calculating the travel distance. In addition, the user may specify a portal to be a destination when starting a position information game, and check in to the portal, thereby causing the updated travel distance information to be reflected in the in-game time.

[0095] In the above embodiment, the moving distance information is updated during the location-based game, and is not updated when the location-based game is not being played. However, the moving distance information may be updated according to the user's movement in real space, for example, during a city-building game, regardless of whether the location-based game is being played or not, and may be reflected in the in-game time. This allows the in-game time to progress independently according to the moving distance associated with the user's movement while displaying the screen during the city-building game.

[0096] The travel distance information may be updated according to the user's movement in real space, regardless of whether the program for executing the game is running (logged in). For example, if the user terminal 100 has a function for periodically (e.g., every 30 seconds) storing (accumulating) the user's position information in the memory 11, when the user starts (logs in) the program for executing the game, the program for the game may read out the position information stored (accumulated) in the memory 11, and from the position information, identify the user's travel distance while the program for the game is not running, and update the travel distance information according to the travel distance to reflect it in the game time. Note that the update of the travel distance information when the program for the game is running is as described above.

[0097] Also, as shown in step S20 of FIG. 5, an example has been described in which the in-game time in the city-building game is updated during the city-building game (at the start) and is not updated when the city-building game is not in progress. However, the in-game time in the city-building game may be updated according to the user's movement in real space, for example, even during the location-based game, regardless of whether the city-building game is in progress. In this case, when it is determined that the time has elapsed for improving the degree of advantage of an object according to the user's movement in the location-based game, information that can identify the type of the object and the improved content may be displayed in a predetermined area in the location-based game (for example, a pop-up display in the header area). This can encourage the user to switch to the city-building game.

[0098] (2) About the resident characters In the above embodiment, as shown in step S01 of Fig. 4, an example has been described in which the user selects a resident character to be taken as a companion. However, the resident character to be taken as a companion may be determined by lottery. In addition, when a portal to be a destination is set when starting a location information game, a resident character having characteristics that are highly common to the set portal and portals around the set portal may be determined (or determined at a high rate) as the resident character to be taken as a companion, depending on the types of these portals.

[0099] In the above embodiment, an example has been described in which a user checks in to a portal, causing a resident character taken as a companion to check in to another portal. However, the companion resident character may be automatically checked in to a portal without the user checking in to the portal. For example, when a portal having the same characteristics and type as the companion resident character is placed while the user is moving toward a desired portal, the resident character may be automatically checked in to the portal to acquire a benefit. This provides the user with the fun of deciding which route to take to move to the portal.

[0100] In the above embodiment, an example has been described in which the range in which a resident character can automatically check in is set (for example, a range of a 500 m radius). However, the range in which a resident character can automatically check in may not be set. This allows the resident character to move freely and check in.

[0101] In the above embodiment, an example was described in which a resident character associated with a town can be taken out as a companion to the user at any time. However, when a value of a predetermined parameter related to the resident character is equal to or greater than a predetermined value, the resident character can be taken out as a companion, and when the value is less than the predetermined value, the resident character cannot be taken out as a companion. Specifically, a parameter such as stamina may be set for the resident character, and the stamina parameter may be consumed according to the distance traveled as a companion to the user, and when the stamina parameter is equal to or greater than a predetermined value, the resident character can be taken out as a companion, and when the stamina parameter is less than the predetermined value, the resident character may not be taken out as a companion. In addition, when the stamina parameter becomes 0 during the movement, the resident character's companionship ends at that point, and the resident character may not be able to accompany the user beyond that point. This can add fun to the scene in which the resident character to be the companion is selected.

[0102] In addition, certain parameters related to resident characters may be made recoverable according to the distance traveled by the user when not accompanying the user as a companion, or may be made recoverable by providing souvenir items for recovering stamina, or even may be made recoverable according to the amount of virtual currency purchased through a charge.

[0103] (3) Souvenir items In the above embodiment, an example was described in which souvenir items corresponding to portals could be purchased with in-game currency, but the present invention is not limited to this, and souvenir items may be purchased with virtual currency purchased through a charge.

[0104] In the above embodiment, an example has been described in which the release condition of an episode is satisfied by acquiring or giving a specific souvenir item to a resident character of the user, and the user can view the episode. However, a parameter for satisfying the release condition of an episode may be updated by acquiring or giving a specific souvenir item, and the release condition of an episode may be satisfied by acquiring or giving the specific souvenir item and then reaching a predetermined value. In addition, the resident character is not limited to a resident character associated with the town of the user. The release condition of an episode of a resident character of another user who has a predetermined relationship (for example, a friend relationship) with the user may be satisfied by acquiring or giving a specific souvenir item to the resident character of the other user, and the user may be able to view the episode of the resident character. This allows interaction with other users and increases interest.

[0105] Also, an example has been described in which souvenir items at a portal where a resident character has automatically checked in can be purchased without the user having to check in to that portal. However, the purchase of souvenir items is not limited to this. The resident character may check in to inform the user of what souvenir items are available at that portal, and the souvenir items may not be purchased unless the user actually checks in to that portal.

[0106] (4) About objects placed in city-building games In the above embodiment, an example has been described in which the time required for an object to be placed in the city building game is predetermined for each object, such as the time required for it to go from a construction state to a completed state, the time required for it to be able to exert an effect, and the time required for it to be leveled up. However, the predetermined time for improving the object's advantage may be shortened by consuming virtual currency purchased by charging, or may be immediately elapsed (e.g., immediately completed, etc.) by consuming virtual currency. In addition, an example has been described in which the magnitude of the exerted effect (e.g., production volume, etc.) is predetermined according to the level of the object, but this is not limited thereto, and an effect greater than the predetermined effect may be exerted by consuming virtual currency purchased by charging. This allows the user's city to grow and develop quickly by charging, and as a result, the resident characters can be associated with each other quickly.

[0107] In addition, although an example has been described in which owned objects can be placed on the game field regardless of the number of objects in the construction state, the present invention is not limited to this. When the number of objects in the construction state reaches a predetermined number, it may be possible to prevent new objects from being placed. In this case, even when the number of objects in the construction state reaches a predetermined number, new objects may be placed by consuming virtual currency purchased through a charge. This allows the user's town to grow and develop quickly by charging, and as a result, resident characters can be associated with the town quickly.

[0108] In the above embodiment, an example has been described in which it is not possible to specify how far a user needs to move during a position information game to pass the time required to improve the degree of advantage of an object placed in the game field. However, it may be possible to specify how far a user needs to move during a position information game to pass the time required to improve the degree of advantage of an object placed in the game field. If the moving distance corresponding to the time required to improve the degree of advantage of an object designated by the user is X km, for example, a circle image with a radius of X km based on the current position may be displayed superimposed on a map image. This allows the user to confirm the moving range required to improve the degree of advantage of the designated object, and therefore to clearly set a destination.

[0109] In the city building game of the above embodiment, an example has been described in which the in-game time is used as an index for whether or not to improve the degree of advantage of the placed object. However, the index for whether or not to improve the degree of advantage of the placed object is not limited to the in-game time, and may be any other predetermined parameter that is updated according to the user's moving distance, or may be the user's moving distance itself.

[0110] <Additional Notes> The matters described in the above embodiments will be supplemented below.

[0111] (Appendix 1): According to one aspect of an embodiment of the present disclosure, there is provided a game program executed on an information terminal device having a processor, a memory, and a display unit, the game program causing the processor to execute a step of executing a first game part in which an object whose state can be changed is placed in a virtual space and the state of the object is changed to a state advantageous to the user (FIG. 5), and a step of determining a distance traveled in real space by a user who possesses the information terminal device (step S02 in FIG. 4), the step of executing the first game part including a step of progressing in-game time in the first game part based on the distance traveled (step S20), and a step of changing the state of the object to a state advantageous to the user based on the progression of the in-game time (steps S21, S22).

[0112] (Appendix 2): In (Supplementary Note 1), the changing step changes the state of the object to a state advantageous to the user as the in-game time progresses for a predetermined period of time.

[0113] (Appendix 3): In (Supplementary Note 1) or (Supplementary Note 2), the game program causes the processor to execute a step (steps S04 to S09 in FIG. 4) of executing a second game part, which is different from the first game part and in which game control (granting a benefit) is performed when a permission condition is satisfied (the user moves so that a portal enters a circle image C) according to a position in real space of a user who possesses the information terminal device, the step of executing the first game part includes a step (step S25) of associating a game character (resident character) with the virtual space, and the step of executing the second game part includes a step of displaying, on the display unit, an image within a partial area of ​​a map image corresponding to real space and in which a plurality of portals are arranged (a step of displaying FIG. 2(A) or the like); The game control includes a step of identifying a game character to accompany the user's movement in the second game part from among the game characters associated with the virtual space in the first game part (step S01), the permission condition being established by accepting an input operation on a portal that is located in an area within a predetermined range from the user's position in the real space among the portals displayed on the display unit, and the game control that is performed by the permission condition being established in the second game part includes control of granting a benefit corresponding to an operation target portal among the portals that has accepted the input operation (steps S04, S05), and control of moving the game character that accompanies the movement of the information terminal device to a portal other than the operation target portal and granting a benefit corresponding to the portal (steps S08, S09).

[0114] (Appendix 4): In (Supplementary Note 3), the reward includes an in-game currency required to place an object in the first game part.

[0115] (Appendix 5): In (Supplementary Note 3) or (Supplementary Note 4), the step of executing the second game part includes a step (step S07) of determining a portal through which the game character is to be moved from among portals located within a specific range that is wider than the predetermined range from the user's position in real space, regardless of an input operation from the user.

[0116] (Appendix 6): In (Appendix 5), the step of associating the game characters associates a game character having characteristics according to the type of object placed (step S25), and the step of determining determines a portal to be moved based on the characteristics of the game character to be moved (step S07).

[0117] (Appendix 7): In any one of (Supplementary Note 1) to (Supplementary Note 6), the game program causes the processor to execute a step (steps S04 to S09 in FIG. 4) of executing a second game part, which is different from the first game part and in which game control (granting a benefit) is performed when a permission condition is satisfied according to a position in real space of a user who possesses the information terminal device (the user moves so that a portal enters a circle image C), the step of executing the second game part includes a step of displaying on the display unit an image of a part of a map image corresponding to real space and in which a plurality of portals are arranged (a step of displaying FIG. 2(A) or the like), the permission condition is satisfied by accepting an input operation for a portal that is displayed on the display unit and is arranged in an area within a predetermined range from the position of the user in real space, and the moving distance specified in the step of specifying is a distance from the position of the user in real space when the second game part started to the portal for which the input operation was accepted.

[0118] (Appendix 8): In any of (Appendix 1) to (Appendix 6), the game program causes the processor to execute a step (steps S04 to S09 in FIG. 4) of executing a second game part, which is different from the first game part and in which game control (granting a benefit) is performed when a permission condition is satisfied (the user moves so that a portal enters circle image C) depending on the position in real space of the user who possesses the information terminal device, and the movement distance specified in the specifying step is a distance specified from the user's position in real space regardless of whether or not the second game part is in progress.

[0119] (Appendix 9): In any one of (Supplementary Note 1) to (Supplementary Note 8), the game program causes the processor to execute a step (steps S04 to S09 in FIG. 4) of executing a second game part, which is different from the first game part and in which game control (granting a benefit) is performed when a permission condition is satisfied (the user moves so that a portal enters a circle image C) according to a position in real space of a user who possesses the information terminal device, the step of executing the first game part includes a step (step S25) of associating a game character with the virtual space, and an execution condition (release condition) for executing a special performance (episode) associated with the game character is set for the game character (FIG. 3(B)), and executing the second game part The step of performing the second game part includes a step of displaying on the display unit an image of a portion of a map image corresponding to real space in which a plurality of portals are located (a step of displaying FIG. 2(A), etc.), and the permission condition is established by accepting an input operation on one of the portals displayed on the display unit that is located in an area within a predetermined range from the user's position in real space. The step of executing the second game part includes a step (step S05) of granting, as the game control, an item (souvenir item) corresponding to the portal from among a plurality of types of items when the permission condition is established by accepting an input operation on the portal, and the execution condition can be established by the grant of a specific item (see FIG. 3(B)).

[0120] (Appendix 10): In (Supplementary Note 9), the step of associating the game character associates a game character having characteristics according to the type of object placed (step S25), and the item that enables the execution condition to be satisfied is determined according to the characteristics of the game character (see FIG. 3(B)).

[0121] (Appendix 11): In (Supplementary Note 9) or (Supplementary Note 10), the step of granting the item includes granting an item corresponding to the portal for which the permission condition has been met by consuming in-game currency required to place an object in the first game part (steps S05, S09).

[0122] (Appendix 12): According to one aspect of an embodiment disclosed herein, a gaming method is executed by an information terminal device having a processor, a memory, and a display unit, the method including the steps of: executing a first game part in which an object whose state can be changed is placed in a virtual space and the state of the object is changed to a state advantageous to the user (FIG. 5); and determining a distance traveled in real space by a user who possesses the information terminal device (step S02 in FIG. 4), the step of executing the first game part including a step of progressing in-game time in the first game part based on the distance traveled (step S20); and a step of changing the state of the object to a state advantageous to the user based on the progression of the in-game time (steps S21, S22).

[0123] (Appendix 13): According to one aspect of an embodiment of the present disclosure, an information terminal device having a processor, a memory, and a display unit executes a step of executing a first game part in which an object whose state can be changed is placed in a virtual space and the state of the object is changed to a state advantageous to the user (FIG. 5), and a step of determining a distance traveled in real space by a user possessing the information terminal device (step S02 in FIG. 4), wherein the step of executing the first game part includes a step of progressing in-game time in the first game part based on the distance traveled (step S20), and a step of changing the state of the object to a state advantageous to the user based on the progression of the in-game time (steps S21, S22).

[0124] [Software implementation example] The control in each of the user terminal 100 and the server 200 may be realized by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like, or may be realized by software.

[0125] In the latter case, the user terminal 100 and the server 200 are provided with a computer that executes instructions of a program, which is software that realizes each function. The computer includes, for example, one or more processors, and a computer-readable recording medium that stores the program. The computer achieves the object of the present invention by having the processor read the program from the recording medium and execute it. The processor may be, for example, a CPU (Central Processing Unit). The recording medium may be a "non-transient tangible medium," such as a ROM (Read Only Memory), tape, disk, card, semiconductor memory, programmable logic circuit, or the like. The computer may further include a RAM (Random Access Memory) that expands the program. The program may be supplied to the computer via any transmission medium (such as a communication network or broadcast waves) that can transmit the program. One aspect of the present invention may also be realized in the form of a data signal embedded in a carrier wave, in which the program is embodied by electronic transmission.

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

[0127] 1 game system, 2 network, 10,20 processor, 11,21 memory, 12,22 storage, 15 touch screen, 151 input unit, 152 display unit, 17 camera, 18 distance measuring sensor, 1010 object, 1020 controller, 1030 storage medium, 100 user terminal, 200 server.

Claims

1. On the computer, A program that, when a user playing a position-based game reaches a specific position, moves a character associated with the user to a specific object located in a virtual space according to characteristics of the character.

2. 2. The program according to claim 1, wherein when an event related to a purchase occurs at a destination where the character has moved to the specific object, a notification is sent to the user asking whether or not the purchase is possible.

3. 2. The program according to claim 1, wherein when the character moves to the specific object and a predetermined condition is satisfied, an event related to the character is opened.

4. A system comprising: a means for, when a user playing a position-based game reaches a specific position, moving a character associated with the user to a specific object located in a virtual space according to characteristics of the character.

Images