Jonathan Blow: Microsoft's Cloud/Server Claims Are Lies

[DiamanteGeeza]

Well, noone claimed Cloud gaming will improve graphics to begin with.
Physics, AI, Offsite calculation - sure. Graphics - not possible. You can imrpove graphics offsite if tyou stream them, but thats not clouding.

So, essentially we have somebody calling out MS on being rather economical with the truth in a PR reveal, but doesn't have any evidence, or even tech knowledge to back it up.

It's like a dick measuring contest, but then with bullshit.

His last name is "Blow". Acting like a dick is predetermined.

Seriously; cloud computing will never enhance game play, it will only slow it down. Don't believe, how laggy do things get when you're on a 20 man raid in WoW? How much does your fps drop?

Nopt sure about WOW and thier programming sincei dont play one, but in other games i often run with a pack of 30 to 200 people and experience no lag-jumps or what is popularly called "rubberbanding".
FPS drops are solely based on your computer calculation - your computer cant manage to calculate that much. if anything Cloud gaming would help with exactly that - FPS drops. your attacking it from a wrong angle mate.

No, actually your frame rate can drop thanks to data transfer, too. Online games do as much prediction as they can while they're waiting for either other player's input data or actual positional information, but it reaches a point where the game (especially one as in the original poster's scenario - a 20 person team in WoW) just doesn't have the information required to predict any more - for whatever reason it has been starved of data, and it has to stall and wait for some solid data before processing can continue. The amount of impact this has depends hugely on the type of game that's being played, of course.

There's also the scenario where the more players you have in a party, the larger the lump of data that will be sent to each person's machine in the group. Depending on how the online architecture is set up (peer to peer, client/server, etc.) also has a bearing on possible frame rate hits on large groups. The larger the group, the more stuff will be going on (people moving, shooting, blowing stuff up, all generating lots of particles, physics objects, and collision events, and all of this, depending on where the processing for that is done, has an impact too.

(To address your first point as well, you can't do physics or frame-critical AI in the cloud. The latency on the round trip is too high and your game would be running at about 1 frame per second while it waited for object position data to be sent back!)

 

[Strazdas]

You can't offload any work that is frame critical, such as physics or rendering. The round trip latency for the data is just too great, even with a very good internet speed, and a close proximity to the server farm. You're looking at a minimum of 100ms round trip, which would destroy your frame rate.

Any processing done in the cloud cannot be game or frame critical. Simple as that.

You cannot offload rendering. I never claimed otherwise. You can offload Physics calculation, remaining the movement factor to be information recieved by the client. World of Tanks recently did server-based physics. They are not working on a hybrid where part of physics wil lbe calculated at user side and part at serverside because its a large strain on their servers as now they take most of the calculating load and thus they cant add all the physical structures they want (like turrets flying off from explosions).
Well, WOT seems to handle it with pings as low as up to 17ms. OF course thats server calculation and not cloud, cloud would add extra latency because my game would have to wait for somone to send his calcualtion results via his dialup from congo.

No, actually your frame rate can drop thanks to data transfer, too. Online games do as much prediction as they can while they're waiting for either other player's input data or actual positional information, but it reaches a point where the game (especially one as in the original poster's scenario - a 20 person team in WoW) just doesn't have the information required to predict any more - for whatever reason it has been starved of data, and it has to stall and wait for some solid data before processing can continue. The amount of impact this has depends hugely on the type of game that's being played, of course.

There's also the scenario where the more players you have in a party, the larger the lump of data that will be sent to each person's machine in the group. Depending on how the online architecture is set up (peer to peer, client/server, etc.) also has a bearing on possible frame rate hits on large groups. The larger the group, the more stuff will be going on (people moving, shooting, blowing stuff up, all generating lots of particles, physics objects, and collision events, and all of this, depending on where the processing for that is done, has an impact too.

(To address your first point as well, you can't do physics or frame-critical AI in the cloud. The latency on the round trip is too high and your game would be running at about 1 frame per second while it waited for object position data to be sent back!)

No, render rate cannot drop due to slow data transfer unless you transfer render data, which noone does. It stops and waits for response, which is lag, but this does not affect your actual framerate. dont confuse lag caused by ping and lag caused by slow hardware.
The more particle effects generation is a fair point, however this has nothing to do with internet speed but rather with how the game engine is set up and if it can handle many particles at once or not.

 

[Lieju]

Okay, I don't get why so many people are hating on his comments here.

He's just saying 'Yeah, that sounds like BS to me, someone who knows more about this stuff should probably look into it.' over Twitter. Which is what everyone with even some knowledge on this stuff is saying.

It's not like he's putting on a press conference refuting Microsoft's claims or something. MS made claims, he is saying he's not convinced.

 

[DiamanteGeeza]

You cannot offload rendering. I never claimed otherwise. You can offload Physics calculation, remaining the movement factor to be information recieved by the client. World of Tanks recently did server-based physics. They are not working on a hybrid where part of physics wil lbe calculated at user side and part at serverside because its a large strain on their servers as now they take most of the calculating load and thus they cant add all the physical structures they want (like turrets flying off from explosions).
Well, WOT seems to handle it with pings as low as up to 17ms. OF course thats server calculation and not cloud, cloud would add extra latency because my game would have to wait for somone to send his calcualtion results via his dialup from congo.

I can't speak about World of Tanks... never played it, so I can't comment. But, I can tell you categorically, as someone who's been developing video games for decades, you can't process anything that is frame critical - and let me clarify what frame critical means... it means you need the result of the calculation before you can render the next frame - anywhere other than locally if you want to maintain a stable frame rate of 30fps or above in any type of remotely fast paced game. Take a driving game, for example, if you send your inputs off to the cloud, and wait to get the resolution of the rigid body solver back from the cloud before rendering the frame, the game will be running at single digit frame rates if you're lucky, and the frame rate will vary wildly between frames as the latency on the data rate varies. Same with shooters (especially something running at 60fps like CoD)... if you wait for the physics on the player to be computed on a cloud before rendering the frame, you won't be anywhere near 60fps. And, of course, you can't defer calculations like these because you need to update object positions prior to rendering the frame. The same goes for collisions if the result of the collision is required prior to rendering the frame, which of course they typically are.

No, render rate cannot drop due to slow data transfer unless you transfer render data, which noone does. It stops and waits for response, which is lag, but this does not affect your actual framerate. dont confuse lag caused by ping and lag caused by slow hardware.
The more particle effects generation is a fair point, however this has nothing to do with internet speed but rather with how the game engine is set up and if it can handle many particles at once or not.

We're not talking about the length of time it takes to render a frame. We're talking about frame rate, which is a different thing altogether. Perhaps, not being an engineer, you're not quite understanding what FPS is...? If your game has to wait 100ms for a lump of data to arrive before it can render the frame, it doesn't matter whether you can render the entire frame in 1ms (you can't), because you've just had a delay of 100ms on top of that. Bang, your frame rate drops drastically. Frame rate is the TOTAL amount of time required to update and render a frame. If you're busy sitting waiting for some data from a server, that will affect your frame rate. And lets not forget: 16.66666ms is all you have to run at 60fps, 33.33333ms is what you get to run at 30fps.

Once again, with the particles, you're not quite understanding how game traffic works when an external cloud is involved. In your scenario of offloading it all to the cloud, if there are 20 people all blasting away with rocket launchers and blowing stuff up, the explosions will probably generate debris and particles. Every single client in the game will need to be told of the creation of these particles by the cloud (which increases the amount of data being sent... delay number 1), then each client has to create their own version of these particles and objects in their local simulation of the world (delay number 2), and then they all need to be rendered in the next frame (extra polys to process and render = delay number 3). And, of course, if all calculations are being done in the cloud for these particles (as in your scenario), the local client can't render the next frame until they've been notified of all the new particle positions. The more data this becomes, the longer it takes to transmit it, so you can see how this all adds up as the number of players increases, and this will, in turn, hit the frame rate. And now bear in mind that if you get a round trip to and from the cloud in less than 50ms you're doing really well, that would put your frame rate around 15fps - in the real world it would be less than this, because even if you have a speed of light connection to the cloud, you're at the mercy of the slowest client that's connected - the cloud can't send you a new update packet until it has all other clients' input data and has done a full processing update. This is why the best way to handle a situation like this is to have the arbiter (whether that be a server or the cloud) inform the clients that something has blown up, and the local client decides what debris it can handle (bearing in mind everything else that is in view on that particular client) and will process all physics and collision locally to avoid a synchronous reliance on the arbiter.

I'm not sure how many client/server or peer-to-peer network engines you've written, but I've written quite a few over the years, and they are complicated beasts. Keeping as much processing as is humanly possible local to the client removes a considerable amount of frame-lock reliance on the cloud/server.

 

[Gatx]

Don't we hate this guy for some reason? Should we listen to him?

Actually no, people don't have a reason to hate him. I haven't seen any reason that is more valid than my subjective 'dislike' of game development houses that don't cater to my platform of choise or people that I don't understand.

There, I said it. People hate him because they don't understand him. Not that I try to defend his words, in many cases he has a vastly different view on the whole gaming genre than most people do but fuck, more often than not people clearly don't get what he is saying.

My problem with him is that he made an "artsy" game, and as with other works of art, people started analyzing it and giving their own interpretations about what it meant. He then proceeded to go around and tell people that their interpretations are wrong.

That said I don't have a problem with what he's saying right now though.

 

[Strazdas]

I can't speak about World of Tanks... never played it, so I can't comment. But, I can tell you categorically, as someone who's been developing video games for decades, you can't process anything that is frame critical - and let me clarify what frame critical means... it means you need the result of the calculation before you can render the next frame - anywhere other than locally if you want to maintain a stable frame rate of 30fps or above in any type of remotely fast paced game.

Physics are not frame critical then. you can calculate physics for multiple secons ahead in current games. epecially when one physics effect does not do anything to the other (for example a splash of explosion does not effect physics of a building nearby it being a static model).

Take a driving game, for example, if you send your inputs off to the cloud, and wait to get the resolution of the rigid body solver back from the cloud before rendering the frame, the game will be running at single digit frame rates if you're lucky, and the frame rate will vary wildly between frames as the latency on the data rate varies.

thats assuming pings above 100 ms, but fair enough many people still have that.

We're not talking about the length of time it takes to render a frame. We're talking about frame rate, which is a different thing altogether. Perhaps, not being an engineer, you're not quite understanding what FPS is...? If your game has to wait 100ms for a lump of data to arrive before it can render the frame, it doesn't matter whether you can render the entire frame in 1ms (you can't), because you've just had a delay of 100ms on top of that. Bang, your frame rate drops drastically. Frame rate is the TOTAL amount of time required to update and render a frame. If you're busy sitting waiting for some data from a server, that will affect your frame rate. And lets not forget: 16.66666ms is all you have to run at 60fps, 33.33333ms is what you get to run at 30fps.

The processing if powerful enough happens way bellow those marks though. for most renders anyway. (lets ignore consoles being stuck on ancient technology for a second). 33 MS is still enough for a render and a signal if the render is, say, happening in 15 MS, which on some machines do for almost all games. granted you need powerful machine to render everything at that speed, but if the machine only has to render 10% and another 10% is rendered by another machine it does the job much faster. well maybe i shoudl say calculate and not render since render is done locally anyway.

Once again, with the particles, you're not quite understanding how game traffic works when an external cloud is involved. In your scenario of offloading it all to the cloud, if there are 20 people all blasting away with rocket launchers and blowing stuff up, the explosions will probably generate debris and particles. Every single client in the game will need to be told of the creation of these particles by the cloud (which increases the amount of data being sent... delay number 1), then each client has to create their own version of these particles and objects in their local simulation of the world (delay number 2), and then they all need to be rendered in the next frame (extra polys to process and render = delay number 3).

and you need to do that once. and your fine for the whole particle effect to last multiple seconds. Yes it will cause a single freze of say 100ms once. But thats because our machines are not powerful enough yet to make it smaller. Or rather, they are but people dont get acess to.

The more data this becomes, the longer it takes to transmit it, so you can see how this all adds up as the number of players increases, and this will, in turn, hit the frame rate.

Technically - yes. Practically the bandwitch of our cables in comaprisong to how much data is being transmited by online gameplay in current games would allow us much higher data amounts without extra delays.

This is why the best way to handle a situation like this is to have the arbiter (whether that be a server or the cloud) inform the clients that something has blown up, and the local client decides what debris it can handle (bearing in mind everything else that is in view on that particular client) and will process all physics and collision locally to avoid a synchronous reliance on the arbiter.

and that is why we have dedicated servers that does the calculations for us, so we wouldnt need to rely on the slowest machine. of course clouding would render that away which makes your point valid.

 

[Lightknight]

It's funny how people seem to hate Jonathan Bow for saying this. He's saying the exact same thing as the rest of the internet. But he's not anonymous. He has a face so he can be hated. Fuck that, I agree with him.

Same here. He might be "allied" with Sony, but that doesn't make him any less wrong. It doesn't take a technical genius to see that Microsoft is spouting bullshit and that someone (who is a tech genius) should call them out on it.

Why would it take a technical genius to prove that? Blow stated that he himself could produce 10,000 servers and they'd suck. There's nothing that indicates Microsoft can't produce 300,000 servers.

It's not that they're lies, it's that they're misleading to the point of practically being nonsense. I build and blow away virtual machines nearly every day for testing. Servers, client machines, new and old environment types, all of that. 300,000 machines is saying nothing because the amount of RAM, the CPU type, and even disk space are all things I can completely control and may suck or be fine. If you found out that they were making a server farm of 300,000 pre-color gameboys would you think that number matters? Probably not.

It's like me telling you that I have one computer to sell you for $900 but I refuse to tell you anything more than the fact that it is a computer. I'm not lying in this hypothetical scenario, I do have a pc to sell you. But the deception or misleading part is that it could be an old Pentium 3 that barely works or it could be one of the latest and greatest i7 machine with everything cutting edge to go with it. Microsoft is doing that in such a way that is indicating that it's a good thing without giving real details. Total misdirect.

If you really want to complain about cloud computing being used to augment video games, you should do it in another way. This isn't just requiring always online while you're playing solo player games, it's requiring a decent internet connection that can upload and download data in a manner that could potentially make a solo game more internet demanding than first person shooters. The number of people who do not have the infrastructure for this could be extremely significant since it takes a step beyond the people who don't have a reliable connection. It also means that every game created in this fashion will die the day that those servers go down unless special provisions are made. So these games would cease to exist for our children and grandchildren. If the average infrastructure proved capable of handling this load in a timely manner then it'd be feasible. But if anything happens and your internet can't handle it, we're facing a future of lagging single playing games that have no business lagging.

What's more, there's not necessarily a reason to require cloud processing. It will just be used as an excuse to require always online gaming. We already saw EA trying to pull that shit with Sim City and they got caught. But the truth is that this is the crutch publishers were hoping for to force a kind of DRM on consumers that they know we wouldn't go for without a legitimate reason. Shame on them.

As for the processing bit, with the appropriate internet speeds and network set up, it is entirely viable. Sony did a less upload/download intensive version of this with their folding at home project where ps3's all over the world did the processing. But real time processing and responses is a trickier problem. It really all comes down to the amount of latency it would cause as to whether or not it's worth having. I don't know that we could prove or disprove it as feasible until we have an actual example of it: A game that demands a significant amount of remote processing and a reasonable connection.

But again, they are going to use this, mark my words, as a way to justify always online drm. Just like EA did.

 

[Antari]

Don't we hate this guy for some reason? Should we listen to him?

Until today reading this news item, I didn't have a clue who he was. I still don't much care. But he is right. Live Cloud computing requires an equally powerful connection to that processor. Microsoft could sink billions into the fastest computers in the world. Unless they upgrade everyone's internet with it, its a complete failure before it starts.

 

[zalithar]

So, essentially we have somebody calling out MS on being rather economical with the truth in a PR reveal, but doesn't have any evidence, or even tech knowledge to back it up.

It's like a dick measuring contest, but then with bullshit.

This sounds about right. I'm all for makin fun of Microsoft for their absolutely shit ideas so far for the Xbone, but lets stick with the facts for now. If what they said is false, then someone who actually knows what the fuck they're talkin about can call them out on it. Someone who outright admits that he's just talkin shit and hopes someone who actually is in the know backs him up just makes him look dumb.

To quadruple the processing power of the XBone would probably require an internet connection of upwards of 20 Mb/s, that being a favorable estimate. A person I know with about 20 years of experience put it closer to 1 Gb/s, which in North America is ludicrously expensive. Another factor to consider would be that the more people using the same cloud server the less power each person gets.

I honestly have no idea where they got the fact that it would improve lighting effects and physics. I'm pretty damn sure the game software would set that limit with the cloud only increasing processing speed. It would be very unintuitive to be running the physics and lighting engines on the cloud.

Technically Microsoft's claims are possible, but chances are, their not going to do it. Or you would need a perfect scenario to get what their promising. As in; the server is next door, connected with 1Gb/s speeds, you are the only user.

 

[DiamanteGeeza]

I'm not too sure where to begin! There is so much wrongness(tm) that it's almost overwhelming... LOL.

Physics are not frame critical then. you can calculate physics for multiple secons ahead in current games. epecially when one physics effect does not do anything to the other (for example a splash of explosion does not effect physics of a building nearby it being a static model).

Of course physics are frame critical! You can't just not process a piece of debris for a few frames while you wait for a new position to come back from a server somewhere!

The processing if powerful enough happens way bellow those marks though. for most renders anyway. (lets ignore consoles being stuck on ancient technology for a second). 33 MS is still enough for a render and a signal if the render is, say, happening in 15 MS, which on some machines do for almost all games. granted you need powerful machine to render everything at that speed, but if the machine only has to render 10% and another 10% is rendered by another machine it does the job much faster. well maybe i shoudl say calculate and not render since render is done locally anyway.

I'm not too sure what you're talking about - rendering isn't really relevant to this conversation.

and you need to do that once. and your fine for the whole particle effect to last multiple seconds. Yes it will cause a single freze of say 100ms once. But thats because our machines are not powerful enough yet to make it smaller. Or rather, they are but people dont get acess to.

No, wrong again. Your scenario is that the cloud does all of the processing for the physics. That means an object's position cannot be updated until that position arrives from the cloud. Bearing in mind a 50ms round trip would be fantastically quick, there goes your frame rate.

Now then, if you are suggesting that the client is informed of what has happened and then THE CLIENT processes the actual physics of the debris, then what you're referring to is exactly what I outlined in the point below (the correct way to implement this) and the cloud is NOT doing the physics processing - the client is.

Technically - yes. Practically the bandwitch of our cables in comaprisong to how much data is being transmited by online gameplay in current games would allow us much higher data amounts without extra delays.

Even if you had an internet connection at the speed of light and you were just 1,000 miles from the server farm, the round trip from your computer to the server and back again would be roughly 10ms, and that's just a ping time. Add into that the processing on the server (let's say 10ms for the solver to process the world) as well as transmitting the actual packet data and your round trip is looking more like 20-22ms in absolutely perfect conditions with network traffic moving at the speed of light across ALL CONNECTIONS TO THE SERVER (remember how the internet works... you aren't connected directly to the server, so all paths that your traffic uses would need to be at the speed of light). Right there, just because of the round trip time, you cannot run at 60fps. Now consider the real world (most people are not within 1,000 miles of the server farm, connection speeds are much slower than that, the server has to wait for other people etc. etc.) and even you must conclude that anything close 30fps is impossible if all physics processing is done on the server.

and that is why we have dedicated servers that does the calculations for us, so we wouldnt need to rely on the slowest machine. of course clouding would render that away which makes your point valid.

Again, I'm not quite sure I follow the wording, but let me take a stab anyway... if all physics processing is done in the cloud, you will ALWAYS be at the mercy of the slowest connection. The solver cannot process the world until ALL client actions have been received. I can tell you don't know how physics solvers work, so let me put it like this. Imagine me asking you to solve this equation: what is 4+x? ... if the 'x' is a position coming from a client, you cannot solve that equation without the data from that client.

Anyway, don't let my 30+ years of game programming experience deter your enthusiasm to reply with another load of uninformed nonsense! ;-)

 

[DiamanteGeeza]

Don't we hate this guy for some reason? Should we listen to him?

Until today reading this news item, I didn't have a clue who he was. I still don't much care. But he is right. Live Cloud computing requires an equally powerful connection to that processor. Microsoft could sink billions into the fastest computers in the world. Unless they upgrade everyone's internet with it, its a complete failure before it starts.

Even if you had an internet connection at the speed of light and you were just 1,000 miles away from the sever, the ping time alone for the round trip is 10ms - now add in actual processing time on the server and increase your packet size to something realistic and you end up with (in a perfect world) at least a 20-22ms round trip. Bearing in mind that to run at 60fps you have 16.6666ms per frame, there's no way you're ever running at 60fps if something like the physics is being done anywhere other than the client.

And now change all of the parameters from my speed-of-light example to real world scenarios... most people are further than 1,000 miles from the server farm, real-world internet speeds, varying client connection speeds to the cloud, etc. etc. and it's quite clear that MS are talking crap! LOL.

 

[Strazdas]

I'm not too sure where to begin! There is so much wrongness(tm) that it's almost overwhelming... LOL.

Im glad you enjoyed reading my post

Of course physics are frame critical! You can't just not process a piece of debris for a few frames while you wait for a new position to come back from a server somewhere!

Read my post again?
You process debris flight trajectory once. thats it. you send that data to the client and it executes this for the next 2-3seconds or w/e time debris animation last. you dont have to re-process debris physics every frame! there are some things that are mroe touchy, like the player control object (the person you are playing) as you can pre-process it far due to change in input, but thats it.

I'm not too sure what you're talking about - rendering isn't really relevant to this conversation.

sorry, misused the word, should have been processing instead of render for the most part.

Now then, if you are suggesting that the client is informed of what has happened and then THE CLIENT processes the actual physics of the debris, then what you're referring to is exactly what I outlined in the point below (the correct way to implement this) and the cloud is NOT doing the physics processing - the client is.

Cloud is calculating the physics, and then the client is merely rendering it according to instructions by the cloud. the client iself does not calculation, thus lowering its load. calculation done in the cloud.

Even if you had an internet connection at the speed of light and you were just 1,000 miles from the server farm, the round trip from your computer to the server and back again would be roughly 10ms, and that's just a ping time.

we have internet connects of speed of light. they are called fiber optics. Server farms are closer than 1000 miles. Most games have local servers, for example WOT server i connect to is in Bavaria, Germany, which is 715.46 miles away (granted, direct line). and thats a bad example. there are plenty of games that connect to servers hosted in baltic states or Poland which is bellow 500 miles.
And while the people themselves do not always have dfiberoptics, the intra-ISP connections are all fiberoptics by now. so at worst you got the regular broadband till your ISP server base. and thats usually bellow 1 mile.
Also if the clouding is using other Xbone devices, its very likely to pick ones that are close to you, which likely end up being same city, which means the distance stops being a factor.

Now consider the real world (most people are not within 1,000 miles of the server farm

if you are in, say, Europe and play on american server than its kinda your own fault though. (ofc i udnerstand not all games got localized servers yet)

Again, I'm not quite sure I follow the wording, but let me take a stab anyway... if all physics processing is done in the cloud, you will ALWAYS be at the mercy of the slowest connection.

No. You will be at the mercy of the server speed. the server sends out the signal of what maxhine x should do. it does not wait for a reply. it shows your client what server calculated about that person, if that person himself does not recieve it, hes lagging out, but the server does nto care, you can still kill that person ect and it woudl die in a server and if that guys machine then starts respondign it will be told its dead. servers ignore slow machines, thats the whole reason we got dedicated servers - so we wouldnt have to reply on the slow players.

The solver cannot process the world until ALL client actions have been received.

sent*. recieving is not important. that person will ahve shitty game due to his shitty connection, does not damage others.

I can tell you don't know how physics solvers work, so let me put it like this. Imagine me asking you to solve this equation: what is 4+x? ... if the 'x' is a position coming from a client, you cannot solve that equation without the data from that client.

if client refuses to respond in time ignore the calculator and return x as zero or w/e else defautl value till it responds. if your prgoram has to wait for the client and hold down all other clients because one of them is lagging out, your a bad programmer.

Anyway, don't let my 30+ years of game programming experience deter your enthusiasm to reply with another load of uninformed nonsense! ;-)

Always glad to help
experience time does not matter without context. you could have been programming stuff that requires no clouding and not know shit about it for all i know, or you could be the msot knowledgable person in the world on this stuff, internet does not care.

Cpacha: rodents of unusual size
capcha, i got this twice today, whats up?

 

[DiamanteGeeza]

Im glad you enjoyed reading my post

"Enjoyed" might be a stretch. Wanting to bang my head against my desk due to your lack of knowledge, yet blind assertions about something you know nothing about is more like it.

Read my post again?
You process debris flight trajectory once. thats it. you send that data to the client and it executes this for the next 2-3seconds or w/e time debris animation last. you dont have to re-process debris physics every frame! there are some things that are mroe touchy, like the player control object (the person you are playing) as you can pre-process it far due to change in input, but thats it.

GAHHH! NO YOU CAN'T!!! How many physics solvers have you written? None. How many have I written/used? Lots!

You HAVE to process each physics object EVERY FRAME because you have no way of knowing what is going to interfere with that object over the course of its lifespan. Two frames after it was created, it could be smacked into by something else that gives it an additional impulse. You honestly think that when you see physics objects moving in a game, their entire trajectory was computed once and then it just gets on with it? Please tell me you're not that stupid. Aside from the problem I just outlined, to calculate the full trajectory of an object (even if you could know that it would never, ever have additional impulses or forces applied to it) takes a good chunk of CPU time, so you'd kill your frame rate as well.

Cloud is calculating the physics, and then the client is merely rendering it according to instructions by the cloud. the client iself does not calculation, thus lowering its load. calculation done in the cloud.

Right, and as I have been patiently trying to explain to you, that will not work for fast-paced games.

we have internet connects of speed of light. they are called fiber optics.

No we don't. We have FiOS companies TELLING us that it's moving at the speed of light, but the fiber optic cable itself slows the speed by 33% due to what the cable is made of. Do some research if you don't believe me. There have been recent breakthroughs in various labs to improve the material the cable is made of and considerably reduce speed loss, but they are not available to us yet.

No. You will be at the mercy of the server speed. the server sends out the blah blah blah

Let me reiterate: GAAAAHHHHH! Once again, you have no understanding of what you're talking about. I'm not about to try and re-explain the intricacies of client/server architecture because you clearly want to believe your own made up version of how it works. Suffice to say, you're wrong (again), but if you want to remain ignorant, knock yourself out.

Always glad to help

You're certainly helping raise my blood pressure! LOL.

experience time does not matter without context. you could have been programming stuff that requires no clouding and not know shit about it for all i know, or you could be the msot knowledgable person in the world on this stuff, internet does not care.

Of course experience matters. If I didn't actually know about this stuff, I wouldn't have commented, unlike a certain person I could mention... ;-)

 

[Strazdas]

"Enjoyed" might be a stretch. Wanting to bang my head against my desk due to your lack of knowledge, yet blind assertions about something you know nothing about is more like it.

well, at least your not bored then

You HAVE to process each physics object EVERY FRAME because you have no way of knowing what is going to interfere with that object over the course of its lifespan.

yes you do. you can pre-calculate the physics forward with everything but player actions. now its rarely done due to need of fast and powerful processing which single machine cant handle, but a cloud can.

Two frames after it was created, it could be smacked into by something else that gives it an additional impulse. You honestly think that when you see physics objects moving in a game, their entire trajectory was computed once and then it just gets on with it?

many objects, especially ones that are reacting materially (like you cant change their predetermiend trajectory) do. FOr example bullet trajectory in a shooter is one-off calculation and lasts multiple frames.

No we don't. We have FiOS companies TELLING us that it's moving at the speed of light, but the fiber optic cable itself slows the speed by 33% due to what the cable is made of. Do some research if you don't believe me. There have been recent breakthroughs in various labs to improve the material the cable is made of and considerably reduce speed loss, but they are not available to us yet.

Fair enough. 66% of speed of light is still pretty fast though.

You're certainly helping raise my blood pressure! LOL.

only if you have anger management problems.

Of course experience matters. If I didn't actually know about this stuff, I wouldn't have commented, unlike a certain person I could mention... ;-)

What i meant was that if you have, say, "Experience i software design for 30 years" and those 30 years been programming stuff that do not do such calculations, your experience with such calculations would still be 0, so it all depends on type of experience.

 

[DiamanteGeeza]

You HAVE to process each physics object EVERY FRAME because you have no way of knowing what is going to interfere with that object over the course of its lifespan.

yes you do. you can pre-calculate the physics forward with everything but player actions. now its rarely done due to need of fast and powerful processing which single machine cant handle, but a cloud can.

No. You are completely and utterly wrong. I am sick of trying to enlighten you. I'll tell you what... learn to program, write a very basic physics system, and you'll understand why you're completely clueless.

Two frames after it was created, it could be smacked into by something else that gives it an additional impulse. You honestly think that when you see physics objects moving in a game, their entire trajectory was computed once and then it just gets on with it?

many objects, especially ones that are reacting materially (like you cant change their predetermiend trajectory) do. FOr example bullet trajectory in a shooter is one-off calculation and lasts multiple frames.

Wrong again. If a bullet is processed over multiple frames, you have no idea what might happen during those frames. A character might walk unexpectedly into its path, which would alter the physics and reaction of said object.

You're certainly helping raise my blood pressure! LOL.

only if you have anger management problems.

I currently have idiot-management problems, thanks to you. ;-)

 

[TheCommanders]

Hmm... I'm not an expert on cloud computing, but at the most, couldn't it only improve your processing power by whatever your upload speed is? Because sure the server sends stuff back to you, but you need to be able to send the data to the server to be processed.

Also, wouldn't cloud gaming have a catastrophic effect on your connection speed in a multiplayer game if not only did you have to maintain a steady connection to the server, but half your broadband speed was being consumed with game calculations? Even if this does work, it seems like a bad idea. Cloud storage is great. Cloud computing? I... don't think the infrastructure is there yet (and probably won't be for a while, for the majority of Americans and Europeans).

Oh and one more thing, the claim of 300,000 new servers (or about 275,000 including whatever they have now) seems a bit... high. I'd like to know if that's number they have now, are planning to have in the future, or just want to have. I'm reminded of a car company, while talking about a prototype, saying that it can go 250 mph! Well... it doesn't yet, but we promise it will when launched (it usually doesn't)!

 

[Lovely Mixture]

Took me a while to see your post, but anyway.

Why would it take a technical genius to prove that?

Figure of speech.

Blow stated that he himself could produce 10,000 servers and they'd suck. There's nothing that indicates Microsoft can't produce 300,000 servers.

Cause the number of machines isn't relevant?

It's not that they're lies, it's that they're misleading to the point of practically being nonsense.

Never said they were lies, just said that they're "spouting bullshit" which I define as "being misleading to the point of practically being nonsense." As you say

I build and blow away virtual machines nearly every day for testing. Servers, client machines, new and old environment types, all of that. 300,000 machines is saying nothing because the amount of RAM, the CPU type, and even disk space are all things I can completely control and may suck or be fine. If you found out that they were making a server farm of 300,000 pre-color gameboys would you think that number matters? Probably not.

Like I said, they don't matter.

It's like me telling you that I have one computer to sell you for $900 but I refuse to tell you anything more than the fact that it is a computer. I'm not lying in this hypothetical scenario, I do have a pc to sell you. But the deception or misleading part is that it could be an old Pentium 3 that barely works or it could be one of the latest and greatest i7 machine with everything cutting edge to go with it. Microsoft is doing that in such a way that is indicating that it's a good thing without giving real details. Total misdirect.

Yeah, they stated that the Xbox One's power would be tripled or doubled. They didn't really say how, but the proposition of this being a huge and game-changing thing is stupid.

If you really want to complain about cloud computing being used to augment video games, you should do it in another way.

I'm not... I'm just being critical of Microsoft's usage of what "the cloud" means. Aren't you projecting?

This isn't just requiring always online while you're playing solo player games, it's requiring a decent internet connection that can upload and download data in a manner that could potentially make a solo game more internet demanding than first person shooters. The number of people who do not have the infrastructure for this could be extremely significant since it takes a step beyond the people who don't have a reliable connection. It also means that every game created in this fashion will die the day that those servers go down unless special provisions are made. So these games would cease to exist for our children and grandchildren. If the average infrastructure proved capable of handling this load in a timely manner then it'd be feasible. But if anything happens and your internet can't handle it, we're facing a future of lagging single playing games that have no business lagging.

What's more, there's not necessarily a reason to require cloud processing. It will just be used as an excuse to require always online gaming. We already saw EA trying to pull that shit with Sim City and they got caught. But the truth is that this is the crutch publishers were hoping for to force a kind of DRM on consumers that they know we wouldn't go for without a legitimate reason. Shame on them.

As for the processing bit, with the appropriate internet speeds and network set up, it is entirely viable. Sony did a less upload/download intensive version of this with their folding at home project where ps3's all over the world did the processing. But real time processing and responses is a trickier problem. It really all comes down to the amount of latency it would cause as to whether or not it's worth having. I don't know that we could prove or disprove it as feasible until we have an actual example of it: A game that demands a significant amount of remote processing and a reasonable connection.

But again, they are going to use this, mark my words, as a way to justify always online drm. Just like EA did.

Not sure what you're arguing here, we seem to be on the same page.