# HTML canvas, Node WebSocket and multiplayer game like slither.io. How to send visual data over websockets?

Where to start creating a multiplayer game like slither.io, agar.io, etc.

I need only learn how to draw live positions and other data of all players into one fullscreen HTML5 canvas with update frequency +/-100ms.

I already have websocket server but that is only chat. I dont know sending images of players and positions. My first idea is sending every 100ms array of all players positions, current position on the map and all other data of players.

var worldSize = [10000,10000]; //width and height in px
var currentPosition = [5000,5000]; //center on the map
var players = new Array();
//on player join
players.push({
id: 1,
name: "test",
position: [1234,850], //random position on the map
points: 100 //example points
});

//on player eat point find that player, update players[index].points+1 etc.


This is only my (bad) idea and I not tested it because I dont know how start, how to send visual game data via websockets. How?

Update

I checked slither.io game WebSocket console and all frames is Binary Frame (Opcode 2) and Binary Frame (Opcode 2, mask). This is short version of array of all players and their positions and all other data? Or?

For example if game play 1000 peoples, that array will be too long. This will lag browser?

• Slither.io was made in flash BTW – Bálint Sep 27 '16 at 12:08
• Updated question. – Dave Sep 27 '16 at 12:22

When you have a massive multiplayer game, then giving everyone information about everyone is often overkill (upload bandwidth on the server would increase quadratic with the number of players). In many cases it is completely sufficient to only send updates about those players which are close enough to appear on the player's screen and omit updates for those further away.

Further, you can sometimes safe traffic by only informing players about things which change, not things which stay the same. In agar.io, for example, players often move with a constant speed in a constant direction. When neither speed nor direction changed since the last tick, you don't need to resend that information. The same applies to player information like name, color, size etc. Don't resend information which didn't change.

• Given that the server forwards these messages; do you mean that the server should calculate; for each client; which other client is near, before sending the message? – Paul Nov 12 '19 at 19:55
• @Paul Yes. If that becomes too computationally expensive in your case, consider to divide the game world into cells of uniform size and keep track of which players are in each cell. That way you just need to build one message per cell (with all players in that cell and the adjacent cells) and send that message to everyone in that cell. – Philipp Nov 12 '19 at 21:37
• I was thinking that, but theoretically you would have issues at the edges of those cells. But then you could make cells overlap or send everyone a 3x3 cells around them. – Paul Nov 14 '19 at 6:49
• @Paul Sending everyone a 3x3 cell around them is exactly what I meant with "all players in that cell and the adjacent cells". – Philipp Nov 14 '19 at 9:18
• I might have not completely read your message as I was thinking exactly the same except missing "adjacent", but indeed :) – Paul Nov 14 '19 at 17:51

You don't send visual data over websockets, you only send the positions, then use that to draw the images on the screen.

You should do everything on server side, collision detection, updating entities, etc.

• Updated question about big array of users – Dave Sep 27 '16 at 12:23