Stunt Car Racing multiplayer
Community Forums/Showcase/Stunt Car Racing multiplayer
| ||
| Hooray, it works!!!! However I could do with a little advice about Tokamak and networks, so if you can help please answer this thread - http://www.blitzbasic.com/Community/posts.php?topic=52106  |
| ||
| Hurra! :) |
| ||
| NICE!!!! :D |
| ||
| HOLY COW VorderMAN! :) Hehe.. My code im testing at the moment would probrably have worked for this ^.^ Neat. I wanna go home to play! [edit] When DO we get to play? lol. |
| ||
| I wouldn't know much about physics, but I can offer some insight to multiplayer on race games as i've done it twice now. You may take or leave this and to some extent it probably depends on how you program, but I shall dissect that part of my brain and let you know what i've found for myself: The most important packet is the one that tells the other clients new information they didn't already have. Such as the first packet after a car has changed direction. Using standard networking systems that send packets every 250ms or so this can result in a quarter of a second delay when that important packet is sent, with latency it could be half a second before it arrives at all the clients, this is bad. Interval timed packets are good as a backup in case an important packet didn't arrive, but they are not good for sending the important packets. I structure my network code to use internvalled timing but I reset the timer whenever there is a change in the state of the controller like if the accelerator is pressed when it wasnt previously. I then send a new packet strait away with x,z mommentum and the control being pressed. My remote clients continue to process the controls that I am pressing in a hacked version of my main control function. So far for race games i've found this is by far the best system to use of all those i've tried and results in the client machines showing other racers very true to their real positions. |
| ||
| Becky: At the risk of hijacking the thread, just a quick one: so you're saying you send packets every 250ms or so, but to supplement that you send an 'important' packet whenever something changes (ie accelerate, turn, brake etc)? Are your 'important' messages the ones you send as 'reliable' packets, supplemented by the 'unreliable' ones every 250ms after that? Vorderman: After the furore of the last preview, and with the news that you've added multiplayer successfully... well, just... brace yourself. :o) I'm not going to be so crass as to ask for a demo soon (everyone else can do that!), but a lil bit of video to get us frothing at the mouth would be an excellent hype-inflater. :oD |
| ||
| Just a note Vorderman, Ive used a technique like Beckys above. Its not good with Physics. Certainly didnt work for more than a few seconds with the racer- So perhps send a global position update every now and then to keep it all smooth. |
| ||
| LineOf7s i'll email a reply to that so we dont totally hijack the thread. |
| ||
| Becky: So considerate. Ta. :o) |
| ||
| LineOf7s i'll email a reply to that so we dont totally hijack the thread. No no, please do hijack the thread - I really could do with reading everything about multiplayer networking that others have done or are doing, it's something I've never tried before. and with the news that you've added multiplayer successfully Well, I wouldn't say "added successfully" - certainly I now have 2 (or more :) ) cars running under full physics in the game, but as yet no way to control the cars over a network...I was rather surprised that just spawning a new car actually resulted in another car appearing and working, rather than something daft happening that I'd overlooked. I could get it working split-screen in a few minutes, but networking is what I really wanted and that'll take longer. I quite like the idea of putting the rear view mirror back in, then adding spotlights to the front of the cars that the player can flash on and off....it was always fun to do this in Need For Speed, trying to put the other player off. Perhaps a horn also...? |
| ||
| No no, please do hijack the thread lol, in that case here is the email I sent to LineOf7's "you're saying you send packets every 250ms or so, but to supplement that you send an 'important' packet whenever something changes" Most people send packets every 200-250ms or so when writting a network game, I send a network packet when the players control state changes or an event (such as a tyre failure) happens. This is a workable system, but far from ideal as when a player brakes or turns the wheel they can be out of sync by half a second or more - which is quite bad for a race game where tenths of a second matter. To counteract this I send my packets when the state of the players controls change. If I start braking I send a packet, if I start turning I send a packet (with analogue controls it's best to use a window to test against, ie: if abs(currentBraking-breakingInLastNetPackage)<0.2). Unfortunately network games do sometimes drop a packet, although it doesn't happen often. However if the player is going down a long strait and misses the packet that is sent as they enter the strait then other players may show them in the barrier for a good 10-15 seconds or so, to counter this and incase of dropout I still use the timed interval system. In practice it can usually be set to even less frequent than 200-250ms as packets getting dropped are quite a rare event usually, but provided a safety net is there to let other players know you are not link dead and incase of packet drop then you should be fine. "Are your 'important' messages the ones you send as 'reliable' packets, supplemented by the 'unreliable' ones every 250ms after that?" I dont really have reliable and unreliable packets, a packet is a packet it is just a question of when to send them and the info contained in them. I dont use any form of error detection and correction in my network games. I usually use TCP/IP as although the header size is more than UDP it costs less bandwidth to use TCPIP then sending back a single byte verification. Rather than flaff around detecting an error I would rather just send the repair packet anyway by virtue of getting the next packet when it arrives. It's rare that a single packet drop is such a major issue anyway. The other issue in network games is what information to send. I always send the state of the controls being pressed, depending on the game this is usually in some form of binary system: 1 accelerate 2 brake 4 gear up etc.. This then allows the remote clients to process my position using the same mathematics which causes less of a "jump" when the next packet arrives with the correct x and z position. Some people like to gradually smooth out any innacuracies by comparing the distance between the current x and z position of a remote entity and the corrected position and gradually applying the difference over time. I find that sending the control being pressed pretty much addresses this anyway and the only ocassional "jumps" are fixing the odd drop out - and i'd rather the unit jumped to it's correct position rather than drove sideways. |
| ||
| Half-life sends packet every 50milliseconds as default, and usually people change it to send to every 10milliseconds. But its first person shooter and uses UDP so its different thing. I'd suggest just sending the position and direction & speed like every 200ms, and make it adjustable for LAN etc. |
| ||
| It would be nice to have a kind of option to set how many packets are sent. Means: 56K Modem - few 1 MBit/ DSL - more 2 MBit - more than more T1 / Lan - many Btw: I got my joypad, "saitek 2600 rumble" :) |
   |