Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Quasar

Netcode: The Quest Begins!

Recommended Posts

EE is now at the point where it needs some basic functionality in netcode so that when changes are made to support player classes, custom weapons, etc., those changes can be tested.

I started the process by adding in anarkavre's i_net.c module from WinMBF, which is a modification of earlier Chocolate Doom netcode. This is just a few calls to SDL_net which allow the high-level netcode to actually transmit and receive packets over UDP.

So far, the upper level netcode's behavior has confirmed every one of my fears: it is completely broken.

Problems found so far:
* If the "server" node (player 1) starts up first, all nodes will go into an infinite loop in D_ArbitrateNetStart
* If the "clients" are started first, the game will connect, run, and on the first gametic bombs out with "Tried to transmit to another node", due to "netgame" being set to false in G_DoNewGame
* If the netgame assignment in G_DoNewGame is removed, the game connects, runs, and then goes completely berserk. Player 2 has control of *both* nodes, and player 1 has no control at all. After walking around a bit using player 2, player 2's game commits an illegal operation, and player 1's game drops to console. If a new game is started from the console using player 1, the game is running at an unlatched framerate (~1000 FPS), the player shakes violently, there is no control, and consistency failure error messages begin appearing in the console.

In short, we've got a REALLY long way to go with this.

Update:




I have isolated the console from the netcode and have restored it to its state as of MBF, excepting some modifications which fraggle made in SMMU that stop the game from locking up if the key player drops. This has fixed most if not all of the problems, so EE currently has Doom's original netcode running over UDP ^_^

Share this post


Link to post

Seems netcode is the flavour of the month, I'm working on it now for EDGE and the Legacy guys are working on theirs.

Not sure I can offer any useful advice for EE. Understanding how it all works is pretty mind-bending because all the computers are running in parallel, and UDP packets can arrive out-of-order or not at all.

You need a good idea on how it'll flow. For EDGE, the "host" (server) will need to be started first. Then clients will connect to the host. When enough clients have connected, the host will send a "LOAD" command to make everybody load the map, then a "BEGIN" command to actually start the game (set gametic/maketic to 0 and start exchanging ticcmds).

Good luck!

Share this post


Link to post

We're going to look at implementing Choco Doom's code as a stopgap. We'd eventually like to have a client-server architecture, but that can be a very difficult thing to transition to, especially while retaining compatibility. We hope that Odamex will be helpful in figuring out how to do that.

Right now though it's just the plain old Doom protocol with an SDL_net backend. This should be good enough for me to be able to test modifications made for the new extension module features :)

Share this post


Link to post

Client/Server architecture (as opposed to lock-step) is indeed very difficult. I can't say I recommend it, as it changes everything, a really huge job.

I didn't mean to give the impression that EDGE is using that model (authoritive server, dumb clients), it is not, I'm just using those terms for the connection process. After everyone is connected, it is lock-step model like standard Doom, with a small change of having a reliable connection between host and client which is used for sending lost ticcmds and other admin.

Share this post


Link to post
Ajapted said:

Client/Server architecture (as opposed to lock-step) is indeed very difficult. I can't say I recommend it, as it changes everything, a really huge job.


I'd love to see a doom source port that actually does this the right way instead of hacking it on like csdoom/zdaemon/presumably skulltag/odamex does.

Share this post


Link to post
AlexMax said:

I'd love to see a doom source port that actually does this the right way instead of hacking it on like csdoom/zdaemon/presumably skulltag/odamex does.

Please elaborate.

Share this post


Link to post

You can do client-server in two ways: either "authoritative server", which is how Quake and all modern games do it, and is indeed a lot of work to implement in Doom. Alternatively, you can have a thin server that just routes packets, which is how PrBoom does it and what I've done for Chocolate Doom as well. With a thin server, you keep most of the original peer to peer structure, but just change how the data is passed around.

You really want to use a thin server at the minimum, because there are advantages just in having a client-server structure for passing data around. One of the biggest ones is that you have less problems with firewalls/NAT gateways (compared to a peer-to-peer system). It's also easier to set up.

Share this post


Link to post

Thin server is definitely the way to go, at least as a stop-gap implementation. I think that a heavy server offers certain benefits, however, like being able to sync new clients on the fly, and offering more stability (all clients can drop without killing the game).

I'll be looking at Choco Doom's netcode soon, but probably not before the next release. It looks like the Doom protocol works well enough for purposes of testing modifications for the new weapon system and other player-input-altering stuff such as inventory (netcode must transmit inventory use events). That's all I needed to proceed with the current target feature set for 3.37.00 release ;)

Share this post


Link to post
Ajapted said:

Please elaborate.


Modern Doom multiplayer source ports basically "hacks" heavy server on top of the origional doom sources. It works, but because doom was not designed with client/server in mind, there are lots of little bugs, oddities and inconsistancies that are left over from the conversion. Also, in Odamex and ZDaemon at least, it's still possible to start the game in 'single player' mode, where there is no concept of client and server.

On the other hand Quake (and most other modern games) were designed from the ground up for client/server multiplayer. There is no single player mode, and when you start a 'single player game' it essentually starts a server in the background and has the client connect to loopback. Presumably, since it was designed from the ground up with client/server in mind, you don't have any of the oddities that you find in doom multiplayer source ports.

From my limited understanding of the doom source compared to the quake source, doing things the "right" way would be very tedious and would almost guarentee that you wouldn't be able to keep things like Demo Compatability. However, considering that Quake and Quakeworld use two distinct demo formats, among other things (such as physics), and everyone has gotten along fine, I'm wondering how much of an issue it actually is.

Only problem is what you would call a net-optimized Doom. Doomworld? :P

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×