I made this RPG node demo a while back: http://sleeperbot.com
I'm not using any server monitoring so it can crash at any moment.
Would love to get more than 15 users on here moving around and see what happens.
Experimenting with Node.js
21–30 of 88 posts
Re: Experimenting with Node.js
#22I made this RPG node demo a while back: http://sleeperbot.com I'm not using any server monitoring so it can crash at any moment. Would love to get more than 15 users on here moving around and see what happens. code: http://github.com/weixiyen/avatar
Your comment is less than a minute old and it's already giving a 502 Bad Gateway error :(
Re: Experimenting with Node.js
#23I made this RPG node demo a while back: http://sleeperbot.com I'm not using any server monitoring so it can crash at any moment. Would love to get more than 15 users on here moving around and see what happens. code: http://github.com/weixiyen/avatar
Your comment is less than a minute old and it's already giving a 502 Bad Gateway error :(
sorry was messing with nginx config. it's up now
Re: Experimenting with Node.js
#24Extremely cool demo. It would be interesting to see this applied to analytics, so you could see exactly what people are doing on your site in real time. Although that would also be a bit creepy.
There's already something called Hummingbird that does that: http://mnutt.github.com/hummingbird/
Hummingbird shows traffic in real time. It doesn't show mouse movement or user activity in real time.
Re: Experimenting with Node.js
#25Why is it that within ten seconds, I felt compelled to "hump" other arrows with my own?
It was also interested to see if I could get other people to form lines and other constructs, without any communication other than my own cursor.
Re: Experimenting with Node.js
#26Earlier quoted context omitted.
This was a startup idea I had when I started Mibbit (I decided on balance webchat had more potential than multiplayer web games). The idea was 'mouse games'. I had a similar setup where you could see everyones mouse cursor. I planned a whole load of multiplayer games where you could chase each other, complete puzzles, click on other people to kill them, draw circles round other players to trap them, etc etc. You coul…
It still sounds like a pretty cool idea to me - I'd certainly check it out if something like that existed.
But would you also:
* Come back regularly to play it?
* Pay to play it?!! :/
* Click on ads? (If the creator were evil, they'd confuse
the users into clicking on ads, making them think it's
part of the game).
Re: Experimenting with Node.js
#27It would be interesting to hear from the author how the server is handling HackerNews traffic
Hi, author here. While building this thing, the Node server had the tendency to drop out. I'm monitoring it with God ( http://god.rubyforge.org/ ) now, so it restarts whenever anything goes wrong. I'm genuinely impressed by how it's holding out now. :)
What kind of traffic have you gotten in the last hour?
Re: Experimenting with Node.js
#28While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that are 6 or 7 callback chained together--and don't forget to attach error callbacks as well at each point.
In the Python world, for example, eventlet, gevent, and diesel (disclosure: my project) all use coroutines to achieve very high performance asynchronous I/O that's still written in a "synchronous" style. And before that, CCP games has been using stackless python to do coroutine-based networking for the servers behind the very popular MMORPG eve online (http://www.tentonhammer.com/node/10044).
Even slicker, in languages like Erlang and Haskell (via forkIO + the select/epoll I/O manager), support for asynchronous networking using "blocking-style" code is a fundamental language/compiler/vm feature. When you write any code in these languages, you're transparently taking advantage of the same scaling characteristics node.js and its ilk provide.
So, I'd humbly suggest to anyone getting serious about doing this kind of programming that they investigate some of these systems (which are usually built by weary callback-style async I/O veterans) and leapfrog the rest of their peers. Consider Node.js a gateway drug.
Linkage:
http://eventlet.net/ http://github.org/jamwt/diesel http://en.wikipedia.org/wiki/Asynchronous_I/O#Light-weight_p... http://www.galois.com/~dons/slides/a-scalable-io-manager-for...
Re: Experimenting with Node.js
#29Earlier quoted context omitted.
It still sounds like a pretty cool idea to me - I'd certainly check it out if something like that existed.
But would you also: * Come back regularly to play it? * Pay to play it?!! :/ * Click on ads? (If the creator were evil, they'd confuse the users into clicking on ads, making them think it's part of the game). Still a fun thing to make though!
As with everything, it depends on the implementation ;)
I think it's probably tougher to monetize a web game, but flash game creators seem to be doing moderately well with advertisements that run before you can play the game.
There's an interesting hook in what you're talking about: I could IM a friend and say "hey jump on here, let's play together". It's much more social than most web games out there which is intriguing.
In general most web pages feel like you're there by yourself. The model of seeing many other people there at the same time is novel enough right now that it should be a little easier to get people to tell each other about it.
Re: Experimenting with Node.js
#30While I think it's great that more and more developers are being exposed to building network applications using async I/O (which I guess is "evented" now) via Node.js, I think it's worthwhile to point out that the state of the art has moved well beyond these kind of callback frameworks. The reason is simple: it sucks programming in callback patterns on serious, large projects. You end up with lots of routines that ar…
I think developers get attracted to frameworks because of fun examples like the one linked in the posting. Until there are multitudes of interesting examples using other tech, I think it's going to be an uphill battle to attract significant numbers of developers to them.
Since many of the Node.js demos like this one are open-source it's much easier for developers to download working code and make modifications to see how everything works.
The technically superior solutions often get overlooked for the most accessible ones.