← Back to board

change visuals of ping buffering system

Openr0hkxr0hkx20 messagesstarted May 23, 2026, 11:52 PM
gameplay
r0hkxr0hkxOPlast week
currently the ping compensation system means that when you complete an objective, there is a slight lag before it registers on the server. the ping sound plays, but the chat message is grayed out and the board doesn't update. after a short delay, the chat message turns green and the board updates

in the rare case where two players do get an objective within this ping adjustment window, instead of the chat message turning green, the losing player's chat message changes to say the opponent completed the objective (and changes the color to red), and also appends "(adjusted for ping)"

imo, the current system doesn't feel great. completing objectives feels kinda laggy, the chat feels flickery, and it doesn't make rollbacks feel meaningfully better

my suggestion is simple: do not visually buffer anything. instantly make completed objectives appear completed in chat and on the board. the vast majority of objective completions aren't "adjusted for ping", so this standard situation should look and feel as good as possible, even if that comes at the cost of making it feel slightly worse when there is rollback

the chat/board lagging can be good because it does give you a feel for your ping, and also makes it obvious if you have connection issues, or just what the margin is. i think a better way to communicate that would be a very small icon that appears under the board when an objective completion hasn't been confirmed on the server

to clarify, having a ping rollback system is great, and im not complaining or suggesting any changes to the core functionality of it at all

Example of current objective "rollback":
https://www.twitch.tv/videos/2778987113?t=7h43m44s
feinberg went live on Twitch. Catch up on their Minecraft VOD now.
5
Bompkin
Bompkinlast week(edited)
I kinda like how it works right now but the ding should should be made when its confirmed, the suspense is nice and if its rolled back then only the goal loss sound should be played instead of both the ding and then the goal loss
1
r0hkx
r0hkxOPlast week(edited)
imo the ding has to occur when you complete the objective on the client side, since that's what you react to to stop doing something in a lot of cases
2
r0hkx
r0hkxOPlast week
like if you're looking at a ghast with a spyglass, you only stop looking at it when you hear the ding
r0hkx
r0hkxOPlast week
if that ding was ping dependent it would make the game feel significantly worse, especially for higher ping players
r0hkx
r0hkxOPlast week
i assume this is the reason it works like it does currently
marin
marinlast week
yes that's why it pings immediately, feels way more responsive
marin
marinlast week
i agree thats its not perfect yet
marin
marinlast week
adding it to board would make sense, indifferent about chat, gray message kinda makes sense to me
Bompkin
Bompkinlast week
actually ur prob right about that
Bompkin
Bompkinlast week
I like how it works right now then though
r0hkx
r0hkxOPlast week
why do you think you would prefer the current system to my proposed system?
r0hkx
r0hkxOPlast week
i don't really see the drawbacks at all
Bompkin
Bompkinlast week
I like the suspense of it turns green or red on close goals and also wouldn't want a goal ripped from me if it was green and pinged for already rather than just client side completed
Bompkin
Bompkinlast week(edited)
doesn't change much and it seems better than your suggestion but either works
r0hkx
r0hkxOPlast week
the obvious noise of the rollback is just the noise of the opponent completing the objective, and i think it should still replace the chat message when there is a rollback and include the "adjusted for ping" so it would be obvious that it is a rollback
r0hkx
r0hkxOPlast week
an additional rollback sound would be good as well though
r0hkx
r0hkxOPlast week
i guess i just feel as if the current system makes it already feel as if objectives are ripped away, since the ding sound still plays instantly. if ping wasn't an issue at all, i do agree that the sound should wait and the suspence would be good, but in practice i think it makes more sense here to optimize the most common case