EDIT: I guess I'm not going to get anywhere near my max theoretical population of 560.
EDIT: Had to reboot the instance server. The WebRTC processes are holding up, though.
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
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!
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.
var wrtc = require('electron-webrtc')({ headless: true });
var SimplePeer = require('simple-peer');
var requestify = require('requestify');
var dgram = require('dgram');
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.
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.
I had the polarity reversed. It's actually client-server, server wins.