Ignoring for a moment all the who pay for it, and what it actually is discussion.
Since this is an interesting mental exercise If I were tasked to write a game or for that matter a demo that utilized the clouds compute performance regardless of vendor this is what I would try. Bear in mind I'd never try and do this in a title I'd expect to ship anytime soon.
Let's put latency in perspective for a moment, out of interest I just pinged my ISP, that's a roundtrip of an ICMP packet taking roughly 19ms, assuming MS's servers are "local" (i.e. located in the same region you'd have similar latency). Now my internet connection is far from great (11Mbit ADSL) but it is probably very slightly above the baseline you could target to hit the bulk of the US, but we'll go with it for now.
Now if I take the 3x the CPU performance in the cloud at face value, and we recognize the extremely limited per frame bandwidth. the first thing I'd try given that 20ms number is running the entire game in the cloud and keep all master game state there including the player, if I can get the time from controller packet to player state update response down to 50ms or less I'd probably persue it.
I've shipped action games with latencies >70ms controller to screen, so it doesn't seem impractical to me.
The next issue becomes prioritizing data from the server and how I deal with frames without data, or the quality of my prediction algorithm. The tendency for more recent multiplayer solutions is to run the same simulation on both ends, but your trying to reduce host side computation, so you'd probably try and do something simpler. You can run the simpler prediction algorithm on the server as well and determine the error the client is seeing, using that to prioritize what updates are sent per frame.
You can afford to run a somewhat simpler prediction algorithm because you have more bandwidth than in a typical P2P multiplayer game where the bandwidth is limited by the upstream bandwidth of the server.
The advantage with keeping everything on the server is everything can interact with the player, the danger is that the quality of the prediction is too low and the experience suffers. I suspect this would be the most difficult balancing act to get right.
What about events that create meshes or change textures?
My first thought is I'd run them at both ends, all I need is to ensure they are deterministic and a way to assign the same object ID's on both ends if they continue to be interactive after creation.
what about Animation that continually deforms meshes like cloth etc?
I'd probably run them locally, but I'd do the math first I suspect that data is highly compressible, either way there would be some limit based on the available bandwidth.
What do you get out of it?
I think the only way to get good utilization out of the cloud is to avoid the bandwidth issue altogether and just run the game there.
Short version is I don't know and I'm not sure you end up with significantly better experience. Your offloading all of the gameplay work to the cloud, including at least rigid body physics, but you'd probably still end up having to animate skeletons locally, and that's a significant cost.
Latency is increased, so it's possibly not a great fit for games that need very low latency like shooters, though since everyone has the same disadvantage it might not actually be as bad as you might expect.
You could probably run 1 or N players in the same environment with minimal additional effort.
I think it would come down to how CPU dependent the game is, but I also suspect that starting with a premise like this would encourage using more CPU.
Of course there would be no offline play and even degradation of the link would likely cause degradation of the experience.
Perhaps a variation on this is that you could run the game on both ends and split ownership so the cloud runs the game say 50M from the player, so if something blows up in the distance, it's coming from the cloud, if it blows up in front of you it runs locally. This resolves the latency issue to some extent. It adds complexity because you have out of date state for parts of the world on both sides of the link and you have to negotiate the ownership handover. Though the more I think about it the more I think it's feasible.
The alternative is to take the low hanging fruit, I think there is probably a fair amount of this to be had like incrementally updating light probes but I think even with a number of tasks like this you'd be grossly underutilizing the 3x resources claimed to be available in the cloud.
I think all of these ideas are interesting technical challenges.
Now all I need is someone to pay me a lot of money to prototype all this,
Since this is an interesting mental exercise If I were tasked to write a game or for that matter a demo that utilized the clouds compute performance regardless of vendor this is what I would try. Bear in mind I'd never try and do this in a title I'd expect to ship anytime soon.
Let's put latency in perspective for a moment, out of interest I just pinged my ISP, that's a roundtrip of an ICMP packet taking roughly 19ms, assuming MS's servers are "local" (i.e. located in the same region you'd have similar latency). Now my internet connection is far from great (11Mbit ADSL) but it is probably very slightly above the baseline you could target to hit the bulk of the US, but we'll go with it for now.
Now if I take the 3x the CPU performance in the cloud at face value, and we recognize the extremely limited per frame bandwidth. the first thing I'd try given that 20ms number is running the entire game in the cloud and keep all master game state there including the player, if I can get the time from controller packet to player state update response down to 50ms or less I'd probably persue it.
I've shipped action games with latencies >70ms controller to screen, so it doesn't seem impractical to me.
The next issue becomes prioritizing data from the server and how I deal with frames without data, or the quality of my prediction algorithm. The tendency for more recent multiplayer solutions is to run the same simulation on both ends, but your trying to reduce host side computation, so you'd probably try and do something simpler. You can run the simpler prediction algorithm on the server as well and determine the error the client is seeing, using that to prioritize what updates are sent per frame.
You can afford to run a somewhat simpler prediction algorithm because you have more bandwidth than in a typical P2P multiplayer game where the bandwidth is limited by the upstream bandwidth of the server.
The advantage with keeping everything on the server is everything can interact with the player, the danger is that the quality of the prediction is too low and the experience suffers. I suspect this would be the most difficult balancing act to get right.
What about events that create meshes or change textures?
My first thought is I'd run them at both ends, all I need is to ensure they are deterministic and a way to assign the same object ID's on both ends if they continue to be interactive after creation.
what about Animation that continually deforms meshes like cloth etc?
I'd probably run them locally, but I'd do the math first I suspect that data is highly compressible, either way there would be some limit based on the available bandwidth.
What do you get out of it?
I think the only way to get good utilization out of the cloud is to avoid the bandwidth issue altogether and just run the game there.
Short version is I don't know and I'm not sure you end up with significantly better experience. Your offloading all of the gameplay work to the cloud, including at least rigid body physics, but you'd probably still end up having to animate skeletons locally, and that's a significant cost.
Latency is increased, so it's possibly not a great fit for games that need very low latency like shooters, though since everyone has the same disadvantage it might not actually be as bad as you might expect.
You could probably run 1 or N players in the same environment with minimal additional effort.
I think it would come down to how CPU dependent the game is, but I also suspect that starting with a premise like this would encourage using more CPU.
Of course there would be no offline play and even degradation of the link would likely cause degradation of the experience.
Perhaps a variation on this is that you could run the game on both ends and split ownership so the cloud runs the game say 50M from the player, so if something blows up in the distance, it's coming from the cloud, if it blows up in front of you it runs locally. This resolves the latency issue to some extent. It adds complexity because you have out of date state for parts of the world on both sides of the link and you have to negotiate the ownership handover. Though the more I think about it the more I think it's feasible.
The alternative is to take the low hanging fruit, I think there is probably a fair amount of this to be had like incrementally updating light probes but I think even with a number of tasks like this you'd be grossly underutilizing the 3x resources claimed to be available in the cloud.
I think all of these ideas are interesting technical challenges.
Now all I need is someone to pay me a lot of money to prototype all this,
