Ultimate Integration

[erlend-sh]

Description

Fish Fight org has a platform partnership with https://ultimate.games/

We are working on integrating the web-version of Punchy with their browser-based platform.

This integration will touch various parts of our architecture, such as the wasm build and multiplayer netcode.

Current goals:

• Setup working server connection to ultimate (only tcp working so far)
• Setup working wasm build on ultimate
• Split server and client into multiple binary targets? Or decide on a different strategy like using features to organize client and server code.

[odecay]

A question came up from the last discussion with ultimate folks. How do we want to split out/organize our client and server? Their servers will host a native binary, and client will be a wasm build.

On the ultimate side it seems like they have some build scripts they expect us to use right now.
The server side thus far seems to require Tokio which doesn't compile to wasm AFAIK, although there may be a possibility of dropping that dependency in the future.

Another thing to think about is modularity of the networking/ultimate integration code in general. For now I think it should live in its own branch and not be part of master, since we will be continuing to build and publish our own web build that wont interface with their platform at all. Eventually I think we will want to find a way to make it possible to build with ultimate integration features and with some other multiplayer service/hosting strategy.

[odecay]

Some more things came up in discussion but we haven't gotten anywhere near implementation of are the general services they provide. Two that stood out off the top of my head were a storage API for saving arbitrary data, (save files, settings, player progression) and some form of matchmaking/lobby system with ready up features.

I imagine when we get to it how we deal with their save data API will some overlap with what @zicklag has done in #79.

[zicklag]

Here are my not-very-sorted thoughts, which are rather uninformed because I know nothing about Ultimate. Still there might be something useful to you guys in here. :)

---

We definitely can't put Tokio in WASM, but I don't think we need to put Tokio in WASM anyway. We should be able to implement our server component core logic agnostic of the IO and async executor.

WASM can't host network multiplayer games by itself period. It needs some server component, even if that server component is simply a WebRTC relay server or something similar.

If we wanted to allow multiplayer in WASM for our own non-Ultimate builds, we could setup a system where peers discover each-other through a relay server, and one of the peers gets elected as the "server" and serves the game to the other connected peers. We could run a relay server on your own server infrastructure and I think we could handle almost unlimited players with almost no server load, because relay servers just relay traffic without thinking about it.

As far as Ultimate goes, they apparently have standards on lobby's and matchmaking, which will probably require running a smarter server component than a simple relay, and it looks like, from this repo that you need a Docker container ( that's easy ), and also some crates that aren't public ( ? ) to integrate with their service.

I'm wondering if we can implement a sort of backend abstraction that would allow us to cleanly plug into Ultimate through that abstraction, but also implement our own backend that is free of Ultimate for our own builds.

I'm not sure, it really depends on what the Ultimate API looks like, but it seems like we'd want to essentially wrap anything that interacts with Ultimate in some sort of a IntegrationBackend trait that would have one implementation for Ultimate, and one implementation of our own that doesn't need the Ultimate API to function.

I tend to lean away from keeping different versions of the code in long-term branches. It can be a hassle whenever you do an update in one branch that needs to land in both branches. I wonder if we could just use a cargo feature to conditionally build the ultimate stuff so that they can all land in the same branch?

[odecay]

I'm wondering if we can implement a sort of backend abstraction that would allow us to cleanly plug into Ultimate through that abstraction, but also implement our own backend that is free of Ultimate for our own builds.

This is exactly what I'm hoping for eventually, but I'm nowhere near being able to say how yet.

As far as Ultimate goes, they apparently have standards on lobby's and matchmaking, which will probably require running a smarter server component than a simple relay, and it looks like, from this repo that you need a Docker container ( that's easy ), and also some crates that aren't public ( ? ) to integrate with their service.

This is accurate to what I've gathered/been told thus far. 👍

I'm not sure, it really depends on what the Ultimate API looks like

As far as I can tell their rust crates are private (stored in an access controlled private registry) and as of yet undocumented but there is some API doc here which I have not yet got far into. https://docs.ultimate.games/reference/sidecar.proto

[erlend-sh]

The most promising multiplayer netcode library in Bevy land these days is https://github.com/lucaspoffo/renet

Web-support is on its tentative roadmap, and a first step towards that is in a draft PR:

• Any intention of WebRTC Support? lucaspoffo/renet#10
• Use channels as a transport abstraction. lucaspoffo/renet#14

[zicklag]

Created #217 to discuss networking technology.

[odecay]

I think this should be closed for now with the alternative of rollback netcode and some combination of steamworks and/or the custom server used to forward p2p connections which @zicklag has been working on for jumpy.