|
Arkaign said:
I never thought that game streaming was impossible, because the data involved is miniscule, and all calculations are done remotely. It's no different in many respects to me using PCAnywhere in the 90s over ISDN to support clients in Israel and Japan with remote desktop.
The key not wheather you think something is possible or not, the key would be if you are developing in this space and know if something is possible or not. Just because you do not have a reference wheather cloud based Physics works doesn't mean there are not may protoypes out there where the tech has been vexxed. This happens all the time with new implementation of software. At the software company I work for, customer have thought many things we have done is impossible because our competitors have not done it.
I also don't think you understand what I mean by async. Once you have a big event happening with a ton of pieces moving, all that has to be synced out between client and server, otherwise you have no real interaction with those objects possible without breaking the physics model.
In software, Async means that the client does not have to wait for the server to send back information. The client can continue to send info to the server and not have to wait for a response. The server can queue up those transactions and send they back in order to be process by the client. You can have async and schronous communication at the same time especially if the backend and front ends are designed for such purpose. I understand what you are saying its just that you only present a one sided solution which does not take into different client server implementations. Is this setup complex yes it is but thank goodness MS development a platform called Orleans to handle the complex interactions behind the scense. Orleans has been in development for over 3 years so my guess is that MS understand how complex such calculations can be and spent 3 years making it easy on the developer to code against such multi-threaded actions.
Let's get a decent basic hypothetical : you are playing a game where you control a player who can untie a ribbon and release hundreds of various size balls from the ceiling in a net. These balls vary in size and weight. Half of the floor is rubber, half linoleum. The graphics are all rendered by your console. Okay, pull the string, and everything tumbles down and starts bouncing. This is an event being calculated by the server, server tells the client where things are, client draws them. Now walk up and start bouncing the balls against each other. You are now changing the variables dramatically with every action, and that input needs to get back to the server, and there is no longer a 'set piece' in place, but rather a constant variable series of actions that all have immediate consequences. If there is lag, then the physics model won't appear realistic, or worse, it will fail to render and cause client side issues/glitching.
Thats a good scenerio but the key would be if the design of a game would go for such a dynamic situation for the cloud compute part. The client only needs to render the point of view of the person moving. Once you get beyound the person point of view, all other calculations can then be sent server side. Great thing is that information can always be sent to the server without the client waiting on a response. Data can be plugged in by the server once those calculations are made. You can easily dedicate CPU threads for just those purposes or with the X1, it already have dedicated hardware just for that purpose without having to waste CPU resources. Either way, the game designer has full control of what happens within their world. Having this control allows then to easily predict when to perform server side cal and when to do client side. What you are looking for is a scenerio where their is chaos but in reality, a game can be tighly controlled to not introduce those scenerios.
Does that make sense? Because a big set-piece action triggered by the user, but that is not interactive beyond the start/end of it, is useless. We can already do that locally. The bigger stuff, huge synchronous cloud to client and back physics events of a continually changing cycle : THAT is both what would be incredibly cool AND is ridiculously impractical.
We probably could argue this point all day. You really only show one side of a coin where they are multiple different solutions. I am more than willing to wait until MS give us the data on how them are implementing their solution. I have plenty of ideals of how they could go about the work but I hate making speculations when the data is really sparse at this time.
It bears repeating that dedicated hardware physx cards start having problems when they're moved from a bus of 2000MB/sec to one that is 500MB/sec. Moving that same physx engine to one that exists on 1MB/sec (8 megabit) is astonishingly unlikely to be impressive or effective.
So how do you explain the Build Demo
|
