For a bit more context, here's the announcement video:
https://www.youtube.com/watch?v=XfcCyMQ13XM
(Edit: fixed link)
The unlikely story of Teardown Multiplayer
41–50 of 69 posts
Re: The unlikely story of Teardown Multiplayer
#42For a bit more context, here's the announcement video: https://www.youtube.com/watch?v=XfcCyMQ13XM (Edit: fixed link)
Seems like the wrong link to me. Just a dude working on a car.
Re: The unlikely story of Teardown Multiplayer
#43If someone from Teardown dev team is here, did you guys ever tried to do the physics in voxel space? If I understand correctly, Teardown convert each physics chunk into a mesh and feeds all the meshes into a traditional physics engine. But this means that the voxel models remain constrained to the voxel grid only locally but not globally. I have been trying to figure out a way to do physics completely in voxel space…
(not a teardown dev)
i had brainstormed a bit a similar problem (non world aligned voxels "dynamic debris" in a destructible environment. One of the ideas that came through was to have a physics solver like the physX Flex sdk.
https://developer.nvidia.com/flex * 12 years old, but still runs in modern gpus and is quite interesting on itself as a demo * If you run it, consider turning on the "debug view", it will show the colision primitives intead of the shapes.
General purpose physics engine solvers arent that much gpu friendly, but if the only physical primitive shape being simulated are spheres (cubes are made of a few small spheres, everything is a bunch of spheres) the efficiency of the simulation improves quite a bit. (no need for conditional treatment of collisions like sphere+cube, cube+cylinder, cylinder+sphere and so on)
wondered if it could be solved by having a single sphere per voxel, considering only the voxels at the surface of the physically simulated object.
Re: The unlikely story of Teardown Multiplayer
#44> 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…
As far as I know, the ARM (at least aarch64) situation should be about the same as x86-64. Anything specific that's bad about it? (there's aarch32 NEON with no subnormal support or whatever, but you can just not use it if determinism is the goal) that RECIP14 link is AVX-512, i.e. not available on a bunch of hardware (incl. the newest Intel client CPUs), so you wouldn't ever use it in a deterministic-simulation multi…
The Steam hardware survey currently has FMA support at 97%, which is the same level as F16C, BMI1/2, and AVX2. Personally, I would consider all of these extensions to be baseline now; the amount of hardware not supporting them is too small to be worth worrying about anymore.
Re: The unlikely story of Teardown Multiplayer
#45Re: The unlikely story of Teardown Multiplayer
#46> 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…
At least in the early 2000s, Bloomberg had strict requirements about this. Their financial terminal has a ton of math calculations. The requirement was that they always had live servers running with two different hardware platforms with different operating systems and different CPU architectures and different build chains. The math had to agree to the same bitwise results. They had to turn off almost all compiler opt…
Ah the old Enterprise Service Bus...
Re: The unlikely story of Teardown Multiplayer
#47Earlier quoted context omitted.
They didn't explain those in detail because they didn't implement these concepts themselves. The GameNetworkingSockets library (and most likely also the internal network backend that was mentioned) provides them: > A reliability layer significantly more sophisticated than a basic TCP-style sliding window. It is based on the "ack vector" model from DCCP (RFC 4340, section 11.4) and Google QUIC and discussed in the con…
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.
Re: The unlikely story of Teardown Multiplayer
#48I feel like there's detail missing in the blog. The "Reliable vs Unreliable" section implies that different parts of the scene are sent using a strict-ordering protocol so that the transforms happen in the same order on every client, but other parts happen in a state update stream with per client queueing. But which is which? Which events are sent TCP and which are UDP (and is that literally what they're doing, or on…
There really doesn't seem to be anything new or unique to their solution. I'm personally not surprised, because it is what has worked for thirty years.
I presume you know this, but maybe for others: judging by what was written in that paragraph, I'd indeed assume he means the same paradigm that has been driving replicated real-time simulations since at least QuakeWorld - some world-state updates (in this case _"object transforms, velocities, and player positions"_, among others) don't have to be reliable, because in case you miss one and need a retransmit, by the time you receive it, it's already invalid - the next tick of the simulation has already been processed and you will get updated info anyway (IIRC this is essentially John Carmack's insight from his .plan files).
The command messages (player operations and events) _need_ to be reliable, because they essentially serve as the source of truth when it comes to the state of the world. Each game client depends on them to maintain a state that is the same for everyone (assuming determinism the Teardown team has been working on ensuring).
Re: The unlikely story of Teardown Multiplayer
#49Earlier quoted context omitted.
This seems to get brought up in every hn post on video game mulriplayer, and it makes me wonder: do you play video games? I dont know of any video games that do multiplayer that way, and i would think that alone suggests its not a good idea. Who wants to play a game with 50ms+ keypress to screen update delay? Sounds miserable.
I don't play it much anymore, but I used to be a heavy player: the latency isn't 50 ms on GeForce Now (with a French connection, which is pretty good).
GeForce Now has the advantage of being able to pick a server closest to specifically you. If you're near a major datacenter, you're probably getting sub 20ms delay. Annoying, but playable for many games. That is not the case as soon as you try multiplayer with people in different metro areas.
Re: The unlikely story of Teardown Multiplayer
#50do they have split screen multiplayer? I wish they did.