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]

https://github.com/Davidobot/love.js/issues/7 using love.audio.stop on only a single source resolves the issue

[FormularSumo]

https://github.com/Davidobot/love.js/issues/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 https://github.com/FormularSumo/Star-Wars-Galaxy-Collection/issues/72#issuecomment-1266138951

[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]

With cross-origin headers in theory set and worker.js it now runs on Safari, but audio is completely broken

[FormularSumo]

Testing multi-threading version on Github pages, threads still don't do anything like in localhost on any browser. And audio is still broken on iOS. So unfortunately will have to go back to non-compatibility I think, and remove multithreading from web version.

[FormularSumo]

For good measure have tried threads on non-compatibilty mode github pages, with love.worker installed, but still doesn't work.

[FormularSumo]

https://github.com/FormularSumo/Star-Wars-Galaxy-Collection/commit/70680dbeccdd5cea24ca0378696e92076099c135 and https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web/commit/359f44cd106c73ddcbc9a57e6fe603b502073579 mean that data is now saved permanently on the user's browser, for whenever they next load the website/web app. If the device is running very low on storage, or if Safari feels like it, data could be cleared if it's among the least recently used websites. This only happens if Chromium-based browses/Safari choose not to grant persistent storage, or a user denies the permission prompt in Firefox.

[FormularSumo]

Testing out indexedDB data storage - persistent storage permission requested or not

Desktop (Linux/Windows)

Chrome/Firefox

Data saves perfectly, whether reloading the page, browser, or web app

Gnome Web

Data persists when reloading the page. But when restarting the browser or installed web app, only uses data from last time you reloaded. Which can mean old data is used or no data, it's bizarre. Tested with tracking protection on and off.

Android

Chrome/Firefox

Same as Gnome Web desktop, including web apps (regardless of whether browser/tab is open)

ChromeOS

Same as above. Note: seems like only Chrome can install web apps, so unsure about them in other browsers

iOS

Data does not persist ever, regardless of browser, tracking protection, in-browser vs web app, reloading.......

[FormularSumo]

For some reason in this arrangement, the top card (Chewbacca in this screenshot) is getting stuck on final movement forward for at turn. Not reproducible on native, only love.js. Happens to the same card number if I swap the cards around, as long as there is a card opposite in the enemy deck. If I move that card up and then it merges down, does not happen.

[FormularSumo]

On web, vs natively I get as expected, each correct number twice in a row. The fact that 4 and 2 are being run seems to imply that there's some kind of almost race condition, as I'm updating the table the iteration in gamestate is also being updated. Disabling the the P1deck updating code causes the numbers to be correct, which seems to confirm this theory.

[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 https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web/commit/5832f9e69c200836330175bc38d661457a7e0197 (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]

https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web/commit/e02f166d1942518fe519aa25a7d99331ac99e19a 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 https://github.com/FormularSumo/Star-Wars-Galaxy-Collection-Web/commit/c9fcd71bc32658ec2589fc61ac2466c6a558d1d8) 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: https://github.com/Davidobot/love.js/issues/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 https://github.com/Davidobot/love.js/issues/50#issuecomment-2338513304 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.