It's too bad we won't see any playable twitch games in the browser until there is some way to do UDP. I don't see why browsers don't just allow UDP subject to same origin policy, perhaps only on pages which serve a special "X-Allow-UDP" header.
From what I understand, the only reason browsers shy away from being able to send UDP packets is fear of DDOS. This does not seem to be an issue if packets are only sent to same host that the page is served from.
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.
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.
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?
TCP is ok, but it has a lot of flaws with handshaking and long lag, and also is useless for things like gaming because it can't go through NAT (NAT itself is a disaster too). TCP has created an internet of second class citizens who can only download but can't upload. The worst thing is, IPv6 will repeat all the same mistakes, so I think of it as second class citizen 2.0.
If it were up to me, I would scrap the whole thing, especially the needlessly large UDP and TCP headers, and make a simpler scheme that only contains the destination IP address and maybe a small key that references metadata held in each endpoint's internal state. So the TCP protocol would only exist in each endpoint's TCP stack, not on the wire.
I don't really have any sources, but I lost two years of my life trying to write a windowed reliable transmission scheme over UDP that can punch through firewalls, basically what WebRTC is trying to do, and got thoroughly disillusioned with networking. It just never, ever, ever works 100% reliably, so you end up recreating the work that Skype did if you want a connection as reliable as TCP. I think that says a lot about the miserable state of networking today. I might get down voted for this, but I feel that what I've said is a statement of fact if you look at the hoops that P2P protocols have to go through today. That mess was never the intention of the original network architects (except for admins maintaining corporate firewalls who want their users to be second class citizens, who sadly had a hand in the NAT used in home broadband modems).
Would you consider adding on screen controls for tablet users? I'd guess this kind of thing is a better fit for mobile than desktop, but is unusable as is under Android Chrome.
I just went on and played against someone called G...Maybe from HN? Anyway, fun game, pretty slick. I'm loving the stuff people are doing with HTML5. Well done!
This is a great little game. Just played a few rounds and had a blast but hit some nasty lag a few times. The basic game play is quite addictive. Nice job.
Thanks for the kind words and helpful feedback everyone! We appreciate it!
If you're still having trouble with Chrome or Firefox, please reply below with your browser and version, and possibly with a gist/pastebin of any console errors. Mark and I will get on it.
Regarding the lag: We match you with players based on your latency to each gameserver and the amount of time you've been waiting. If you experienced a lot of lag earlier, it might have been due to there being too few players online. However, 196 people are playing as I type this now, and hopefully there's now enough player density so you'll get matched with a lower-latency player who's nearby.
wow thank you for this. haven't thought about bomberman in years and within 5 seconds i was having a great time.
lag issues ("waiting for other players") and passer-throughs are making it a bit difficult to get a game going though.
edit: this has a few crippling bugs. seems like i have the most trouble after someone leaves a game. also, this desperately needs chat, or voice chat, and a high score. thanks again this is the most fun i've had in a while.
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.
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 :)
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.
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 visited the site using Firefox Nightly and it said: "Powderkeg can't run on your browser. Would you mind coming back with either Google Chrome or Firefox?".
72 comments
[ 3.7 ms ] story [ 171 ms ] threadIf you mouseover the tiny, hard-to-see lag meter in your colored square while playing a game you'll be able to see some stats about your connection.
The creators have a blog entry about latency and websockets. With even a minimal amount of packetloss, TCP makes for really bad latency - http://blog.artillery.com/2012/06/websocket-performance.html
It's too bad we won't see any playable twitch games in the browser until there is some way to do UDP. I don't see why browsers don't just allow UDP subject to same origin policy, perhaps only on pages which serve a special "X-Allow-UDP" header.
From what I understand, the only reason browsers shy away from being able to send UDP packets is fear of DDOS. This does not seem to be an issue if packets are only sent to same host that the page is served from.
(found on http://blog.artillery.com/2012/07/six-impossible-problems.ht...)
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.
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.
If it were up to me, I would scrap the whole thing, especially the needlessly large UDP and TCP headers, and make a simpler scheme that only contains the destination IP address and maybe a small key that references metadata held in each endpoint's internal state. So the TCP protocol would only exist in each endpoint's TCP stack, not on the wire.
I don't really have any sources, but I lost two years of my life trying to write a windowed reliable transmission scheme over UDP that can punch through firewalls, basically what WebRTC is trying to do, and got thoroughly disillusioned with networking. It just never, ever, ever works 100% reliably, so you end up recreating the work that Skype did if you want a connection as reliable as TCP. I think that says a lot about the miserable state of networking today. I might get down voted for this, but I feel that what I've said is a statement of fact if you look at the hoops that P2P protocols have to go through today. That mess was never the intention of the original network architects (except for admins maintaining corporate firewalls who want their users to be second class citizens, who sadly had a hand in the NAT used in home broadband modems).
Good luck
That said, after the first game it was very laggy.
If you're still having trouble with Chrome or Firefox, please reply below with your browser and version, and possibly with a gist/pastebin of any console errors. Mark and I will get on it.
Regarding the lag: We match you with players based on your latency to each gameserver and the amount of time you've been waiting. If you experienced a lot of lag earlier, it might have been due to there being too few players online. However, 196 people are playing as I type this now, and hopefully there's now enough player density so you'll get matched with a lower-latency player who's nearby.
You can read more on our blog post: http://blog.artillery.com/2012/10/play-powderkeg-html5-multi...
We're also on VentureBeat today: http://venturebeat.com/2012/10/04/artillery-aims-to-make-web...
Also, I'd like to thank our amazing artist, Adam deGrandis. Check out his portfolio — he's incredible: http://www.adamdegrandis.com/portfolio/
<3
lag issues ("waiting for other players") and passer-throughs are making it a bit difficult to get a game going though.
edit: this has a few crippling bugs. seems like i have the most trouble after someone leaves a game. also, this desperately needs chat, or voice chat, and a high score. thanks again this is the most fun i've had in a while.
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-for-game-programmers/wha...
Oh, and here's one implementing it with Node / HTML5: http://buildnewgames.com/real-time-multiplayer/
Good luck.
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.
How come you decided to send input rather than state to the client?
EDIT: Ah cool I see it's explained in your post: http://blog.artillery.com/2012/10/play-powderkeg-html5-multi...
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.
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.
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!
Kidding aside, I'll take a look. What OS?