Create a web app version using love.js and GitHub Pages

[FormularSumo]

Repo and web-specific issues - https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web

Partially fixes #31, allowing the game to be run on iOS as a web app. Also adds support for macOS (which I don't currently build for) and any platforms not supported by Love2D, and is generally an easier way to play the game than downloading and installing it.

Using
https://github.com/Davidobot/love.js
https://pages.github.com/

[FormularSumo]

cd C:\Program Files\nodejs\node_modules\love.js
npx love.js.cmd -m 150000000 -t "Galaxy Collection" C:\Users\chewy\Documents\SWGC\love-android\app\src\main\assets\game.love "C:\Users\chewy\Documents\SWGC\Galaxy Collection website" -c

cd C:\Users\chewy\Documents\SWGC\Star-Wars-Galaxy-Collection-Web
python -m http.server 8000
localhost:8000
ctrl + c to stop
Running as a local server fixed the a/sync wasm issues, but now I get this issue

[FormularSumo]

I switched from using bitser to binser so that FFI is not needed, and also removed the FFI-dependent but unneeded on the web ANGLE code. The game runs well, with the major exception that it crashes when trying to load battles. Turning videos on also crashes.

For game loading crash:
Firefox console:

Chromium (Chrome/Edge) console:

[FormularSumo]

Davidobot/love.js#7 using love.audio.stop on only a single source resolves the issue

[FormularSumo]

Davidobot/love.js#69

[FormularSumo]

Website now hosted on https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web.
The only existing issue from the point of the source code (aside from things outside of my control such as videos not working) is character duplication in deck editor which doesn't happen in native app, and the escape key being binded to exit fullscreen as well as back.

[FormularSumo]

Character duplication occurs whenever sortdeck() is called I believe

[FormularSumo]

Character duplication fixed

[FormularSumo]

It might now be possible to get video working using a workaround discussed here #72 (comment)

[FormularSumo]

Another important thing is to get it working as a PWA. This is currently working fine on Firefox. It doesn't work on Chromium or Safari/iOS. Install prompts would be good. Screenshots too.

[FormularSumo]

PWA is now working on (iOS) Safari and partially working on Chromium. On Chromium it's still just saying add to home screen not install, I think adding a screenshot might fix this? Additionally on Chromium and Firefox on Android the logo has an extra white box around it which is not supposed to be the case.

[FormularSumo]

Install still not working on Chromium, maybe service workers are still needed?

[FormularSumo]

Turns out it just wasn't finding the files. Installs is now working in Chromium, with screenshots and browser prompts. The logo is now correct on Chromium and Firefox too

[FormularSumo]

It would be good to get the app working offline using a service worker. The app resolution and screen filling also still need fixing on mobile... Also the fullscreen button is not needed on Android when installed as a PWA on Chromium (is on Firefox), and doesn't do anything on iOS

[FormularSumo]

Changing the scope now enables it to work offline, the service workers correctly update. I'm not sure what happens if there is an update to what's hosted on the server now

[FormularSumo]

I attempted to fix resizing using https://github.com/MrcSnm/Love.js-Api-Player) but turns out console wrapping is disabled by github pages so that doesn't work.

[FormularSumo]

Testing results

• In order to change the actual canvas size, rather than the css size (which just stretches it), you need to use the canvas height and width property, which is not in style but a separate tag.
• screen.orientation.addEventListener("changed") is called just before a screen has rotated not afterwards, so accessing window.innerWidth for example gets the wrong value
• Changing the canvas size using window.addEventListener("resize") works, but changing the canvas does not always cause love2d to correctly resize.
• When I print the size in love2d, it does not change resolution on desktop until the program has entered and left fullscreen, then resizing does change the resolution. Chrome and Firefox have slightly different behaviour around entering and exiting fullscreen but it's a minor difference.
• Meanwhile on mobile Chrome and Firefox are the same, both also only resize after fullscreen has been toggled, with identical behaviour. However when they are fullscreen, rotating does not cause them to resize properly. On Safari mobile though resizing and reorientating actually works fine always (there's no fullscreen toggle as this isn't supported on Safari). This was all tested both in browser and in web apps

[FormularSumo]

I've been trying to get threads working on the web version since #81, however I've been unable to make it work so far.

I've switched to compiling in non-compatibility mode and included love.worker.js. I've yet to get the "Uncaught ReferenceError: SharedArrayBuffer is not defined" error, but to be thorough I also tried using a script (from this issue) to add the correct cross-origin headers, as Github pages doesn't support this, but without any effect. I've also done all my testing with the game and the Love wiki thread example. My testing has been in localhost anyway, which I think should support the headers, at least with the extension I've temporarily installed to always enable.

Also strange is the Love.js compatibility example does not work with threads despite saying it should, and the non-compatibility one won't run whatever I do (extension, firefox/chrome, whatever). So I think I'm going to have to conclude that threads are currently broken in Love.js and easiest thing is if I just rewrite it to be like it was previously, doing image decoding on the main thread :/

I should test on Github pages as well just to double check, and also check if non-compatibility mode works there on all browsers - if so would presumably be better than compatibility mode ("dodgy audio")

[FormularSumo]

Initial test of non-compatibility mode: works fine in Firefox and Chrome, not Safari (who would have guessed). Testing now with cross-origin script

[FormularSumo]

This is now fixed by the above commit

[FormularSumo]

#115

[FormularSumo]

For some reason desktop Chromium browsers are using the monochrome logo for PWA installation, on Windows and Linux. Meanwhile Chromium on Android is using the non-monochrome one even with "themed icons" on. Idk who thought that was a good idea. For the meantime, might be best to just remove the monochrome icons until they're working, maybe follow/open relevant Chromium bug tracker issue.

(Left: Chrome, Right: Gnome Web)

[FormularSumo]

Chrome: "Fast 4g" throttling downloading game from scratch.

Unfortunately most of the game is kept in the game.data file, which will need redownloading entirely I believe whenever there is an update to it. I could however keep the rest of the files (especially love.wasm and love.js) in a separate cache which is updated less frequently, at least. Maybe change game to say "downloading update" rather than "downloading data" where applicable.

It would be especially helpful to avoid redownloading the love files when unchanged because they prevent the game data actually being downloaded until after it's finished.

[FormularSumo]

Using return this.skipWaiting(); in install event in the service worker means that the service worker will be updated on next page reload, rather than full page close + open.

Disabling the fullscreen footer in index.html then updating the SW version causes only this amount of new resources to be fetched according to Chrome's Network profile:

Which if true, means that only the files/data that are changed get reloading. Hopefully including game.js and therefore game.data. For some reason game.data isn't included in caching everything, which is good because its cache is managed by game.js separately anyway.

And when updating the game files, SW version and nothing else, causes game.js+game.data reload

[FormularSumo]

Full transfer data according to Firefox, from Github pages rather than localhost (so text compression should be on). Everything other than game data is compressed quite a lot here.

[FormularSumo]

Data transferred disabling fullscreen button and updating cache name in Chrome. Firefox says nothing is transferred. Both Chrome and Firefox do update the index.html it seems unless I clear all data, which is different to what they did running locally.

[FormularSumo]

Updating game data + service worker appears to download from Firefox, whereas on Chrome throws this error

Both don't actually update the game (edit: might have uploaded wrong version, not sure)

[FormularSumo]

File structure on github.io according to Chrome and Firefox

[FormularSumo]

All that Chrome downloads when updating game

[FormularSumo]

Under some cirucmstances, game.data is getting incorrectly saved to cache as well as indexedDB

This seems to happen after the game is redownloaded due to the game data changing.

[FormularSumo]

Changing to
Doing
cache.addAll([
'/'
]);
Does seem to have caused the game to be updated (unless this was happening otherwise, it's really hard to tell). It requires 2 reloads to do so (first to download the service worker and install it, 2nd to then run the new code). It would be good to either have a pop-up for reloading again to update, or force the client to do it.

[FormularSumo]

Non game code (fullscreen button) is also updating now, on Chrome desktop and Firefox mobile at least. Firefox desktop is is refusing to for some reason.

[FormularSumo]

I've now tried only caching the files which should be needed to run the game - index.html/love.js/love.wasm/game.js. However, now the game isn't updating at all. I assume that somehow game.data not being cached is causing it not to update, which shouldn't happen but is. I'm thinking that potentially I could disable caching in game.js and then enable it here instead.

[FormularSumo]

Looking at both Chrome and Firefox's source thing: even though they're using the most recent service workers, they're both using an old version of game.js

Manually deleting game.js does cause it to redownload correctly and update

[FormularSumo]

So my current thoughts are that what I'm doing should be working, but isn't (nobody's said that before), and I have 3 options.

• Ignore that the save data is being duplicated (for now) and move on to trying to force reload
• Move to an online-first caching approach instead of offline; if online, download data, and cache it. If offline, use cache. This has the advantage that anyone using the website online will always be using the most up-to-date version after just one reload. It has the disadvantage that they still need to download a bit of data (~5MB) each time they load it, and if the cache isn't updating properly that could cause an issue when they do then play it offline (would they then get a previous version of the game? It is completely broken or would it update after longer enough (eg a day)?)
• Further test saving game.data in cache and not in indexedDB (I couldn't get this working in my brief testing, and also not ideal because it means you always get a (very very brief) loading screen, and game.js would need changing every time I build for web)
• Try more things to try and fix it not working?? (Maybe delete game.data from cache after it's been created?)

For now, 1 seems like the best approach. It's not great to duplicate ~70MB on the user's device for no good reason, but is seems to be the only approach that'll avoid all the other pitfalls. And if I do get it working without lots of reloads then I can revisit trying to get it working again after.

[FormularSumo]

Resources I've been following:
https://developer.mozilla.org/en-US/docs/Web/API/Cache/addAll
https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Offline_Service_workers
https://developer.mozilla.org/en-US/docs/Web/API/Cache/addAll
https://stackoverflow.com/questions/42891815/service-worker-with-multiple-caches (didn't work so well so haven't been using so far)
https://www.thecodeship.com/web-development/guide-service-worker-pitfalls-best-practices/
https://web.dev/articles/service-worker-lifecycle#activate
https://codyanhorn.tech/blog/pwa-reload-page-on-application-update
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/controllerchange_event

[FormularSumo]

Update: For some reasons it's now liking reloading. However, even though I've specifically told it to delete game.data here it's still ending up in the cache, alongside a lot of other things which I'm not putting there (on Chrome)



It only gets added after being downloaded though, much later than the service worker installing, so something else is putting it there.

[FormularSumo]

If I then reload the service worker, it does get deleted while still using the latest version

[FormularSumo]

I've now set the page to reload after a new service worker is activated, with the aim of then causing new game data to download (if applicable). Unfortunately whether the new service workers decides to find the new game.js file seems to be incredibly temperamental. Sometimes it does, straight away, other times it only does if it's been awhile (only if not already reloaded?) (maybe 10 minutes?) and other times it requires a new service worker or game.js to be deleted.

[FormularSumo]

Also, Firefox seems reliably slightly slow at updating service workers, anywhere from 10-40(?) minutes, whereas Chrome does it instantly.

[FormularSumo]

It currently seems to be working reasonably reliably. Still not working straight away, and sometimes more reloads needed, but more often than not it seems to be working as intended (across Linux/Android/iOS) which is good...

Deleting the game.data cache is only working when you reload the page, which is better than only when there's a new service worker, but still not ideal.

[FormularSumo]

Monochrome icon on desktop mostly fixed I think FormularSumo/Galaxy-Collection-Web@5832f9e (Windows needs testing still).

Still no monochrome icon on Android, but I don't think Google/Chrome have got around to implementing that yet. Hopefully when they do it'll just work.

[FormularSumo]

FormularSumo/Galaxy-Collection-Web@e02f166 Added some in-game screenshots to web install (not allowed on Play Store build)

[FormularSumo]

Returning to resizing shenanigans

Using mostly default Love.js (pre FormularSumo/Galaxy-Collection-Web@c9fcd71) game doesn't really resize on mobile except sometimes when you enter/exit fullscreen. On the plus side it's never rendered off-screen or stretched. (Check this)

Using this solution: Davidobot/love.js#16 in the Chrome mobile device emulator, until I click on it, the game is always filling the screen, but (CSS) stretching instead of resizing correctly. After I click it doesn't resize at all. And after entering or fullscreen, it works perfectly...
On Chrome and Firefox Android it's the same, except you need to exit (as opposed to just enter) fullscreen for to work perfectly.
On Safari iOS it works pretty much perfectly
On Firefox desktop/emulator it's same as Chrome except no resizing at all instead of stretching before clicking on the game

If I then add the resizeCanvas function/listener, it causes the game to seemingly never resize (Chrome emulator)... although according to my above comment this is Love2d not resizing rather than the canvas

Using Davidobot/love.js#50 (comment) doesn't change behaviour except for when in fullscreen, then it stretches instead of resizing on Chrome emulator. Might retest later if I can fix initial resizing not working.

[FormularSumo]

Now that 0.12 has been officially released and the web build is largely functional/stable, I'm going to close this issue and migrate the remaining issues into https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web/issues