Feature Expansion for Smart Phones

[+ATXTracker]

Admittedly I'm a little out of touch with everything that is going on in Wherigo. I own one Wherigo cache, but haven't kept up with news.

 

Question: Has there been any thought to adding functionality into the builders/players. Since the best builders and players are third parties, and since the lua language is not a proprietary Groundspeak thing, is it possible to build new features into the builders and players without Groundspeak's help? Would their compiler still work?

 

Specifically I'm thinking about the ability to make a web request to a URL and get a value back. If this were possible, then the gates would open much wider on what is possible. You could send messages between players, and or save/share state between games. You could see or not see other players based on their actual location.

 

The cartridges would have to either be only playable on phones, or have a degraded experience.

[+ATXTracker]

something like this perhaps...

http://w3.impa.br/~diego/software/luasocket/

[Ranger Fox]

Lots to discuss on this topic, but it borders on what I've been discussing with Groundspeak.

 

I admit that, over the years, I have had thoughts and desires about continuing Wherigo development without Groundspeak's involvement, same as what you mention. To make it a reality, I needed to have a demonstrable working version of a Wherigo Player, preferably in C# because that's the language in which I am most comfortable. Fortunately for Groundspeak, I've been busy and distracted by my other personal projects and geocaching activities, mostly the latter. Since I'd need a Player and emulator that would work with current cartridges before I even started, just getting to that point would take a serious commitment in time. Had I had something up front without having to get that far, I would have gone with it as a proof of concept.

 

I've already come up with a lot of ideas you'd probably suggest. All this was detailed in a document I provided to Groundspeak, at their request, a few years ago. Web services was just one thing. Among the others are multimedia (especially video streaming), Player skinning, cartridge state sharing (as part of a larger social playing initiative), save file management, and a badge/trophy system that would be central to Wherigo just as geocaching finds or the Waymarking grid is to those activities. An API was a given. I have a very good vision of what I want to see within Wherigo. I know I've mentioned some of this already.

 

All this, I've been told, has been discussed at several Groundspeak meetings since mid to late spring, especially what I put forth in that document. I have been hearing things out of Groundspeak as of late, but it's all ideas and intentions, nothing concrete--and that's the only type of news I intend to share with the community. Why? The Geocaching Challenges is my case in point. If you were to listen to the initial ideas and intentions, you'd have thought virtuals were coming back in all their glory. However, the end result was quite different. And, frankly, if I can't get them to fix that completion code issue, I can't quite trust anything else. (It would be funny if everyone got together and emailed Groundspeak about the completion code issue on one day, overwhelming their mailbox.)

 

-----------

 

I need to mention a little about how I understand Wherigo Players work. The Player runs a lua virtual machine and makes certain objects and method calls available to the cartridge. Certain other things are made available to the cartridge through the require "Wherigo" statement made at the top. If you want to create a zone, you instantiate it and the Player becomes aware of it. Showing a message box or requesting an input will call the appropriate exposed method within the Player.

 

If you want to make a web service call, this should also be done in the Player, with it exposing a method that takes in a web service URL, parameters, and a callback to use when the call completes.

 

I remember someone at Arlington National Cemetery contacting me around 2009. They have a site set up that offers a guestbook and information for each grave. He was interested in using Wherigo to search for the graves, navigate people to them, display the information, and allow interaction with the guestbook. If I could define the UI with Wherigo functioning as a back end engine, this would be ideal. Considering Arlington easily has thousands of markers, only a web service call to a faster computer and database would be efficient enough to perform the search. Also, the guestbook feature would need to be interactive and current, so a web service call would be a must.

 

As you can tell, I'm leaning towards Wherigo being a flexible platform where, if needed, you can hide its default interface and implement a new one. No need to show parts of the default UI if you're not using it.

 

-----------

 

Yes, the community has control of the Wherigo Players and Builders. A Player for Magellan devices may also join the list at a later date. Groundspeak has the site, compiler, and control of the iPhone Player (how much I've never asked). The compiler is what concerns me. We should be able to put whatever we want within the author script and author directive sections and there's a fair chance it will still compile. I guess we can also define a global cartridge skin within the author directive section, though this isn't quite how I'd like to see this feature implemented. Anyway, as long as the cartridge compiles, it's fine. The moment the community reaches the point where we need to modify the compiler, things will start getting interesting. If the compiler needs to be modified, the cartridge cannot be hosted on Wherigo.com and we'll have to create our own listing service (I'm not worried about constructing the web site because I'm a web developer). And a new listing service will put Groundspeak on edge and, perhaps, even against the community. The compiler would be the limit.

 

For a community effort like this to work, everyone who has created a Player and Builder would need to be on board. Those that have created a Wherigo Builder are the least concern, mostly because I don't foresee a problem, but also because such an initiative does not initially hinge on them. It's the Wherigo Player developers that I'm concerned about. As far as I am aware, the Android Player is left as-is without a developer. The iPhone Player is either fully or partly owned or controlled by Groundspeak. I don't know if spstanley can modify the source, fork it, or even if he can create a second Player from scratch (non-compete agreement?). I think matejcik is up to the challenge, though. In short, if we can't get the Player developers to implement these features, the initiative will die.

 

-----------

 

I would love to see more activity with Wherigo, though.

[+Afterburned]

The first place to start in Wherigo is (IMHO) getting it simpler for new carts to be written.

Forget the nice-to-have features, we need a REALLY simple builder for people who are not programmers to use. It really is hell to develop a cart with any of the current builders (I am in IT but not a developer).

 

Once we have as many Wherigo's as Multi's THEN we can put pressure on Groundspeak for new features.

[Ranger Fox]

Well, I suppose I could continue developing Wherigo\\kit or get others in on it. In my opinion, that Builder is the easiest because it's intentionally very limited. It's supposed to serve as a gateway to the other Builders and not as a full Builder in its own right.

 

If you're pushing for web services, this will require someone with programming expertise and a site to host the service. As far as I know and can visualize, some of the advanced things you can do with Wherigo can't be made using a Wherigo Builder. And there isn't a way to get a Builder to make those things outside a kit-based approach.

[+charlenni]

Did you see the numbers about Wherigo? You could find them at http://www.das-Wherigo-handbuch.de/index.php?title=Statistiken_zu_Wherigo-Caches. They are in german, but the values are clear: 2475 Wherigos with Geocache. Why should someone develop new features for such a small market? If there wouldn't be the enthusiasts, which develop builders, players and provide beginners with informations, Wherigo would be dead.

 

In the last 5 years, the community developed great things: two builders, players for nearly all platforms, accented characters for cartridges, multi language cartridges, different wikis for informations. And what did Groundspeak in the meanwhile? They didn't correct the bug with the completion code. One line of code, to shorten the code from the edit control to 15 characters. Shame on you Groundspeak.

 

@Ranger Fox: Sorry, but each line of information you write for Groundspeak about Wherigos is one line to much. They didn't want to do anything with Wherigo.

 

What we need are good ideas for new Wherigo cartridges, good designers and developers for interesting games. And if we have much more cartridges than now, we could think about new, much more difficult to handle technics.

[+St.Matthew]

It's a bit off topic, but since half or more of Wherigo players use a smartphone, I've thought it a cool idea to use the functions of a smartphone: scanning barcodes and QR codes, shaking the phone, tilting the phone in various directions. This could be incorporated into a Wherigo cartridge. Buuut no Garmins.

[+sTeamTraen]

The coolest feature of a smartphone is surely a data connection. You could have interactive multiplayer games, or partly/entirely server-based cartridges, etc etc.

[Ranger Fox]

Why should someone develop new features for such a small market? If there wouldn't be the enthusiasts, which develop builders, players and provide beginners with informations, Wherigo would be dead.

You develop features for such a small market because the small market will give you good feedback and test the features in ways you wouldn't have come up with during development. This small market, by creating cartridges, will demonstrate the technology. Businesses looking to implement a tour guide or training/team building exercise might be interested in using the technology if they don't have smartphone development experience or need a fast turnaround. I know there was one business interested in the latter around January 2009. This is one avenue of revenue.

 

@Ranger Fox: Sorry, but each line of information you write for Groundspeak about Wherigos is one line to much. They didn't want to do anything with Wherigo.

Yeah, it is difficult to remain positive, but at least I try to be respectful. The community doesn't hear anything and everything I hear doesn't yet have a tangible deliverable. Still, I consider it my unofficial responsibility to go back and forth between the community and Groundspeak, though it really does seem more one way than the other these days. I hope, at some point, it'll be a two way street and I can bring some announcements back.

 

What we need are good ideas for new Wherigo cartridges, good designers and developers for interesting games. And if we have much more cartridges than now, we could think about new, much more difficult to handle technics.

I fully agree with what you're saying. I don't develop near as many Wherigo cartridges for my home area as I should, usually because I can't either think of an idea for a place or find a place to put one. Like many, I'd prefer to tie my story very closely with what's in an area. I've said time and again that if someone has an idea for a cartridge--especially an arcade type cartridge like Whack-A-Lackey and Battleship--I will create it for them if they're unable.

 

 

The coolest feature of a smartphone is surely a data connection. You could have interactive multiplayer games, or partly/entirely server-based cartridges, etc etc.

Oh, yes. Very much so. I really want to capitalize on multiplayer cartridges. That and the Wherigo API.

 

 

I would like to point out the more complicated and technical a feature, the less likely you will see it in a cartridge. For instance, if it's possible to make web service calls with Wherigo v2, not everyone will be able to set up the other endpoint or have a place to host it. However, those that correctly make use of this feature will be able to make some really neat cartridges. This is especially so with skinning the Wherigo Player.

[+charlenni]

We talked about all this some time ago (http://forums.Groundspeak.com/GC/index.php?showtopic=239796&st=0&p=4399958&hl=charlenni&fromsearch=1entry4399958). In the past two years, only one thing happend from side of Groundspeak: they bought the player for iPhone. With this deal, they achived two things:

1. The development stagneted. Last version is from 2012-01-28.

2. They bought the iPhone player, but no other. I'm sure, they discourage the other developers.

Sorry, but I don't think, this is the right way to show us, that Groundspeak is interessted in Wherigo.

 

You are a web developer. Do you think, it is such a horrible thing to shorten each completion code to 15 characters?

 

Btw. I didn't think, that integrating new things with the old compiler is a problem. But the players had to support them.

[Ranger Fox]

You are a web developer. Do you think, it is such a horrible thing to shorten each completion code to 15 characters?

Yeah... I suggested several ways this could be fixed: the root cause, using the same completion code generator for validation, trimming long completion codes before validating them, or even having a script do the trimming right before the form is sent to the server. Either way would work. I strongly encouraged using the third suggestion as this would have the least impact on their code and how cartridges are generated. Every time I have a phone meeting, I make it a point to remind them.

 

Btw. I didn't think, that integrating new things with the old compiler is a problem. But the players had to support them.

I'm not certain how they have the compiler working, so it could either be something easy to do or a pain. From what I understand and anticipate, it should be easy to do. You are right, though: the Wherigo Players would need to support the new features.

 

It almost seems like Groundspeak's acquisition of the iPhone Wherigo Player was a step backward for the community. Due to this, we'd have to have another Player of our own on the iPhone if we wanted to take over development of Wherigo.

 

We've all talked about it before, but if Groundspeak could fix or add a few things on the site and the iPhone Player, what would you like to see first? Here's what I could think of off the top of my head. Please add to and critique it.

• Connect a cartridge's visibility status with the associated geocache's. Add a link in the cartridge details section. When the cache is archived, remove the cartridge from the list and do not make it possible for the cartridge to be downloaded. This is a safety concern.
  
• Delete unpublished test cartridges from our account list.
  
• Search for open source cartridges.
  
• Hide cartridges you've completed from the list and note which ones are completed when shown.
  
• Add "mi" as a unit to the iPhone Player so the computed distance is not in meters. Also, fix the distance calculation to match the Great Circle Calculator.
  
• Add the ability to select whether to save a cartridge's state on close and whether a cartridge's state should be saved automatically as you go along.
  
• A basic Wherigo API for listing and downloading cartridges, plus the ability to log completed cartridges on the device. Allow Wherigo Builders like Urwigo and Earwigo to upload and manage a person's cartridges. Give all third party developers access and not just the iPhone Player.
  
• Wherigo cartridges shown on a map, or a link to go to geocaching.com's map with only cartridges displayed (this would be less work, I think, than integrating it into Wherigo.com).
  
• Add a shortcut to view an author's other cartridges.
  
• When only the country is listed, use the coordinates to guess the state/province/etc. Or, for heaven's sake, when the cartridge list says "Utah", don't say "United States" in the cartridge details screen.
  
• Email the author when someone marks a cartridge as complete or writes a log.
  
• Show the list of people who have completed the cartridge and their date of completion.
  
• Remove the price copy from the listing's details until a market system is established, if one ever is.
  
• What about non-English characters in cartridges?
  
• Apply the same look and feel to the iPhone Player as the geocaching app.
  
• The completion code issue is a given.
  

[+charlenni]

Wow! What a long list of things, which are nice to have. Glade to hear, that other also think, that the progress of the iPhone player stops.

 

I think, to get the completion code workaround is very important. Not only for usability, but also to show the developer out there, that Groundspeak is furthermore in the boat. If they don't manage to do this, all other ideas are useless.

[matejcik]

one:

the Android player is currently without maintainer, as RangerFox said. It is open-source, but without the maps component, which is sort of a big deal. If a volunteer were to step up and implement a maps component based on some opensource OSM implementations, that would be very cool. I'll do it at some point in the future, but that point seems to be pretty far away.

If any of you want to dabble in Android development, this is a great place ;e) The original maintainer designed the app pretty well and the maps component should be easily pluggable. He also told me that if someone updates the app, he is willing to publish the updates under his account, to follow the update path.

The OpenWIG core engine can be dropped in without modifications. At this point the one in WhereYouGo is somewhat outdated.

 

two - an app developer's perspective:

 

I'm reluctant about giving cartridge creators too many options. The player apps run in a limited-resources environment as it is, and by becoming a "platform" in itself, we would at some point have to solve the same problems the creators of Android and iOS are solving for "native" apps. One simple example is data usage: what if you want to conserve your data by not using the online maps, or precaching them on a WiFi, and then the cartridge just goes straight ahead and downloads a 500kB page every two seconds just to parse some status from the middle of it?

Obviously, if you were concerned about data usage, you would turn off data on the phone (and we haven't started talking about streaming yet, where this all becomes moot anyway). Still, this is exactly the kind of thing that would happen sooner or later. Not to mention that parsing a 500kB page in embedded Lua is not something you want to do in the cartridge anyway.

 

Now there are two approaches:

a) FORBID EVERYTHING

accept that this is the way things go in the real world and give them creators enough rope to shoot themselves (and their users) in the foot

 

I will strongly object to just dumping LuaSocket or similar straight into players. For one, it's not asynchronous by design. That is something that's an absolute requirement in Wherigo, otherwise Horrible Things Will Happen.

At minimum, we need an api that works like jQuery's AJAX: instantiate a request, associate callbacks, go merry on your way until they .. um ... call back. (notice that it is very similar to how GetInput works, by the way ;e) ) I'd go even further and say that the response must be a properly formatted JSON string no longer than, say, 4096 bytes.

 

Yes, there is a third, hybrid approach: carefully measure the length of rope given out, so that if the creator tries really hard, they can still shoot themselves in the foot, but probably not repeatedly. By which i mean, very carefully designing an API that can, by applying enough pressure in just the right places, be convinced to do the evil things I speak of, but is generally hard to abuse otherwise.

Designing this is a fun way to spend time, but to do it right is hard. As in, HARD. And I'd like to point out that the designer(s?) of Wherigo API did a very decent job, but we now know that they didn't get it completely right either - the nonsense that is Distance class is one example, the horrid mess of saving cartridge state is another.

 

oh and three:

 

Most people who create cartridges are not programmers, and they often have a hard time. The existing builders are lowering the barrier to entry (which, btw, was completely artificially set to absurd heights by how the original Builder generates sourcecode - if the API itself is a perfectly respectable job, the way Builder works with it and compiler compiles it is a horrifying vortex of chaos and discord, brought forth by an ancient and unspeakable evil from the eldritch dimensions. And i really mean that, too. I have a hard time coming up with ways to design it any worse) by presenting a nicer (by which i mean "actually usable") UI, and helping along the way, but they are no help at all when it comes down to the original issue that most people who create cartridges are not programmers.

 

Great job with RangerFox's Wherigo\\kit, by the way. That is the direction builder apps should be heading, IMNSHO. Take notes, folks ;e)

 

(whoa, i'm even more opinionated than usual. heh.)

 

But. The point is what Afterburned said. Unless we have a simple and usable builder for everyday people, we can play around with cool features all we like, because we'll be the only ones using them.

 

four:

 

Speaking of some sort of web-retrieving API, i think the best way to do that would be to have a dedicated server providing a limited set of online-enabling features for cartridges, and simple built-in calls in the API to talk to this server and this server only. (with possible advanced interface somewhere under the hood). That way you could have an online-enabled experience created completely inside some builder.

Just a thought. I haven't even started thinking about what exactly would this server have to do.

 

and five:

 

Given the current state of technology, i don't think it's impossible to have server-side cartridges anymore. THAT would be an interesting development.

[+sTeamTraen]

Connect a cartridge's visibility status with the associated geocache's. Add a link in the cartridge details section. When the cache is archived, remove the cartridge from the list and do not make it possible for the cartridge to be downloaded. This is a safety concern.

Safety: Meh. And if the cache is archived, people generally won't be doing the cart. (But if Wherigo caches are to be done seriously, there needs to be a structured way to include the cartridge link, not just overloading the "Related Web Page".)

 

Add the ability to select whether to save a cartridge's state on close and whether a cartridge's state should be saved automatically as you go along.

More generally, allow management of N timestamped saved versions of a cart.

 

What about non-English characters in cartridges?

Already available with Earwigo ), except in the cartridge's Description and StartingLocationDescription fields (because the re-compilation process requires those to be Lua long strings).

[+charlenni]

First of all, it's nice to hear from you, Jan, and that the development of OpenWIG is going on. That are really good news.

 

You could find a system with server side cartridges at www.geolua.com.

 

I saw RangerFox's Wherigo\\kit the first time. For beginners, it would be enough and if you want to make something more complicated, you could import the cartridge into another builder. Good job. I saw the Groundspeak demo cartridge. Did you show it to Groundspeak? What did they say?

[Ranger Fox]

You could find a system with server side cartridges at www.geolua.com.

That's very interesting. And it also includes a multiplayer aspect. The problem with it being online, though, is you limit yourself to places with cell phone coverage. While some of the nice things I'd like to see with Wherigo would be online-only, it's nice that, in places without cell phone coverage, you can still create a cartridge as long as you don't use the online-only features.

 

I saw Ranger Fox's Wherigo\\kit the first time. For beginners, it would be enough and if you want to make something more complicated, you could import the cartridge into another builder. Good job. I saw the Groundspeak demo cartridge. Did you show it to Groundspeak? What did they say?

I created Kit in more or less one week as a demo for Groundspeak to illustrate a point I was trying to make about what can be done to eliminate the steep learning curve. I received a few words in reply, saying they were impressed, but that's all. I've gotten some nice reactions from the few people I showed it to. I added Kit to my signature line in the forum and didn't say anything else because I knew continuing to develop it on a regular basis would stretch me too thin. Supposing I spend less of my free time geocaching, I would be able to allocate more time to developing my various personal projects. (But I've almost found 10K in this year alone, so why slow down?)

 

I do agree that adding certain functions to the Wherigo Player might require cartridge authors who are more into programming to use them. Consuming web services is a good example to cite. Most people wouldn't have a use for them in a cartridge. However, if you can think of any reason to connect to a database online or a server that creates images on the fly, it make sense. I've already mentioned Arlington National Cemetery in a previous post, and that's a good database example. Another reason for a web service, one that creates images on the fly, is something I see benefiting those making puzzles and mazes. It also reduces the cartridge's size, even if you only use the server to store and retrieve static images.

 

That said, I can feel free to contradict myself quite nicely. Some Builders might find a nice way to implement some of the complex functionality. For instance, if it's a database back-end the person wants, the UI could present the person with a DB designer or import an MS Excel file. For streaming video, a simple link to a YouTube video wold suffice. Assigning badges or trophies would be easily done as well: define which badges are in a cartridge, then allow the user to select the badge name somewhere during play just as if you were setting a variable or saving a cartridge. Of course, the badge system would be a little more complicated on the back end because it would have to interact with the Wherigo API to apply for and register badges, receiving the badge GUID (or badge list) upon its return. A badge/trophy system would require some oversight because not all cartridges would have the same number of badges and this could become a point of contention. For instance, a go-here-answer-this cartridge would only have three possible trophies: completion, completion within a specified time limit, and perfect answers. A cartridge like Battleship would have more: completion, completion within a specified time limit, all ships sunk using only the small ammo, sinking multiple ships at once, and never missing (a perfect game).