Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console Web Support #91

Open
RobDavenport opened this issue Sep 25, 2022 · 2 comments
Open

Console Web Support #91

RobDavenport opened this issue Sep 25, 2022 · 2 comments
Labels
Console Related to the Console crate Discussion Discussions and non-concrete issues. help wanted Extra attention is needed

Comments

@RobDavenport
Copy link
Member

RobDavenport commented Sep 25, 2022

A common question about Gamercade has been "does it support web target?" or "are there web examples?" which has lead to some confusion. WASM is currently synonymous with browsers, so it's easy to understand why. In the case of Gamercade, WASM was selected due to its flexibility as a compilation target from multiple languages.

Currently, the priority and focus areas of Gamercade has always been on delivering a consistent multiplayer experience. This is much easier to do with desktop apps, since we only need to reason about a single WASM runtime.

The difficulty with browsers is due to the sheer number of them and each with potentially unique implementations, especially with regards to desktop browsers, tablets, and mobile. It's important that Gamercade provides a simple development experience regardless of platform, and that games are completely deterministic regardless of platform. I don't want the games to need to worry about which platforms theyre on, it needs to just work regardless of platform.

It's not impossible, of course, but here are some key areas that need to be addressed.

  • Console needs to support crossplay, allowing web and desktop users to connect seamlessly (webRTC has workarounds).
  • 1:1 Fully deterministic execution of game logic to prevent discrepancies between different browsers and platforms.
  • Full Gamepad functionality including analog sticks and triggers.
  • Good enough performance for the lower tier devices, especially on the rollback and audio parts.
  • It doesn't hinder the development of native in a negative way.

If this isn't feasable, it may be worth exploring something like a stripped down version which doesn't support multiplayer or some other features, but I'm also hesitant to go this route since it may convey and incomplete image of the Console. This is also important when thinking about mobile browsers.

On a more opinionated note, I think web games are awesome. But arguably one of their best selling points, the ease and speed of getting users into games, also comes with a drawback: it's very non committal and super fast to close out of the browser or game. Additionally, I think Gamercade is positioned as a great middle ground in terms of game content/complexity/depth. It has just enough tools to create a flexible development environment for deep and interesting games, but also imposes enough constraints to keep projects focused on delivering solid core set of features. I worry that web support might push developers towards developing more instant-play, simple, or casual games, for which there are already great alternatives for: pixi, phaser, playcanvas, rust-to-wasm crates like macroquad and bevy, and of course other fantasy consoles like wasm4, pico8, and tic80.

If someone wants to tackle this problem, the first few steps would probably be:

  • Find which crates can compile to web, or find alternatives for the ones which dont. For ones that dont, we may need to write our own replacements.
  • Build an abstraction layer inside of the console which lets us use either wasmtime or browser runtimes.
  • Add docs on how to build and test web versions.
  • If necessary a list of incompatible (or removed) features across browsers or devices.

I have stated in some other places that due to these reasons I am not intending to add browser support as a core feature in the near or far future. But if the general use case for Gamercade changes I am open to reconsidering. Of course, of anyone wants to take on this large challenge, I'm here to help!

@RobDavenport RobDavenport added help wanted Extra attention is needed Console Related to the Console crate Discussion Discussions and non-concrete issues. labels Sep 25, 2022
@VegaDeftwing
Copy link

Good enough performance for the lower tier devices, especially on the rollback and audio parts.

May conflict with

Audio Effects - Slides, reverb, chords, anything to make our sound engine even better.

Some audio effects are simply to heavy to do reasonably, real time, if targeting any platform and not limiting the audio engine. Reverb especially stands out as a problem, as constitutional reverb is crazy expensive and algorithmic, if cheap, tends to sound awful. This may be remedied by imposing more limitations on the sound engine, such as only doing 12-bit, 44.1kHz audio, which, imho, is already overkill for a fantasy console.

@NHodgesVFX
Copy link

For multiplayer matchbox supports native and web over webrtc with a socket that's compatible with ggrs. It also includes a prebuilt signalling server and if you want their is also a library for building signalling servers as well. The prebuilt server also supports basic matchmaking.

https://github.com/johanhelsing/matchbox

It would be cool to have a hosted signalling server that way in most cases you don't need to port forward.

@RobDavenport RobDavenport pinned this issue Apr 10, 2024
@RobDavenport RobDavenport unpinned this issue Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Console Related to the Console crate Discussion Discussions and non-concrete issues. help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants