Hacker News Reader

Comment by crucio | Hacker News Reader

Are you using webrtc for client to server communication? or just for client to client? if the former, what library did you use on the server?

I've made lots of small browser games but haven't tried in the last few years. Websockets have never scaled well for the obvious reason that over bad connections data gets blocked up!

I don't understand what to do on your game, and the UI needs work. You're obviously very good at the physics/networking side of things, but maybe get some help on the UI :D I played for 10 seconds then had to close it

View on HN

There's an old school tutorial here:

https://secure.emergencevector.com/tutorial/

If you can't figure out how to make it into Hyperspace, you are officially a weakly interacting massive particle! :D

Everything is client-server, client wins, except for one thing. (Left as an exercise.) WebRTC is only there as a substitute for UDP.

Ahh nice, sounds like a good setup. Did you use an open source library for the server side part of WebRTC? I'm super interested in having a play with a good implementation if you have any tips..

I used some variation of node-electron. Here is the top of the node server file:

    var wrtc = require('electron-webrtc')({ headless: true });
    var SimplePeer = require('simple-peer');
    var requestify = require('requestify');
    var dgram = require('dgram');

The Go server uses UDP to talk to one of the 4 node server processes, which are running instances of Chromium under xvfb under tmux. There's a lot of code load overhead for the 4 processes, in terms of a lot of Chromium loaded but not running, but EC2 servers are RAM heavy, so not an issue.

I haven't looked into exploiting the new true headless mode in Chrome yet, which should simplify things a lot. I'm also thinking of doing a full port to Go for WebRTC. That's a lot of stuff, however.

Ahh interesting, thank you for that. That's an interesting point re headless mode in Chrome (and Firefox now I guess!). It's a shame there's not an easier way though yet..

> WebRTC is only there as a substitute for UDP.

I knew that this was possible in theory, but my experience with messing around with the available serverside WebRTC libraries gave off a similar first impression to the one you mention in your blog, namely immature libraries.

Looking forward to your blog post on your experiences with Datachannel.

Everything is client-server, client wins, except for one thing.

I had the polarity reversed. It's actually client-server, server wins.

I thought stuff like "1M concurrent connections" was easy this days? I'd love to understand more about your problems.

Sorry when I said scale, I mean.. scale to real world usage. Websockets run over TCP so if you're on a bad connection, packets have to be re-sent, meaning real time gaming becomes very very difficult to implement.

TCP/websockets are good for slower paced games like point and clicks but they don't normally work well for fasted paced games with physics.

WebRTC data channels don't have to re-send lost packets (unlike WebSockets), so if you do WebRTC between client and server it will unlock a new genre of games for the web!

Reply on news.ycombinator.com