jumpy
jumpy copied to clipboard
fishfolk
WASM Support
Hello! I've worked with Macroquad before, and have really enjoyed it mainly for how easy it is to make cross platform games with it (and it's simplicity makes it really easy to integrate with existing Rust libraries). I actually used it before to make a proof of concept web game, and was wondering if the same could be done for FishFight.
Some immediate issues I can see (from just trying to compile to wasm32-unknown-unknown) is
- FishSticks and SDL2 don't want to work immediately out of the box, though from some limited DuckDuckGoing it maybe could?
- Networking with UDP immediately makes it a no-go, though maybe WASM could have it's own seperate networking arch?
I of course don't mean to intrude at all or come off as rude in the slightest, I just was curious about this. Would it be too difficult to implement? Do you all have any suggestions / more hiccups? I'd love to work on this as an open draft PR, but I'd want to understand the game and how it works better first.
Hey!
If those dependencies are the only problem, I think they can be excluded from the build with using feature flags in Cargo.toml. Although I'm not sure if it's easy to refactor the codebase for excluding them, I think it is possible this way.
However, I don't know if the project itself aims to support WASM so I cannot say anything further.
@orhun From what I can tell it's only gamepad support, though upon removing it from Cargo.toml just as a test, it is used in a loooot of the codebase.
I think it could be possible to replace the UDP stuff with WebSockets, I'm pretty sure there's a crate for that
@johanhelsing put together a promising proof-of-concept for what we’d need in browser-based multiplayer: https://johanhelsing.studio/posts/introducing-matchbox
I'd love to work on this as an open draft PR
Go ahead! 😊
@orhun From what I can tell it's only gamepad support, though upon removing it from Cargo.toml just as a test, it is used in a loooot of the codebase.
I think it could be possible to replace the UDP stuff with WebSockets, I'm pretty sure there's a crate for that
I don't think there should be any issues getting fishsticks working with WASM, though, as glirs uses the same backend and works fine. If there are any issues, me or @PotatoTech will look at them
@erlend-sh I've actually worked with the creator of matchbox q little before, since both me and him are working on using webrtc-rs to create a native version of the respective libraries. We're both having issues with it, however, and actually are having a speed bump in the exact same place.
@billyb2 See https://github.com/PotatoTech/fishsticks/issues/18 regarding SDL2.
The gilrs backend works without Emscripten, but we had issues with bizarre button mappings when using gilrs, which is why we chose not to use it here.
@billyb2 See PotatoTech/fishsticks#18 regarding SDL2.
The gilrs backend works without Emscripten, but we had issues with bizarre button mappings when using gilrs, which is why we chose not to use it here.
reading through that thread again, I noticed that you were using a USB SNES controller. I believe they are made by 8BITdo, just like my bluetooth xbox controller, so it might actually just be an issue with this certain manufacturer. Strange, still., as they are very common gamepads
My SNES controller is not from 8BitDo, so I do not think it is a manufacturer issue. Another possible cause is that the controller mappings used by gilrs happened to be wrong for our controllers. The controller ids used by SDL2 are not universally unique, so if someone adds a mapping for a controller that uses the same id as a preexisting mapping, they have to overwrite it.
After the Bevy rewrite this is almost essentially done. Because we are focusing on getting a release out before the end of the month, the web build has been temporarily disabled and doesn't compile, but it was previously working and should only need minor changes to get it back up and running.
