Network Multiplayer Support

[jm2]

Thanks again for getting Cro-Mag Rally released; it's an excellent port :D

I know you mentioned network multiplayer support may come back in a future release. In the event someone was interested in trying to help make this a reality, what areas would require work to fully enable support? It looks like the networking source code may still be in place, although I'm not sure if it's complete and what was done to disable/exclude it in the 3.0.0 release.

Since this was originally a NetSprockets title, would https://github.com/mistysoftware/openplay be of use for re-implementation here, or is it in a state where just starting over on the network stack entirely would be more practical?

Thanks,
JM

[jorio]

I personally wouldn't bother with a true NetSprockets implementation. There's very little that really depends on NetSprockets features, so I'd just port those parts to the networking API of our choosing.

The net code from the core game looks simple enough. It's a client/server model. On every frame, the clients send their inputs to the host, which rebroadcasts them to all clients. The clients then replay the other players' inputs locally. There's obviously more setup work before the game starts, but as far as the core game loop is concerned, that's really it.

I haven't culled any of the net code, it was just #if 0'd away so the game compiles without it.

I think the bulk of the work will be designing new screens for matchmaking. As with other features that depended on Mac OS dialogs (settings, physics editor), we're going to need to create our own UI.

[EliasHeydrich]

Really, the clients send their input? That sounds to me like a dsync waiting to happen... So, everybody except the Host has a terrible input delay?

[jm2]

That may explain why the original OS 9 network play was so unstable :P I have distant memories of this only working properly with identical G3 iMacs in an Apple Store, and other setups frequently failing to sync at or shortly after race start.

[jorio]

I have pushed a work-in-progress branch called "net" if you're interested. It works, but only on a LAN.

Just sending inputs and having each peer simulate the world in parallel isn't unheard of in multiplayer games. Unfortunately, there's no prediction/rollback mechanism in CMR. The game stalls until it's received inputs from all players on every frame. So, there better not be too much latency on the network. Right now, you'll need to be on the same LAN for the game to be playable at all. On a stable LAN, though, it does work fairly well.

[jm2]

I have pushed a work-in-progress branch called "net" if you're interested. It works, but only on a LAN.

Again incredible work 😁 I just compiled the branch and gave it a quick test on my gigabit wired network between two machines (both Arch Linux.) It worked for about 10-15 seconds or so, then the client reported 'seed desync' and the host reported that all players had left 😅 I'm happy to do any sort of logging or tcpdump if that'd help.

[jm2]

Ok so I did a bit more testing, and it's possible my network topology might be causing the instability. If the machine connected to 1GbE hosts it appears to work okay, however if the machine connected to 10GbE hosts it desyncs pretty quickly.

[fordcars]

Thanks for the updated @jorio! I guess hanging the game until all inputs are received was a technique to avoid desync, but I'm sure that would cause issues over WAN.

[jm2]

I finally had the chance to test this at a real LAN party with a cross-platform build that merges the network branch with the latest main branch changes. Here is what I found:

1. As long as the network is wired and homogeneous (e.g. all system wired at 1GbE) the game appears to be relatively stable in the sense that it doesn't de-sync after ~5 seconds (which happens on WiFi and mixed-mode wired networks.)
2. As long as 1. is met, cross-platform seems to work well, at least between Windows and Linux; I haven't had a chance to test the Mac build in a stable environment yet.
3. The game seems to start creeping above 100% game speed in network mode. Not by a ton, but it's somewhat noticeable with how fast and twitchy the cars get.
4. If a player intentionally quits the match at race start, things get weird and all remaining network clients end up in split-screen mode.
5. While all input methods work for the game host, it appears game clients lose controller support with network mode and must resort to keyboard input only. I'm not sure if this is a host/client issue or if this is just something weird happening with the Windows build. What is clear is the Windows client had controller support in-game until he connected to a network match.
6. There was one case where one of the clients network paused the game (and possibly disconnected) and no one else including the host was able to resume the match. Network pause/resume did work successfully on an earlier attempt. If only the client that pauses the game can resume as intended behavior, it might be worth changing that so any client, or at least the host, can resume the match.

Overall though despite the rough edges it was really fun testing the network support out. Hopefully it can be fixed up and promoted to the main branch eventually :)