Server based game augmentations. The transition to cloud. Really possible?

We could think of it like 'the Cell'. On launch the performance may not be relevant at all but by the time we reach 2nd or 3rd generation games in 2-4 years time we might see a major difference. In a couple of years for instance a lot of places will have been upgraded to 30-100Mbps fibre-optic as Europe, Asia, Australia, New Zealand etc roll out their fibre networks. In 2015 I will have a 100Mbps fibre-optic connection so they could probably do a lot given time to develop the software and roll out the hardware.

 

But the result of the non immediate results should be immediately be used in

You are going through a building in BF or just entered a building, but turns out the building was already destroyed in server perspective.

So in order for this to be used, you must have result of non immediate result that will have no immediate result back to gameplay.

Tells me this is very limited.

 

So after everything I've read in this thread I wonder if it is safe to say that a really cool and realistic application of cloud would be hyper realistic non interactive scenes,in other words evolving wallpapers. Imagine a hyper realistic always growing and changing aquarium or forest scene instead of a loop or loops. Or is that something already possible by simply being connected to a regular server?

 

Not really i'd say

 

Not really possible with regular server or cloud?

 

Either

Though i think i may be misunderstanding the question, ignore me

 

Well if people are making the case that interactive games can be enhanced by cloud,I would think something non interactive would be even easier.
It may not be as sexy as a game,but there could be a market.

 

I definitely misunderstood lol.

For something non interactive you would be best off doing all the processing in the cloud ala Gaikai, without interaction you could stream the same instance to millions with a single render. If there was a market for that type of thing id say it would be pretty feasible from from a business perspective

 

You are assuming that nothing happens between you plant C4 and it explodes. What if aerial bomb strikes the building?

 

So sum it up.

Input needs to be small.

Output needs to be small.

Cannot require immediate result.

Only thing I can think of is pre baked effects which again can be done on local hardware during loading anyways.

 

http://gafferongames.com/2010/03/11/gdc-2010-networked-physics-slides-demo/

Seems relevant to certain parts of discussion.

 

You might run a cheaper local animation instead.

The idea is to offload computationally expensive problems that are not quite so latency insesitive they could be done during loading.

 

like music,decryption, and decompression.

Background effects(volumetric particle physics like sandstorms,rain,steam,smoke,snow,and other weather)

 

Then it's not my C4 demolition game anymore
It's true that if i plant my C4, send the calculations to the cloud then my game would have to be static until it explodes. If i moved in front of the building, someone else planted a C4 in the meantime, a truck parked in front of it, a player went into the building, someone ordered an airstrike, etc etc the original calculations would be wrong.

 

Can you clarify if you mean that decryption and decompression can be offloaded to the cloud server?
The first issue is that consoles will have some decent dedicated hardware and instructions for decryption and decompression, and the second is that data transactions over the internet should be compressed and possibly also encrypted.

 

That isn't a necessary assumption. The output results of the physics-based animation/destruction can still affect the player, just not vice versa. That's why I stuck to larger scale events which in the real world would barely notice some tiny human/tank/etc getting in its way. The player/tank/jeep/etc itself could still react to large scale debris that collides with it based on the local physics. That debris just wouldn't be slowed by the impact which, for large scale events, is realistic anyhow.

The cloud-computed physics-based anims are just for the static environment as is. For anything that you'd be able to drive or park in front of it clearly that's already fully interactive and handled locally. As such, when the animation plays out as the building collapses and all the previously-static bits of the structure fly around your player/tank/jeep/etc can still "feel" that since their physics modeling is handled locally. In other words you should be able to have the collapse hurl the player/jeep/etc around when concrete bits or i-beams or whatnot hit them, but those interactive, dynamic elements can't influence the collapse anim itself.

Not sure if I'm explaining what I am envisioning very well.

Player triggers avalanche. Avalanche is a huge, dominant physics effect that isn't significantly affected by player state once triggered. Avalanche computed in cloud, sent to console. Player can be swept along with the avalanche because reaction to such moving objects can be handled locally.

Are you certain about the last part? I've speculated on that for a while now and most ppl have asserted I was wrong for no real good reason.

 

Thanks all of you, I think that makes even more sense - that way, the two side-by-side OS's each can have their own resolution.

I would expect though that scaling is supported per plane as well, but it hardly matters - if each layer can have a different resolution, then by definition the output being just one framebuffer for your TV, everything will have been merged to one target resolution.

Avalanche is an interesting idea.

@keenism: thanks for the link. You're pushing the discussion into an area where on this forum it deserves to be. It's interesting though basic actual testing of the waters for 'co-operative' physics rendering. There are some limitations that are discussed in the comments, but I think if say, 16 players are playing together and all contributing to a large physics interaction, it could potentially benefit a lot from having those calculation interactions all being done server-side, on the same Microsoft server-farm.