Smoother gameplay on iClassic through FB/iPhone?
Is it impossible to set it up so that you can use the UDP protocol on the iClassic server? I ask because not only is TCP slightly jumpier, but it seems like players skip around more when they spar on the iClassic server.
If you were to log on UN and spar when both players are using the UDP protocol, it's 100% silky smooth with no noticable lag. Not really sure if this is a question or a suggestion so I placed it here. Any insight? I really should record a high-res vid and put it on youtube showing the difference between sparring & movement when both clients use UDP vs both clients using TCP. It's immense! |
In theory (I'm not sure enough about the technical aspects to know how much difference it makes) peer-to-peer UDP could be a bad thing if it's around a huge number of players. This is due to the fact that you would be sending data to each and every different player, whereas the more conventional protocol only involves uploading data to the server.
I have had experiences on PC Graal where sparring someone without a great connection but using UDP is silky smooth while there's only a couple players in the level, but then it goes back to being bad when there's a lot more players in the level. I recall Stefan making a post in a particular thread about the removal of UDP in V6 that he could implement the UDP protocol, but in a way which is still only sending data to the server and not each player. This wouldn't be quite as good as what we're used to among those who use UDP on PC Graal, but it would be a partial improvement for every player. Maybe it's already implemented on iPhone? |
Not sure, movement on iClassic is relatively skippy and laggy. There are moments where everyone on the server experiences halfa second where people don't move then suddenly move, aka jump. It's not just me either, and my connection is quite good so it's not a bad connection or something like that.
Just wish it could be improved. ): |
To make things clearer, there are two variables here:
Protocol - TCP vs UDP Routing - Client-Client vs Client-Server-Client The UDP setting in the Graal settings changes both variables:
In summary, the UDP setting in Graal changes two things: the protocol, and the path the data takes to get to other clients. Now, to analyze both of these variables a little... TCP vs UDP TCP is a protocol that has a lot of machinery to protect against temporary issues in between the two endpoints that are talking to each other. In other words, if there is a packet loss issue, TCP will try to resend the packets so no data is lost. TCP is particularly good if you're, for example, downloading a large file. You don't want packet loss to corrupt your file. UDP on the other hand has none of this protection. In gaming, this is sometimes better, since you can write your own "data-protection" protocol which suits your purposes better. But this usually involves some extra work, since just doing raw UDP isn't the greatest idea on a lossy link. Client-Client vs Client-Server-Client This is a really tricky question. Client-Server-Client data transfer is probably the "fairest" solution, and it's how I would do it. Client-Client data transfer has the potential to be much more "lagless" if you're near each other in the real world, but also has the potential to be much worse. If there are more than 2 people in the level, it gets a hella lot more confusing, since every person will have a direct connection to one-another, and everyone will be seeing their own picture of what's going on in the level. There is also the question of security in Client-Client connections, because there is no 3rd-party which can monitor what's going on. Overall, I would personally do it like this: UDP Client-Server-Client. Doing Client-Client is a beehive of confusing lag for some players, terrible lag for some players, and security issues. |
Whatever it is, it would be nice for iClassic to not have its mini lag-bursts. :[
|
Quote:
When a packet is either received out of order or is lost entirely on TCP, the stream will stall out until said packet is resent by the server or the order can be restored. Those are the lag bursts that you're seeing. There's also a lot of prediction magic that Graal could be using to reduce visible lag quite a bit, but nobody's gone so far as to implement any of it. |
Quote:
|
Quote:
Good sparrers already essentially extrapolate (guess) a player's new position in their heads if that person is lagging (especially on Era) and move or attack to try to hit them there. |
Other than rendering players at a position even further away in comparison to where they see themself, it would also cause some confusion due to the fact that players alternate their style according to how skippy other players appear to me. If a player appears to move smoothly you're more inclined to believe you should slash closer to the position inwhich you see them, even though the opposite would be more true.
|
Quote:
Quote:
This is all a lot of work, though, and personally, I wouldn't do it just because Graal is Graal and it's not exactly competitive anyway. |
Quote:
|
Using UDP would be too complex because a lot of people cannot use it and on some platforms (Facebook) it's not available. But we can check if we can improve the performance, may be sometimes the Graal server needs to handle bursts of data, so it could prioritize some.
|
Quote:
|
Quote:
Big advantage to using UDP is that you can send player positions as unreliable, which would improve the experience by a ridiculous amount. You could also write a decent NAT punchthrough method for you to provide peer-to-peer UDP that actually works reliably across clients rather than forcing users to adhere to certain ports in the settings. |
Quote:
|
All times are GMT +2. The time now is 04:32 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.