Smoother gameplay on iClassic through FB/iPhone?

[Crono]

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!

[ffcmike]

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?

[Crono]

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. ):

[WhiteDragon]

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:

• UDP disabled: Graal uses a TCP Client-Server-Client connection.
• UDP enabled: Graal uses a UDP Client-Client connection.

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.

[Crono]

Whatever it is, it would be nice for iClassic to not have its mini lag-bursts. :[

[Hezzy002]

Originally Posted by Crono

Whatever it is, it would be nice for iClassic to not have its mini lag-bursts. :[

Blame TCP. Like WD said, with UDP you can implement your own reliability layer, and select which packets should be handled as reliable or unreliable, and have different reliable streams with different packet priorities.

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.

[ffcmike]

Originally Posted by Hezzy002

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.

Could this have negative effects on fast paced combat such as traditional sword sparring?

[cbk1994]

Originally Posted by ffcmike

Could this have negative effects on fast paced combat such as traditional sword sparring?

Any time you're guessing where other players are going to be (extrapolation) or even showing players in slightly older positions (interpolation), you're changing where the player sees them and affecting the spar. Interpolation would be nice for most uses in Graal, but with spars, I'd prefer it to be off, especially since hit detection is done clientside by the victim player.

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.

[ffcmike]

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.

[Hezzy002]

Originally Posted by cbk1994

Any time you're guessing where other players are going to be (extrapolation) or even showing players in slightly older positions (interpolation), you're changing where the player sees them and affecting the spar. Interpolation would be nice for most uses in Graal, but with spars, I'd prefer it to be off, especially since hit detection is done clientside by the victim player.

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.

This is true, but I think one or two frames of extrapolation would do fine for everybody. Beyond those two frames, it might make sense to actually freeze both players until the connection is restored. Unfortunately, that's the only solution I can think of for sparring. It could be as short as one frame, but if it exceeds a certain threshold you could even cancel the match. Fighting games do it all the time, SFIV and UMvC3. They also cache positions and snap back in time a few frames if there's some kind of paradox (This is only true for fighting games that do any kind of prediction at all; SFIV and UMvC3 don't seem to do any prediction).

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.

Graal already trusts the victim client 100%, so there's no reason not to trust the attacking client. You could just as easily have either the server or player get the positions that were dropped and hit the player, even though on the victims client they skipped over the slice, but were visibly getting attacked on the attacker's client.

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.

[Crono]

Originally Posted by Hezzy002

I wouldn't do it just because Graal is Graal and it's not exactly competitive anyway.

That's a ridic thing to say considering there are hundreds of sparrers.

[Admins]

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.

[Crono]

Originally Posted by Stefan

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.

Yeah, my network knowledge isn't vast at all but I just know that UDP on normal Graal is very smooth. TCP itself isn't that big of a problem, but for some reason iClassic has short mini-lag bursts. Would be cool if that could be checked out.

[Hezzy002]

Originally Posted by Stefan

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.

You don't need to use UDP on a peer-to-peer basis. UDP is available on every computer for a server-client relationship. It wouldn't work on Flash, like you said, because only TCP is exposed, but it would work 100% on iOS, Android, PC, Linux, and Mac.

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.

[Crono]

Originally Posted by Hezzy002

You don't need to use UDP on a peer-to-peer basis. UDP is available on every computer for a server-client relationship. It wouldn't work on Flash, like you said, because only TCP is exposed, but it would work 100% on iOS, Android, PC, Linux, and Mac.

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.

Sadly I'm speaking from the flash FB perspective. This is why I wish iClassic was just available on v6 instead of FB for normal players. ;[