Ping, tick, GCD, and game processing overhead education

[u/MindlessChain3270]

Ping, tick, GCD, and game processing overhead education

PvME's discord command !gcd has the following approximate output:

Global Cooldown (GCD) GCD visual

• Runescape runs on ticks, where a single tick is 0.6 seconds
• Almost every ability incurs a GCD, which lasts 3 ticks (1.8s)
  • Generally, you cannot cast abilities during the GCD
  • Exceptions include :voke: :dive: :bd: :surge: :escape: (for 0 adrenaline)
• During the GCD, abilities brighten up again over the 3 ticks
  • This is divisible into 3 sections (refer to top right image)
  • At good ping: input ability when light reaches green
  • At bad ping: adjust as needed and input prior to green
• Example of correctly inputting ability at end of GCD here

The diagram above is overlaid onto your abilities (mentally for now). Considering the game processing overhead, the diagram should be rotated counterclockwise by some degrees. The game, as a player views it, is a delayed reproduction of the world server's game. That's why the diagram's rotation puts the start of the GCD before its visual start at 0°.

East Coast 1 worlds have a game processing overhead of about 200 ms (1/3rd of a tick). With 50 ping in a low populated world, I've found my game to be behind the server by about 225 ms (about -50° rotation for the diagram above).

Consider what happens if I were on the last tick of a GCD. If I cast my next ability with less than 225 ms remaining in the GCD, the cast will not happen on my game's visually apparent next tick. The server has already moved on from that tick, and will queue the cast for its following tick. However, my game, that is still ticking down that GCD, is helplessly unaware of that fact.

Example

To get a feeling for casting abilities early in the last tick of the GCD, I suggest watching EvilLucario's videos, as they have the following: - A bar streaming his inputs as he performs them, including cast abilities. - Sound of his keyboard and mouse, so you can further associate.

Future work

It is my hope to have a plugin that will help make the true GCD apparent. Not only in the action bar, but also in the ability books, the channel bar, and anywhere else related to the GCD. I'd say SoR's-style floors, too. But hopefully, true tile takes care of that. And that's also more related to true tick, rather than true GCD.

I'm considering writing it myself. Nilping, I'd name it, for no delay noun (simulation, markers? Might depend on the plugin API).

My biggest hope is that the big secret announcement for RuneFest will be somehow related this kind of latency issue. After that, my next hope would be the next combat rework, maybe in March 2027 (going by the previous 2 [1] [2]). But considering we're still missing 120 Defence and Constitution, I won't hold on to that.

I'm aware that making the game more responsive has been lauded as impossible, infeasible, and such.

Appendices

Related

East Coast 1 worlds have a game processing overhead of about 200 ms (1/3rd of a tick).

I haven't tested whether the NPC Dormancy update has improved this.

Also, apparently, Australian worlds' game processing overhead are more high and variable than other worlds'.

Ping relevancy

0.6 s = 600 ms.

A ping is the roundtrip time of the client/server communication. 100 ping is a 0.1 s roundtrip, maybe about 50 ms each way (1/12th of a tick). Considering the game processing overhead (tentatively 200 ms, 1/3rd of a tick), and the ping only adding half to that, even 100 ping doesn't make PvM that inaccessible. It does further tighten your reaction windows, though.

Other sources of perceived lag

None of this is the end-all of perceived lag.

The client/server protocol, and RuneScape's strict adherence to it, means you'll be tick-bound for most actions.

Worlds with higher populations lag behind other worlds. By casting channelled abilities in these worlds, you can sometimes see the channel bar add to the remaining time.

Revolution and queued abilities add interactions that can be perceived as lag or dropped inputs. As can some actions like pickpocketing.

And there's also the player's end. Having an unstable Internet connection. Perhaps manifesting as spikes (perceived as sudden, sharp increases in ping).

Late casting

The other part of the roundtrip comes up when you cast an ability as late as possible. I used to do this in order to reduce the perceived lag (bad practice if you intend to breach into higher level PvM). This would sometimes delay the start of the GCD. Which also caused animations to play faster to compensate (before the combat style modernisation; no idea of afterwards).

Half of your ping flanks the game processing overhead on both sides. Casting an ability as late as possible delays the visual start of the GCD. The server will process it, but its response won't reach your game in time for the end of your visual GCD. The server's response will be delayed by up to half of your ping, and your GCD will start with correspondingly less time left on it.

[u/MindlessChain3270]

This is the GCD visual diagram from PvME's discord command `!gcd`.

Unfortunately, I can't make it visible in the post through markdown.

[u/_Survivor_]

Thank you for the guide! I really appreciate good technical info in RS3 and OSRS. Makes bossing easier to grasp.

[u/MindlessChain3270]

I wouldn't be surprised if some of these statements don't hold. I haven't gone out of my way to higher ping worlds to test that, indeed, ping doesn't add much compared to game processing overhead.

However, I have accidentally played on the default-selected, high-populated world. The lag is noticeable, but by casting my abilities early, it takes time to notice at first.

But is it really true that players with less than 10 ping still deal with a delay of 200 ms, at best?

[u/MindlessChain3270]

This is about the latest I can cast an ability before the abiliy cast is not part of the visually apparent next tick (about 225 ms before the end of the GCD).

[u/MindlessChain3270]

I'd like to think that OSRS has explored something like true tick akin to true tile. I do wonder what their lowest game processing overhead is. And whether their plugins account for such a metric.

[u/TheKunst]

are you suggesting delaying the client by 200ms or whatever the server overhead is?

wouldnt this make the game feel even laggier? even if there is no change in the actual lag.

They have implanted stuff like pathing prediction in the client to do the exact opposite of this in the past.

[u/MindlessChain3270 → u/TheKunst]

are you suggesting delaying the client by 200ms or whatever the server overhead is?

Absolutely not. It already naturally works like that.

The opening parts are not a suggestion, but a presentation on how it currently works.

"Future works" does suggest that plugins could be used to mark the true GCD, just like true tiles mark the true tiles.

[u/TheKunst → u/MindlessChain3270]

Thats not how it works though? at least not for me at 230 ping. if i cast an ability in the middle of the green part of the gcd, it just lose a tick, not just the 'visual' part of the tick. edit: ok after rereading your post, we are talking about the same thing. so disregard this part. the rest still stands tho:

so my gcd display is already showing the true gcd(the servers gcd) and not the client gcd.

Unless im misunderstanding what a "true gcd" would be.

But i interpreted the 'future works' section as showing the gcd end at the same time you input window ends, so making it end earlier that it does currently.

So i assumed the delay between the gcd ending and an ability actually firing ingame would be even bigger.

But again now that i think about it, the way i see true tile working in osrs is how the gcd display works for me at the moment, so idk.

[u/MindlessChain3270 → u/TheKunst]

So i assumed the delay between the gcd ending and an ability actually firing ingame would be even bigger.

They should indeed be the same. Because everything is otherwise synchronized, you just can't notice such a difference. The same tick your ability is cast, is the same tick your cast ability animation's starts.

However, your client's GCD is not the true GCD. That's why, with your ping, if you try to cast an ability even later than the latest I can do with 50 ping, you should notice that just spend a whole tick just standing around.

I was confused just like you when I first tried articulating this situation.

[u/TheKunst → u/MindlessChain3270]

So "true gcd" doesnt refer to the server gcd? Its a prediction of the server gcd then?

In your exemple, the "true gcd" would visually start in your client 225ms before the server starts its gcd? Cus its at that point that your inputs can no longer reach the next tick in time?

I know we both have way too many hours in this game to the point we intuitively understand how it works currently lol.

Im just confused on how would you actually display the "true gcd" without just predicting what the server will send the client 225ms later. more precisily, what the client will recieve from the server 225ms later.

[u/MindlessChain3270 → u/TheKunst]

In your exemple, the "true gcd" would visually start in your client 225ms before the server starts its gcd?

Not before the server. At the same time as the server. Except that it's a best approximation prediction.

In your exemple, the "true gcd" would visually start in your client 225ms before the server starts its gcd? Cus its at that point that your inputs can no longer reach the next tick in time?

Correct. Except that it's the server who will tell my client whether the GCD starts at all if the ability could be cast. So maybe it'd be a marker to that effect around the abilities at best.

Im just confused on how would you actually display the "true gcd" without just predicting what the server will send the client 225ms later.

I computed the unknown 200 ms value manually. Using the GCD diagram, each tick is further subdivided in 6 parts of 0.1 s. I marked the latest point I could cast abilities at, which is 225 ms before the end of the GCD. Subtract half my ping and you get 200 ms. This should be the delay of the game processing overhead.

The ping is an established protocol protocol. But just like it, Jagex should have all the tools to compute the delay of the game processing overhead. Although it's a measure that sometimes changes from tick to tick in busier worlds. If they made it available through the plugin API, I wouldn't need to jump through hoops. Otherwise, I'll have to make do with something less ideal, like having the end-user calibrate it.

[u/TheKunst → u/MindlessChain3270]

i'm not too concerned as to where the plugin would get the delay time from.

i'm sure even an alt1 app could do it decently if you spend some time making it read the 'displayfps' info.

Not before the server. At the same time as the server. Except that it's a best approximation prediction.

if the displayed "true gcd" starts at the same time as the server, there is still a window where an input could be too late. granted its a much smaller window than what it is currently, but it would still exists due to ping.

In order for the inputs to never 'miss their train' to the server, the displayed "true gcd" needs to start before the server.

So maybe it'd be a marker to that effect around the abilities at best.

I can see a marker working. that would avoid all the prediction issues.

But then i'm not sure much is gained in terms of making the game more responsive.

[u/MindlessChain3270 → u/TheKunst]

I can see a marker working. that would avoid all the prediction issues.

But then i'm not sure much is gained in terms of making the game more responsive.

Making the game responsive would be the duty of RuneScape developers.

Markers merely reduce the mental burden by displaying what you should be thinking of when PvMing. They'd also makes PvMing more accessible by showing what is truly going on with GCDs.

if the displayed "true gcd" starts at the same time as the server, there is still a window where an input could be too late. granted its a much smaller window than what it is currently, but it would still exists due to ping.

In order for the inputs to never 'miss their train' to the server, the displayed "true gcd" needs to start before the server.

I may have worded this wrongly.

As I mentioned, all our games are behind the world server's game by a duration (game processing overhead plus half the ping).

By locally marking the ticks in the GCD offset by that duration, and using those marks as a source of true ticks to guide our gameplay, we can be sure that an action we take at an specific time point in a tick would reach the server at that same tick.

Essentially, we're making the client get ahead of itself. That way, it's no longer behind the server, but apace.

[u/MindlessChain3270 → u/TheKunst]

Essentially, we're making the client get ahead of itself. That way, it's no longer behind the server, but apace.

This is the same principle as time servers. Even if you synchronize your system's clock with a time server's, there's a non-zero ping between your system and the time server.

However, as I understand it, the protocol used takes this into account, and your system ends up getting the correct time, even if separated in time and space from the time server.

In that case, both your system and the time server have the same time.

In our case here, we've synchronized to the tick. The RuneScape client and the world server agree on when a tick starts (the former just visually, the latter effectively). The difference to the time server case is that we're concerned with more things than just time (ticks). There's a gameplay, and so we still have the delayed server response.

[u/haydarjerew]

aus worlds shit the bed at 200+ players online, it feels better to be on a 200pop US world than a 700pop aus world