# How to find and send data about on-screen players to a client in a real-time multiplayer game?

I'm surprised I couldn't find much information on this.

I am making a top-down browser game in which the players see a small section around their player (see the image). Since the player doesn't need to render the players far away that they can't see, it would be unnecessary to send data about them. I want to know how the server should calculate who is near enough to the client that they appear on their screen and therefore receive data from the server about those players.

The way my problem differs from what I have found is that I need to track many players (at least 50 and preferably up to 100) and many can be on screen at one time (assume a maximum of 10 on screen at any one time).

• The players are always moving and positions constantly changing
• Must handle at least 50 players at one time (preferably up to 100)
• Players can drop in and out at random locations so should be able to adapt to this quickly
• Screen sizes vary
• Player input is just movement (but there should be scope for other simple actions)
• Data sent over TCP as will be browser based
• Node.js server

Initially I thought about sending data for all the positions of the players to each player but this seems like a terrible idea with so much unnecessary data being sent - from what I understand the server should be sending as little as possible.

My current strategy (shown in the image) is to have the server periodically (every second for example) calculate the distances between all players to determine those near enough to each other to appear on screen. For the next second, data will only be sent to the client regarding those near it. After the next second, new distances are calculated to decide what to send (and render) for each player.

Some problems to take into account:

• A lot of calculations must be performed by the server for all the players
• Extra information would need to be sent about players just outside the screen to account for any movement between updates
• Interpolation would probably be required
• Different screen sizes will mean that some players can see more than others (the fairness isn't the issue here, but tracking to what distance to let players see)

The main issue is the ability of the server to process all of this with everything else that it must already do. I am not convinced this is a very good way.

This is trivial for off screen entities in a single player game, however for multiplayer games with many players moving at once this becomes much more difficult.

How can I figure out what players are on screen efficiently and what data should be sent regarding this? Or please point me to where I can find information on this.

• If it's a 2D game, get everything that falls within the screen rect as world space coordinates. If it's a 3D game, get everything that falls within the camera frustum (again, world space). Jun 30 '17 at 7:02

Also, you may not want to send n(n-1) packets each frame for n players regarding every other player's n positions necessarily if you're concerned about performance too much. The best approach may be to fit all of this data each tick into one giant packet containing the positions of every other player within the same chunk as the player you're sending position data to, so there are as few send() calls as possible (then again, this may not be a huge performance hit either in practice depending on the game). The size of one packet in this case is upper bounded by the num of players in a chunk * size of player packet.