Remote physics processing with asynchronous rendering in multi-user environments.

[NanoStuff]

The problem with the coming era of complex game physics is the disparity in the processing power of PC gaming machines.

Unlike the purely local issue of frame rate differences between clients, the differences in the simulation rate in the physics engine would cause synchronization issues in the state of the environment, therefore there seem to be limits in the complexity of local physics processing, requiring that it be suited for the lowest denominator so that sync can be maintained.

If however physics processing were to be done on a remote machine (game server), this would not only ensure synchronization, it would also result in great computational efficiency as the environment would only have to be processed once for all clients involved, which could potentially allow for incredibly thorough environments, only increasing in efficiency with more clients involved, perhaps even global particle physics of all materials for MMOGs with thousands of players involved.

The clients in this case would have varying update-rates which would allow for asynchronous rendering for each individual client to the extent their machine allows, and the state of environment physics would remain consistent regardless of frame-rate.

The catch here is that this would require very low latencies and very high bandwidth, but this seems to be well within reach in the near-future with optical networks.

 

[NanoStuff]

Actually, the concept can be applied to computing the entire environment, graphics, sound and all. The only problem with this is input latency, which would have to be extraordinarily good. 8ms within a radius of 1200km is conceivable, I'm unclear what the thresholds of perception for mouse input are, but it's probably less than even that. Perhaps some form of smoothing trickery can be applied here.

 

[Throckmorton]

Originally posted by: NanoStuff
Actually, the concept can be applied to computing the entire environment, graphics, sound and all. The only problem with this is input latency, which would have to be extraordinarily good. 8ms within a radius of 1200km is conceivable, I'm unclear what the thresholds of perception for mouse input are, but it's probably less than even that. Perhaps some form of smoothing trickery can be applied here.

I thought he was talking about calculating, for example, the path of a projectile or something on the server, and sending position data to clients in real time. Graphics wouldn't benefit because you'd have to calculate the graphics for each client, and then send it as video.

 

[Crusty]

Originally posted by: Throckmorton

Originally posted by: NanoStuff
Actually, the concept can be applied to computing the entire environment, graphics, sound and all. The only problem with this is input latency, which would have to be extraordinarily good. 8ms within a radius of 1200km is conceivable, I'm unclear what the thresholds of perception for mouse input are, but it's probably less than even that. Perhaps some form of smoothing trickery can be applied here.

I thought he was talking about calculating, for example, the path of a projectile or something on the server, and sending position data to clients in real time. Graphics wouldn't benefit because you'd have to calculate the graphics for each client, and then send it as video.

Not true, the server could do some basic geometry calculations for the clients like mapping out the landscape and adding in the dynamic objects. There would be no need for the servers to actually render if they can just relay geometry data to the client who would then render it with the correct textures and such.

The issue here is that you are offloading calculations from the client so you would need massive amounts of bandwidth and cpu power on the server end to make this possible.

 

[CycloWizard]

This is how some games used to be (e.g. CounterStrike in its mid beta versions). This had the added benefit of disallowing some cheats by requiring the server to perform movement calculations. However, by switching all of the player movements to the client, the latency was significantly decreased (by a factor of about 10 on LAN, going from a ping of 60 to 6, for example).

The method you're suggesting requires input from the player which, as you mentioned, depends on their latency. This input is then used to compute all of the information required (player/projectile positions and velocities). This output is then sent back to clients while new input is collected.

The other method (client-based calculations) can be approached in at least two ways. Both of these have been implemented in various games that I've played and can be very annoying in their own right, but they seem to be more consistent when playing against people with a large range of latencies. The first is that the client computes everything - movements, velocities, and even whether your shot hit someone based on where they are in your most recent snapshot from the server. The second is that the client tells the computer where you are and where your projectiles are, then the server tells you whether or not you've hit something. This effectively outsources the computation to the client while retaining some centralized control for the server, but has potential drawbacks.

The former method can result in very strange hit detection. If I have a latency of 300 ms and the server runs at 30 Hz (i.e. sends a snapshot every 33 ms or so), then I can potentially kill someone who is no longer there. In addition, I can kill someone, then they can kill someone else before the server knows that they're dead. The latter method removes this difficulty at the cost of increased latency. Both of these methods also have the drawback of making cheating relatively easy, since the client is reporting its position directly to the server. By fudging this data, the client can effectively move faster or aim strangely and the server can't necessarily pick up on this.

After all that rambling, I think there are a few things that you need to consider. To achieve what you've proposed, I think the bandwidth demands would be huge. The server would essentially send each client a snapshot of all particles in the entire game every time it updated their information. Computing the changes in these particles would be a huge load on the server, requiring a high-end system. This would in turn make the game catch on more slowly because people usually use their older systems for servers (at least in my experience), while their newest system is usually used to play the game. Using this system, the server would need to be much more powerful than the gaming system.

 

[NanoStuff]

Originally posted by: CycloWizard
To achieve what you've proposed, I think the bandwidth demands would be huge.

If the entire game state is sent on every transmit, the bandwidth would be huge, of course, but this could be compressed to only send changed data, which could potentially also be huge depending on the resolution of the particle system and the intended precision.

The more ideal option would likely be to just send a video stream, this would require substantially more CPU time but less bandwidth, but again, circumstantial. Eventually the processing time required to compress video on the fly will be negligible compared to the processing time of the game itself, which should make a video stream a more favorable option. The real delight of this approach is it would largely eliminate cheating, short of gaping game vulnerabilities themselves exploitable through network send data. The unavoidable issue remains that this would be limited to a radius of little more than 500 km.

Originally posted by: CycloWizard
Computing the changes in these particles would be a huge load on the server, requiring a high-end system.

That was merely an example of potential capability, the real point was that there is much efficiency to be gained computing things remotely. The game can be distributed on a grid server with a fairly consistent load throughout the day. When you pay for a high-end machine, all the time you're not gaming with it, you're wasting a lot of computing potential. Remotely, these resources would be much more consistently utilized.

But the lack of hardware utilization is just beans. The immense potential here is in the said particle system and global illumination. High quality real time rendering of this kind at a respectably high resolution would require Exaflops of processing power, at minimum, but the gorgeous aspect of this approach is that once the scene is illuminated, it's illuminated regardless of the viewing position, unlike typical rasterization. If you have 10,000 clients connected to a certain environment, in this regard you've effectively improved processing efficiency 10,000x, it only has to be done once. The more clients, the merrier. Inconceivably spectacular multiplayer environments could be achieved economically, with what will certainly be a subscription model. If that's not enough, it completely eliminates the potential for piracy.

 

[Nathelion]

Seriously though - I can tell the difference between playing with a wired mouse and a wireless one. How am i supposed to put up with the data traveling all the way to a distant server and back before i get feedback on my input?

 

[NanoStuff]

Originally posted by: Nathelion
Seriously though - I can tell the difference between playing with a wired mouse and a wireless one. How am i supposed to put up with the data traveling all the way to a distant server and back before i get feedback on my input?

The reason your wireless mouse is slow (and I agree, I've used one too) is largely a result of delays in the resonator assembly. It's certainly not because the the signal is moving through the air very slowly. If the range of your mouse was extended by hundreds of kilometers, it would not be perceptibly slower than it is now.