For my (first) browser game, which I'm currently developing, I'd like to include a possibility to include others players on the map. It is a 2D Javascript Engine (with a rails backend), drawing players on it won't be a problem, but how can I track positions without spamming the server with requests? I read about websockets, but they seem too experimental, yet.
Basic question: How I can track user movement and avoid spamming the server with ajax requests?
Extended question: Is there a technique on the rise to track multiple player movements? It can be experimental, but at least some browsers should work with it already.

It's my first post on gamedev.net, so hello world and I hope I didn't break any rules yet.

So let's say you have 5 players in a room. You can all 5 players to be drawn on each others screens? I don't see why this would be an issue. Each player movement is recorded back to the server I'm assuming. You'd just draw sprites for the other 4 players based on their last known position.

I think my problem is that if 100 people are playing the game, even if they are in different rooms, they would send 100 requests to the server each second/move change. So I'm trying to find a way to have people see each other without having to send a large amount of http requests, don't want the server to crash

Ah, that's easy enough. Once every so often, like once every quarter second or so, have the client send back their current velocity as well as their current position. Then, when you're sending data back to each client with all the on screen actors include this velocity as well so the client can animate each actor on the screen in between the times it gets more data.

Though, you're going to deal with a lot of connections. What makes real time multi-player possible is a lot of data and a lot of data often. It's going to be a challenge. Please, keep us updated. I know I'd like to see how it comes out. One thing that would help limit this is only sending actor data back to each client for the actors that are in the current players view.

I had an idea today how I might overcome the connection problem. I need something like a network-like connection, which is pretty hard to achive in a browser environment. So why not use a node.js server with socket.io for managing the network part (positions, vectors, and ingame chat), while everything else stays on the rails/js environment.
The idea to only send position if a player is in your view is great, this should keep the amount of sent data reasonable. Additionally, if both vectors are 0, the client doesn't need to send data to the server.

I'm gonna try to hack something together tomorrow, and of course I keep you updated. I don't need a 128 people realtime network experience in the browser, but something like 16 people on one map is my first goal.

Yesterday, I managed to have 4 people running around on the same map
It is actually pretty easy to do, I'll post a more code related article later:
- Add another player object to the js engine
- Set up a node.js server with socket.io somewhere on the internet. I used heroku for this.
- Add the socket.io js link to the application
- On Player movement, the client now sends an array with the player id and current position to the node server. The node server broadcasts this information to every other connected player (In the future, there is a possibility to include groups here for coop mode). The other client receives the data. Now it looks in a players array on the second client application, if a player with the broadcasted id exists. If there is no such player, add a new "other player" object to this array and then set a "wanted" position. This is the position where the other player should be next. The application now takes the current position (if there is any), and move towards the new position.
In my game, I use 25 updates per second and try to send a new position every 100ms. It is a bit laggy yet, but for a first version, it's damn cool

One problem: Using heroku, I could not use websockets (not supported there yet), and only chrome manages to have a persistent connection. But its a first step.

Demo Video of the Multiplayer test, including a chat function.

Looks pretty good, nice job. You could probably have done an event based comet implementaiton ( http://en.wikipedia....t_(programming) ). Essentially the rate of http requests per second per client would be determined by the frequency of data being pushed to your game. Not sure if node.js/socket.io does something similar or not. Anyways, good job on your progress I'm working on something similar as well although purely limited to 2 people but it's good to see other people making progress on it as well

One thing I noticed though is that the way your doing it is fine assuming no one wants to be naughty but it is pretty open to hacking since your letting users send their position and velocity.

That's pretty cool. I'd love to read a blog post on how you set it up more specifically. The most i've done with websockets is a pub/sub setup where you draw with a pencil tool on the canvas, and release the mouse. The other users connected then see that drawing.

It's not perfect as it's not completely cross-browser, but the solution I found for this was with socket.io and node.js. Instead of opening a new http connection for each bit of data, socket.io provides the webapp with an "always-open" connection where the server can send/receive much smoother. This will support many more players on your map.

http://socket.io
http://nodejs.org

You can also use the Realtime Framework: http://www.realtime.co

We actually have a tag for canvas (demo will be put online soon).