Hacker News Reader

Comment by statico | Hacker News Reader

All good links, thanks! We are in fact using client-side prediction and lag compensation. It's extremely difficult to make a perfectly-playable action game with 500ms ping — you'd be kicked off a Quake server with that kind of lag :)

Powderkeg uses lockstep network synchronization and every client sees the same simulation (though the player you control has prediction). The network framerate is 10 FPS and the server waits 2 ticks to collect input, so anyone with more than a 200ms ping to the gameserver will have a less-than-desirable experience.

View on HN

So with your lockstep I presume you're allowing the client to move instantly locally then syncing back with the server? As I'm getting some minor snapbacks (I probably have 200ms+ ping being in Australia) and usually lockstep (for RTS games anyway) doesn't have that and has input delay instead as the client waits for their moves to return from the server.

EDIT: Ah cool I see it's explained in your post: http://blog.artillery.com/2012/10/play-powderkeg-html5-multi...

Yep, the 'snapbacks' you're referring to are a product of the hinting and lag compensation. Right now the "tick lag" which controls this is 200ms — we could raise it to make gameplay smoother but then the snapbacks would be even more egregious.

I'm playing from Aus, and yeah there are slight snapbacks but it's completely playable (and quite fun).

Aus here. Too much lag on movement for me to be playable.

Is there any way to display ping?

Also perhaps the servers are a bit overloaded? Cause I'm playing from Palo Alto on a decent connection and the lag is making it pretty unplayable.

You can mouseover the tiny lag meter in your info square while playing to see ping stats.

Your connection might be fine, but you might be matched with someone on a less-than-optimal connection.

> Your connection might be fine, but you might be matched with someone on a less-than-optimal connection.

Ahh, the unsolvable problem of lock-step back in action.

Suboptimal, not unsolvable. There are a handful of ways we can — and, after today's feedback, will — improve the experience.

Apologies! I just read your blog post, and it seems like you're way ahead of me.

How come you decided to send input rather than state to the client?

There's no need to send state if every client runs the same simulation. All you need to do is send every client a frame's worth of input and the frame's number. The gafferongames.com article you posted explains more about it :)

Reply on news.ycombinator.com