[fappenhosen]

Game for Cats says otherwise.

Most expensive way to wreck a cheap rug.

[fappenhosen]

In this case it would be on the server but the same principal applies.  And all you need to do is loop the previous input until you get new input from the client.

I don't think you understand the concept of "client side".

[Lord Dave]

In this case it would be on the server but the same principal applies.  And all you need to do is loop the previous input until you get new input from the client.

I don't think you understand the concept of "client side".

Why do you say that?

[Rushy]

gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

Look at the bit titled Client-Side Prediction.  In this case it would be on the server but the same principal applies.  And all you need to do is loop the previous input until you get new input from the client. 

Again, you're talking out your ass. Client-side prediction is not "input prediction subroutines" and the server does not loop input anywhere. It looks like you found an article on your google adventures and hopes it vaguely agreed with you. That didn't work out so well, bummer.

Yes it will be slower by some number of ms but with a fast enough connection, it isn't too noticeable.  I mean, its not like keyboard/mouse input data requires a lot of bandwidth.  And that data only goes one way.

Bandwidth is (mostly) irrelevant. Anything beyond dial-up upload speeds would suffice. The problem here is that the commands have to leave the client terminal, arrive at a server, be processed, then rendered, then sent back to the client terminal. 

Also remember that while your local based game can visually react nearly instantly it still has to send your input data to the server, have the server process it, then send any corrections on position and status back to the client.

No it doesn't, that isn't how localhost or server hosted multiplayer games work. You should probably read that article that you posted, you would learn a lot.

The only real difference with cloud gaming is that instead of sending status updates downstream, it sends a video stream.

Uhh, no.

In this case it would be on the server but the same principal applies.  And all you need to do is loop the previous input until you get new input from the client.

I don't think you understand the concept of "client side".

Why do you say that?

Client-side prediction is used in client-side multiplayer games. It means that players each have their own instance of a game that predicts what impact the player's actions will have on the game and other players. The server only verifies player activity. This is how multiplayer games became playable and Quake became so popular. OnLive is a step backwards from this, it uses server-side processes to determine player actions.

This is also why on games like Call of Duty another player can shoot you in the face when on your screen the player was around the corner.

[Lord Dave]

gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

Look at the bit titled Client-Side Prediction.  In this case it would be on the server but the same principal applies.  And all you need to do is loop the previous input until you get new input from the client. 

Again, you're talking out your ass. Client-side prediction is not "input prediction subroutines" and the server does not loop input anywhere. It looks like you found an article on your google adventures and hopes it vaguely agreed with you. That didn't work out so well, bummer.

If the server is waiting for your input, what do you think it should do?  Have your avatar do nothing?  Assume you're doing nothing?  That you aren't pressing any keys?  Why not have the server simply assume that whatever input you sent it last is what input you're still sending it until it receives an update?  If you press the forward key, odds are you're still pressing that key 50 ms later.

Yes it will be slower by some number of ms but with a fast enough connection, it isn't too noticeable.  I mean, its not like keyboard/mouse input data requires a lot of bandwidth.  And that data only goes one way.

Bandwidth is (mostly) irrelevant. Anything beyond dial-up upload speeds would suffice. The problem here is that the commands have to leave the client terminal, arrive at a server, be processed, then rendered, then sent back to the client terminal. 

Let me make sure I'm on the same page.  I assume that cloud gaming works by having a VM of a client computer on it's server farm.  Your device connects to that and essentially get a stream of the screen data.  Now in a multiplayer game, this VM machine has to run the client software for whatever game you're running.  (let's say Counterstrike) That client, to connect to a multiplayer server, is going to go out and find one.  It may be on the same server farm as the client VM, or maybe not. 
I see the "client" as the VM running the game and the "server" as whatever is hosting the server version of the game for others to join.
Which means, if I'm right, the data goes from the dummy device(you) to the "client" to the "server".

Also remember that while your local based game can visually react nearly instantly it still has to send your input data to the server, have the server process it, then send any corrections on position and status back to the client.

No it doesn't, that isn't how localhost or server hosted multiplayer games work. You should probably read that article that you posted, you would learn a lot.

instead sending your inputs such as key presses, mouse movement, clicks to the server. In response the server updates the state of your character in the world and replies with a packet containing the state of your character and other players near you

How am I wrong?  The above quote is what I said. 

The only real difference with cloud gaming is that instead of sending status updates downstream, it sends a video stream.

Uhh, no.

Are you saying that cloud gaming doesn't send a video stream to a device?

[Rushy]

If the server is waiting for your input, what do you think it should do?  Have your avatar do nothing?  Assume you're doing nothing?  That you aren't pressing any keys?  Why not have the server simply assume that whatever input you sent it last is what input you're still sending it until it receives an update?  If you press the forward key, odds are you're still pressing that key 50 ms later.

I would not have the server involved in making real time decisions. You know, like most modern multiplayer games.

Let me make sure I'm on the same page.  I assume that cloud gaming works by having a VM of a client computer on it's server farm.  Your device connects to that and essentially get a stream of the screen data.  Now in a multiplayer game, this VM machine has to run the client software for whatever game you're running.  (let's say Counterstrike) That client, to connect to a multiplayer server, is going to go out and find one.  It may be on the same server farm as the client VM, or maybe not. 
I see the "client" as the VM running the game and the "server" as whatever is hosting the server version of the game for others to join.
Which means, if I'm right, the data goes from the dummy device(you) to the "client" to the "server".

You've got cloud gaming correct, but multiplayer wrong. The server only runs data points and verifies accuracy in (most) multiplayer games, it doesn't actually render the game, which is what cloud gaming does.

instead sending your inputs such as key presses, mouse movement, clicks to the server. In response the server updates the state of your character in the world and replies with a packet containing the state of your character and other players near you

How am I wrong?  The above quote is what I said. 

The quote is actually talking about what games used to do, client-side prediction is summarized in the article:

So now in order to remove the latency, the client runs more code than it previously did. It is no longer a dumb terminal sending inputs to the server and interpolating between state sent back. Instead it is able to predict the movement of your character locally and immediately in response to your input, running a subset of the game code for your player character on the client machine.

The whole article is talking about how server-side games are slow as shit, you posted an article that disagrees with literally everything you are posting.

Are you saying that cloud gaming doesn't send a video stream to a device?

No, your statement claimed the only difference is video streaming, when the difference is actually a lot more than that.

[Lord Dave]

If the server is waiting for your input, what do you think it should do?  Have your avatar do nothing?  Assume you're doing nothing?  That you aren't pressing any keys?  Why not have the server simply assume that whatever input you sent it last is what input you're still sending it until it receives an update?  If you press the forward key, odds are you're still pressing that key 50 ms later.

I would not have the server involved in making real time decisions. You know, like most modern multiplayer games.

It has to.  Something has to process all the player input and figure out what the new statuses are.  If you hit the forward button and someone else hits the fire button, the server has to determine if you're hit and if you are, it has to tell you.  Also, unless I'm mistaken, the random cone of fire for games with such things is processed by the server to ensure that clients can't cheat.

Let me make sure I'm on the same page.  I assume that cloud gaming works by having a VM of a client computer on it's server farm.  Your device connects to that and essentially get a stream of the screen data.  Now in a multiplayer game, this VM machine has to run the client software for whatever game you're running.  (let's say Counterstrike) That client, to connect to a multiplayer server, is going to go out and find one.  It may be on the same server farm as the client VM, or maybe not. 
I see the "client" as the VM running the game and the "server" as whatever is hosting the server version of the game for others to join.
Which means, if I'm right, the data goes from the dummy device(you) to the "client" to the "server".

You've got cloud gaming correct, but multiplayer wrong. The server only runs data points and verifies accuracy in (most) multiplayer games, it doesn't actually render the game, which is what cloud gaming does.

Yeah, I know game servers don't render the game.  But they still need to combine all the new data from every client, figure out the new data points and status (did you get shot for example) and send that update data to whoever needs it.  Even if the client has the right data(like nothing new happens), the server still needs to process that data so it can verify that it's true.

instead sending your inputs such as key presses, mouse movement, clicks to the server. In response the server updates the state of your character in the world and replies with a packet containing the state of your character and other players near you

How am I wrong?  The above quote is what I said. 

The quote is actually talking about what games used to do, client-side prediction is summarized in the article:

So now in order to remove the latency, the client runs more code than it previously did. It is no longer a dumb terminal sending inputs to the server and interpolating between state sent back. Instead it is able to predict the movement of your character locally and immediately in response to your input, running a subset of the game code for your player character on the client machine.

The whole article is talking about how server-side games are slow as shit, you posted an article that disagrees with literally everything you are posting.

Since when have I suggested that games are rendered on a server under normal, non-cloud gaming? 

[Rushy]

It has to.  Something has to process all the player input and figure out what the new statuses are.  If you hit the forward button and someone else hits the fire button, the server has to determine if you're hit and if you are, it has to tell you.  Also, unless I'm mistaken, the random cone of fire for games with such things is processed by the server to ensure that clients can't cheat.

The server only verifies actions after they are made by the client, it has little real-time impact on game performance.

Yeah, I know game servers don't render the game.  But they still need to combine all the new data from every client, figure out the new data points and status (did you get shot for example) and send that update data to whoever needs it.  Even if the client has the right data(like nothing new happens), the server still needs to process that data so it can verify that it's true.

Servers normally verify data after the face to catch cheaters or determine contested matches. You seem to think the client and server play some sort of ping pong match, where the client sends the server "move forward one space" and the server says "moved forward one space" and then the client sees they moved forward one space. That isn't what happens.

Since when have I suggested that games are rendered on a server under normal, non-cloud gaming?

Where did I suggest you suggested that? Is this what we're going to do now, dave? Play word games? You know what, I'm done. I am really, truly done. Maybe someone else will come in here and be boggled by you.

[Lord Dave]

It has to.  Something has to process all the player input and figure out what the new statuses are.  If you hit the forward button and someone else hits the fire button, the server has to determine if you're hit and if you are, it has to tell you.  Also, unless I'm mistaken, the random cone of fire for games with such things is processed by the server to ensure that clients can't cheat.

The server only verifies actions after they are made by the client, it has little real-time impact on game performance.

Yeah, I know game servers don't render the game.  But they still need to combine all the new data from every client, figure out the new data points and status (did you get shot for example) and send that update data to whoever needs it.  Even if the client has the right data(like nothing new happens), the server still needs to process that data so it can verify that it's true.

Servers normally verify data after the face to catch cheaters or determine contested matches. You seem to think the client and server play some sort of ping pong match, where the client sends the server "move forward one space" and the server says "moved forward one space" and then the client sees they moved forward one space. That isn't what happens.

The client still needs the data from the other players doesn't it?  I get that the server doesn't need to send a confirmation of what the player does, but doesn't it need to send the data about what the other players do?

Since when have I suggested that games are rendered on a server under normal, non-cloud gaming?

Where did I suggest you suggested that? Is this what we're going to do now, dave? Play word games? You know what, I'm done. I am really, truly done. Maybe someone else will come in here and be boggled by you.

The bit I quoted.  I thought that's what you were getting at.  If it is not, I apologize.  I'm not trying to play word games.  The fact that you think I am indicates that what I'm trying to say is so horribly distorted that I'm wondering if I can speak English anymore.

[EnigmaZV]

It seems as though Sony thinks they have it all figured out with Playstation Now. We'll see how well that works.

[Ghost of V]

It seems as though Sony thinks they have it all figured out with Playstation Now. We'll see how well that works.

Is that the game streaming service I keep hearing about? I don't think it will catch on, but stupider things have worked before.

[Fortuna]

Software can fix latency. It can't, however, fix the fact that you have a ghetto ass connection and can't receive high resolution content from the server fast enough.

[Pete Svarrior]

Software can fix latency.

I upgraded my speed of light yesterday. Thanks, iOS.

[Rushy]

Software can fix latency.

I upgraded my speed of light yesterday. Thanks, iOS.

You laugh, but remember, a lot of iPhone users genuinely believed an update made their phone waterproof due to some 4chan shenanigans.

[Ghost of V]

So the iPhone isn't waterproof? :O

[Pete Svarrior]

You laugh, but remember, a lot of iPhone users genuinely believed an update made their phone waterproof due to some 4chan shenanigans.

thatsthejoke.rar

[Fortuna]

Software can fix latency.

I upgraded my speed of light yesterday. Thanks, iOS.

I'm talking about latency in relation to multiplayer gaming.

[Pete Svarrior]

I'm talking about latency in relation to multiplayer gaming.

Yes.

[Lord Dave]

Software can fix latency. It can't, however, fix the fact that you have a ghetto ass connection and can't receive high resolution content from the server fast enough.

Wouldn't the only software fix be more efficient packet management by the switches?  And wouldn't that result in negligable gains?

[Rushy]

I'm talking about latency in relation to multiplayer gaming.

Is multiplayer gaming operating under special physics?