Future and evolution of DXX' Multiplayer
#11
@Alter-Fox:
I thought exactly the same. So I waited for Flip's reply as well here. Big Grin

@aqqman:
I can also make the player spawn points fixed to the bases. Still this might mean that two players spawn inside of each other (i.e. the center of the base-cube).
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#12
zico it's all right for me even if i would have to redesign few maps, could you just make spawn points fixed 0-3 for red and 4-7 for blue?
(or 0,2,4,6 for red and 1,3,5,7 for blue just in case map doesn't have 8 spawn points).

It would be better since some ctf maps wont be playable in new mode, so when making new map I can put start positions myself anywhere I want but still knowing its going to be red or blue spawn point by numbers.

As for returning your flag it shouldn't be hard, just when you touch your flag it disappears and spawns in the base?

oh please please please Smile
Reply
#13
Well, Rebirth is near excellent but you can definitely see a strain after 3-4 players, depending. If removing IPX improves that I fully support it. Rebirth improves with every damn release!
Reply
#14
Yes flip I know exactly what you mean. However please do not get me wrong: That unusual high frequency of inconsistencies in the game are actually produced by the simple fact that the host now takes up all the traffic.

If we are in a 10PPS game with 8 players and everyone firing with Vulcans the host has to manage ~ 60 KB of Upload per second. And that still happens with low-precision movement packets which also once more cause powerups in slightly different positions for certain players which already can cause redundant pickups (i.e. two or more players collecting the same powerup). Now if also the host cannot manage all the traffic, the packet loss prevention will eventually backfire and cause the whole game to go haywire. So all by itself this is not the fault of the IPX-DOS-compability mode.

Thing is however that I can improve A LOT of this by rewriting the general Multiplayer gameflow - parts the IPX-compability also relies on. I can do that seperate but it's just a pain in the ass. Best example being the firing which can (consulting Vulcan cannons or the Omega) cause almost 40% of all traffic (in worst situation).
Then there are other parts which are just too "Client based". Means they can cause inconsistencies and including packet loss to that it makes the game virtually unplayable for everyone - because of a lag of ONE single player.
Now if I can freely re-design these parts - without adding one after another layer of exceptions just for the DOS-compability mode - I can optimize the code flow to take less traffic and be immune against inconsistencies by adding host-authority which as a result only "hurts" the lagging players - not everyone in the game.

I still think I went the right way making the communication Client/Server based and adding Packet Loss. Now without thois compability I can work this to it's end.
Still that will not mean the host will have a WAY easier time: The host will still have the need to provide a safe and reliable connection. I also want to improve on timeouts in that regard:
- If a player lags like hell, fails to ship or receive important packets the player will be kicked
- If the host is lagging failed receivers will also disconnect from the game
Currently th egame only disconnects after a packet silence of over 10 seconds but does not care if even one important packet was lost (which even packet loss prevention could not save - which can happen if the host is simply overstressed). To improve there I have to be more "agressive" towards timeouts. So if you are sitting there, reading this text while your Wireless signal is barely at 30% - this might be bad news for you.

But in the end I think that in a near future I can evolve the Multiplayer to an acceptable state where you can be assured that even tho you can experience lags or even a timeout or two you can participate in games where you can be sure that what YOU see on your screen is the SAME what every other player sees - unrelated to if every player has a near-perfect connection.

Maybe it's a too ambitous goal for me - after all the engine IS old - but here I can come back to the topic: If I do not have to watch to keep Multiplayer compability with the game of 95 I CAN have the freedom to work towards this goal wihtout too many distracting obstacles.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#15
I'll throw in my vote...definitely kick IPX...UDP is the way of the...well...it's the way of NOW Wink
Reply
#16
Quote:If a player lags like hell, fails to ship or receive important packets the player will be kicked
- If the host is lagging failed receivers will also disconnect from the game

Would you explain this further? Seems to me, especially considering EU-USA games, that we are much more likely to encounter laggy players than we are those that have no access to their routers. Which also seems like an end-user problem. I honestly think that the multiplayer should be designed with the lowest common denominator in mind, and if we think to exclude others, it should be those(either through ignorance or bad hardware)that cannot figure out how to simply open a port up. A necessary skill for anyone attempting to master the intanet anyways. Just my 2 cents, but most important to players would be as close to lan-like as possible.
Reply
#17
Okay so let me explain two things:
First I know I always talk about IPX vs. UDP.
However technically this is wrong. I rather mean by that: MS-DOS-compatible-Multiplayer vs. Rebirth-only-Multiplayer. Whatever I do now with the Rebirth-only will work on ALL protocols. Heck it would EVEN work on IPX - I just don't do that since it makes no sense compared to UDP.
We could make this work on TCP for example in a matter of days and IPv6 also is no problem anymore. So whatever happens to the Multiplayer WILL be future-proof and protocol-independent AS LONG as we do not force a certain amount of compability to non-Rebirth games.


And now to the thing Flip brought up:

The short thing is as follows: You have to make sure all important packets arrive. If that does not happen - the game will get inconsistent. Host-authority or not. If a laggy player misses an important packet, he WILL get an inconsistency. You can only prevent that by kicking him out of the game.

HOWEVER please note that now with a lot more Freedom I can make this conecpt a LOT less spooky than it sounds. Right now games get inconsistent since often hosts seem to underestimatre their bandwidth. As said without any compabilty to DOS games I can optimize the traffic more which will lead that hosts will have less traffic which will also lead to less timeouts.
Also I can rework certain packets so some "important packets" will become packets that can get lost while the game corrects the loss later.
Example: The score computation can get totally screwed if one player loses just one score packet. Now with my idea on how to rework that these packets will not be "important" anymore as as single lost score packet will not be a problem anymore. Sicne now such a packet is not flagged "important" it will cause less traffic - as no ACK is needed - and it's one less reason to kick in case of loss.


Of course this is just a very simplified example of a big bunch of changes I plan to introduce. The aim IS to make the game less laggy. With optimizations I can contribute to that. And it's not that each time someone is laggy in movement he'll be kicked some seconds later - on the contrary. The game will get less and less reasons to even screw up or remove a player in the long shot. The goal is to MAKE a concept that can correct the behaviour of laggy players - not punishing them. Of course if the connection is TOO laggy a player has to go to not screw the whole match.

I think tha tnow was all a lot of talk and I have no idea how it makes sense.
Short story is:
Yes, some players HAVE to go before an inconsistency can happen. But you should notice that with all the changes I have in mind such situation swill become WAY less likely than they are now.
EDIT However it will not get as few traffic as it was in time of Peer-To-Peer (a system which makes host-authority almost impossible). That - unfortunately - is a sacrifice we HAVE to make for a competitive Online mode but not a big one considering how wide our bandwidth is nowadays.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#18
Well, I'm interested to see these improvements and I trust you know more than I do about how to make the gameplay as realistic as possible. I've noticed that games with up to 3-4 still plays very acceptable but across the board, every game that fills up (6-Cool ends up with every player in the game bursting and becoming unplayable after just a few moments. Albeit, large games like that are uncommon at the moment but activity seems to be increasing every month Smile
Reply
#19
Yeah it's pretty much that balance between > 4 players. As you must know that when you come from 4 to 8 players the host has a lot more to do giving everyone positional data from everyone. With 4 players you have a positional data packet with size X and you send this to 3 other people. When having 8 players the packet is roughly doubled in size AND you have 4 more receivers. So in the end the traffic nearly increased by the factor 4 from 4 to 8 players. Same goes for all other kinds of packets. Imaging a crowded map where every player is shooting at everyone at the same time.
Just the sheer horror the network stack has to take often is too much. Now if a host thinks it might be pretty cool to play with 20 PPS ... you know - Descent might be old but all this data simply is there and it might very well be around 120KB/s Upload - per friggin second (again, 8 player game).

As said, there is stuff I can do about that. I can optimize quiete some stuff here and there. Still this is a bunch of data and we just cannot ignore it. Positional data is pretty large and the game doe snot care if it's from the 90's or from 2011 - it's all the same amount of data for a player position (I just said that since one might think why such an old game can produce so much traffic).
Actually many games might run WAY more smoother and consistent if a host would possibly reduce the PPS to 8 or 7.

Of course the PPS decision you make before launching the game and also you might not be aware how much traffic your PPS/player-limit balance might produce. I think about something easier there as well (but that might not happen for 0.58, yet). I mean there IS a reason why many games use dedicated servers - these boys just HAVE a proper connection able to handle this while a Windows XP has a network stack you can overload easier than a 5 year old midget with a bottle of absinthe - which also is a serious problem... the stack - not the midget...

Anyways there is a logn way to go and I am perfectly aware that I might not meet everyone's expectations. I might just not be able to reduce an 8 player traffic below 40KB/s or allow a Wireless palyer with 20% signal strength to play without a single timeout...
But I guess we'll see about that when we reached that point. I can just say that it WILL get better from here in terms of consistency/smooth gameplay AND traffic. How much tho is what we need to see.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#20
Awesome, sounds great. I can see no other obvious flaw in Rebirth aside from this traffic issue.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)