The Xbone

[Zeph]

I said potential. Right now, it's not practical to offload heavy, time-sensitive stuff. That will change in the future as broadband gets better. What you can stream at this very moment, however, would be the level geometry itself. Textures can get processed on the box since that's what you really see, while the mesh can be calculated remotely. Perhaps skyboxes, or NPC interactions. How about storing all of the markers that are necessary to maintain a large, persistent world? Heck, Microsoft may not even know everything that they can do with the servers and Azure yet, it's there partly so developers can explore this new resource.

And the PS4 does not have that much of a hardware advantage. It just doesn't. Yes, it has more stream processors, but the GDDR5 advantage is made up for by software tomfoolery on the Xbone. I really don't think multi-platform games are going to look any better on the PS4 than they do on the Xbone.

Nonononono. You would never want to run anything that directly affects a local simulations each frame.

The cloud is such a bullshit term.

This is a server and nothing more. You want to use it for player versus player interaction and that's about it. Single-threaded capability on these servers are going to be the most power-efficient thing microsoft can afford to maintain. I'm actually surprised they're considering using some of them for on-demand dedicated servers for various games.

[Warsaw]

The games that use it for more than multi-player server hosting will be akin to MMOs. They'll have a disclaimer on the box making it clear to the player exactly what it is. As long as you know what you're getting into, I don't see a problem with this. I am a pretty anti-cloud person, but you'd have to be blind to ignore the benefits; it's rather disingenuous to only preach about its pitfalls.



I also fail to see how static level geometry affects a local simulation each frame if it doesn't even move. All you need to know is that there 's terrain there so your collisions interact properly. NPC interactions, i.e. Mass Effect conversations, don't really have a time demand, and a skybox does nothing but look pretty...

[Btcc22]

They might not have a 'time demand' but they don't have a computational demand either, therefore making them pointless to process remotely.

[Warsaw]

That is not a true statement. If it were, then polygon counts wouldn't matter.

[Btcc22]

That is not a true statement. If it were, then polygon counts wouldn't matter.

It wasn't supposed to be taken literally, like with your time demand statement. The point is that there's no benefit to streaming geometry over the Internet that I can see. I didn't understand the comment about skyboxes and calculating meshes remotely.

[Skyline]

If it were, then polygon counts wouldn't matter.

They only matter for the actual rendering, which happens 60+ times a second and is done locally on the GPU so I still fail to see how the cloud would be of benefit.

[Zeph]

The games that use it for more than multi-player server hosting will be akin to MMOs. They'll have a disclaimer on the box making it clear to the player exactly what it is. As long as you know what you're getting into, I don't see a problem with this. I am a pretty anti-cloud person, but you'd have to be blind to ignore the benefits; it's rather disingenuous to only preach about its pitfalls.



I also fail to see how static level geometry affects a local simulation each frame if it doesn't even move. All you need to know is that there 's terrain there so your collisions interact properly. NPC interactions, i.e. Mass Effect conversations, don't really have a time demand, and a skybox does nothing but look pretty...

Simulation-level stuff (ie your physics colliders, render geometry (arguable, but depends on specific engine architecture and game's design), game code that directly interacts with those two prior things such as weapons fire checking what material was hit for particles/sounds/hit info/etc) would be hung up on the latency to obtain a serialized version. Even if you had amazing ping (less than one millisecond), that ping would take up a significant fraction of a frame. If you get to more accurate pings (especially in the united states) where a good low ping is 33ms or lower (lets be reasonable here it's usually somewhere under 200ms) then you've waited the equivalence of two 60Hz frames for your serialization.

Networked game code that doesn't affect the simulation frame by frame would be fine since you can predictably handle latency. So your 'ME conversations' query to the server to see "what's hot and what should be talked about like cool hip dudes" would be fine since you can check frame by frame if a pointer to the data is valid yet without breaking anything on the simulation side. If you 'start the conversation', you ask the server for the conversation. While you're waiting to see if you even get a response, you can have the simulation carry on without any worry.

Titanfall managed to get away with AI-bots(autopilot Titans) in their game because their gameplay completely relies on a server authoritative method to serialize everything. Want to walk forward? Server says that's fine. Want to walk more forward? Well, server says that you're running into a wall at this position, but you can keep trying. DayZ would work fine, considering it completely relies on the server for persistence. WoW or EVE would be fine as well.

[Warsaw]

Titanfall's server-authoritative method is the only way this hybrid cloud is going to work.

They only matter for the actual rendering, which happens 60+ times a second and is done locally on the GPU so I still fail to see how the cloud would be of benefit.

A better way to look at it would be that your avatar is remotely controlled by you via the internet in the remotely calculated environment, and the console renders the textures or other bits that would be really hard to transmit over an internet connection without issues such as excessive popping. All the console is doing now is effectively drawing a matte painting over top of what would otherwise be a grey clay render (if even that) using the information contained in the packet to set the boundaries. It's not doing 3D. It doesn't have to figure out what the player's position is, where the lights are; it simply gets told all of that and executes the texture, which will be stored locally as a base and modified according to the lighting information received. Voxels might actually be a good fit for this, using the cloud information as a sort of skeleton to be magnetically attached to by the local hardware. Glorified pixel art, but damn pretty pixel art.

This may not work for fast-paced games at first, but that doesn't matter because not all games are fast-paced. They are not even all shooters.

This is, really, all uncharted territory. Even Microsoft themselves said they are excited to see what uses developers come up with for their new cloud services. I don't expect any current engine technologies to really be flexible with the cloud system. What I described above is most definitely not a conventional raster engine.

[Zeph]

That's not how it works with games now and would actually be a step back.
It's pretty much all or nothing.
Commit everything to the cloud (onLive failed miserably btw) or keep it to the local client.
It's not about where the processing power is, it's about how long away it is. That time is crucial.
OnLive got its funding as an IPO only because of their strict testing environment which pretty much equated to requiring your ISP to have direct backbone access to where their datacenters were.


Learn some cpp and start digging into an engine to get a better idea of how a game actually runs. Unity or CE3 should do.
As it stands, you say cloud without really comprehending the mechanics behind it.

[Warsaw]

Wall-o-text incoming:

Microsoft's new XBL cloud is a large number (300,000+) of servers using the Azure framework (I assume you know what that is) that are used to host your typical XBL features but are supposedly also capable of doing pretty much anything the developer asks Microsoft permission to do, i.e. streaming content. Events need to be synchronized between client and server, and you need a system in place to make the effects of latency invisible to the client; this generally involves compression and minimizing the amount of data that needs to be transmitted and synchronized by choosing what gets computed where. OnLive chose to have everything about the game computed on their side so all the user received were the audio and video streams while all OnLive had to receive were user inputs and ID checks. What Microsoft is proposing is that developers can split the computing task between two machines by intelligently choosing which tasks are capable of being done remotely with minimal impact by latency.

Did I miss anything? It's straight-forward enough. There are all those details of what to store where, which side performs what task, but that is all dependent on the task you are trying to perform.

I'm familiar with C++ and Python by necessity (yay school), enough to be able to follow what I'm looking at, though it's not my forté. I actually do understand the basics of how a current game works and is drawn; what I'm getting at, though, is that what you know about how a game currently works is not necessarily applicable to a game tailored to a hybrid remote-local computing solution. You could all but forget things like LOD if you offload to the remote render farms: you have your geometry calculated and rendered remotely with identifiers so your machine knows which textures to employ where and with what lighting so it can paint by numbers when it receives a video feed. It's 3D on the server's end, but all your machine is doing is largely 2D work. By removing the colour information from the transmission, you cut down on packet size; you could even let the 3D world have a low resolution and use the identifiers and 2D painting to mask it with the player none the wiser. It's a new concept (and I may actually have it backwards with which side does what), and that's really what makes this exciting: it's new territory. There is nothing on the market, to my knowledge, that can currently take advantage of this hybrid solution out of the box. Microsoft doesn't even have a system in mind, though it was them who said that it was capable of letting developers use their servers to offload some of the work. And, what's even better, is that what they suggest we can do with it now is not going to be all we can ever do; the console hardware is stuck at what it is while internet connections and the Xbox Live back-end can and will be constantly improving.

Really, the Xbox One is a much more exciting package than the PS4. Sure, Sony could theoretically do all of the above but from what I've read, they don't already have the software and hardware infrastructure in place to do anything like what Microsoft is suggesting the Xbox One can do. I, like you, prefer to have my games all rendered and stored locally, but that doesn't make the potential any less cool. Yes, it's more efficient to render everything server-side, but I think the hybrid idea they are putting forth is a way to get around the supposed bandwidth issue (also local storage/horsepower issues) and to slowly ease people into a world where all of their software is provided as a service. While I'm appalled at the latter thought, the former is neat.

By the way, OnLive also didn't really fail because of bandwidth issues (I tried it, it worked just fine), it failed because it didn't offer people anything that they couldn't already do at a price that made it worth switching. It wasn't convenient enough. Anybody who could afford a sub to OnLive, and didn't want to play on the PC, had a console already and with a larger library of games and no requirement to pay a recurring fee. It could have had a promising future on handheld mobile devices if carriers didn't all price their data rates through the stratosphere; I would have subbed for that (though I'd rather be able to stream games from my already capable home PC) and I loathe subscription-based business models.