This approach is very clever and has a few significant advantages. The underlying transport was pluggable (this being the days before we’d even standardized on IP), which complicated things a bit, but the Unix port that’s on GitHub just uses UDP.
Only sending input means there’s not that much to send, and the receiving end just has to queue up packets from every peer and then play them back once it’s heard from everyone. You can read the code if you want to, but at a glance, I don’t think there’s anything too surprising here. There’s no client or server every peer talks to every other peer. Once a node has received input from every connected player, it advances the world by one tic. Rather than passing around the entirety of the world state, Doom sends the player’s input to all the other players. To play back a demo, Doom runs the game as normal, except that it reads input from a file rather than the keyboard. Thus, if you play the game twice with exactly identical input, you’ll see exactly the same playthrough: same damage, same monster behavior, and so on.Īnd that’s exactly what a Doom demo is: a file containing a recording of player input. There is no seed, either a game always begins at the first value in the list. Its random number generator is really a list of shuffled values each request for a random number produces the next value in the list. Surprise! The thing I know is, roughly, how multiplayer Doom works.ĭoom is 100% deterministic. Well, joke’s on you! I don’t know anything about networking.
You’re hoping for my usual detailed exploration of everything I know about networking code in games. How about do something on networking code, for some kind of realtime game (platformer or MMORPG or something). :DĪh, I see.
0 kommentar(er)
