Running in Browser

[lumi-a]

There are ways (e.g. this, though I spent no time searching for better ways) to run the game in-browser. Hosting could simply be done via github-pages, same way I host my sliding-blocks-game.

• 👍 Significantly more accessible, people need not clone the repo or even download python
• 👎 Might impose restrictions, the above link says "You will probably have to change some of your code.", though it doesn't seem to be much work (again, didn't spend much time looking into that yet)
• 👎 Performance on web is worse, but perhaps not worse enough (in a rust-wasm project of mine, the web-version ran at about half the speed of the local version). Even after implementing web-support, we can always also run it locally for "maximum performance" (whatever that means for Python)
• Running on web also makes online-multiplayer (peer-to-peer, not server-based) more attractive.

[Tim2othy]

Sehr cool.

[lumi-a]

Great work. Still todo:

• Better error-handling
  • The current red on-screen-error-message is hardly helpful for debugging, could we maybe display a traceback?
  • Maybe we shouldn't try catching the errors, and they'd just get logged to the web-console?
• Instead of awkwardly redirecting tim2othy.github.io/spacegame to spacegame/build/web, we should do a branch on which we publish web-builds, and deploy github-pages from that branch
• Web-performance is significantly worse, we should diagnose that. Do web-builds simply have less "effective compute", meaning to increase web-performance we could just increase local-performance, or do web-builds maybe introduce some significant (avoidable?) overhead that would be present even if the game-loop were as simple as "draw one rectangle on screen every frame"?
• The github-actions-workflow immediately publishes to web on push to main, which means the app breaks for everyone if we accidentally push a faulty commit. We could instead run the action on demand, whenever we feel like publishing a new version. Alternatively, we could write really good tests (Tests #50) and use git pre-push-hooks demanding the tests to pass before pushing to main.

Regarding peer-to-peer Multiplayer, there's #51.

[Tim2othy]

Added a branch for hosting the website gh-pages. Should we still change the github-actions-workflow? I think now we can make changes to the main branch and once we've tested everything etc. we sync the gh-pages branch and in doing so deploy the changes, this seems like a good workflow but maybe I'm getting something wrong.

[lumi-a]

I think you still need to change the repo-settings so that the gh-pages-branch is deployed to tim2othy.github.io/spacegame (I can't seem to access these settings, which is fine). The pygbag-docs also talk about deploying to github-pages that way.

[lumi-a]

After changing deployment to that branch, we should really add the build/ directory back to .gitignore Done in 9b33d29

[lumi-a]

To test the performance, I locally replaced main.py with:

import pygame
import asyncio


async def main():
    t = 0.0
    clock = pygame.time.Clock()
    surface = pygame.display.set_mode((1000, 1000))
    running = True
    while running:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                running = False

        t += clock.tick(60) / 2
        surface.fill(pygame.Color("black"))
        pygame.draw.line(surface, pygame.Color("red"), (t % 1000, 0), (t % 1000, 1000))
        pygame.display.flip()

        await asyncio.sleep(0)


asyncio.run(main())

which just draws one single line per frame. This runs smoothly both with py main.py and pygbag ., so indeed our game just has bad performance, rather than pygbag introducing some avoidable overhead. The sharp decline in performance when comparing py main.py to pygbag . seems to be because pygbag does not compile the Python code to WASM, but ships a python-runtime (that runtime is compiled to WASM) together with all of our code, and then runs our code in said python runtime, as per this stackoverflow answer. It also says:

Python code is actually interpreted and type-annotated code could be compiled direcly to Wasm but that fonctionnality is not (yet) available for public use.

I guess I'll get around to primitively profiling our code and then trying to improve performance.