Wherigo v2: Feature List

January 25, 2023

Like others, I received a message from Forrest-Ghost. I am not a coder. I built most of my cartridges with Urwigo, or took someone else's an altered it to make it do what I wanted to do.

I am a fairly organized person though, and would be willing to help in that area if needed.

January 25, 2023

Thanks so much for the invite! WiGs are my favorite and as soon as I saw that @Ranger Fox and @Forest-Ghostwere involved, I knew I had to be a part of the movement. Going back to read everything from the beginning but excited about the future of the platform! Urwigo has been my tool of choice, thus far.

Edited January 25, 2023 by Ol'Fogie

January 26, 2023

13 hours ago, Mangatome said:

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.

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?

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.

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.

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.

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!

I am right with you on every point! I think virtual get togethers would be really great to bring the group together, although my introverted side is already trying to find a place to hide out lol. :-) My dream is that the platform could someday draw all kinds of programmers and video game designers.

Also I would love to see a new UI for Wherigo in the future. This is one of the parts I'm most excited about. As you mentioned, I think Wherigo is definitely starting to show its age.

It would be awesome if players could customize various elements of the screen and add map overlays. Thank you so much for all you do! I still have WF Player on my phone btw!

January 26, 2023

Thanks for the invitation, Forest-Ghost!

I see there's been a lot of discussion going on about Wherigos here...

As a Wherigo creator, I was invited by someone from Groundspeak about 5?-6 years ago to discuss Wherigos etc. and what I thought about them moving forward, but I think they decided to can it in the end and move towards Adventure Labs, which don't interest me in the least. But I understand that they are much easier to create and probably less bug-prone than some Wherigos can be.

My biggest gripe about Wherigos has always been how so much time and effort would be spent in creating a cartridge, and then the final coordinates would be shared and then few people bother to play the Wherigo at all especially if it has any complexity to it. I'd love to see a way that requires players to actually get a unique completion code from the Wherigo, and only be able to log the cache with that completion code, but I feel Groundspeak would never agree. They seem too invested right now in AL's to consider tweaking the Wherigo system, I am just waiting for the axe to fall and wondering when they will "grandfather" all Wherigo caches, now that AL's have taken off and seem wildly popular (!).

I use several different programming languages for my job, hobbies etc. and so am comfortable with Lua although I've only ever used it to write my Wherigos. I'd like to help in whatever capacity I can (I made all the graphics for my Wherigos too), with the free time I have, so I want to keep informed about whatever happens with this project.

January 27, 2023

Hey Guys,

Thank you Forest-Ghost for the invite.

A quick introduction. I've been geocaching since 2009 and reside in Washington State. I am the current Washington State Geocaching Association President. I have put out over 20 Wherigo cartridges all in Washington.

I love all the ideas floating around on this forum about Wherigos. Not sure how the "hostile takeover" will go. I am all for a diplomatic approach before taking matters into ones hand. To truly update the Wherigo platform mentioned in the first post, it will take an entity with capital (man power and funds) to make it happen. A group of volunteers will be limited in both and would take many years to accomplish. On top of all of that, its still HQs baby. Ultimately, I do believe that HQ needs to hear from the community about Wherigos.

As WSGA President, I have been lucky enough to get meetings with upper management at HQ to discuss geocaching in Washington State. The topic of Wherigos have come up past visits asking about the future of the Wherigo website and where the Wherigo platform is going in general. Its been a while since I have had a visit with HQ and perhaps its time for another visit. HQ is always interested in getting input from the geocaching community. Perhaps its time that they hear from a small group of representatives from the geocaching Wherigo community. HQ needs to know that there are geocachers out there that like to build cartridges and put them out for the community as a whole to enjoy. HQ needs to hear that we want to see the platform evolve and move beyond is mid 2000's humble beginnings. Once we have their attention, we could proceed into how we would like the Wherigo platform evolve. Ranger Fox's list of items is a great place to start. HQ needs to understand that its not just me talking to them about the future of Wherigo. They need to hear from a group of Wherigo enthusiasts and not just me.

(Stepping off of my soap box). One other thing I would like to mention here. There is a stigma with the geocaching community that building cartridges is hard. I have tried to dispel that. Sure, you CAN build a very intricate and involved cartridge that is a programmers delight. However, all cartridges do not need to be like that. The "kit" builder site is excellent. I have funneled many cachers to that site to try to build a cartridge. Heck, I have even gone on a podcast to show how easy it is to build a simple cartridge. Keeping the cartridge builder sites easy for those who want to put out there first Wherigo is important to grow the Wherigo community. The "kit" site goes a long way to help with this task. A huge THANK YOU to Ranger Fox for putting that site together.

Thanks again, Forest-Ghost for the invite. I am hopeful that the Wherigo platform can move forward and evolve. I just think that HQs involvement will be most helpful in the evolution of Wherigos.

January 27, 2023

10 hours ago, mc3cats said:

(Stepping off of my soap box). One other thing I would like to mention here. There is a stigma with the geocaching community that building cartridges is hard. I have tried to dispel that. Sure, you CAN build a very intricate and involved cartridge that is a programmers delight. However, all cartridges do not need to be like that. The "kit" builder site is excellent. I have funneled many cachers to that site to try to build a cartridge. Heck, I have even gone on a podcast to show how easy it is to build a simple cartridge. Keeping the cartridge builder sites easy for those who want to put out there first Wherigo is important to grow the Wherigo community. The "kit" site goes a long way to help with this task. A huge THANK YOU to Ranger Fox for putting that site together.

I can confirm that: it can be hard but it does not have to be hard.

I also organised some hands-on workshop events (all of my events were actually of that type. Dutch only sorry, but you get the gist when you look at the listings e.g. with translate) where I showed and practically guided fellow geocachers in different techniques and steps for making basic cartridges that are rich enough to get a lot of favo points :-) I not only used \\kit but also Urwigo and even Earwigo for that.

What I personally like for the very beginner is starting with \\kit for the general layout of zones, questions, order, ... and then continue in Urwigo (just adding little extras like a NPC or an object you have to interact with to get the question instead of firing that from the onProximity event). You very quickly get a solid working cartridge that is rich enough to impress most players. I even use this technique myself often as it makes me focus on the import and fancy stuff and do not have to bother with the basics.

I know that I have kick-started several geocachers in building nice Wherigo cartridges: I get a lot of feedback afterwards from the attendees and they show me their creations (or have me do the live testing) with pride.

Edited January 27, 2023 by Dani+Iris

3.3k · January 27, 2023

On 1/26/2023 at 5:28 AM, artemisworks said:

I'd love to see a way that requires players to actually get a unique completion code from the Wherigo, and only be able to log the cache with that completion code, but I feel Groundspeak would never agree.

I use several different programming languages for my job, hobbies etc. and so am comfortable with Lua although I've only ever used it to write my Wherigos. I'd like to help in whatever capacity I can

Completion codes were added because there wasn't a way for the player device to connect to the website since Wherigo was created in the pre-app days. Any contempory development on Wherigo would involve APIs. Thus, the app would download the cartridge, you'd play it through, and the moment the cartridge declares itself as complete, the app sends the completion information through the API and the cartridge is marked as complete. Because of this, an author would not have trouble knowing who actually completed the cartridge. The trouble instead comes from when a group of individuals try to complete a cartridge together and only one or two of them are using the app while the rest are following. The geocaching approach is everyone gets credit. The Adventure Labs approach is only those going through the lab stages in their app gets credit. Wherigo will likely follow the latter unless the player app allows everyone in the group to register that they're playing an individual cartridge, which might be an interesting feature.

I should probably start organizing people so we can begin working on the listing site. Cartridge features aside, we're still going to need an API and updated listing service site. I've been balking at this because I know I'll need to do this with microservices and I still have very little professional experience in architecting a microservice architecture. Those times I thought I was coming into a business that used recent technologies, I found out they were behind the times. At least the listing site seems like it might be easy, with microservices covering: cartridge listing, logs/feedback, completion/bounties, user data, user permissions, and authentication. Then send events via a bus like RabbitMQ. That would solve one use case I've seen in geocaching: a user writes a found log, the logging service handles it, the logging service raises a LogCreated event, the geocache service hears of it and updates its log summary count, and the user data service also hears of it and updates the user's find count if applicable. But I'm not up on the whole dynamically bringing up additional microservice processes with their own databases restored from the event source type of thing. Perhaps for now, each type of microservice can connect to a database shared with all the same type of microservice. But, still, no database transactions if I'm to provide as much performance as possible.

I'll need to create a public GitHub repo, create projects for the different services, and stub out a lot of the methods. People can then contribute.

Yeah, funding will be important. I'm just dreading the increased bill I'll have for this. Oh, well, as long as people are having fun. Regardless what happens, I'm not budging on my strict anti-ad stance.

January 28, 2023

23 hours ago, mc3cats said:

Hey Guys,

Thank you Forest-Ghost for the invite.

A quick introduction. I've been geocaching since 2009 and reside in Washington State. I am the current Washington State Geocaching Association President. I have put out over 20 Wherigo cartridges all in Washington.

I love all the ideas floating around on this forum about Wherigos. Not sure how the "hostile takeover" will go. I am all for a diplomatic approach before taking matters into ones hand. To truly update the Wherigo platform mentioned in the first post, it will take an entity with capital (man power and funds) to make it happen. A group of volunteers will be limited in both and would take many years to accomplish. On top of all of that, its still HQs baby. Ultimately, I do believe that HQ needs to hear from the community about Wherigos.

As WSGA President, I have been lucky enough to get meetings with upper management at HQ to discuss geocaching in Washington State. The topic of Wherigos have come up past visits asking about the future of the Wherigo website and where the Wherigo platform is going in general. Its been a while since I have had a visit with HQ and perhaps its time for another visit. HQ is always interested in getting input from the geocaching community. Perhaps its time that they hear from a small group of representatives from the geocaching Wherigo community. HQ needs to know that there are geocachers out there that like to build cartridges and put them out for the community as a whole to enjoy. HQ needs to hear that we want to see the platform evolve and move beyond is mid 2000's humble beginnings. Once we have their attention, we could proceed into how we would like the Wherigo platform evolve. Ranger Fox's list of items is a great place to start. HQ needs to understand that its not just me talking to them about the future of Wherigo. They need to hear from a group of Wherigo enthusiasts and not just me.

(Stepping off of my soap box). One other thing I would like to mention here. There is a stigma with the geocaching community that building cartridges is hard. I have tried to dispel that. Sure, you CAN build a very intricate and involved cartridge that is a programmers delight. However, all cartridges do not need to be like that. The "kit" builder site is excellent. I have funneled many cachers to that site to try to build a cartridge. Heck, I have even gone on a podcast to show how easy it is to build a simple cartridge. Keeping the cartridge builder sites easy for those who want to put out there first Wherigo is important to grow the Wherigo community. The "kit" site goes a long way to help with this task. A huge THANK YOU to Ranger Fox for putting that site together.

Thanks again, Forest-Ghost for the invite. I am hopeful that the Wherigo platform can move forward and evolve. I just think that HQs involvement will be most helpful in the evolution of Wherigos.

Hi mc3cats, thanks so much for joining the thread and for supporting Wherigo! The group would very much appreciate the support of HQ and would love to bring them into the conversation. If you have any contact with them, this would be a huge help. As you mentioned, there are some pretty big hurtles to overcome. Thanks again for reaching out!

January 28, 2023

Thanks for the invitation. I'm a bit late here, and I haven't fully read the thread so far, but I've prepared a dump of the thoughts about things that I've come across over the time I've developed my Wherigo. It's all about deep technical details. While a grand vision about features is important to start with, to define the general direction, in the end the overall user experience boils down to the quirks of the actual implementation. If it doesn't work, then the vision was naught.

I went the full way of 1000 miles into madness, step by step. In the end, I had developed a Wherigo scripting language that completely abstracted away most of the dirty little details, so I could concentrate on the story and the game. The compiler took my source files and all the referenced media files, produced the complete LUA code, and generated both the package to directly upload to Wherigo.com, and the GWC file complete with self-defined player name and exit code, ready to play in the Wherigo player, in one single keypress.

A typical item/zone/char/task source looks like this:

image Paper.Image   = "item_paper.jpg"
image Paper.Image_I = "item_paper_i.jpg"

state [enum] Paper.Status = @( None, InZone, Taken )

trigger ((Paper.Status == None) & (MonasteryLib.Status == Searched))
{
    Paper.Status = InZone
}

item Paper
{
    trigger (false)
    {
        Name        = "Papier"
        Description = "Ein Stapel Papier mit leeren Seiten."
        Media       = Image
        Icon        = Image_I
    }

    trigger ((Status == InZone) & (Monastery.Story == Entered))
    {
        Commands = @( Take )
        Location = Monastery
        Visible  = true
        Allocate = true
    }

    trigger ((Status == Taken) & (GameState.Items == Visible))
    {
        Location = Player
        Visible  = true
        Allocate = true
    }

    command Take ("Nehmen")
    {
        Builtin:Dialog("Du nimmst den Papierstapel.", Image)
        Status = Taken
    }
}

Everything could be freely moved around, even the zones could be randomized, with literal coordinate definitions.

routine [point]    Meadow_Point () { return (              point(N51.547019, E007.301560)         ) }
routine [area]     Meadow_Area  () { return ( area(circle, point(N51.547019, E007.301560), 10, 6) ) }
routine [distance] Meadow_Proxi () { return ( distance(10 m) ) }

All texts are calculated on-the-fly, so you can do some fancy stuff if you like.

routine [string] GetDescription ([string] Location)
{
    return (
        '"' ..
        Builtin:RndStr(
            "Schau auf meine Karte.",
            "Ich zeige dir den Weg auf meiner Karte.",
            "Hier sieh mal, meine Karte."
        ) ..
        " Du gehst hier vorne los, " ..
        GetParts() ..
        "und hinter " ..
        Builtin:RndStr(
            "dem Dornenwald",
            "den Feuergeysiren",
            "dem Drachenhort",
            "dem Brennesselfeld"
        ) ..
        " kannst du bereits " .. Location .. " am Horizont " ..
        Builtin:RndStr("sehen", "erahnen", "erkennen") ..
        " und nicht mehr verfehlen." .. '"'
    )
}

I could go on and on with bragging, but you get the picture. Allow me to give some general advice in no specific order.

Keep it simple.

Do you really need arbitrary zones? Given a single, central point and some distances for circles around this point, I can tell you out of my sleeves how to check if you're inside or outside of one of these circles: Pythagoras with the x and y differences to the central point. You can do hundreds of these calculations on modern devices without producing a significant delay.

How do you do the same check for arbitrary polygons? Read the Wikipedia page (https://en.wikipedia.org/wiki/Polygon), then you tell me. How fast will it be? The advice goes to not show more than 7 or such zones at once, or the Wherigo playing may become a really slow experience.

You have to support this everywhere, in the builder apps, in the player apps. Once your math wizard leaves the project for whatever reason, someone else has to maintain the bubbling cauldron with the funny colored, yet strange smelling smoke he left behind. One wrong ingredient -- BOOM!

If you have to, my advice is to allow the creator to draw arbitrary enclosed zones. Then he can set single central points with circles around it inside this zone to cover as much of the polygon zone as possible. Circular zones that belong together get the same ZoneID, and then enter/exit is based on these ZoneIDs. Enter any given circle, and you're inside this zone. The exact lines of the polygon won't work anyway with the typical GPS drift.

Do some additional zone locking as already mentioned here, to avoid drift and sudden jumps. In my system I tested with dynamically growing the zone borders by some meters when the player enters. So when he enters and immediately stops, he has to go some significant way back to trigger the exit event. But if I remember correctly, I finally did it with using the zone enter event to enter, but the proximity exit event for exit, which has the same effect.

    event OnEnter ()
    {
        if (Story == InSearch)
        {
            Builtin:Dialog("Du erreichst einen dichten und undurchdringlichen Busch.", Image)
        }
        Story            = Entered
        Player._Location = Bush
    }

    event OnDistant ()
    {
        if (Player._Location == Bush)
        {
            Player._Location = _Nowhere
        }
    }

Carefully chose the tools.

You're developing a distributed system. You need builder websites or apps. You need a compiler that produces the cartridges. You need player apps on the mobile devices from different vendors, distributed through different shops. And then you have the cartridges, created with a lot of blood, sweat and tears. Depending on how much the creator needed to fight the toolset to finally get it running and published, he possibly won't touch it again with a 20 feet pole, even when changes are necessary.

And then there comes a breaking change in the environment. Let me reference my old documentation.

Lua Gotchas

Some significant changes were made between Lua versions 5.0 and 5.1, and
unfortunately they interfere with the different Wherigo players, which may be
based on different Lua versions.

The mod operator % was introduced in 5.1 and the math.mod() function was
removed. A separate mod function was used for Builtin_Randomize, while the
Shift calculation in Builtin_Decrypt was changed to a manual count and compare
(which may be more efficient than multiply and modulo, anyway).

The hash operator # for tables was introduced in 5.1 and the equivalent
table.getn function was removed. Builtin_RndStr was changed to manually count
the number of elements in the array. Although the Java based Desktop player
that had math.mod still implemented worked well with the # version. There is
no documentation about the existence of the # operator in the 5.0 language
reference.

Breaking changes in a basic programming language for a distributed system. That's a technical armageddon. Fortunately, these changes didn't seem to be significant for the old Wherigo ecosystem, only for creators who handcraft their LUA code, like me. Just imagine what have happened if these were significant. When you update the builder and the player apps, you're leaving behind all of the old cartridges that their creators won't touch again with a 20 feet pole, ever. These just stop to work. Gone.

When you think about supporting the old cartridges for downward compatibility, my advice is to think twice. You have to support all of the old unfixed errors and gotchas from the past.

Document everything down to the bit.

One of the unfunniest things that could happen to a developer is an API or a data format that is undocumented, and that you have to guess. It's unreliable even if it seems to work, it could be changed in the future so it stops to work. Your usage of it may open a security hole that allows to infiltrate the system, but will never be fixed, because it is undocumented and you're not supposed to even use it.

Again, let me reference my old documentation about character encodings.

The Wherigo online compiler performs an encoding step of the Lua source before
compiling it into bytecode. The Lua bytecode starts with the filename of the
sourcefile, and that has the extension enc, not lua.

    @E:\webtempfiles\<GUID>\<FileName>.enc

Within this encoding step, CR/LFs and the HTML control characters & < > are
encoded to their HTML entities, in case of CR/LF to some hybrid.

    CR -> "<BR>\10" 3C 42 52 3E 0A
    &  -> "&amp;"   26 61 6D 70 3B
    <  -> "&lt;"    26 6C 74 3B
    >  -> "&gt;"    26 67 74 3B

This is done for all string literals. The resulting text is also used in the
GWC header. Other conversions to HTML don't seem to happen, and it is yet
unknown if any others are supported by the different players. Additionally, it
is unknown how sophisticated the conversion is performed, and if all string
literals in complex nested expressions or the return values from function
calls are completely converted.

The special characters ä ö ü Ä Ö Ü ß are handled differently.

For the GWC header, they are substituted by question marks:

    66 3F 72  f?r

Within the Lua code, they are converted to UTF-8:

    66 C3 BC 72  für

        Win Utf-8
    ä   E4  C3 A4
    ö   F6  C3 B6
    ü   FC  C3 BC
    Ä   C4  C3 84
    Ö   D6  C3 96
    Ü   DC  C3 9C
    ß   DF  C3 9F

This has been found in at least one Wherigo, where it is unknown how they were
entered in the first place. The exact behaviour of the online compiler and the
support by different players has yet to be explored further. Additionally, the
conversion to UTF-8 is done in the Wherigo Builder, when compiling locally,
for text fields where the input of special characters is supported, e.g. in
MessageBox texts.

For some inputs, the Wherigo Builder compiled to &nbsp; as well, so it is
assumed that this is supported by the players. However, it is currently not
supported in the scripting system.

As you see, it is an inconsistent mess. I've solved it in my script system by providing all special characters in variables, and building all the strings dynamically based on these. That has the nice effect that I could implement a permanent toolbox item in the inventory, where you could change the character encoding within the game.

The script system supports both the creation of the Lua file that can be
uploaded to Wherigo.com and be compiled there, and the local compilation to a
GWC cartridge with full conversion of encodings. For all critical characters,
variables are defined at the beginning of the Lua code. This centralizes all
encoding problems to one single place.

    C_CR     Carriage Return
    C_AMP    AMPersand
    C_LT     Less Than
    C_GT     Greater Than
    C_LAUML  Lowcase A UMLaut
    C_LOUML  Lowcase O UMLaut
    C_LUUML  Lowcase U UMLaut
    C_UAUML  Upcase A UMLaut
    C_UOUML  Upcase O UMLaut
    C_UUUML  Upcase U UMLaut
    C_SZLIG  SZ LIGature

For the Lua upload, C_CR is defined as

    C_CR = [[
    ]]

while for the internal compiler, it is defined as

    C_CR = "<BR>\10"

The supported character set is differentiated into functionality sets.

Splitting characters are not directly stored into string literals, but result
in a string split with a concatenation of the defined variable. The caret is
used for CArriage RETurn.

    ^ & < > ä ö ü Ä Ö Ü ß

    "Für^Zeilenumbrüche"
    "F" .. C_LUUML .. "r" .. C_CR .. "Zeilenumbr" .. C_LUUML .. "che"

Do not leave anything affecting the player's experience to guesswork. Define it, document it, and then stick to it everywhere.

Handle the result of the user's creativity as sacred.

The original Wherigo builder was a buggy catastrophe. That's one of the rare occasions in life about which everyone agrees, who was unfortunate enough to ever use it.

Imagine you write a document with Microsoft Word. When saving it, Word renders it as a PDF, which is written. When it is reopened, Word takes the PDF, analyses it for pictures and paragraph positionings, OCR's the text back into single letters and words, and present the result back to you for further editing.

That's pretty much what the original Wherigo builder did with your cartridge. It stores it as LUA code, and when you want to continue your work, it parses the LUA code back into the GUI objects. It works. Somehow. Often enough, the save operation produces bugs in the code. Often enough, the load operation produces bugs in correctly saved code, resulting in wrong data in the GUI. Often enough, the load operation completely fails with some correctly or incorrectly saved code, leaving the unwary user, who doesn't know much about programming or programming languages, with a big question mark of what to do now.

And if he forgot to manually make backups, he is stuck with possibly days of lost creative work, which may be a complete showstopper, resulting in him giving up his project.

Don't be the guy who produced a tool that is responsible for that.

Please provide an automatic backup system that regulary saves the current state of editing, even if the user never cares. Backup is easy. Restore is hard, and usually left out as an exercise for the user, who has to wade through hundreds of backups to collect what he needs. So you may go the extra mile, and provide a restore functionality with an easy graphical choice. It would be a nice and outstanding touch.

While we are at it, the storage format of your builder apps is also one of the things that should be carefully designed, fully defined and fully documented. Today we have all the funny, text based and human readable formats like JSON and XML, for quite some varying degrees of "readable", so don't even think about using some opaque binary format. This includes all the media, thanks to Base64 encoding.

For an online builder, I take it as granted that I can download the full storage file with *MY* creative work, to save it in my local backups. As for providing security checks for hand-modified uploaded and imported storage files, well, there is a big $$$ security industry for a reason. That requires a careful and educated evaluation for how deep you want to travel into the darkness.

I've made my 1000 miles journey, met many strange creatures and characters, found my fair share of powerful and mysterious items, solved countless riddles and tasks, but I'm still not in proximity range of the core zone. Above all, it's still a hobby, so have fun.

January 29, 2023

Following! It's good to see that the topic is alive and well.

January 30, 2023

First of all thank you Forest-Ghost for the invitation to participate at this discussion forum. I am an Italian geocacher and I love wherigos.

I currently have 20 active Wherigo's, some developed with Earwigo and others with Urwigo. Not having a deep knowledge in programming my contribution to this Forum will be rather limited but I will follow the development of this project with great attention.

January 30, 2023

On 1/28/2023 at 2:48 PM, 48xor48 said:

I went the full way of 1000 miles into madness, step by step. In the end, I had developed a Wherigo scripting language that completely abstracted away most of the dirty little details, so I could concentrate on the story and the game

This is beautiful insanity, I am baffled, and I really wish I had known about this earlier because it would really have made my life easier when writing cartridges Did you consider open-sourcing your compiler?

Regarding the rest of your message, I agree with you on most points. You are right that many technical details of W1 actively make developers' lives hell. Not just cartridge devs but also engine devs (I would know; I had to backport Lua 5.2 fixes into a C# port of Lua 5.1 in order to support WF's player engine). My general solution for most of the problems you mention is: let's throw away Lua and move to a language that comes with a strong community, ecosystem and toolkits. The fact that we virtually cannot use any Lua lib without crashing half of the player apps out there is a shame, and that the bytecode is stuck to an almost unmaintainable Lua 5.0/5.1 is a disgrace.

Personally my favourite language is by far C#, it's very well documented and designed, comes with a very strong baselib, and has a robust community making lots of good code available. We don't have to have the cartridge API target C# (although, like Ranger Fox, that'd be my personal choice); but the player and builders very well may, since the WF.Player.Core engine already solves a lot of the problems you mentionned, and can serve as a common model and processor for players and builders alike. Also it supports geometrical testing of arbitrary polygons quite fine

3.3k · January 31, 2023

7 hours ago, Mangatome said:

Personally my favourite language is by far C#, it's very well documented and designed, comes with a very strong baselib, and has a robust community making lots of good code available. We don't have to have the cartridge API target C# (although, like Ranger Fox, that'd be my personal choice); but the player and builders very well may, since the WF.Player.Core engine already solves a lot of the problems you mentionned, and can serve as a common model and processor for players and builders alike. Also it supports geometrical testing of arbitrary polygons quite fine

Just thinking aloud on this, but if the player app and cartridges ran in WebAssembly, we'd be able to do everything on a website without need of an app. When I was playing around with a preview of Blazor three years ago (practically to the day, based on some of the files' timestamps), I messed with making a web-based player and a player API I could then call into for cartridge events. It was more for me to play around with than anything else. I was trying to see how close to the current format I could come. I did manage to make something I could play with, complete with a map, zones, events, dialogs, and inputs.

It's not much and I doubt it works with the production version of Blazor, but you can poke around in it. The Overlook zone is where I played around with different inputs and introduced a dialog that played a video from YouTube. You can pick up the source code from here until I remove it: https://www.wherigofoundation.com/temp/Wherigo_Player_Next_20200130.zip

Had I intended at that time to create Wherigo v2 or even make a production player and API, it would have been a lot different. I was just playing around a couple nights to see what was possible, then moved on since I needed to use my after-work hours for work-related things (yes, it was during that job that took over much of my non-work life for a few years).

February 1, 2023

Thank you for inviting me to the group! This sounds exciting! So I have been playing with wherigos since it started. I call them my outdoor interactive video games😀 I am not a programer! However I do have a good understanding of how they work and can figure it out. The Wherigo kit is good its easy and simple I know a lot of cachers who have used it with no problems. Keep in mind not everyone is going to like what ever gets accomplished here. I ask people what they don't like about them #1 answer they take too long blah blah blah. Well those people are usually numbers people who could care less about an adventure! Ignore them! They usually don't even play them they get final coords and don't even play it.

So what ever you do with this I will help if I can

3.3k · February 1, 2023

6 hours ago, A Team Vallejo said:

those people are usually numbers people who could care less about an adventure! Ignore them!

... ... ... I'm being ignored?

Jokes aside, I look at it this way: people have a certain amount of temporal capital and invest it in ways they believe will provide the desired returns on such an investment. If you're looking for adventure, there may still be competing caches which advertise to provide that should you spend your temporal capital on them. A Wherigo author would need to be able to compete with those caches, advertising on their listing page about the enjoyment the experience will give. If you're looking for numbers, I guess there could be a series of reverse ones?

In the end, Wherigo shouldn't always have to compete with geocaching. I don't mind sharing a portion of the user base with geocaching, but Wherigo does need to have its own distinct user base. To do that, we need good tooling for authors, help articles and tutorials for authors, an easy experience locating and downloading cartridges for users, compelling and interesting author-created content, cartridges working flawlessly in the player app, and an engaging scoring system (and perhaps the Invaders meta game would help with engagement).

Once it no longer becomes possible for geocachers to download the cartridge files, that'll cut down on a good deal of coordinate acquisition. The reverse Wherigo solver websites would still contribute to a significant amount of coordinate leaks, but that has become the Wherigo equivalent of a park and grab, so if that's what the author wants, that's fine. And we'll always have geocachers sharing final coordinates. We shouldn't be too concerned with the geocacher side of things beyond this if we're aiming for an audience all our own.

At this stage, feedback and ideas would be very helpful. Later on, volunteer for something based on your skills. Not everything will be programming. You could test, contribute artwork, create some ideas for demonstration cartridges, make some tutorials, give feedback on feature ideas and UI designs, make videos, and so on. Everyone should be able to find some way to contribute because everyone has a different set of skills and experience. And since everyone is volunteering their time (back to temporal capital), it's both appreciated and needed. We'll work at whatever pace we can afford. Even as little as one hour a week will still push things towards completion.

Keep a watch for any topics labeled "Wherigo v2". Not everything discussed will be in this one thread.

February 3, 2023

Hi,

Thank you Forest-Ghost for the invite. It seems like a great project.

A quick introduction. I've been geocaching since 2006 and I live in Sweden. I have logged geocaches in all 50 states in USA. I have published 26 Wherigo cartridges. Mostly in Sweden, but also one in Greece. I have used several different ways of making Wherigo: Groundspeak, Urwigo, Earwigo, Wherigo\\Kit... Once I held a course for other geocachers "How to make a Wherigo".
I have studied different programming languages. C++, Python and Java. The last years I have mostly used Java. I also teach Java programming. I have also studied Web programming.

/Mr_Finder

February 11, 2023

Like most people here I got an invitation from Forest-Ghost.

I make my Wherigos with Earwigo and am actually very satisfied with it. The main problem is in my eyes the stability of the player. with some it works, with the other not, you could also throw a coin...

unfortunately my programming skills are limited, even though i have made very sophisticated cartridges in the meantime. The routines are cumbersome & bumbling.

The lack of time is also a problem, but I sincerely wish you much success!

I'll be sure to check the forum from time to time.

3.3k · February 13, 2023

Yes, about the player app...

What is the consensus about this? Are the player's stability problems related to:

The player's implementation
The API a cartridge uses to communicate with the player
How some cartridges are built
The use of lua for cartridges

I don't mind switching cartridges to being built using some sort of WASM or just straight C#, supposing we can prevent authors from using networking features that would compromise users' security and privacy. While there are many wondrous things people can do if you gave them unrestricted network access, there are likewise a lot of things you wouldn't want them doing.

I don't mind creating a cross-compiler so lua-written cartridges could be translated into some sort of other code that's faster and more stable. However, something like that is outside my current capabilities.

Anyway, the current question is whether we wish to remain with lua or switch to a different language. As long as we can guarantee stability, I don't mind remaining with lua unless there's a more compelling reason. (If cartridges could run on a Pocket PC in 2008, I don't see any reason they shouldn't be performant on 2023 hardware.)

February 13, 2023

is there any way we can get rid of the "reverse wherigos" or is this something that will skew the numbers forever?

3.3k · February 13, 2023

11 hours ago, syfun said:

is there any way we can get rid of the "reverse wherigos" or is this something that will skew the numbers forever?

The reverse Wherigos are like the geocaching equivalent of light poles, traffic signs, and guard rails. I would rather not interfere with what cartridge authors submit so long as the cartridge does not involve content inappropriate for children or anything copyrighted that might get us as a content-hosting service in trouble with the copyright owners.

Instead, I would like to let the scoring and other systems encourage usage. Reverse Wherigo cartridges might be worth fewer points if people consistently find them--and since the person putting out the geocache doesn't own the listing or is a contributor, they won't receive any points within the Wherigo scoring system. And since the reverse Wherigo cartridge won't be listed multiple times within the Wherigo cartridge listing service, it won't be a target for the Wherigo Invaders metagame, further decreasing the likelihood someone on the Wherigo side would want to implement something.

In the future, you might want to worry about cartridges with only one zone. This might slightly skew the numbers. I'm hoping that by their being completed quickly and easily, they'll likely consistently be worth less points in the scoring system. (If you haven't read that post, please do.) Perhaps by also implementing a kudos, favorite, or other feedback system, authors of more popular yet less-completed cartridges will also receive a larger point kickback from completions in the long run than someone who created a park and grab equivalent. (Don't forget that, unlike geocaching, the Wherigo v2 scoring system will not equate one completion with one point.) I suggest you contribute in the scoring system topic some ideas that will encourage the activities you (as a community member) wish to encourage. I will eventually have to turn the scoring system into a mathematical formula.

And I hope that not all of Wherigo's user base will overlap with geocachers. We need a user base of our own. That's where we might run into one-zone cartridges.

February 14, 2023

On 2/13/2023 at 2:12 AM, Ranger Fox said:

What is the consensus about this? Are the player's stability problems related to:

The player's implementation

The API a cartridge uses to communicate with the player

How some cartridges are built

The use of lua for cartridges

In my opinion, the biggest problem is clearly the first, as evidenced by the disparity of behaviors a simple operation such as `os.time()` can yield depending on the player app (let alone the OS) due to various Lua implementations being used. And don't get me started on other parts of the base Lua library, for example math functions, which used to simply crash the Groundspeak iOS player because it hadn't been built with the math library. And of course, not to mention the varying support for basic Wherigo constructs such as proximity events, which may not even fire on some apps - I suppose, because of various implementations of the player.

All the other issues are very secondary. As long as a cartridge respects the API, it should work consistently. The unreliability of players comes from the variety of implementations.

So, clearly, on the player side, our number 1 priority should be to provide the community with a single player app that is built and distributed on all relevant platforms. For smartphones/tablets, this is going to be rather easy thanks to existing frameworks like MAUI or Unity, React Native etc (although I'd rather stick with C# and .NET on the player side). For GPS devices this may require to write alternative code bases if there is outstanding community demand (for instance a Monkey C app for newer Garmin devices).

Making a better player, that works consistently across all devices people use. I think that should be the goal, and I think we're closer to it than we'd think.

On 2/13/2023 at 2:12 AM, Ranger Fox said:

I don't mind switching cartridges to being built using some sort of WASM or just straight C#, supposing we can prevent authors from using networking features that would compromise users' security and privacy. While there are many wondrous things people can do if you gave them unrestricted network access, there are likewise a lot of things you wouldn't want them doing.

This may be a bit tricky due to sandboxing having been removed from .NET starting with .NET Core. There might be other strategies but that'd require some research. Also, do we really want to be more restrictive than the OS? If you're concerned about cartridge code exfiltrating sensitive data such as geolocation, this is something we could fix at the compiler level, by processing cartridge code and figuring out what goes in the network. Though, I admit, this would be a bit convoluted.

But the question remains: are we restricting cartridge devs too much if we strip away the ability to reach the network?

On 2/13/2023 at 2:12 AM, Ranger Fox said:

I don't mind creating a cross-compiler so lua-written cartridges could be translated into some sort of other code that's faster and more stable. However, something like that is outside my current capabilities.

Anyway, the current question is whether we wish to remain with lua or switch to a different language. As long as we can guarantee stability, I don't mind remaining with lua unless there's a more compelling reason. (If cartridges could run on a Pocket PC in 2008, I don't see any reason they shouldn't be performant on 2023 hardware.)

What you describe can be done with LLVM, if I'm not mistaken.

But concerning whether or not to switch, I see it as a tradeoff. The main issue with Lua in my opinion, is that it's locked in Wherigo at a deprecated version. This makes it very annoying to keep it in sync with the evolutions of the Lua baselib and API (read: no player developer bothered to do so, leading to the inconsistent reliability of Lua base lib support in player apps). If we keep Lua we should at least use the native Lua implementations and stop relying on version-locked bytecode for cartridge code. This implies that the cartridge code should be compiled by the player at runtime (using the player's built-in version of Lua); or that the player should be able to load Lua bytecode for all major versions supported by the compiler.

Edited February 14, 2023 by Mangatome

3.3k · February 15, 2023

@Mangatome

Then from your perspective, we have not yet reached the limit of what we can do with lua if done correctly.

What will need to be done is the following:

The player app should be able to run one version of lua for all v1 cartridges (retaining compatibility, such as it is). We will run all v2 cartridges in the latest version of lua. When the player app requests a cartridge from the Wherigo API, the player app's current lua version will be included in the request. The Wherigo API is responsible for compiling a cartridge with the requested lua version. As long as the Wherigo API is updated prior to releasing an updated version of the app with a newer lua runtime environment, things will work as expected. In this manner, we can also deal with old versions of the app. (The Wherigo API reserves the right to tell the app when it is too old and must be upgraded.)
Updates to the player app could include updates to either the lua environment or player app API. Because of this, once we expose an endpoint to a cartridge, it is fixed in stone and cannot be changed. I know how to version web-based APIs, but have not yet put time into determining how to version the player API. (In other words, we need to guarantee cartridges built in 2024 will still be able to run when the year is 2030--or even cartridges created in 2026 using a 2024 version of Urwigo.) I imagine we could just have an interface per player API version, which when upgraded will simply chain call into the newer method.
As mentioned above, the Wherigo API's compiler service would need to load the compiler appropriate for the request. (I'll likely store a compiled cartridge when requested for the first time, then skip the compiling step during subsequent requests.)
We will need to have living documentation that covers the player app's specification: lua versions, required libraries, and the player API (not only the part that allows interaction with the UI, but also that allows the subset of network features we desire).
I would like cartridge state to be kept separate from the lua version if at all possible. I want to work on a more robust state management API.

Other thoughts:

I certainly don't mind exploring a version of player app that will allow cartridges to be written in C#. You definitely know player apps better than I: how difficult would it be to construct interfaces for the player app such that we could easily drop in different types of cartridges? Even if we stay with lua, that's my intent to preserve compatibility with v1 cartridges while continuing to update lua for v2 (unless we decide each cartridge's manifest can tell the player app the lua version against which it's supposed to run).
My first priority is to everyone's security. I still would like to allow authors the ability to use network resources, so how about this idea? When an author wishes to use network resources, their cartridge can undergo review. Once approved, that particular URL scheme will be whitelisted for that cartridge. When a player app downloads a cartridge, it can also download the URL whitelist. The player API will expose a network layer whereby it will only allow whitelisted URLs to be called. In this way, we maintain security while at the same time giving authors the ability to consume network resources.
As for in what the player app will be coded, I must leave that up those who will volunteer for the player app. My preference is for the environment to be something in which most people are familiar. That way, when some volunteers have to step away for a while, other people can take up the responsibility with not as much of a learning curve. My preference is MAUI or Blazor Hybrid. I know Groundspeak seems to like React Native (their Adventure Labs app is built using that), but Wherigo v2 is not going to be a Groundspeak project (though I still want Groundspeak's backing).
For developing all this, I'll want public GitHub repos with a couple project leads (always more than one since we're all volunteers) set up to review and merge pull requests into the trunk. Anyone in the community can make a pull request. Whether we want these repos initially private is still a good question.
I'm glad we're not all jumping into coding this.

And some public news: I attended a mega event last weekend, and Jeremy from Groundspeak was there. We'll set up a time to talk with each other and see if I can get Groundspeak to agree to let the Wherigo Foundation run Wherigo if we can deliver.

February 15, 2023

30 minutes ago, Ranger Fox said:

The Wherigo API is responsible for compiling a cartridge with the requested lua version. As long as the Wherigo API is updated prior to releasing an updated version of the app with a newer lua runtime environment, things will work as expected. In this manner, we can also deal with old versions of the app. (The Wherigo API reserves the right to tell the app when it is too old and must be upgraded.)

This feels... awkward. I think of things like bitwise operators (which were introduced in a more recent version of Lua.) We may want to consider writing "polyfills" (somehow) for such things, so that the final bit ("reserved the right to...") is invoked only when it is absolutely 100% necessary.

34 minutes ago, Ranger Fox said:

When an author wishes to use network resources, their cartridge can undergo review.

Who's going to do this work? And how "deep" do they go?

Checking that the files the cartridge downloads are (say) family-friendly?
That the CO doesn't eat through people's mobile data caps by streaming 4k video?
That the CO hasn't got anything malicious running that "picks favourites"? This would require the CO to provide Reviewers with access to their server.

(I will ignore the fact that the CO can alter the behaviour of their site after publication, which further complicates things.)

Why not prompt the player ("This cartridge requests network access. It would like to communicate with XYZ.com."), and let them decide if that's something they're comfortable with? For users that are on limited data plans, the app could have an option to re-prompt every X MB of data consumption.

February 15, 2023

8 hours ago, Ranger Fox said:

@Mangatome

Then from your perspective, we have not yet reached the limit of what we can do with lua if done correctly.

Overall, I agree. If we stick with Lua as a backend to sandbox Wherigo cartridges in the player, we'd save ourselves some trouble. Besides, thanks to projects like LLVM, Roslyn and others there are strategies to convert C# code to Lua. So, this will be a question more for the editor apps than for the player apps.

And I think @Hügh is right, turning to polyfills could help extend cartridge lifetime.

I think that overall, we need to use separation of concerns as much as possible. The player app(s) will need to honour various versions of the Cartridge API and the server API will need to honour various players through versioning. The mechanisms you describe seem right to me, and I don't see any major roadblock in versioning Cartridge APIs player-side.

8 hours ago, Ranger Fox said:

I certainly don't mind exploring a version of player app that will allow cartridges to be written in C#. You definitely know player apps better than I: how difficult would it be to construct interfaces for the player app such that we could easily drop in different types of cartridges? Even if we stay with lua, that's my intent to preserve compatibility with v1 cartridges while continuing to update lua for v2 (unless we decide each cartridge's manifest can tell the player app the lua version against which it's supposed to run).

I think we are 90% there. The WF.Player.Core repo already defines an internal model to use something else than Lua as a backend. All entities from the v1 model are backed by interfaces in the data layer, so even if we stick with Lua, this out-of-the-box would let us switch from a Lua 5.1 to a Lua 5.2 backend. I say 90%, because I'd need a little refactoring pass on the code to upgrade it to newer versions of the language, code style, best practices and target platforms (Portable Libraries became .NET Standard since we wrote the engine). But the core mechanisms are here.

8 hours ago, Ranger Fox said:

When an author wishes to use network resources, their cartridge can undergo review. Once approved, that particular URL scheme will be whitelisted for that cartridge.

7 hours ago, Hügh said:

Who's going to do this work? And how "deep" do they go?

I agree that it doesn't feel right to add such a bottleneck in cartridge publication. It seems more flexible to let final users decide if and how to let all or specific network traffic through. If anything to facilitate development and experimental cartridges in events. I could envision a simple permission system in the player app like @Hügh suggested.

8 hours ago, Ranger Fox said:

As for in what the player app will be coded, I must leave that up those who will volunteer for the player app. My preference is for the environment to be something in which most people are familiar. That way, when some volunteers have to step away for a while, other people can take up the responsibility with not as much of a learning curve. My preference is MAUI or Blazor Hybrid.

I also would prefer a C#-based framework to back the player. However the feature set we want to support should influence this choice a bit, so I think we should gather needs from the community before deciding on the player tech. I too am glad we're not jumping into coding this

Edited February 15, 2023 by Mangatome

February 15, 2023

If I remember it correct, the only reason, why we didn‘t used a higher version of Lua was, because we wanted to compatible with the Wherigo.com website, which uses Lua 5.1 for compiling.

February 16, 2023

Hi,

here is my view of the Wherigo ecosystem in ASCII art. Feel free to reuse in any form, and to correct it without mercy if anything if wrong.

    +------------------------------+
    | Developer with Builder       |
    | writes/produces/generates    |
    |   +-----------+   +------+   |
    |   |LUA        |   |Media |   |
    |   |source code|   |      |   |
    |   +-----------+-+-+------+   |
    |                 |            |
    +-----------------|------------+
                      |
                      | Upload
                      V
    +---------------------------------------------------+
    | Wherigo.com                                       |
    |                                                   |
    |   +-----------+          +---------+   +------+   |
    |   |LUA        | compiled |LUA      |   |Media |   |
    |   |source code+--------->|byte code|   |      |   |
    |   +-----------+          +----+----+   +--+---+   |
    |                               |           |       |
    |   +-----------+ packaged      |           |       |
    |   |Cartridge  |<--------------+-----------+       |
    |   |           | Byte code, Media, player name,    |
    |   +----+------+ finish code, description          |
    |        |                                          |
    +--------|------------------------------------------+
             |
             | Download + Install in Player App
             V
    +---------------------------------------------------------------+
    | Player App                                                    |
    |                                                               |
    |   +---------+      +-----------+               +---------+    |
    |   |LUA      | runs |LUA        | calls         |API      |    |
    |   |byte code|<-----+byte code  +-------------->|Wherigo  |    |
    |   +---------+      |interpreter|               |Main loop|    |
    |   |Media    |      |           |<--------------+         |    |
    |   |         |      |           | calls back    |         |    |
    |   +-----+---+      +-----------+ Events:       +----+----+    |
    |         |                        Zones enter/exit   ^         |
    |         |                        Timer              |         |
    |         |                        User interactions  |         |
    |         |                                           |         |
    |         +-------------------------------------------+         |
    |                                                     |         |
    +-----------------------------------------------------|---------+
                                                          ^
                                                 presents | interacts
                                                          V
                   +----------------+             +-----------------+
                   |  Human Player  |    GAME     |  Display / GUI  |
                   |ALL OF THE ABOVE|<----------->|                 |
                   |IS DONE FOR HIM!|             |                 |
                   +----------------+             +-----------------+

Just some comments to some points from the last posts in random order:

1) Any limits are not set by LUA. LUA is a turing complete programming language. Anything computable can be done (in theory), with more or less efforts. All limits are defined by the Wherigo API. These limits won't go away when you change the language that runs the Wherigo.

2) Frankly, I don't see C# in place of LUA here. What do you even want to provide in the cartridges? Source code? MSIL/CIL code? Anything else? Without .NET, C# is basically just another C/C++ dialect that doesn't even provide lists and dictionaries as native types. In comparison to the simplicity of LUA, it's a moloch -- and I haven't mentioned VERSIONS yet. Yes, it may make a lot of things easier, but as said, it won't remove any limits of the Wherigo API.

3) Networking will be a nightmare. By all means, don't allow access to any random servers within the game. You're not planning the next Ingress, Pokemon Go or Harry Potter. You're planning Wherigo v2, basically a guided point and click adventure in the outdoors. Networking will be a nice group feature, but some local communication would suffice for that, whatever is the current state of the art. The same way the Wherigo API limits the possibilities, it provides compatibility for any features, so all communications should go here. Everything that circumvents the API will likely only work on that specific device type.

Some more ideas:

4) Given display capabilities of modern devices, why not provide images as an image matrix, where each cell can show a different image? It will provide many possibilities, from showing multiple characters in the zone, to the dynamic building of labyrinths out of predefined blocks, without the necessity to allow the dynamic generation of images. A simple single image is a 1x1 matrix.

5) State. Beside Zones, Items, Characters, Commands, and all that, provide a State object. The difficulty in handling the development of complex adventures boils down to effectively handle the game state. When the code checks if an item is in the player's inventory to find out where in the game it is, you need to save and restore all objects with all configurations, with all the hassle that is coming with that.

Let me recite the given example code of my scripting language to give some ideas.

state [enum] Paper.Status = @( None, InZone, Taken )

The type attribute "state" defines a game state variable, here of type [enum], thus a simple integer. Most of the states I've used are enums, therefore the complete game state is described by an array of integer values. Everything else is derived from that.

trigger ((Paper.Status == None) & (MonasteryLib.Status == Searched))
{
    Paper.Status = InZone
}

Global triggers (outside of objects) distribute changes in any state variable to other state variables. State changes are verified for really changing the old value, and directly marking the triggers that actually use this changed state. Thus only the triggers that may really be affected will be tested. By performing other state changes within these triggers, these may activate other triggers, thus this process is repeated until no more triggers were activated.

item Paper
{
    trigger (false)
    {
        Name        = "Papier"
        Description = "Ein Stapel Papier mit leeren Seiten."
        Media       = Image
        Icon        = Image_I
    }

    trigger ((Status == InZone) & (Monastery.Story == Entered))
    {
        Commands = @( Take )
        Location = Monastery
        Visible  = true
        Allocate = true
    }
}

After the global triggers are tested, the local triggers inside objects are tested once (with the same shortcut, of course). These only (re-)define the properties of the given object, there won't be any state changes inside these. trigger (false) contains basic configuration that remains unchanged by other triggers, and thus need to be done only once at the start. I've also used trigger (true), but I have to look that up. From the logic, it should be always activated -- actually I've never used it.

To save the game, just save all the state variables. After reloading these, all local object triggers are activated to reconfigure the objects. Done. No need to save any specific text, location or whatever.

February 17, 2023

I'm interested - I've made a lot of cartridges with Urwigo.... frankly scared of lua or any programming languages though...

February 24, 2023

On 2/16/2023 at 10:50 PM, 48xor48 said:

1) Any limits are not set by LUA. LUA is a turing complete programming language. Anything computable can be done (in theory), with more or less efforts. All limits are defined by the Wherigo API. These limits won't go away when you change the language that runs the Wherigo.

2) Frankly, I don't see C# in place of LUA here. What do you even want to provide in the cartridges? Source code? MSIL/CIL code? Anything else? Without .NET, C# is basically just another C/C++ dialect that doesn't even provide lists and dictionaries as native types. In comparison to the simplicity of LUA, it's a moloch -- and I haven't mentioned VERSIONS yet. Yes, it may make a lot of things easier, but as said, it won't remove any limits of the Wherigo API.

You are right that Lua has the advantage of being simple and versatile for programmers who enjoy procedural programming, but anything else is a can of worms (e.g. metatable madness for the simplest POO use-case). That makes it more annoying for engineering.

Also the core libraries do not shine by completness, so there is a lot lacking there. But maybe it's a better course of action to try and fill these voids with existing or new Lua libraries than having to wrap .NET platforms in all our player apps.

So, at this point, my thoughts on this matter is: Lua is nearly not simple enough for cartridge authors, as evidenced by the multiple testimonies above, but neither will be C# or whatever else scripting language. So it does not really matter what we use to sandbox cartridges, provided there exist robust and accessible pathways for people to make cartridges.

In a way we already have quite a few workflows, web-based or not, visual or not. Even your language is a nice addition to this ecosystem (please open source :D). Personally I'm missing a C# to cartridge pathway, but that's just my personal preference.

If Lua works for everyone and solves problems as a sandbox, let's keep it. But we'll have to invest in editor tools and resources, because it is my gut feeling that no one in this thread really enjoys or wants to write cartridges in Lua.

On 2/16/2023 at 10:50 PM, 48xor48 said:

3) Networking will be a nightmare. By all means, don't allow access to any random servers within the game. You're not planning the next Ingress, Pokemon Go or Harry Potter. You're planning Wherigo v2, basically a guided point and click adventure in the outdoors. Networking will be a nice group feature, but some local communication would suffice for that, whatever is the current state of the art. The same way the Wherigo API limits the possibilities, it provides compatibility for any features, so all communications should go here. Everything that circumvents the API will likely only work on that specific device type.

Agreed, so the cartridge-side API should evolve to include modern features such as networking. I agree with you that at first we could focus on supporting the use case of a party of players playing a cartridge together, which is in my opinion the most promising avenue for the game.

February 26, 2023

I'm already at friends with the idea of releasing my stuff. I think the language itself got pretty solid, starting with a formal grammar definition and including arbitrary nested expressions.

    Exp_Unary    = OP_ADD
                 | OP_SUB
                 | OP_NOT
    Exp_Paren    = BLK_LPAREN Expression BLK_RPAREN
    Exp_Elem     = Exp_Unary Exp_Elem
                 | Exp_Paren
                 | Literal
                 | Call
                 | Identifier
    Exp_Op       = CMP_EQ | CMP_NE | CMP_LE | CMP_GE | CMP_LT | CMP_GT
                 | OP_AND | OP_OR | OP_CONCAT
                 | OP_ADD | OP_SUB | OP_MUL | OP_DIV | OP_IDIV | OP_IMOD
                 | OP_POWER
    Expression   = Exp_Elem Exp_Op Expression
                 | Exp_Elem

The compiler implementing this, however, needs a complete rewrite, or at least a significant transformation into a different language. I did this as a personal project, without really thinking about releasing this, thus the comments, the error handling and the error messages, well, let's say it has a lot of potential for advancements.

Additionally, I just know that NOBODY will ever touch it as it is. It's written in VBScript. No excuses, no shame, I was very productive in that language. It is likely the most underestimated programming language in existence, and usually associated with large, ugly unreadable messes of white noise that runs flawless when you just put that "on error resume next" at the top of the script. With some additional luck, you will also get the results you've wanted.

Ugly code is rarely caused by the programming language, and most often by the non-existing discipline of the author. Given the state of the art with IDEs and editors, providing Intellisense and autoformatting of structures, it now requires real effort and ignorance to still produce really ugly code. As for the fact that VBScript doesn't provide even a rudimentary module system, in my POV any developer who isn't able to handwave some basic text based include mechanism for modularization purposes shouldn't call himself developer.

sub Include (FilePath)
    dim oFSO, oFile, Content

    ' WScript.StdOut.WriteLine FilePath

    set oFSO  = CreateObject("Scripting.FileSystemObject")
    set oFile = oFSO.OpenTextFile(FilePath, 1)
    Content   = oFile.ReadAll()
    call oFile.Close()

    call ExecuteGlobal(Content)
end sub

call Include("System\SystemConfig.vbs")
call Include("System\SystemLogging.vbs")
call Include("System\System.vbs")

call Include("Data\DataByteArray.vbs")
call Include("Data\DataBinary.vbs")
call Include("Data\DataList.vbs")
call Include("Data\DataNamedList.vbs")
call Include("Data\DataStrList.vbs")
call Include("Data\DataTree.vbs")

call Include("Syntax\SyntaxTokens.vbs")
call Include("Syntax\SyntaxTokenList.vbs")
call Include("Syntax\SyntaxParser.vbs")
call Include("Syntax\SyntaxNode.vbs")
call Include("Syntax\SyntaxNodeScope.vbs")
call Include("Syntax\SyntaxNodeScopes.vbs")
call Include("Syntax\Syntax.vbs")

But I've said "No excuses", so let's get back to LUA. I love drawing diagrams.

    +-------------------+
    |Groundspeak Builder|
    |Urwigo             |
    |Earwigo            |
    |My script language |
    |Any Other          |
    +---------+---------+
              |
              | Generates
              V
    +-------------------+
    |LUA Source Code    |
    +---------+---------+
              |
              | Compiled to (by LUA compiler)
              V
    +-------------------+
    |LUA Byte Code      |
    +---------+---------+
              |
              | Processed by
              V
    +-------------------+
    |LUA Interpreter    |
    +-------------------+

Byte code is basically a virtual machine language. The interpreter is basically a virtual CPU that processes the machine language. In this case, both make up a virtual machine running the game, with input and output interfaces provided by the Wherigo API.

This virtual machine is the heart of the game. Notice that the LUA source code is only an intermediate step. It is solely used to build the cartridges, but not to actually run these, thus it is perfectly possible to omit this step, and to directly produce the byte code. Let's ignore for now that this may not be a good idea - e.g. human readable and modifiable text vs. an opaque binary blob of data for which most non-programmers don't even know how to view it.

    +-------------------+
    |Groundspeak Builder|
    |Urwigo             |
    |Earwigo            |
    |My script language |
    |Any Other          |
    +---------+---------+
              |
              | Generates
              V
    +-------------------+
    |LUA Byte Code      |
    +---------+---------+
              |
              | Processed by
              V
    +-------------------+
    |LUA Interpreter    |
    +-------------------+

There -- we've just eliminated LUA as a language and the LUA compiler. All that is necessary for that is to write new Wherigo development tools that directly produce valid LUA byte code, instead of the source code. Can't be that hard -- give or take a few years.

While I am going with crazy daydreaming, let me turn the controls up to 11.

    +-------------------+
    |Wherigo v2         +-------+
    |Builder ecosystem  |       |
    +---------+---------+       V
              |              +---------------+
              | Generates    |Wherigo v2     |
              V              |Gaming Language|
    +-------------------+    +---------------+
    |Wherigo v2         |<---+Wherigo v2     |
    |Byte Code          |    |Assembly       |
    +---------+---------+    +---------------+
              |
              | Processed by
              V
    +-------------------+
    |Wherigo v2         |
    |Interpreter        |
    +-------------------+

There again, we've just eliminated any 3rd party dependency. We can define and control everything on our own. Provide the byte code with powerful general contructs so that developers can go creative. Provide it with specific constructs that optimally support the Wherigo gaming structure. Everything can be hand-tailored as needed, and we are in complete control of upward and downward compatibility, and of what is allowed and what is forbidden.

Not that I recommend that in any way, even though I've already created a rudimentary Gaming Language myself. The consequences would be devastating.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

1) You start at absolutely 0. Zero. Null. Nothing. When you take an existing system of language definition + libraries + compiler + byte code + interpreter, you have a working ecosystem. All you have to do is to make it run in your desired setting, and you can start to write and RUN the first experimental Wherigo v2 cartridges. For our new system, there is not even a single definition currently available.

2) It's a showstopper. It's the heart of the game. Nothing will RUN until it is designed and written halfway into completeness. No builder can be written against an undefined byte code that is still subject to change. Nobody will write any cartridge. Expect that state to last 3 to 5 years as a rough estimate.

I just leave that here as an idea for Wherigo v3.

My overall point is that the language itself, LUA, C#, whatever, is secondary. The important thing is the stuff that will be running from the cartridges in the player apps. Write a compiler that transforms C# code directly to LUA byte code, and you've created C# based v1 cartridges. Write another compiler that transforms C# code to LUA source code, or a decompiler that transforms LUA byte code back to LUA source code, and you can publish these cartridges as a normal Wherigo cache.

February 28, 2023

On 2/26/2023 at 4:32 PM, 48xor48 said:

My overall point is that the language itself, LUA, C#, whatever, is secondary. The important thing is the stuff that will be running from the cartridges in the player apps.

You make a good case for sticking with Lua, and I think it makes sense, to harness the experience and code bases the community has aggregated over the years. However I still think that, if we went this road, we'd need to bump to the latest Lua version, just to leave the possibility for a few humans to actually hack together cartridges from code.

February 28, 2023

5 hours ago, Mangatome said:

You make a good case for sticking with Lua, and I think it makes sense, to harness the experience and code bases the community has aggregated over the years. However I still think that, if we went this road, we'd need to bump to the latest Lua version, just to leave the possibility for a few humans to actually hack together cartridges from code.

A good case for LUA wasn't even my intention, like most others I can't say that I really like LUA, but still -- it's the option that is immediately available. Haven't yet looked myself, does anybody know how well the LUA byte code is documented? Is there some kind of documentation, or do you have to read the full LUA interpreter source code to get it all together?

I have taken a look into Webassembly today. Now that's a formal definition as far as formality goes. I got the feeling it takes three months alone just to read and understand that, and extract the information you really need for any practical implementation.

I've read most of the first page of this thread again, and got a few additional thoughts about some points.

Access to external video/audio: Web content tends to be removed or moves to different locations over time. When was the last time you've checked the availability of your bookmarks? I'm definitely a friend of cartridge-in-one-single-file (including the kitchen sink). 20 years from now, you at least have the chance to replay it in some emulator in completeness. External content that was removed is digital heritage that is lost forever. Not considering the fact that most of today's "content" should better get lost right NOW.

A lot of points and ideas could already be implemented for the current existing Wherigos, by writing a player app that supports just that.

Map-based with zones shown: Visible zones and invisible but active zones (the next target to go) are known to the API, else the enter/exit events couldn't fire. You can already draw them on a map.

Inventory as tiles - sure, what's stopping you? Items with their icons are known to the API. Display them in any way you want.

GPS stability -- the API is in control. It can decide that a sudden jump of 15 meters within 1 second is impossible, so it must be a glitch and it should keep the current memorized coordinates where they are. It can decide that the exit event for the current zone should be put into a queue to be fired later, because the player is currently in another dialog, trying to make a decision -- maybe even show a warning signal that the player better should stop moving around.

Stay with the old apps, and play with the old glitches and bugs. Or write a new shiny app in all glory. Of course, the motivation to invest the time in that is significantly higher when that is done for the full ecosystem with many new features...

3.3k · March 1, 2023

Okay, then let's do this:

Wherigo v2 cartridges will at first be in lua.
The player app will need to be built in such a way that we can swap the environments we're using. For all v1 cartridges, the player app will use that version of lua. For all v2 cartridges, we'll record the language and version against which it was built. When the Wherigo listing service API provides the cartridge to the player app, it will also provide this metadata. The player app can then load the correct environment and the cartridge itself.
- As time progresses, we would then be able to upgrade the lua version and even offer other languages for cartridges without breaking existing cartridges. We can also feel free to add objects and methods to the player API without upgrading the environment. If we modify objects or methods in the player API, we can then build that as a new environment.
Media must be supplied with the cartridge data when publishing a version of the cartridge. What the Wherigo listing service API does with this information is up to that system. However, the media does not need to be compiled with the cartridge code. The listing service API can provide media files to the player app either on demand or all at once. The listing service API also reserves the right to provide either the binary data itself or a URI for the media. (I would not prefer to serve binaries directly from the listing service API. Instead, I'd prefer to provide a URI to either Azure or AWS Storage so the listing service API can reply to more requests without having to scale out--though the API itself will me made specifically to be scaled out.)
The player app is given latitude with how it deals with coordinates and cartridge events. The player app might therefore process proximity/in events at the author-desired coordinates and distance, but distant/out events when the coordinates read twice the EPE away. The player app team can implement this however they wish.

Later, I need to start a thread about what people expect in the new version of the listing service. For all I can tell, everything I have in the current one is what we'll need, plus responsive design (and, oh boy, will I definitely need a UI/UX engineer and/or designer to help with the front end).

March 1, 2023

While researching a bit the Lua byte code, I've found this interesting Stackoverflow post from 2009.

https://stackoverflow.com/questions/1480678/luas-bytecode-specification

Quote

The only specifications for Lua are the language, standard libraries, and the C API. The creators of Lua intentionally left the VM unspecified for a couple main reasons:

Lua can be fully implemented with any underlying architecture (VM, interpreter, compiler, etc.)

The official Lua distribution doesn't have to worry about maintaining VM compatibility between versions

This means, for example, that you generally shouldn't use the Lua VM as a target for a compiler. If you'd like to know how the official Lua distribution's VM works as an example for your own curiosity, see the other answers.

And from the comments:

Quote

The Lua source code is merely a reference implementation of Lua, it is not "The" Lua. The only specification for Lua is the language itself, and the C API. Anyone can implement that specification using whatever underlying mechanics they want: VM, interpreter, FPGA/ASIC (physical chip). The creators of Lua have purposefully left it [the byte code] unspecified in order to make the language maximally flexible.

I read this as: Lua was neither designed nor intended for a distributed, interdependent system like the Wherigo ecosystem.

The language specification can change, as actually was the case. It is always the specification for a very specific version.
The byte code can change between versions. I don't know (yet) if this ever happened.

You can't update just a single component (Source generation in the builders / compiler on website / byte code interpreter in players), because it has the potential to break things. If you do an update, you do it all at once.

It's not a showstopper, the existing Wherigo ecosystem is a living example that it works. One of the key points could have been that the Wherigo website centralized the compilation for published cartridges, requiring the Lua source code. By this, it provided THE one and single reference implementation against which all cartridges must remain error free. Plus, that it's very likely that the byte code actually didn't change between 5.x versions. It's a very simple, machine language like command set, there simply wasn't a reason to do so.

What does that mean:

Make the choice for a Lua version. That's the version to go, no matter what's coming in the future.
Additionally provide the old version that is used on Wherigo.com to support the compilation of old cartridges, if you like.
Document and communicate that to developers of builders and players: This is the version we use. You support that, or else...
Collect free/Write new reference documentation for the chosen version, both the language spec and the byte code spec.

What's coming next?

Once the language spec for builder apps and the byte code spec for player apps is carved in stone, you can go wild with languages. Any language for which you can provide a compiler to either Lua source code or directly to byte code can then be used to write Wherigos.

March 2, 2023

17 hours ago, 48xor48 said:

Lua was neither designed nor intended for a distributed, interdependent system like the Wherigo ecosystem.

Spot on. The Lua bytecode is indeed version-specific and unspecified. The consequence is that it should be considered transient and therefore it should never have been part of the Wherigo specification. In my opinion, Groundspeak made a mistake there. What using the bytecode as a language for game logic does is locking the version of Lua that the ecosystem uses, putting very strong pressure on player and editor developers to remain compatible with deprecated versions of Lua. (I personally had to backport Lua 5.2 bug fixes into a C# port of Lua 5.1. I do not wish that on anybody.) This is unbearable technical debt, almost impossible to ever pay back, since the cartridges in the wild are forever locked to this format.

17 hours ago, 48xor48 said:

It's not a showstopper, the existing Wherigo ecosystem is a living example that it works. One of the key points could have been that the Wherigo website centralized the compilation for published cartridges, requiring the Lua source code. By this, it provided THE one and single reference implementation against which all cartridges must remain error free. Plus, that it's very likely that the byte code actually didn't change between 5.x versions. It's a very simple, machine language like command set, there simply wasn't a reason to do so.

I disagree there. Just because the bytecode never changed doesn't mean it will never change. The Lua authors clearly meant the bytecode to remain internal and not be persisted.

17 hours ago, 48xor48 said:

What does that mean:

Make the choice for a Lua version. That's the version to go, no matter what's coming in the future.

Strong disagree. That is precisely the mistake Groundspeak made, and this would equally lock us to a particular version of Lua, with the same maintenance and technical debt issues we currently encounter.

And what good would it do anyway? Really, why do we even need bytecode at all?

It's not necessary to execute code - the Lua interpreter can load text as code, obviously.
It's not necessary to obfuscate code in transit - it wasn't even good at it, and we could do better with encryption and a simple key exchange with the listing service API, if that was even ever needed.
It's not necessary to reduce file sizes - most of a cartridge's weigh is media, and there are good HTTP compression techniques nowadays.
It's not necessary to speedup runtime - cartridge code is usually small and will likely be interpreted very fast on modern devices.

So, personally, I would advocate for simplicity and flexibility:

the player app exposes to the listing service API the versions of Lua it supports
the listing service API returns a cartridge payload along with metadata, but
- for a Wherigo v2 cartridge, the logic is Lua X.Y code, compressed and obfuscated if necessary. The code targets the maximum version that is supported both by the player app and the uncompiled cartridge stored in the listing service.
- for a Wherigo v1 cartridge, it is the Lua 5.1 bytecode for backwards compatibility

3.3k · March 6, 2023

We're intending to build new methods against which cartridges can call. This itself is a change. We will need to track both the lua version AND Wherigo version against which a cartridge is created. For those who don't understand this, here's an easy example: when Wherigo v2 comes out, it'll likely support video files. We'll call this Wherigo v2.0. When we complete work for multiplayer and release that, it'll be Wherigo v2.1. The lua version, v5.4, didn't change in the meantime, however, a Wherigo v2.1 cartridge cannot be played on a player app that only has Wherigo v2.0. The user will need to visit their app store and download an update to the player app.

I intend for these tenants to be followed:

When a builder application contacts the Wherigo API, it must define the lua and Wherigo versions ("versions") against which the cartridge was created. The API can reject the command if the versions don't match ones it accepts. Both versions will be stored alongside that version of the source code (i.e. it isn't globally defined at the cartridge level, but at the version of the source code). The listing service will contact the building service, asking for it to perform a build of the cartridge against that lua and Wherigo version as a test. If it succeeds, the API will accept the source code and version numbers.
- For v2, we can decide to use token text when things like a user's name is requested to be placed into the cartridge. Therefore, it'll be up to the player app to substitute that token text when it comes across it. This would allow me to store and serve one compiled bytecode to all clients, reducing server resources and response time prior to a download begins. I like that idea. Wish I thought of it sooner. (We could possibly inject the player's name into a v1 cartridge to achieve the same effect.)
A cartridge author can choose to switch an existing cartridge to a new version of lua or Wherigo if desired. Simply use the builder application (or other tool) to upload the cartridge source code again, using a different version identifier. The API will once again perform a build validation against the building service.
The API will provide to any caller the lua and Wherigo version numbers it supports, including one endpoint that just says the current version numbers for all things.
When the API provides cartridge search results, it will include the cartridge's current version numbers. It's up to the calling application to know whether it can play such a cartridge.
When cartridge bytecode is requested, it will only be built against the lua and Wherigo versions against which it was uploaded. This ensures on our end that the cartridge functions true to how the author [should have] tested it.
The player app is responsible for loading the proper environment to handle a cartridge with this lua and Wherigo version number.
When deploying a new version of anything to the Wherigo ecosystem, updates must flow in this sequence: builder service, API, website (if applicable), player app, builder application. If this sequence is broken, bad things can happen. We could perform a preview release by allowing these to work with new versions without advertising it or enforcing a new version by default. This would help for testing. Communication will be crucial.

March 6, 2023

Hi,

It's been a while since I talked to you all. I've been quite busy and I'm not sure how much time I have to spend on here. However, I'm always interested in the subject, so I decided to at least respond now. :-)

For those who don't know me, I've been working on a Wherigo player in the past and was part of earlier discussions about v2.0. I'm a programmer, I like free (open source) software, and I believe users have the right to be in control of their own devices. In particular, I believe that if a player wants to cheat in a (single player) game, they should not be prevented from doing so. This may not be very relevant at the moment, but I thought it could be useful to mention so you understand how I generally feel about this.

So let me now way something about what Ranger Fox was writing:

5 hours ago, Ranger Fox said:

We will need to track both the lua version AND Wherigo version against which a cartridge is created.

Yes, this makes sense. The idea is to have the cartridge source on the server, correct? I believe that is important, because different Lua versions have near compatible language syntax, but incompatible bytecode. This means that it should be relatively easy to write code that will work with multiple Lua versions, but only as long as it isn't compiled. And I think we should allow players to include only one version of Lua, without making it impossible to run most cartridges.

Quote

For v2, we can decide to use token text when things like a user's name is requested to be placed into the cartridge. Therefore, it'll be up to the player app to substitute that token text when it comes across it. This would allow me to store and serve one compiled bytecode to all clients, reducing server resources and response time prior to a download begins. I like that idea. Wish I thought of it sooner. (We could possibly inject the player's name into a v1 cartridge to achieve the same effect.)

I think it would be a lot easier to inject the tokens into Lua as variables. No need for the player app to search and replace anything.

Quote

A cartridge author can choose to switch an existing cartridge to a new version of lua or Wherigo if desired. Simply use the builder application (or other tool) to upload the cartridge source code again, using a different version identifier. The API will once again perform a build validation against the building service.

This is good for making "certified" versions, but I think it would also be useful if players can attempt to compile cartridges for different Lua versions if the author is unresponsive and doesn't do this.

Quote

When cartridge bytecode is requested, it will only be built against the lua and Wherigo versions against which it was uploaded. This ensures on our end that the cartridge functions true to how the author [should have] tested it.

In other words, I would like for this to not be the case. It's fine if there is a giant warning about it, but it would be nice if it would be possible.

I think some authors may not like this, because you never know if the internals can be (more easily) discovered on a new Lua version. While it may give them a false sense of security (because this is possible from bytecode as well, no need to wait for a more "debuggable" Lua version), if they want an option to disallow this, I'd be open to that. However, if they select that option, it means that they are (even more) responsible for keeping the cartridge up to date. This should be made very clear to them.

Quote

When deploying a new version of anything to the Wherigo ecosystem, updates must flow in this sequence: builder service, API, website (if applicable), player app, builder application. If this sequence is broken, bad things can happen. We could perform a preview release by allowing these to work with new versions without advertising it or enforcing a new version by default. This would help for testing. Communication will be crucial.

Yes, properly documenting this process and having a test environment before making it live are indeed essential for a good user experience.

Thanks,
Bas

March 11, 2023

On 3/6/2023 at 4:32 AM, Ranger Fox said:

For v2, we can decide to use token text when things like a user's name is requested to be placed into the cartridge. Therefore, it'll be up to the player app to substitute that token text when it comes across it. This would allow me to store and serve one compiled bytecode to all clients, reducing server resources and response time prior to a download begins.

Isn't that already done in v1? The downloader's GC name and the individual completion code is not placed in the bytecode, but in the GWC cartridge header information. It is then made available to Lua by the API, if I remember correctly by Wherigo.Player.Name and Wherigo.Player.CompletionCode.

Additionally, I had some thoughts about the game graphics that allows some image dynamics without giving too much security away, e.g. by dynamically created graphic files.

The player app defines a "Viewport". This is the part of the screen real estate where the game code can show its graphics. That can itself be dynamic (depending on the current orientation of phone/tablet), it can be fullscreen with overlayed action controls, or whatever the player app allows the player to configure.

The game code defines a "Canvas" of a given pixel size. The developer of the game knows best what format the provided media has, so he knows best what he wants for that. When e.g. all images are of size 640x480, he defines just that for the Canvas. All drawing operations in the game are done on this Canvas. The player app proportionally projects the Canvas' content to the current Viewport, with necessary up- or downscaling and empty frames on left/right or top/bottom.

The Canvas drawing functions are provided by the API. The most important is a Blit function, that allows to draw any given rectangle from a predefined media image to any position on the Canvas. That already allows for a lot of freedom: Showing multiple images at once, drawing dynamic maps from tile templates, a world map that is only showing the zones you've actually visited in any order, or simply show the full image at position (0,0) on a 230x130 Canvas to support Wherigo v1 cartridges with the old limits.

When the API provides additional drawing primitives (point, line, (filled) ellipse, triangle, rectangle, ...), developers can go wild on the Canvas. I could imagine all that cool retro stuff, how about flying through space with old 8 bit Elite 3D vector graphics?

Most of the stuff required here (scaled projection, blitting, primitives) should already be available in the OS. Of course I wouldn't go too far here, else there will be incompatibilities between devices.

June 18, 2023

Howdy,

Very late to the party - I've been a bit "geo-dormant" for a while but I did build a few carts and did not build a few as some of the concepts I wanted I couldn't deploy (mostly time of day triggers, of graphical/sound triggered, more interaction with devices to progress, stuff like that) and what I was planning became quite high-concept, across many locations, with branching narratives and all sorts of random and crazy things I was just lost for time and inspiration.

However I do think there is plenty of life left in the platform yet - I've just recently played a couple of cartridges and they were very simplistic - might be that the systems to create them are limiting the scope/quality or maybe some of the creators just can't be bothered.

Either way I'd love to try to help out in any way I can. Not a coder but I do have connections, and connections in other areas I might be able to "borrow" - so yeah, happy to assist where I can or simply just get involved in discussions as required really.

Cheers

RC

October 15, 2023

What is the current status here?

3.3k · October 26, 2023

Nothing is happening. I'm not doing this alone. I'll continue to maintain and make available what I have, but I won't be making any progress on this. This is a team effort, not a project for one or two people. If people help out in things like design, art, app creation, and team organization, I'll work on it.

Wherigo v2: Feature List

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation