Skip to main content
Wanderlust

GPS Stops

Unlock a stop when the visitor arrives

Put a scene on the map, gate a stop on being there, pick a radius that actually works, and understand exactly what does and does not leave the visitor's phone.

Video walkthrough

Video coming soon. A recorded walkthrough of these exact steps will appear here.
Narration script

The walkthrough has not been recorded yet. This is the narration it will follow, step for step.

Let us make a stop that only opens when someone is standing there. Two settings, in two places. First, the scene needs a spot on Earth. In the hunt editor I scroll to Where scenes are in the world, type a latitude and a longitude, and click Save position. Both or neither. And this is not the tour map, which puts scenes on a floor plan on the Connections page. This is the place on the planet, and a room can have both. Second, the stop. Edit stop, set How it opens to the visitor is physically there, and there is my unlock radius in metres, starting at forty. Do not make that small. Forty is the number that works, because phone G P S is five to twenty metres out, and worse between tall buildings. A ten metre radius feels precise and then fails for people standing in exactly the right place, which just teaches them to press the skip button. The phone also reports how wrong it thinks it might be, and we add that to your radius instead of ignoring it. Also leave the remote fallback on. It is in Hunt settings, on by default, and it is accessibility, not convenience: switch it off and nobody with a mobility limitation and nobody outside the area can finish. Now the part your legal team will ask about, so let me be exact. The visitor's location is read by their own browser, on their device, only after they tap Use my location. The distance maths happens right there in the page. When a stop opens, what is sent is the hunt I D, the stop I D, an opaque random token, the typed answer if there was one, and a flag if they used the fallback. There is no latitude or longitude field in that request at all, and no column in our database could store one. That token is sixteen random bytes the browser made up: not an account, not joinable to a person. Two honest consequences. Someone could fake an unlock without walking anywhere, the right trade for a teaching game and the wrong one for a prize. And because we never store a position, we can never show you a trail or a heatmap.

Steps

  1. Give the scene a real-world position first. In the hunt editor, scroll to Where scenes are in the world, find the scene in the list, and fill Latitude and Longitude, then click Save position. Latitude runs from -90 to 90 and longitude from -180 to 180, and you must fill both or clear both: half a coordinate is rejected.
  2. This is not the tour map. The tour map places scenes on a floor plan image and is built on the Connections page. This is the scene's place on Earth. A museum scene can have both at once, and setting one does nothing to the other.
  3. Now set the stop. Click Edit stop, set How it opens to 'The visitor is physically there', and check Unlock radius (metres). It starts at 40, and it accepts 5 to 2000.
  4. Resist making the radius small. 40 metres is not sloppiness, it is the number that works: consumer GPS is roughly 5 to 20 metres out, and considerably worse between tall buildings. A 10 metre radius reads as precise and then misfires constantly, which trains visitors to reach for the fallback button and makes the whole mechanic pointless. Anything under 25 metres raises a warning before you publish.
  5. The radius grows by the phone's own error estimate, automatically. Every position a browser reports comes with an accuracy figure, and that figure is added to your radius rather than ignored. Someone standing 45 metres from a 40 metre stop on a fix the phone admits could be 30 metres out will unlock, because the device genuinely cannot tell the difference and refusing would strand a visitor who is in fact standing right there. The bias is deliberately toward opening, which is right for a game and would be wrong for anything guarding real access.
  6. Here is what the visitor does. The stop shows 'Turn on location to unlock this stop by arriving.' and a Use my location button, and nothing reads their position until they press it. Once it is on, the stop reports 'About 100m away. Keep going.' and updates as they walk. If they decline, or the phone has no location, they get 'Location is off or was declined. You can still continue below.'
  7. Leave the remote fallback on. In Hunt settings, 'Allow visitors who cannot travel to unlock on-site stops remotely' is on by default and is an accessibility setting, not a convenience toggle. With it on, any stop the visitor cannot reach also offers 'I cannot get there, open it anyway', worded so that using it does not read as cheating, because for a lot of people it is the only way through. Turning it off means nobody with a mobility limitation and nobody outside the area can finish, and it raises a warning on every arrival stop.
  8. Now the privacy model, which is the part to hand to a legal team. The visitor's position is read by their own browser, on their own device, only after they press Use my location. The distance to the stop and the decision about whether they are close enough are both computed in the page, on the device. The location watch stops as soon as they leave the hunt page.
  9. What leaves the phone when a stop opens is exactly this: the hunt's ID, the stop's ID, an opaque token, the typed answer if the stop asked for one, and a flag saying the remote fallback was used if it was. There is no latitude or longitude field in that request. Not an optional one, not an empty one. What gets stored is which stop opened, for which token, whether the fallback was used, and when. There is no column anywhere in this system that could hold a visitor's position.
  10. The token is not an identity. It is 16 random bytes the browser generates and keeps in its own storage, so that reloading the page does not wipe progress. It is not an account, not derived from anything about the device, and not joinable to a user. Typed answers are the one thing checked on the server, because an answer can be checked without learning anything about the visitor, and checking it in the browser would put your answer key in the page source.
  11. Two consequences, stated rather than hidden. A determined visitor can record an unlock without going anywhere, and that is the accepted trade for a teaching game: a hunt carrying a real prize would need a different design, not a location field added to this one. And because no position is ever stored, there can be no map trail, no heatmap, and no report of how close people got. Visitors are told the short version on the hunt page: their location is checked on their device only, and is never sent to us or stored.