Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unlikely story of Teardown Multiplayer

blog.voxagon.se

Post reply on HN
Print view View original

51–60 of 69 posts

Re: The unlikely story of Teardown Multiplayer

#51

Post by ChadNauseam »

jmgao wrote: post #14

> For the longest time (and for good reasons), floating point operations were considered unsafe for deterministic purposes. That is still true to some extent, but the picture is more nuanced than that. I have since learned a lot about floating point determinism, and these days I know it is mostly safe if you know how to navigate around the pitfalls. If you're only concerned about identical binaries on x86, it's not t…

> If you want this to work across ARM and x86 (or even multiple ARM vendors), you are screwed, and need to restrict yourself to using only the basic arithmetic operations and reimplement everything else yourself.

Is this problematic for WASM implementations? The WASM spec requires IEEE 754-2019 compliance with the exception of NaN bits. I guess that could be problematic if you're branching on NaN bits, or serializing, but ideally your code is mostly correct and you don't end up serializing NaN anyway.

Re: The unlikely story of Teardown Multiplayer

#52

Post by Negitivefrags »

jmgao wrote: post #14

> For the longest time (and for good reasons), floating point operations were considered unsafe for deterministic purposes. That is still true to some extent, but the picture is more nuanced than that. I have since learned a lot about floating point determinism, and these days I know it is mostly safe if you know how to navigate around the pitfalls. If you're only concerned about identical binaries on x86, it's not t…

We use floating point operations with deterministic lockstep with a server compiled on GCC in Linux a windows client compiled with MSVC in windows, and an iOS client running on ARM which I believe is compiled with clang.

Works fine.

This is a not a small code base, and no particular care has been taken with the floating point operations used.

Re: The unlikely story of Teardown Multiplayer

#54

Post by amlib »

jerf wrote: post #34
Sweepi wrote: post #4

"1.Serialize the entire scene, compress the data, and pass it to the joining client. We already do full scene serialization for quicksave and quickload, so this is possible, but the files are large: 30-50 MB is common, often more, so transfer would take a while. [...] 3. Record the deterministic command stream, pass it to the joining client, and have that client apply all changes to the loaded scene before joining th…

Part of the problem with [1] is that you still end up needing [3] anyhow, because even if you've got a fiber-to-fiber connection, while the transfer was occurring the game world has moved on and you'll need to replay that anyhow. But if you've got a solution for [3] that works completely correctly anyhow, then writing lots of code for [1] becomes redundant to that anyhow, even with save/load code sitting right there.…

There is always the option of force pausing the game to all clients until the joining client is fully in sync. Age of Empires 2 does something like this when a player that was dropped later rejoins the game. You can even have a screen showing how synced each player is and an ETA based on their download speed, with the ability to chat and even kick a player...

Obviously that won't scale if you intend to have dozens of players constantly joining a server rather than a "friends only" (or whatever more constrained scenario) where players only occasionally join mid game.

Re: The unlikely story of Teardown Multiplayer

#55

Post by sand500 »

DimitriBouriez wrote: post #9

Wouldn't it have been simpler (even if technically heavy) to host the game on a single machine and just stream each player's camera? That way all the physics would be computed in real time on one computer, and each player would just receive a different video stream.

Might have been a key differentiator for Stadia.

Other comments are worrying about the streaming and latency but local split screen could also be another use case here.

Re: The unlikely story of Teardown Multiplayer

#56

Post by dwroberts »

yakcyll wrote: post #47
dwroberts wrote: post #35

Earlier quoted context omitted.

How did you find out their game used this library? Maybe I missed it but didn’t seem to be mentioned anywhere

They mentioned switching to the Steam networking backend, which for games is essentially GNS.

Ahh thank you, didn’t make the link between the names

Re: The unlikely story of Teardown Multiplayer

#57

Post by Hikikomori »

kajkojednojajko wrote: post #12

I enjoyed playing Teardown when it first came out. It was already a technological marvel back then, so it's even more impressive that they managed to make the simulation deterministic to add multiplayer several years after release. Clearly top tier engineers. Cool to see that the game is owned by Coffee Stain now, too. Satisfactory has been handled well by them, so I'm optimistic about the future of Teardown as well.

Not about multiplayer but still interesting.

Dennis Gustafsson – Parallelizing the physics solver – BSC 2025

https://youtu.be/Kvsvd67XUKw

Re: The unlikely story of Teardown Multiplayer

#58

Post by [deleted] »

DimitriBouriez wrote: post #11
dwattttt wrote: post #10

Earlier quoted context omitted.

Video streams are not known for their low bandwidth needs, let alone adding in RTT latency for inputs.

That's true, I'm not saying it comes without trade-offs. But in return you get a perfectly consistent and physically accurate simulation. It would mostly be expensive, I think, but it's technically feasible (services like Shadow or GeForce Now already demonstrate that).

[deleted]

Re: The unlikely story of Teardown Multiplayer

#59

Post by thunderfork »

DimitriBouriez wrote: post #9

Wouldn't it have been simpler (even if technically heavy) to host the game on a single machine and just stream each player's camera? That way all the physics would be computed in real time on one computer, and each player would just receive a different video stream.

In addition to what others have said: even where remote play works, some games are worse candidates than others, and I expect Teardown would be towards the "worse" side of the set.

Teardown, visually speaking, is a pretty noisy game at times, and doesn't give a great visual clarity when streamed at real-time-encoding-type bitrates during these noisy moments.

FPS mouse+keyboard is also one of the worst-case scenarios for Moonlight/GFNow/etc. remote play, because first person aiming with a mouse relies very heavily on a tight input-vision feedback loop, and first person camera movement is much harder to encode while preserving detail relative to, say, a static-camera overhead view, or even third person games where full-scene panning is slower and more infrequent.

Re: The unlikely story of Teardown Multiplayer

#60

Post by gcr »

jerf wrote: post #37
gcr wrote: post #21

Earlier quoted context omitted.

Perhaps the solution could be to have all players stream the game from a centralized instance, rather than all clients streaming from the host’s instance. That would have a number of advantages, come to think of it. For starters, install size could be much lower, piracy would be a non-issue, and there would be no need to worry about cross-platform development concerns.

We don't have to theorize about this. We've had cloud gaming for years, and the companies have immense motivations to turn us all into renters in the cloud so they've poured a lot of effort into it and we can see half-a-dozen highly-resourced results now. We can just look at it and we can see that it... almost ... works. If you don't care much about latency it definitely works. However, Teardown is in the set of game…

For the record, my comment was a joke. I was quoting from Stadia’s marketing. :-)
Post reply on HN