Known facts about game internals
Physics tick distribution
How does the game distribute physics updates across frames?
AccumTime += DeltaTime; while (AccumTime >= PhysicsFixedDeltaTime) AccumTime -= PhysicsFixedDeltaTime RunPhysics(PhysicsFixedDeltaTime)
To avoid downward spiral the game won't run more than 5 physics frames per render frame, anything below 24 fps is going to start running physics slower.
Forces server to send out a packet if somebody does a jump, dodge, or double-jump when near the ball.
ForceNetUpdate()forces actor to be replicated next time replication runs.
ForceNetUpdate()and forces replication to run. The stuff for forcing packets is to ensure important events get sent ASAP even if the player has their Server Send Rate set to medium or low. Doesn't really do anything if Server Send Rate is set to default (High)
ReplicatedRBState.Timeis not physics time, it's world (render) time. It's used to keep track of the last time the physics state was replicated.
To help some of us better understand what is the significance of the the red box? And what does it mean when it's closer or further away from the car? From my understanding the red box signifies where the server has your car placed and green is where your client has your car placed? Is there anything specific we should be looking out for there?
Packet loss is measuring a loss of packets/sec, but what really matters is how many packets in a row are being lost. You could have 50% packet loss but if it's just every other packet you probably wouldn't even notice, but if it's half a second straight of all packets lost followed by half a second of all packets going through, that's very noticeable. It's a threshold, needs tweaking.
Client send rate: limits how many packets per second the client uploads to the server. Normally client sends 60 packets/sec and each packet contains 2 frames of input (because 120hz physics). Lowering the client send rate sends fewer packets but puts more inputs on each packet. The goal was to see if people's routers or ISPs don't like being hit with 60 packets/sec.
Server send rate: server normally replicates data to clients at 60 packets/sec. Basically it tries to put as much information about the game onto a packet until that packet is full or there's no more new information, then it sends that packet. Lowering the rate causes the server to send fewer packets per second, but each packet has more data.
Bandwidth limit: will restrict how much data the server puts onto a single packet.
For context, most competitive games only have the server send 10 packets/sec.
We don't use any of our own threads no.
UE has some I/O threads.
WinInet probably has a thread handled by windows.
Scaleform doesn't have a thread. It ticks on the game thread and renders on the render thread.
Rendering is done on a thread.
Wwise handles its own thread.
I think there's some random thread to keep the windows screen saver from activating.
Steering and accel forces are calculated after physics moves the car, hence them not having affect until the next frame. Been like that since game launch and doesn't change from game to game.
The hitching you get when a match is found is expected, that's when it starts loading products for the other players in the upcoming match.
People on steam: you can add
-StatUnitto your launch options to show ghetto perf graphs. It's just perf, not net yet.
- Game is game thread time
- Render is render thread time (CPU sending instructions to GPU)
- Frame is how long the entire frame took (with Game, Render, and GPU all working at the same time)
Another shot in the dark thing, can you all try adding
-USECURLto Steam launch options? Tells game to use the cURL HTTP library instead of WinInet.
It IS Rocket Science! The Physics of Rocket League Detailed - GDC talk detailing the game's physics and netcode architecture
Reddit comment revealing that Jared does not know why inputs are sometimes dropped during goal explosions, with multiple replies from people experiencing the same thing at low pings.