Took a look at your code and noticed you're using Socket.io. Don't use Socket.io for anything over double digit concurrent users. It's well known to be horrible at scaling. If you want something that's better at scaling I'd suggest SockJS[1].
The "over double digit" claim is simply not true. I'm running three multiplayer games for about two years now, and it starts to have problems once if goes over 3500 concurrent connections. It could be that I just hit the right combination of node+socketio versions, though, as I had problems with newer ones. My setup is:
node.js 0.6
socket.io 0.9.6
This version of socket.io has a nasty bug in jsonp protocol handling which I patched manually by merging some change from a newer version, but it does work fine.
To make it scale, I run multiple node processes. In the last 300+ days each of those has between 1000 and 2000 concurrent connections all the time and it works fine. Except that there is some memory leak (I'm not sure if it's related to socket.io or some other lib), so I restart each server once a week (it's done automatically each Sunday at 2am).
I had my eye on SockJS since 2012, and it looks like newer versions are really good, but I'd need upgrade to newer nodejs and this is simply not possible for the existing projects as many used modules are not available.
However, if you're starting a new project, it's worth testing and see which performs better.
Interesting, but I'm not using Redis nor MemoryStore. I gave each machine behind HAProxy a different hostname (mapped to the same IP address), and I route the clients in roundrobin fashion to each of those before they open the page with socket.io javascript. It works like this:
- client opens a page on HAProxy load-balancer picked server
- the actual node server that receives the request, redirects the browser to its custom hostname using the same URI
- client opens the same page on the particular server and socket.io connects to that subdomain
This ensures that all future requests (if socket.io connection is broken) will go to the same server without Redis, MemoryStore, cookies or whatever.
Drawbacks:
- one additional HTTP redirect when page that contains socket.io is loaded (luckly, in games there aren't many of those)
- if you want to retire some sub-domain hostname, you have to be careful to allow existing clients to re-connect somewhere else. Not really a problem for my setup, but YMMV.
You said you don't use Redis/MemoryStore, but when you broadcast something it has to be saved somewhere until all of the polling sessions get it. Where is it being saved?
There's a memory leak that only got fixed in 0.10.22 I believe. Erin Hammer and the whole Node Black Friday team really publicized it when it was biting them[1]. I'm not sure if the leak was present in 0.6 and given that you rely on older modules the cost/benefit of switching is probably too high.
You're the first person I've heard that was able to run vanilla Socket.io at such scale. I know Trello and some other shops use Socket.io, but they've forked & changed it to something that looks nothing like the original[2].
"Under the hood SockJS tries to use native WebSockets first. If that fails it can use a variety of browser-specific transport protocols and presents them through WebSocket-like abstractions." - SockJS
How this is helping?
"Flash is absolutely not required for Socket.IO to function. If Flash is available, it'll be leveraged, as it provides almost the same capabilities as WebSocket. If it's not, the next best transport will be chosen." - Socket.io
i'd suggest https://github.com/primus/primus. it's an abstraction layer for real-time so no lock-in to a single socket implementation. it's simple and extensible by plugins.
I literally was going to do this this coming weekend, same name even!
I was going to take a much different approach however - I was going to use rabbitmq speaking STOMP over a websocket [0] with two queues, one for client moves, which the server would consume and write to the moves queue, which each client would consume. This would allow the server to do more fancy rate limiting / throttling as not to just lead to a message storm. This, along with storing the game state in a db, allows for scaling out app servers.
Kind of fun, but I agree with some of the other comments that it would be interesting to see what would happen if the app made a move every 15-20 seconds based on the vote tally in that time window.
tl;dr: anarchy produces all the fun crazy ridiculous happenings, it's what makes TPP fun. If it's "taking too long" and you want to beat the game quickly just play solo; beating the game fast isn't the point.
Users should only be able to vote once (maybe be allowed to change it, but right now someone can overrule the consensus by hitting an arrow key as many times as they can)
Some rate limiting has been put in place, but it's not good enough. If there are 50 users online at once, they all shouldn't be able to spam a command every second.
It's currently unplayable. Instead imagine if it would make one move every half a minute. During the time between moves anyone could vote on the next move. Then the winning move would be played. It would be a slow game, but would be the aggregate HN wisdom.
And we could name that mode democracy, but we could have a meta game where people vote on anarchy (current system) or democracy, as you describe. And there should be fan art.
Democracy mode is great! But a couple of players (and I) figured out that multiple key presses by a user are counted, so we have more of an oligarchy determined by whoever can spam keystrokes...
Democracy mode needs a chat to scream about the occasional horribly stupid moves voted (merge a mid-value pair that prevents a win because it blocks in a low value cell between the 256's)
This makes a perfect illustration why startups are shit. Instead of working on something useful, people either produce crappy javascript games, or play them. Now massively downvote this comment, write 100 replies explaining why I'm wrong and how retarded I am for trying to say something like this, then go read something by Paul Graham and play more clones of 1024. And then write a long essay why your startup failed.
Damn, this version seems so unplayable-- so much chaos.
When I play on my own, I already do so many random moves until I reach 512. After that every move that I make is evaluated. I have no problems reaching 2048 (or 29,000 points) within 10-15 minutes.
Here, I just get frustrated with the slowness of the moves (not to mention the strategy of the "democratic group" is way off)
This is probably a bit much, but I'd love to see someone whip up a multiplayer 2048 using something like Firebase. It would probably start many an argument.
1 - https://github.com/sockjs/sockjs-node