JP7366584B2 - program - Google Patents

Description

The present invention relates to a program .

Conventionally, objects such as buildings are placed in the game field, and as time passes, the object is completed, value (coins, items, etc.) is generated in the object, and the value is used to create new objects. There are known city-building games in which the game progresses through a cycle of arranging objects.

JP2019-69081A

However, in conventional games, after an object is placed, time in the game automatically passes without the user taking any action, and the object is completed or value is generated. For this reason, there is a risk that the sense of participation in the game may decline, and there is room for improvement.

The present invention was devised in view of such circumstances, and its purpose is to provide a program that can prevent a decline in the sense of participation .

According to an aspect of an embodiment disclosed in the present disclosure, there is provided a program executed on a computer , the program places an object whose state can be changed in a virtual space, and changes the state of the object to be advantageous to a user. means for executing the first part of changing the state to a state of and means for changing the state of the object to a state advantageous to the user based on the progress of the intra - part time in the first part .

According to the present invention, it is possible to prevent a decline in the sense of participation .

1 is a diagram showing a hardware configuration of a game system. (A) and (D) are diagrams showing examples of display screens displayed on a touch screen during a location information game, and (B) and (E) are diagrams showing display screens displayed on a touch screen during a city building game. It is a diagram showing an example, and (C) is an example of the purchase price of an object, the in-game time required from placing it on the game field until completion, and the travel distance required to elapse the in-game time. FIG. (A) shows a display example when a user checks in to the portal with a resident character taken out as an companion, and (B) is a diagram showing characteristics, episodes, and release conditions of the resident character. FIG. 3 is a diagram for explaining a flowchart of location information game related processing. FIG. 3 is a diagram for explaining a flowchart of city-building game-related processing.

A game system according to the present disclosure is a system for providing a game to a plurality of users. The game system will be described below with reference to the drawings. It should be noted that the present invention is not limited to these examples, but is indicated by the scope of the claims, and it is intended that all changes within the meaning and range equivalent to the scope of the claims are included in the present invention. Ru. In the following description, the same elements are given the same reference numerals in the description of the drawings, and overlapping description will not be repeated.

<Hardware configuration of game system 1>
FIG. 1 is a diagram showing the hardware configuration of the game system 1. As shown in FIG. As illustrated, the game system 1 includes a plurality of user terminals 100 and a server 200. Each user terminal 100 is connected to a server 200 via a network 2. The network 2 includes the Internet and various mobile communication systems constructed by wireless base stations (not shown). Examples of this mobile communication system include so-called 3G, 4G mobile communication systems, LTE (Long Term Evolution), and wireless networks (for example, Wi-Fi (registered trademark)) that can be connected to the Internet through predetermined access points. It will be done.

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 included in 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. User terminal 100 may be a game device suitable for playing games. As illustrated, 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 section), a camera 17, and a distance measurement sensor 18. Equipped with. These components included in the user terminal 100 are electrically connected to each other by a communication bus. Note that, instead of or in addition to the touch screen 15, 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.

Further, 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, for example, according to a communication standard such as Bluetooth (registered trademark). The controller 1020 may have one or more buttons or the like, and transmits an output value to the user terminal 100 based on a user's input operation on the button or the like. Further, the controller 1020 may include 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.

Note that instead of or in addition to the user terminal 100 including the camera 17 and the distance measurement sensor 18, the controller 1020 may include the camera 17 and the distance measurement sensor 18.

It is desirable that the user terminal 100 allows the user using the controller 1020 to input user identification information such as the user's name or login ID via the controller 1020, for example, when starting the game. This makes it possible for the user terminal 100 to link the controller 1020 and the user, and identify which user the received output value belongs to based on the source (controller 1020) of the received output value. be able to.

When the user terminal 100 communicates with a plurality of controllers 1020, by each user holding each controller 1020, the user terminal 100 can communicate with the one user terminal 100 without communicating with other devices such as the server 200 via the network 2. Multiplayer can be realized. In addition, each user terminal 100 communicates with each other using a wireless standard such as a wireless LAN (Local Area Network) standard (communicates without going through the server 200), thereby realizing local multiplayer with multiple user terminals 100. You can also. When the above-described multiplayer is locally implemented using one user terminal 100, the user terminal 100 may further include at least some of the various functions provided by the server 200, which will be described later. Moreover, when the above-mentioned multiplayer is realized locally by a plurality of user terminals 100, the plurality of user terminals 100 may have various functions provided in the server 200, which will be described later, in a distributed manner.

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

Further, the controller 1020 may be configured to be detachable from the user terminal 100. In this case, a coupling portion with the controller 1020 may be provided on at least one surface of the casing of the user terminal 100. When the user terminal 100 and the controller 1020 are connected via a wire via the coupling section, 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 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 a game program obtained by communicating with an external device such as the server 200 in the memory 11 of the user terminal 100, or may store a game program obtained by reading from the storage medium 1030 into the memory 11. It may be stored in

As explained 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 an example of a mechanism for inputting information to the user terminal 100. Each of the above-mentioned units serving as an input mechanism can be regarded as an operation unit configured to accept user input operations.

For example, when the operation unit is configured with at least one of the camera 17 and the distance measurement sensor 18, the operation unit detects an object 1010 near the user terminal 100 and performs an input operation based on the detection result of the object. Identify. As an example, a user's hand, a marker with a predetermined shape, or the like is detected as the object 1010, and an input operation is specified based on the color, shape, movement, type, etc. of the object 1010 obtained as a detection result. Ru. More specifically, when the user's hand is detected from the captured image of the camera 17, the user terminal 100 converts the gesture (a series of movements of the user's hand) detected based on the captured image into the user's input operation. be identified and accepted as such. Note that the photographed image may be a still image or a moving image.

Alternatively, when the operation unit is configured with the touch screen 15, the user terminal 100 identifies and accepts the user's 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 receives a signal (for example, an output value) transmitted from the controller 1020 as a user's input operation. Alternatively, when the operation unit is configured with the input/output IF 14, a signal output from an input device (not shown) connected to the input/output IF 14 and different from the controller 1020 is identified and accepted as the user's input operation.

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

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

Memories 11 and 21 are main storage devices. The memories 11 and 21 are composed of storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). The memory 11 provides a work area for the processor 10 by temporarily storing programs and various data that the processor 10 reads from a storage 12, which will be 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 work area for the processor 20 by temporarily storing various programs and data that the processor 20 reads from a storage 22, which will be described later. The memory 21 also temporarily stores various data generated while the processor 20 is operating according to a program.

In this embodiment, the program may be a game program for realizing a game on 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 started on the user terminal 100. Alternatively, the program may be a game program for realizing the game through cooperation of a plurality of user terminals 100. Further, the various data include data related to games such as user information and game information, and instructions or notifications transmitted and received between the user terminal 100 and the server 200 or between the plurality of user terminals 100.

Storages 12 and 22 are auxiliary storage devices. The storages 12 and 22 are comprised of storage devices such as flash memory or HDD (Hard Disk Drive). The storage 12 and the storage 22 store various data related to the game.

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, wireless LAN, or mobile phone network, and communication using short-range wireless communication.

The input/output IF 14 is an interface for the user terminal 100 to receive data input, and is an interface for the user terminal 100 to output data.
The input/output IF 14 may input/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 for the server 200 to receive data input, and an interface for the server 200 to output data. The input/output IF 24 may include, for example, an input section that is an information input device such as a mouse or a keyboard, and a display section that is a device that displays and outputs images.

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

The input unit 151 detects the position where the user's operation (mainly physical contact operations such as touch operation, slide operation, swipe operation, and tap operation) is input on the input screen, and inputs information indicating the position. Equipped with a function to transmit as a signal. The input unit 151 may include a touch sensing unit (not shown). The touch sensing section may employ any method such as a capacitance method or a resistive film method.

Although not shown, the user terminal 100 may include one or more sensors for identifying the holding posture of the user terminal 100. This sensor may be, for example, an acceleration sensor or an angular velocity sensor. When the user terminal 100 includes a sensor, the processor 10 can also 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 display a vertically long image on the display unit 152. On the other hand, when the user terminal 100 is held horizontally, a horizontal screen display may be used in which a horizontally long image is displayed on the display unit. In this way, the processor 10 may be able to switch between vertical screen display and horizontal screen display depending on the holding posture of the user terminal 100.

The camera 17 includes an image sensor and the like, and generates a captured image by converting incident light that enters from a lens into an electrical signal.

The distance sensor 18 is a sensor that measures the distance to the object to be measured. 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 sensor 18 measures the distance to the object to be measured based on the timing of light emission from the light source and the timing of reception of reflected light generated when the light emitted from the light source hits the object and is reflected. The distance sensor 18 may include a light source that emits light with directivity.

Here, an example will be further described in which the user terminal 100 uses the camera 17 and the ranging sensor 18 to receive a detection result of detecting an object 1010 in the vicinity of the user terminal 100 as a user's input operation. The camera 17 and the ranging sensor 18 may be provided, for example, on the side surface of the housing of the user terminal 100. A distance measuring sensor 18 may be provided near the camera 17. As the camera 17, for example, an infrared camera can be used. In this case, the camera 17 may be provided with a lighting device that emits infrared rays, a filter that blocks visible light, and the like. This makes it possible to further improve the accuracy of object detection based on images captured by the camera 17, regardless of whether the object is outdoors or indoors.

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 image recognition processing on the image taken by the camera 17 to identify whether or not the user's hand is included in the image taken. The processor 10 may use a technique such as pattern matching, for example, as an analysis technique employed in the image recognition process described above. (2) The processor 10 also detects the user's gestures from the shape of the user's hands. For example, the processor 10 identifies the number of fingers of the user (the number of extended fingers) from the shape of the user's hand detected from the photographed image. The processor 10 further identifies the gesture performed by the user from the identified number of fingers. For example, if the number of fingers is five, the processor 10 determines that the user has made a "pa" gesture. Furthermore, when the number of fingers is 0 (no fingers are detected), the processor 10 determines that the user has made a "goo" gesture. Further, if the number of fingers is two, the processor 10 determines that the user has made a "choki" gesture. (3) The processor 10 performs image recognition processing on the image captured by the camera 17 to detect whether the user's finger is in a state where only the index finger is held up or whether the user's finger is in a flicking motion. . (4) The processor 10 determines whether an object 1010 (such as a user's hand, ) and the user terminal 100 is detected. For example, the processor 10 determines whether the user's hand is close to the user terminal 100 (for example, at a distance less than a predetermined value) or far away (for example, at a distance less than a predetermined value), depending on the size of the shape of the user's hand identified from the captured image of the camera 17. or more distance). Note that when the captured image is a moving image, the processor 10 may detect whether the user's hand is approaching or moving away from the user terminal 100. (5) If it is found that the distance between the user terminal 100 and the user's hand has changed while the user's hand has been detected based on the image recognition result of the image taken by the camera 17, the processor 10 recognizes that the user is waving his hand in the photographing direction of the camera 17. When an object is detected or not detected by the ranging sensor 18, which has stronger directivity than the shooting range of the camera 17, the processor 10 detects that the user is waving his/her hand in a direction perpendicular to the shooting direction of the camera. recognize.

In this way, the processor 10 determines whether the user is clasping his/her hands (a "goo" gesture or another gesture (for example, "paa") by image recognition of the image taken by the camera 17. ). The processor 10 also detects the shape of the user's hand and how the user moves the hand. The processor 10 also detects whether the user is moving his hand closer to or away from the user terminal 100. Such an operation can correspond to, for example, 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 according to the movement of the user's hand, and detects the user's gesture “goo”. In this case, the user terminal 100 recognizes that the user is continuing the selection operation. Continuation of the selection operation corresponds to, for example, the mouse being clicked and kept pressed in, or the mouse being touched after a touch down operation is performed on the touch panel. Further, when the user further moves his/her hand while the user's gesture "goo" is being detected, the user terminal 100 detects a series of such gestures as an operation corresponding to a swipe operation (or drag operation). It can also be recognized. Further, when the user terminal 100 detects a gesture such as a flick of the user's finger based on the detection result of the user's hand based on the captured image of the camera 17, the user terminal 100 converts the gesture into a mouse click or a tap operation on the touch panel. It may be recognized as an operation corresponding to .

<Game Overview>
The games executed by the game system 1 according to this embodiment include a location information game and a town building game. In a location information game, when a user actually moves in real space, the user moves on a map image corresponding to the real space according to the user's position in the real space, and moves to a portal placed on the map image. This is a game in which, by checking in, you can obtain benefits corresponding to the portal (for example, in-game currency, souvenir items corresponding to the portal, etc.).

On the other hand, in city building games, objects such as buildings are placed in virtual space according to input operations from the user, and the objects evolve (e.g., building completion, value generation, leveling up, etc.) as time passes in the game. etc.), and by associating resident characters in the virtual space according to the placement of objects, the user's town is developed and grown.

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 a city-building game elapses (progresses) according to the distance traveled by the user in the location information game. In this embodiment, for example, when the user moves 1 km in real space, 10 minutes of in-game time can elapse; however, the present invention is not limited to this, and when the user moves 100 m, the in-game time can elapse by 1 minute. It may be something.

Additionally, the benefits (in-game currency) acquired in the location information game can be used to newly purchase and place objects in the city-building game. Furthermore, the resident character associated with the virtual space in a city-building game can be moved as a companion to the user in a location-based game, and when the user checks in to a portal, the character can automatically move to another portal without the user having to move. can be used to check in and earn benefits for that portal.

For this reason, for example, obtain benefits in a location-based game → place objects such as buildings in a city-building game → move in a location-based game → evolve buildings (develop the city) and associate resident characters in a city-building game → position It is possible to provide the user with a game cycle such as doubling the benefits obtained through portal check-in with a resident character in an information game → further evolving buildings (further developing the town) in a town building game. Below, details of each of the location information game and the town building game will be explained.

First, the location information game will be explained. When the location information game starts, the user terminal 100 uses information from the location registration system, the GPS (Global Positioning System) module of the user terminal 100, etc. to collect current location information (for example, address information) of the user terminal 100. , latitude and longitude information, etc.), and displays a map around the current location of the user terminal 100 (the user who owns it) in real space based on the current location information. When displaying a map, for example, current location information is transmitted to the server 200 to request transfer of map data around the current location. The server 200 acquires map data around the user terminal 100 via the network from other service providing devices (servers) that provide map data, and also obtains portal information ( information for specifying the location of the portal, the type of portal, etc.), and transmits the portal information to the user terminal 100 together with map data around the user terminal 100.

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, the touch screen 15 displays a map image of a part of the map image based on the map data, which is centered on the user's position in real space. The portal is displayed at a position specified from the portal information in a manner that allows its type to be specified. Further, on the map image on the touch screen 15, a current position image showing the user's current position in real space and a circle image showing the area within a predetermined range (for example, a radius of 200 m) from the current position are superimposed and displayed. be done.

FIG. 2(A) is a diagram showing an example of a display screen displayed on the touch screen 15 during the position information game. FIG. 2A illustrates a case where the user who owns the user terminal 100 is located around Ebisu Station and southwest of the station. A map image 201 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.

Images indicating the type of portal are displayed in correspondence with each of the portals P1 to P4. Examples of portals that can be placed on a map image include parks, coffee shops, supermarkets, department stores, ramen shops, temples, schools, amusement parks, factories, banks, stadiums, mountains, oceans, rivers, fields, apartments, and research. There are various types of portals such as power stations, power stations, police stations, etc. 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 the photographic image, but for example, portal P1 displays a photographic image of a tent and hammock suggesting that the type belongs to leisure, and portal P4 It is assumed that a photographic image of a temple is displayed which suggests that the type belongs to a temple. In this embodiment, an example will be described in which a photo image, etc. is displayed in response to a portal, but the present invention is not limited to this. It may also be one that displays photographic images or the like.

In addition, in the location information game, by touching the portal placed in circle image C (or the image (photo image) indicating the type displayed corresponding to the portal), you can check the portal. can be in. In the example of FIG. 2A, by performing a touch operation on portal P1 or portal P3 arranged in circle image C, the user can check in to the portal.

When a user checks in to a portal, he or she can obtain benefits depending on the type of portal. As a benefit, for example, it is possible to obtain in-game currency in an amount depending on the type of portal, or souvenir items depending on the type of portal checked in. The souvenir items are, for example, items related to local gourmet food or local products where the portal is located. In the location information game, the user can acquire benefits by actually moving in real space and checking in to a portal placed on a map image. Information that allows the acquired benefits to be specified is stored in the memory 11.

Further, when the user moves, the user terminal 100 transmits the current position 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 a portal is displayed superimposed on the map image based on the portal information. That is, the map image and portal on the touch screen 15 are updated as the user who owns the user terminal 100 moves.

In the position information game, the memory 11 stores movement distance information that can specify the distance traveled by the user in real space, aiming at a desired portal. In location information games, movements at speeds below a predetermined speed (e.g., 100 m/min), such as walking or trotting, are counted as user movements, and movements at speeds exceeding the predetermined speed (e.g., by car, train, etc.) are counted. Designated to be excluded from the scope.

Next, the city building game will be explained. In a city building game, a city is created by arranging objects owned by the user in a game field, which is a virtual space, based on the user's input operations. In a city building game, objects can be held and placed by purchasing objects by consuming in-game currency. Information that enables identification of held objects, placed objects, their placement positions, etc. is stored in the memory 11.

FIG. 2(B) is a diagram showing an example of a display screen displayed on the touch screen 15 during the city building game. In the example shown in FIG. 2(B), a screen that is displayed when placing a purchased object is shown, and a game field is displayed in the first area 202 that occupies most of the touch screen 15, and the game field is displayed below the touch screen 15. Objects 204 and 205 held by the user are displayed in a second area 203.

The user can place the desired object at a desired position within the game field by dragging the object shown in the second area 203 and dropping it at the desired position within the game field. In FIG. 2(B), a plurality of objects have already been placed to form the user's town T1, and it is shown that the user is about to newly place the object 204 that he/she owns.

A plurality of types of objects are provided corresponding to buildings and the like that may exist in real space. For example, parks, coffee shops, supermarkets, department stores, ramen shops, temples, schools, amusement parks, factories, banks, stadiums, mountains, oceans, rivers, fields, apartments, research institutes, power plants, police stations, etc. Types of objects are provided.

When an object is placed on the game field, it first enters a construction state, and the in-game time required for completion is determined for each type of object. The remaining in-game time required for completion is displayed superimposed on the object in the building state by, for example, tapping the object.

After the object reaches the completed state after the in-game time required for its completion has elapsed, the object exhibits an effect corresponding to the object each time a predetermined amount of in-game time (for example, production completion time, etc.) elapses. Therefore, when the object is completed, the degree of advantage for the user in town planning increases. The time required to exert an effect and the effect to be 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, and department stores, banks, etc. are associated with the effect of producing resources. The effect of issuing (in-game currency) is associated with it, and the effect of developing schools, buildings, research institutes, etc. is associated with it. A town generated in a town-building game is evaluated based on the total value or percentage of food, resources, funds, development, etc., which can be determined from the number and type of placed objects, for example. In a city-building game, for example, the larger the total value of each of food, resources, funds, and development, or the more balanced the four items are, the richer the city is evaluated.

Further, for an object in a completed state, a level of the object is determined. The level of an object affects, for example, the magnitude of the effect it exerts and the time it takes to exert it; the higher the level, the greater the effect it exerts and the shorter the time it takes to exert it. For this reason, the degree of advantage for the user in city development increases. For an object in a completed state, for example, the in-game time required to reach the next level is determined. The in-game time required until the next effect is exerted or the in-game time required until the next level is displayed superimposed on the object by, for example, tapping the object. To make it possible to identify the status of objects (under construction, completed, effective, level, etc.), the total value and proportion of food, resources, funds, development in the entire city, values indicating the richness of the city, etc. Information is stored in memory 11.

As described above, the in-game time that affects the completion, effect exertion, and level improvement of objects elapses according to the distance traveled by the user in the position information game. Furthermore, in-game currency necessary for purchasing objects can also be acquired by the user checking in to the portal in the location information game.

FIG. 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 elapse the in-game time. As shown in FIG. 2C, park objects can be purchased by consuming "25" in-game currency, and are completed when 10 minutes of in-game time have elapsed after placement. Therefore, when the moving distance reaches 1 km, the placed park object can be completed after 10 minutes of in-game time has elapsed. Similarly, for the coffee shop object and the factory object, the purchase price, in-game time from placement to completion, and required travel distance are determined. In addition, for each object, the in-game time required to exhibit its effect once after completion, the in-game time required to reach the next level, etc. are determined. As a result, after objects are placed in a city-building game or after an effect is exerted, it is possible to prompt the user to move by having the user play the position information game. Information that can specify the remaining in-game time required to improve the degree of advantage such as completion, effect exertion, level up, etc. is stored in the memory 11 for each object.

FIG. 2(D) illustrates a case where a user who owns the user terminal 100 walks from around Ebisu Station (for example, FIG. 2(A)) to a location located northwest of Shibuya Station during a location information game. ing. A map image 210 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, and the current position image U, and circle image C are displayed. The user can check in to the portal by moving to a position where one of the portals P5 to P7 is within the circle image C and touching the portal. This makes it possible to earn in-game currency according to the type of portal. Furthermore, by consuming in-game currency owned by the user, it becomes possible to acquire souvenir items according to the type of portal.

Furthermore, in the location information game, the moving distance information is updated as the user moves, thereby making it possible to advance the in-game time in the city building game. As a result, in city-building games, in-game currency is consumed to purchase and place objects, and in-game time progresses based on travel distance information to complete the objects, demonstrate their effects, level them up, etc. As illustrated in FIG. 2(E), the user's town can be developed and grown. FIG. 2(E) shows how the town T1 shown in FIG. 2(B) is developing and growing into a large town by further placing a large number of objects.

Furthermore, in a town building game, resident characters are associated with the user's town as the town is developed and grown by arranging objects. Resident characters K1 to K7 are associated with the town shown in FIG. 2(E). As resident characters that can be associated with a virtual space, there are multiple types of characters with different characteristics such as hobbies and preferences, and characters that have characteristics according to the types of objects placed in the virtual space are associated. . For example, when a museum object is placed, a character having a characteristic of liking art such as paintings is associated with the character at a higher rate than when no museum object is placed. Furthermore, when the ramen shop object is placed, characters having the characteristic of liking ramen are associated with the character at a higher rate than when the ramen shop object is not placed.

Further, the number of resident characters increases or decreases depending on, for example, the affluence of the user's town. For example, the greater the total value of each of food, resources, funds, and development, and the better the balance, the more resident characters are associated. In FIG. 2E, in the second area 203, a pie chart shows the balance of food, resources, funds, and development, and the center of the pie chart shows the number of resident characters associated with the user's town. ing. The example in FIG. 2(E) shows that food accounts for 40%, resources account for 30%, funds account for 20%, and development accounts for 10%, and that there are seven resident characters. Information that allows identification of resident characters and characteristics associated with the user's town is stored in the memory 11.

A resident character associated with a town can be taken out as a user's companion in a location information game. The resident character and the number of characters to be taken out as companions are specified by being selected by the user when starting the position information game.

FIG. 3(A) is an example of a display when a user checks in to portal P1 with resident characters K1 to K7 taken out as companions. Resident characters K1 to K7 each have their own characteristics. As shown in FIG. 3(B), the resident character K1 has a characteristic of preferring B-class gourmet food, the resident character K2 has a characteristic of preferring visiting coffee shops, and the resident character K3 has a characteristic of visiting history. Suppose you are doing so. Although not shown, the resident characters K4 to K7 have similar characteristics.

On the other hand, as shown in FIG. 3(A), around portal P1, there are ramen portal P2, which has similarities with B-class gourmet food, coffee portal P3, which has similarities with coffee shop visiting, and portal P3, which has similarities with history exploration. Portal P4 of a temple with gender is located. In this case, as shown in FIG. 3(A), among the resident characters K1 to K7 taken out as companions, resident character K1 moves to portal P2, resident character K2 moves to portal P3, and resident character K3 moves to portal P3. A display to move to P4 is displayed, and each user checks in to a portal having commonality.

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 character's own characteristics, and selects the portal. Check in. The range in which the resident character can check in is set to be wider than the circle image C (for example, a radius of 500 m). This makes it possible for the user to acquire in-game currency corresponding to each of the portals P2 to P4 without checking in to the portals P2 to P4.

Also, when a resident character checks in to a portal, an inquiry will be displayed asking whether or not to purchase a souvenir item corresponding to the portal, and if the user selects to purchase, the user can purchase the souvenir item of the portal using in-game currency. It is possible to obtain souvenir items. Furthermore, for resident characters K4 to K7 taken out as companions, if there is no portal that has characteristics in common with their own, they may not check in to any portal. You may check in to any portal even when there is no portal with the same.

Furthermore, as illustrated in FIG. 3(B), each resident character has an episode and release conditions (viewing conditions) for the episode. An episode is associated with each resident character, and is a narrative performance related to that resident character. The episode release condition is established when the user acquires a specific souvenir item according to the characteristics of the resident character and gives (consumes) the souvenir item to the resident character. Note that the episode release condition may be satisfied when the user acquires a specific souvenir item. Information that allows the title and release condition of the resident character's episode to be specified is stored in the memory 11.

As shown in FIG. 3(B), the resident character K1 is associated with EP1 and EP2 as episodes, and is given a souvenir item of fried rice or Chinese steamed buns that can be purchased at the portal corresponding to XX house. Conditions for release are established based on this. For example, EP1 is set to produce a story in which the resident character K1 learns why he fell in love with XX house. Resident character K2 is associated with EP3 and EP4 as episodes, and a release condition is established that is established by giving souvenir items such as cookies or coffee beans that can be purchased at the portal corresponding to cafe △△. ing. In this way, the specific souvenir items that satisfy the episode release conditions are determined to be items that are related to the characteristics of the resident characters. Similarly, unique episodes and release conditions are defined for other resident characters. The resident character's episode title and release conditions are displayed in a list when selecting a resident character to be taken out as an companion during the location information game. Furthermore, when the title of the episode and the release conditions are displayed in a list, the location of the portal where the souvenir item that satisfies the release condition can be acquired, the distance to the portal, etc. are also displayed. Therefore, it is possible to confirm the portal that the user should aim for in order to release the episode of the desired resident character, and to give the user a motive to move to the portal.

Next, the processing contents for playing the location information game and the town building game will be explained. FIG. 4 is a diagram for explaining a flowchart of 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 the present invention is not limited to this, and some of the 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 position information game, a resident character to be taken out as an companion is determined. Specifically, the user checks the souvenir items that satisfy the release conditions, the distance to the portal, etc. by referring to the episode titles and release conditions of resident characters that are displayed as a list when starting the location information game. Then, select the resident character you want to take out as your companion.

In step S02, the moving distance information is updated according to the moving distance based on the user's position in real space. The movement distance may be, for example, a straight line distance from the user's position when starting the location-based game to the user's current position, or a straight-line distance from the user's position when starting the location-based game to the user's current position. It may also be the distance traveled to reach .

In step S03, it is determined whether the user has checked in to any portal within the circle image C. If it is not determined that the user is checking in, it is assumed that the user is moving, and the process proceeds to step S02, where the moving distance is updated in accordance with the user's movement. Note that during this time, the map image and portal on the touch screen 15 are updated as the user moves.

On the other hand, if it is determined that the user has checked in, in-game currency is given to the user in accordance with the portal to which the user has checked in, in step S04. In step S05, a souvenir item is provided as the in-game currency owned by the user is consumed. Specifically, when users check in to a portal, they are notified of the in-game currency that has been granted, and then a list of souvenir items that can be purchased at the portal is displayed, and the souvenir items can be purchased according to the user's selection operation. Become.

In step S06, it is determined whether the resident character is accompanied by a companion. If it is not determined that the resident character is present, the process moves to step S10. On the other hand, when it is determined that the resident character is accompanied by a companion, the process moves to step S07, and processing is performed to determine the portal where the resident character will check-in. In step S07, the portal to be checked in is determined based on the characteristics of the resident character taken out as an companion and the commonality with the types of portals placed around the portal where the user checked in. Portals that can be check-in destinations are not limited to portals within the circle image C, but include portals located in a wider area than the circle image C. For the resident character whose check-in destination has been determined, a display is performed to move to the determined portal and check-in.

In step S08, in-game currency is given according to the portal checked in. In step S09, a souvenir item is provided as the in-game currency owned by the user is consumed. Specifically, when a resident character checks in to a portal, the provided in-game currency is announced, and then the resident character is asked to confirm whether or not it is okay to purchase souvenir items that can be purchased at the portal. A window is displayed, and when the user indicates his/her intention to purchase the souvenir item, 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 the user's selection operation, or may be selected at random based on the characteristics of the resident character.

In step S10, a souvenir item for releasing an episode of the resident character is acquired, and the souvenir item is given (consumed) to the resident character, thereby releasing an episode related to the resident character. Thereby, episodes of resident characters can be viewed.

FIG. 5 is a diagram for explaining a flowchart of city-building game-related processing included in the process for playing the city-building game. The city-building game-related processes are executed by the user terminal 100, but the process is not limited thereto, and some of the processes may be executed by the server 200 and the processing results sent to the user terminal 100. When starting the city-building game, in step S20, the in-game time is allowed to elapse according to the travel distance based on the travel distance information updated in the position information game. Specifically, 10 minutes of in-game time are allowed to pass for every 1 km.

In step S21, it is determined based on the elapsed in-game time whether or not the time for improving the advantage of the placed object has elapsed. The time required to improve the advantage of an object includes the time required for it to go from a built state to a completed state, the time required for an effect to be exerted, the time required for an object to be leveled up, etc. If it is not determined that the time for improving the advantage of the object has elapsed, there is no object whose state changes, and the process directly proceeds to step S26.

On the other hand, when it is determined that the time for improving the advantageous degree of the object has elapsed, the advantageous degree of the object to be determined is improved in step S22. Specifically, when the object is in a construction state, processing is performed to update it to a completed state, make it exhibit an effect, or level it up.

Further, in step S23, the richness of the town is specified based on the total value and proportion of food, resources, funds, development, etc., of 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, depending on the affluence of the town. For example, it may be determined that a resident character is newly associated each time the total value of each of food, resources, funds, and development in the entire city increases by a predetermined value. When it is determined that a resident character should be newly associated, a resident character having characteristics corresponding to the types of objects placed in the town is associated in step S25. As described above, when a museum object is placed, characters having the characteristic of liking art such as paintings are associated with the character at a higher rate than when no museum object is placed.

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. As a result, in addition to growing and developing the user's city, in order to complete newly placed objects or improve the advantage of already placed objects, the user can start the position information game again and move around in real space. It can encourage users to move.

<Effects of this embodiment>
According to the present embodiment, as shown in step S20 in FIG. 5, the in-game time for improving the advantage of objects in a city-building game and growing and developing the city is the same as the in-game time when the user is in real space in a location-based game. Progress based on the distance traveled. Therefore, it is possible to encourage the user to move in order to advance the in-game time, and it is possible to prevent a decline in the user's sense of participation in the game.

Further, the degree of advantage of an object increases as a predetermined time period for each object passes, as shown in step 21 and step S22 in FIG. Therefore, the user can be prompted to move in order to advance the predetermined time.

Furthermore, in the town building game, as shown in steps S23 to S25 in FIG. 5, resident characters can be associated with the town by growing and developing the town. In addition, in the location information game, as shown in steps S06 to S09 in FIG. 4, by taking out a resident character as an companion and moving it around, the user can acquire benefits corresponding to the portal by checking in to the portal. Furthermore, you can earn benefits by automatically moving the resident character you brought out as your companion to another portal and checking in. As a result, the more resident characters there are, the more benefits the user can acquire efficiently. As a result, the user can be motivated to grow and develop the town in order to associate more resident characters to accompany movement in the location information game.

Further, the check-in destination of the resident character is determined based on the characteristics of the resident character from portals arranged within a wider range than the circle image C, as shown in step S07 of FIG. Therefore, the user can also check in to portals that are not placed within the circle image C without actually moving. As a result, it is possible to create an incentive to associate more resident characters. Further, the characteristics of the resident character associated with the town are determined according to the type of placed object, as shown in step S25 of FIG. Further, the number of resident characters is determined according to the richness of the town, etc., which is specified from the placed objects, etc., as shown in steps S23 and S24 of FIG. For this reason, it is possible to provide fun in the city-building game, such as deciding what kind of objects to place.

Benefits obtained through portal check-in include in-game currency for purchasing objects in the city-building game. This requires more in-game currency to grow and develop the city, which in turn encourages user movement in location-based games and motivates users to check in to the portal. can.

As shown in FIG. 3(B), each resident character has a unique episode and release conditions for releasing the episode. Further, the release condition is established by giving (consuming) a specific souvenir item to the resident character according to the characteristics of the resident character. Therefore, the user can be motivated to move toward the portal where the souvenir item for releasing the episode of the resident character can be obtained. In addition, souvenir items can be obtained by checking in to the portal and consuming in-game currency. This can encourage more check-ins to the portal to earn in-game currency.

<Modified example>
Modifications of the embodiment described above are listed below.

(1) About travel distance and in-game time The travel distance information updated in step S02 of FIG. 4 in the above embodiment is updated in step S20 of the city building game in FIG. An example of how this is reflected in the progression of in-game time has been explained. However, the travel distance information updated in step S02 of FIG. 4 is reflected in the progress of the in-game time of the city building game by checking in to the portal, and the travel distance information updated in step S02 of FIG. Even if it is, it may not be reflected in the progress of in-game time. This makes it possible to further encourage users to check in to the portal. In addition, in this case, the movement distance information is not the actual distance traveled by the user, but, for example, the distance from the user's position when starting the location information game to the portal where the user checked in (straight line distance or (distance traveled along the route). Thereby, the processing load for calculating the moving distance can be reduced. Additionally, when starting a location-based game, the user specifies a portal as the destination, and by checking in to that portal, the updated travel distance information is reflected in the progress of in-game time. good.

Furthermore, in the above embodiment, an example has been described in which the movement distance information is updated during the location information game, but not updated when the location information game is not in progress. However, the movement distance information is updated according to the user's movement in real space, regardless of whether or not a location information game is being played, for example, even during a city building game, and is reflected in the in-game time. You can do it like this. Thereby, while displaying the screen during the town building game, the user can progress the time in the game on his/her own according to the distance traveled by the user.

Furthermore, the movement distance information may be updated in accordance with the movement of the user in real space, regardless of whether the program for executing the present game is activated (logged in) or not. For example, if the user terminal 100 has a function of storing (accumulating) the user's location information in the memory 11 periodically (for example, every 30 seconds), the user may start a program to run the game ( When the user logs in), the program of this game reads the location information stored (accumulated) in the memory 11, and uses the location information to determine the distance traveled by the user while the program of this game is not activated. Then, the moving distance information may be updated according to the moving distance and reflected in the in-game time. Note that the updating of the travel distance information while the program of this game is running is as described above.

Furthermore, 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), as shown in step S20 in FIG. 5, 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, regardless of whether the city building game is in progress or not, for example, even during the position information game. In this case, when it is determined that the time for improving the advantage of an object according to the user's movement during the location-based game has elapsed, it is possible to identify the type of object and the content of the improvement in a predetermined area during the location-based game. It is also possible to display (for example, a pop-up display in the header area) information that becomes the following. Thereby, it is possible to prompt the user to move on to the city building game.

(2) Regarding the resident character 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 out as a companion. However, the resident character to be taken out as a companion may be determined by lottery. In addition, if you set a portal as a destination when starting a location-based game, depending on the type of portal that is set and the portals around the portal, you can select a portal that has a high degree of commonality with these portals. A resident character having the characteristic may be determined as the resident character to be taken out as an companion (or determined at a high rate).

In the embodiment described above, an example has been described in which, by checking in to a portal, the user causes the resident character taken out as an companion to check in to another portal. However, the accompanying resident character may be automatically checked into the portal without the user checking into the portal. For example, when a user is moving towards a desired portal and a portal with the same characteristics and type as the accompanying resident character is located, the resident character is automatically checked into the portal and given a special benefit. You may also be able to obtain This makes it possible to provide the user with an interesting experience of deciding which route to take to reach the portal.

In the embodiment described above, an example has been described in which a range (for example, a radius of 500 m) within which a resident character can automatically check-in is determined. However, the range in which the resident character can automatically check in may not be determined. Thereby, the resident character can be freely moved and checked in.

In the above embodiment, an example has been described in which a resident character associated with a town can be taken out at any time as a companion to the user. However, when the value of a predetermined parameter regarding the resident character is equal to or greater than a predetermined value, the resident character can be taken out as an accompaniment, and when the value is less than the predetermined value, the resident character may not be taken out as an accompaniment. Specifically, a parameter such as stamina is set for the resident character, and the stamina parameter is consumed according to the distance traveled as a companion of the user, and when the stamina parameter is equal to or higher than a predetermined value, the resident character can be taken out as a companion. If the value is less than the value, you may be unable to take him out as an companion. Furthermore, when the stamina parameter becomes 0 during movement, the companion character may end at that point and be unable to accompany the resident character further. This can add interest to the scene where you select a resident character to accompany you.

Furthermore, predetermined parameters regarding the resident character may be recoverable according to the user's travel distance when not accompanying the user as an attendant, and may be recoverable by giving a souvenir item for stamina recovery. Furthermore, it may be possible to recover the value according to the amount consumed by consuming the virtual currency purchased by charging.

(3) About souvenir items In the above embodiment, an example was explained in which souvenir items depending on the portal can be purchased with in-game currency, but the present invention is not limited to this, and it is also possible to purchase souvenir items with virtual currency purchased by charging. It's okay.

In the above embodiment, an example has been described in which the episode release condition is satisfied and the user can view the episode by acquiring or giving a specific souvenir item to the user's resident character. However, by acquiring or giving a specific souvenir item, the parameters for fulfilling the release conditions of the episode will be updated, and even after that, by acquiring or giving a specific souvenir item, the parameter will reach the predetermined value. By doing so, the release condition for the episode may be satisfied. In addition, the resident character is not limited to the resident character associated with the user's town, but can also be used to give specific souvenirs to resident characters associated with the town of other users who have a predetermined relationship with the user (for example, a friend relationship). By acquiring or giving items, etc., the release condition for the episode of the other user's resident character can be established, and the user may be able to view the episode of the resident character. This allows interaction with other users and increases liking.

Furthermore, an example has been described in which the user can purchase souvenir items from a portal that a resident character has automatically checked into without checking into the portal. However, the purchase of souvenir items is not limited to this, and the resident character checks in to notify the user of what kind of souvenir items are available at the portal, and the user actually checks in to the portal. Otherwise, the souvenir item may not be available for purchase.

(4) About objects placed in the city building game Objects placed in the city building game of the above embodiment have the time required to go from the architectural state to the completed state, the time required to exhibit their effects, and the level up. An example has been described in which the time required to improve the advantage of an object is predetermined for each object. However, the time for improving the advantage of a predetermined object may be shortened, for example, by consuming virtual currency purchased by charging, or may be shortened by consuming virtual currency (e.g. , immediate completion, etc.). In addition, although we have explained an example in which the magnitude of the effect (for example, production volume, etc.) is predetermined according to the level of the object, it is not limited to this. The effect may be made to be greater than a predetermined effect. This allows the user's town to grow and develop at an early stage through billing, and as a result, resident characters can be associated at an early stage.

In addition, as for objects held, although we have explained an example in which they can be placed on the game field regardless of the number of objects in the construction state, this is not limited to this, and when the number of objects in the construction state reaches a predetermined number, , it may be possible to disable new placement of objects. In this case, even when the number of objects in the construction state has reached a predetermined number, new objects may be placed by consuming virtual currency purchased through billing. This allows the user's town to grow and develop at an early stage through billing, and as a result, resident characters can be associated at an early stage.

In the above embodiment, an example has been described in which it is not possible to specify how much movement is required during the position information game to elapse the time required to increase the advantage of an object placed on the game field. However, during a position information game, it may be possible to specify how much movement is required to elapse time to increase the advantage of objects placed on the game field. If the travel distance corresponding to the time to improve the advantage of the object specified by the user is Xkm, for example, a circle image with a radius of Xkm based on the current position may be displayed superimposed on the map image. . This allows the user to confirm the range of movement required to improve the advantage of the specified object, and thus allows the user to clearly set the destination.

In the city building game of the above embodiment, an example has been described in which in-game time is advanced as an indicator of whether or not to improve the advantage of placed objects. However, the indicator of whether or not to improve the advantage of placed objects is not limited to the in-game time, but can be any other predetermined parameter that is updated according to the distance traveled by the user. Alternatively, the distance traveled by the user itself may be used.

<Additional notes>
The matters described in each of the above embodiments are additionally described below.

(Additional note 1):
According to an aspect of an embodiment shown in the present disclosure, there is provided a game program executed in an information terminal device including a processor, a memory, and a display unit, wherein the game program allows the processor to change the state. executing a first game part (FIG. 5) in which an object is placed in a virtual space and the state of the object is changed to a state advantageous to the user; and a movement distance in the real space of the user who owns the information terminal device. (step S02 in FIG. 4), and the step of executing the first game part includes the step of advancing the in-game time in the first game part based on the movement distance (step S02 in FIG. 4). S20), and changing the state of the object to a state advantageous to the user based on the progress of the in-game time (steps S21, S22).

(Additional note 2):
In (Additional 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.

(Additional note 3):
In (Appendix 1) or (Appendix 2), the game program causes the processor to perform a game part different from the first game part according to a position in real space of a user who owns the information terminal device. A step of executing a second game part in which the game is controlled (granting benefits) when the permission condition is satisfied (the user moves so that the portal enters the circle image C) (steps S04 to S09 in FIG. 4) and the step of executing the first game part includes a step of associating a game character (inhabitant character) with the virtual space (step S25), and the step of executing the second game part includes a step of associating a game character (inhabitant character) with the virtual space, and the step of executing the second game part includes a step of associating a game character (inhabitant character) with the virtual space. a step of displaying, on the display unit, an image within a part of the map image in which a plurality of portals are arranged (a step of displaying FIG. 2(A) etc.); a step (step S01) of identifying a game character associated with the virtual space in the first game part as the user moves in the second game part; This is established by accepting an input operation for a portal displayed on the display unit that is located within a predetermined range from the user's position in real space, and the permission condition is satisfied in the second game part. The game control performed by this includes control for granting a benefit according to the operation target portal that has received an input operation among the arranged portals (steps S04 and S05), and The present invention includes control (steps S08 and S09) of moving the game character currently present to a portal different from the operation target portal and granting benefits corresponding to the portal.

(Additional note 4):
In (Additional Note 3), the benefit includes in-game currency required to place objects in the first game part.

(Additional note 5):
In (Appendix 3) or (Appendix 4), the step of executing the second game part includes moving from the user's position in real space to an area within a specific range wider than the predetermined range, regardless of an input operation from the user. The method includes a step of determining a portal to which the game character is to be moved from among the arranged portals (step S07).

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

(Appendix 7):
In any one of (Appendix 1) to (Appendix 6), the game program includes a game part that is different from the first game part to the processor, and a position in real space of a user who owns the information terminal device. A step of executing a second game part (step S04 in FIG. 4) in which the game is controlled (granting benefits) when the permission condition is satisfied (the user moves so that the portal enters the circle image C). ~S09) to execute the second game part, the step of executing the second game part includes converting an image within a part of the map image corresponding to the real space and in which a plurality of portals are arranged into the map image into the map image. The permission condition includes a step of displaying on the display unit (a step of displaying FIG. 2(A) etc.), and the permission condition is that the portal displayed on the display unit is located within a predetermined range from the user's position in real space. The moving distance specified in the identifying step is established by accepting an input operation for the placed portal, and the movement distance specified by the identifying step is determined by the distance from the user's position in real space when starting the second game part to the portal that received the input operation. This is the distance to.

(Appendix 8):
In any one of (Appendix 1) to (Appendix 6), the game program includes a game part that is different from the first game part to the processor, and a position in real space of a user who owns the information terminal device. A step of executing a second game part (step S04 in FIG. 4) in which the game is controlled (granting benefits) when the permission condition is satisfied (the user moves so that the portal enters the circle image C). - S09), and the moving distance specified in the specifying step is a distance specified from the user's position in the real space, regardless of whether it is during the second game part or not.

(Appendix 9):
In any one of (Appendix 1) to (Appendix 8), the game program includes a game part that is different from the first game part to the processor, and a position in real space of a user who owns the information terminal device. A step of executing a second game part (step S04 in FIG. 4) in which the game is controlled (granting benefits) when the permission condition is satisfied (the user moves so that the portal enters the circle image C). ~S09) and executing the first game part includes a step of associating a game character with the virtual space (step S25), and the game character has a special character associated with the game character. Execution conditions (release conditions) for executing a production (episode) are determined (FIG. 3(B)), and the step of executing the second game part is a map image corresponding to the real space. The permission condition includes the step of displaying an image within a part of the map image in which a plurality of portals are arranged on the display unit (displaying FIG. 2(A), etc.), and the permission condition is such that the display The step of executing the second game part is realized by receiving an input operation for a portal located within a predetermined range from the user's position in real space among the portals displayed in the part. The game control includes a step (step S05) of providing an item (souvenir item) corresponding to the portal among a plurality of types of items when the permission condition is satisfied by receiving an input operation for the portal; The condition can be satisfied by providing a specific item (see FIG. 3(B)).

(Appendix 10):
In (Appendix 9), the step of associating the game character associates a game character having characteristics according to the type of the placed object (step S25), and the item for which the execution condition can be satisfied is the game character. (see FIG. 3(B)).

(Appendix 11):
In (Appendix 9) or (Appendix 10), the step of granting the item is performed by consuming in-game currency required for placing objects in the first game part, in response to the portal for which the permission condition is satisfied. (steps S05, S09).

(Appendix 12):
According to an aspect of an embodiment disclosed in the present disclosure, there is provided a game method executed by an information terminal device including a processor, a memory, and a display unit, in which an object whose state can change is placed in a virtual space, and the object a step of executing a first game part that changes the state of the information terminal device to a state advantageous to the user (FIG. 5), and a step of specifying the moving distance in real space of the user who owns the information terminal device (step S02 of FIG. 4). ) and executing the first game part includes a step of advancing the in-game time in the first game part based on the movement distance (step S20); (steps S21, S22), changing the state of the object to a state advantageous to the user based on the following.

(Appendix 13):
According to an aspect of an embodiment of the present disclosure, there is provided an information terminal device including a processor, a memory, and a display unit, in which an object whose state can change is placed in a virtual space, and the state of the object is changed to the user. (FIG. 5), and specifying the moving distance in real space of the user who owns the information terminal device (Step S02 in FIG. 4). The step of executing the first game part includes the step of advancing the in-game time in the first game part based on the movement distance (step S20), and the step of advancing the in-game time in the first game part based on the progress of the in-game time. The method includes a step of changing the state of the object to a state advantageous to the user (steps S21 and S22).

[Example of implementation using software]
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 instructions of a program that is software that implements each function. This computer includes, for example, one or more processors and a computer-readable recording medium that stores the above program. In the computer, the processor reads the program from the recording medium and executes the program, thereby achieving the object of the present invention. As the processor, for example, a CPU (Central Processing Unit) can be used. As the recording medium, in addition to "non-temporary tangible media" such as ROM (Read Only Memory), tapes, disks, cards, semiconductor memories, programmable logic circuits, etc. can be used. Further, the computer may further include a RAM (Random Access Memory) for expanding the above program. Furthermore, the program may be supplied to the computer via any transmission medium (communication network, broadcast waves, etc.) that can transmit the program. Note that 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 embodiments described above, and various modifications can be made within the scope of the claims, and embodiments obtained by appropriately combining technical means disclosed in different embodiments. are also included within the technical scope of the present invention.

1 game system, 2 network, 10, 20 processor, 11, 21 memory, 12, 22 storage, 15 touch screen, 151 input section, 152 display section, 17 camera, 18 ranging sensor, 1010 object, 1020 controller, 1030 memory medium, 100 user terminals, 200 servers.

Claims (11)

A program executed on a computer,
The program is
means for executing a first part of arranging an object whose state can be changed in a virtual space and changing the state of the object to a state advantageous to the user;
executing a means for specifying a moving distance in real space of a user who owns the computer;
The means for specifying the moving distance specifies not only the moving distance when the first part is not being executed but also the moving distance when the first part is being executed,
The means for performing the first part includes:
the first part based on the moving distance specified by the means for specifying the moving distance not only when the first part is not being executed but also when the first part is being executed; means for advancing time within the part;
A program comprising means for changing the state of the object to a state advantageous to the user based on the progress of the intra-part time. 2. The program according to claim 1, wherein the changing means changes the state of the object to a state advantageous to the user as the intra-part time progresses for a predetermined period of time. The program is
Executing means for executing a second part, which is a part different from the first part, and which performs part control when a permission condition is satisfied according to a position in real space of a user who owns the computer;
The means for executing the first part includes means for associating a character with the virtual space,
The means for performing the second part includes:
means for displaying, on a display unit, an image within a part of a map image corresponding to a real space and in which a plurality of portals are arranged;
means for specifying a character to be accompanied by the movement of the user in the second part from among the characters associated with the virtual space in the first part;
The permission condition is established by accepting an input operation for a portal located within a predetermined range from the user's position in real space among the portals displayed on the display unit,
The part control that is performed when the permission condition is satisfied in the second part includes control for granting benefits according to the operation target portal that has accepted the input operation among the arranged portals, and control for the movement of the computer. 3. The program according to claim 1, further comprising control for moving an accompanying character to a portal different from the operation target portal and providing a benefit according to the portal. 4. The program according to claim 3, wherein the benefit includes intra-part currency required to place an object in the first part. The means for executing the second part selects the character from among the portals arranged 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. 5. The program according to claim 3, further comprising means for determining a portal to be moved. The means for associating the characters associates a character having characteristics according to the type of the placed object;
6. The program according to claim 5, wherein the determining means determines the portal to be moved based on the characteristics of the character to be moved. The program is
Executing means for executing a second part, which is a part different from the first part, and which performs part control when a permission condition is satisfied according to a position in real space of a user who owns the computer;
The means for executing the second part includes means for displaying, on a display unit, an image within a part of a map image corresponding to a real space and in which a plurality of portals are arranged;
The permission condition is established by accepting an input operation for a portal located within a predetermined range from the user's position in real space among the portals displayed on the display unit,
Any one of claims 1 to 6, wherein the moving distance specified by the specifying means is a distance from the user's position in real space when starting the second part to the portal that accepted the input operation. The program described in. The program is
Executing means for executing a second part, which is a part different from the first part, and which performs part control when a permission condition is satisfied according to a position in real space of a user who owns the computer;
Any one of claims 1 to 6, wherein the moving distance specified by the specifying means is a distance specified from the user's position in real space, regardless of whether it is in the second part. The program described in. The program is
Executing means for executing a second part, which is a part different from the first part, and which performs part control when a permission condition is satisfied according to a position in real space of a user who owns the computer;
The means for executing the first part includes means for associating a character with the virtual space,
Execution conditions for executing a special performance associated with the character are defined for the character,
The means for executing the second part includes means for displaying, on a display unit, an image within a part of a map image corresponding to a real space and in which a plurality of portals are arranged;
The permission condition is established by accepting an input operation for a portal located within a predetermined range from the user's position in real space among the portals displayed on the display unit,
The means for executing the second part includes means for providing, as the part control, an item corresponding to the portal among a plurality of types of items when the permission condition is satisfied by receiving an input operation on the portal. ,
9. The program according to claim 1, wherein the execution condition can be satisfied by being provided with a specific item. The means for associating the characters associates a character having characteristics according to the type of the placed object;
10. The program according to claim 9, wherein the item for which the execution condition can be satisfied is determined according to the characteristics of the character. 10. The item granting means grants an item corresponding to the portal for which the permission condition is satisfied by consuming in-part currency required for placing an object in the first part. The program described in 10.

Images