| 10 posts found | |
|---|---|
|
Well , on of my favourite genres of games is the FPS though i used to play it on a LAN with friends (peer-to-peer architecture) but when i began to play it on the internet (Client-Server architecture) i saw a problem all of the FPS games had (Lag) , unlike turn-based games, these kinda games deal with the loss of data in a different way . For a Turn-based game , it's not really the kinda problem if a command on your avatar didn't make it to the server after all you've got time to redo the action. But for an FPS game timing is one essential skill you need to learn so seeing the other player having the lag sign , you try to avoid him cause in these kinda games when a player has got lag he automatically stops but no one can attack him , so why wasting time with him... Does this kinda problem have to happen in FPS networking architecture because of the differences of INTERNET SPEED each one has got ?? And are there any solutions to this kind of problem??? Feel Free :D |
|
|
5/14/09 10:48:07 AM#2
As I understand it no client side FPS will get over 24-32 players. The reason for this is in client side gaming one person gets to be the "host" and all others players connect to him. Two problems arise from this; If the host has a bad connection then everyone lags or individual players have a bad connection to the host and they lag. The The PS3 suffers only from individual users having bad connections because they use dedicated servers like MMOs. This also allows PS3 shooters to have 64 man matches and there is a game coming out called MAG that will have 256 player matches. MAG will be the first real test of an FPS MiniMMO.
For an MMOFPS to work it would take a dedicated server and an upgrade on internet speed. There have been rumblings of an internet 2.0 being brought online that will allow 30gb dl and 5gb upload speeds (approximate numbers) but who knows when and if that will happen. As it is right now our interenet structure just cannot handle 1000 space marines shooting at each other with detailed worlds and special effects. Maybe it will happen in the future though.
Beta Testing: Star Wars: The Old Republic Playing: League of Legends, BF:BC2 |
|
|
5/14/09 12:29:46 PM#3
It could work if the amount of data sent was minimize, (FPSs don't optimize things as much as MMOs need to), and if the client and server computers had faster or closer connections to the backbone. Also if the US Government stopped splicing the backbone and told the ISPs to turn off the government double filter, "Carnivore", it would also make the current internet noticeably faster. Barcladica Studios --- Projects: Pith PHP Framework, Also working on a small gui for pygame |
|
|
5/14/09 12:48:24 PM#4
An MMOFPS is perfectly practical, but only where the roundtrip communication time between server and client is small. That generally means being close to the server. 'Close' is actually a network topology issue, but geographic distance is a 'good enough' metric. The OnLive service presents an opportunity to find out how to structure an MMOFPS service. OnLive claims to run FPS games over the network. If it works, then it will establish that having an MMOFPS server per geographic area would be a way to make it work. That keeps the distance from the server short and network delays low. Today, MMOs assume 24/7 operation and pretty much worldwide access. Tomorrow's MMOs might become specific to a thousand-mile radius area so that everyone within that area can interact with the server in approximate real-time. That's the model that OnLive uses - they provide a server that is relatively close to you. As the internet figures out how to reduce network latency (round trip times), that thousand-mile radius could grow. We're limited to lightspeed communications, meaning that a perfect system can do no better than 6ms from one side of the planet to the other (following the surface). With various repeaters and routers in between, that time climbs. My regional ISP server pings in 20ms. 50 roundtrips per second. A japanese server pings in 200ms. 5 roundtrips per second. So being close to the server helps avoid problems with network delays. The bottom line is that if an MMOFPS comes into being, you'll be playing with people in your geographic area. If you work a graveyard shift and want to play an MMO when you get home, you may find the server in your area rather empty. The ones that are populated in other time zones wouldn't be useful to you. Unless you wanted to play a game that didn't require quick response times. Personally, I think that playing with people in your geographic area provides greater opportunities for community. I might even like playing with people that I know are in my metropolitan area. For other people, that's the exact opposite of what they enjoy. |
|
|
5/14/09 12:56:02 PM#5
Originally posted by BioNut Exactly, this was a major problem in Gears of War 1 - (PC) I used to play with some mates on that game pretty much every night I was not playing an online PC game. It was great fun apart from the fact that if my one of my freinds internet connection was acting up (or usually it was just because there connection was bad all the time) then the people connecting to the hosted GoW server at the time would receive some lag and in most cases the host had hardly any lag at all. To the OP. Lag has been around for a long time. :) |
|
|
5/15/09 12:25:01 AM#6
Originally posted by BioNut Internet speed isn't all that much of a problem, depending on how much you can off load to the client. 128 bits should be enough to locate a player and give all their actions (I actually came up with 96 bits). Using 250 latency (updating 4x a sec) and a full 1000 players (I wouldn't expect that, as you would server side parse) you'd need 512 kb/s d/l to handle that side of it. Another 256 kb/s should cover model info, chat, VoIP and pretty much anything else you could think of. A true 1mb/s connection should easily handle what we are talking about. The real obstacle is client renders for that many objects at the level of detail required. |
|
Originally posted by ghstwolf Internet speed isn't all that much of a problem, depending on how much you can off load to the client. 128 bits should be enough to locate a player and give all their actions (I actually came up with 96 bits). Using 250 latency (updating 4x a sec) and a full 1000 players (I wouldn't expect that, as you would server side parse) you'd need 512 kb/s d/l to handle that side of it. Another 256 kb/s should cover model info, chat, VoIP and pretty much anything else you could think of. A true 1mb/s connection should easily handle what we are talking about. The real obstacle is client renders for that many objects at the level of detail required. ghstwolf , have you got any references explaining this in more details ???
|
|
|
5/18/09 12:52:37 AM#8
Not really, but I'll give you the way I came up with that number. For any given player the amount of info needed can be divided into 2 catagories: the constantly changing (location and actions) and the fairly static (player appearance). By treating them seperately, that is giving the player build data seperately from the more dynamic parts you get a very streamlined data set. You'd have a database that gives all the data to build player models referenced to the player ID used for the rest of this. At this point all you'd need to send for each person is: the ID (I used 16 bit), map slice (depends on the size of the map but 8 or 16 should suffice), x,y,z on that map (3*16 bit), orientation (8 bit = accuracy to 1.5 degrees) and 16 bits for status (to include all your firing stances, crawling and such). Even if I missed a couple things, or shot a bit low on a couple of them it's there's still room to stay under 128 bits per character for the dynamic data set. Using 128 bits per charcter I scaled using 1000 characters and updating 4 times a second. The 256kb/s for everything else is something of a high ball guess, but it should readily cover updating the player build data and anything else the game would need.
|
|
|
5/18/09 6:28:41 PM#9
When FiOS becomes standard, or cable companies take their QoS to its upper limit, this issue will be solved. Problems with lag caused by routing can be solved with smart tunneling between two connections, minimizing latency by finding and utilizing the fastest possible route as a virtual point-to-point connection between players and the server (akin to L2F). No reason why the "FPS problem" should be a problem much longer. Really, it can already be done, but with more limited player numbers. In Japan, it can already be taken to whatever level you want. |
|
|
5/18/09 7:38:43 PM#10
What I find to be a problem is that most games have servers in the USA and Europe, sometimes Australia. I live in South America, which is pretty freaking far from any of those, which dooms me to a bare minimum of 250ms. If there were more servers, the general lag would be reduced. |
|