native web game shell
for the cloud gobblers game we made at @emma I wrote a little shell in rust to be able to run it as a native application, basically something like electron but with 8k of overhead instead of 300mb...
it uses wry, the web view library written for tauri, which uses the system webview which is fine when all you need is webgl and a few other basic widely available js apis.
it has a few other bits of cleverness I was quite pleased with:
* compiles the built site into the binary for one file deployment
* all native functionality is done via a rest api to a fake domain that represents the shell. so you just use standard js apis like fetch, and outside of the shell those URLs just don't resolve
native web game shell
so unlike electron you don't have a full stack JavaScript experience for writing the native os and front end functionality -- but that's totally fine to wrap games that are static sites without any server component.
relying on standard JavaScript apis means you can take an unmodified web game and stick it in the shell. it's also trivial to check if the game is running in the shell or not by making a fetch request. no need for IPC mechanisms or other esoteric weirdness. you can just use whatever normal web development workflow you already use and it should just work in the shell, on cloud gobblers we used vite.
native web game shell
the one bit of native functionality cloud gobblers needed was the ability to click in the window near the start of the game. the JavaScript pointer lock API requires this. you would need to do something similar for eg web audio. in cloud gobblers it was kind of cludged in at the last minute on the rust side but the kind of API I would want to expose would look something like
await fetch("http://shell.tld/mouse/click", { method: "POST", body: { x:500, y:500 }})
other native functionality would be exposed similarly
native web game shell
something else i think we could do is have a configurable update URL that the shell checks at startup. if there is a new build at the url, it gets downloaded, timestamped, and replaces the current default build that launches with the application. the shell could present an egui internal interface to browse, select, rollback etc old builds making remote updates safe and undoable.
native web game shell
@nasser I did something similar with Cordova back in the day. Had automatic rollback and retries since we managed to softlock a few hundred kiosks before we added it :P
native web game shell
@mauve ☠️ ☠️ ☠️
i am VERY much thinking of kiosks and arcade machines and installations which is a big chunk of the work I do/EMMA does
