What To Do in a GPS Game - Locative Game Interactions

If you've decided to make a locative game, you might be wondering what you can actually have the players DO in it. There's a decent amount of activities you can set up as the core actions in your GPS game. I will also point out how the PraxisMapper components support adding each of these into your own games.

Random Items on a Grid:
The most common thing to do is to randomly place interactive items around the player. Since GPS coords are already on a grid, this is a simple matter of selecting random points within a distance of the player and picking what appears near them. This is Pokemon in Pokemon Go, XM in Ingress, gathering nodes in Monster Hunter Now, and so on.

Doing a typical random scatter on a fixed number in an area is the common way of doing this. Niantic, having a database of mobile activity most games don't have access to, makes more items show up where cell phone use is more common. This is why a busy street might not have many spawns, and a grocery store parking lot is flooded with them.

The ScrollingCenteredMap2 control in PraxisGodotComponents can be passed in Nodes that it can place onto the map for you. If you want to add a single Node, use $scm.trackChildOnMap(node, plusCode). If you have a way of reliably generating lots of node, you can call $scm.SetLoadableSource(func)  in your _ready() function and pass it a Callable that generates those nodes to track. Your callable will take in the 8 digit PlusCode for the northwest corner and the size of the square grid to generate Nodes for. The Nodes you return will need a metadata property named 'location' with that nodes intended center as a PlusCode position.  

Fixed items on a Grid:
As above, but the stuff players interact with is always in the same spots. These are Portals in Ingress or Stops and Gyms in Pokemon Go. Niantic, again, has a specific database of locations they're determined are interesting and qualify for gameplay targets that most games do not. 

PraxisMapper uses tags in OpenStreetMap data to determine what type of element a place is, and certain types qualify as gameplay targets. If you want specific interesting places to always be a gameplay target, using map data generated by PraxisMapper will work. You can also use the logic from random items for this, if you have a function that returns the same data for the same location every time.

Player-Placed Items:
The most dynamic of the items-on-the-map options, you can allow players to create the things that appear on the map. These might be cooperative points, they might be competitive points. They might be permanent, they might be temporary. Your game design will decide their behavior.

Delta-V required players to create all of the interactive points on its map, which made being the first player in an area pretty dull. Orna allows players to place shops on the map and optionally make them public to allow other players to use them as well. Parallel Kingdoms/PKEchoes uses them as competitive claims over area.

PraxisMapper would treat these the same way it does the previous 2 entries, and your function for the ScrollingCenteredMap2 control would simply need to load in any places the player has created as well as any it's generating.

Walking A Distance:
Some things will require the player to move and explore some distance before they fire off. Pokemon Go uses this for hatching eggs, making them loot boxes with an exercise requirement. 

PraxisMapper can calculate the distance between PlusCodes, so this can be tracked with a simple function call when the Player moves. That can be tracked in meters and stored however your game requires it.

Areas Traveled To:

Tracking what areas or spaces in a grid the player has walked through is not a common sight in these games. And this is normally good, since having a server full of data on people's full location history while playing would be a huge liability. The problem here is the server-side storage of this. Games that do not transmit data to a central server don't have the issue of leaking this data, and can implement this without much concern.

GPS Monster Scouter operates primary on Areas rather than Places. Without any map data in it, it can only operate on a grid. And it does so pretty well, using a nested grid setup. Each base cell is 500m square, has a single pokemon family spawn, and has a Gym you can fight for a badge. There are also 3x3 grids made up of those base cells, which cover a Region. Defeating all the outer Gyms in a Region allows you to fight the Elite 4 in the center to be its Champion. This pattern applies globally, so you can get multiple Championships from multiple Regions as long as you can get into each grid and win gym battles. 

PraxisGodotComponents has a CellTracker class, which will track which 10-digit PlusCodes have been entered. ScrollingCenteredMap2 uses one by default, and can be set to show or hide this info as an overlay. Gameplay would most likely use derived data from this collection of info, to get total cells explored or an estimate of area covered by it. I assume that the player will only be interested in their total exploration history, but individual gameplay items could each have their own that get filled in by a player. Perhaps different magic items are empowered by exploration, and those can use their own CellTracker separate from the player. For large Places, like national parks, you could use a CellTracker for a player in that place, adding cells only if they intersect with the Place's geometry, and see how much of that Place they have explored.

There is also the RecentActivityTracker, which works the same but also deletes entries after a certain expiration time has passed. I normally use this with an expiration timer of 1 hour when granting basic resources by walking as in Pokemon Walk, or 22 hours when doing daily tasks to allow a little flexibility in a routine like quests in Weekend Space Command (Prototype).

Places Traveled To:

In my design vocabulary, Areas are cells in a grid and Places are actual real-world things drawn on the in-game map.  For instance, an Area would be the PlusCode 8CGRC873+GM, which gives you a roughly 14 feet square (~4 meters) in Madrid, Spain filled in on a map, but Bar La Dolores is a Place that happens to be drawn inside that Area. 

You'll likely still want players to go to Places to do things, though. Lots of the positive interactions people can have will require being in the same location, and Places make that possible in ways that cells across the global grid don't. You may want to consider which Places you want players going to, and I think the default set of gameplay places in PraxisMapper is a reasonable choice.

PraxisMapper has a simple PlaceTracker, which is a list of names of Places visited that updates automatically. Pokemon Walk tracks gameplay Places a specific Buddy has been to and grants a small combat power boost for each one. 

Call to Visit A Place:
Rarely used, a game could ask the player to go to a specific place or type of place. These may be inconvenient for the player, as this will often require driving rather than walking. However, this is often a direct fulfillment of the designers goal to get players out and about to interesting places instead of sitting at home.

Weekend Space Command (Prototype) gives quests that require the player to go to specific types of locations. It searches its map data for nearby entries with the matching type, and picks one of them to be your goal.

PraxisGodotComponents has AreaScanner classes that can search for Places with specific requirements like type and distance, and pick any of the valid entries found. As a convenience method, the player should be able to re-roll the goal and a different entry may be selected if other valid targets are found.  

Resource Investment:
One way to make players get out to a specific location repeatedly is to require investing some in-game resources into it. This might be upgrades, or unlocking resources or interactions. Spending resources as an attack on an opponent can be looked at the same way.

This is XM and Modules added to a portal in Ingress, placing Pokemon in a Gym in PoGo, upgrading shops in Orna, building up a home base, and so on. There isn't anything PraxisMapper specific for this, since this isn't directly tied to the locative part of a locative game. 

Walking a Path:
One way of ensure players get enough movement involved is to build a specific path for them to walk through. This is a bit trickier, as you will need to know which things are walkable and which things aren't, and if they're reasonable choices or if they're private property or unsafe. These either include a re-roll option to generate a different path on-demand, or are made manually by the devs or players to confirm they're viable.

Maguss was the first game I know of to build a path and require the player to follow it specifically to complete a task. Pokemon Go has this as Routes. PraxisMapper does not currently have any helpers to generate these, but by grabbing all the Places that are in a walkable group (tertiary roads, sidewalks, and footpaths would probably be the core of that group) and determining which ones touch, a path would be possible to generate from existing data.

Remote Interaction: 
Less common is doing things at a distance. That sort of defeats the point if your game about going places doesn't make the player actually go there. But, this is rarely the primary way players interact with a location. It is an excellent tool for both letting players get stuff without trespassing, and for checking in on places previously visited.

GPS Monster Scouter does the first, where you can send one of your monsters to walk somewhere and pick up an item you've found on the map you can't personally walk close enough to get. It also requires you to wait for it to return to your position before you can use that monster in battles, so doing this is a moving car can result in long waits for a walking monster to return. Ingress does the second, having added drones at some point that allow you to view the status of a portal you have a key for, with keys normally being acquired by interacting with a portal though they can be traded between players as well. Ingress also only lets you refill a portal's energy if its owned by your team, and not to attack it from the safety of your own house. It does not negate the need to actually walk and explore to play, it just allows for locations to be defended without having an actual human standing somewhere for hours. 

If this is the primary way your players do things in your location-based game, there might be a core flaw in your game design. Rescue Rush, an old iOS game, used your local streets to make Pacman style mazes for its gameplay. Since this gives a player one level to play unless they travel about a mile away, it had to include ways to let the player teleport in-game to other, more interesting places.

All the current PraxisMapper games are local-only, so there's little need for this in them at this point because they download a set of map data that will limit what the game can identify immediately. Places are tracked by PlusCode first and OSM ID second, so given the appropriate map data was downloaded you could do this without a server.

Conclusion:
There are a lot of basic interactions you can drop into a locative game, and many of them don't use more than 1 or 2 of these techniques. Some of them seem like they would require dramatically more infrastructure than most indie developers can build or afford, but PraxisMapper enables dramatically more of these than have been seen recently with a fairly small amount of extra data.  Several of these examples are available in my uploaded projects, with source code available to dig in deeper on how something is done.

Go make your game!