3 ms·

Modern multiplayer games already do the "world model" calculations on the server, with clients simply rendering the little data they have.

haolez 7y ago
Then what’s stopping us from making a MMORPG with the physics of a simulator?
- nepeckman 7y ago
  The technical difficulty of making an MMORPG I'm guessing.
- kllrnohj 7y ago
  A lack of gameplay from the resulting physics to justify the server costs? Game devs don't simulate worlds for the fun of it. They have a purpose behind things. There's a cost/benefit involved.
  - honkycat 7y ago
    > Game devs don't simulate worlds for the fun of it. Unless you are Tarn Adams
    - AnIdiotOnTheNet 7y ago
      Or about a thousand other small indie devs, but somehow I don't think Stadia has much interest in them. P.S.: Don't take this statement the wrong way, I love small indie devs and donated for Dwarf Fortress.
- beaconstudios 7y ago
  I would hazard to guess that latency would be a killer for that. It's painful enough if you have 100ms ping on tactical FPS games like CS:GO for instance, but if the delay in a player's position updating caused a completely different physics cascade to happen (running into a wall rather than a stack of cardboard boxes for instance), that could get pretty jarring to see either the correction occurring constantly or the physics delayed after someone's actions. Of course I'm just theorising - it could be an idea that no-one's implemented yet.
juped 7y ago
Rendering is the computationally heavy part.
deleted 7y ago
[deleted]
skybrian 7y ago
Hmm, I'm wondering if rendering on the server would make things a bit harder for bots? It seems hard to figure out exactly what to send without at least doing visibility calculations and clipping?
- windsurfer 7y ago
  I have heard that the latest Counter Strike servers do player occlusion calculations on the server so that cheaters can't see through walls. If you can't see an enemy, than the server won't even send your client their position.
dividuum 7y ago
That only partly helps with cheating. Client side cheat software still has access to the internal game state and can modify rendering (so you see in the dark for example) or input (point the gun at any visible opponent). If you only remotely control a video stream, that's harder. I guess the next step would then be computer vision on the video stream.
- ryanmercer 7y ago
  >That only partly helps with cheating. Client side cheat software still has access to the internal game state and can modify rendering (so you see in the dark for example Exactly, companies like "Artificial Software" (artificialaiming.net) have been selling aimbots for FPS for a decade or longer. I was curious back in 2009 and purchased access for a game in the Battlefield franchise. It allowed me to have colored rectangles around all other players, my own team being green and the opposing team being red. You could see this rectangle through walls which would let you rack up kills and avoid getting ambushed. You could also auto-aim and tell it if you wanted the head or the torso, you could headshot people that were so far away you could not see a single pixel of their body. It also allowed you to start using your knife rapidly if an enemy got within a certain proximity of you. It would even allow you to spawn in on enemy team memebers instead of your own team on maps that allowed you to spawn on team members AND it would change your name on non-hardcore servers to appear to appear as an ally to the enemy so you could spawn on one and casually follow them around, them thinking you were on their team, and just knife or headshot them when you wanted or follow them to a group of them and det pack/grenade/spray and pray and kill a bunch of them. A quick look at their site and they still have many bots that still allow many of these features (and others like radar hacks, no recoil, no bullet spread etc) for various titles because all of this is still on the client side.
- Izkata 7y ago
  > I guess the next step would then be computer vision on the video stream. Matching output seen on the screen has existed for decades under the umbrella of macros. I remember writing my own for an MMO around 2005 using AutoIt; it was significantly easier than any client modification.
squeaky-clean 7y ago
Yep, definitely not new tech. (You probably know this next bit, but just for anyone scrolling by). Having your server verify every action is the only way to prevent hackers from simply sending a packet that says "I got a headshot on that guy". Instead the server replays through all their actions. You never say you got a headshot, you just say when you clicked and the server figures out if you hit. And because like you mention, clients only receive gameplay data and not the fully rendered screen, this allows clients to do things like interpolate the (delayed) server data with their own realtime input elements. Otherwise every single action you take would be delayed by whatever your latency is, and every other player's actions would be delayed by a similar amount. Instead, it appears seamless until your latency gets so bad that you just begin teleporting between positions because the server can't track you well enough (often called multiplayer rubber-banding). Instead (well designed) game servers run their own authoritative version of the game world and track each player's latency, and use that to replay the previous few ticks of the game when an input comes in from any player. So if you have a 100ms ping, and press "W" to walk forward, when the server receives your forward input it treats it as if you have been moving for 100ms already. Basically, saying every player shares the world model is incorrect unless you can set them all to the same latency. https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... Edit: additional source, these gafferongames articles are a bit old (2004) but still extremely relevant. https://gafferongames.com/post/networked_physics_2004/ https://gafferongames.com/post/networked_physics_2004/ https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/ https://gafferongames.com/post/what_every_programmer_needs_t...
Impossible 7y ago
This isn't entirely true for most games, clients run world simulation for prediction and sometimes can make authoritative changes. Almost no multiplayer games are complete dumb terminals ,you'd end up with the same latency issues that Stadia has. Complex physics with high object counts can be difficult because synchronizing a lot of state is bandwidth intensive. Most games with lots of moving objects (RTS for example) use deterministic lockstep so only inputs need to be transferred, even if there is an authoritative server.
summerlight 7y ago
This is simply an incorrect statement. Even with a dedicated server, most games simply replay game logic with deterministic lock-step simulation based on ordered user input events. There's some exceptions, but (partial) state synchronization is tricky especially with complex physical interaction and complicates/limits game design with a huge amount of edge cases so it's not a wise choice unless you absolutely need to do this, like open-world or MMO games.
- windsurfer 7y ago
  What games are you talking about? For example, Natural Selection 2, Counter Strike GO, and Overwatch all do a full simulation of the world on the server, and the server is 100% authoritative. Clients are often running the same simulation locally to predict state despite network latency. Players also can experience packet loss or reconnect at any point and still have full state synchronization.

haolez 7y ago

Then what’s stopping us from making a MMORPG with the physics of a simulator?

nepeckman 7y ago
The technical difficulty of making an MMORPG I'm guessing.
kllrnohj 7y ago
A lack of gameplay from the resulting physics to justify the server costs? Game devs don't simulate worlds for the fun of it. They have a purpose behind things. There's a cost/benefit involved.
- honkycat 7y ago
  > Game devs don't simulate worlds for the fun of it. Unless you are Tarn Adams
  - AnIdiotOnTheNet 7y ago
    Or about a thousand other small indie devs, but somehow I don't think Stadia has much interest in them. P.S.: Don't take this statement the wrong way, I love small indie devs and donated for Dwarf Fortress.
beaconstudios 7y ago
I would hazard to guess that latency would be a killer for that. It's painful enough if you have 100ms ping on tactical FPS games like CS:GO for instance, but if the delay in a player's position updating caused a completely different physics cascade to happen (running into a wall rather than a stack of cardboard boxes for instance), that could get pretty jarring to see either the correction occurring constantly or the physics delayed after someone's actions. Of course I'm just theorising - it could be an idea that no-one's implemented yet.

juped 7y ago

Rendering is the computationally heavy part.

deleted 7y ago

[deleted]

skybrian 7y ago

Hmm, I'm wondering if rendering on the server would make things a bit harder for bots? It seems hard to figure out exactly what to send without at least doing visibility calculations and clipping?

windsurfer 7y ago
I have heard that the latest Counter Strike servers do player occlusion calculations on the server so that cheaters can't see through walls. If you can't see an enemy, than the server won't even send your client their position.

dividuum 7y ago

That only partly helps with cheating. Client side cheat software still has access to the internal game state and can modify rendering (so you see in the dark for example) or input (point the gun at any visible opponent). If you only remotely control a video stream, that's harder. I guess the next step would then be computer vision on the video stream.

ryanmercer 7y ago
>That only partly helps with cheating. Client side cheat software still has access to the internal game state and can modify rendering (so you see in the dark for example Exactly, companies like "Artificial Software" (artificialaiming.net) have been selling aimbots for FPS for a decade or longer. I was curious back in 2009 and purchased access for a game in the Battlefield franchise. It allowed me to have colored rectangles around all other players, my own team being green and the opposing team being red. You could see this rectangle through walls which would let you rack up kills and avoid getting ambushed. You could also auto-aim and tell it if you wanted the head or the torso, you could headshot people that were so far away you could not see a single pixel of their body. It also allowed you to start using your knife rapidly if an enemy got within a certain proximity of you. It would even allow you to spawn in on enemy team memebers instead of your own team on maps that allowed you to spawn on team members AND it would change your name on non-hardcore servers to appear to appear as an ally to the enemy so you could spawn on one and casually follow them around, them thinking you were on their team, and just knife or headshot them when you wanted or follow them to a group of them and det pack/grenade/spray and pray and kill a bunch of them. A quick look at their site and they still have many bots that still allow many of these features (and others like radar hacks, no recoil, no bullet spread etc) for various titles because all of this is still on the client side.
Izkata 7y ago
> I guess the next step would then be computer vision on the video stream. Matching output seen on the screen has existed for decades under the umbrella of macros. I remember writing my own for an MMO around 2005 using AutoIt; it was significantly easier than any client modification.

squeaky-clean 7y ago

Yep, definitely not new tech. (You probably know this next bit, but just for anyone scrolling by). Having your server verify every action is the only way to prevent hackers from simply sending a packet that says "I got a headshot on that guy". Instead the server replays through all their actions. You never say you got a headshot, you just say when you clicked and the server figures out if you hit. And because like you mention, clients only receive gameplay data and not the fully rendered screen, this allows clients to do things like interpolate the (delayed) server data with their own realtime input elements. Otherwise every single action you take would be delayed by whatever your latency is, and every other player's actions would be delayed by a similar amount. Instead, it appears seamless until your latency gets so bad that you just begin teleporting between positions because the server can't track you well enough (often called multiplayer rubber-banding). Instead (well designed) game servers run their own authoritative version of the game world and track each player's latency, and use that to replay the previous few ticks of the game when an input comes in from any player. So if you have a 100ms ping, and press "W" to walk forward, when the server receives your forward input it treats it as if you have been moving for 100ms already. Basically, saying every player shares the world model is incorrect unless you can set them all to the same latency. https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Lag_compensation https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... Edit: additional source, these gafferongames articles are a bit old (2004) but still extremely relevant. https://gafferongames.com/post/networked_physics_2004/ https://gafferongames.com/post/networked_physics_2004/ https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/ https://gafferongames.com/post/what_every_programmer_needs_t...

Impossible 7y ago

This isn't entirely true for most games, clients run world simulation for prediction and sometimes can make authoritative changes. Almost no multiplayer games are complete dumb terminals ,you'd end up with the same latency issues that Stadia has. Complex physics with high object counts can be difficult because synchronizing a lot of state is bandwidth intensive. Most games with lots of moving objects (RTS for example) use deterministic lockstep so only inputs need to be transferred, even if there is an authoritative server.

summerlight 7y ago

This is simply an incorrect statement. Even with a dedicated server, most games simply replay game logic with deterministic lock-step simulation based on ordered user input events. There's some exceptions, but (partial) state synchronization is tricky especially with complex physical interaction and complicates/limits game design with a huge amount of edge cases so it's not a wise choice unless you absolutely need to do this, like open-world or MMO games.

windsurfer 7y ago
What games are you talking about? For example, Natural Selection 2, Counter Strike GO, and Overwatch all do a full simulation of the world on the server, and the server is 100% authoritative. Clients are often running the same simulation locally to predict state despite network latency. Players also can experience packet loss or reconnect at any point and still have full state synchronization.