4th Year Anniversary

Background

In 2016, Pokemon Go came out and most of the world finally discovered location-based (“locative”) games. The overwhelming success of it, and seeing so many people start getting into the habit of going for walks at lunch breaks and trips on weekends, made me wonder just how long it’d take before someone fired up an open source version of it or something like it. In early 2020, well before people realized it was spreading in the US, I got covid and spent 4 or so months recovering from severe brain fog. Once I was self-aware enough to see that I’d spent a quarter of the year unable to process a complete sentence, I wanted to pick up a project to make sure I was able to actually think and code and learn unfamiliar stuff again. I checked around, and there was still nothing related to making locative games with open source code. I finally decided the person that had to make that was me. I started working on PraxisMapper in 2020 with little knowledge of OpenStreetMap data, no experience with a game engine, and a -4 INT penalty from the pandemic.

As of August something-th, PraxisMapper is 4 years old. It’s the open source suite for making locative games by a solo dev with as few external dependencies as possible. The core parts are PraxisMapper (the web server that handles running services), Larry (The bootstrapping and file processing companion app), and PraxisGodotComponents (The client library for Godot 4.2+ that handles talking to the server, GPS processing, drawing map tiles on the Android device running the game, and other common tasks). None of these components call out to Google Maps or MapBox or any similar 3rd party API, which both means there’s no surprise costs or scaling bill for the game developer and no silent tracking of the players and their data being sold to advertisers.

In Year 4 of development, the main focuses were finally processing global data and pivoting from server-connected features to using offline data and local processing. The server’s generic functionality is about as complete as it will be, and most ideas I’ve had have been game-specific and not reusable. It’s also fairly heavily optimized for the processing it does, and getting increased performance out of it will be tricky. 

It’s also a hobby project, not a commercial product, and this is reflected in its development. It works, but its focus shifts along with my specific short-term goals over time and it lacks in some areas that I have no interest in working on in my spare time (Units test and CI, among others). PraxisMapper is ‘good enough’ and I believe someone can grab it and make a game with it, but I cannot recommend using it as an introduction to game development. You need some intermediate level of experience, and possibly a willingness to grab the source code and tweak parts that don’t work for your specific setup.

Global Processed Data
I have said for years in my notes to potential developers and myself “Don't do global data, you don't need it”. Processing OSM data on the global level is dramatically slower than processing any extract file, and the number of players (and developers) that will actually use the full global data are few to none. I then went and ignored my own advice, and figured out what it’d take to do global processing to prove PraxisMapper could do it. With time and a new PC dedicated to processing these files, I got 2 full sets of global data: The 300MB minimize offline set, and the 43GB full detailed set drawable on devices.

The minimized data is something I’m quite proud of figuring out. By tracking only places that are very reliably good places to encourage people to go to, and saving each as 4 small numbers (x, y, radius, type of place as an int) in blocks, the entire planet can be gamified in about the same storage space as any 2 social media apps. The data is available on github, and small enough to be included in an Android game. I wrote the Weekend Space Command prototype to show off how the data can be used and posted that to itch.io. It is also included in the area control game/prototype I’m working on next. This data is not well-suited to drawing maps, as it's very hard for people to orient themselves on a map with few landmarks and no details beyond some colored circles. It does work well enough to detect when a player is at or near places for gameplay interaction purposes. Locative games have stuck to the “draw stuff over a map” UI since 2003, and this data works well enough to include in a game where that isn’t the key focus. Imagine an RPG where a wizard character could level up into a Necromancer by visiting a cemetery, or a druid by going to a nature reserve. You wouldn’t need to draw the full maps, just know if the player is at or near one and enable a button in-game to make it happen.

The full detailed map of Kokyo Kien National Garden, Tokyo, Japan

And again, to scale, with the minimized map data.

The detailed map data is also fairly impressive. These files can be drawn with 1 pixel being approximately .1 meter, and include most of the drawable elements from OpenStreetMap. Tiles can be drawn on demand, though there is a chance this may make the games too processing-heavy for the slowest or weakest of phones. The logic runs fine on a Pixel 4a for me, and my main device is a budget Motorola phone that's capable of running this, so I am not particularly worried about this potential performance issue right now. The current issues around this are mostly on how Godot handles drawing commands and viewports, and I’m continuing to improve this as I learn more about these.

One of the main pushes to get a global data set is to make it even easier to make locative games. PraxisMapper already makes all the steps as simple as it can get, and the only way to make it simpler is to do the baseline work and distribute the results instead of the process. I’ll have to keep rebuilding these files on roughly an annual basis, but if someone was to run a global game on their own it could be updated monthly. OSM updates their global file every week, and it takes about 18 days to run that through Larry into a database. Converting that database to output files is another couple of days. This is probably less important for a locative game than a map navigation app, where keeping updated info on roads or bike trails is critically important, but a monthly update cadence is possible.

Oh, most importantly: Do you want the pre-processed results, and to save yourself 2-3 weeks of processing time? Email me, praxismapper [at] gmail.  I can ship you a flash drive with all 43GB of data at cost. OSM license prevents selling the data for a profit, but allows for physical copies to be sold.

Godot 4

For the previous 3 years, my main examples and games were done in Solar2D. This year, I decided to drop that in favor of Godot 4. Initially the idea was to be able to use C# in my client app, but that did not work immediately when 4 launched. I also had to create my own GPS plugin for Godot in Android-native Kotlin to have one I could redistribute and not rely on Google Play Services. This was important to me, because I want everyone to be able to just grab the libraries and make a locative game, and I do not want to give any more data about the players to any third parties than necessary. Without the Play Services dependency, PraxisMapper games will work on phones that don’t have Google Play installed, which adds a significant amount of the world to the potential player pool. This also decreases the location accuracy, since using cell towers to aid in triangulation seems to be the key for most phones to get your position within 2 meters.

The Godot components are usable, though they’re not mature yet with about 6 months of development. An experienced Godot dev could probably improve these quite a bit on their own, but the library itself is workable in expected conditions as it is. Scenarios like “the player is driving on the freeway” still tend to cause issues as of today, and I’m working on making the components robust enough to handle those smoother.

Weekend Space Command is the first prototype put together with Godot as well as the global offline data. It shows off the logic for everything, even if it's not particularly pretty or polished. It can handle drawing tiles, and searching through offline and online data. It can sort places by type and push you towards better places to play at. It is an excellent learning experience for the developer. I had more ideas to continue on with it, focusing on an actual plot, but I decided that I had to get out of this first prototype and build up a better framework to keep going on. Something a little more presentable and usable for most players than this ended up being.

The Indie Scene

I also decided that the headache that is keeping up with Google Play’s constantly increasing demands for info on the developer isn’t worth the effort for the return, and have quit trying. Itch.io is the new home for all my games and demos now. Google’s refusal to run a search that’s remotely accurate without spending significant cash is the primary blocker. I searched for my own app, free without in-app purchases, by its full name and it would not appear higher than the 100th result. I understand that mobile is bombarded by apps and games of all qualities constantly, but it's truly egregious that a perfect full name match will not be shown in search results unless the dev has also thrown a few thousand dollars into advertising or Google can skim a similar cut from sales. Itch may also be a busy site, but it’s fair and accurate.

I also got a reality check while working on a Mastodon thread about the history of locative games. On itch.io, there were 16 existing locative games. 8 of them were dead due to mandatory server connections or accounts, and 2 more were unplayable due to technical issues. 4 of them had never been installed before, according to Google Play Protect. So the 25 downloads that Weekend Space Command (Prototype) got in 3 months? And 50 total unique player estimates across all my games and prototypes? That’s huge. Actually, honestly incredible. Any expectations I had of doing any better were not based in reality. As much as I’d like to have a game with an active player base in the thousands, that simply isn’t going to happen. I’m OK with this. Half the reason I made PraxisMapper and not just a locative game is that I hope someone else takes the tools I’ve made and makes a better game with them than I can.

Future Plans

I usually like to end with a rough take on what I want to accomplish in the next year on the project. The obvious plans are to work on the Godot side of things now. I may also look into improving my offline data workflow, to make processing the end files faster. Right now, MariaDB occasionally takes 90 seconds to run a query that should otherwise be nearly instant. I have an idea on how to get around that, but it’s basically going to be a separate workflow in the same app. And the results for that mean I might want to re-do the whole workflow because of the huge gain in productivity from it.

Looking at what tasks are the most important, filling in documentation and creating tutorials is probably top. It's a catch-22, because if no one uses PraxisMapper than documenting it is a waste of my time, but if I don’t document it no one is going to use it. I might start with a tutorial on setup and then go to full API documentation, to see if tutorials generate any of that interest I need to bother with the drier documentation. Second on improvements is to keep going with the Godot components and improve on those. Both making its current behavior better and more reusable, as well as adding in more common behaviors and components. At a stretch, I might poke at how to make an ad-hoc multiplayer component, so you can do something with other players within WiFi range. I already have everything needed for server-based calls, it’s the client side where direct communications are a place I have yet to explore.

I will be working on an area-control style game for the near future. It’s a pretty common concept and I think it could serve as a good example of what PraxisMapper games can do. The hard part will be getting into a non-violent theme, as a personal challenge. I’m working on that. Hopefully I can muster up a working game before autumn come and share it with everyone.

I still want to do a cold-reading game at some point. Some kind of haunted messenger app, possibly even a fully functional chat app for an existing service that occasionally pops up notifications from a ghost chatting with you. They’d send you to a nearby graveyard and ask questions while you look around until you wander into a grave that matches some criteria made up as you played. To help the ghost rest, you’d then go to a library, find a poetry book from [Some poet that was active and alive when the ghost died], then bring it back and read the poem aloud over the grave to ‘win’ the game. It’s the sort of setup that has potential to catch on among younger teens and gives them a story to share. Or would have, before every app pivoted to communicating via video or proprietary end-to-end encryption. (E2EE is good, but it also means you can’t choose your own app and that defeats the haunted-AIM-clone plan here).

I had plans to make a better version of Pokemon Go. A fan game with all of the actual Pokemon, using the actual battle system. Distributing Pokemon around the world so that you could actually find pokemon that aren’t on this week’s promotional event. Different types of places would attract Pokemon, making biomes an actual localized influence (Niantic finally sort-of did this recently). Having a gym in every city block, with a theme or limitation that required using more than your 6 strongest legendaries or type matchups. To further encourage exercising by granting coins from walking, and spending those to customize or improve your pokemon. A combination of PokeRogue’s release satiating my interest in a Pokemon game and Nintendo ramping up legal action against anyone and everyone have shelved this idea.

I want to make some kind of auto-battler where you get your units from places you visit and upgrade them by going to other places. This one isn’t high on my list, so that’s the extent of the details I’ve envisioned on it. Some kind of auto-battle setup, and some kind of locative element for acquiring resources. 

Historical Preservation and Research

On non-code development, I did run through and post a Mastodon thread that quickly summarized a large number of locative games, starting with the first and going on to the current year. I may do deeper dives on them, though it's going to be difficult. Preserving console games is a challenge. Preserving modern PC games, where everything requires a central server, needs a team of reverse engineers to keep them going. For mobile games from 20 years ago, on proprietary OSes, across the world, that had little to no actual marketing or discussion in gaming media? I’m going to be lucky to find 2 paragraphs and a screenshot in a magazine for a lot of them. I pondered keeping a lot of the APKs I could dig up and test, and decided against it. 

I don’t have much interest in sitting on a bunch of unplayable games, nor in reverse engineering any of the infrastructure layers needed to get them working. I’m more interested in the culture of people that play them, and that’s the thing I want to investigate. I want to see what made these ideas interesting and consider exploring them again. (Exceptions apply, of course. Ingress players are secretive and defensive to an extreme that makes the game inaccessible to new solo players, and I’d rather that sort of behavior stay out of my games.)

Some of these are dramatically easier to remake now. Botfighters’ core logic would be trivial to redo with modern data connections instead of SMS messages, and everything could be done on the phone instead of needing a PC to do most of the game setup in a web browser. Some of these are more difficult. Most mobile OSes have dramatically more control over apps and games behavior now than they used to, and one of the most restricted behaviors is “running in the background”. It is dramatically more difficult to get an Android game to quietly listen to GPS and poll a server for data than it used to be, because the OS generally blocks those off to very limited features and game engines don’t always expose the stuff necessary to use them. These were all reactions to games and apps using everything available to keep users opening them all day. Mobile games (specifically ones powered by ads that required constant attention and all of your data) ruined mobile gaming.

One game I dug up in my history was Tagging the City (2007) by the Ludic Society. I have no interest in preserving the actual activity itself, though I will note that it occurred. Why? Because it's an interesting footnote, but one of no cultural impact. One art school teacher drives around with a (probably single-digit) number of students and friends to commit petty RFID vandalism in the name of…. Some well-meaning and forward-looking principle? That might mean a lot to those students, but that's a personal experience and story to tell, not a cultural touchstone that the masses can point to and say “this is one of the things we all share”. I appreciate it as the first written case where someone connected real-world places and objects to in-game places and objects, but both implementation and execution are kinda boring. And that particular connection wasn’t used again. The idea was recreated organically elsewhere, better. 

Summary

Year 4 of PraxisMapper’s development hit a couple big milestones. Full global data has been processed, twice. I finally moved into Godot for client work, making the baseline stuff more functional and accessible to a bigger community. I’ve moved distribution for my Android projects to itch.io, and rejected the Google Play Store treadmill. Starting year 5 is the first time I don’t immediately know which big feature I want to implement next.