Tips for communication between JS browser game and node.js server? [closed]

Question

I am tinkering around with some simple Canvas based cave flyer game and I would like to make it multiplayer eventually. The plan is to use Node.js on the server side.

The data sent over would consists of position of each player, direction, velocity and such. The player movements are simple force physics, so I should be able to extrapolate movements before next update from server.

Any tips or best practices on the communications side? I guess web sockets are the way to go. Should I send information in every pass of the game loop or with specified intervals? Also, I don't mind if it doesn't work with older browsers.

Answer 1

I recently made a asteroids/geometry wars crossover with Node.js / JavaScript:
http://github.com/BonsaiDen/NodeGame-Shooter

It has a fat Server which processes the game and thin clients which are basically just views. The client does some interpolation and things to make it look smooth.

You may want to look at these two files, which contain the underlying networking logic, as well as the actor and client models:
http://github.com/BonsaiDen/NodeGame-Shooter/blob/master/client/nodegame.client.js
http://github.com/BonsaiDen/NodeGame-Shooter/blob/master/server/nodegame.js

The whole game is based on Actors which handle their "update events"(the stuff that gets send to the clients) on their own, for the most part. It's also possible to hide actors from specific client to implement, for example, invisibility.

One can also record games and just feed the messages into the client to play them back.

As far as the tech goes:
WebSockets are the way to go here. I also did a custom binary encoding for JS that, while giving up on things like more than 2 decimal places on floats, is about 50% smaller than JSON(and is 2x as fast under V8 than native JSON encoding)

Answer 2

I'd suggest to keep things apart.

In Stendhal which is a 2D MORPG written in Java, we did the following things and it works out pretty fine:

• The client uses a fast loop for drawing. It does smooth animation and some predictions to minimize lag.
• The server uses a loop to process all the game logic. In our case it can be a lot slower than the drawing loop. While the clients make some predictions, the server always wins.

Communication between client and server is done using actions and perceptions:

• Actions done by the users like "move up" are sent to the server when they occur. The server queues them up and processes them in its own loop.
• Perceptions are sent from the server to the client to update their view of the world.

We did some "tricks" to gain additional performance:

• We have two kinds of perception messages: A full one used on login and players joining a zone. And incremental updates used after that. This saves a lot of network bandwidth.
• We split perception messages into a public and a private part: All players in the same zone share the same public part so we save processing time because serialisation turned out to be a bottle neck on Java (not JavaScript).

Answer 3

Use socket.io, it's a handy WebSockets abstraction library that provides fallbacks for browsers that don't support it.

Also, if you are going for an online model like that, I would recommend moving game processing to the server. That way you only need to communicate graphical changes and mouse/keyboard input. It also helps quite a bit to prevent cheating.