EPTFuture of Games? - Page 6
| Forum Index > General Forum |
|
MamiyaOtaru
United States1687 Posts
| ||
|
prOxi.swAMi
Australia3091 Posts
| ||
|
h3r1n6
Iceland2039 Posts
For me, living in the middle of nowhere in Germany, my ping is 60 in the average-good case. Let's take the FPS case. I press w and try to move forward. The command goes to the server, takes 60 ms. Then the server computes my command and moves my character. Let's say that does not create any delay, and the video is sent back. It then has another 60 ms. This is a 120ms delay, which you have by default. And it is not the standard lag you would get on a server, your own movements are delayed, which is very hard to deal with and very noticable at 120 ms. In a regular FPS, you move client side, sending the information to the server as you move. You don't have a delay between you input and your actual actions. The server only gets your commands after your ping, 60 ms, for example. It's the same way for your opponents. On their Pc, they will be at some place. On the server, they will be 60 ms behind, on your Pc, they will be 120 ms (their ping+your ping to the server) behind. This leads to missing shots, because your opponent is not actualy at the position where you see him. I am not really into this, but how I understand the anti-lag code usualy works is, that it calculates the time backwards, so that when you shoot your opponent, you actualy hit him. The way it works in Starcraft is, that every action you do is delayed by a certain time period, depending on the latency (lan - bnet / each with low - extra high). The commands are sent to the other person, where the units then execute the commands. If the packages with the commands need longer than the preset latency (i.e. lan latency is 100ms, your latency to opponent 150), the game will lag. Those solutions are however game specific, and only fix the lag between two players. I have no clue how you would fix the lag between client and server for the streaming games, and I don't think it would be playable with the lag. | ||
|
FaCE_1
Canada6174 Posts
On March 25 2009 07:10 Klive5ive wrote: What you talking about?! The UK standard is 8Mb, you only need 5. I'm sure USA is the same. I got a 7.5 in canada and its the "standard high-spped version" | ||
|
armed_
Canada443 Posts
On March 30 2009 04:02 h3r1n6 wrote: As I see it, every game would need extra coding for somehow making the user input not lag. This is absolutely impossible. | ||
|
stroggos
New Zealand1543 Posts
| ||
|
Sayara
Finland42 Posts
Who knows, maybe they'll break laws of physics. | ||
|
Fen
Australia1848 Posts
On March 30 2009 09:03 stroggos wrote: wow this is awesome, especially for us new zealanders and Australians and South Americans. Actually the technology, if it did work would still be useless for us. You need reliable internet for this to be viable at all  | ||
|
rredtooth
5460 Posts
edit: ok just looked at the list of "current partners" and must admit that it is quite a list. thought i don't believe onlive (yet) i trust the partners enough that i would give it a shot. link to list: http://www.onlive.com/partners.html | ||
|
piskooooo
United States351 Posts
| ||
|
da_head
Canada3350 Posts
| ||
|
Badjas
Netherlands2038 Posts
Actually, the game will run server side as a single instance (per match at least), so all the player's inputs can be put in sync by the onlive server side process, before passing it to the game instance. | ||
|
lololol
5198 Posts
On March 30 2009 04:02 h3r1n6 wrote: As I see it, every game would need extra coding for somehow making the user input not lag. For me, living in the middle of nowhere in Germany, my ping is 60 in the average-good case. Let's take the FPS case. I press w and try to move forward. The command goes to the server, takes 60 ms. Then the server computes my command and moves my character. Let's say that does not create any delay, and the video is sent back. It then has another 60 ms. This is a 120ms delay, which you have by default. And it is not the standard lag you would get on a server, your own movements are delayed, which is very hard to deal with and very noticable at 120 ms. In a regular FPS, you move client side, sending the information to the server as you move. You don't have a delay between you input and your actual actions. The server only gets your commands after your ping, 60 ms, for example. It's the same way for your opponents. On their Pc, they will be at some place. On the server, they will be 60 ms behind, on your Pc, they will be 120 ms (their ping+your ping to the server) behind. This leads to missing shots, because your opponent is not actualy at the position where you see him. I am not really into this, but how I understand the anti-lag code usualy works is, that it calculates the time backwards, so that when you shoot your opponent, you actualy hit him. The way it works in Starcraft is, that every action you do is delayed by a certain time period, depending on the latency (lan - bnet / each with low - extra high). The commands are sent to the other person, where the units then execute the commands. If the packages with the commands need longer than the preset latency (i.e. lan latency is 100ms, your latency to opponent 150), the game will lag. Those solutions are however game specific, and only fix the lag between two players. I have no clue how you would fix the lag between client and server for the streaming games, and I don't think it would be playable with the lag. Ping is the time for the packet to travel to other peer and back, so 60ms ping is 60ms delay. The server you play on will be hosted on the same pc/cluster that streams the game to you, so after the input delay, there will be no extra client-server delay. Still input delay is much worse than server lag, because it fells awkward and affects single player games as well. As I see it this will be mostly for casual gamers that don't want to pay upfront for a console or a high end pc. On March 30 2009 04:29 FaCE_1 wrote: I got a 7.5 in canada and its the "standard high-spped version" You can get 20mbit/s ADSL for 10-12 euro/month around here. | ||
|
R3condite
Korea (South)1541 Posts
there's no way there would be no lag time... there's still internet lag esp if u r talking about using wifi... and plus this isn't really legit cloud computing in that they rn't' gonna use other ppl's comp do run their games now r they? say it get popular that they have more ppl playing games at any given time then they have processes for then wat? it's just like playing on ur own desktop now... the idea sounds cute and would be cool but im not putting any money down till it comes out and at least is patched once or beaten by another company in a competitive market | ||
|
D10
Brazil3409 Posts
/remembers tons of defeats in WC3 because the fucking TP never came out in time because I played with 250+ ms | ||
MasterOfChaos
Germany2896 Posts
Unreal Networking Architecture document on the history of game networking architectures Next came the monolithic client-server architecture, pioneered by Quake, and later used by Ultima Online. Here, one machine was designated "server", and was responsible for making all of the gameplay decisions. The other machines were "clients", and they were regarded as dumb rendering terminals, which sent their keystrokes to the server, and received a list of objects to render. This advancement enabled large-scale Internet gaming, as game servers started springing up all over the Internet. The client-server architecture was later extended by QuakeWorld and Quake 2, which moved additional simulation and prediction logic to the client side, in order to increase visible detail while lowering bandwidth usage. Here, the client receives not only a list of objects to render, but also information about their trajectories, so the client can make rudimentary predictions about object motion. In addition, a lock-step prediction protocol was introduced in order to eliminate perceived latency in client movement. Yeah go back to Quake 1 level of networkcode. Sounds like progress to me. Only difference is the reduced client hardware requirenment when rendering on the server. And since the server requires a lot of rendering hardware then, I see no real gain. So + Less hardware required on the client - More hardware required on the server (graphicscard wise about as much as you safe on the client, processorwise it is more efficient) - Bad latency characteristics for servers more than a few ms away - Insane bandwidth requirenments - Probably worse graphics due to badwidth limitations 50$ a year does not sound realistic. At 500MB/h (HD quality, bandwidth might be even worse due to severe timeconstraints when encoding) and 10ct/MB this corresponsds to 1000h a year. And it does not yet include the energy burned by their computer center, or even the hardware costs. | ||
|
Sonu
Canada577 Posts
but what about hardware companies. I do not think they will support this because companies like Alien ware cater to PC gamers, selling hi-end hi level computers. As a gamer I like this. As someone who works at a company like Alien ware.... not so much | ||
|
zizou21
United States3683 Posts
| ||
|
Jovan
Canada65 Posts
On March 31 2009 13:53 zizou21 wrote: To the skeptics: http://www.onlive.com/partners.html Steve Perlmen, one of the people behind OnLive is quoted as saying: "Perceptually, it appears the game is playing locally... what we have is something that is absolutely incredible. You should be sceptical. My first thinking was this shouldn't work, but it does." [sic] This article discusses some of the reasons why it's not going to work. They are very valid reasons, because thus far OnLive has only been tested in a controlled environment, not in a real one. Videos are pretty and all, but lets not forget the reason why Quakeworld was made: LAN and internet play are very very different. Latency and packet loss are things that need to be taken into account, and this is where the "controlled" environment is no longer controlled. Welcome to the real world. | ||
|
rkarhu
Finland570 Posts
| ||
| ||
