If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
> Huh? Explain please.
The physics seem good to me, but the cars & tracks are about as exciting as sliced bread and the graphics & sounds are woeful. |
Ads |
#22
|
|||
|
|||
As I'm writing client/server netcode for a flight sim right at this
very moment, I can tell you that it is a grade-A bitch. This is the basic way things work... You have a whole bunch of clients who are trying to play the same game-that is, everyone needs to know where everyone else is, what they're doing, etc. This is called the game state. You designate a server to be the one 'true' game, and each client sends info on what they are doing to the server, and the server collates it and sends it all back out to the clients. As a client, you tell the server what you're doing, the server tells you what everybody else is doing. Except... the game state is *huge*, much bigger than even broadband could possibly cope with as player numbers go up, so the server only sends 'deltas', it only sends what changed since the last frame. But each packet might get lost en route, a series of packets might arrive out of order, so the client has to somehow patch this all together to get some kind of representation of what's going on. Also, when you steer left, you don't send your new position/velocity to the server, you send your control input, and the server does the physics and stuff, then tells you where you end up. This is because you might have just steered into another car. Lets say you're driving alongside somebody else, there's a bit of a gap between you, and you move towards them just as they move towards you. You (your computer) thinks there is no crash (because you steer immediately but you don't see them move for a while due to lag), their computer thinks there is no crash, but the server sees you *both* steer, decides you crashed and then has to tell you both (and everybody else) that you just crashed. Even stranger, because of lag, lets say everyone in the game has a ping of 100ms to the server. If you steer, the server only finds out about it 100ms later. If someone else steers, you only find out about it 200ms later. 1/5 of a second. If you're on dialup and your ping is 500ms, you steer and it happens on your screen *half a second* later. That's unplayable, so your computer doesn't wait for the server, it does it immediately, assuming that the server will tell you the same thing anyway. Your computer also predicts what everybody else is up to. When you finally get an answer from the server, your computer shifts everybody in the world into their proper place, which makes them jump, or 'warp'. Of course, they warp to the places they were at when the server sent the packet, so 100ms ago... Basically, no client ever sees what's really going on. They are always incorrect by some margin. If you have a steady broadband connection to a decent server in a game with good netcode and prediction, you might not even notice anything except the occasional warp, but you're still seeing into the past to a certain extent. As for client replays, the positions of the cars comes from the server, the client does no physics on them, it just puts them where it's told, or predicts if it has no data. Client replays are *always* incorrect. Plus, good netcode will drop distant state info. If the server is sending out state for 40 cars, that's a lot of data (=bandwidth), so it will drop cars which are further away, updating them less often, so the client does more prediction. It's less accurate, but you don't care. Sometimes they might disappear completely. The only replay which shows what really happened to everybody is (by design) the server replay. Why are flight sims better for replays? Because if you're 10 miles from someone and the server isn't giving you much info, or you have a lot of lag, then you start to predict, your predictions start to go wrong, but hey! If they are 10 miles away and their position is 5 metres out of true, can you tell? No. If you're driving alongside someone at 200mph and their position is 5 metres out, can you tell? You betcha. I know this is a bit epic, but I've had my head in this stuff for ages and I'm only just figuring it out. I'm making my netcode generic, but I'm starting with a flight sim because it hides the errors ;-) The biggest problem I've had (thankfully 'solved' now) is, if you're sending the difference on each frame, what happens if the last packet didn't arrive? How do you work out the new values if you never had the old ones?! You could just resend the lot, but that takes *ages*. What happens if you get packet 6 before packet 5? Arrgh, it's a nightmare! Thanks for letting me vent! :-) By the way if anybody wants to know more (details, code), I'm happy to help out. The internet is great for WinSock tutorials, great to tell you the problems for games, but thin on solutions... all of my info comes mainly from Quake, Quake 2 and Freespace 2 source code. |
#23
|
|||
|
|||
"Nick" > wrote in message oups.com... > > Also, when you steer left, you don't send your new position/velocity to > the server, you send your control input, and the server does the > physics and stuff, then tells you where you end up. This is because > you might have just steered into another car. Lets say you're driving > alongside somebody else, there's a bit of a gap between you, and you > move towards them just as they move towards you. You (your computer) > thinks there is no crash (because you steer immediately but you don't > see them move for a while due to lag), their computer thinks there is > no crash, but the server sees you *both* steer, decides you crashed and > then has to tell you both (and everybody else) that you just crashed. > An educated guess tells me that any netcode that starts out using control input is stuffed. I would think it should start by having 6 pieces of info, X times per secong. The 6 pieces of info are a 3D point + the accompanying 3 angles of rotation about the 3 planes. I'd guess that's how Papy code works. The only problem with Papy code is the crude use of linear prediction which creates collisions that never actually happened such as when an inside car warps up into an outsie car. Anyway, anything after these 6 bits of info is just nice - engine rpm and throttle opening/engine volume, tyre squeal/smoke probably being next in the pecking order. Then maybe you throw in front wheel turn, etc, etc. The server should be able to have the option to enable/disable as much of the nice stuff as possible and also control the freq that data is sent/recieved at. That way available bandwidth can be used to either maximize field numbers and/or the quality of the multi I basically disagree with the gist of your post too ie that it's a nightmare. Papy have had it pretty well sorted since GPL and even b4 that with Hawai. Any company setting out to do things properly, with the right, dedicated people, should have this sorted in no time. And it should be the first thing to be sorted with emphasis on not only the racing, but the results reporting after races. |
#24
|
|||
|
|||
> An educated guess tells me that any netcode that starts out using
> control input is stuffed. Well, that's about all the net games ever made, then. If you let clients just send their positions, they can hack the game to speed up, for example. If you don't send the control inputs to the server for it to verify movement, you've got one almighty cheat-filled game going on. Ideally, you would want to do as much as possible on the client, but clients are easy to hack. Look at Counter-Strike-the most common hacks are aimbots, because the speed you can turn is not restricted, so they just lock on to the nearest player, calculate the control inputs they would need to do so and send them back to the server, so the server can't tell anything bad is going on. You never see teleport hacks or jump hacks or speed hacks, because the server would notice and disallow it. There are a few good articles around, such as "The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter" by Peter Lincroft on Gamasutra. Another good one is "Instant Replay : Building a Game Engine with Reproducible Behavior" by Patrick Dickinson. They dovetail quite nicely. You could also check out the Unreal Networking Architecture at http://unreal.epicgames.com/Network.htm (look at the client prediction bit). Or, just check out the source code to, say, Quake, which is pretty much identical in operation to Quake 2, Quake 3, Half-Life, Counter-Strike, and all the other games descended from Quake. > The 6 pieces of info are a 3D point + the accompanying 3 > angles of rotation about the 3 planes. Well, you need a velocity vector to even start predicting any kind of movement, and if you wanted to add any kind of accuracy you'd need an acceleration vector too. Same for angular velocity and angular acceleration. So minimum 18 floats, which is 72 bytes per packet. That, as you say, is without the 'nice' stuff. Add on the IP header (20 bytes) and UDP header (8 bytes), and it starts getting big. Figure 100 bytes for this 'bare minimum' stuff. If the server is running at 20fps (like Quake 2), and you have 40 cars, each client has to download 100 * 20 * 39 = 78,000 bytes every second from the server. If you're on 512kbps broadband, that's 512 kiloBITS per second, 64 kiloBYTES per second. So you physically CANNOT play the game, even on half-a-meg broadband. God help you if you're on dialup. Remember, this wouldn't result in lag, that's the delay between sending and receiving data, this is beyond the physical limit of the amount of data you can receive over a given timeslice. > I basically disagree with the gist of your post too ie that it's > a nightmare. Papy have had it pretty well sorted since > GPL and even b4 that with Hawai. LOL! Papy have some of the best netcode around, and as you say, it's been in development since, well, when was Hawaii? We're talking 8 years minimum. My netcode isn't even 8 weeks old! It is a nightmare trying to coordinate dozens of people across the world, each with different pings, packets getting lost, arriving out of order, needing to severely restrict what you send due to the reasons I've outlined above, stopping cheating, etc. It isn't a case of ISI netcode being especially bad, it's Papy netcode being especially good. Remember, ISI weren't even allowed to do dedicated servers until recently, so they don't exactly have 8+ years of experience here... |
#25
|
|||
|
|||
|
#26
|
|||
|
|||
Lets say that a remote players' data takes 100ms to get to the server,
and it takes another 100ms to get to you, their data is already 200ms old by the time it gets to you. To go back another 50ms (server rate) to take an average is just increasing the inaccuracies twofold (older data, and averaging). Plus, what happens if data from the remote player gets lost for a bit? You either use some data that's whole seconds old to get your average, or you have no velocity data at all. Either way it's pretty meaningless. This is what makes it so hard, you come up with something that sounds like it works, it works on your LAN, but as soon as it hits the internet it dies, and more often than not it's hard to figure out why it died, because you can't replicate the conditions, and you can't exactly set breakpoints in a multiplayer game... As soon as a car goes around a corner, the velocity keeps changing, but the acceleration remains pretty constant (towards the centre of the corner), so if you only use velocities, then as soon as you lose data in a corner, all the cars start going straight (imagine swirling a rock on a piece of string around your head-losing a packet is like cutting the string, the rock moves in a straight line with its last known velocity, now that it has no acceleration acting on it to drag it round the circle). |
#27
|
|||
|
|||
|
#28
|
|||
|
|||
|
#29
|
|||
|
|||
Steve Simpson wrote:
> > Huh? Explain please. > > The physics seem good to me, but the cars & tracks are about as exciting > as sliced bread and the graphics & sounds are woeful. I've just recently unlocked the LFS S2 alpha and am having a bunch of fun with it, the physics are actually very good and there is a good selection of cars with my favourite probably being the open wheel formula XR. Have no problem with the tracks and graphics but the sound is perhaps the weakest part of the game but it doesn't detract hugely from what is a very well done racing simulator with solid netcode. The guys behind this deserve a lot of credit. |
#30
|
|||
|
|||
Jan Verschueren wrote:
> rFactor corrects some of the issues related to the "ISI" multi, like the > join pauses, but is, in essence, no better than GTR in that department. Boo. I haven't messed much with the multi demo, have they at least implemented a better tire model if not better net, menu (argh, the demo menus are worse than the old SCGT/F1x menus), and replay code? |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
rFactor Multi ? | Ed White | Simulators | 2 | March 16th 05 07:39 PM |
If multiplayer code in NSR is as good as rFactor... | Bill Bollinger | Simulators | 0 | February 7th 05 04:12 AM |
rFactor MP Test Fix: unfortunately doesn't fix ... :( | Hans de Heer | Simulators | 7 | January 15th 05 03:16 PM |
rFactor demo - any fix? | [email protected] | Simulators | 23 | January 15th 05 12:47 PM |
rFactor: Fix available for "Trymedia" problem! | Hans de Heer | Simulators | 1 | January 15th 05 12:43 PM |