How does this source port handle multiplayer?

[TheNoob_Gamer]

Been searching for an alternative to PRBoom+ now, and this seems to be the perfect choice. I'm still very much fuzzy about the multiplayer components of the port, though, so, title.

[seed]

Summoning @printz & @Altazimuth.

[printz]

Summoning @Ladna (even though he actually left years ago) and especially @Edward850 :-P

 

I haven't checked multiplayer development myself and I have zero experience unfortunately.

[Edward850]

The multiplayer component as it is tight now is basically the same as prbooms, though using the less intuitive -net param. I hope to have a new experimental netcode out one day. 

[Danfun64]

PrBoom 2.5 or PrBoom-Plus? Didn't the multiplayer side of PrBoom-Plus fall into disrepair to the point that even entryway said "play PrBoom 2.5 for multiplayer instead of my port"

[Ladna]

C/S netcode in Doom is hard for several reasons.

 

Doom is a fast game, so the netcode has to be high-performing.  You can't skimp on this, or you'll cause cascading problems.

 

C/S netcode by itself is a pretty deep area.  The main worry is you'll bake desyncs deep into your protocol without a plan.  But there are lots of things to work on too: lag, packet loss, prediction, reconciliation, randomizing the order you think on players, projectile nudging....  Each of those things is pretty deep too.  I spent months just on sound sync, for example.

 

There aren't really good libraries for it.  There's ENet, but it has a pretty hard limit of 4095 connections (maybe an issue considering spectators) and you have to build tons of stuff on top of it.  EECS and D2K use(d) ENet, but these days I think that's a mistake.  Reliable UDP isn't actually that useful.

 

Doom assumes it's always using the P2P, TIC/command based netcode everywhere, and that means you have to change a lot of things, everything from finales, to the automap, to player commands themselves.

 

As a result of this, it's very easy to break demo sync.  Unless you have a great testing framework like Odamex and D2K, it'll be so hard to maintain you'll probably give up on it.

 

Doom really thinks there should only ever be 4 players.  Boom increased this limit to... 64?  Changing this further requires a lot of thought, think about scoreboards, saves, etc.  And of course, monkeying with this affects demo sync.

 

Once you bring C/S netcode into the fold, you need to do a lot to make it usable.  Things like a console, a sane configuration/menu system, a way to find servers and join games, a C/S netdemo system, and a way to manage and monitor servers--either an RCON system or a standalone server console.  You probably want to implement different game modes (e.g. TeamDM or CTF) or statistics.

 

Finally, modern Doom is a moving target and it's not all up to you.  People will design popular new LUMPs in formats you think are garbage or require a lot of work from you to support, extend ACS or implement their own scripting whatevers, build new mods directly into source ports, etc.  Like any source port author or modder, you'll have to make your own personal choice about how much of that to implement yourself, and how much to get involved in designing those things.

 

I'm basically retired, but I was tinkering around w/ D2K over the holidays and it's kind of impressive.  The netcode evidently works, it preserves demo sync, it has a console, scripting, and a new config/cvar system.  I think where I left off was refactoring the netcode to be clearer so it could be used by other ports.  If you (or anyone else) are looking for a project... :)

Edited January 20, 2020 by Ladna

[drfrag]

I've tried PrBoom+ local and the SDL2 version works, SDL1 versions had severe lag. There's a problem: all players wear green. Also Choco SDL1 had lag.

[TheNoob_Gamer]

Spoiler

<removed>

 

Edited January 21, 2020 by TheNoob_Gamer