1 free read left. Create a free account for unlimited reading + AI research.
Create free account[Music] to explain the the state-of-the-art what most companies do today is so you have your game running on your local PC console mobile phone whatever and then you have other players which send you input and game State and of course you have latency all right so everything you get from the other players takes if you are lucky 20 milliseconds if you're not so lucky maybe 200 milliseconds and if they you are really not lucky at all it may be 500 milliseconds or something so then usually you have one
authoritative server in a good location who is correcting and who is the boss and he decides basically okay who hit him and who is winning or was it a headshot or not or what not again this boss is attached to you with the latency as well so now game developers or you or your net coders or the guy you developers who are doing the netcode have to figure all this out so they have to program this game to make sense with delayed information and to predict stuff and to correct the physics and everything so it's super complicated so and what we found in the past 10 years there are lots of successful games and Studios building multiplayer but all teams struggle with the latency with jitter with the lag so people do
something and it's kind of it doesn't feel it feels delayed so with cheating if your game gets successful suddenly there are a lot of cheaters trying to find ways to to use a mods to to crash your servers right so there's a huge motivation of people out there of your community just to to ruin the experience of other players right you would say this this doesn't make sense but that's so we see more and more DDoS attacks recently so this is a topic you have to deal with and of course bandwidth even though 5g and Internet and everything is getting better nevertheless if you do not pay attention and you send too much this will lead to disconnect disconnects again you have to handle it in your game let's say if you want that people can reconnect after this connect all this is the big mess right so our claim is we make multiplayer simple but I have to admit it's not really simple so and
there's a new thing happening which i think is really interesting and it's taking a very different approach which may sound a little bit magic and it is a little bit magic so let's assume you would build a game so you came without the rendering just the pure game I call it simulation and you have one controller attached to it which is your local controller all right so it can be your mouse your keyboard because it could be a controller and the other players are connected like it would be local to your game so you as a developer you do not see Network at all it looks like there are four controllers attached to your local simulation so and this is
how you build your game so there's only input input is right left up down jump shoot can be a swipe in in VR it could be like moving your hand control all right so all this is input but it's nothing so input is coming from outside into your game so it's not something that's happening it's not game state or characters moving or bullets or what's on whatnot so and the beauty is your code your writing is working single player it's working local multiplayer it's working online and in fact it's exactly the same code because again it looks like all the controllers attached to that simulation so another big advantage is that your physics engine so let's say you you are building a soccer game and you have a ball which is shared across all clients
it it's it's only there once you do not have a distributed oh I get somebody hit the ball a different player and and now but in my local simulation it's totally different this doesn't exist you just have one physic system and just by default it will be networked another big topic is BOTS so let's say some player would get disconnected so you would want the bot to jump in for him right so he would be driving through a tunnel or lose his internet connection you could but could take over this guy is reconnecting after 20 seconds and the bot is disappearing so all this is very natural in this model so the feedback from developers so first of it sounds
too good to be true right so what's what's the catch so what's why why is this why has never somebody done something like this I I don't know so to get the big picture though that simulation that I showed the same simulation is running on every client it can be 30 clients it can be 10 it can be one that's one limitation so you because you have to send input to every client there is a natural limit of how many people can play in the same game so this technique would never work for an MMO where you have hundreds of thousands of players that's another important thing so let's say you are playing with 30 people in an i/o game for example and you're and one
guy has a horrible connection so he has whatever 500 milliseconds or even two seconds of input he's sending very very late so all the other clients would suffer so that's one trick because everything is running through a relay so the relay is basically deciding if information is coming too late so the the relay can can invalidate stuff and punish the guy with a bad latency and reset him basically so right so I let's say I would be the guy with a bad latency so I would move my character and it would move up and the cat and the server would invalidate me all the time so on my screen it would look like I go up it I would be Rosetta to my position I go up and it would be Rosetta to my position on all the other clients it would look like I'm standing still and that's a big problem in multiplayer games if you don't use a technique like this to deal with clients which have a bad latency because because they have
the potential to ruin the complete experience so you want to have a very very fast protocol UDP based usually you are sending around input so you Nance you need to send stuff reliable because you want it to arrive all the input needs to arrive but it can be out of order so I'm I use the term deterministic game engine so they're usually let's say most network solutions you you get out there or if you would build your own arm or a transport layer so they give you a way to connect different clients with with a fast UDP connection and you can send packages around all right so that's what
I call a transport layer so steam networking for example if you use steam networking they give you a very fast way to send packages back and forth so usually this whole gameplay simulation and the rendering this is typically let's say what a game engine will take over so now in this deterministic game engine you need to make sure that the complete game logic is deterministic because you are you only have input and you know you need to make sure that no matter what device B the mobile phone B the PC video console it needs to generate the same game state and that's let's say the challenge or why it was so hard to develop a solution like that because this block needs to be deterministic and because of float let's
say every physics engine is usually usually you are not usually it's using floating point numbers so in floating point numbers we'll generate different results on different platforms different results means on one platform you could you could collide on the other one not and suddenly boom you are out of sync and with the same input you would generate on a phone and on a PC you could have totally different results so so in our case so we built this deterministic game engine and we build the complete simulation decoupled from the view and it provides like the complete stack from entity component system fixed port math library animation control physics engine pathfinding and everything is fitting together so you have the input layer here so the simulation only gets input
from controllers network is completely abstracted away and you do not see it at all and the view is clearly decoupled it's polling the game state from the simulation and then nicely rendering everything so one thing it needs to be super fast and and to explain that really quickly so let's say your games run your game run at 30 Hertz it means that per tick you only have 33 milliseconds basically one second divided by 30 is at 33 milliseconds so in 33 milliseconds you have to do everything you have to calculate all the game logic the physics the pathfinding and you have to render everything on the screen so let's say if you say I take 25% of my time budget 8 milliseconds and do the simulation it's
not only you have to run the simulation once but you have to cope with all the roll backs you are doing constantly so you only have half a millisecond so 500 microseconds to basically do all the calculation and you need to use really special techniques like data oriented architecture no garbage collection il-2 cpp and unity and so on and then you get really down to simulation times which are significantly below a millisecond so why does it disrupt a multiplayer game development so you have you get a completely determinant deterministic system zero lag means everything you do happens instantly its eSport grade you can do replay spectate and you can just replay the input you have a perfect replay you have cheap protection because you cannot teleport players anymore you
can only send around input so you cannot teleport clients or send game set around there's no net code you just deal with input it's low bandwidth because you're only sending the input and it's super fast so the advantages are overwhelming but again it doesn't fit for every use case out there but it fits for a lot of use cases so we built this thing has kind of a reference implementation if you want so we worked on it for three years we launched it about two years ago we've won some of the most amazing teams to use it but we are super happy to work with independent teams and to work something out so we want to get this two passionate dedicated team so we are not looking let's say for hobbyists or people who cannot afford to go even on a conference or who are not really
dedicated to this but if you have great ideas we are super happy to to unboard you so not sure if you have some perfect time we have about a minute left I am a huge fan of this because I think the demo you showed me must be in six months ago something of a small game but because the deterministic physics when it was an explosion happening the explosion moves vehicles in the same direction on every screen playing which if you know anything about trying to make physics work on games that's really difficult and it wasn't complicated to do and you just worked so anyway I'm a big fan but I'm biased anyone got a quick question for Chris off so you've either wowed them or I've scared them off genuine a really fascinating thing and it's it's very accessible to anybody but I think what's interesting is making sure you think about it first before you get started rather go down the ride the
road and try to reinvent it you know trying to reconvert your game afterwards might be a bit more complicated you [Music]
Deterministic game engines utilizing predict-rollback netcode represent a significant shift in multiplayer game development by abstracting network complexity away from the developer. Traditional multiplayer architectures rely on authoritative servers to manage state, which often results in latency, jitter, and complex synchronization challenges. In contrast, a deterministic approach treats all connected players as local inputs to a shared simulation. By running the identical simulation on every client, the system eliminates the need for manual netcode, as the engine handles state synchronization automatically based solely on player inputs.
The primary technical requirement for this model is strict determinism across all hardware platforms. Because standard floating-point math can produce inconsistent results on different devices, developers must employ specialized techniques—such as fixed-point math libraries, data-oriented architectures, and the avoidance of garbage collection—to ensure the simulation remains perfectly synchronized. The engine must also be highly performant, often requiring simulation calculations to occur in under a millisecond to accommodate the constant rollbacks necessary to maintain state consistency when network latency occurs.
This methodology offers several advantages, including inherent cheat protection, as clients can only transmit inputs rather than manipulate game state. It also provides low bandwidth usage, eSports-grade responsiveness, and native support for features like replays and bot integration. However, the approach is not universal; it is best suited for games with a limited number of participants, such as competitive action or IO-style games, and is not designed for massive multiplayer online (MMO) environments. Ultimately, this architecture simplifies development by allowing creators to focus on game logic rather than the intricacies of network transport, provided the system is integrated during the initial design phase.
Comments