c# parsing/executing of lua Wherigo file

[+ATXTracker]

I'm looking to interpret and run Wherigo cartridges in c#. I have this working a little using NLua for .net, but I'm missing lua code for all the Wherigo objects (ex Wherigo.ZCartridge). I think this could be reverse engineered with a great amount of work, but I'd guess it already has been.

 

Can anyone share their effort running a cartridge in c#? Is there already some sort of Wherigo.lua code file available?

 

Happy Caching,

John

[+ATXTracker]

I see the Wherigo Foundation work. I had seen that before but didn't realize exactly the great work being done there.

 

Question: What is the output of the compiler? Does it compile to an existing format, or a new format.

[+charlenni]

The compiler generates GWC files. The same format as the original compiler produces. You could find the code on Github.

 

There is although a core in C# for a Wherigo player. It is used for a iOS, an Android and a WinPhone implementation. You could find this although on Github. Search for the Wherigo Foundation.

[Ranger Fox]

Join us. We have fudge brownies.

[+ATXTracker]

Join us. We have fudge brownies.

 

Maybe I will. Have you considered a web based player? Getting frequent location updates to the server might be a challenge, but it seems like that might be doable.

[Ranger Fox]

There's a web-based emulator available to us. You could equip it with the HMTL5 geolocation API and have a web-based player app.

 

If the location is updated every second, I do not want a client-server architecture. Just imagine how overloaded that poor cloud-based server farm would be if more than a thousand (or even ten thousand) people decided to play cartridges at the same time!

[+spstanley]

Plus one obstacle is that Internet connectivity is absolutely essential, so Wherigos in remote areas wouldn't work with a client/server model. But I do like the idea.

 

There's a web-based emulator available to us. You could equip it with the HMTL5 geolocation API and have a web-based player app.

 

If the location is updated every second, I do not want a client-server architecture. Just imagine how overloaded that poor cloud-based server farm would be if more than a thousand (or even ten thousand) people decided to play cartridges at the same time!