Multiplayer Support [AARD-2024, AARD-2021]

[azaleacolburn]

Task

AARD-2021 AARD-2022 AARD-2023 AARD-2061 AARD-2067

Symptom

We want to support multiplayer

Solution

There were three sprints done to determine which technology / architecture would be used for multiplayer: #1198, #1220, and #1240, The latter of which we ended up choosing, read that spike PR for details on the architecture.

This PR introduces a new MultiplayerSystem, which manages all the peer connections, handles all the sent and received messages, and keeps data about which objects are owned by which peers, including its own client. Every tick, PhysicsSystem.update sends either a collision or update message, as outlined in #1240.

To avoid having to send field assemblies over network every time one is spawned, at first, only the assembly name is sent over, the receiving client searches for the assembly in its cache. If it doesn't find the assembly, the receiving client sends an assembly request message back to the first client, which responds with the full assembly.

To avoid any central stateful server (which peerjs is designed to avoid), joining rooms is done by encoding several hashes in the user id. This allows clients joining a room to easily identify peers with the same room id, verify that they also know the room id, and avoid exposing the room id to anyone who doesn't know it (and prevent people from enumerating rooms).

Verification

0. cd <synthesis>/multiplayer
1. bun i && bun run start
2. Visit http://localhost:3000/fission?randomId=1 in two tabs. Click the multiplayer button in both. Press create game in one and copy the code, then paste it and click join game in the other
3. Try spawning a field (there may be a small delay here), then a robot, then driving around and picking game pieces up
4. Try spawning another robot controlled by the other client and collide them

---

Before merging, ensure the following criteria are met:

• All acceptance criteria outlined in the ticket are met.
• Necessary test cases have been added and updated.
• A feature toggle or safe disable path has been added (if applicable).
• User-facing polish:
  • Ask: "Is this ready-looking?"
• Cross-linking between Jira and GitHub:
  • PR links to the relevant Jira issue.
  • Jira ticket has a comment referencing this PR.

[AlexD717]

2. Drag mode on robots the other user spawned in doesn't work

This feature isn't exactly supported by the Hybrid architecture we're using. We could augment it by having each client keep a list of every body they touched, but that's not how we're handling it for now. I'm not sure if this is even a desired feature (what if they're trying to drive and you just pick them up, that leads to all sorts of issues. Another solution might be only sending over collision (or drag) messages while in drag mode. Attempting to drag another robot doesn't result in a bunch of errors or anything breaking (it just doesn't work), so it's not something I think we need to worry about for now.

I agree that this isn't something we should worry about, and isn't a needed feature.

3. Deleting robots you spawned in, sometimes doesn't work properly or leads to performance losses

I can't replicate this, could you provide more details about the conditions these performance issues occurred in (field, robot, etc)

I don't remember the exact setup I had, but if I encounter it again, I will make sure to record the conditions.

[PepperLola]

Looks pretty good overall. I don't think one user should be able to remove another user's robot though, which is currently possible through the context menu.

Also, unexpected behavior happens if you configure your robot after spawning it. For example, I had two clients running and spawned a dozer in each, both of which were missing an ejector configuration. If I added an ejector to one and picked up a gamepiece, the other client would be spammed with "you need to configure an ejector first" toasts. I was able to configure the ejector on that second client to point in a different direction and have a different velocity, and when I ejected the gamepiece they went in different directions at different velocities depending on the client. I was only able to get this to happen once, but at one point after configuring the ejector on the second client, the first client lost possession of the gamepiece but was still considered to be holding it, so the robot could move around without the gamepiece but ejecting it shot the gamepiece in the direction of the ejector from where it was on the ground (even though the robot was across the field). When the ejectors don't match, the robot will often (after one or two ejections) get stuck and not be able to intake anymore.