Hey guys, HalfwayDead here.
There are already 2 great videos on the topic of Rocket League's Netcode, one of them being
by Psyonix_Cone himself.
I highly recommend watching both.
But because I know a lot of people ignore these recommendations, I'm going to cover
the basics in this video too, even though it's just a repetition.
Let's start with the reason we need a netcode.
Delay.
When everything is running on your own computer the physics and inputs can all be used pretty
much immediately to determine the physics outcome.
Unfortunately, when playing online the data needs to travel in between all participating
players.
The upper limit for how fast information can travel is the speed of light.
Berlin and Washington are 6700 km or 4200 miles apart.
It takes light 22.4 ms to travel that distance one way, and 44.8 ms if you include the way
back.
In real world scenarios, the ping is going to be much higher tham 45ms, but the point
I'm trying to make is that there are physical limitations that make it impossible to not
have delay.
Delay always creates a problem.
Let's say player A jumps.
However, this information arrives at player B's computer 50ms later.
In that time player B has already demoed player A. Yet from player A's perspective he has
sucessfully avoided the demo having jumped 100ms ahead of where player B is.
So how do we deal with this problem?
First of all, we need an unbiased entity.
The server.
It's not going to be able to get rid of the delay altogether, however, it is vital to
making online games fair.
The state of the server physics always gets treated as the true state of the game.
If the server determines that player A was indeed demoed, then that might still frustrate
them, but it will ensure that each player has the same opportunity and player B has
equal edge cases, assuming both players have the same ping to the server.
Always preferring the person jumping or demoing would just create even more ridculous looking
edge cases.
Alright, with the server in place and having established that some delays are unpreventable,
what can the game actually do against lag?
The key concept is prediction.
Take the ball as the easiest example.
If we have 100 ping, which means it takes 100 ms for data to travel to the server and
back then the ball location from the server will be arriving 50 ms late on our screen.
The ball would not actually be in the spot where we think it is, and since the server
is always considered the true state we could end up missing the ball because it has already
moved past us on the server.
It gets even worse though, our inputs also take 50 ms to get to the server, which means
that the difference of what you see on your screen and what the server sees would be off
by the full 100 ms.
Here is where the prediction netcode does it's magic.
Since the ball follows the deterministic physics, the game can actually calculate where the
ball will be 100 ms later than the data that came from the server.
That is enough time for our inputs to reach the server at the correct moment.
If you think about it, you're also predicting your own car because only the server determines
the true state.
This system actually works so well that you can play by yourself on a server with 340
ping and as long as the connection is stable, the car ball interactions will be the same
as playing offline.
Mathematically, this would even be true with 30 s of ping but no connection is 100% stable
and a higher ping makes each of those inconsistencies worse.
The real problems start when the game tries to predict other player's cars.
They still follow the principles of Rocket League's physics but there is no way to know
what the opponents input is going to be 100 ms ahead of when the actual data arrives.
But there are just best assumptions that can be made.
If they were doing nothing then it is assumed that they're still doing nothing.
If they were boosting then it is assumed that they're still boosting.
The same is true for accelerating, braking, turning, powersliding, jumping, as well as
pitch, yaw, and roll in the air.
The times where they will start or stop to boost, jump, and such are unknown and as a
result the timing of dodges is also unknown.
Whenever the prediction of the client is different from the server their states will be out of
sync, which is why this is called a desync.
Once the data from the server has arrived, however, the cars on your PC will be adjusted
to their correct location, speed, etc.
Here are a couple of examples with 340 ping: Boosting, which shows acceleration so fast
that it shouldn't be possible.
This happens because the client has to overcorrect once it know the player has already been boosting
for a third of a second.
Dodges, where it looks like the car is basically teleporting, due to the abrupt speed increase.
Earlier I said that the ball prediction works amazing, yet everyone can probably name a
lot of scenarios where they saw massive desyncs with the ball.
That is just because there are constant interactions with the ball.
If the cars touching the ball can't be predicted perfectly then the ball can't be either.
For example, with a ping of 100ms, if another players input causes a change in speed, location,
rotation, or angular velocity less than 100ms before they hit the ball then the ball will
first get predicted incorrectly until the update from the server arrives.
This becomes especially apparent in 50/50s where multiple players dodge into the ball.
The prediction can go wrong once for every player and every time the client gets an update
for a player dodge it will change the direction of where the ball seems to go.
Another horrible scenario happens when someone is on a collision course with the ball but
dodges at the last possible moment and ends up not hitting it.
Unfortunately, these kind of desyncs are again unavoidable based on how high your ping is.
I've often heard people complain about the server when this happens, and while it can
be the case that a poor server exaggerates this and makes it happen a lot throughout
the entire game, if it only happens once then it was probably an extreme example where you
just have to concede that playing games over the internet can never be perfect.
I haven't yet talked about specific parts of the game that don't get predicted, such
as scoring a goal.
If the goal explosion was predicted but on the server the ball was barely saved then
that would just create a worse scenario than the bit of delay that you usually have on
goal scoring.
If you're the player trying to save the goal, the current implementation can allow you to
seemingly save it after it is already a goal on the server which is frustrating but the
opposite would be worse.
Another aspect that doesn't get predicted is the ball hitting the floor to end the game.
Only when the server says that the game is actually over, will it stop on your screen.
By that time, the ball has usually bounced in the air again and possibly even into someones
net, but once again, the opposite would be worse.
The kickoff timer also doesn't get predicted but in this case I am not sure if that is
on purpose.
You can start boosting before the timer ends on your screen and the car will do so on the
server which means you can arrive at the same time to the ball but it will look like you
teleported the first couple of meters.
This is once again footage of terribly high ping but it still seems like an unnecessary
issue.
When you're driving over a boostpad, the client will also not predict whether you will get
the boost or not.
That is not optimal when you're the only one near the boostpad but if any other player
was close enough to steal it and your client predicted wrongly that would arguably be worse.
Unlike the kickoff, it's impossible to use the boost before the client gets the update
that it did indeed get the boost.
Let's talk about some of the technical details of the netcode.
So far I've only talked about data getting sent back and forth and not really about what
is getting sent and how often.
For your car, all the game does is send the inputs straight to the server.
It's not actually sending that you've pressed the X button on your controller.
It does so in an abstract manner.
Whether you have boost pressed, jump pressed, or what your current steer percentage is.
This approach makes it impossible for the player to teleport around the map or have
speedhacks.
The server does send the actual game state back however.
That is of course necessary in order for your computer to check if the prediction is still
correct, and adjust it if it isn't.
Each of these chunks of data are called a packet.
They are getting sent a regular rate between server and client to ensure that they stay
in sync.
Based on my testing, the amount of packet that you receive from the server is always
60 per second.
A bit more complicated is the send rate.
It seems pretty unstable, anywhere between 65-70.
At maximum, it sends 1 packet per frame though.
Which means if you cap your FPS to stable 65 or below then the packet send rate seems
to be more stable.
I couldn't find any benefits to that though.
For some reason, the client send rate and server send rate options as well as the bandwidth
limit in the menu do not seem to make a difference at all.
Shoutout to reddit user /u/Nextil who originally showed this to me.
I did retest everything myself, however.
If it gets fixed in a future update, I will report on it.
What different types of lag you can have?
My previous examples were mainly showing high latency, which is subpar to low latency, but
the other potential issues are usually the ones that make the game literally unplayable.
Server health.
Rocket League's support website says that this is a scenario where the server itself
is experiencing issues, like eating up too much memory.
In that case, the server might not be able to run the physics simulation in real time
anymore.
Everyone's computer still does though but since the server is considered the ground
truth, the state of everyone's game will get reset to the server state whenever it manages
to send out the next update.
That will cause those scenarios where you see and replay the same situation multiple
times but only the last one is actually the one that happened on the server.
It is important to know that server health does specifically not say anything about how
good the internet connection of the server is.
Usually it should be great because the servers are located in datacenters with the best data
connections you can have but if the server has packet loss then every player playing
on the server will get the packet loss icon and not the server health icon.
Which gets me to explain what packet loss is.
It could be that data sent from the server or the player never arrives at it's destination.
That is obviously terrible when playing a game.
If the client doesn't get an update from the server then it goes on, trying to predict
the game.
Any desyncs get worse, when you don't get an update for a while.
That doesn't even compare to the horrible experience is that you get when your inputs
get lost on the way to the server.
You could press your jump button but the server thinks you never jumped.
Turns feel sluggish.
You start warping around the field.
You have no control over your car.
To mitigate this issue, the game seems to send the inputs of the last 4 physics ticks.
That way, if you're playing at 60+FPS, you can have 1 out of 2 packets dropped without
an issue.
In reality, though, it's very common to drop 2-3 packets in a row when the connection is
bad.
Best of luck to you, if you do.
Latency variance or jitter is also a big issue.
The truth is that packets can always arrive a couple of milliseconds later than usual.
That is why the server and the client both have a small buffer.
They basically increase the latency on purpose so that when a packet does arrive a bit late
it's not a problem.
It's the lesser of two evils.
Because in a real-time application, if a packet arrives too late then that is basically the
equivalent of a packet not arriving at all.
The server doesn't have any use for a jump press that happened 1 second ago.
It is not going to rerun the simulation just because it has that information now.
Latency variance is basically all about choosing the right buffer size.
You don't want it too large because it's going to increase the average delay but you certainly
wouldn't want it too small because that gives a worse experience.
Unfortunately, the buffer on the server is the same for everyone, so if your variance
is too high for the set buffer then you're out of luck.
What can you do against these issues?
If it's the server, then you can look at the name and report that to the support team.
However, it is highly unlikely that the issue has anything to do with the server if not
everyone on the server experiences the issue.
I feel like I see people daily, blaming servers even when only one player's connection is
bad.
So if it's not the server, what can you do?
In general, you should avoid Wi-Fi at all cost because it is prone to packet loss and
variance.
If you already do that and you still have regular issues then talking to your ISP is
probably your best bet.
There is no guarantee they will do anything, but there is no one else that can do anything.
Tell them the exact issue that you're having and ask for instructions on what data they
need from you to fix the connection to the servers.
Lastly I want to quickly talk about the ping in the scoreboard.
It is only correct when using 60FPS.
If you get more frames, it shows a higher ping, and if you get less it shows a lower
ping.
If I lock my framerate at 15 it displays a ping of 0 ms which obviously can't be correct.
I imagine that their measurement includes some processing delay and they subtract a
frame of time which works out at 60FPS but does not hold true at any other framerate.
Shoutout to my patrons, who make it possible for me to spend this much time on creating
videos.
If you want to help me too, then you can do so at the link on screen.
In return you get to see some sneak peak information on future videos and a vote to prioritize
certain topics over others.
If you want to stay up to date about this channel, follow me on twitter or join my Discord
and I'll see you guys soon for the next video.
For more infomation >> Arrêtez de manger Ces compléments alimentaires (sérieusement), ils sont train de ruiner votre santé - Duration: 5:27. 
For more infomation >> #5 Hướng dẫn học nhảy Shuffle dance cơ bản | Shuffle Dance Sài Gòn - Duration: 1:07. 
For more infomation >> VLOG DANS LA CAMPAGNE JAPONAISE - Duration: 19:02. 
For more infomation >> Lần Đầu Chơi Game: Close Line - Game Mobile Cực Hay - Duration: 8:35. 
For more infomation >> DƯƠNG QUÁ ba lần cứu Vợ Chồng quách Tĩnh Hoàng Dung thoát chết khỏi người mông cổ | phim online - Duration: 14:10. 
For more infomation >> 4 Things you should not discuss on a first date - Duration: 2:58. 
For more infomation >> SpinTires Mudrunner - Xe tải Dongfeng đi lội bùn siêu yếu | ND Gaming - Duration: 22:08. 
For more infomation >> कुरडईची भाजी | Kurdai Bhaji | Marathi Recipe by Chef Madhura | Ep - 376 - Duration: 7:15. 
For more infomation >> 👗 Куклы ЛОЛ Моя утренняя рутина Мультики про куклы ЛОЛ Сюрприз Видео для детей Мультфильмы - Duration: 2:52. 
Không có nhận xét nào:
Đăng nhận xét