Live data from Hacker News

Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

powderkeg.artillery.com

31–40 of 73 posts

Re: Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

#32

Your licenses page ( http://powderkeg.artillery.com/attribution.html ) is down and otherwise, there's no reference to Bomberman here at all. It's a well-executed game though. Haven't found any flaws, but I can't really say it's original. Good proof-of-concept for HTML5!

Whoops! Fixing that broken link now. Thanks!

Re: Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

#33
post #29
post #26

You might want to consider using client-side prediction and lag compensation. Here's John Carmack describing how he used the aforementioned techniques to make Quake playable over the internet: http://fabiensanglard.net/quakeSource/johnc-log.aug.htm Here's how Valve do it: https://developer.valvesoftware.com/wiki/Latency_Compensatin... And here's another good article on the topic: http://gafferongames.com/networking-f…

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 w…

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?

Re: Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

#35
post #33
post #29

Earlier quoted context omitted.

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 w…

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 :)

Re: Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

#36
post #25
post #23

Earlier quoted context omitted.

WebRTC allows for general UDP packets (in the spec at least - haven't tried it in Chrome stable) so hopefully this will be a workable solution as it gets more support.

"The Data Channel API is not implemented and its implementation is being discussed in the standards committee" http://www.webrtc.org/faq-recent-topics WebRTC is currently some weird wrapper around ICE and nat traversal protocols, not something that seems useful for sending generic javascript-land ArrayBuffers or similar.

Ya this appears to be the achilles heal of WebRTC and I was extremely disappointed (but not surprised) to hear that they chose to go this route of splitting data and media instead of layering media on top of data.

All I can think of is that there might be pressure from media companies and ISPs to block the media or data components.

This has happened before - we have UDP and TCP as independent protocols instead of having TCP built on UDP. This created the mess with firewalls and NAT that we have to live with today.

Re: Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

#37
post #25
post #23

Earlier quoted context omitted.

WebRTC allows for general UDP packets (in the spec at least - haven't tried it in Chrome stable) so hopefully this will be a workable solution as it gets more support.

"The Data Channel API is not implemented and its implementation is being discussed in the standards committee" http://www.webrtc.org/faq-recent-topics WebRTC is currently some weird wrapper around ICE and nat traversal protocols, not something that seems useful for sending generic javascript-land ArrayBuffers or similar.

[deleted]

Re: Show HN: Powderkeg, a realtime, synchronous, multiplayer HTML5 action game

#38
post #25

Earlier quoted context omitted.

"The Data Channel API is not implemented and its implementation is being discussed in the standards committee" http://www.webrtc.org/faq-recent-topics WebRTC is currently some weird wrapper around ICE and nat traversal protocols, not something that seems useful for sending generic javascript-land ArrayBuffers or similar.

Ya this appears to be the achilles heal of WebRTC and I was extremely disappointed (but not surprised) to hear that they chose to go this route of splitting data and media instead of layering media on top of data. All I can think of is that there might be pressure from media companies and ISPs to block the media or data components. This has happened before - we have UDP and TCP as independent protocols instead of hav…

uTP (micro transport protocol) is a TCP implementation based on UDP. Used by the majority of BitTorrent clients. It seems to work pretty well. It's interesting that you think TCP was a bad idea. Do you have any sources or reading material that you can share?
Post reply on HN