3 ms·

All my games use a server-client architecture. It's a custom written WebSocket implementation, see https://news.ycombinator.com/item?id=13267261 https://news.y

All my games use a server-client architecture. It's a custom written WebSocket implementation, see https://news.ycombinator.com/item?id=13267261 https://news.ycombinator.com/item?id=13267261 I think Agar.io has around 190 players per server. Diep.io has around 72.

comboy 10y ago
So basically cell won't be eaten/exploded by virus until server says so? I would have thought that would be perceived as too slow. Per server you mean like in a game room or is one game room equal to one linux box? If so, I guess then that handling the game logic was the bottleneck, not the number of concurrent connections? Also, congrats on the success and making some really cool games.
- Matheus28 10y ago
  Exactly. Per game room (each room is a process). I end up just using boxes that have 1 CPU core and run just that game room in there. Except for some dedicated servers that have 40+ cores, in which we run 40+ processes. On Agar.io doing all the collision checking and encoding the packets is the biggest bottleneck. Similarly for Diep.io. Number of players of course increases those two factors almost linearly. For example, Diep.io doesn't process shapes that aren't being transmitted to anyone.
  - bemmu 10y ago
    What kind of collision detection do you use? I was inspired by your games to try something similar for the latest Ludum Dare: http://www.bemmu.com/compo/ludum/37/index.html http://www.bemmu.com/compo/ludum/37/index.html At first I tried checking every creature for collisions against everything else, but unsurprisingly that was too slow (N^2). To reduce the checks I put each creature in a grid cell based on their position, then check for collisions only against creatures in the same or adjacent cells. I think overlapping grids would be even more efficient, or perhaps to do these checks on GPU.
    - efnx 10y ago
      Use a quadtree or similar structure for your broadphase detection, it will help right off the bat.

comboy 10y ago

So basically cell won't be eaten/exploded by virus until server says so? I would have thought that would be perceived as too slow. Per server you mean like in a game room or is one game room equal to one linux box? If so, I guess then that handling the game logic was the bottleneck, not the number of concurrent connections? Also, congrats on the success and making some really cool games.

Matheus28 10y ago
Exactly. Per game room (each room is a process). I end up just using boxes that have 1 CPU core and run just that game room in there. Except for some dedicated servers that have 40+ cores, in which we run 40+ processes. On Agar.io doing all the collision checking and encoding the packets is the biggest bottleneck. Similarly for Diep.io. Number of players of course increases those two factors almost linearly. For example, Diep.io doesn't process shapes that aren't being transmitted to anyone.
- bemmu 10y ago
  What kind of collision detection do you use? I was inspired by your games to try something similar for the latest Ludum Dare: http://www.bemmu.com/compo/ludum/37/index.html http://www.bemmu.com/compo/ludum/37/index.html At first I tried checking every creature for collisions against everything else, but unsurprisingly that was too slow (N^2). To reduce the checks I put each creature in a grid cell based on their position, then check for collisions only against creatures in the same or adjacent cells. I think overlapping grids would be even more efficient, or perhaps to do these checks on GPU.
  - efnx 10y ago
    Use a quadtree or similar structure for your broadphase detection, it will help right off the bat.