Future and evolution of DXX' Multiplayer

[aqqman]

Zico
I wonder what is best solution to deal with inconsistency and lag.
I'm aware that increasing amount of packets isn't a solution...it maybe went too far in 57 since some people who could host a game for 8 before can't do it now without problems like big score differences(which shouldn't happen in 57? or I just misread something) 
I know I was among those who were trying to convince you to that host authoritative solution... however I have some doubts. I'm afraid that it may split community based on location because playing with ping like 250 and enjoying the game at the same time wont be possible any more unless we had dedicated servers which is not going to happen.
I remember bugs and inconsistency in 56 but that time pretty much everyone could host big games.
I don't know, peer to peer or host authoritative but in second case it would be hard to find person with really stable and fast connection to play 6 or more players smooth game.
Maybe some mixture of 2 could work better, something like general less accurate positioning and scoring being handled by the host based on players position - once they move closer more packets go between them in p2p fashion... 
I just thought if you would take some good stuff from 56 and some from 57 it would be perfect somewhere between I mean like a bit less bandwidth demanding from host but still accurate... two opposite goals for host authoritative protocol , I know.

[zico]

Okay just for a note: 0.56 already had Client/Server communication. 0.55.1 was the last with P2P technology and the last one with very little host-traffic.

But to the actual point:
We need to differenciate here - having two players on the opposite ends of the world will not really make the traffic-problem worse. This is just a problem of delay and with host-authority this problem is much LESS of a problem in terms of consistency but a more fatal with P2P.
Another thing with P2P and the ONLY reason I initially went away from that is that a large amount of players do not know or do not have the ability to open ports needed to play. Remember for P2P communication to work, ALL players need their ports to be open. Soon as one player has port closed he will not be allowed in the game or the host has to take the traffic which brings us in the same position as now.

Of course I can revert to the state of 0.55.1 but then it means - all open ports and possibility of inconsistency. Or I go all the way through and the only problem you'll have if your connection isn't that good (somewhere between 20 and 30KB/s upload per second) is that you probably should lower the PPS to 7 or 8 OR limit the game to 6 players.

When I am talking about 60 KB/s upload right now I refer to the most stressful traffic the game is able to reproduce and does not represent anywhere near the average traffic. So even if your upload is limited to 50 you will not get inconsistencies with 0.57.1. if some packets are dropped, this version will already be able to handle that. Just the long-term capabilities aren't that good and I am right now writing on code to improve on that.
Heck, my last commit already improved on the "weapon-fire"-issue easily reducing the fire-packet-traffic by 50% for weapons with very high fire rate (Vulcan, Omega). and I have not even begun to optimize the sizte of the packets themselves.

So in short: There will be progress and there already is. I'll also attempt to make some test games with some folks before I'll release any of te code to the public to see if there are more bandwidth bottlenecks I should erase. Again the bandwidth requirements will neve rbe so low as with P2P but since we surpassed the modem-age I sure can give you something that'll work out much better than the most recent version of the Multiplayer now that I can freely change and rework on all possible parts.

[aqqman]

That's good news.
I was just worried lately how few folks can host decent game for 8.
I don't remember much now but wouldn't tcp improve some things with handshaking dialogues for providing reliability, ordering, or dealing with packetloss ?

edit: on the other hand I guess you have less low level control with tcp and it may be easier to choke the host with resending packets

[zico]

If it turns out half that good as it currently goes I can definately say that you can definately host 8 player games with 2/3 (saying "at least" but also considering that the maximum bandwidth requirement is far from the average but it's certain that in both cases we'll see improvements) of the bandwidth requirement of 0.57.1.
Regarding TCP... well - handshaking would only be something for P2P. For any other things TCP would probably compromise more than it brings. Sure it prevents packets from being lost but also those which are not that important (it just does not matter if you lose one positional update for a player every 5 seconds or so). However TCP comes with a price in terms of speed and bandwidth. It's actually much easier and more controllable to handle packet loss by myself. Also Host-authority does introduce a nice side-effect where many game operations which relied on correct packer order and the need of certain arrival in a short time frame will jus tbe obsoleted. Again this will compliment towards the host-traffic and reliability without the overhead TCP would introduce out of the box.

[Flip]

We got confidence in ya Zico! I will just add so that you know what your dealing with. 2 player games, I've got demos from both sides showing a significant amount of plasma going through opponents. But it seems to come and go and hardly noticeable in a 1V1.
Once you add the 3rd or more it goes down hill quickly. 6 players, everyone lags and at times I've seen ships just disappear or appear out of nowhere. I have this on that same demo with just 2 of us, but it's pretty common in larger games. As of right now, the only games that are even playable without a great deal of frustration, is games with no more than 4. You say lowering pps will allow for more players?

[zico]

How good the hit detection is will always depend to a high degree on the PING. That's always the case. Now the higher the traffic is, the higher the ping tends to get. And of course with Client/Server traffic the host ping is also important for hitting any player. So if the host has a significantly high ping, you won't hit anything. Lowering the PPS will of cource make the ships move a bit more choppy but the traffic and ping *can* (but does not have to) decrease pretty much.

So as it may be: For keeping games consistent and "in sync" the ping/packet delay will not matter too much. But for hitting something, ping is the most important thing. If with higher players the ping gets worse then I can assure you will see improvements there. But I can not genereally improve the ping for all players around - just make the best scenario to ensure the best ping possible.

[Flip]

A 100 ping in a 1v1 doesn't seem like that much of a burden to see so many inconsistencies. I'm not arguing with you here. Just making you aware of the circumstances. I can understand there is no solution for "loss", but considering the community, ping should be a high consideration.

[aqqman]

I always thought other way around, ping - you just cant help it -its distance
packetloss is something to work on - resend packets as long as there is some room.
Without packetloss you can adjust your aiming no matter how high the ping is, but if you lose packets it is no way to use any adjustment, the game is just inconsistent and ping may be jumpy too.
another question:
If the person has 1Mbit/s upload and game/scores go inconsistent with just 4 players what does it mean?
(10 pps) It didn't happen in 56

[zico]

Okay I think I have a bit of a hard time to explain that - I am sorry.

First when I usually talk about inconsistencies I mean scores are different for players, multiple players being able to pick up the same object, Player A destroys a robot but the robot still being alive for Player B. This is what I primarily work on. Since these effects can always happen with simple packet loss. I do not only want to improve on packet loss handling but also adding more host-authority so that inconsistencies can be prevented by the flow of the code itself. As an example: Player A could not pick up powerup just collected by Player B as the host first agreed that Player B picked it up and will not give permission to Player A in that regard.

The second thing I work on is the traffic going on in the games. Traffic from weapons now is optimized in first step and next - after making Packet Loss Prevention handling more organized - I'll optimize the player positions, making them more accurate AND less traffic intense.


Now as aqqman said: Ping is something you cannot improve. If a high Ping is there, we cannot "fix" that (okay, we basically COULD do something by adding Client side movement prediction which would again make hitting easier but I first have to read a ton of tutorials before thinking to implement that).
However: As Flip pointed out hitting is way more hard the more players are in the game. This also has some kind of logic and I think this is the actual problem. The higher the traffic is, the more fire and positional packets might get lost in action. The game is not supposed to prevent the loss of THESE packets since both fire and positions are just time-relevant. So with the engine of Descent it means: Either NOW or NEVER.Doe snot help if you resend a fire packet as it only adds more delay to the shot, making you miss your target nontheless.

Again, this is where I improve. And also improve for these guys already having a bandwidth high enough (as even they are not protected from their network stack overloading - this micro management is very interesting actually).
So that is what I said that I cannot improve the ping, just make the best scenario to ensure the best ping a host can offer.

I admit that the jump from P2P to Client/Server was a big one. And I also know folks had nothing better to do than to place critique on how hard this is to do with this engine (instead of actually contributing something) but I KNOW I am on the right way as I know it's the right thing to do.

@aqqman:
It's also interesting that often it's considered 0.56 being more robust when it comes to traffic even tho this version basically produces the same amount of traffic as newer versions. But one thing I can say now: If I am done with my changes - esepcially the managament of packet loss handling - if you would THEN see score inconsistencies or somthing - making games out of sync I cwill then be able to directly pinpoint it to a flaw in the game logic (which is simplified on this way already) not needing to wonder if it might just be simple loss. When networking - especially with an engine that just makes no insurance on packet arrival but relying on it working flawlessly ... well you can see where this potentially ends. For me this is one of the most important parts and I want to get rid of this "insecurity2 once and for all. Everything going wrong after that is something I can blame on the code - not someone's connection.

[Flip]

And I also know folks had nothing better to do than to place critique on how hard this is to do with this engine (instead of actually contributing something) but I KNOW I am on the right way as I know it's the right thing to do.

Heh, that's good enough for me, just so as we don't have to wait till sometime 2013.................