Geoguessr is a geography related browser game that really took off during the pandemic, when people were unable to do much travelling. Since then, it's evolved to a very competitive game, including its own officially sanctioned world cup (besides numerous community driven challenges and competitions).
As a result, even from the beginning, the community started creating mods thru either user scripts or outright external apps like ChatGuessr to increase the difficulty, involve more community members or just track their progress in some way.
This is a very brief history, that's omitting lots of drama, schisms, accusations of all sorts and lots of friendships built and destroyed.
Frankly, I had three reasons for starting up Extenssr:
This is technically a special purpose service worker. Its purpose is to:
The pop-up script (formerly grouped under the same category as right click context menu options?) is used to manage settings.
Content scripts are distinct from user scripts, in that they run in a separate JS context from that of the content loaded by the page, and have access to an extra set of APIs. For example, it can obtain URLs for extension specific assets.
The fact that they run in a distinct context is actually very important. It has the following advantages:
It also has the following major drawback: it cannot "hijack" any of the page's scripts. This means we cannot take control of the Google Maps and/or StreetViewPanorama APIs, to track the player's movements over time or prevent them from moving. Also, you can't hijack the creation of canvases and WebGL contexts, to inject postprocessing effects.
As explained above, the main purpose of these kinds of scripts is to 'hijack' the different APIs the website uses and inject our own (or replace it). This is IMO very naughty behaviour, and I love it. The tricky bit about page injected scripts is how to inject them and ensure they are fully loaded before any other scripts are. The current solution is good enough, due to the production version of the bundle being smøl enough, but there is a better solution in the works.
There's only one reason for this: running AI inference in a distinct thread from the page. Running this in the regular background script did not work for whatever reason.
Extenssr uses Typescript to make development easir, however all communication between these contexts lacks type safety. To make it easier, I've worked on at least a couple solutions, and ReAnna__ improved drastically the ergonomics, however the goal in the future is to create tRPC adapters, to ensure both compile-time type safety and runtime safety as well.
The initial design was more event-driven, as I thought having multiple tabs open and allowing state consistency among them was important. I'm now leaning more on allowing context-to-context communication, and don't care about intra-context communication.
browser.runtime.sendMessage. I've found that having a long-lived communication port is not ideal, as the background
script is supposed to be more event driven, and as such the port may be spuriously killed.window.postMessage
and listening for 'message' events on the window object.postMessage
method and by listening for the message event.The current work for implementing tRPC wrappers for all these endpoints is being done here. A similar project, chrome-trpc, does not handle all the above kinds of communication. To be fair, these are not typical use cases for browser extensions.
I'm a firm believer that state should be kept on the server. That said, in the context of a game mod, it makes sense that you would need to keep a client-side clone of the state. Extenssr uses two abstractions for this:
/battle-royale,
/duels, /game etc.This is imperfect and mostly impeded by hydration messing with any attempts to modify the UI. Currently, this is mostly overcome by adding delays where applicable. I think the longer term solution is to create a single overlay div that is a child of the body tag, such that it doesn't get affected by hidration. The current solution is good enough though.
Settings are kept consistent thru the web storage API, specifically with an async wrapper provided by the webext polyfill. Whenever a script changes a particular setting, all the other scripts receive a notification, to ensure consistency. This is done by sending a message to the background script, who in turn sends it back to all other tabs (except the one that originated the change).
Longer lived data - such as per-round and per-game movement, bespoke country streaks and other similar stuff is kept in IndexedDB. As previously mentioned, any requests to change IndexedDB insertions are funnelled through the background script.
The most interesting thing to me is how the community discovered how to hide the car and how ChatGuessr managed to hijack the Google API to add extra overlays on top of the map.
As a result, I don't claim to have invented this, and actually after doing some research, it's a quite common thing - see for example the WebGL profiling extension Spector.js.
The difference between the no car script and Extenssr's post processing is that Extenssr does two-pass rendering. A lot of work was needed to remove all the sources of flakiness.
In essence, the document.createElement method is hijacked, and if it creates a canvas,
and that canvas requires a WebGL context, and that WebGL context uses the Google StreetViewPanorama
shader, then all the drawing is done to an offscreen canvas, that then is used as an input texture
for the actual on-page canvas, with a cascade of optional effects.
Extenssr currently doesn't support true multi-pass, as it's a potential performance liability, plus that makes the order matter and therefore complicates the UI for choosing the effects. And that's way too much for a silly geography game.