Stunt Car Racing Multiplayer
Blitz3D Forums/Blitz3D Userlibs/Stunt Car Racing Multiplayer
| ||
| I need a bit of advice regarding using Tokamak over a network - Stunt Car Racing seems to work just fine with 2 or more cars, but obviously each one is a collection of jointed Tokamak entities and suchlike, so I need to know how is best to run such a system over a network. Split-screen is no problem, and the single Tokamak world and entities will exist and interact within the single program, but running over a network allows for a few possible options as far as I can see - 1. Run all the tokamak for all cars on one PC, then just get control input updates from the clients to control the cars locally, then send back the new positions for the visual entities only, and do no Tokamak at all on the clients. 2. Run Tokamak for the local car on each PC, then try to simulate the collisions using impulses etc... 3. Run Tokamak for the local car on each PC and ignore any collisions (Trackmania style) - not much fun this way. The only other option seems to be to run Tokamak for the local car on each PC, then move a single tokamak body around in the world that represents each remote car. However I can see some real problems with the remote body hitting the local tokamak car, and I just don't see it working. If anyone has any hints or tips on this I'd be very grateful to hear, as obviously 3 or 4 player over a network is more fun that 2 player split-screen. To spark your interest, here's a screenie with 2 cars lined up ready to race -  |
| ||
| Well, as i have commented before, you could use a 'dead reckoning system'. The DR System is very much used when running physics simulation over a network. The idea is to have all computers running all full physics and synchronizing remote cars periodically. In the DR algorith you send periodically local position, velocity, direction and user input, then the remote players update remote values and extrapolate positions using the remote input untill a new value arrives. To avoid position jumps, the DR algorithm only updates position if there is enough position difference from actual values and the values received. Advantages: - Smooth movement - Real Physics in every computer - Easy implementation Disadvantages: - Some problem when cars collides at great velocities. You can avoid the problems updating position only when not collided. I suggest you to implement the basic algorithm then use your own tweaks. I have implemented it in my racing game and is working great over internet! Good Luck! |
| ||
| So using this system, each PC would run full physics for all cars, then pass their coords back and forth to check for any car being away from its real position. If it is, all systems will update their local car position to the real position. The only problem I can immediately see is that there is no way to move a jointed Tokamak vehicle instantly from one place to another - you just end up with huge forces on some of the jointed parts and the object gets slung around. I originally tried to just re-position the cars after they fell off the track, but there is no way to do it. Even resetting all the force values to zero doesn't seem to work. In the end I had to make it rebuild the car completely when it gets reset. However, having just read what I've written it occurs to me that I didn't reposition the joints themselves, just the physical entities, so I might try that again and see if I can get it to work.... |
| ||
| Hi vorderman! What i do in the Racer is: have a flag to disable physics on logged-in cars. The disable simply stops the car from moving. I use the network to send the position of each player from their clients, AND VELOCITIES. the velocities makes the collisions work properly. ON receiving the location of a car, set the physics body of that car to the received location, and velocity. Over LAN, the racer runs absolutely fine like this, and is mostly playable with a tad of lag over a few hundred miles. Lemme know if you need more information :) (yeah, there are other ways to do it, but this is my way. ) [edit] to add to what Kurix said, which is probrably the better way, and is the way my new network code will do it, When two cars collide at great velocities, theres a chance that one will act like it was made of rubber and it just hit a wall at 500 mph, bouncing off backwards.. Fnuny to watch. Me and Evak have laughed quite a few times when our cars decided to visit the moon... |
| ||
| Even resetting all the force values to zero doesn't seem to work Dont know where to start- You may be doing it wrong :? |
| ||
| Well, i am using ode, and although repositioning a jointed body in ode is not a good idea, is working fine, because i position the body, then i set the velocities to the right values. I don't know if you can make it with tokamak. |
| ||
| Ive used the technique in both ODE and toka. it was easier on toka, ODE seems to dislike it a bit, but if youre stubborn with it, its fine (in ode, i force the reset to take place two frames in a row.) |
| ||
| Dont know where to start- You may be doing it wrong :? Yep, I was - just re-wrote the reposition routine in 1/2 hour and it works perfectly, so now I can ditch the code that deletes and rebuilds the car and use this nice quick easy repos routine instead. I forgot to repos the joints last time, I think that was the problem. use the network to send the position of each player from their clients, AND VELOCITIES In the DR algorith you send periodically local position, velocity, direction and user input I think I'll try running this dead-reckoning system, sounds reaasonably easy to implement and I can't see many possible pitfalls, apart from when a remote car is repositioned inside another car...wonder what would happen then? |
| ||
| then... BOING (in ODE) one car flies off :) |
| ||
| I'm tempted to try it in Tokamak and see what happens.... lol, this is what happens -  Not too bad though, even with one car spawning right inside the other, they just get flung apart a bit. Can't see a case this bad happening in the game, so long as the clients are updated and checked pretty often. |
| ||
| Hehe. I should have known, I had the same thing happen yesterday when testing my library :) As you said though, there shouldnt be a point where two cars spawn at the same point, you could just move player2's spawn point forward by the car length :) |
| ||
| Now is where tweaking is important. One thing you can make is not reposition the car if it is too near from other :) DeadReckoning + Some Tweaks = Good System! |
| ||
| i have to say, these graphics are already top-notch. add physics andnetworking and you have a hit :) |
   |