BEPUphysics

Hello. I am doing some network programming and I have vehicle-like objects in my game. When a user moves or rotates one of these "vehicles" I would like to send the new position and rotation to the other users in the match. However, when I reposition everyone else's vehicle on their machine, the wheels and other objects constrained to the vehicle stay where the vehicle was before it was moved. This makes both sides of the constraint very unstable. I have tried to move the other objects (the wheels for example) by the offset they where on the vehicle before so they stay in the same relative position to vehicle, but it did not have very good results. Is there any easy way to have objects which are constrained to the frame of the vehicle move with the frame when I reposition it? Thanks.

I have tried to move the other objects (the wheels for example) by the offset they where on the vehicle before so they stay in the same relative position to vehicle, but it did not have very good results. Is there any easy way to have objects which are constrained to the frame of the vehicle move with the frame when I reposition it? Thanks.

Constraints perform all their calculations based on the relative states of objects. If all objects undergo the identical transform, no extra position correction should be necessary for an isolated constraint system. Is every single connected component being teleported with the same transform, and is that transform rigid (translation and rotation only)? If so, it should work as expected.

However, if the transform is based on a single object, applying that transform to other objects may result in invalid situations, like wheels being stuck in walls (if wheels were a separate entity). To prevent this, every object would need to have its own transform, and for best results, the whole connected component should have its transforms sent together and applied together.

The Vehicle class simplifies this a bit since it's only one entity and the wheels are not physical entities.

Odd behavior can also come from the networking paradigm itself; it's tricky to get robust. Here's a thread that goes over some approaches and links to resources: http://www.bepu-games.com/forums/viewto ... f=4&t=1161

Thanks for the reply!

I rewrote the repositioning code on the remote machine and that seems to have made it much more stable but it still shakes a bit.I am sending the frame's position and rotation on each player's machine. Then on the other player's machines I go through each object and preform code similar to this:

thing.Orientation = newOrientation;
Vector3 orbitPosition = Vector3.Transform(thingOffset, thing.Orientation);
thing.Position = newPosition - orbitPosition;

This way I am sending the minimum data I need to in order to reposition the entire vehicle on the other machines.

I don't think I could get away with the results I'm looking for by doing the ray casting that the vehicle class uses. i.e. I'm not smart enough to do that and still get the effect I'm looking for.

I have been reading up on that thread and the presentation. Very cool stuff. I should be able to get most of what I need from it though I don't understand why multiple computers acting as their own servers would be ok for COOP but vulnerable to cheating, especially on the Xbox 360 (The game is being developed for PC as well). What types of issues might I run into as my game is meant to be a highly competitive physics based game?

This way I am sending the minimum data I need to in order to reposition the entire vehicle on the other machines.

Is that using a transform per object, or a transform for the 'vehicle' and then transforming all pieces using that one transform? The latter is a minimal approximation, but will sometimes cause problems.

If it's the former, I suspect the shaking is just the authoritative corrections yanking the object around.

If it isn't already, the velocity needs to be corrected as well as position. If the velocities do not agree, the remote client will continually extrapolate the simulation into invalid positions, requiring constant recorrecting.

A common problem is also trying to send too much data, too often. Even if you don't get bitten by packet loss and bandwidth issues, this will usually result in a jittery appearance. It's better to allow some leeway and correct when necessary rather than trying to update the whole state for every object every single frame. The trick is finding a good set of rules that govern when and how objects are corrected.

I should be able to get most of what I need from it though I don't understand why multiple computers acting as their own servers would be ok for COOP but vulnerable to cheating, especially on the Xbox 360 (The game is being developed for PC as well). What types of issues might I run into as my game is meant to be a highly competitive physics based game?

The nice thing about each player being authoritative over a subset of the simulation is that you don't have to fake any authority. If a player presses the move button, that updates their 'true' state- it doesn't have to go to a server and back before it's accepted while the client tries to hide the latency with tricks. Additionally, since objects near a player or controlled by a player are also generally hosted by the player, vehicles or held objects behave smoothly too.

I wouldn't worry too much about cheating. On the Xbox360, it's not really a concern even in competitive games. On the PC, you're still partially protected by obscurity- most people aren't going to spend the time cheating on an indie game unless it's extremely easy to do it. So long as there aren't user accessible console commands to teleport yourself around or something, it will probably be okay.

If it turns out it isn't okay, there are still ways to address it. There can be a super-peer that analyzes the information it receives for validity and can determine if a player is doing invalid things. If you can't trust any specific peer, you could also share that responsibility amongst many peers. Those peers can then vote on actions over time to see if a player is likely cheating, and if it becomes a high probability, get rid of the player. This sort of technique adds in a lot of complexity and some overhead, so I wouldn't go down that road unless it's truly necessary.

And there's external methods too. Steam has some anti-cheat stuff available (VAC), though I'm not sure how it works. If it's something like Blizzard's warden, it might watch for known external programs. That might be enough.