

Lessons learned building a multiplayer game in NodeJS and WebGL - arasmussen
http://codeofrob.com/entries/lessons-learned-building-a-multiplayer-game-in-nodejs-and-webgl.html

======
sgrove
The author mentions defensive object cloning, which is, in general, an
unpleasant way of doing things. Using immutable data structures makes for a
far saner development experience (although with Javascript as the underlying
target, it probably means some automatic defensive copying anyway...).

Using mutable state obviously generates far, far less garbage, and we've run
into all sort of problems of bumping up against the GC in trying to have fast-
enough javascript, so it is tempting from a performance POV. Would be
wonderful if immutable structures can eventually co-exist nicely with GC
implementations.

Great article, thanks for writing it!

~~~
kevingadd
Unfortunately there aren't any particularly efficient ways to do immutable
values in JS right now. readonly properties tend to behave in poor ways (like
silently discarding attempted writes, or slowing down jitted code) and
immutability forces you to create way more object instances than you would
otherwise (which, as the post mentions, tends to perform poorly due to the
relative immaturity of JS GCs.)

At this point I consider this to be a bigger problem than it was when I wrote
about it [1]. On the upside, it's possible to use tools like Emscripten or
LLJS to produce JavaScript code that doesn't suffer from these downsides
because it doesn't rely on the JavaScript GC or heap, but that introduces its
own issues.

Ultimately, JS engines either need dramatically better garbage collectors or,
the language needs to evolve to the point that an ordinary piece of JavaScript
isn't going to place tons of pressure on the collector. Proposals like Binary
Data [2] will help pave the way here but it may ultimately take the addition
of value types that behave like structs in C/C#.

[1] [http://www.luminance.org/blog/code/2011/06/18/performance-
ch...](http://www.luminance.org/blog/code/2011/06/18/performance-challenges-
in-compiling-code-to-javascript)

[2] <http://wiki.ecmascript.org/doku.php?id=harmony:binary_data>

------
jpadvo
I'm a web developer, but am just about to jump into making a multiplayer HTML5
game, just for fun.

But after reading this post, and the one linked at the bottom [1], I'm
thinking maybe this is going to be pretty valuable professionally. It should
give insight from a completely different vantage point on what it means to
write good code. By the way, you really should read that other post, too. It
offers some interesting ideas to think about.

[1] [http://codeofrob.com/entries/a-relaxed-attitude-towards-
the-...](http://codeofrob.com/entries/a-relaxed-attitude-towards-the-
pragmatic-delivery-of-okay-software.html)

------
TazeTSchnitzel
>If you're going to deploy a long running node application that is going to be
running a constant load, don't deploy it to either: A really low budget VPS

My multi-user node.js chatroom (<http://ponyplace.ajf.me/>) sustains around 60
concurrent users at any given time on a $5/month (not oversold) VPS. It can
sustain a lot more than that too (151 at its highest yet after a 4chan raid).

The secret I find is in not letting your web server gobble up your memory.
Don't use Apache, for example. I use nginx.

~~~
robashton2
Hey, I noticed the traffic spike and came to say hello.

The thing about a chatroom and load, is that your server is effectively just
message passing, and if there is any CPU spike, that is all it is - a spike,
which VPSs for the most part are fine with.

When you are executing physics and logic 30 times a second _constantly_
regardless of load (so I made a mistake in phrasing there in my blog post),
then you will be throttled on a cheap VPS because you're no longer being a
good citizen - which was my point in that post if I recall correctly.

To my recollection, this hasn't got much to do with memory at all. I hope this
clarifies what I meant to say a bit more.

~~~
TazeTSchnitzel
Ah. I thought your point was more about VPSes and guaranteed vs burst RAM,
which would be an issue. I see your point.

------
james33
The game is giving a 503.

~~~
dirkk0
This blogpost is old and the EC2 instance is not there anymore. I guess this
was posted to give attention to the code.

~~~
jpadvo
...which is available here: <https://github.com/robashton/HoverBattles>

I just downloaded it and am gonna see if I can get it to run...

Edit: to run the game, download the code, and open the folder in your
terminal, and run:

> npm install > npm install socket.io > mv config/keys.json.example
> config/keys.json > node server.js

Then open your browser and navigate to <http://localhost:8000>

~~~
robashton2
Yeah, that's pretty much it - I don't really want to keep dozens of domain
names and DNS entries for pet projects lying around when they're only going to
get 10 hits a day and the code is all available :-)

