6 ms·

With Stadia et al. your computer sends keystrokes and mouse movements to Google's servers, and the server returns a video feed that's then displayed on your scr

With Stadia et al. your computer sends keystrokes and mouse movements to Google's servers, and the server returns a video feed that's then displayed on your screen. Today's multiplayer games send and receive movement information and such, but the graphics rendering, which I believe is the main issue here, is still done client-side.

gameswithgo 5y ago
we try to send something as close as just keystrokes in games too, to prevent cheating among other reasons. sometimes we have to send actual state though
setr 5y ago
I don’t think graphics rendering is really the problem — worst comes to worst, you just reduce graphical fidelity — and regardless, rendering 300 AI characters roaming around is clearly doable, and it’d be the same with viewing real players. It’s a client-side problem, and doesn’t have to really scale much with player count (Stadia’s main pitch was that you didn’t need high end PCs to play AAA games — not that it would enhance games’ ability to play online) The hard part is dealing with 300 players communicating simultaneously with random delays and state changes, in an environment that doesn’t really handle delays very well (a text chat can be 10s late and no one cares. A character moving can only be a frames late before interpolation becomes obvious, and you start teleporting people around). And tracking the state changes across users and passing them around tends to add up, causing further delays. Of course, you could always change the game model itself too. RuneScape & Maplestory trivially enabled large groups of players simultaneously (pretty sure you could easily find places with 200+ players visible and active). Runescape was basically turn-based and ran like 1 turn a second, so much larger room for delays. Maplestory capped actual active play to relatively few players, but enabled large quantities in towns acting as glorified visual chat rooms — which solved 90% of the feeling of being in a large community. The Maplestory strategy I think nearly every MMO implements.
- jfrunyon 5y ago
  The delays, interpolation, etc. are a big problem in games like FPS, but I fail to see why they'd be a large problem in an MMO. Why can't you just send the new position of other visible players, and then client-side play those characters' walking animations to the new position from their current (client-side) position? Unless the accuracy of another player's targeting is relevant why is there a problem with their position always being delayed by, say, a second?
  - patmcc 5y ago
    A good MMO typically isn't just a large number of players walking around and not interacting with one another. Look at Eve Online; you have a spaceship, you travel around and shoot stuff (this is simplifying it, but that's a big part of it). Sometimes there are 100 or 1000 ships all involved in one battle; what do you have to deal with in that case? You need to send all ship data (model, loadout, customizations) to every client so they can load in the right assets. You need to track where each ship is (in 3d) and where it's going at any given time. You need to track what weapons are firing, and who they might hit (there are missiles, interception missiles, "bombs" with an explosion radius, lasers that hitscan, guns that have tracking projectiles, etc). You need to compute status effects that may change based on distance between given ships. You need to send all this data to each client regularly (every second at least). This really adds up, both in compute and memory on the server and in amount of data that needs to be sent to each client. It gets difficult quickly. Let's say all the info above can be described in 1kb/ship/tick - you get up to the larger battles, which in Eve have hit 5000+ (rarely, yes) - and you're dealing with 5000kb/tick going to every one of those clients.
    - rasz 5y ago
      Eve online has a lot of self inflicted problems, like relaying on Python for speed sensitive code, running single threaded servers, allocating one CPU per solar system (small region around a star) instead of per grid, expanding Grids to ridiculous sizes instead of partitioning them into small microgrids with delayed group updates. You really dont need to be send accurate per server tick information about a rocket hitting a ship 5000km away from you.

gameswithgo 5y ago

we try to send something as close as just keystrokes in games too, to prevent cheating among other reasons. sometimes we have to send actual state though

setr 5y ago

I don’t think graphics rendering is really the problem — worst comes to worst, you just reduce graphical fidelity — and regardless, rendering 300 AI characters roaming around is clearly doable, and it’d be the same with viewing real players. It’s a client-side problem, and doesn’t have to really scale much with player count (Stadia’s main pitch was that you didn’t need high end PCs to play AAA games — not that it would enhance games’ ability to play online) The hard part is dealing with 300 players communicating simultaneously with random delays and state changes, in an environment that doesn’t really handle delays very well (a text chat can be 10s late and no one cares. A character moving can only be a frames late before interpolation becomes obvious, and you start teleporting people around). And tracking the state changes across users and passing them around tends to add up, causing further delays. Of course, you could always change the game model itself too. RuneScape & Maplestory trivially enabled large groups of players simultaneously (pretty sure you could easily find places with 200+ players visible and active). Runescape was basically turn-based and ran like 1 turn a second, so much larger room for delays. Maplestory capped actual active play to relatively few players, but enabled large quantities in towns acting as glorified visual chat rooms — which solved 90% of the feeling of being in a large community. The Maplestory strategy I think nearly every MMO implements.

jfrunyon 5y ago
The delays, interpolation, etc. are a big problem in games like FPS, but I fail to see why they'd be a large problem in an MMO. Why can't you just send the new position of other visible players, and then client-side play those characters' walking animations to the new position from their current (client-side) position? Unless the accuracy of another player's targeting is relevant why is there a problem with their position always being delayed by, say, a second?
- patmcc 5y ago
  A good MMO typically isn't just a large number of players walking around and not interacting with one another. Look at Eve Online; you have a spaceship, you travel around and shoot stuff (this is simplifying it, but that's a big part of it). Sometimes there are 100 or 1000 ships all involved in one battle; what do you have to deal with in that case? You need to send all ship data (model, loadout, customizations) to every client so they can load in the right assets. You need to track where each ship is (in 3d) and where it's going at any given time. You need to track what weapons are firing, and who they might hit (there are missiles, interception missiles, "bombs" with an explosion radius, lasers that hitscan, guns that have tracking projectiles, etc). You need to compute status effects that may change based on distance between given ships. You need to send all this data to each client regularly (every second at least). This really adds up, both in compute and memory on the server and in amount of data that needs to be sent to each client. It gets difficult quickly. Let's say all the info above can be described in 1kb/ship/tick - you get up to the larger battles, which in Eve have hit 5000+ (rarely, yes) - and you're dealing with 5000kb/tick going to every one of those clients.
  - rasz 5y ago
    Eve online has a lot of self inflicted problems, like relaying on Python for speed sensitive code, running single threaded servers, allocating one CPU per solar system (small region around a star) instead of per grid, expanding Grids to ridiculous sizes instead of partitioning them into small microgrids with delayed group updates. You really dont need to be send accurate per server tick information about a rocket hitting a ship 5000km away from you.