There are many things which have to fall in place before GpsQuest becomes a real thing. This roadmap is an attempt to draw up the order in which the pieces need to be developed.
Here the basic concepts are defined and described, the basic file format and at least the beginnings of the xml structure are laid out. Very little (if any) code will be written in this phase. At the end of this phase, a quest can be manually created but nothing can be done with it yet, except performing very basic validation using an
Status: done ✓ the basics are now defined, and so even though some aspects (such as images and audio) will be added in later phases, we can probably say that this phase is now complete.
In this phase a java CLI program is written to run on a PC. It will load a quest file according to the defined specification and perform a variety of validation steps, issuing warnings or errors as appropriate. At the end of this phase, the validator will be published to allow authors to identify and fix errors in their quest definitions.
Status: done ✓ a
quest_core module provides the basic implementation of loading the quest files, and this module will be re-used by the simulator in a later phase. Additional validation is performed in a separate
quest_tool module which may later go beyond simple validation to provide other authoring tools. The code so far is available in the public repository on github, and there's a quest_tool.jar for those who want to play with it.
In this phase a (very) basic simulator will be written, also to run on a PC. It will not look anything like a smartphone app, but is only intended to be used by authors for their testing of their quest files. It will re-use the
quest_core module and add logging and inspection abilities, and maybe a (very) simple GUI for simulating entry into and exit from the defined zones.
At the end of this phase, a simulator will be published (here and probably also on github), so that quest files can be easily debugged and fine-tuned. Still no smartphone code though.
Status: In progress 🚀. A
quest_sim module will form the basics of the simulator, re-using the
quest_core module. The first steps will make the framework for the GUI and provide language support.
In this phase some example quests will be published to demonstrate how to implement common functionality in quest files. These will serve as documentation to help authors achieve what they want, and practice with the simulator.
This is the phase with the largest unknowns. We'll start with a basic "Hello World" app for Android and run through some simple tutorials with the Android SDK, then integrate the
quest_core module and start loading quests. Then we'll slowly build up the application including menus, settings, loading and saving, and multi-language support. Then we'll figure out how to read positions from the GPS receiver and hook that in to the already existing Quest logic to get things working.
At the end of this phase, there will be some kind of Android App which can be installed somehow (but not yet via any Store), and with basic functionality (but maybe not yet with maps or other optional features). Quests will be loaded only from the file system, so they'll have to be saved manually and/or copied to the correct place.
In this phase the details of the location-independence of quests will be finalised, so that it will be possible to "relocate" a quest to the current position. This will make it easier to run the example quests in any sufficiently open place in the real world.
In this phase the app will be polished to meet Android's requirements, such as specifying permissions, error-handling, packaging, naming, and other such details. This includes handling different Android versions, handling different screen sizes and handling different languages, if that hasn't been done already. At the end of this phase, the app will be in a form which can be published and installed "properly" on any suitable smartphone, and can run quests which have been manually downloaded.
In this phase some kind of online database of quests will be published, probably on this website. At this point the website will provide the main source of quest files to run, but the smartphone user will still have to use a browser to download the files.
In this phase some mechanism will be provided so that volunteer authors can submit their quests for publication. Maybe there's some kind of review, definitely at least a validation step first, and this will probably be fairly manual at the beginning. Here is where we see how much interest there is already from authors.
In this phase the app will be provided with a way to directly access the online quest database, instead of using the website. Given the current location, or another location, you will be able to search for quests in that area, and directly download them without a browser. Especially in the beginning, we'll be relying on the location-independent quests a lot here.
In this phase the app will be provided with a way to submit quest completion details back to the website. I don't know what kind of user registration / profile / login details will be required here, but there needs to be a way to register that a user has completed a quest. Also the date on which it was completed, maybe the quest duration (if it's a quest against the clock) or some kind of score (if it's a quest to collect as many items as possible). Then the website can start to show which quests are the most popular, maybe also how many "likes" each quest received etc. Maybe also a leaderboard of which quester has completed the most quests. Probably you can't give a "like" to every single quest you do, so maybe you have to complete a certain number before you can award one.
By this time there may be a need to speed up or automate the quest submission process, to reduce the manual review time required. It depends on how many are being submitted and how much time it costs to validate, review and publish to the database.
It may be that somebody has already started making a build tool by this time, as the specs will have been open for some time. If there is sufficient author interest, then some kind of PC-based, GUI tool for building quests would really help the less technical authors. If there isn't such a tool already, then start making one. It should probably be java, to fit in with the other tools, and it should probably rely as much as possible on pointing, clicking and connecting rather than typing too much. It probably shouldn't even show any xml, just quest objects, and then the save button produces a complete quest file.