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].
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.
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 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.
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)
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.
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.
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].
1 - https://github.com/sockjs/sockjs-node
I'll look into it. Thanks
Your app's down :(
Anything to backup your claim about Socket.io?
This epic issue: https://github.com/learnboost/socket.io/issues/438
Great podcast about using Websockets (including Socket.io) in Node: http://nodeup.com/fortytwo
This is a rather inaccurate statement to make. I've used Socket.io with double digit concurrent users before and Socket.io handled things fine.
You're not disagreeing with the parent. They said more than double-digit.
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.
Seconded. I ran a very popular website that used Socket.IO. It broke down whenever we had 200+ concurrent users. Sockets would randomly close.
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.
We also do had a memory leak because of socket.io 0.9.6
take a look at this discussion https://github.com/LearnBoost/socket.io/issues/1303#issuecom...
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.
How does this work for non-socket transports? You have to be saving the broadcasts in case someone is polling, right?
I'm not sure what you mean by "saving the broadcasts". Can you give an example?
Some 11% of clients are using XHR or JSONP protocols and it it Just Works(tm), I did not add anything special.
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].
1 - http://www.joyent.com/blog/walmart-node-js-memory-leak
2 - http://nodeup.com/fortytwo
"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
My understanding is the issue is not in the protocols, but in the implementation of the libraries themselves.
Hey guys, it's the creator here.
I never thought this little project would get this big!
If someone wants to help me scale this, or add things like chat, please do! Just send a PR on Github!
https://github.com/grant/hnplays2048
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.
0 - https://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitm...
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.
Right. It needs a Democracy mode. maybe even a Democracy/Anarchy slider controlled by Q and E.
I feel like this undermines the true spirit of HN Plays 2048
Ask and you shall receive http://hnplays2048-democracy.herokuapp.com/
Edit: Now integrated into the OP's app
Thanks for the feature, dbieber!
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)
Nice work though!
Yep, my bad. Added that too now. (changing not allowed)
Isn't that a metaphor for democracy in America today?
I like this one better: http://voting-2048.herokuapp.com/
Edit: pull request here if anyone wants to see the code:
https://github.com/grant/hnplays2048/pull/13
15-20 seconds seems like it might be too much, at least with the number of users online now...
Or as an alternative, perhaps it could allow each person 1 vote per 5 seconds, while keeping moves instant, so each time it is a subset of people
Counterpoint - In TwitchPlaysPokemon democracy mode was always a lot more boring, and a lot less fun, than anarchy mode.
This point was explored more fully in the Twitch Plays Pokemon community, where anarchy vs. democracy in the game caused a significant cultural crisis: http://www.reddit.com/r/twitchplayspokemon/comments/1y8r6d/i...
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.
This game is no more playable than it was when it was posted hours ago. And here's why:
setInterval(function() { window.manager.inputManager.emit("move", Math.floor(Math.random() * 3) + 1); }, 1000);
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.
A better algorithm would be:
seconds_between_commands = 60 - (60 / number_of_players);
With a clock letting you know when you can make your next move.
Otherwise, it's just way too easy to spam.
Good idea. Working on it.
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.
This is awesome. It's anarchic and chaotic and amazing.
I can't wait until it falls off the frontpage and drops to 5 users.
EDIT: We killed it. Nooo.
Should be online now.
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.
I added democracy mode...
The pull request is here: https://github.com/grant/hnplays2048/pull/10
You can play it here: http://hnplays2048-democracy.herokuapp.com/
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...
I like this one a bit better because it shows vote totals and has a visible countdown:
http://voting-2048.herokuapp.com/
Pull Request if anyone wants to see the code. Sorry this is in 2 places.
https://github.com/grant/hnplays2048/pull/13
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)
Is this HN's version of twitch plays Pokemon? http://www.twitch.tv/twitchplayspokemon
Yes. Explicitly.
https://news.ycombinator.com/item?id=7431436
I've made a version of 2048 on Hexagonal Board - check it out https://play.google.com/store/apps/details?id=com.spiralcode...
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)
Here is my app for Android: https://play.google.com/store/apps/details?id=com.contraryki...
Nice. I shall try this and never be productive for the rest of my life with all these 2048 forks.
According to GP your app contains in-app purchases.
Yuck. How much for that 2048 tile again?
Utter chaos going on in the game over there. But it's a fun experiment.
I think someone figured out how to unleash its AI on this :)
Yeah and whoever is running that AI is being a complete a-hole with the rate they're sending commands.
It's completing the puzzle in less than 5 seconds at the rate that its spamming commands.
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.
There's also an api: http://hnplays2048.herokuapp.com/api
:)
It's pretty interesting how the strategy derived by averaging over multiple intelligent users can be that sub-optimal.
Funny to see a new player entering the game to start button bashing and ruining the playing field in a matter of seconds :)
Can someone index all of these versions :)
This seems to show what I thought when I originally saw the game, that random spamming would get you pretty far.
It would be nice to know your own user #.
Good idea! I'll make an issue for this on Github.
Your own user inputs are now bolded
Commit: https://github.com/grant/hnplays2048/commit/308f68341b2c54bf...
This needs a delay. That way you can follow the chaos instead of just staring at a moving screen.
http://xkcd.com/1344/
It is a good demonstration that in cases like this user democracy is a loosing strategy.
Man... scalability sucks.
A-a-and it's down.
Another case of "HN crashes the heroku app"
LOL
We really need a democracy mode for this
it has been added and is awesome
I really don't like to hate on other people's work but seriously more 2048 forks? And now ones that aren't even remotely playable?
Make 2048 forks, not war.
Any idea on handling transaction?
Start9
Anarchy lasted minutes before the democracy babies came running in.
seems like it falls victim to popularity, and crashes often.
holy hell this makes me hate you all! =P
the chaos.
Crashed!!
you guys really suck at this game.
I'd love to give people the benefit of the doubt and attribute it to spoilers who intentionally move it against the flow, but I have my doubts.
A joKE?