Hi everyone,
I've hunted around, but I don't think anyone's asked this before, so...
I'm imagining a story that'd be played on a mobile device. Some decisions, branches would go as per normal; others would require the player to be in a physical location to reveal new options (or indeed, new passages). For this to work, I'm imagining a javascript chunk in a passage that would call html5 geolocation api?
Would that work? Could that work?
Comments
The code would go in your story's Story Javascript area (not in a passage) and would need to do at least the following:
1. Check if geolocation exists and is turned on.
Remember not everyone reading your story will be on a mobile device and/or have a mobile device that supports geolocation.
2. Determine if their geolocation is one of the ones you are looking for and then update a Twine variable based on the answer, you can then use this variable to control the availability of selected passages / features.
note: The Harlowe story format does not currently support a simple method for updating Twine variables using javascript code therefor I would suggest using either SugarCube or Snowman 2 instead.
One could build that kind of serendipity into the narrative (somehow), where the game played from (say) the local school as a starting point would be a completely different narrative experience than if the player started at the local park.
Just a thought. Absolute positioning, and comparing passages against a list is probably more within my capabilities (potentially; I need to learn about variables etc!)
And that's it for my social commentary.
;-)
then, I'd have one super passage, where I'd have an if statement, comparing $Location against my list of points of interest (ok, so an array?). If there's a match, the correct passage would display...?
I can't test your code because I don't use a smartphone but I noticed a couple of things.
1. Registering a watchPosition callback:
I believe SugarCube's prerender event happens every time a Reader changes from one passage to another, so therefor your code is registering a new watchPosition callback over and over again.
Something like the following should work but you really need to add extra code checking for things like if geolocation exists and any other possible thing that could go wrong:
2. Unless you are planing on using a background thread/worker then even though the $Location variable will be updated in semi-real time the Reader is not going to see the result of their location change until they move from one passage to another.
If this is the case then I suggest not using a watchPosition and using getCurrentPosition instead, either at the time when a decision needs to be made of showing a geolocation passage or not, or by giving the Reader a button to press when the they have changed locations.
Beyond that, the code is probably still incorrect as it assigns only the latitude to $Location. I assume that you, @shawn, were trying to assign both the latitude and longitude.
I'll also echo @greyelf and suggest that using watchPosition() is likely overkill for what you seem to want to do. So, my suggestion would be something like the following (goes in the Story JavaScript):
So now I just need to check the location, and depending on results, update the passage accordingly. I can do that!
So, I put this in a passage:
and create a passage called "Downtown Toronto". I play through, and I get the kind of response I'm looking for. Of course, I'm only looking for the latitude here. Guess I'd need some sort of AND statement to get both. Anyway-
FYI, this is my storyboard:
So now, I need to build in a bit of tolerance on the location trigger (we don't need to get right down to the metre) and perhaps, rather than absolute positioning, it'd make sense to go for relative positioning. Although absolute vs relative would depend on what one actually wants the geotrigger for.
And of course, more locations. It might be ugly, but a series of if-then statements will do the trick. I expect there are more elegant ways, some sort of of look-up table.
But getting closer, closer...
anyway, here's the html, which those interested can open in the twine 2 import
https://dl.dropboxusercontent.com/u/37716296/geolocate5.html
ie, if regex were possible, something like <<if $Location.latitude eq 43.6[0-9]\w>>
so that the user doesn't have to be pin-point on the spot in order to hit the trigger?
Perhaps there is a kludge.
Ugly, but does the trick.
Usage with default allowed difference (0.5): Usage with specified allowed difference:
OH NO
I'm sorry - folks had great answers to my note above, and I don't know what I did, but I've deleted their answer.
I'm sorry - I'm such a dufus. Would you mind reposting?
I remain a dufus.
I wrote up this process on my blog at http://electricarchaeology.ca/2015/05/20/low-friction-augmented-reality/ and the link to my story file is at the end. You can download 'The Ottawa Anomaly' there, open it in the Twine 2 editor to see how I put this together.
It's not elegant - no doubt there's better ways of adding & managing points of interest - and the narrative leaves a bit to be desired, but ideally one of you will take a crack at making this all work better!
I'd like to think that geotriggers opens a new vista for twineworks.
Thanks again for all your help,
Shawn
Circles aren't much harder:
The above does a 10 meter circle ($dist2 is the square of your distance from the center of it).
Values without $ need replacing with constants.
You are likely using the default story format for Twine 2, which is Harlowe. The code given above will only function as-is in SugarCube (v1 or v2). Adapting it to Harlowe probably wouldn't be too difficult, but it would have to be adapted. And, for the sake of completeness, adapting it to Snowman should be fairly trivial.
I've created a game using this code (http://blog.patientrock.com/guardian-blue-light-twine/) in Sugarcube 2 and it took a bit of tweaking to get it running. You'll have to spend some time learning what his code does and see where the issue is. It's been a couple months for me so I don't remember exactly-- I think my issue was that it wasn't refreshing the player's coordinates fast enough. Dig around his various projects and take a look at the code he provides: https://electricarchaeology.ca/2015/05/20/low-friction-augmented-reality/