JP7654741B2 - Programs and systems - Google Patents

Description

The present invention relates to a program and a system .

Conventionally, there are known city-building games in which players progress through a cycle in which they place objects such as buildings 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 the value.

JP 2019-69081 A

But traditional games leave room for improvement .

The present invention has been devised in view of the above circumstances, and an object of the present invention is to provide a program and a system that enable a user to efficiently acquire benefits .

According to an aspect of an embodiment disclosed herein , there is provided a program comprising:
A character moves together with a user playing a position information game, and even if the user does not select an event associated with a predetermined position of the position information game, the character automatically advances the event instead, and the user acquires a privilege of the event .

According to one aspect of an embodiment disclosed herein, a system includes a means for moving a character together with a user playing a location-based game, a means for the character to automatically progress through an event associated with a specific location in the location-based game without the user having to select the event, and a means for allowing the user to acquire a reward for the event .

According to the present invention, benefits can be acquired efficiently .

FIG. 2 is a diagram illustrating a hardware configuration of the game system. (A) and (D) are figures showing an example of a display screen displayed on a touch screen during a location-based game, (B) and (E) are figures showing an example of a display screen displayed on a touch screen during a city-building game, and (C) is a figure 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. 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. FIG. 11 is a diagram for explaining a flowchart of a location information game related process. FIG. 13 is a diagram for explaining a flowchart of processing related to a city-building game.

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 will be given the same reference numerals, and redundant description will not be repeated.

<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.

The server 200 (computer, information processing device) may be a general-purpose computer such as a workstation or a personal computer. The server 200 comprises 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.

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 body can be connected instead of or in addition to the touch screen 15.

As shown in FIG. 1, the user terminal 100 may be configured to be able to communicate with one or more controllers 1020. The controller 1020 establishes communication with the user terminal 100 according to 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.

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

For example, when starting a game, the user terminal 100 desirably has the user using the controller 1020 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.

When the user terminal 100 communicates with multiple controllers 1020, each user can hold a controller 1020 and realize a multi-play on the single user terminal 100 without communicating with other devices such as the server 200 via the network 2. In addition, the user terminals 100 can realize a multi-play 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 realizing the above-mentioned multi-play locally using a single user terminal 100, the user terminal 100 may further include at least some of the various functions of the server 200, which will be described later. In addition, when realizing the above-mentioned multi-play locally using multiple user terminals 100, the multiple user terminals 100 may have various functions of the server 200, which will be described later, distributed among them.

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

The controller 1020 may be configured to be detachable from the user terminal 100. In this case, a connection part for the controller 1020 may be provided on at least one of the faces of the housing of the user terminal 100. When the user terminal 100 and the controller 1020 are connected by a wire via the connection part, the user terminal 100 and the controller 1020 transmit and receive signals via the wire.

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

The user terminal 100 may store 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.

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

For example, when the operation unit is composed of at least one of the camera 17 and the distance 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 or a marker of a predetermined shape 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 and accepts a gesture (a series of movements of the user's hand) detected based on the captured image as the user's input operation. Note that the captured image may be a still image or a video.

Alternatively, if the operation unit is configured with a 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 a user input operation. Alternatively, if the operation unit is configured with a communication IF 13, the user terminal 100 identifies and accepts a signal (e.g., an output value) transmitted from the controller 1020 as a user input operation. Alternatively, if the operation unit is configured with an 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 a user input operation.

<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).

Processor 10 reads the program from storage 12, which will be described later, and expands it in memory 11, which will be described later. Processor 20 reads the program from storage 22, which will be described later, and expands it in memory 21, which will be described later. Processor 10 and processor 20 execute the expanded programs.

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

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, as an 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 multiple user terminals 100. Furthermore, 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 multiple user terminals 100.

Storages 12 and 22 are auxiliary storage devices. Storages 12 and 22 are configured with storage devices such as flash memory or HDDs (Hard Disk Drives). Storage 12 and storage 22 store various data related to the game.

The communication IF 13 controls the transmission and reception of various data in the user terminal 100. The communication IF 23 controls the 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 line network, and communication using short-range wireless communication, etc.

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

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 touchpad. The display unit 152 is, for example, configured by a liquid crystal display or an organic EL (Electro-Luminescence) display.

The input unit 151 has a function of detecting the 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 be provided with a touch sensing unit (not shown). The touch sensing unit may be of any type, such as a capacitive type or a resistive film type.

Although not shown, the user terminal 100 may have one or more sensors for identifying the holding orientation of the user terminal 100. The sensor may be, for example, an acceleration sensor or an angular velocity sensor. If the user terminal 100 has a sensor, the processor 10 may identify the holding orientation of the user terminal 100 from the output of the sensor and perform processing according to the holding orientation. For example, when the user terminal 100 is held in portrait orientation, the processor 10 may perform a portrait screen display in which a vertically elongated image is displayed on the display unit 152. On the other hand, when the user terminal 100 is held in landscape orientation, the processor 10 may perform a landscape screen display in which a horizontally elongated image is displayed on the display unit. In this way, the processor 10 may be able to switch between portrait screen display and landscape screen display according to the holding orientation of the user terminal 100.

The camera 17 includes an image sensor and generates a captured image by converting the light incident through the lens into an electrical signal.

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

Here, an example will be further described in which the user terminal 100 uses the camera 17 and the distance measurement sensor 18 to detect an object 1010 in the vicinity of the user terminal 100, and receives the detection result as a user input operation. The camera 17 and the distance measurement sensor 18 may be provided, for example, on the side 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 can be used as the camera 17. In this case, a lighting device that irradiates infrared rays and a filter that blocks visible light, etc. may be provided in the camera 17. This can further improve the accuracy of object detection based on the image captured by the camera 17, regardless of whether it is outdoors or indoors.

The processor 10 may perform one or more of the following processes (1) to (5) on the image captured by the camera 17. (1) The processor 10 performs image recognition processing on the image captured by the camera 17 to determine whether or not the captured image includes the user's hand. The processor 10 may use a technique such as pattern matching as an analysis technique to be adopted in the above-mentioned image recognition processing. (2) The processor 10 also detects a user's gesture from the shape of the user's hand. The processor 10, for example, determines the number of the user's fingers (the number of fingers that are extended) 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, if the number of fingers is five, the processor 10 determines that the user has made a "paper" gesture. If 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 performs image recognition processing on the image captured by the camera 17 to detect whether the user's fingers are in a state where only the index finger is raised, or whether the user's fingers are moving in a flicking manner. (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) When it is determined that the distance between the user terminal 100 and the user's hand is changing while the user's hand is detected based on the image recognition result of the image captured by the camera 17, the processor 10 recognizes that the user is waving his/her hand in the capturing direction of the camera 17. When an object is sometimes detected and sometimes not detected by the distance measuring sensor 18, which has a higher directivity than the capturing range of the camera 17, the processor 10 recognizes that the user is waving his/her hand in a direction perpendicular to the capturing direction of the camera.

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 the pointer on the touch screen 15 in response to the movement of the user's hand and detects the user's "rock" gesture. 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 his/her 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.

＜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 benefit corresponding to the portal (e.g., in-game currency, a souvenir item corresponding to the portal, etc.).

Meanwhile, city-building games involve placing objects such as buildings in a virtual space in response to input operations from the user, evolving those objects (e.g., completing buildings, generating value, leveling up, etc.) as time passes in the game, and associating resident characters within the virtual space in response to the placement of objects, thereby developing and growing the user's city.

Location-based games and city-building games are different types of games. However, the in-game time for evolving buildings and the like in city-building games passes (progresses) according to the distance traveled by the user in the location-based game. In this embodiment, for example, 10 minutes of in-game time can pass when the user travels 1 km in real space, but this is not limiting, and 1 minute of in-game time can pass when the user travels 100 m.

In addition, rewards (in-game currency) acquired in the location-based game can be used to purchase and place new 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.

For this reason, for example, a game cycle can be provided to the user in which: acquire a bonus in the location-based game → place objects such as buildings in the city-building game → move them in the location-based game → evolve the buildings (develop the city) and associate them with resident characters in the city-building game → double the bonus acquired by taking the resident character to a portal check-in in the location-based game → further evolve the buildings (further develop the city) in the city-building game... The location-based game and city-building game are each described in detail below.

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 of the user terminal 100 (e.g., address information, latitude and longitude information, etc.), and displays a map of the surroundings of the current location of the user terminal 100 (the user who owns it) 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 acquires portal information (information for identifying the location of the portal, the type of portal, etc.) related to portals located in the vicinity of the user terminal 100, and transmits the portal information to the user terminal 100 together with map data of the surroundings of the user terminal 100.

The user terminal 100 displays a map image based on the map data on the touch screen 15, and superimposes a portal at a predetermined position on the map image based on the portal information received together with the map data. Specifically, the touch screen 15 displays a map image of a portion of the map image based on the map data, the area being centered on the user's position in real space. The portal is displayed at a position specified by the portal information in a manner that makes it possible to specify its type. In addition, a current position image indicating the user's current position in real space and a circle image indicating a predetermined range (e.g., a radius of 200 m) from the current position are superimposed on the map image on the touch screen 15.

Figure 2 (A) is a diagram showing an example of a display screen displayed on the touch screen 15 during a location-based game. Figure 2 (A) shows an example in which the user owning 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 location image U, and a circle image C are displayed superimposed on the map image 201.

Each of the portals P1 to P4 is displayed with an image indicating the type of the portal. Portals that can be arranged on the map image include various types of portals, such as parks, coffee shops, supermarkets, department stores, ramen shops, temples, schools, amusement parks, factories, banks, stadiums, mountains, oceans, rivers, fields, apartment buildings, research laboratories, power plants, and police stations. As an image indicating the type of 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 displays a photo image of a tent and a hammock suggesting that it is a type belonging to leisure, and the portal P4 displays a photo image of a temple suggesting that it is a type belonging to temples. In this embodiment, an example in which a photo image or the like is displayed in correspondence with the portal will be described, but this is not limiting, and a photo image or the like corresponding to the type of portal that is the target of the tap operation may be displayed by tapping the portal.

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

When a user checks in to a portal, the user can acquire a benefit according to the type of portal. The benefit may be, for example, an amount of in-game currency according to the type of portal, or a souvenir item according to the type of portal checked in. The souvenir item may be, 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 real space and checking in to a portal located on a map image in this way. Information for identifying the acquired benefit is stored in memory 11.

Furthermore, when the user moves, the user terminal 100 again transmits current location information to the server 200 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.

In addition, in a location-based game, memory 11 stores travel distance information that can identify the distance traveled by the user in real space to reach the desired portal. In a location-based game, travel at a predetermined speed (e.g., 100 m/min) or less, such as walking or jogging, is counted as the user's travel, and travel at speeds exceeding the predetermined speed (e.g., by car or train) is excluded from the count.

Next, the city-building game will be described. In the city-building game, the user builds a city by placing objects owned by the user in the 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.

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

The user can place a desired object at a desired location in the game field by dragging the object shown in the second area 203 and dropping it at the desired location 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 a new owned object 204 is about to be placed.

There are multiple types of objects corresponding to buildings that may exist in real space. For example, there are various types of objects, 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.

When an object is placed on the game field, it first goes into construction mode, and the in-game time required to complete it is determined for each type of object. The remaining in-game time required to complete the object is displayed superimposed on the object when, for example, a tap is performed on the object in construction mode.

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 amount of in-game time (e.g., the time required for production to be completed) has elapsed. Therefore, as the object is completed, the user's advantage in town building increases. The time required to exert an effect and the effect that is 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 created 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 determined 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 more balanced the four items are, the richer the town is evaluated to be.

In addition, a level of an object in a completed state is set. The level of the object affects, for example, the magnitude of the effect it exerts and the time required to exert the effect, and the higher the level of the object, the greater the effect it exerts and the shorter the time required to exert it. This increases the degree of advantage for the user in town development. For example, the in-game time required to reach the next level is set for an object in a completed state. 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 food, resources, funds, and development in the entire town, and a value indicating the wealth of the town are stored in memory 11.

As mentioned above, the in-game time that affects the completion, effect, and level-up of objects passes 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 by checking in to a portal in the location-based game.

2C 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. 2C, 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, in-game time from placement to completion, and required travel distance are also determined for coffee shop objects and factory objects. In addition, each object is determined to have an in-game time required to exert an effect once after completion, and an in-game time required to reach the next level. This allows the user to play a location information game to encourage movement 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.

Figure 2 (D) illustrates an example in which a user who owns a user terminal 100 walks from the area around Ebisu Station (for example, Figure 2 (A)) to a location 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 located 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 portal. The user can also acquire a souvenir item according to the type of portal by spending the in-game currency owned by the user.

Furthermore, in location-based games, distance traveled information is updated as the user moves, allowing the in-game time in the city-building game to progress. As a result, in the city-building game, in-game currency is consumed to purchase and place objects, and in-game time progresses based on distance traveled information to complete the objects, exert their effects, level up, etc., allowing the user's city to develop and grow, as exemplified in Figure 2(E). Figure 2(E) shows how city T1 shown in Figure 2(B) develops and grows into a larger city by further placing many objects in it.

In addition, in city-building games, resident characters are associated with the 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, multiple 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, a higher proportion of characters having a characteristic of liking art such as paintings are associated than when a museum object is not placed. Also, when a ramen shop object is placed, a higher proportion of characters having a characteristic of liking ramen are associated than when a ramen shop object is not placed.

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), the balance of food, resources, funds, and development is shown in a pie chart in the second area 203, and the number of resident characters associated with the user's town is shown in the center of the pie chart. The example in FIG. 2(E) shows that food is 40%, resources are 30%, funds are 20%, and development is 10%, and that there are seven resident characters. Information that enables identification of the resident characters and characteristics associated with the user's town is stored in memory 11.

Resident characters associated with a town can be taken out as companions to the user in the location-based game. The resident characters and number of characters to be taken out as companions are specified by the user's selection when starting the location-based game.

Figure 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 their own characteristics. As shown in Figure 3 (B), resident character K1 has a characteristic of liking B-grade gourmet food, resident character K2 has a characteristic of enjoying visiting coffee shops, and resident character K3 has a characteristic of exploring history. Although not shown, resident characters K4 to K7 have similar characteristics.

As shown in FIG. 3(A), around portal P1 are located portal P2 for ramen, which has something in common with B-grade gourmet food, portal P3 for coffee, which has something in common with coffee shop hopping, and portal P4 for temples, which has something in common with historical exploration. In this case, as shown in FIG. 3(A), of the resident characters K1 to K7 that have been taken along as companions, resident character K1 moves to portal P2, resident character K2 moves to portal P3, and resident character K3 moves to portal P4, and they each check in to the portal with which they have something in common.

In this way, when a user checks in to a portal, the resident character identifies a type of portal other than the one 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 wider 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 portals P2 to P4 without having to check in to those portals themselves.

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

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 that corresponds 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.

As shown in FIG. 3B, resident character K1 is associated with EP1 and EP2 as episodes, and a release condition is set by giving souvenir items 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 resident character K1 likes XX restaurant. Resident character K2 is associated with EP3 and EP4 as episodes, and a release condition is set by giving souvenir items 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 be used to set the release condition of the episode. Similarly, unique episodes and release conditions are set for other resident characters. The titles of the episodes 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 the location-based game. In addition, when the episode titles and unlocking conditions are displayed in a list, the location of the portal where the souvenir item that fulfills the unlocking condition can be obtained and the distance to the portal are also displayed. This allows the user to confirm the portal they should aim for in order to unlock the episode of the desired resident character, giving them an incentive to move to that portal.

Next, the processing content 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 processing included in the processing for playing the location information game. The location information game related processing is executed by the user terminal 100, but is not limited to this, and some processing may be executed by the server 200 and the processing results may be transmitted to the user terminal 100.

In step S01, when starting the location-based game, the user decides which resident character to take along as a companion. Specifically, the user refers to the titles and release conditions of the resident character's episodes that are displayed in a list when starting the location-based game, and selects the resident character to take along as a companion while checking the souvenir items that will satisfy the release conditions and the distance to the portal, etc.

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

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 distance traveled is updated in accordance with the user's movement. During this time, the map image and portals on the touch screen 15 are updated in accordance with the user's movement.

On the other hand, when it is determined that the user has checked in, in step S04, the user is granted in-game currency corresponding to the portal that the user has checked in to. 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.

In step S06, it is determined whether the resident character is accompanied by someone else. If it is not determined that the resident character is accompanied by someone else, the process proceeds to step S10. On the other hand, if it is determined that the resident character is accompanied by someone else, 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 which the resident character will check in is determined based on the characteristics of the resident character taken as a companion and the commonality with the types of portals located around the portal where the user checked in. Portals that can be used as check-in destinations are not limited to portals within circle image C, but include portals located in a wider area than the circle image C. For resident characters for which a check-in destination has been determined, a display is displayed indicating that the resident character will move to the determined portal and check in.

In step S08, 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 souvenir items available at that portal. By indicating that the user is OK with the 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.

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

Figure 5 is a diagram for explaining a flowchart of the city-building game-related processing included in the processing for playing the city-building game. The city-building game-related processing is executed by the user terminal 100, but is not limited to this, and some processing may be executed by the server 200 and the processing results 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 distance traveled based on the travel distance information updated in the location information game. Specifically, 10 minutes of in-game time is elapsed for every 1 km.

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 in-game time that has elapsed. The time to improve the degree of advantage of the object includes the time required for it to change from a construction state to a completed state, the time required for it to be able to exert its effect, the time required for it to level up, and the like. 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 moves directly to step S26.

On the other hand, when it is determined that the time to improve the degree of advantage of the object has elapsed, the degree of advantage of the object being evaluated is improved in step S22. Specifically, if the object is in a construction state, it is updated to a completed state, its effects are activated, or its level is increased.

In step S23, the wealth of the town is determined based on the total value and ratio of food, resources, funds, and development by objects placed in the user's town. In step S24, it is determined whether or not to associate a new resident character with the town, depending on 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 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 characteristics according to the type of object placed in the town is associated. As described above, when a museum object is placed, a higher proportion of characters having a characteristic of liking art such as paintings are associated than when a museum object is not placed.

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

<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.

In addition, the degree of advantage of an object increases as a predetermined time for each object passes, as shown in steps S21 and S22 of FIG. 5. This allows the user to be prompted to make a move to advance the predetermined time.

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 resident character can be taken out as a companion and moved around, and the user can check in to a portal to obtain a reward corresponding to the portal, and a reward can be obtained by automatically moving the resident character taken out as a companion to another portal and checking it in. This allows the user to obtain more rewards more efficiently, the more resident characters there are. As a result, the user can be motivated to grow and develop the city in order to associate more resident characters to be taken out as companions with movements in the location-based game.

The check-in destination of a resident character is determined based on the characteristics of the resident character from portals located within a range wider than the circle image C, as shown in step S07 of FIG. 4. This allows the user to check in to portals that are not located within the circle image C without actually moving. As a result, it is possible to create an incentive to associate more resident characters. The characteristics of the resident character associated with a town are determined according to the type of object that is placed, as shown in step S25 of FIG. 5. The number of resident characters is determined according to the wealth of the town, as determined from the objects that are placed, as shown in steps S23 and S24 of FIG. 5. This provides an added fun factor in terms of what types of objects to place in a town-building game.

The rewards obtained by checking in to a portal 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 in turn encourages the user to move around in the location-based game and motivates the user to check in to portals.

As shown in FIG. 3(B), each resident character is assigned a unique episode and a release condition for unlocking that episode. Furthermore, the release condition is met by granting (consuming) a specific souvenir item to the resident character that corresponds to the resident character's characteristics. This can motivate the user to move toward a portal where the souvenir item for unlocking the resident character's episode can be acquired. Furthermore, the souvenir item can be acquired by checking in to a portal and then consuming in-game currency. This can further encourage checking in to portals to acquire in-game currency.

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

(1) About the travel distance and the in-game time The example in which the travel distance information updated in step S02 of FIG. 4 in the above embodiment is reflected in the in-game time of the city-building game in step S20 of FIG. 5 regardless of whether or not the user has checked in to the portal has been described. 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 the portal, and may not be reflected in the in-game time even if the user has moved at a stage where the user has not checked in to the portal. This can further encourage the user to check in to the 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 as a destination when starting the position information game, and check in to the portal, so that the updated travel distance information is reflected in the in-game time.

In the above embodiment, an example was described in which the travel distance information is updated during a location-based game, and is not updated when the location-based game is not being played. However, the travel distance information may be updated according to the user's movement in real space, regardless of whether the location-based game is being played, even during a city-building game, for example, and reflected in the in-game time. This allows the in-game time to progress independently according to the distance traveled by the user while the screen during the city-building game is displayed.

In addition, the travel distance information may be updated in response 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 location information in memory 11, when the user starts (logs in) the program for executing the game, the program for the game may read out the location information stored (accumulated) in memory 11, and from that location information, determine the distance traveled by the user while the program for the game was not running, and update the travel distance information in response to that distance traveled and reflect it in the in-game time. Note that the update of the travel distance information when the program for the game is running is as described above.

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 in response to the user's movement in real space, for example, even during a 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 in response to the user's movement in the location-based game, information that identifies the type of object and the improved content may be displayed in a specified area in the location-based game (for example, a pop-up display in the header area). This can encourage the user to transition to the city-building game.

(2) Regarding 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 along as a companion. However, the resident character to be taken along as a companion may be determined by lottery. In addition, when a portal to be a destination is set when starting a location-based 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 with a high probability) as a resident character to be taken along as a companion, depending on the types of these portals.

In the above embodiment, an example was 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 that has 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 so that the user can obtain a benefit. This provides the user with the fun of deciding which route to take to get to the portal.

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

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, it is also possible to set it so that when the value of a certain parameter related to the resident character is equal to or greater than a certain value, the resident character can be taken out as a companion, and when it is less than the certain 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, so that when the stamina parameter is equal to or greater than a certain value, the resident character can be taken out as a companion, and when it is less than the certain value, the resident character cannot be taken out as a companion. Also, when the stamina parameter becomes 0 during 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 interest to the scene in which the resident character to be the companion is selected.

In addition, the specified parameters related to the resident characters may be restored according to the distance traveled by the user when not accompanying the user as a companion, or may be restored by providing a souvenir item for restoring stamina, or even may be restored according to the amount of virtual currency purchased through a fee.

(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 may be made to be able to be purchased with virtual currency purchased through a charge.

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

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 cannot be purchased unless the user actually checks in to that portal.

(4) About objects arranged in a city building game In the above embodiment, an example was described in which the time required for improving the degree of advantage of an object, such as the time required for the object to go from a construction state to a completed state, the time required for the object to be able to exert an effect, and the time required for the object to be leveled up, is predetermined for each object. However, the predetermined time for improving the degree of advantage of an object 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 was described in which the magnitude of the effect exerted (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.

Although an example has been described in which owned objects can be placed on the game field regardless of the number of objects in a building state, this is not limiting, and it may be possible to prevent new objects from being placed when the number of objects in a building state reaches a predetermined number. In this case, even when the number of objects in a building 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 it quickly.

In the above embodiment, an example was described in which it was not possible to specify how far a user needs to move during a location-based 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 location-based game to pass the time required to improve the degree of advantage of an object placed in the game field. If the travel distance corresponding to the time required to improve the degree of advantage of a user-specified object 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 range of travel required to improve the degree of advantage of the specified object, allowing the user to clearly set a destination.

In the city-building game of the above embodiment, an example was described in which in-game time is used as an indicator of whether or not the degree of advantage of a placed object is improved. However, the indicator of whether or not the degree of advantage of a placed object is improved is not limited to in-game time, and may be another predetermined parameter that is updated according to the user's travel distance, or may be the user's travel distance itself.

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

(Note 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 possessing 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).

(Note 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.

(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) in accordance with 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 second 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 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 located portals that has accepted an 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).

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

(Note 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 will be moved from among portals located in an area within a specific range wider than the predetermined range from the user's position in real space, regardless of an input operation from the user.

(Note 6):
In (Supplementary Note 5), the step of associating the game characters associates a game character having characteristics according to the type of object being 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).

(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 in accordance with 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 is started to the portal for which the input operation is accepted.

(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 position in real space of the user regardless of whether or not the second game part is in progress.

(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 executing 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) or the like), 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, and 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)).

(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)).

(Appendix 11):
In (Supplementary Note 9) or (Supplementary Note 10), the step of granting the item grants 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).

(Appendix 12):
According to one aspect of an embodiment of the present disclosure, 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).

(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).

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

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

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

REFERENCE SIGNS LIST 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 measurement sensor 1010 Object 1020 Controller 1030 Storage medium 100 User terminal 200 Server.

Claims (7)

The processor:
Move the character together with the user playing the location-based game,
Even if the user does not select an event associated with a predetermined position of the position information game, the character moves to the predetermined position instead of the user and automatically progresses the event at the predetermined position;
A program that allows a user to acquire a benefit of the event. The program according to claim 1, wherein the events that the character can progress through are events that exist within a predetermined range. The program according to claim 1 or 2, wherein the condition for the character to proceed on behalf of the user is when a parameter is a predetermined value. The program according to any one of claims 1 to 3, in which the number of characters that can be moved can be changed depending on the progress of the game. The processor:
The program according to any one of claims 1 to 4, further comprising: moving and displaying a character that progresses the event to a position where the event is present, and then automatically progressing the event. The processor:
6. The program according to claim 1, wherein the program enables the user to move a character together with the user when a predetermined condition is met as the game progresses. A means for moving a character together with a user playing a location information game;
a means for causing the character to move to a predetermined position on behalf of the user and automatically progress the event at the predetermined position even if the user does not select an event associated with the predetermined position of the position information game;
and a means for allowing a user to acquire a benefit of the event.

Images