Being picky about packets

[LanHikariDS]

So, just wondering about a more technical aspect, ZDoom (And I'm assuming Vanilla Doom, and most other source ports) uses a networking method where in multiplayer, the other player just sends button inputs for their respective player Thing to act by (Much like an RC car). However, if there should be a desync, they'll look like they're running around and shooting blindly, possibly even into walls (Like broken demo recordings). Are there any source ports that (At least give the option to) sync up the X/Y axis and rotation of things at an interval, instead of letting desynced players run mad? I've a coop idea I want to work on, but it sadly needs this (Or some very complicated scripting.)

[VGA]

I think they run mad because of the client-side prediction that is going on.

[LanHikariDS]

Exactly. I would like to stop this. I'm making a map where there WILL be desyncs, and I don't want them to affect this too much. So, say for one player, a hall is open, but for another, it is closed. The player who it is open for could run through it, but for the player who can't, it looks like the one who can is just running into a wall, and desyncing. If instead of streaming live Demos, it synced X/Y coordinates, the player who can't go through would see the player who can (Somewhat) seamlessly clip through the wall, and it can continue as it should.

[fraggle]

LanHikariDS said:

Are there any source ports that (At least give the option to) sync up the X/Y axis and rotation of things at an interval, instead of letting desynced players run mad?

The simple answer is that it's more complicated than that. There are far more things than just the player positions which need to stay in sync. What you propose would "paper over" the problem but eventually you'd notice that the game is completely desynced in other ways.

What you really want is an authoritative client-server networking engine, like what Quake has. There are several ports which implement this: Odamex and Zandronum are a couple of them. My best suggestion is to switch to one of those instead as they're ports designed for multiplayer (which ZDoom isn't).

LanHikariDS said:

Exactly. I would like to stop this. I'm making a map where there WILL be desyncs, and I don't want them to affect this too much. So, say for one player, a hall is open, but for another, it is closed.

What you're proposing certainly sounds imaginative, but the summary is that desyncs are really a bug and I don't think there's a way to make this work properly. Even if you "fix" the player positions, the game will eventually fall apart in other ways. So I think this is a losing battle.

The most you can probably get away with is using visual tricks. For example you could maybe have a hallway where one player sees a line having a solid texture while the other player sees the same line as transparent. But if anything is physically different (like a door being open instead of closed), the game can potentially desync.

[RestlessRodent]

In ReMooD, the server player is the player who defines the state that clients should also be in. If a desync is detected then the client which desycned will be removed from the game. I prefer the player to be removed so they can reconnect rather than letting them run around in a desynced state.

[LanHikariDS]

fraggle said:

Even if you "fix" the player positions, the game will eventually fall apart in other ways. So I think this is a losing battle.

If you're referring to monsters desyncing, I don't see that being too big of a problem, as the player generally won't leave the sight of the monsters. There will be physical changes, but only in slight ways.

GhostlyDeath said:

In ReMooD, the server player is the player who defines the state that clients should also be in. If a desync is detected then the client which desycned will be removed from the game. I prefer the player to be removed so they can reconnect rather than letting them run around in a desynced state.

That's going to be a huge problem for my project...

fraggle said:

But if anything is physically different (like a door being open instead of closed), the game can potentially desync.

I figure it will still desync. Even if common monsters still desync, it won't matter that much, as monsters will desync from the start. I just need player positions to sync up, or else it won't work at all.

[Gez]

Monster behavior depends on player action. If there's a desync, monsters will not behave the way they did for the synced player.

You can test that easily. Make a quicksave at some point, do some action, and look how the monster reacts. Then reload the save and act differently -- the difference can be as slight as simply moving in a different direction, no need to shoot or activate linedefs.

And of course, monster actions have an influence on the player.

Example: in sync, monster moves left, running along a wall. Player shoots it and continues, entering in a corridor. After moving forward a second, player turns right and enters a room.
In desync, monster moves right and blocks the entrance of the corridor. Player shoots the wall, and tries to move in the corridor but is blocked. After a second of being blocked by the monster, player turns right and move a bit, still in the same room as the beginning.

You may force player positions to stay in sync by transmitting their positions, but suppose there's a cyberdemon. In the synced game, the player managed to two-shot it and continue. In the desynced game, the player missed because the cyberdemon wasn't in the same place. The cybie then sends a volley of rocket on the desynced player, who being unaware the dead cybie is still alive, doesn't try to dodge them. Player dies. For the rest of the game, the corpse moves around, mimicing the actions of the player.

[LanHikariDS]

I'm aware of this, Gez. I'm relying on these Desyncs for some of the challenge, forcing players to stick together and take down monsters that are syncronized to them. Plus, I'm not going to be cheap about it. I don't yet plan on including any large enemies like a Cyberdemon, but if I do, it'll be in a synced up arena. If player positions are synced up, and there's no desyncs for the player to access in sight of the cyberdemon, there shouldn't be any problem, as the players won't be able to lose sync when in sight of the cyberdemon.

[Edward850]

fraggle said:

(which ZDoom isn't).

Hang on, that's a silly statement. Of course ZDoom is meant for multiplayer. That's why it has it in the first place. Or is Vanilla Doom magically not now, either?

[Maes]

Edward850 said:

Hang on, that's a silly statement. Of course ZDoom is meant for multiplayer. That's why it has it in the first place. Or is Vanilla Doom magically not now, either?

He probably meant that it hasn't any special countermeasures for handling desync, such as movement prediction, freezing/slowing the game until all clients catch up etc. Multiplayer will only work correctly on a network with 100% guaranteed packet delivery and pings within a strict tolerance, which may work OK on a LAN or even over a serial cable, but not over the wild, open Internet. For that, you need ports which can handle those problems more gracefully.

[Edward850]

It seems to work perfectly fine over the internet.

LanHikariDS said:

I'm aware of this, Gez. I'm relying on these Desyncs for some of the challenge, forcing players to stick together and take down monsters that are syncronized to them. Plus, I'm not going to be cheap about it. I don't yet plan on including any large enemies like a Cyberdemon, but if I do, it'll be in a synced up arena. If player positions are synced up, and there's no desyncs for the player to access in sight of the cyberdemon, there shouldn't be any problem, as the players won't be able to lose sync when in sight of the cyberdemon.

I have no idea on why you posted this thread on two different forums (that is actually kind of annoying) but anyway.
Relying on broken behaviour to do broken things is, in fact broken. It's cheap from that start, no matter how you twist your words. Only syncing up player positions will not leave you with a resynced game, and relying on a kludge to fix everything is a complete disregard of sane design. Or basic sanity. Anything to do with the word sane.

[fraggle]

LanHikariDS said:

If you're referring to monsters desyncing, I don't see that being too big of a problem, as the player generally won't leave the sight of the monsters. There will be physical changes, but only in slight ways.

Monsters are the biggest example but there are likely others as well. But really, because of the way Doom's random number generator works, "only in slight ways" isn't good enough, I'm afraid. It only takes very, very small changes in game behavior to throw the entire game out of sync. I've had a lot of experience of this kind of thing when dealing with issues related to demo sync, which is essentially the same problem.

Edward850 said:

Hang on, that's a silly statement. Of course ZDoom is meant for multiplayer. That's why it has it in the first place. Or is Vanilla Doom magically not now, either?

I think my post was clear enough, but if you want to be intentionally obtuse: yes, ZDoom includes the ability to play multiplayer games, as do most source ports. However, it's clearly never been a primary focus of the source port (I think the authors have even stated as much?), and the original vanilla-style synchronous multiplayer that ZDoom retains is pretty limited. This is the reason why Odamex, Zandronum et al. exist.

Edward850 said:

Relying on broken behaviour to do broken things is, in fact broken. It's cheap from that start, no matter how you twist your words. Only syncing up player positions will not leave you with a resynced game, and relying on a kludge to fix everything is a complete disregard of sane design. Or basic sanity. Anything to do with the word sane.

There's no need to be so hostile. You can make your point without being a douche.

[Edward850]

fraggle said:

it's clearly never been a primary focus of the source port (I think the authors have even stated as much?)

Sans the part where I'm the current maintainer of ZDoom's multiplayer framework, Randi has repeatedly inquired and maintained multiplayer functionality in new features and remains accounted for. While the point isn't to make it Quake 3 Team-arena any time soon, it is to make sure Doom multiplayer functionality remains as expected.

Being comparatively limited should never be a reason to completely disregard something, however. PRBoom+ is pretty limited, isn't it? It sure can't do everything ZDoom can. The multiplayer exists to make sure you can play multiplayer as you always could.

fraggle said:

There's no need to be so hostile. You can make your point without being a douche.

On reflection that was a bit too strong indeed. Maybe I'm just tired of these sorts of questions. The "no-one else has done this, therefore I must" style of not thinking about just why exactly it was never done. It seems to be a common trend as of late.

LanHikariDS said:

Are there any source ports that (At least give the option to) sync up the X/Y axis and rotation of things at an interval, instead of letting desynced players run mad?

I just remembered this is impossible anyway. In Doom, the network runs ahead and independently of the actual game (the network is actually what tells the game to run, not the other way round). This is what allows network latency to not disrupt the game performance. This introduces a problem with your idea in that you can't send information about the player's current position because the next network command you create isn't necessarily related to the current gametic (even in singleplayer).

You can't go back and resend old information because a remote node will have most likely have already processed the gametic by the time they receive the new information, so the only way you could theoretically resync a player is to physically halt and realign the gametic and the network tic, which is too slow and disruptive for a live game, especially on something where you could be 300ms behind from network latency alone.

Which means you need to wait 150-300ms for all remaining commands, processes all gametics to flatten your input to the gametic, then wait another 300ms for the game to start back up again due to response times. This added to the concept that you need to pre-empt when to halt the game to all active nodes, as you all need to be sitting on the same flat gametic/nettic.

That is simply just to much time.

[LanHikariDS]

Edward850 said:

The "no-one else has done this, therefore I must" style of not thinking about just why exactly it was never done.

I'm not simply doing this because it hasn't been done, but because I think it a neat cooperative idea.

Edward850 said:

I have no idea on why you posted this thread on two different forums (that is actually kind of annoying) but anyway.

Because, not everyone is registered on both forums, and someone with my answer may only reside on one forum. Plus, on ZDoom forums, I initially asked if there was a way of doing it in ZDoom. Here, I just asked about ports that can do it.

Edward850 said:

I have no idea on why you posted this thread on two different forums (that is actually kind of annoying) but anyway.
Relying on broken behaviour to do broken things is, in fact broken. It's cheap from that start, no matter how you twist your words. Only syncing up player positions will not leave you with a resynced game, and relying on a kludge to fix everything is a complete disregard of sane design. Or basic sanity. Anything to do with the word sane.

I don't expect synced players to keep everything synced, that's where part of the fun comes in. But on a bigger enemy like a Cyberdemon where cooperation would be needed to take it down, it would be synced up, as no desyncs would happen onces it's active.

"Basic Sanity"...? What's that?

Edward850 said:

In Doom, the network runs ahead and independently of the actual game (the network is actually what tells the game to run, not the other way round). This is what allows network latency to not disrupt the game performance. This introduces a problem with your idea in that you can't send information about the player's current position because the next network command you create isn't necessarily related to the current gametic (even in singleplayer).

You can't go back and resend old information because a remote node will have most likely have already processed the gametic by the time they receive the new information, so the only way you could theoretically resync a player is to physically halt and realign the gametic and the network tic, which is too slow and disruptive for a live game, especially on something where you could be 300ms behind from network latency alone.

Which means you need to wait 150-300ms for all remaining commands, processes all gametics to flatten your input to the gametic, then wait another 300ms for the game to start back up again due to response times. This added to the concept that you need to pre-empt when to halt the game to all active nodes, as you all need to be sitting on the same flat gametic/nettic.

That is simply just to much time.

... What?

[fraggle]

Edward850 said:

Sans the part where I'm the current maintainer of ZDoom's multiplayer framework

Ah, okay - I wasn't aware of that. I understand your point a bit better then. But this is news to me - I've never thought of ZDoom as a port for multiplayer.

LanHikariDS said:

I'm not simply doing this because it hasn't been done, but because I think it a neat cooperative idea.

Yep, that's why I called it "creative" in my previous comment. But the fact is I simply don't think you can make it work in the way you want to make it work. You can maybe do some texture effects like the ones I suggested, but any kind of trick like this needs to be pulled off very delicately. Game sync is a fundamental limitation you need to work within and not work around.

[Edward850]

LanHikariDS said:

... What?

Doom's gametics are controlled by by the network, even in singleplayer, and is constantly ahead. This means that you can't actually sync information from the game state back to the network to modify the next gametic, as the intended gametic would have by every possibility already run by the time the network can feed that information back. Basically your inputs are buffered ahead of the actual game you're playing, which is done so that network latency has no effect on the speed of the actual game.

Under the right conditions and settings, you could buffer a couple of seconds worth of input commands in a live game. If you wanted to sync any data for the next gametic, you would need to halt the game for at least 4 seconds to correctly sync that data for all nodes.

[kb1]

I applaud the goal of making unique mods, but I'm afraid that this one will just frustrate your users. Having played a few desynced games, I can, at least offer some of my experience in them. Here's an example of what can occur:

Player 1 is looking at an empty room of corpses, but player 2 has dozens of live monsters in the same room. Player 1 goes to help player 2 (in player 2's reality), by moving to the room player 2 is in (in player 1's reality), but when player 1 gets there, on player 2's screen, player 1 is not there - player 1 was killed by one of the still roaming monsters, and has respawnned at the beginning of the map!

The only way we knew what happened is that both computers are beside each other on the same table, so we could look over each other's shoulders.

We actually could finish the level, because of the computer monitors being visible by both of us. Otherwise it would never be possible.

Now, the port could be modified to send and receive Angle, X, Y, and Z positions of each player, and sync them up, but which copy is believed? Does player 1 use computer #1's position, computer #2's position, etc? Or does each PC believe it's player's position?

And, let's say you resolved that question. You'd then be placing some users inside doors, monsters, or even other players. Monsters' positions would be completely different on each computer, meaning that a given spot may be clear, or occupied, with no way to tell.

Supposed you solved that problem, somehow. Now imagine a revenant shooting a homing missile. On one computer, the missile hits the player in the face. But, on the other computer, the player's position is adjusted in the nick of time, and the missile flies past his ear. Now you've got a dead player on one computer, and a live player on the other. How do you synchronize that?

The slightest desync will make the game radically different, in most all situations. I had a desyncing demo one time, that went out of sync because I forgot I had changed the height of a lamp. A missile flew over my changed lamp, when it should have been blocked by the lamp. Soon after, DoomGuy was riding a wall, getting shot in the back, due to desync.

Maybe, you've devised some awesome way to turn that into a fun game, but I'm not seeing it yet. And, it should be really difficult to make a source port go out of sync - the source port is trying it's best to prevent that. I guess with scripting you could specify a situation that translated into differences across nodes (such as specifying consoleplayer).

In normal circumstances, the source port will detect desync, and either boot the player, or, better yet, force a game save on one of the nodes, transmit that game to the other nodes, and then force a game load on each node, bringing the game back to a known state. However, I have not yet implemented this detect/save/reload stuff, because my theory is that, if the game desyncs, there's something wrong with the port or the hardware (or the game definition, or level), that needs to be fixed. I cannot imagine supporting purposeful desync - it'd have to be awful fun :)

[LanHikariDS]

Well, my idea was to create something like Fractured Soul, but with two players. The players would be on two largely similar maps, but still with some slight differences, and they'd have to work together to get through the level. Some doors/switches can only be activated by one player, some by the other. The same was to go for monsters: all monsters could attack any player, but some monsters can only be attacked by certain players.

[kb1]

Maybe each player starts out in a different area, where they can see the other player throughout the level, but can't get to them. Each player would have switches that the other player needed to be clicked. Player 1 could help player 2 by shooting thru one of many windows, and vice versa, but never actually cross over to the other side until much further in the game.

(That's actually a neat idea, I think :)

[Danfun64]

That's pretty much what Portal 2 did in the first coop level. The best part about that idea is that it doesn't revolve around desyncs to begin with.

One half would have a rocket launcher, the other would have a switch that can only be activated by splash damage.

[LanHikariDS]

kb1 said:

Maybe each player starts out in a different area, where they can see the other player throughout the level, but can't get to them. Each player would have switches that the other player needed to be clicked. Player 1 could help player 2 by shooting thru one of many windows, and vice versa, but never actually cross over to the other side until much further in the game.

(That's actually a neat idea, I think :)

Well, I wanted it to be where they are still with each other, and can assist each other in combat. Just having them in two separate hallways would take away some of the uniqueness to it.

[kb1]

Danfun64 said:

That's pretty much what Portal 2 did in the first coop level. The best part about that idea is that it doesn't revolve around desyncs to begin with.

One half would have a rocket launcher, the other would have a switch that can only be activated by splash damage.

That was the goal - "how could it work without desync"!

LanHikariDS said:

Well, I wanted it to be where they are still with each other, and can assist each other in combat. Just having them in two separate hallways would take away some of the uniqueness to it.

Sorry, man, that happens to be the best advise I have to give - the closest thing to your idea that's feasible, as far as I know. And, it does seem like it would be fun.

Another addition: Maybe you could have a very tight passage, only wide enough for 1 player, with a super slow, tall lift that forces the players apart for some time. Or a tight passage and a long crusher, again preventing passage of more than one player. Or a lift that can only be dropped at the level start (so respanning players don't get blocked from progressing), or far past the lift. Another mechanism is a lift that player A activates for player B, but cannot himself use, and vice versa.

There are a lot of mechanisms available to force cooperation. Maybe you can't accomplish exactly your idea, but it seems like you have the imagination to make something interesting within the confines of the game's mechanics. Good luck.

[fraggle]

LanHikariDS said:

Well, I wanted it to be where they are still with each other, and can assist each other in combat. Just having them in two separate hallways would take away some of the uniqueness to it.

I think your best bet is probably to put them in separate, identical hallways but find clever ways to give the illusion that the two hallways are the same one. It's easy to synchronize doors opening, lifts moving, etc. With sufficiently clever ACS you might be able to make eg. fake monsters which copy the position of a real monster in the other corridor.