Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Jun 03, 2018 · View creator page →

Creator of

Recent community posts

It now says: "This topic has been auto-archived and can no longer be posted in because there haven't been any posts in a while. If you have a something related to post consider creating a topic in Questions & Support."

I believe this is the same issue as:

As you can see we haven't been able to get any feedback from staff :/

Hmm, good thing I checked the page because I missed your post notification.

I never saw the push/pop notifications you mention.
I suspect there is some Python "print" calls somewhere in your game.
I'm considering blocking those, but they are usually debug left-over that are best removed, for performance reasons.

(if that's not it, send a screenshot and details about  your OS/browser brand&version)

(1 edit)


For, you don't add files to

You make a new .zip (e.g. that contains all the build directory files (e.g. all the files within myvisualnovel-1.0.0-dists/myvisualnovel-1.0.0-web/), including (in the end, there is a zip in a zip, e.g. in staff: note that this isn't specific to RenPyWeb, this applies to all HTML5 games and storage methods.

It is true to playing directly at the CDN bypasses all the fullscreen & orientation-locking wrapper.

Maybe this wrapper would need to be hosted at the CDN as well.

Or maybe the CDN could be exposed as a subdomain to solve the root issue.

A little test case: (iframe, error on save) (no iframe, no error on save)

Hi team,

I'm developing Ren'Py's official web port ( ).

With iOS working better with WebAssembly, I get bug reports about the way embeds web games, using a web host with a different domain.

This triggers IDBFS (storage) errors when writing savegames: called an invalid security context
because AFAICT the browser considers this is akin to storing a 3rd-party cookie ( -> * This was already the case with Debian's Chromium (see Emscripten thread), which blocks 3rd-party cookies (and cross-domain IDBFS) by default, but now this happens on a major mainstream browser/platform.

Playing the game directly at * solves the issue.

What do you think about opening web games directly at the CDN for mobile users?

I would suggest checking the F.A.Q. on size :)

I don't understand: when a privacy-enhanced user checks a game's page (e.g. because they found it via search), they just get the sitelock warning indefinitely and confusingly. Are you saying gamedevs need to ensure users play the game from outside via an embed?

Just let us decide whether to enable it.

How about letting devs decide whether they enable sitelock?

How about disabling sitelock when there's an empty referrer (means the player uses whatever privacy extension)?



As part of the RenPyWeb engine, I need to transmit a large-ish .wasm with browser-level gzip compression (75% gain).

Embedding a JS gzip decompressor is proving increasingly hard to maintain, is less efficient, and incompatible with .wasm streaming compilation.

I can't find documentation on how compression is meant to work at and my tests so far are not conclusive (I can't find a way to both get content-type=application/wasm and content-encoding=gzip).
What do you guys recommend?