Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (605)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Physics Collisions + Network Latency  (Read 14593 times)
0 Members and 1 Guest are viewing this topic.
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Posted 2005-06-20 16:00:50 »

Hi all,
Im trying to put a game together but it looks like ive stumbled across a dead point. The game is a multiplayer car game with physics and collisions. The initial idea was only to send the forces that are being applied onto the car through the network. This will give a smooth look on each player's screens, which theorehtically, it does. But one problem. What if a collision occurs between two cars. The forces will change dramatically, but due to lag and whatnot, on one screen a collision can have happened, on another, it may not have. Obviously, its a problem.

I couldn't find many articles on google describing this, and quite rightly so, because most article refer to FPS and a stray bullet isn't really noticed.

Is server side collision detection and response a good idea? If so, how much of it? Just the collisions between two players and terrain-car client side?

What about if we only used forces. I.e. dont send anything other than forces and torques. Then we do a client side positions comparision wereby the client compares what he sees by what he *should* see (sending positions) and adding a force to bring the car back on track? Good idea? Bad? It can possibly take a while for the car to be back on track and it also might look weird if the car is drifiting sideways...

What about P2P style networking? send the force and torques via a P2P network (does P2P reduce ping times?) and other statistical things to a server. Also, the server will set out the rules for the game. E.g. how long it will last, what map...etc. Again, good idea? Better than the rest? worst? Im confuzzled!  Undecided

Regards,
DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline shawnkendall

Senior Devvie





« Reply #1 - Posted 2005-06-20 17:46:18 »

Ok, we are doing nearly the same thing so perhaps I will come out and start discussing publicly to support any synergy that could germinate in this community.

I have done real-time game networking (RT meaning not turned based but "fast" in-frame action type stuff, FPS, racing etc) in the past with Java in our game demos.  This was using UDP (and multicast in some cases) on LANS but NOT ever WAN (Internet).

This is what we are working on right now.  More specifically, we are networking an "area" full of physics objects with multi-player intertactions.

We are not sending forces right now. Instead, we are sending the dynamics 'snapshot' of the object the ODE will use to bring back in sync the networked worlds. And specifically, position, orientation, linear and angular velocities.  Work with forces in my experience is mess and in exact in frame based physics engines like ODE.

We are doing point to point networking, i.e. no server checking other than for connection services.  Latency is the major issue (well asuming broadband) with the data, so direct player to player seems to be best. We make the 'server' another client in the group, so it has the last info, but isn't in-between the clients creating delays.  the big down side is that player client code has other players IPs, which ultimately can be a security issue.

Ok enouhg for now :-

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #2 - Posted 2005-06-20 17:55:21 »

I see, ok, so your recomending i send the positions/rotations and the Torque and linearVelocity through a P2P network and simply "set" them to the other object. I know ode can recalculate the force based on a new velocity, but last time i heard, it doesn't like it very much...

Have you played a game called TrackMania? (It was released last April)...Its a very fun realtime car racer and they dont allow collisions between cars which I found suprising. I.e. you can pass straight through another car. Perhaps they were hitting the same problem...

Take this scenario. Two cars almost parallel are traveling, they will eventually hit each other. Now one of the players (call him player1), swerves at the last minute to avoid a collision. If we are acting on forces, the other player (player2) will see player1 as carrying on forwards and a collision will happen between the two on player2's screen. Although player1 has swerved 200 millis ago (average ping). Even on positions and linear velocites etc, it might be too late...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ask_Hjorth_Larsen

Junior Devvie




Java games rock!


« Reply #3 - Posted 2005-06-20 23:30:19 »

Quote
The forces will change dramatically, but due to lag and whatnot, on one screen a collision can have happened, on another, it may not have. Obviously, its a problem.

Maybe it isnt' what you meant, but this implicitly assumes that it is "okay" for the calculations to be inexact when no large forces are involved. Any, even the slightest deviation across clients will be sufficient to severely desync games, so any inexact approach is completely unusable.

One approach which will eliminate this problem is to do all calculations on the server, then beam the complete game state across the network every frame. Rather expensive if you have many cars, and latency will be a problem. Latency can be eliminated to some degree by letting clients simulate loosely what they think is going to happen, then beam corrections from the server at regular intervals. Still, those corrections would be quite large. In a large world, not all information might be necessary to all clients, so one could save some bandwidth there. In games life Halflife, I guess things work roughly this way. When you fire or move, the person will do so immediately, but in reality there will be some fuss with respect to lag, since the server has to somehow carry out these things in sync across all clients.

A very bandwidth-cheap way is to let every computer do all calculations in parallel, then simply send basic commands by the user through the network. This approach is common in RTS games. Latency is a problem, but very little traffic is required. You just need to synchronize the execution of these events across the network by associating a specific frame with each.

These are just ideas, and I'm not exactly a specialist, so feel free to clear up any inaccuracies and stuff.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #4 - Posted 2005-06-21 01:51:45 »

After playing Q3 I am convinced that it is not possible with current technology to make a fast-paced network game that works. There is no way to get around the lag that is satisifying... some aspect of game play MUST suffer.

Offline JoC

Junior Devvie




I love YaBB 1G - SP1!


« Reply #5 - Posted 2005-06-21 07:43:52 »

Best car game I ever played is Flatout, http://www.flatoutgame.com/
It uses some sort of point to point networking i think, since if the "host" crash all other still can play on without any problems.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2005-06-21 08:15:52 »

After playing Q3 I am convinced that it is not possible with current technology to make a fast-paced network game that works. There is no way to get around the lag that is satisifying... some aspect of game play MUST suffer.
Well you can try all the fancy algorithms you want, but for a face paced game over the internet the fact remains that there'll be about 200ms seperating the two players, and humans are inherantly unpredictable.  Wink Until we get LAN-range pings over the internet people will still have to mess around with game-specific shortcuts and fudges.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Mark Thornton

Senior Devvie





« Reply #7 - Posted 2005-06-21 09:28:18 »

Put the track on the moon with all drivers operating via remote control. Now you have an excuse for 500ms delays. :-)
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #8 - Posted 2005-06-21 12:14:20 »

Thanks all,
So i guess the conclusion from this thread can be thought of as do P2P networking, server (acting as a client) manages states and hope for the best!

@ Ask_Hjorth_Larsen: In a way, yes, this approach is inaccurate. Lets put a scenario together: A player (player1) and someone is watching (player2). Player 2 is not playing...Now if we are only sending forces, the force can change without it being sent to player2, e.g. accelerate hard and then brake, the total force will not show that, so what player2 sees will be probably a very innacurate picture of what should happen. To get around this, probably sending the position every 3 - 4 seconds and setting the position to of player1 is probably best...

Any other ideas folks?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline tom
« Reply #9 - Posted 2005-06-21 13:35:30 »

Don't worry about synching the state. It don't matter if what the player sees is "correct" as long as it seems plausable and it don't effect the lap time. With that in mind you can cut some corners and just try and make the physics seem realistic.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #10 - Posted 2005-06-21 14:24:47 »

tom, thanks for the advice, if I just ignore it, inaccuracies can accumulate and it ends up being WAAYY off. Player1 colliding with player2 on his screen sending player2 off, but on player2's screen, P1 is miles away...thats what im worried about.

@JoC, i just downloaded the demo for this game...SWEEEET! It is very good, shame i can't nab their models/tracks tho, it seems the first track is perfect for me!  Smiley

Regards

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Ask_Hjorth_Larsen

Junior Devvie




Java games rock!


« Reply #11 - Posted 2005-06-21 15:04:31 »

Quote
@ Ask_Hjorth_Larsen: In a way, yes, this approach is inaccurate. Lets put a scenario together: A player (player1) and someone is watching (player2). Player 2 is not playing...Now if we are only sending forces, the force can change without it being sent to player2, e.g. accelerate hard and then brake, the total force will not show that, so what player2 sees will be probably a very innacurate picture of what should happen. To get around this, probably sending the position every 3 - 4 seconds and setting the position to of player1 is probably best...

That seems reasonable. Allow me to emphasize, though, that even small inaccuracies can affect the game very much (near-misses and whatnot), and it can be difficult to determine the minimum amount of data necessary to reconstruct the model without having to send the complete game state. For a car game, however, it might be possible to send a complete game state since only a rather small amount of entities are moving around (depending).
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #12 - Posted 2005-06-21 15:17:52 »

Im afraid the amount of data that needs to be reconstructed would be quite large... Roll Eyes

Think of barrels, tyres...etc and because they all can possibly change the state of the game (hit a car), they have to be entities as well...

Also, how frequently should I be sending packets? Every frame? Thats 60 in a second! That seems quite large....or am i wrong?

Regards

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline kevglass

« JGO Spiffy Duke »


Medals: 221
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #13 - Posted 2005-06-21 15:46:48 »

60 times a second isn't feasible. What you're trying to achieve is very very difficult (I was going to say impossible, but I'm sure someone would just disagree). Running a synchronised world across the internet with any sort of accurasy just isn't possible. As people have mentioned above the latency just doesn't make this possible, 200ms is a reasonable estimate and in that time frame so much can change in a physics world.

Herk once said that its about tailoring the game not the network (or something similar). In your case I would suspect the sensible thing to do would be to be run everything locally. Two people can for instance hit the same barrel at different times at the same location, just make it look right to the player. Car (QuadBike?) damage is maintained locally to the player, if they see themselfs get hit - they get hit - yes this is prone to cheating. If you're really bothered add a voting layer, damage is inflicted when 50% of players say it happened. Don't try to sync game worlds in this sort of detail, its just a frustrating track through the darkest dampest bowels of hell.

You do of course want to resolve times when two people intersect and the like, but that pretty similar to any FPS.

Kev

Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #14 - Posted 2005-06-21 16:04:48 »

Ok, taking a laid back approach to the whole thing...

Ok, realistic scenario: Player1 is racing ahead and player2 is behind him. Theres a barrell out of sync between the players and player2 is going to hit it on his screen, but the barrel is out of place on player1's screen. The damage should just appear on player1's screen? It actually sounds horrible, but thinking about it, its not so bad.

What if player1 sees player2 is going to collide with the barrel? but he doesn't...If im just transmitting forces, player2 will be HIGHLY out of sync (actual player2 would be traveling fine, but player1 sees him flying through the air)...That sounds a horrible concept! Everytime i get an answer, 4 questions crop up! Your right kev, its an underground, flammable sewer in hell, full of monkies with laser guided chickens!

And your right kev, it is a quadbike. Its looking currently like a jeep, so if anyone wants to model me a quadbike...consider it a late birthday gift!  Grin

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Ask_Hjorth_Larsen

Junior Devvie




Java games rock!


« Reply #15 - Posted 2005-06-21 23:52:12 »

Due to simplicity I recommend the (high-latency) RTS approach. Transmit all control input (commands) across the network and have every client calculate physical stuff in parallel. Associate with each command the absolute frame number in which that command is going to be carried out.

ALL (logical) FRAMES MUST BE NUMBERED SEQUENTIALLY.

You could implement it like this:
player 1 hits "forward".
a "forward" instruction is sent to the server.
Server receives this instruction in frame number 716.
A "forward" instruction is sent to all players, scheduled for execution at frame number 716+LATENCY, let's say LATENCY = 20.
A player receives the instruction in frame number 731. that instruction is stored in a queue until its time is up.
Finally in frame number 716+LATENCY = 736, ALL players are expected to have received the command, and will then execute the command in exactly the same frame!

One question remains: what stops each player from progressing beyond the time at which the command is scheduled for execution? You could regularly send out max-frame-number-instructions allowing clients to run up to a certain frame number. Whenever the client's frame number reaches this maximum frame number, the game MUST HALT until a new max-frame-number instruction is received. Thus it is virtually impossible to get out of sync, at least if this is implemented correctly! TCP/IP is really a nice protocol.
Offline tom
« Reply #16 - Posted 2005-06-22 01:07:46 »

Due to simplicity I recommend the (high-latency) RTS approach. Transmit all control input (commands) across the network and have every client calculate physical stuff in parallel. Associate with each command the absolute frame number in which that command is going to be carried out.

Be aware that you'll have to limit yourself to integer math if you base your simulation on input only. Floating point math will differ between hardware, even vm version. StrictMath might help, but don't know if garanties that all results will be identical.

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #17 - Posted 2005-06-22 01:59:55 »

Don't worry about synching the state. It don't matter if what the player sees is "correct" as long as it seems plausable and it don't effect the lap time.

That is exactly the problem with "deathmatch" play in every FPS I have ever played.  Either your own "hits" aren't counted, or you are hit by something that clearly was rendered as a "miss".  Not to mention shooting walls because the game didn't react to your strafe in a timely manner.

I stopped playing them because it took all the fun out of it to be "cheated" like that all the time.  Depending on your network traffic you can even see the effect on a LAN.

That said, Q3 is still quite popular... so not everybody cares that the games aren't WYSIWYG.

Offline elias

Senior Devvie





« Reply #18 - Posted 2005-06-22 07:07:42 »

Due to simplicity I recommend the (high-latency) RTS approach. Transmit all control input (commands) across the network and have every client calculate physical stuff in parallel. Associate with each command the absolute frame number in which that command is going to be carried out.

Be aware that you'll have to limit yourself to integer math if you base your simulation on input only. Floating point math will differ between hardware, even vm version. StrictMath might help, but don't know if garanties that all results will be identical.

That's exactly what StrictMath is for. However, to make all floating point operations identical, you'll need to declare all game-state affecting code 'strictfp' too. Note that this is a problem if you're using e.g. ODE which is probably not strictfp at all.

 - elias

Offline Mark Thornton

Senior Devvie





« Reply #19 - Posted 2005-06-22 07:57:54 »

Even without StrictMath/strictfp, any differences will usually be tiny. However estimating the likely size of these differences for particular algorithms is a highly specialized skill.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2005-06-22 12:06:07 »

If you want to go that way, do it loosely (but checking that your FP won't go wild in those few frames), and re-synch periodically. You can afford e.g. a once-per-second re-synch on the fp stuff

malloc will be first against the wall when the revolution comes...
Offline tom
« Reply #21 - Posted 2005-06-22 12:09:40 »

Even without StrictMath/strictfp, any differences will usually be tiny. However estimating the likely size of these differences for particular algorithms is a highly specialized skill.
It do not mather how tiny the difference is. Don't have to be an expert to know that the error will add up very quickly and the game will end up out of synch.

StrictMath might fix it, but then you'll have to consider if it is fast enough.


Offline Mark Thornton

Senior Devvie





« Reply #22 - Posted 2005-06-22 12:51:32 »

Even without StrictMath/strictfp, any differences will usually be tiny. However estimating the likely size of these differences for particular algorithms is a highly specialized skill.
It do not mather how tiny the difference is. Don't have to be an expert to know that the error will add up very quickly and the game will end up out of synch.
If you are not an expert you should probably not say anything at all on this subject. Whether the errors accumulate and how fast depends on the algorithms involved. While some algorithms would diverge rapidly, others can proceed for billions of operations with only tiny differences. In my opinion (as a PhD in mathematics) attempting to avoid floating point is not the correct answer to this problem. After all a great deal of effort was put into the design of the arithmetic used in modern computers (and required by Java) with the intention that the behaviour of floating point is well controlled. Perhaps instead of treating floating point as "here be demons", more programmers should learn to understand it.
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #23 - Posted 2005-06-22 13:51:53 »

Err, are you seriously suggesting people should use a more complicated  and error prone system over a tried and simple secure system?

Floating point rounding errors do add up a lot over time. You either work around it (what I suggest), or make sure it the errors are exactly the same and add up in exactly the same way for everyone (what you seem to suggest).

Play Minecraft!
Offline Mark Thornton

Senior Devvie





« Reply #24 - Posted 2005-06-22 14:10:59 »

Err, are you seriously suggesting people should use a more complicated  and error prone system over a tried and simple secure system?
No, that is what you may get through attempting to use integers.

Quote
Floating point rounding errors do add up a lot over time. You either work around it (what I suggest), or make sure it the errors are exactly the same and add up in exactly the same way for everyone (what you seem to suggest).
Again no, what I suggest is to understand what the error bounds are and keep them under control. Accumulated error doesn't become a problem until it reach perhaps 1 in 1e6, so at that point you need to distribute corrections.

However in the case of Java, the extent of difference is very restricted. For the basic operations (+,-,*,/ etc) even without strictfp the results must be exactly the same unless the range of float/double has been exceeded. A JVM is not allowed to perform computation with any more (or less) precision, it can only use a larger exponent range. So in the case of double if no intermediate value exceeds 1e308, then the results are required to be identical. Java does allow some differences in the case of some of the non StrictMath methods (e.g. sin, cos, etc), but here the permissable difference is very small. Note that methods such as Math.sqrt specify a correctly rounded result --- all conforming Java implementations must return exactly the same result for this method.

While doing your own thing in integers may ensure that all clients produce the same answer, it also increases the likelihood that the answer obtained is wrong!
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #25 - Posted 2005-06-22 14:45:00 »

Floating point math isn't right either. Wink
(like, for example, how 0.1 isn't 0.1)

But, yes, I misunderstood you. Wooohoo! Cheesy

Play Minecraft!
Offline Mark Thornton

Senior Devvie





« Reply #26 - Posted 2005-06-22 15:01:10 »

The problem with 0.1 (base 10) doesn't apply to physics. Using floating point with finance is much more problematic, largely because various authorities specify rounding rules invariably in base 10 while the usual computer floating point is base 2 based.
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #27 - Posted 2005-06-22 15:14:49 »

My point was that there are rounding errors in floating point math unless you happen to only use 2^x numbers, so claiming that floating point math contains fewer errors than integer math is wrong.
0.1 was just a clever example, it's the 1/3 of binary math. (but please note that 1/3 is not a problem in trinary math)

The errors in floating math are more "hidden", though, so they often act as time bombs unless the programmer knows what he does. With integer math the error shows up immediately rather than after "billions" of operations.

[edit: added quotes around "billions"]

Play Minecraft!
Offline Mark Thornton

Senior Devvie





« Reply #28 - Posted 2005-06-22 15:31:54 »

You still have quantization errors when using integers to represent real world quantities, plus you add in risk, if you scaled the values, that someone will assume the wrong scale factor. In addition many real world quantities have inherent measurement uncertainties (Heisenberg). These uncertainties are much greater than the difference between a base 10 value and its double (base 2) approximation.
Offline JoC

Junior Devvie




I love YaBB 1G - SP1!


« Reply #29 - Posted 2005-06-22 15:52:57 »


@JoC, i just downloaded the demo for this game...SWEEEET! It is very good, shame i can't nab their models/tracks tho, it seems the first track is perfect for me!  Smiley

Regards
Yes it is a damn fun game, especially in multiplayer.
Be sure to check the forum for tools for reading the map format, I know atleast that they make their own cars for the game.
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Elsealabs (16 views)
2014-12-28 10:39:27

CopyableCougar4 (20 views)
2014-12-28 02:10:29

BurntPizza (25 views)
2014-12-27 22:38:51

Mr.CodeIt (15 views)
2014-12-27 04:03:04

TheDudeFromCI (20 views)
2014-12-27 02:14:49

Mr.CodeIt (26 views)
2014-12-23 03:34:11

rwatson462 (58 views)
2014-12-15 09:26:44

Mr.CodeIt (47 views)
2014-12-14 19:50:38

BurntPizza (96 views)
2014-12-09 22:41:13

BurntPizza (115 views)
2014-12-08 04:46:31
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!