The name is very much still under discussion — I toyed for a while with the name "Outdoor Quest" because it should encourage you get outdoors but perform some kind of quest like in a video adventure game. But it seems there are many outdoor quests already on the internet, from backcountry blogs to pirates in Sussex to various online shops. So the working title is currently "GpsQuest" (or GPS Quest?). Because it only works with a GPS, and it's at least tangentially related to GpsPrune. More name suggestions welcome!
The basic idea is that of a mobile adventure game played on a smartphone, probably offline but enabled by GPS. So you have to actually go out and navigate to the real places in the real world, follow clues, answer questions, solve mysteries and complete the quest.
Obviously this isn't a new idea, and there are examples of similar things being done in connection with geocaches from a certain well-known geocaching website. But for many reasons this half-baked and poorly-supported solution isn't satisfactory, hence possibly the opportunity for a new project.
Firstly, the technical specifications and definitions would be open, to encourage volunteer involvement. Decisions about tools and languages would be based on practicality, not history.
Focus would be on predictable behaviour, effective simulation to ease testing, and elimination of weird bugs and crashes.
Having a geocache at the end of it is not necessarily the goal — sometimes this just appears like an afterthought when the actual "quest" or mission has already been accomplished. Of course, if there's no geocache then there are no bragging rights for number of quests completed, number of quests created and so on, so some alternative would be necessary to stimulate the community participation. But without the official support from the big geocaching website for this new cache type (which they would obviously never provide!), a geocache on that site wouldn't be possible anyway.
Quests could instead be more like an outdoor escape game, with a mystery to solve, a criminal to catch, a bomb to defuse or a spell to cast, a world to rescue or any other kind of satisfactory conclusion. There would just not be a tupperware box at the end to write your name in, which is often superfluous anyway. Or perhaps a quest could be more of an informative tour rather than an adventure game, with information about aspects of a city or a series of audio files (commentary on the architecture, history, local myths, legends or songs?) attached to physical locations. Maybe there is scope for linking up with existing audio tours, food trails and so on.
Currently I'm thinking about probably not online, probably not indoors, and probably Android-only.
Starting from scratch and attempting to compete with a massively popular behemoth is of course a challenge. But the steps towards it could look like this:
There are more details in the roadmap, including the current status, and the latest code is published in the repository on github.
What's still unclear is whether and how any of this generates any income. Is all of it open source and wholly reliant on fellow volunteers? Who pays for the hosting of the quests and for the submission of the Android app to Google's App Store?
At the beginning, with zero quests available worldwide, the app is worth nothing and nobody will pay money for it. Also, other developers won't be willing to help if it's not a free, open-source product. As more and more quests become available, maybe eventually the app becomes worth some amount of money, but only if it becomes well-known and popular. And the quest authors are then doing all the hard work of creating cool quests, so how do they get rewarded appropriately? Do we then get stuck in the uncomfortable mire of basic apps and premium apps, or basic quests and premium quests which you have to pay for? Or an app which lets you run one quest for free before you have to pay to be allowed to run a second?
Or alternatively could it work on a kind of licencing model, so free content from volunteer authors run for free on a free app, but if a tourism authority or a city want to provide some kind of tour, then they have to pay to be allowed to create a quest? Which would of course then run freely on a free app? Or a business like a "Food Trail" which is charging people directly themselves, could they be persuaded to pass on some of that cost if they're taking advantage of the quest app? But if we went that way, then it starts to look more like a business model competing with other businesses rather than a community project looking for a way to cover costs.
Oh, and just to make it clear — no, there will be no ads.
Currently there are far too many open questions and a huge list of complex tasks, some of which with completely unknown technologies to be integrated. At least the starting point is fairly clear, so some progress on the file format can be made without knowing the end destination. Perhaps some enthusiasts could be inspired enough to join in?
One big unknown is whether an iOS version of the app would be possible or not. Currently it seems that producing and publishing an Android app is possible and even encouraged, but developing for iOS is made impractical by the deliberate hurdles (both technical and financial) put in place.
Phase zero is to define the basic concepts with which the quests are defined, so here is a first draft of what the file format could look like. (Spoiler: zipped xml)
An open question is how you can manipulate or combine the virtual objects which you collect on the way. At the most basic, a modified <Scene> is activated depending on the variables' values, so that additional actions or options are available, selected by multiple choice. Hopefully that's sufficient, at least for the first version.
The current idea is that no code-writing is required to author a quest, so that means no lua or javascript. Instead, the whole logic is defined by the xml. Another restriction is that no concave polygons are allowed, only convex ones, in order to simplify the calculations whether you're inside or outside the zone. If you really need a concave polygon, you can define multiple convex ones and assign the same triggers to each. Similarly, instead of allowing complex combinations of logical OR and logical AND expressions, all conditions are always evaluated with AND. If you need an OR, just define separate Triggers for each case and do the same thing for both.
Perhaps on the simulator but definitely on the mobile app, it would be nice to have a map view to help you navigate to the next place or zone. For the mobile app, this needs to be rendered using offline maps, including showing the current position and additional markers for places or zones. Probably there's some open source library available to make this easier.
It's not yet clear whether there is always a single next goal to navigate to, or whether there could be a list of targets from which you can select one. Maybe there are side-missions which can be completed in any order?
It should always be possible to pause a quest, save the current status, and resume it at some other time. Maybe the progress is even automatically saved? And if you need to, you should be able to ignore the saved state and start again from the beginning.
What will be saved is just the values of all of the variables, and the currently selected target. That should be enough to restore all your collected items, activated objects and visited places. Then you can resume, navigate to the target, and continue where you left off. It could also store the timestamp where you paused it too.
How that information is actually saved is still open, but it might be convenient to use Xml for this as well for consistency, or maybe json. The file would of course be tiny, and wouldn't need to be viewed or edited.
Additionally, a completion file could be stored to keep track locally of which quests have been completed and which ones are incomplete. That could also be xml (or json), and only stored locally on the mobile device. Eventually that would be replaced by some online stats for bragging rights, but that would then require a discussion about logins, passwords or certificates or challenges, registration and all that stuff.
The simulator would run on a PC and wouldn't necessarily have to replicate the view on the phone exactly. In fact the first version will probably look absolutely nothing like a phone and will probably be very very basic, with more technical logs than fancy graphics. More importantly it would allow you to see all the variables and log what is happening to the triggers, timers and scenes as they happen. The controls and appearance could be extremely rudimentary at the start, perhaps even without any map display or even coordinates.
Also the quest inspection tools and validation tools would start off extremely basic (simple CLI commands) to see if there's any need to make them more fancy. The important part for that tool is just validating whether a quest is properly defined or not.
If everything is open source, the software is free and every single quest is free to copy, distribute and edit, then there's no need for any encryption to protect anything. But if you want to ask for payment, restrict access to those who haven't paid, and limit the execution of unauthorised quests, then maybe some encryption would be necessary. I can't currently imagine it getting to that.
Once it becomes possible to log quest completions online then you of course need usernames and authorisation tokens and passwords and so on, which will need proper handling. Maybe the phone just generates an RSA-keypair and uses the public key as an identifier, then there's no password to remember.
The same goes for quest authors too, who will somehow authenticate before uploading their quest. And how are the quests reviewed to make sure there is no dodgy content inside? Can quests be flagged as dubious, can they be banned, can the authors be banned? Don't know.
If the Quest file can be easily opened, viewed, inspected and even simulated, then there's the possibility that people don't even bother to complete the quest in the real world, but just get the information they need out of the simulator. It depends how much of a reward there is for completion and how much temptation that offers for abuse. But I currently don't think it will be necessary to prevent quests from running in the simulator, as such a mechanism could probably easily be circumvented anyway.
One thing we haven't got yet in the currently documented file format is any kind of inventory of the objects you've managed to collect so far. It was originally thought that this would just be handled by the variables, so if you've collected item X then the associated variable is set to 1. The explanation of this and the description or image of the item can be handled by the Scenes. But. It was later realised that a very interesting mechanic emerges when the player has the ability to combine items in their inventory to create a new object — for example, combining a stick you found with a length of string in order to create a fishing rod. Or a magic wand combined with a frog makes a Prince character appear.
For this to work, the player has to be able to select any two (or more?) items from their inventory and request that they should be combined, and there doesn't really seem to be a way to do that with only variables. So one proposal is that the Quest definition be expanded with an optional list of Items which might appear during the Quest, and definitions of the allowed combinations and their consequences. The Quest simulator would then keep track internally of which items have been collected (and would be able to save and load these too, as part of the state save). And importantly there would be some way to trigger a combination of items, independent of entering or exiting zones. Acquisition of items would be defined by triggers, and combination triggers would normally cause items to be removed from the inventory too.
Currently, however, these are just suggestions and obviously they wouldn't be needed for simple races, informational tours or games.
Especially at the start of this project, there will be an extremely limited number of Quests available to try, presenting a hurdle to adoption and authoring. In line with other similar projects, the intended workaround is that some Quests may be specified to be location independent, and can therefore be attempted anywhere in the world.
The way this will exactly work hasn't been defined yet, but presumably you'll go to your nearest open park or sports ground where there is plenty of space to wander around, and then tell the Quest that you want to attempt it at the current location. All the coordinates would then be shifted so that the zones lie within a reasonable radius of the start position.