Hello all hackers from HackerNews. We notice a new MMO was released by n01se and xkcd yesterday (September 26th, 2012) with multiple users flying around with a balloon figure. If you got stuck, you can click your balloon guy and turn into a ghost to seamlessly move through the landscape unhindered by mortal barriers like trees and hills. There was a problem however with the scaling of users on the system. The max concurrency could only be 20 users at a time leaving many wonder where the MMO part of the MMO was. We ripped out the non-scaling Node.JS code. ENJOY.
I don't think it's fair implying that Node.js is to blame for the scaling issues of this particular project. Dead reckoning, variable polling and other tricks could have been used with a Node.js server as well and make it look smooth and play decently, they just weren't there in this implementation.
Stagas, you are correct. Thank you for mentioning this. Node is not to blame here as you say. However MMOs require orchestration and server parallelization expertise in order to properly scale an acceptable user experience.
I have no doubts your system is a very powerful and scalable solution for pubsub, but I believe just the fact that it's not utilizing Websockets, the overhead is not acceptable for MMOs or other latency sensitive tasks. So you shouldn't advertise as such, people might actually believe you and try and build one. It'll blow up in their face when they realize they can't get the latency down to an acceptable level due to the 200-300 extra bytes per request and the delay of constantly opening new connections.
There are a fair number of browser based strategy games such as evony.com where latency is not really an issue. It's mostly a question of how to handle communication between back end servers and 'world' chat that's the real scaling issue.
It should be more than adequate for strategy or turn based games. Perhaps I should have been more clear that I was talking about latency sensitive MMOs, like shooters or anything where your position and movement in time are critical to the gameplay.
It's a good hack and all, but you didn't actually solve the real problems. Most of which ahould be solved with server side logic[0], something I'm guessing your service can't do?
I guess it would be more as a concept than technically. That is, you could send to a specific peer through the server. That way you could have only the messaging logic on the server and the game logic on the clients.
The clients would then (again theoretically) be able to agree on a game state, optimize messaging and the other things you would normally do on the server.
Enter the xkcd World with Friends: http://www.pubnub.com/static/pubnub-xkcd/index.html