Jump to content

Wherigo v2: Feature List


Ranger Fox

Recommended Posts

Wow, that's a long list😯. I'd love to help, but with my current knowledge, I can only help with the website's UI.

 

7 hours ago, Ranger Fox said:

Game saves - Not only are they stored locally, but they'll automatically be backed to the server so you can access them across devices.  Authors will be able to save any type of serializable object to the game save storage.  An author can access game saves from other cartridges where they're a contributor.  This will allow state to be carried over to other cartridges.

I don't think, that the storage at the Server is required. I often hear at events that one of the advantages of wherigos is that they can be played offline. So I think we can live without that. But of curse it's a nice to have also for v2.0 or 2.1

 

7 hours ago, Ranger Fox said:

Video - Do we want streaming from a YouTube link or do we want video files included with the cartridge itself?

Video streaming often consumes a lot of data. We should also allow watching the video offline.

Link to comment

Game saves

- The online game save backup feature does not have to be immediate.  A game save will be created immediately on the device and can be backed up to the server some other time.  This allows you to have access to your game saves across devices.  If you switch to another device, you can resume the same cartridge.  It's a convenience feature.

- As for how we'll work with a different cartridge's game save, it should be understood by the author that such a game save might not exist.  If the cartridge is downloaded and later played offline, this might pose a problem.  Perhaps each cartridge should have a manifest so things like this, online-required play, and other capabilities be declared.  After all, multiplayer would have to be an online-only feature.

 

Video

- I've gone back and forth on what to do with video: 1) should it be a link to YouTube, 2) should I store it on the server and stream it, 3) should I store it on the server and the player app (and user) decide whether to download all assets ahead of time, 4) how much storage space should I allow for each cartridge, 5) should video and other expensive assets be retained when a cartridge is archived, 6) should I convert video to a lower quality if someone uploads in high quality (say, convert to 720p if someone uploads in 8K).

- I have a rather small cellular data plan.  Last year, it was only 2GB/month, but then I was bumped up to the 5GB/month plan because my old one didn't exist anymore.  I don't like the idea of having to stream a video in the field.  But if I have to download a cartridge in the field, I don't like the idea of having to download all assets, either, because my playthrough might not need every single asset.  So, perhaps all assets should be downloaded while on WiFi and streaming be used on cellular (unless the user wishes to download all assets via a cellular connection).

 

Player app

I've also wondered about constructing a player app 100% using Blazor.  Three years ago, I constructed a rudimentary player app using Blazor and a cartridge in C#, just to see what that would be like.  Blazor has changed since then, and the proper way to do it these days would be with MAUI if we were going the .Net route.

 

UI

It would certainly help to have assistance with someone wireframing, drawing out, or constructing the UI for the site.  Doing that and making it responsive would take me quite a bit of time.  If I could have someone better do it, my time would be better spent in creating the back end.  And though I want to do the thing in Blazor, I'm still new to it.  Professionally, every time I was brought in to work on a project, people said a site was using MVC only for me to realize I'm back in WebForms land.  I've done a weird way of making WebForms sites over the past decade, using WebForms only to construct the initial layout and JavaScript and API calls to handle everything else.  An unreleased version of Kit was made using almost 100% script hosted in WebForms (I didn't release it because I tired myself out after the builder portion was created, so I never completed the cartridge listing and login portions).  I've wanted to construct a site using Blazor.  However, I believe the first thing you make from start to finish should be discarded right after you make it because you've learned so much.  Oh, well.  At some point, I'll either construct a site at work using Blazor or a new Wherigo listing site using it.

 

And, yes, a huge amount of work would need to be done to launch Wherigo v2, but a large amount of planning also needs to be done ahead of time.  The question as to which languages a cartridge should use and how it should be packaged is also up for discussion.  That will be sooner than later, but the intended features might likely play into such a decision, so I wanted to discuss features first.

  • Upvote 1
Link to comment

Thank you for laying this all out, Ranger Fox. I think this looks like a really great road map for Wherigo, and I am very excited to see where this project will take us. I’ve been reading through all the old posts and think I understand the plan: basically, create Wherigo 2.0 and we all hope that Groundspeak doesn’t block it again? Please correct me if I mis-understood. If this is the plan, I am concerned since they’ve blocked Wherigo foundation before. Also, they currently rely on the official IOS Wherigo player to pull data from Wherigo.com—this is part of why they blocked the foundation, I think. If we created a new website/player, it seems like it would create a conflict with their player.

 

Are there any discussions in the background with Groundspeak that would show they somehow support or allow this project?  I’m wondering if there could be some type of Plan B in place so if/when all this comes together, the project can continue regardless of how they respond.

 

Link to comment

My biggest requests would all revolve around making Wherigo much more accessible. It seems like so few people can use the Wherigo tools. I would like to see the Wherigo platform become accessible to everyone. I wasn't sure if this is the right thread for all this, so need be please move this elsewhere.

 

 

Simplifying the platform

·        The Wherigo builder is built into the Wherigo website, no more uploading cartridges. Once a cartridge is finished it can be automatically uploaded/published into the database.

·        Cartridges are all listed in the official app. Sort of like the way the new Wherigo IOS app works.

·        Design the Wherigo 2.0 builder to be more user friendly. I’m thinking something similar to the scratch builder with color coded blocks. Built in starting point or messages and final zones. Possibly even connecting lines to show how the cartridge progresses ( sort of like in Wherigo kit. The meta verse augmented reality app also implements this https://studio.gometa.io/discover/me

·        Wherigo templates that players can open and start messing around with and adapting to their own cartridges right away. Question and answer, Lights out, battleship, Whack-A-Lackey, reverse Wherigo, trivia questions, ect. I like the idea of players with no coding knowledge can easily copy and paste a cartridge and look inside it. This was a big part of how Iearned to code.

·        Make all new cartridges open source by default and cartridges can easily be copied on the builder page. Anytime someone copies a cartridge, the final zone information is removed -this would have to be specially designed in the builder. Players can lock their cartridge, if they so wish, but the general idea is to make code much more accessible to everyone. This is what scratch has done and I believe it is a large part of what makes the platform so successful. I recognize there are some problems with this, but it would really lower the barrier to entry if it were a lot easier to see what is going on behind the scenes in cartridges and if it were easier to create cartridges.

·        Media is automatically re-sized and formatted. No more spending hours trying to fit all the media files to the correct specs.

·        Tutorials listed on the builder section of the website. This is something I could help out with. I especially like the type of tutorial where you actually interact with the program your learning to use—manipulating objects in the program as the tutorials tells you what to do.

·        Get rid of completion codes and make completions automatically built into the player and website.

·        Assets in the builder. If a player wants to create a quick and easy cartridge, there are a bunch of royalty free pictures, and sounds already added into the builder page. Another idea from GoMeta.

· Simplify some of the more complex Functions built into website making it much easier to do tricky things like moving objections or say getting the distance to a zone.

 

 New Type of Wherigo

I would say that before we even move forward with Wherigo 2.0, perhaps we should even look at what Wherigo could be in the future. Magnatome mentioned a new user interface with unity. I am wondering if there could be room for something outside of the Locations, Items, Character, Map, and Tasks. I envision something where players could interact with a graphical or 3D page. This could include sprites and allow builders to design the look and feel of each page. Maybe a new type of cartridge for arcade type wherigos like tetris.

 

I really like the idea of a map based Wherigo. This would be especially awesome for building RPG type wherigos where players are battling monsters, finding items, locations, ect.

 

Wherigo Website

 

I really like the idea of a points system for building and playing wherigos. The Wherigo website should feel like a game. Achievements for getting more points. Maybe there is special icons for different types of Wherigo and players get badges for completing special tasks. Let’s try and gamify the website as much as possible. Maybe even add animated graphics say a spinning Wherigo icon when a cartridge is published or fireworks/shooting stars when a cartridge is completed like in adventure lab. I would like the website to be something really fun to interact with and I feel like this is often lacking in other gaming websites. 

 

Stuff for further down the road

· Waymarking and benchmarking integrated into the website adding more games for players to use. I like that idea alot and think we could even add a new spin or game elements to interact with the Wherigo world. 

· Augmented reality – the GoMeta app uses google vision to have your smart phone recognize items in the real world – smile detector, you can program it to recognize specific words, or colors, items, ect. There could be an entire new location-based game where players have to go out and look for and scan locations/objects in the real world. I saw one game where players had to scan text on gravestones to complete an experience.  Check out https://cloud.google.com/vision/ 

  · Skins for the Wherigo map so players could enter into a fantasy or sci-fi setting.

· Players get “credits” for completing or building wherigos. They have virtual bases on the map that can be stocked with items purchased with their credits. Maybe they can show off special trophies for their achievements.  

· Virtual Challenges – basically players can code their own challenge Wherigo which draws statistics from geocaching.com. Then once a player qualifies for a challenge, they would have to visit some virtual location to be able to redeem the challenge. Obviously, this would require a special separate builder, but I think it’s a fun idea.

· Would be awesome if you could create a Wherigo night cache where the clock is based upon the server and not the phones clock (so players can't cheat it).

 

 

 

Link to comment
20 hours ago, Forest-Ghost said:

think I understand the plan: basically, create Wherigo 2.0 and we all hope that Groundspeak doesn’t block it again?

Sort of, except it's going to be a hostile takeover.  The idea is to make something so good that the community will use it regardless.  This will have one of three outcomes: Groundspeak can initiate the partnership this time, ignore everything altogether, or put an end to Wherigo.

 

20 hours ago, Forest-Ghost said:

Are there any discussions in the background with Groundspeak that would show they somehow support or allow this project?

Nope, not after my experience last time.  Hostile takeover.  Besides, I don't even know if there are enough volunteers to pull off the project at this point.

Link to comment

And as far as the other reply:

  • I disagree about integrating the builder with the site, at least from a technical level.  If we had a web-based builder app, we could perform a seamless redirection between both applications.  Besides, with the API in place, the Urwigo builder can also offer a seamless experience.
  • You can use the app to search for cartridges either by the map or any other UI because, you know: API.
  • Templates are a good idea.  I was mostly thinking about smaller snippets, but it's reasonable that someone could build a larger template.
  • I'd rather start with cartridges being closed source because almost all are tied to a final geocache.    I can't simply remove the last zone in a cartridge when it's copied because there isn't a simple way to tell what the last zone is.  Other cartridges simply tell the final coordinates.  I'd rather incentivize open source sharing or say a cartridge automatically becomes open source after a period of one or two years after its last update.
  • I forgot about the media resizing feature.  But, yes, media should automatically fit the view, but should be capped at zooming in 200% to avoid being too pixelated.  Hopefully, it's more about downscaling.
  • Yes, there won't be completion codes because of the API.  When the cartridge marks itself as complete, the player app will send that information to the site via the API when the device has a data connection again (or immediately if it does at that time).
  • Assets get a bit difficult to work with because we'd need some sort of community curation.  Fortunately, someone could create an asset management application and API for builder apps to use.  It does not have to be tied to the listing service's API (really, it shouldn't anyway).
  • I don't have experience with Unity.  However, the player app itself should be able to load different player runtime environments.  This would allow for v1 to work, v2, and anything more complicated, such as something with Unity.
  • Wherigo v1 wasn't map-based because it predated devices being Internet-connected.  These days, Internet connectivity is the norm.  So, the UI should be primarily map-based
  • I'll be relying on others, then, to come up with a good UI for the website.  I can hold my own, but a graphic designer and animator I am not.
  • Perhaps Wherigo Invaders is the perfect way to gamify the site.  I should probably make a long post to cover what Wherigo Invaders is.  You have concepts from travel bugs, Ingress, Munzee, trading card games, and whatnot, and this provides a sort of meta game that gets you to revisit cartridges.

And the other items:

  • If you're considering integrating Waymarking with Wherigo, you'll need to answer some questions.  First: what is Wherigo at its core?  How would including waymarks strengthen Wherigo's core fun factor?  (Waymarking could have been Swarm/Foresqure, but was never developed upon after its release.)
  • How easy would it be for an average Wherigo author to include AR?  We need it to be easier and more enticing to set up Wherigo cartridges.  AR could be explored in the long term, but building a fun core game that can be fairly easy to create content for is a priority.  We need the map to fill up with cartridges.
  • Skinning was on my shorter list.  However, I didn't think about skinning the map itself.  (That is, allow the author to create a map upon which the game is played instead of the satellite or road map.  We'll have to either have map tiles or just a very high resolution, large map file.  That could be doable.
  • Credits and such play into Wherigo Invaders.
  • Challenges would be interesting.
  • I forgot about adding to the player API the ability to query the current time.  Good idea.
  • Upvote 1
Link to comment
On 1/12/2023 at 6:32 PM, Ranger Fox said:

Sort of, except it's going to be a hostile takeover.  The idea is to make something so good that the community will use it regardless.  This will have one of three outcomes: Groundspeak can initiate the partnership this time, ignore everything altogether, or put an end to Wherigo.

 

Nope, not after my experience last time.  Hostile takeover.  Besides, I don't even know if there are enough volunteers to pull off the project at this point.

 

That makes sense, thank you for clarifying. Since HQ requires that all Wherigo caches be listed on Wherigo.com though, I don’t understand how the project will ever gain traction through geocaching if none of the Wherigo 2.0 caches can be listed on the geocaching website.

 

To your second point, It’s hard to ask people to come on board with a project that Groundspeak could end at any time. But if we use a separate platform (outside Wherigo), then we don’t risk Groundspeak blocking the project again, and programmers and developers would be more likely to come on board.

 

Link to comment
On 1/12/2023 at 7:27 PM, Ranger Fox said:

And as far as the other reply:

  • I disagree about integrating the builder with the site, at least from a technical level.  If we had a web-based builder app, we could perform a seamless redirection between both applications.  Besides, with the API in place, the Urwigo builder can also offer a seamless experience.
  • You can use the app to search for cartridges either by the map or any other UI because, you know: API.
  • Templates are a good idea.  I was mostly thinking about smaller snippets, but it's reasonable that someone could build a larger template.
  • I'd rather start with cartridges being closed source because almost all are tied to a final geocache.    I can't simply remove the last zone in a cartridge when it's copied because there isn't a simple way to tell what the last zone is.  Other cartridges simply tell the final coordinates.  I'd rather incentivize open source sharing or say a cartridge automatically becomes open source after a period of one or two years after its last update.
  • I forgot about the media resizing feature.  But, yes, media should automatically fit the view, but should be capped at zooming in 200% to avoid being too pixelated.  Hopefully, it's more about downscaling.
  • Yes, there won't be completion codes because of the API.  When the cartridge marks itself as complete, the player app will send that information to the site via the API when the device has a data connection again (or immediately if it does at that time).
  • Assets get a bit difficult to work with because we'd need some sort of community curation.  Fortunately, someone could create an asset management application and API for builder apps to use.  It does not have to be tied to the listing service's API (really, it shouldn't anyway).
  • I don't have experience with Unity.  However, the player app itself should be able to load different player runtime environments.  This would allow for v1 to work, v2, and anything more complicated, such as something with Unity.
  • Wherigo v1 wasn't map-based because it predated devices being Internet-connected.  These days, Internet connectivity is the norm.  So, the UI should be primarily map-based
  • I'll be relying on others, then, to come up with a good UI for the website.  I can hold my own, but a graphic designer and animator I am not.
  • Perhaps Wherigo Invaders is the perfect way to gamify the site.  I should probably make a long post to cover what Wherigo Invaders is.  You have concepts from travel bugs, Ingress, Munzee, trading card games, and whatnot, and this provides a sort of meta game that gets you to revisit cartridges.

And the other items:

  • If you're considering integrating Waymarking with Wherigo, you'll need to answer some questions.  First: what is Wherigo at its core?  How would including waymarks strengthen Wherigo's core fun factor?  (Waymarking could have been Swarm/Foresqure, but was never developed upon after its release.)
  • How easy would it be for an average Wherigo author to include AR?  We need it to be easier and more enticing to set up Wherigo cartridges.  AR could be explored in the long term, but building a fun core game that can be fairly easy to create content for is a priority.  We need the map to fill up with cartridges.
  • Skinning was on my shorter list.  However, I didn't think about skinning the map itself.  (That is, allow the author to create a map upon which the game is played instead of the satellite or road map.  We'll have to either have map tiles or just a very high resolution, large map file.  That could be doable.
  • Credits and such play into Wherigo Invaders.
  • Challenges would be interesting.
  • I forgot about adding to the player API the ability to query the current time.  Good idea.

 

Thank you for your response. I really like your ideas for a new platform.

 

Templates-- I like the idea of shorter templates as well. Would be nice to get a short snippet to show how to do a question and answer, a timed portion, moving a zone ect.. Currently the templates on the urwigo website are for an entire cartridge and require some digging to find what you're looking for--something straight to the point would be really nice. 

 

I will probably need to get a little more coding savvy, but I may be able to help with a UI for the website. I have spent alot of time designing graphics on my geocache pages with HTML. 

 

I had never thought about doing four square for Waymarking. I'd be curious to see how that would work. Part of my idea is that we could use the concept of adventure labs--where it is extremely simple to build an adventure, but add lots more game types for players to choose from. 

 

I really like the Wherigo invaders concept. Will be awesome to see more game elements for Wherigo.

 

Wherigo Zones -- I am wondering if at some point it would be possible to switch Wherigo zones to become a singe point/coordinate. This would require cartridges to all rely on OnProximity events, but this system I think works alot better than OnEnter. For now, it would be tricky to make a straight switch, as many cartridges use OnEnter events and need a large zone size to work. But further down the road, maybe a transition to single point zone would be possible.

 

Edited by Forest-Ghost
Link to comment

Wow, lots of great promise here. Lots of thoughts, but a couple biggest points came to mind.

 

On 1/12/2023 at 7:32 PM, Ranger Fox said:

Sort of, except it's going to be a hostile takeover.  The idea is to make something so good that the community will use it regardless.  This will have one of three outcomes: Groundspeak can initiate the partnership this time, ignore everything altogether, or put an end to Wherigo.

 

It sounds all nice and good, but if they disallow Wherigo 2.0 to be used for geocaches, it won't gain traction at all; can't even be used as a puzzle. They can simply say "nope" and that act itself cuts the project off at its knees so its only hope is to exist as its own non-geocaching game akin to the game that shall not be mentioned.

 

 

Video/Media:  Perhaps when a user chooses to 'download' the Wherigo, they have options. Seeing how large the media package is, they could:

1. Play online - stream all content as needed (data required is a minimum unless the app caches)

2. Download required media for offline - download media that's required and cannot be skipped, stream the rest if desired.

3. Play offline if possible - seems to me the CO would need to be able to flag whether the Wherigo could even be played offline, or if streaming (or online connectivity) is a required ability.

This allows for optional and required content - including downloadable media, streaming media, or linking to external sources/apps.  Whatever is required to play the cartridge determines the minimal the user has to play.

I could make my game playable 100% offline, or find a way to allow for streaming and give them the option, or may require online connectivity anyway. Creators would be asked to favour offline playability, and mobile reception, but at least they'd have the option to make something that can/must be played with internet connectivity. Much more creativity that way.

 

AR: One BIG benefit to today's technology is that you could incorporate AR already with all the data and assets that are in the cartridge. You've got device location in the world, relative distances, icons, zones, 2d images, there could be a collection of free 3d assets (like stock imagery suggested above), and all the app needs to do is use a toolkit that allows depicting that 'virtual' realm over top of the camera view. I'd say that would be a first stage. Getting more complex than that, like interacting with in-world objects and mechanics, then yeah there could be a whole lot more work :)

How accurate and smooth the 3d rendering is over top of the camera view is something that's been improving over the years (whether the AR kit has image tracking, how much the gps location and compass/orientation bounces and moves without coordinating with the camera, etc)

 

 

Lots of potential... looking forward to see what can be developed!

  • Love 1
Link to comment
23 hours ago, Forest-Ghost said:

That makes sense, thank you for clarifying. Since HQ requires that all Wherigo caches be listed on Wherigo.com though, I don’t understand how the project will ever gain traction through geocaching if none of the Wherigo 2.0 caches can be listed on the geocaching website.

 

To your second point, It’s hard to ask people to come on board with a project that Groundspeak could end at any time. But if we use a separate platform (outside Wherigo), then we don’t risk Groundspeak blocking the project again, and programmers and developers would be more likely to come on board.

Yes, that makes it challenging.  But no one said we couldn't create a dummy cartridge on Wherigo.com that tells people the cartridge needs to be downloaded elsewhere.  (A bit of a hack, but whatever.)  Again, the idea is to produce something so good that the community will use it regardless of the geocaching guidelines, so much so that it forces Groundspeak to make a decision: partner with the group or close Wherigo.  I'm hoping the former.

 

If we create a separate platform, we lose the geocaching audience, must build our own audience, and will not be able to discuss it on this forum.  At the moment, my interest lies in fixing Wherigo so more people can enjoy it.  "Fixing" also means "adding more features" so people can enjoy it.

 

I believe it's going to be difficult regardless to get enough people on board.  We can start off trying to make a better Wherigo experience, then spin it off as something else if it's fun and a partnership fails.  You might not be able to do it the other way around.

  • Upvote 3
Link to comment
23 hours ago, Forest-Ghost said:

Templates-- I like the idea of shorter templates as well. Would be nice to get a short snippet to show how to do a question and answer, a timed portion, moving a zone ect.. Currently the templates on the urwigo website are for an entire cartridge and require some digging to find what you're looking for--something straight to the point would be really nice. 

 

I will probably need to get a little more coding savvy, but I may be able to help with a UI for the website. I have spent alot of time designing graphics on my geocache pages with HTML. 

 

I had never thought about doing four square for Waymarking. I'd be curious to see how that would work. Part of my idea is that we could use the concept of adventure labs--where it is extremely simple to build an adventure, but add lots more game types for players to choose from. 

 

I really like the Wherigo invaders concept. Will be awesome to see more game elements for Wherigo.

 

Wherigo Zones -- I am wondering if at some point it would be possible to switch Wherigo zones to become a singe point/coordinate. This would require cartridges to all rely on OnProximity events, but this system I think works alot better than OnEnter. For now, it would be tricky to make a straight switch, as many cartridges use OnEnter events and need a large zone size to work. But further down the road, maybe a transition to single point zone would be possible.

 

Let's use the term "template" to refer to something cartridge-wide, such as a template that allows you to create a Whack-A-Lackey game, and the term "snippet" or "action snippet" to refer to a small piece of code that allows you to do something.  Moving a zone won't be a snippet, though, because it should be a method call within the Wherigo Player API.  A snippet could be as simple as "ask a question over and over until the right reply is given".  Anyway, templates and snippets are isolated completely within the builder app sphere.  This means once we have the Wherigo v2 Player API set in stone, anyone would be able to work on this outside the main group.

 

For me, being able to see a mockup of a design and have all the graphical assets would be a big help.  In the group, I'd rather focus my efforts where there's a gap in capabilities.

 

When I get time, I should outline the Wherigo scoring and Wherigo Invaders concepts.

 

Yes, Wherigo v2 should handle zones as single coordinates or as a shape.  I would prefer to deal with zones as single points because that makes the distant/proximity/enter events so much easier.  I don't know the math involved to determine if someone is ten meters from a zone that's in the shape of a star with a dozen points (points to the star, not zone points).  Picture that star.  Picture two of the star's points or arms.  (We're going to exaggerate here.)  Picture each arm goes out half a kilometer.  Now, picture someone standing just outside where both arms meet, or someone a quarter of a kilometer from that vertex.  What would an efficient algorithm be like?  This is one of the reasons why I won't be on the player app team: I think others would be able to make something more efficient.  (But if we lack a player app engineer, I guess that'll fall to me.  Ouch.)

 

So, anyway, if you have a single point zone, I'd like to rule that the zone's OnEnter event is based on getting within the device's estimated position error (EPE).  I'd prefer to guide cartridge authors to use OnProximity for single point zones.  OnEnter can be used for zones with a large enough area for it not to be a chore for a player to get within EPE.

  • Upvote 1
Link to comment
8 hours ago, thebruce0 said:

It sounds all nice and good, but if they disallow Wherigo 2.0 to be used for geocaches, it won't gain traction at all; can't even be used as a puzzle. They can simply say "nope" and that act itself cuts the project off at its knees so its only hope is to exist as its own non-geocaching game akin to the game that shall not be mentioned.

 

Video/Media:  Perhaps when a user chooses to 'download' the Wherigo, they have options.

 

AR: One BIG benefit to today's technology is that you could incorporate AR already with all the data and assets that are in the cartridge.

 

Lots of potential... looking forward to see what can be developed!

I'd rather we start off trying to replace Wherigo, then go off on our own if a partnership can't be reached after we demonstrate a fully-working product.  It at least allows us access to the player base of geocachers for the time being.  But as I said, gathering a group of volunteers to create everything that's needed (and a commitment) will be a challenge on its own.

 

We can control whether media is downloaded or streamed if everything is uploaded to the listing site as one package.  This would require a lot of storage space, but storage is cheap these days.  When downloading a cartridge, the player app would have to download the cartridge's manifest and required assets (e.g. the compiled/interpreted code), then look through the manifest and, based on settings or input from the user, decide what to do with the cartridge's other assets.  It could even warn players that the cartridge's assets total 500MB, so it's advisable to connect to WiFi to download the cartridge, else it will need to stream the assets as needed.  I would, though, prefer offline playability, but the manifest might also say the cartridge must have Internet connectivity because multipayer features are being used.  The Wherigo Foundation used an example of a cartridge built to play poker or blackjack with other players.

 

I do not know how difficult it would be to set up AR, both from a player API and cartridge author standpoint.  It would be interesting to demonstrate this as a proof of concept one day.  The AR I'm thinking of is something that looks at what's in the environment on the camera and places a 3D character that might even be obscured by foreground objects.

 

Don't forget this would be a community effort.  Doing the Wherigo Foundation and then later having a job where I was putting in on average 50 hour weeks every week exhausted me for several years.  And when I needed a break from working on the Wherigo Foundation site, I ended up making a 42 mile hiking multi geocache because to keep balance I needed to be equally intense on something else.  While I think I've recovered from all that and don't have that job anymore, I'll only put in the time for this if I have a group of others who are putting in time.  It doesn't have to be much time every week--even five or ten hours will eventually get us somewhere.

  • Upvote 2
Link to comment
4 hours ago, Ranger Fox said:

But no one said we couldn't create a dummy cartridge on Wherigo.com that tells people the cartridge needs to be downloaded elsewhere.  (A bit of a hack, but whatever.)  Again, the idea is to produce something so good that the community will use it regardless of the geocaching guidelines, so much so that it forces Groundspeak to make a decision: partner with the group or close Wherigo.  I'm hoping the former.

 

If we create a separate platform, we lose the geocaching audience, must build our own audience, and will not be able to discuss it on this forum. 

 

That's the thing. I'm sure that if the reviewer finds that a Wherigo does not need a Wherigo cartridge to complete, and actually makes use of a different 3rd party tool, the cache would not be published and/or would be archived. I don't think there's any way around being able to have geocaches published making use of the platform without the support of Groundspeak.  ie, I'd wager it'll be all or nothing.

 

ETA: Honestly not trying to be a downer :P just realistic, I think

Edited by thebruce0
  • Upvote 1
Link to comment
26 minutes ago, thebruce0 said:

if the reviewer finds that a Wherigo does not need a Wherigo cartridge to complete, and actually makes use of a different 3rd party tool, the cache would not be published and/or would be archived.

I've run across mystery caches that require you to go to a website and play a Wherigo-like game.  Admittedly, I looked it up on the geocaching map and I don't see the cartridge anymore where I thought I played it.

 

You could get around this by hosting a Wherigo cartridge on Wherigo.com where all you need to complete it is a code.  You get the code from playing a v2 game.  Or the final geocache would contain the completion code word that, when put into the v1 cartridge, would give you the final coordinates.  As long as the v2 site is set up properly, such a placeholder cartridge could be generated automatically.  And if the web service on Wherigo.com is still in place, posting the cartridge could be done in the background or as a final step to submitting the v2 cartridge.

 

The real test is in figuring out if there are enough people who can contribute their time to making v2 happen and getting a commitment from them.  But first, when I get some time, I'll share a couple more things I came up with back then: the scoring system and Wherigo Invaders.  It might make for interesting discussion and some ideas.

Link to comment
18 hours ago, thebruce0 said:

External websites are different than requiring a user download an external app. The former is allowed (browser-based and reasonably universal), but the latter to my knowledge isn't.

It would be fun to see Wherigo run in WebAssembly, then.

 

Anyway, if development proceeds, the intent is to make something awesome, let people use it, then see about the partnership again.  Considering what I had gone through last time, I'd just as soon Groundspeak approach me, but nothing's stopping me from reaching out again, save my dislike of the indifferent actions last time.  I can still continue to run things until something happens.

 

I'll point out that I do have that official Groundspeak third-party developer standing with Groundspeak.  When asked how I wanted to be listed on Groundspeak's official third-party developer listing page, I asked not to be included on it because it would be contradictory for Groundspeak both to recognize me as an official third-party developer and yet say cache listings can't mention the software.  All other official third-party developers can have their group's software mentioned on cache listings.  If we want to get technical about it, the listing site is in this middle ground, Kit should be 100% good, and everyone else's software who falls under the Wherigo Foundation banner should be fine as well because they're part of my group, but perhaps not because we're a little too loosely organized.

 

And the moment the v2 project becomes not-Wherigo, I'm going to have to make sure discussion moves off this forum because it'll then fall outside the forum's guidelines and topic of discussion.  I'd have to do that regardless of my moderator standing.

Link to comment
On 1/16/2023 at 6:18 PM, Ranger Fox said:

Let's use the term "template" to refer to something cartridge-wide, such as a template that allows you to create a Whack-A-Lackey game, and the term "snippet" or "action snippet" to refer to a small piece of code that allows you to do something.  Moving a zone won't be a snippet, though, because it should be a method call within the Wherigo Player API.  A snippet could be as simple as "ask a question over and over until the right reply is given".  Anyway, templates and snippets are isolated completely within the builder app sphere.  This means once we have the Wherigo v2 Player API set in stone, anyone would be able to work on this outside the main group.

 

For me, being able to see a mockup of a design and have all the graphical assets would be a big help.  In the group, I'd rather focus my efforts where there's a gap in capabilities.

 

When I get time, I should outline the Wherigo scoring and Wherigo Invaders concepts.

 

Yes, Wherigo v2 should handle zones as single coordinates or as a shape.  I would prefer to deal with zones as single points because that makes the distant/proximity/enter events so much easier.  I don't know the math involved to determine if someone is ten meters from a zone that's in the shape of a star with a dozen points (points to the star, not zone points).  Picture that star.  Picture two of the star's points or arms.  (We're going to exaggerate here.)  Picture each arm goes out half a kilometer.  Now, picture someone standing just outside where both arms meet, or someone a quarter of a kilometer from that vertex.  What would an efficient algorithm be like?  This is one of the reasons why I won't be on the player app team: I think others would be able to make something more efficient.  (But if we lack a player app engineer, I guess that'll fall to me.  Ouch.)

 

So, anyway, if you have a single point zone, I'd like to rule that the zone's OnEnter event is based on getting within the device's estimated position error (EPE).  I'd prefer to guide cartridge authors to use OnProximity for single point zones.  OnEnter can be used for zones with a large enough area for it not to be a chore for a player to get within EPE.

 

This would be awesome if we could switch to a single zone point. I have always thought the multi point format of zones is problematic. With the current Wherigo format I usually create tiny zones and then use a very large proximity. A single point would also be a lot easier for anyone new to Wherigo.

 

Coordinates for items and characters -- I like the idea of being able to see objects and characters outside a zone. I assume this is how the map based Wherigo would work but wasn't sure.

 

Programming Language --  The only programming language I've formally studied is LUA, so I like the idea of sticking with this, but I'd be curious to hear people's thoughts on sticking with LUA vs using some other language.

 

I was thinking too on the issue of gathering help with Wherigo, maybe we can somehow bring the conversation to the developers in the community. I have seen some discussions with developers wanting to build a new Wherigo interface on facebook. I'd also be happy to message some of the Wherigo community to see if there is any interest in getting involved.

Link to comment

I would also like Zones with more points.

For Example on a Play Anywheres is it nice to have bigger fields shown on map. Not ust cycles. If we want to be downwards compatible we also have to implement zones with more than one point.

But zone with just one point are easier for all, so it make sense to add them too.

 

I don't like lua, but we need languages witch are possible to restrict. Maybe some whitch use imports like lua, java, python. 

My favourite language is js, but in this case we have to think, how we can avoid web request. That is maybe too complicated.

I would stick on lua and may add some other, more common languages like java or python.

 

Asking the community make sense. Ee might have better luck building a team if we message people who like WIGs. 

Link to comment
22 hours ago, Forest-Ghost said:

I have seen some discussions with developers wanting to build a new Wherigo interface on facebook.

I tend to live under a rock.  You'd figure I'd be connected and well-informed, especially with my geocaching activity, but I'm not.  I don't tend to do much with social media.  So, yes, do see if there's any interest there.

 

19 hours ago, capoaira said:

I would also like Zones with more points ... it nice to have bigger fields shown on map

 

I don't like lua, but we need languages witch are possible to restrict ... how we can avoid web request.

I'm envisioning a map populated with icons.  If the zone has multiple points, the shape will be shown and icon optional (if provided, one can be shown).  If the zone is just one point, the icon should be required, but if it's still not provided, a player app-supplied default icon will be used.  Tapping on the zone will bring up a small box exactly like in Adventure Labs.  You'll see the zone's full name, icon, distance, and one line of the description.  Tapping on the zone will bring up the full description, larger photo, and a compass with distance if you're not already inside the zone.  NPCs and items can themselves be displayed on the map with icons and have the same treatment.

 

I share your viewpoint regarding programming language.  For security reasons, I'd rather not give anyone the ability to make external calls.  While it's true you can do a lot of cool stuff, such as dynamically build images (think of tracking your route in a maze or showing where you are in a maze without having to have every possible image in the cartridge), it's also true this would be a wide open door for someone to do harm.  So while I'd love to see Wherigo run on C# or JavaScript, I would need a way to guarantee they'd run in a sandbox with the only external resource being the Wherigo Player API.

 

19 hours ago, capoaira said:

Is there somewhere a site where we can see the Wherigo.lua oder the dev API with all methods we have on the current Wherigo?

You can pull it from my archive on my NAS here: https://nas.rangerfox.com/sharing/xD1PIc0ba

The link will work until I move the file or rename the directory.  The file isn't glamorous, but will make you happy you don't have to write any of that in your cartridges or deal with that low level.

The file came from Wherigo Foundation's compiler.

 

The associated file, WIGInternal, exposes these functions:

  • GUI interfaces:
    • LogMessage(a, b)
    • MessageBox(a, b, c, d, e)
    • GetInput(a)
    • NotifyOS(a)
    • ShowScreen(a, b)
    • ShowStatusText(a)
  • Events:
    • AttributeChangedEvent(a, b)
    • CartridgeEvent(a)
    • CommandChangedEvent(a)
    • InventoryEvent(a, b, c)
    • MediaEvent(a, b)
    • TimerEvent(a, b)
    • ZoneStateChangedEvent(a)
  • Internal functions:
    • IsPointInZone(a, b)
    • VectorToZone(a, b)
    • VectorToSegment(a, b, c)
    • VectorToPoint(a, b)
    • TranslatePoint(a, b, c)

Come to think of it, this is the first time Wherigo.lua found its way to the forum.  I've had Wherigo.luac for a while now, but until today I hadn't had a reason to decompile it.

 

I've also decompiled the builder application and thought about fixing some things with it so I could have a working version for Windows 11, but just haven't gotten around to it yet.  A desktop at my house still has Windows 10, so I just remote into it if I need something.  I've been lazy.  These days, if I think about programming something, I usually just log into work and do something there.

  • Helpful 1
Link to comment
19 hours ago, Ranger Fox said:

I tend to live under a rock.  You'd figure I'd be connected and well-informed, especially with my geocaching activity, but I'm not.  I don't tend to do much with social media.  So, yes, do see if there's any interest there.

 

Okay, I will start getting in contact with people! If anyone knows someone who might be interested in building a new Wherigo platform, please don’t hesitate to reach out. Since the forums were updated a couple years ago, there’s a lot of people who don’t get Wherigo forum notifications anymore and may not know about this thread.

 

 

 

Wherigo 2.0 Menu System

 

One of the advantages of adventure lab is that once a player is close to a location, all the information within that location is available to you, even if you leave that area. I wonder if Wherigo 2.0 could include some type of new menu system that would allow players to access information from within a zone once they’ve entered, and keep that information displayed even if they drift outside the zone. This menu should also prevent events from accidently triggering.

 

Currently, Wherigo has a lot of issues with players accessing information within a zone:

 

  • Items and characters will not display unless a player is inside the zone for OnEnter, or within a certain distance of the zone for OnProximity. If there’s bad GPS reception or very tiny zones/proximity distance, it will become very difficult to see these objects.
  • If there are multiple zones and the gps is jumping, you may end up triggering multiple events/zones at the same time. This can cause unexpected problems.
  • The GPS can wander in and out of the same zone causing the events in that zone to re-trigger—also causing problems. 

 

I try and fix these issues by building work arounds into the cartridge.

 

Once a player enters a zone:

  • Set it so On Proximity events do not re-trigger.
  • All other zones are set as inactive.
  • All objects in the zone are set to always remain visible.
  • Once that player leaves that zone, all this is reset.

 

It would be really nice to have a function or menu that somehow automates all of this.

Link to comment

I just received Forest Ghost's invitation to check out this discussion forum.  I have built and published a number of Wherigos, many of them based on cartridges and code by Ranger Fox (thanks for the help on a Battleship implementation several years back) and Forest Ghost as well.  I was following the previous attempts to get Groundspeak to cooperate with the project of updating the WIG site and tools.  When that seemed doomed to failure, I sort of moved away from doing much more WIG development and went back to primarily Geocaching.

 

I would be interested in knowing what is the current state of the WIG sites and tools that Ranger Fox put all that effort into.  I am willing to be of any assistance that I can.  I also know of a few geocachers who have built WIGs and might be interested in getting involved.  Making the development interface more user-friendly would be a great asset.  Many of my WIGs were built using raw lua code and a text editor.

 

Best of luck on getting this project off the ground.  I hope that this time Groundspeak will be more forward-thinking and support (or at least not block/hinder) these effort.

 

  • Upvote 4
Link to comment
2 hours ago, ZenGuru said:

I just received Forest Ghost's invitation to check out this discussion forum.  I have built and published a number of Wherigos, many of them based on cartridges and code by Ranger Fox (thanks for the help on a Battleship implementation several years back) and Forest Ghost as well.  I was following the previous attempts to get Groundspeak to cooperate with the project of updating the WIG site and tools.  When that seemed doomed to failure, I sort of moved away from doing much more WIG development and went back to primarily Geocaching.

 

I would be interested in knowing what is the current state of the WIG sites and tools that Ranger Fox put all that effort into.  I am willing to be of any assistance that I can.  I also know of a few geocachers who have built WIGs and might be interested in getting involved.  Making the development interface more user-friendly would be a great asset.  Many of my WIGs were built using raw lua code and a text editor.

 

Best of luck on getting this project off the ground.  I hope that this time Groundspeak will be more forward-thinking and support (or at least not block/hinder) these effort.

 

 

Thanks for joining the discussion! If you know of any other Wherigo builders that would be really awesome as the group is currently looking for people to help develop the platform.

Link to comment

I too received an invite. I've built many custom Wherigo cartridges from scratch and have extended some cartridges that others have created and made available for reuse. And by trade I am a software engineer specializing in the Microsoft stack (predominantly back-end services using c# .NET). I am interested in seeing where this is headed and would love to see it evolve. The problem with me being a part of it is that I fear I would let everyone down. When I am not actually working for "the man", I have very little time of my own and like to spend that time with my family or out caching. At the very least I think it would be sweet to be a spectator on the project if allowed. And if I see a point at which I have time and can add value I would drop in and do what I can.

  • Upvote 1
Link to comment

Hello,

 

I also got an invitation. Made long time ago, the compiler on the Wherigo Foundation website and a core for Wherigo players.

 

I think, the problem of Wherigo isn't Groundspeak. They are not helpful, that's right, but they got, what the real problem is: Wherigos are difficult, complicated and time-consuming to create. You need someone, who could create a game, design the layout, creates beautiful images and, at the end, could program the cartridge. You need weeks to make a good cartridge, and then players consume them in less than an hour. I also made some cartridges by myself. At the beginning, I thought, that the many bugs inside the development environment are the problem. But later on I got it, that even, if there were any bugs, I could get in trouble and produce nothing, that others would play. That said, the biggest problem is the content.

 

The next is the idea of zones. You think, you could draw them on the screen and think, what happens if the players go inside. But then the player has difficulties with the location. Bad coordinates, so she/he has to walk around for many minutes or couldn't reach the zone. It is no fun to do this, and so you get bad comments for your cartridge. Therefore, not only you need patience, but also the player. That said, the second-biggest problem is the technical side of the Wherigo player.

 

I would say, the problems you will solve with a new start of Wherigo is the third-biggest problem: the environment for developers. What ever you do, I would say, it is always too complicated for normal "developers" to create a cartridge (see the biggest problem).

 

PS: Something similar as Wherigo is Actionbound from a German company.

  • Upvote 1
Link to comment

Hi! If I can help...

 

I'm Software Engineer, mainly Java backend developer, but I have also experience with some Android apps using Java and/or Kotlin.

 

I'm located in Spain but I'm used to work with different time zone and international teams :)

 

Salut i catxés!

  • Upvote 3
Link to comment

It sure is good to see that Wherigo is getting some attention.  I also got an invitation and yes I would like to be involved and help out.  I have a Mac, so my Wherigo cartridges has been built via Earwigo and Wherigo/Kit.  I love Wherigo's and agree with another comment that to make a Wherigo cartridge takes weeks to months for a good Wherigo.  I am not a programmer, but willing to help out.

Edited by gjhimages
  • Upvote 1
Link to comment

Just my two cents in this thread:

  • I was already following this thread actively once it started as I am still regularly developing new WIG cartridges
  • because I love the stories I can tell and the interesting interactions, even with all the technical hurdles of the current platform. I still believe in the idea of location based rich interactive applications that make a better geocaching experience.
  • I am experienced in Wherigo/kit, Urwigo, Earwigo and just plain lua development in notepad. I choose the tool that fits my needs of the moment
  • my worst fears were that at some time in the future Groundspeak would discontinue the platform or that the technology becomes too broken to be fixed for today
  • so yes, I really want to be involved in this group and participate where I can be of use

On the list of features and categories:

  • we also need an out of scope list, things we agree that we will or do not want to pursue (like ads). Suggesting things for the out of scope list will sometimes be more productive than just adding stuff at the wishlist in one priority or the other. It makes it more clear where we are heading. For example: do we really want a dependency on being on-line / being connected? 
  • if we go on with this project, we must leave this forum not only because of the conflict of interest that you are referring to but also because it is very hard to consolidate the information, views and insights gathered in the replies
  • we also must think out of the box (of geocaching): being active in the community of geocaching you don't realise how small it is. For example in my country Belgium there are 40.000 active cachers on a total population of about 11 million. Even if only half of them could be considered as potentially interested in this type of outdoor gaming, that is less than 1% we could reach. And even in that 1% geocachers only a very small percentage is currently interested in WIGs. I read this a lot in my logs "I hate doing WIGs because..."
  • on this last topic: several of my WIG cartridges are also made available outside the Wherigo.com platform (I just host the .gwc on my site for download) and I am surprised that I can attract non-geocachers with the fun of it. I skip the hurdle of having an account, struggeling with the download and broken Wherigo.com site, ... The only hurdle remains with a separate player app and a cartridge that needs to be installed. Could we consider bundling the player with a specific cartridge that could be more easily installed with one click? Ease of installation will be a key to the success
  • and last but not least: this is a huge project to start, especially with a remote and diverse international team that will have to deliver without a commercial or professional driver, just for the love of it. So we need a project lead that can manage that.
  • Upvote 2
Link to comment

I too recieved an invitation from Forest Ghost.  I have built a number of wherigos that are very different from the usual "go here, whats the answer" type.  I have succesfully built a few wherigos where NPCs are able to move from location to location for multiple players playing the same cartridge, but this is always based on time of day/month etc.  I have dabbled with using variables which players have to share amongst each other to confirm the other player has completed a task etc.  It all does makes for it being a bit clunky.

 

Many years ago, I wrote a couple of intercaches, which were sort of a poor man's Wherigo.  The playtform was very limited in finctionality, but it was web based, which made for a few interesting things.

  • You couldn't hack them because all the information was stored on a server.
  • They weren't considered a Wherigo, they were considered a puzzle as users had to naviagte to the external website to play the game and discover the final coordinates.

The down side was that they had to be played online, which used data (and battery).  But if something like this was built, but with the advanced functionality of a Wherigo and then combined with cloud varaibles, I think that would go a long way to truly building something that engages a lareg proportion of the geocaching population.

 

Whilst the requirement for it to be played while using data may be seen as a negative, I really see that at least where I live in Australia, most areas do have mobile data coverage and the cost of that data has dropped significantly in the last 5 years.  So not as big a deal as it used to be.

 

As for my experice, all my wherigos have been built using urwigo, with some limited lua codin inside.  I'm happy to help where I can, but not sure how much use I will ultimately be.

  • Upvote 1
Link to comment

What I want out of Wherigo is simply a stable and reliable app and cartridges. The original Groundspeak builder program was a nightmare. RangerFox's online builder is/was great. However, I still had problems with the app (WhereYouGo) sometimes crashing, cartridges sometimes having problems saving, maps not displaying, etc. Nothing really consistent.

 

Personally, I like Wherigo primarily as a guided tour app. Saves all the manual calculations of a walking tour and lets you provide more information to the user. I'm a history nerd; I like learning about and sharing history via geocaching.

 

I have done a few of the creative Wherigos over the years: a reverse cache, a play-anywhere, and a version of the chicken crossing boat problem. They were all creative uses of the program. However, in practice what they actually entailed driving around in circles, wandering around an empty parking lot, and walking back and forth on a boardwalk.

 

Despite the difficulty that goes into creating them, some Wherigos I've encountered have been surprisingly lame. A 1-5 star rating system wont help as Adventure Labs have proven most geocachers will just rate everything 5 stars. Maybe a Favorite points system.

 

On 1/10/2023 at 10:48 PM, Ranger Fox said:

Scoring mechanism - You get points for playing and building, and you have to do both to make the most of it.  You can't continue taking from the community, nor can you build without experiencing cartridges for yourself.  The time involved, infrequency of completions, special achievements (50+ people completing a cartridge in the same day), and so on can be taken into account with scoring.

 

Could you clarify what this means? If I only play Wherigos and don't create any what is the intended consequence/punishment?

I hope Wherigo 2.0 is successful; if it's not Groundspeak then should really just grandfather the cache type as they don't seem to be making any effort to further develop it. I will be happy to try out Wherigos using the new system placed in my vicinity, but I'm on indefinite hiatus from placing geocaches of any kind.

  • Upvote 1
Link to comment

I am honored that I was asked to participate.  The truth is that I am just not that computer literate.  I built a Wherigo cache  several years ago that took a lot tinkering  to get right.  Now I would be afraid to touch it for fear of screwing it up.   However, it does still work and is found occasionally.

  • Upvote 1
Link to comment
On 1/20/2023 at 6:39 PM, Forest-Ghost said:

One of the advantages of adventure lab is that once a player is close to a location, all the information within that location is available to you, even if you leave that area. I wonder if Wherigo 2.0 could include some type of new menu system that would allow players to access information from within a zone once they’ve entered, and keep that information displayed even if they drift outside the zone. This menu should also prevent events from accidentally triggering.

I believe you're touching on the underlying problem with zone enter/proximity without actually correctly identifying the it.  You're observing that a player tends to drift in and out of a zone, so you're trying to keep the player inside it.  I believe the underlying problem is the player stops walking when the cartridge displays something to the player, and this means the player is typically on the edge of the proximity/enter boundary, so the GPS position drift will eventually cause fluctuations between the player being inside and outside this boundary.  Such a thing could be resolved by a player app taking a look at the estimated position error (EPE--even this value will fluctuate).  A zone's proximity and entrance events would fire at the author-intended distance, but their opposites--distant and exit--should be fired at their distance plus one and a half times the EPE.  Let's take a zone that is 10 meters square, has an entrance event, and the EPE is usually 5 meters.  The player will typically stop on the zone's border.  As long as the player doesn't wander 7.5 meters away from the zone's border, the player is still considered within the zone.

 

On 1/21/2023 at 4:39 PM, ZenGuru said:

I would be interested in knowing what is the current state of the WIG sites and tools that Ranger Fox put all that effort into.

They're still hosted and available.  I made a second version of Kit, but it fizzled out once I had to build the rest of the website around the builder.  I spent so much time on the builder part that I tired myself out and didn't complete the rest.  I could do the programming, but the UI design work just made me tired.  This is going to be a common theme.  I program at work, so doing the same thing at night albeit on a different project tends to get tiring unless I can balance the programming thing out with some other activity.  My other activities--geocaching, photography, travel, and riding that high-powered electric scooter--usually take a good chunk of time.  I should take up locksport or something (I do have several picks and practice locks, by the way).

 

Anyway, the way I see it, technology has moved on since I first created the Wherigo Foundation and Kit sites.  The WF site needs to be separated into a responsive front end atop the Wherigo API.  The Wherigo API needs to be split into the listing service and player app event system (things that can allow multiplayer and other player app features).  Then there's the Wherigo Invaders meta game that ties cartridges together.  I don't have much of a background with microservices, but it's possibly the Wherigo API might need to sit atop microservice land to allow us to expand the system with increased load.  And if I use microservices, then I'd probably need some sort of event system so I can bring new services up.  The more I consider a truly enterprise architecture, the more I get tired thinking about how much work that would entail for me to do--and why I shouldn't do it alone.  As for the front end, I can choose between React, Angular, or Blazor.  I like the idea of WebAssembly and it seems the industry is trending in that direction, so I'd probably go that way.  I'd need to build for mobile first, desktop second.  But since it's a gaming site, as @Forest-Ghost pointed out, you'd likely expect a fancy UI with a ton of animations--and something really high class like that is a little beyond me.  I can go deep and learn only so many things with my time without giving up all my hobbies.

 

8 hours ago, charlenni said:

What ever you do, I would say, it is always too complicated for normal "developers" to create a cartridge (see the biggest problem).

Wow, @charlenni, it has been a while!  So, about the environment.  I still think Kit was the right approach: come up with some typical cartridge scenarios and build a UI that allows the average person to create something without having to touch code or know code is being generated.  Let's take my Battleship cartridge for example because that's a rather complicated one.  You could create a kit that would produce a battleship cartridge: give the user a way to define their battleships, adjust text that's shown in the cartridge, and upload images to use.  An author doesn't even have to know code is being written.  Likewise, you could mimic all of Adventure Labs by having a kit (UI) that looks 100% exactly like the current labs UI, then output a cartridge's code as a result.  We can then have Urwigo able to import these canned cartridges if someone wants to edit them further or create something completely different.

 

At the end of the day, the measure of success is how easy, rewarding, and entertaining it is for someone to author a cartridge.  Someone of low skill level should have tools for them and someone of high skill level could seek the advanced tools.

 

5 hours ago, Ghaz said:

I'm Software Engineer, mainly Java backend developer, but I have also experience with some Android apps using Java and/or Kotlin.

 

I'm located in Spain but I'm used to work with different time zone and international teams :)

Prior to developing anything (but after the requirements phase), we'd need to come up with an architectural plan.  If I can somehow swing microservices (light old Java joke), I can have an environment where multiple languages can be used.  My only concern about that is in retaining enough talent on the team that we have skill overlap.

 

Since this will be a team of volunteers working for the greater good, it won't matter which time zone you're in.  Everyone can work at their own speed, contribute what they can, and help where they can and would like.  For a project like this, for those who can't program, I'd need them either designing or keeping the specification and answering the programmers' questions about what Wherigo is supposed to act like to the users, or coordinate across teams.

 

5 hours ago, gjhimages said:

I am not a programmer, but willing to help out.

Well, first, I'd need someone to keep track of some of these things we've been discussing that we'll all forget.  For example, that idea I had at the top of my post here about the player app treating zone entry and exit events using different distances.  I can bet we're going to forget about this.  And I need to post that other thread about the Wherigo scoring system, and another one about Wherigo Invaders.  We'll need to hammer those things out, though Invaders could be done another time.  Still, Invaders might make a fun meta game...  (I know I've explained Invaders before, but I forget where.  I don't think it was in this forum.  Perhaps a private email.

 

4 hours ago, Dani+Iris said:
  • we also need an out of scope list, things we agree that we will or do not want to pursue (like ads). Suggesting things for the out of scope list will sometimes be more productive than just adding stuff at the wishlist in one priority or the other. It makes it more clear where we are heading. For example: do we really want a dependency on being on-line / being connected? 
  • if we go on with this project, we must leave this forum not only because of the conflict of interest that you are referring to but also because it is very hard to consolidate the information, views and insights gathered in the replies
  • we also must think out of the box (of geocaching): being active in the community of geocaching you don't realise how small it is. For example in my country Belgium there are 40.000 active cachers on a total population of about 11 million. Even if only half of them could be considered as potentially interested in this type of outdoor gaming, that is less than 1% we could reach. And even in that 1% geocachers only a very small percentage is currently interested in WIGs. I read this a lot in my logs "I hate doing WIGs because..."
  • on this last topic: several of my WIG cartridges are also made available outside the Wherigo.com platform (I just host the .gwc on my site for download) and I am surprised that I can attract non-geocachers with the fun of it. I skip the hurdle of having an account, struggeling with the download and broken Wherigo.com site, ... The only hurdle remains with a separate player app and a cartridge that needs to be installed. Could we consider bundling the player with a specific cartridge that could be more easily installed with one click? Ease of installation will be a key to the success
  • and last but not least: this is a huge project to start, especially with a remote and diverse international team that will have to deliver without a commercial or professional driver, just for the love of it. So we need a project lead that can manage that.

 

Ads will always be out of scope.  I don't like them.  Yes, I agree that it's more telling to define what's out of scope than what would be in.  I believe the offline/connected decision will eventually be done on a per-cartridge basis because it'll be based on the features the author desires to use (or in settings established in the player app).  I'd like to start off by saying that cartridges can be offline, then go from there.  Video will be the first question.  Multiplayer will require online.  (And I just went off on a tangent instead of sticking to the point you made.)

 

Any forum will likely be that.  We could either set up a wiki or documentation site to house everything.  I can see discussion about individual documents moving there.  But I also feel it would be good to continue general discussion in this forum as a way to keep the entire community involved and show that progress is being made.

 

That's a whole other discussion, then: what would interest non-cachers to pick up Wherigo.  The geocaching side might like that the cartridge terminates in a box with a log.  The non-caching side couldn't care less about that box.  The end result of a Wherigo cartridge should be different from a box.  A geocacher can create a Wherigo and let it lead people to as many boxes as they want, but Wherigo should be done for something else: stories, adventures, challenges, games, and so on.  And that's where we need to start: decide what Wherigo should be seen as and the feelings associated with it.  We shouldn't just say it's another way to get to a box.  After all, when Groundspeak released Wherigo fifteen years ago this month, there wasn't any overlap with geocaching.  Soon after, though, people began making mystery caches using Wherigo, then the Wherigo cache type was created.  I agree with this: Wherigo should be its own thing and, by the way, it's also possible to use it for geocaching if you want.

 

The cartridge-loading problem with a player app is a non-issue.  The Wherigo API will fix all that.  Think of the Adventure Lab app: you see all the labs in an area, you can see information about a lab, then when you click "Start", it downloads the lab (sort of, since the media are downloaded as needed: I'm generalizing to make a point here) and off you go.

 

Yeah, a project lead.  I bet when you brought that up, people then thought, "I wonder what Fox is going to do?"  Yes, I recognize I have a great deal of power and influence, so we should likely address that.  I don't use it for personal gain or to satisfy an ego.  This has always been a project of altruism.  I intend to fill roles as needed.  I do intend to be one of the key people providing a vision and direction to the project.  The Wherigo Foundation name goes along since the Wherigo Foundation is the community's effort at improving Wherigo.  I intend for whatever we produce to be hosted at first from that domain name, then in parallel at Wherigo.com if/when a partnership can be reached.

  • Upvote 2
Link to comment
1 hour ago, rangercarol said:

I am honored that I was asked to participate.  The truth is that I am just not that computer literate.

You are aware that makes you a great person to provide feedback and test things?  There are times when someone like you needs to step in and say, "you software engineers might think this is really neat technically, but it's either a stupid idea or just confusing to anyone who isn't a software engineer."  Your perspective into what would help you make more and be able to maintain the cartridges you have is important and needed.

  • Upvote 2
Link to comment

Hi All, 
Nice initiative, hope we can give the community a better Wherigo experience. 
I received an invitation from Forest-Ghost. I'm living in the Netherlands and have placed over 70 Wherigo caches in the past years and have created over 60 cartridges with Urwigo. 
I work in IT but don't have developer skills, however, I can help with testing and documentation / manuals to create a Wherigo for users and so on. 
Best regards, Komplot. 

  • Upvote 1
Link to comment
10 hours ago, Ranger Fox said:

We shouldn't just say it's another way to get to a box

I have to admit that "the need for a final box" currently is my least concern:

  1. yes, I think today there needs to be a box because very few people (geocachers) will play a Wherigo from Wherigo.com if there is either no "reward" from a found log on geocaching.com (from the players perspective) or there is no publicity for the cartridge by not putting up a geocaching.com listing (from the creators perspective).
  2. the urge of players "hacking" a cartridge or just plain sharing the final coordinates only comes from "finding the box and the log requirement" from geocaching.com. If we would be released from that requirement,  would we see more effort put into the cartridge? I have to admit that most maintenance for my current cartridges comes from the box / final location issues, not from the coding/cartridge/bit rot.
  3. always ending in one or a fixed location is also a result from "the final box". Imagine the liberation in game play and variety of scenarios we could gain when ending in just one spot is no longer a requirement

I know that in theory you could create WIGs just on Wherigo.com and not cross-list on geocaching.com. But in practice today this does not work. So today the final box is something "I must do" as a creator but "I would rather not do if I did not have to". How can we get to that? It brings up fundamental questions to me:

  • do we need the geocaching community and (the burden of) its rules? (today yes: publicity, ...)
  • can we get attention outside that community? (today sometimes: I used the platform several times for creating something for the general public. It works but it takes a lot of effort)
  • can we then combine both communities? (maybe: the public attention dies very soon and the GC communicty will always at least have the drive for the statistics/found log - hopefully something more than that for the connoisseurs)

I do believe that thinking about this choice (for GC only or (also) for general public) will sharpen the idea of what we want to build.

 

afterthought: I have seen many alternatives over the years that tried to solve the problems we experience with WIG (like Actionbound, intercaching, ojoo, geomob, yes even adventure labs, ...) but many are already gone or slumbering or don't give the full range of possibilities. Wherigo has also been on the verge of dying over the last 10 years but hey: look at this thread. What kept it alive?

Edited by Dani+Iris
  • Upvote 1
Link to comment

Many thanks to Forest-Ghost for the invite, and I will follow developments with interest.  However, I think I have little to offer.  It is just over 10 years since I last developed a Wherigo (for a 10 year anniversary event!), and although I'm hoping to do another at some point my knowledge is so rusty I will probably have to re-learn everything I once knew.

My background is in IT, but I'm a "mainframe dinosaur", and so I cannot offer much in the way of relevant coding skills - unless you decide to rewrite in COBOL?!

Good luck with the project,

Baz.

  • Upvote 1
Link to comment

Hi guys, I got an invitation too. I am not an IT guy, but managed to program my WIGs with Urwigo (https://www.urwigo.cz/). Once you understand the logic, it is not too complicated to program nice WIGs. My most complex ones are covering a fantasy story I played on the computer as a young adult. Quite some time ago... ;-) The first one of the series can be found here: https://www.geocaching.com/geocache/GC4T1NM_ultima-das-herz-des-mutes?guid=a3a3211f-d03e-48ae-be83-9a1df3e00db4

 

True programming, which would be required to build a new platform is not part of my skill set.

  • Upvote 1
Link to comment

Interesting ideas all around. My 2 cents.


I like the comment of Dani+Iris. Yes, it's tedious to maintain a physical location (although in my case it's not too bad honestly). On the other hand, there's plenty of examples of cartridges being (re)used outside of the original cache (the Hangman series in the US, the reverse Wherigo from Waldmeister).

1 hour ago, Dani+Iris said:

I have to admit that "the need for a final box" currently is my least concern:

  1. yes, I think today there needs to be a box because very few people (geocachers) will play a Wherigo from Wherigo.com if there is either no "reward" from a found log on geocaching.com (from the players perspective) or there is no publicity for the cartridge by not putting up a geocaching.com listing (from the creators perspective).
  2. the urge of players "hacking" a cartridge or just plain sharing the final coordinates only comes from "finding the box and the log requirement" from geocaching.com. If we would be released from that requirement,  would we see more effort put into the cartridge? If have to admit that most maintenance for my current cartridges comes from the box / final location issues, not from the coding/cartridge/bit rot.
  3. always ending in one or a fixed location is also a result from "the final box". Imagine the liberation in game play and variety of scenarios we could gain when ending in just one spot is a requirement

I know that in theory you could create WIGs just on Wherigo.com and not cross-list on geocaching.com. But in practice today this does not work. So today the final box is something "I must do" as a creator but "I would rather not do if I did not have to". How can we get to that? It brings up fundamental questions to me:

  • do we need the geocaching community and (the burden of) its rules? (today yes: publicity, ...)
  • can we get attention outside that community? (today sometimes: I used the platform several times for creating something for the general public. It works but it takes a lot of effort)
  • can we then combine both communities? (maybe: the public attention dies very soon and the GC communicty will always at least have the drive for the statistics/found log - hopefully something more than that for the connoisseurs)

I do believe that thinking about this choice (for GC only or (also) for general public) will sharpen the idea of what we want to build.

 

afterthought: I have seen many alternatives over the years that tried to solve the problems we experience with WIG (like Actionbound, intercaching, ojoo, geomob, yes even adventure labs, ...) but many are already gone or slumbering or don't give the full range of possibilities. Wherigo has also been on the verge of dying over the last 10 years but hey: look at this thread. What kept it alive?

 

To attract a crowd for playing Wherigo's (isn't that what we all want), I feel the app/player experience is key. We (as builders) are obviously quick to point out the flaws/features requests of creating a Wherigo. But, in the end it's still the person that's loading a cartridge on his smartphone who's the boss. So what is it in Wherigo that can attract crowds over the myriad (successful or not) alternatives that have been launched? (I wish I had the answer to this.) 

 

Trying to dissect some of the ideas that were posted by Ranger Fox and others on the subject.

1. In general

- I like the idea of having a map centric approach. It will put limits to how you can develop things, but I think it will give a much better experience for the player.

- Videos: I do see use cases (eg. interaction with an NPC) but I would be deterred by the extra effort needed to create videos on top of building the cartridge. So for sure not a critical/v2.1 item for me. From that respect, Audio is more important.

- Formatting of items to make it more appealing: text with different fonts/colors/..., different colors for the zones (if you still have those), ...

 

2. On Zones

- Having a more 'stable' zone experience dealing with GPS-jitter

- For most purposes, just a point is sufficient, but having a shape can be interesting (eg. I have one built on a roundabout, the zones are like a piece of a pie forming a complete circle; it's nice to have rectangles if you want to have a "gameboard" like experience)

- I like the idea of having a picture/icon showing on the map, instead of just the zone shape. But we need to think about how to do it with overlapping zones/small zones (compared to the minimum picture size)

 

3. On NPC / Items

- I like the idea of having a picture/icon showing. But we need to think about how to do it with many items on the same spot/in the same zone

- I like the idea of not being forced to have these NPC/Items in a zone (or the inventory) for them to show up

- Taking this one step further: what's the difference between a zone and one of these objects? From a logical perspective, not a lot (especially if you don't have shapes for zones). Only the options you have to interact with the Object might be different ("add to inventory" or "use" for Items, "talk" is typically something for NPC).

 

4. Online or not?

- I do see the advantage of being able to play it offline. Trust me, as a European without decent/affordable data plans outside of Europe, it can become costly when visiting the US or other territories.

- I like the idea of having a neatly integrated system with APIs to load a cartridge, post a "log", mark completion, ...

 

5. On Groundspeak/GC links

- With the adventure labs, it's going to be difficult to sell a tour guide like Wherigo platform on them

- From the GC posting guidelines: "specific apps" are not allowed. So they can easily block/disallow them.
https://www.geocaching.com/help/index.php?pg=kb.chapter&id=97&pgid=297#mobileapps

 

 

18 hours ago, charlenni said:

I think, the problem of Wherigo isn't Groundspeak. They are not helpful, that's right, but they got, what the real problem is: Wherigos are difficult, complicated and time-consuming to create. You need someone, who could create a game, design the layout, creates beautiful images and, at the end, could program the cartridge. You need weeks to make a good cartridge, and then players consume them in less than an hour. I also made some cartridges by myself. At the beginning, I thought, that the many bugs inside the development environment are the problem. But later on I got it, that even, if there were any bugs, I could get in trouble and produce nothing, that others would play. That said, the biggest problem is the content.

A small remark on this: yes, it's (more) work to create a Wherigo than just drop a pill bottle behind a tree in a forest. But I am sure some people put equally (if not more) time in building great cache containers, multi's, gadgetcaches or mysteries. That being said, to buld a community, you'll need "many" cartridges (of high quality), so you'll need many builders too.

 

SWIPEE

  • Upvote 2
  • Love 1
Link to comment

I am very interested in this project. I have always been an advocate for Wherigo and I personally have built a lot of them and have helped many others build them as well. While I am not a coder I can test, build, tear apart, and am willing to do whatever necessary to help bring some advancement to this issue. 

 

Also, I do have the ability and the platform to get the word out through our Podcast Network (Geocache Talk). this could be handy if we need more testers or builders or just want some feedback. 

I am very interested in this project. I have always been an advocate for Wherigo and I personally have built a lot of them and have helped many others build them as well. While I am not a coder I can test, build, tear apart, and am willing to do whatever necessary to help bring some advancement to this issue. 

 

Also, I do have the ability and the platform to get the word out through our Podcast Network (Geocache Talk). this could be handy if we need more testers or builders or just want some feedback. 

 

Memfis Mafia

  • Upvote 1
Link to comment

 

On 1/23/2023 at 11:25 AM, charlenni said:

I think, the problem of Wherigo isn't Groundspeak. They are not helpful, that's right, but they got, what the real problem is: Wherigos are difficult, complicated and time-consuming to create. You need someone, who could create a game, design the layout, creates beautiful images and, at the end, could program the cartridge. You need weeks to make a good cartridge, and then players consume them in less than an hour. I also made some cartridges by myself. At the beginning, I thought, that the many bugs inside the development environment are the problem. But later on I got it, that even, if there were any bugs, I could get in trouble and produce nothing, that others would play. That said, the biggest problem is the content.

 

Charlenni, thanks for joining the conversation! I was really happy to see your post. I agree with these points and hope the group can come up with a list of all the problems with Wherigo to use as a reference to improve upon. 

 

One idea for rewarding players for playing through a Wherigo -- there could be special point systems that builders could work into a cartridge for completing tasks. Sort of like in adventure lab where a player gets five finds, but instead these would be points rewarded to players as they work through the adventure. Maybe if a player completes the cartridge in a certain time limit they get extra points or there could be other special rewards.

 

 

 

 

22 hours ago, Ranger Fox said:

I believe you're touching on the underlying problem with zone enter/proximity without actually correctly identifying the it.  You're observing that a player tends to drift in and out of a zone, so you're trying to keep the player inside it.  I believe the underlying problem is the player stops walking when the cartridge displays something to the player, and this means the player is typically on the edge of the proximity/enter boundary, so the GPS position drift will eventually cause fluctuations between the player being inside and outside this boundary.  Such a thing could be resolved by a player app taking a look at the estimated position error (EPE--even this value will fluctuate).  A zone's proximity and entrance events would fire at the author-intended distance, but their opposites--distant and exit--should be fired at their distance plus one and a half times the EPE.  Let's take a zone that is 10 meters square, has an entrance event, and the EPE is usually 5 meters.  The player will typically stop on the zone's border.  As long as the player doesn't wander 7.5 meters away from the zone's border, the player is still considered within the zone.

 

I understand what you’re saying, and I like your idea, but I don't think it solves the whole problem. 

 

GPS bounce can cause the phone's gps to jump hundreds of feet away and then back. This problem is especially common when players are offline, or if there is bad reception. Sometimes a player might close their app or turn off the phone in the middle of a sequence of events, move to another area, and then when they resume the game, they trigger some other zone on top of the original event sequence.

 

Another problem is if the builder creates multiple active zones that are close together or even on top of each other. Sometimes the player might mash through the buttons so quickly that the events never properly trigger. There are many other challenges that occur around the player, the builder, and the position, size, and proximity of the zones. 

 

My idea is that as the player enters the zone, they click on a button and all of the information (characters, items, events, etc.) pops up, and that information remains visible and un-effected by the other zones. Then when they are finished, they close the menu, and all of the other zones, and other relevant information is re-activated. If we are creating a map based Wherigo, then there will have to be some type of new menu for when the player clicks on an icon.

 

Link to comment

I'm so thrilled to see this renewed activity around the future of Wherigo, thanks to @Ranger Fox and @Forest-Ghost for starting the train! Also big shoutout to @charlenni, I'm so happy to read you again!

 

There's a lot of contents in the posts above, it's all very interesting and it will take me a while to dive through. I just wanted to add a handful of quick thoughts, as a professional game developer and GC enthusiast and co-writer of the WF.Core player engine with @charlenni.

  1. This thread shows that the community is eager to work together, and that's amazing. As @Ranger Fox said we need organization and communication. I'm afraid the forum is already showing limitations. What about some kind of periodic online meeting to organize efforts?
  2. There is a million technical ways we could build a Wherigo 2.0. The best one is probably the one that contributors are most fluent with, sure. But before we begin to plan out technical roadmaps I think we should start by compiling what cartridge devs and users want and lack. Maybe some kind of UX survey of the community? This thread is a good start but I think we need to be more systematic.
  3. Personally, my number 1 frustration is how limited in scope everything is within Wherigo. I'm completely tired of "Item" menus and "Zone" screens. They served their purpose back at the days of limited device resources, but these days are gone. So are the days of low computer literacy. Maps are necessary to WIGs but they are so 2010. Now people are used to using very nice UIs, especially in the realm of games. I would love us to think bigger.
  4. My dream Wherigo 2 is a hackable Wherigo, where a dev has the flexibility to extensively tweak the UI/UX to provide more interactive activities (I'm thinking for example, for the Pac Man cartridges out there, a map presented as a retro PacMan level screen, with ghosts and players represented with the proper game elements.). This is not mutually exclusive with making it easy for beginners to make cartridges, provided we maintain templates. I'm all for ease of use but please let's not forget advanced users who can get their hands dirty to make something new.
  5. I don't see this happening without the Geocaching.com platform. However, I believe we could harness the GWC format (especially the Media sections) to add arbitrary Wherigo 2.0 payloads. That would make Wherigo 2 backwards-compatible to the extent of being able of showing a message saying "Your player app is a bit too old, please use X or Y" or showing a bare-bone fallback using Inputs and Messages. This would definitely pass compilation and probably pass moderation.

I'm really excited about this community endeavor and I'm eager to help however I can!

  • Upvote 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...