T2D Networking: Will all T2D clients perform the *exact* same?
by John Klimek · in Torque Game Builder · 03/04/2006 (7:00 pm) · 60 replies
I'm creating a Scorched Earth (eg. tanks) game that will feature multiplayer support (as in 2 - 8 players per game). The game server is being written in Delphi and will work as a game lobby server (so the T2D clients can connect and find other people to play with, etc).
The server will NOT calculate physics, etc... I'm going to leave that all to T2D on each client. With that said, is that safe to do? Will each client perform the physics and collisions the *EXACT* same way?
For example, let's say player one fires a projectile and T2D takes care of the physics (gravity, wind, etc). Can I simply tell each T2D client to fire a bullet with (x, y) velocity and be sure it will land in the EXACT same spot on each client?
Also, another thing my game will feature is stuff like anti-air buildings. What I plan to do is when a projectile is fired the client will check the distance to each anti-air building and if it's close enough it will fire an anti-air missile at the projectile. Can I count on each T2D client performing the EXACT same way? If any client renders the position of a projectile or collisions even slightly different it may result in synchornization issues between clients.
I'd like to have my server application (again, written in Delphi so it's non-Torque related) perform all physics calculation and update each client so everything is synchronized, but since T2D has such much built-in physics and collisions I'd MUCH rather let it handle everything and only have the server monitor player health amounts, etc... (some simple cheat protection).
Thanks for any help =)
The server will NOT calculate physics, etc... I'm going to leave that all to T2D on each client. With that said, is that safe to do? Will each client perform the physics and collisions the *EXACT* same way?
For example, let's say player one fires a projectile and T2D takes care of the physics (gravity, wind, etc). Can I simply tell each T2D client to fire a bullet with (x, y) velocity and be sure it will land in the EXACT same spot on each client?
Also, another thing my game will feature is stuff like anti-air buildings. What I plan to do is when a projectile is fired the client will check the distance to each anti-air building and if it's close enough it will fire an anti-air missile at the projectile. Can I count on each T2D client performing the EXACT same way? If any client renders the position of a projectile or collisions even slightly different it may result in synchornization issues between clients.
I'd like to have my server application (again, written in Delphi so it's non-Torque related) perform all physics calculation and update each client so everything is synchronized, but since T2D has such much built-in physics and collisions I'd MUCH rather let it handle everything and only have the server monitor player health amounts, etc... (some simple cheat protection).
Thanks for any help =)
About the author
Recent Threads
#42
Well, Stephen; You still have to admit that there's "something wrong" when the exact same setup results in wildely different end results (see John Klimeks post with the console screenshot).
[/quote]
There are literally dozens of implementation decisions in his scripts (possibilities I mean) that could alter or even completely unstabilize the physics engine--I know, I did it myself not a few times while making the Boot Camp labs. In fact, I never did get my rigid body physics grenade working properly against tilemaps, mostly due to lack of personal understanding of the auto-calculations for mass and density, and how to use them.
Not to mention that I had drastically out of balance forces that were causing penetration cases!
There are both provided commands to help stabilize rendering vs physics operations, as well as multiple techniques describes here in the forums for not being dependent on frame rate, but instead utilizing delta over time implementations. Specifically, look at setTargetFPSActive, and the other methods on t2dSceneWindow (might be scenegraph, I don't remember off the top of my head).
03/11/2006 (1:33 pm)
Quote]Well, Stephen; You still have to admit that there's "something wrong" when the exact same setup results in wildely different end results (see John Klimeks post with the console screenshot).
[/quote]
There are literally dozens of implementation decisions in his scripts (possibilities I mean) that could alter or even completely unstabilize the physics engine--I know, I did it myself not a few times while making the Boot Camp labs. In fact, I never did get my rigid body physics grenade working properly against tilemaps, mostly due to lack of personal understanding of the auto-calculations for mass and density, and how to use them.
Not to mention that I had drastically out of balance forces that were causing penetration cases!
Quote:
In my own tests the t2d physics still seem to be slightly too dependant on framerate and I _would_ consider this a "bug". There will always be some difference due to rounding errors, I agree with that. I'm not at all worried with networking, I just want stable physics that isn't so dependant on the current framerate.
There are both provided commands to help stabilize rendering vs physics operations, as well as multiple techniques describes here in the forums for not being dependent on frame rate, but instead utilizing delta over time implementations. Specifically, look at setTargetFPSActive, and the other methods on t2dSceneWindow (might be scenegraph, I don't remember off the top of my head).
#43
So will TGB implement the same networking strategy?
03/11/2006 (4:42 pm)
Yes Stephen, that is right... So will TGB implement the same networking strategy?
#44
First, you would have to have a real time OS. The term RTOS has been tossed around and due to various marketing efforts has become diluted, but in essence a real time OS can guarantee (still within limits) that something happens when it is supposed to happen. Consumer OSes do not make this guarantee. It's a fact of life.
Second, it isn't "close enough." This is where chaos rears its ugly head. As has already been pointed out the small errors accumulate overtime. What makes the result chaotic is that small perturbations can have disproportionately large results. If the timing is off just enough that a collision doesn't happen the next tick might allow a complete miss (this specific example is supposedly covered in the current version, but it serves as a simple illustration -- to give it teeth throw in non-linear movement).
Railing against the reality serves no useful purpose. Did you know that there are simple decimal numbers that have no rational expression in binary? This can lead strange bugs if you don't code carefully (for example, try incrementing 0.01 at a time from zero and stop when it exactly equals 0.3. It won't.
You could complain that T2D is broken because it gives a wrong result or you could write your loop so that it only runs while the counter is less than 0.3. And the problem isn't with T2D, it is with binary and our decimal expectations.
Once you accept the reality of T2D physics you can focus on coding so that the computer inaccuracies don't affect game play.
Tim Doty
03/11/2006 (4:50 pm)
One thing that seems to be missed by many here is that there is absolutely no way to guarantee identical physics performance between runs, much less across differing computers or platforms on the supported platforms. Why? It isn't because GG might not want to, they literally can't. No one can. Why?First, you would have to have a real time OS. The term RTOS has been tossed around and due to various marketing efforts has become diluted, but in essence a real time OS can guarantee (still within limits) that something happens when it is supposed to happen. Consumer OSes do not make this guarantee. It's a fact of life.
Second, it isn't "close enough." This is where chaos rears its ugly head. As has already been pointed out the small errors accumulate overtime. What makes the result chaotic is that small perturbations can have disproportionately large results. If the timing is off just enough that a collision doesn't happen the next tick might allow a complete miss (this specific example is supposedly covered in the current version, but it serves as a simple illustration -- to give it teeth throw in non-linear movement).
Railing against the reality serves no useful purpose. Did you know that there are simple decimal numbers that have no rational expression in binary? This can lead strange bugs if you don't code carefully (for example, try incrementing 0.01 at a time from zero and stop when it exactly equals 0.3. It won't.
You could complain that T2D is broken because it gives a wrong result or you could write your loop so that it only runs while the counter is less than 0.3. And the problem isn't with T2D, it is with binary and our decimal expectations.
Once you accept the reality of T2D physics you can focus on coding so that the computer inaccuracies don't affect game play.
Tim Doty
#45
Michael posted a solution above to my problem that I'm going to try, but I'm wondering if anybody has any other solutions... (I'm not saying that's a bad solution! I'm just curious about the "best" solution for me)
However, this thread is getting quite long... perhaps I should start a new topic with my particular game idea and ask for help relating to the specific nature of my game...
03/11/2006 (6:24 pm)
I understand what everybody is saying... it's just confusing because you would think that games would run exactly the same on every machine, but from what you're telling me even exact same games will sometimes produce a "miss" when another machine would produce a "hit" (in the case of a projectile/collision). I guess nobody notices execpt in multiplayer games when everything must be synchronized *exactly*.Michael posted a solution above to my problem that I'm going to try, but I'm wondering if anybody has any other solutions... (I'm not saying that's a bad solution! I'm just curious about the "best" solution for me)
However, this thread is getting quite long... perhaps I should start a new topic with my particular game idea and ask for help relating to the specific nature of my game...
#46
As I said above, I am actually pretty sure there is a cleaner solution. I have never done anything with networking.
Integer mathematics are really exactly the same on every machine. Maybe you can exploit this to your advantage. For example you could round the position of the projectile every now and then before the accumulative error becomes too big. This would give you a "wrong" trajectory in physical terms but hey, it's a computer game. It doesn't have to be realistic. It has to look good and be fun.
03/12/2006 (3:07 am)
Quote:
Michael posted a solution above to my problem that I'm going to try, but I'm wondering if anybody has any other solutions... (I'm not saying that's a bad solution! I'm just curious about the "best" solution for me)
As I said above, I am actually pretty sure there is a cleaner solution. I have never done anything with networking.
Integer mathematics are really exactly the same on every machine. Maybe you can exploit this to your advantage. For example you could round the position of the projectile every now and then before the accumulative error becomes too big. This would give you a "wrong" trajectory in physical terms but hey, it's a computer game. It doesn't have to be realistic. It has to look good and be fun.
#47
To put things another way, boundary conditions are where you are most likely to find/expose bugs and other error conditions. Who do you know what is a boundary condition? Experience and knowledge. The more you know about how computers and the algorithms you are using work the better you can identify boundary conditions to test. Trying for exact accuracy (for non-integer math) is definitely a boundary condition, especially when the OS overhead introduces timing uncertainty for iteratively determined values.
If I absolutely needed this accuracy and it to be stable between runs I would establish non-absolute boundary conditions (as a very rough example, rather than %x == 95.68 I would use %x > 95 && %x < 96) and set it to the "exact" value. For example, rather than
This presumes that you have mathematically computed tween values that represent points of interest and you're checking to see when they are reached. If it is an iterative process (like moving a sprite) as long as your fuzzy boundary is big enough that a single iteration can't skip past it then it will always catch the condition. The key to making it looks smooth is to use enough iterations.
But don't be fooled by the ability to set extremely small values. The actual granularity of the OS time slice and overhead in context switching means that it isn't as exact as it may look. I would set the iteration value fairly low so it definitely looks chunky and refine from there. When it looks acceptably smooth you have a solution that should work everywhere. Finding the lower bound on the required iterations means the system will be taxed the least to get the result you want. This gives you more headroom for doing other things and also lowers the minimum spec system required to run the game which increases your audience.
I'm still new to coding for games and have only a general idea of what you are trying to achieve so I can't say what a best fit for your game would be. I can warn you that relying on absolute, exact precision in non-integer math is going to lead to problems so using methods that don't rely on that can save you many headaches. I would echo the other suggestions to use equations of motion for trajectory and use that mathematical certainty to guide your projectiles. If you do that then the built-in collision detection should be sufficient for triggering your desired effects. Due to using an equation of motion you know the path the projectile will take so each client should end up with the same path and the same collisions.
Where that gets tricky is if you want to have bounces/ricochets. Due to timing variations the built-in system will give different results between runs or clients (maybe not much, but due to intrinsic timing differences it is safe to assume that at an exact level they will differ and that opens the door for problems when doing exact matches or for chaos to intrude).
In a single-instance game this really doesn't matter. In my (currently shelved) car combat game the player can fire (somewhat) homing missiles in a steady stream at a target. Doing this and watching closely reveals a slight variation in the flight paths. This is because the homing mechanism is based on periodic correction via schedule(). If I ask for 100ms interval (I think that is what I used) it will be close to that, but it is safe to say that it will not be the same value every time. Which means that sometimes the missile moves a little more or a little less before a correction happens. The end result is the same: the missile arcs in toward the target. The exact path, however, can vary.
I have no idea how I will implement networking for that (when I get back to the project), but it is a thorny problem because of all the dynamics. On one client a missile may hit a wall (and so explode) while it may skim just past it on another due to timing differences. One way to handle this is one client is authoritative (the server) and if the missile hits the wall on it this is broadcast to the clients, and clients don't actually remove the missile until being told so by the server.
Another possibility would be to use mathematically defined trajectories and compute my own collisions, but I don't want to do that. In a fast-paced game with a lot of action players aren't likely to even notice if the missile made it by the wall before blowing up. And if network latency is low it might be very close to the wall when it does. Likewise, a missile that doesn't blow up but the client draws overlapping the wall is not likely to be noticed either (as long as the variations are small).
03/12/2006 (8:01 am)
I'm not a torquescript expert, but I don't think it provides for true integer math. Instead, all numbers are always floating point. As long as the expected accuracy is not too high (e.g., adding 1 to 1000000000 and expecting a different number than 1000000000) and trying to avoid absolute comparisons between numbers you don't know are equal (in my previous example if you echo the iteratively computed value you will see 0.3, but it will fail an equals comparison to 0.3) then it should be okay.To put things another way, boundary conditions are where you are most likely to find/expose bugs and other error conditions. Who do you know what is a boundary condition? Experience and knowledge. The more you know about how computers and the algorithms you are using work the better you can identify boundary conditions to test. Trying for exact accuracy (for non-integer math) is definitely a boundary condition, especially when the OS overhead introduces timing uncertainty for iteratively determined values.
If I absolutely needed this accuracy and it to be stable between runs I would establish non-absolute boundary conditions (as a very rough example, rather than %x == 95.68 I would use %x > 95 && %x < 96) and set it to the "exact" value. For example, rather than
if (%x == 95.68) {
// condition processing
}I would useif (%x > 95 && %x <96) {
%x = 95.68;
// condition processing
}This presumes that you have mathematically computed tween values that represent points of interest and you're checking to see when they are reached. If it is an iterative process (like moving a sprite) as long as your fuzzy boundary is big enough that a single iteration can't skip past it then it will always catch the condition. The key to making it looks smooth is to use enough iterations.
But don't be fooled by the ability to set extremely small values. The actual granularity of the OS time slice and overhead in context switching means that it isn't as exact as it may look. I would set the iteration value fairly low so it definitely looks chunky and refine from there. When it looks acceptably smooth you have a solution that should work everywhere. Finding the lower bound on the required iterations means the system will be taxed the least to get the result you want. This gives you more headroom for doing other things and also lowers the minimum spec system required to run the game which increases your audience.
I'm still new to coding for games and have only a general idea of what you are trying to achieve so I can't say what a best fit for your game would be. I can warn you that relying on absolute, exact precision in non-integer math is going to lead to problems so using methods that don't rely on that can save you many headaches. I would echo the other suggestions to use equations of motion for trajectory and use that mathematical certainty to guide your projectiles. If you do that then the built-in collision detection should be sufficient for triggering your desired effects. Due to using an equation of motion you know the path the projectile will take so each client should end up with the same path and the same collisions.
Where that gets tricky is if you want to have bounces/ricochets. Due to timing variations the built-in system will give different results between runs or clients (maybe not much, but due to intrinsic timing differences it is safe to assume that at an exact level they will differ and that opens the door for problems when doing exact matches or for chaos to intrude).
In a single-instance game this really doesn't matter. In my (currently shelved) car combat game the player can fire (somewhat) homing missiles in a steady stream at a target. Doing this and watching closely reveals a slight variation in the flight paths. This is because the homing mechanism is based on periodic correction via schedule(). If I ask for 100ms interval (I think that is what I used) it will be close to that, but it is safe to say that it will not be the same value every time. Which means that sometimes the missile moves a little more or a little less before a correction happens. The end result is the same: the missile arcs in toward the target. The exact path, however, can vary.
I have no idea how I will implement networking for that (when I get back to the project), but it is a thorny problem because of all the dynamics. On one client a missile may hit a wall (and so explode) while it may skim just past it on another due to timing differences. One way to handle this is one client is authoritative (the server) and if the missile hits the wall on it this is broadcast to the clients, and clients don't actually remove the missile until being told so by the server.
Another possibility would be to use mathematically defined trajectories and compute my own collisions, but I don't want to do that. In a fast-paced game with a lot of action players aren't likely to even notice if the missile made it by the wall before blowing up. And if network latency is low it might be very close to the wall when it does. Likewise, a missile that doesn't blow up but the client draws overlapping the wall is not likely to be noticed either (as long as the variations are small).
#48
You can then pass your initial velocity/pos info over the network and should get identical results on both sides. Use TGB physics for particle effects and other stuff not affecting your simulation.
03/12/2006 (9:41 am)
Implementing your own trajectory calculations based on integers and/or table lookups (as previously suggested) should be pretty failsafe against different platforms calculating different paths (as long as you have a solid understanding of the accuracy of your numbers). The local physics updates should be called on every tick (32ms) NOT on a framerate based call... this may be the root of the problem.You can then pass your initial velocity/pos info over the network and should get identical results on both sides. Use TGB physics for particle effects and other stuff not affecting your simulation.
#49
In my game I do want to have things such as anti-air turrets and such. For example, when a projectile is shot from a tank and gets within a certain distance of an anti-air turret, an anti-air projectile is shot towards the projectile trying to destroy it. I can imagine this can cause HUGE out-of-sync issues...
Also, once I have the projectile path (using a function such as Michael's above), should I use just moveTo and setPositionTarget to move it along the line? moveTo requires a speed but I guess I can use various numbers to simulate "faster" projectiles, etc... I'm assuming this will cause certain clients to render faster than others but as long as the end result (eg. collision points) are the same then I guess everything would be OK. My main concern is the anti-air bullets and such though...
03/13/2006 (9:34 am)
Quote:Thanks for the detailed information....
Where that gets tricky is if you want to have bounces/ricochets. Due to timing variations the built-in system will give different results between runs or clients (maybe not much, but due to intrinsic timing differences it is safe to assume that at an exact level they will differ and that opens the door for problems when doing exact matches or for chaos to intrude).
In my game I do want to have things such as anti-air turrets and such. For example, when a projectile is shot from a tank and gets within a certain distance of an anti-air turret, an anti-air projectile is shot towards the projectile trying to destroy it. I can imagine this can cause HUGE out-of-sync issues...
Also, once I have the projectile path (using a function such as Michael's above), should I use just moveTo and setPositionTarget to move it along the line? moveTo requires a speed but I guess I can use various numbers to simulate "faster" projectiles, etc... I'm assuming this will cause certain clients to render faster than others but as long as the end result (eg. collision points) are the same then I guess everything would be OK. My main concern is the anti-air bullets and such though...
#50
If the hit is not guaranteed then how is success determined? If it is automatically aimed then the success should be computable in a repeatable fashion and you do that and then the above.
If the anti-air turrets do something similar to the rockets I described from my car combat game that is a lot trickier. Unfortunately, the math on that is more difficult, but if you set the problem up right it should be resolvable (e.g., an equation to determine if the "homing" missile will connect with ballistic trajectory target). This can then be used to do the foregoing.
I'm sorry I'm not familiar with MoveTo(), I'm assuming that is a function added in the alpha or beta series and allows movement in straight lines to a given destination. Rendering should be sufficiently similar between clients. The major difference would be a faster client might hit a higher frame rate, but the movement itself (when using controlled movement, e.g., with MoveTo()) should be consistent.
If you notice in my analysis above it all revolves around a computational way of determining the collision. With two ballistic trajectories its a matter of looking for an intercept (x,y,t all equal). If its computational then each client can compute it independently, or the server can compute and give the result to the clients. I like the latter because it avoids any possibility of the math being done differently on different systems.
03/13/2006 (10:00 am)
Is the anti-air turret bullet automatically aimed? Is it guaranteed to hit? If so, then all you need is to have the launch triggered and a client draws the result. One way to ensure that each client *does* have them hitting is to use a collision bounding box slightly larger than the objects.If the hit is not guaranteed then how is success determined? If it is automatically aimed then the success should be computable in a repeatable fashion and you do that and then the above.
If the anti-air turrets do something similar to the rockets I described from my car combat game that is a lot trickier. Unfortunately, the math on that is more difficult, but if you set the problem up right it should be resolvable (e.g., an equation to determine if the "homing" missile will connect with ballistic trajectory target). This can then be used to do the foregoing.
I'm sorry I'm not familiar with MoveTo(), I'm assuming that is a function added in the alpha or beta series and allows movement in straight lines to a given destination. Rendering should be sufficiently similar between clients. The major difference would be a faster client might hit a higher frame rate, but the movement itself (when using controlled movement, e.g., with MoveTo()) should be consistent.
If you notice in my analysis above it all revolves around a computational way of determining the collision. With two ballistic trajectories its a matter of looking for an intercept (x,y,t all equal). If its computational then each client can compute it independently, or the server can compute and give the result to the clients. I like the latter because it avoids any possibility of the math being done differently on different systems.
#51
When a projectile comes within a certain distance of the AA turret......
Type #1: AA missile would be fired towards the other projectile. The AA missile would act like a homing missile but could only turn at a certain rate... (it would ignore gravity and act more like a rocket than a projectile).
Type #2: AA projectile would be fired towards the other projectile but if a collision occurs it would knock the other projectile off-course.
Type #3: A ton of AA projectiles are fired straight up and try to blow up the other projectile (no angle).
03/13/2006 (10:19 am)
Ideally I'd like the game to have three different anti-air turrets:When a projectile comes within a certain distance of the AA turret......
Type #1: AA missile would be fired towards the other projectile. The AA missile would act like a homing missile but could only turn at a certain rate... (it would ignore gravity and act more like a rocket than a projectile).
Type #2: AA projectile would be fired towards the other projectile but if a collision occurs it would knock the other projectile off-course.
Type #3: A ton of AA projectiles are fired straight up and try to blow up the other projectile (no angle).
#52
I don't whant to put oil on the fire but as i'm really interested in T2D physics...
So i've buy T2D, because the product page were nice and mention easy Rigid Body Dynamics and above all : because you can't find any deep informations about T2D when you are "outsider" (EULA blablabla : I'm a graphic artist ^^).
And it's true ! For 100$ you got all of this even if some of the features are unfinished because of "early adopter licence" (that seem's over now if you look at the product page...).
I come from Blitz3D and why not choosing blitzMax ? Because of the Rigid Body Dynamics and the impression that T2D is faster AND crossplatform too (not sure anymore... but that not the point).
It's not the first time i play with ODE/TOKAMAK/Physical wrapper but it's the first time that i ear about this physics bug !
Some of you give tricks to get rid of this (but byebye Rigid body)
Even talk about setTargetFPSActive...
What i whant to know is :
1) Does T2D Rigid Body Dynamics is reliable right now (beta 1.1) ?
2) Does ALL T2D collision answer mode are reliable right now too (cause i'm getting troubles sometimes) ?
3) If Rigid Body Dynamics is in fact unstable or not precise enough at this time does T2D Dev have planned Fix ?
Please don't get me wrong, I'm new to T2D and i just whant to produce something really cool with it.
My english level is quite average too... And i don't whant to put discredit on this wonder ;)
But i don't whant to loose too much time dissuade myself on tweaking something unreliable.
Learning tricks to by-pass Rigid Body maybe gratifying after all (even if it's Torque 2D without torque ^^).
03/13/2006 (6:02 pm)
This thread's getting really big ^^I don't whant to put oil on the fire but as i'm really interested in T2D physics...
So i've buy T2D, because the product page were nice and mention easy Rigid Body Dynamics and above all : because you can't find any deep informations about T2D when you are "outsider" (EULA blablabla : I'm a graphic artist ^^).
And it's true ! For 100$ you got all of this even if some of the features are unfinished because of "early adopter licence" (that seem's over now if you look at the product page...).
I come from Blitz3D and why not choosing blitzMax ? Because of the Rigid Body Dynamics and the impression that T2D is faster AND crossplatform too (not sure anymore... but that not the point).
It's not the first time i play with ODE/TOKAMAK/Physical wrapper but it's the first time that i ear about this physics bug !
Some of you give tricks to get rid of this (but byebye Rigid body)
Even talk about setTargetFPSActive...
What i whant to know is :
1) Does T2D Rigid Body Dynamics is reliable right now (beta 1.1) ?
2) Does ALL T2D collision answer mode are reliable right now too (cause i'm getting troubles sometimes) ?
3) If Rigid Body Dynamics is in fact unstable or not precise enough at this time does T2D Dev have planned Fix ?
Please don't get me wrong, I'm new to T2D and i just whant to produce something really cool with it.
My english level is quite average too... And i don't whant to put discredit on this wonder ;)
But i don't whant to loose too much time dissuade myself on tweaking something unreliable.
Learning tricks to by-pass Rigid Body maybe gratifying after all (even if it's Torque 2D without torque ^^).
#53
Your questions mostly come down to "depends on your game" as the answer.
1. For my RPG prototype, platformer prototype, and shooter prototype, TGB's physics have been great. But I don't know if they would be perfect for your needs since I don't know your needs. pixel-perfect networked joint dynamics might not be as accurate with a few hundred players on different systems or OS's.
2. What are you having problems with? Granted my physics have been limited to the needs of my games so I do not claim expertise. But I'm sure others can help.
3. I have no idea what is in the timeline for TGB.
03/13/2006 (6:59 pm)
I think the main decision about chooseing TGB over BlitzMax would be whether you wanted an engine or whether you wanted to build your engine (as Blitz is a language which you use to build your engine). And if you do not decide to use the physics project for Blitz (coming along very nicely), your options are to roll your own or use a 3D solution such as Newton or ODE (if you want cross-platform) or Tokamak orAegia if you do are only targeting windows. That's my take on choosing between BM and TGB in many ways. I own both and love both. But I see them as very different target markets.Your questions mostly come down to "depends on your game" as the answer.
1. For my RPG prototype, platformer prototype, and shooter prototype, TGB's physics have been great. But I don't know if they would be perfect for your needs since I don't know your needs. pixel-perfect networked joint dynamics might not be as accurate with a few hundred players on different systems or OS's.
2. What are you having problems with? Granted my physics have been limited to the needs of my games so I do not claim expertise. But I'm sure others can help.
3. I have no idea what is in the timeline for TGB.
#54
Second, how does TGB handle cases when the redraw rate is lower than the server rate?
I assume TGB is server client even when not networking, otherwise we are al F*cked.
03/14/2006 (1:29 am)
First, does TGB physics update at a constant server rate, independent on framerate?Second, how does TGB handle cases when the redraw rate is lower than the server rate?
I assume TGB is server client even when not networking, otherwise we are al F*cked.
#55
Second, how does TGB handle cases when the redraw rate is lower than the server rate?
I assume TGB is server client even when not networking, otherwise we are al F*cked.
03/14/2006 (2:11 am)
First, does TGB physics update at a constant server rate, independent on framerate?Second, how does TGB handle cases when the redraw rate is lower than the server rate?
I assume TGB is server client even when not networking, otherwise we are al F*cked.
#56
@ Bucko: I haven't looked at the engine code since pre alpha and don't remember much from then anyway. But it isn't a client/server model unless you program it to be. I'm not sure why you think that is a problem. If you write a single player game it doesn't make sense to burden you with client/server semantics. If you do then you have client/server commands to communicate back and forth. If the (admittedly rather limited at this point) built-in networking is insufficient for your needs you do have the source code to improve on it.
Given Melv's original plans on the subject I believe much more is intended for the networking, but I obviously can't speak for Garage Games.
03/14/2006 (5:55 am)
@ Seelen: Where some people have an issue with the built-in physics is with networked games. Basically, a simplistic approach assuming that there will be no variance without some means of correction will not work as expected. If you game isn't networked or you do something to keep the clients in sync this is not an issue. As to whether or not T2D will suit for you is a question I certainly can't answer.@ Bucko: I haven't looked at the engine code since pre alpha and don't remember much from then anyway. But it isn't a client/server model unless you program it to be. I'm not sure why you think that is a problem. If you write a single player game it doesn't make sense to burden you with client/server semantics. If you do then you have client/server commands to communicate back and forth. If the (admittedly rather limited at this point) built-in networking is insufficient for your needs you do have the source code to improve on it.
Given Melv's original plans on the subject I believe much more is intended for the networking, but I obviously can't speak for Garage Games.
#57
In this specific case, the client would send the shot info to the server (velocity/angle/etc) and the server would precompute the outcome. Basically, given the data, does the shot hit or not. It would then send the 'animation' data back to the clients for playback. If physics gets you close enough, then just send that info and let it rip. If you need an exact computation, send the path to each client, or use one of the other methods above to make sure the object hits.
In a real time environment things would have to be quite a bit different, as real time syncronization is far more hacky and special case than turn based events. At Turbine, we actually handled this at the language level by having each script node (visual language) present it's syncronization options to the user; basically, who is authoritive over the action (client or server), and what type of recovery is used for desyncronization errors (does the client undo the action, or allow it to stand?). Since I'm doing a similiar style game to yours, but realtime, I'll probrably have to deal with some of this in my server model. Ugh..
03/14/2006 (2:07 pm)
Personally, I think the physics is perfectly fine for a networked game. The problem is in expecting the physics to simply handle everything from that point on. If the game is running in a client/server model, the server should be the authorative one in what actually hits, not the client.In this specific case, the client would send the shot info to the server (velocity/angle/etc) and the server would precompute the outcome. Basically, given the data, does the shot hit or not. It would then send the 'animation' data back to the clients for playback. If physics gets you close enough, then just send that info and let it rip. If you need an exact computation, send the path to each client, or use one of the other methods above to make sure the object hits.
In a real time environment things would have to be quite a bit different, as real time syncronization is far more hacky and special case than turn based events. At Turbine, we actually handled this at the language level by having each script node (visual language) present it's syncronization options to the user; basically, who is authoritive over the action (client or server), and what type of recovery is used for desyncronization errors (does the client undo the action, or allow it to stand?). Since I'm doing a similiar style game to yours, but realtime, I'll probrably have to deal with some of this in my server model. Ugh..
#58
Currently my game isn't networking (im rather in a "testing phase" right now) but i'm sure as soon i'm ready with T2D i will use Networking !
Not only networking have issues with physics. For example i've made a tiny simulation in windowed mode, switch to msn to answer good friend and the simulation begin to shake and goes crazy :(
The same effect append sometimes only because i get low fps with my Radeon9200se (i never go over 100fps without vsync) or when i drag the window title bar.
It is why i thing physics aren't perfect at this time. I only wait someone at GG show me how to correctly setuping a physics simulation to get rid of this cause it's probably a misunderstanding.
03/15/2006 (7:35 am)
@Tim DotyCurrently my game isn't networking (im rather in a "testing phase" right now) but i'm sure as soon i'm ready with T2D i will use Networking !
Not only networking have issues with physics. For example i've made a tiny simulation in windowed mode, switch to msn to answer good friend and the simulation begin to shake and goes crazy :(
The same effect append sometimes only because i get low fps with my Radeon9200se (i never go over 100fps without vsync) or when i drag the window title bar.
It is why i thing physics aren't perfect at this time. I only wait someone at GG show me how to correctly setuping a physics simulation to get rid of this cause it's probably a misunderstanding.
#59
03/15/2006 (7:52 am)
Quote:Honestly, I disagree. Physics in TGB need a lot of improvement over little issues.
Personally, I think the physics is perfectly fine for a networked game
#60
@ Seelen: I can't comment about your statement as too many particulars are unknown. My last project was done before the alpha and works quite well despite a bug in the engine (fixed in the alphas BTW). I accomplished what I wanted with the project -- it was more of a demonstration than anything else -- though it isn't a complete game. What I did have was numerous objects that used rigid body physics with some modification/extension done entirely in script using the onCollision() callbacks. It would have worked much cleaner modifying the engine, but it was quicker (and dirtier) to do it his way.
The "bobbles" bounced around the screen, split, merged and changed color. There were sceneObjects mounted to the bobbles to manage "forces" which varied with the size of the bobbles. Computations additionally accounted for the distance between. Given all of these factors there were usually multiple collisions being resolved in each frame. And yet I could throw in things like a timer made up of sceneObjects that stayed grouped as a bundle and could interact physically with everything else (rigid body physics, caused rotation, etc.).
Yes, there was a limit to how many objects could be handled on the screen before getting a slow down, but the physics wasn't a problem at all (aside from the aforementioned and worked-around bug that has been fixed since then).
I'm not trying to say there isn't a bug, but I am noting that I haven't seen a "haywire" problem. What does haywire mean? Is it herky-jerky from being slow? In fact, is it any kind of performance issue or is it a bug-related issue.
Performance issues can be addressed any number of ways depending on the specifics. Bugs are handled by bounding the problem and getting them fixed. A good bug report will be well received.
03/15/2006 (4:22 pm)
If you read Melv's material on networking (sorry, I don't have a link, but a search should turn it up) there is a lot missing from the present networking. And I don't think anyone from GG would disagree. Now, what is there is certainly good enough for many uses, including certain network games. My current effort (which won't see serious work for at least a week, unfortunately) has minimal demands on physics and, being absolutely turn based, has minimal requirements on networking. There are things I could make work better by modifying/extending the engine, but it would be a waste of effort given my limited time for development.@ Seelen: I can't comment about your statement as too many particulars are unknown. My last project was done before the alpha and works quite well despite a bug in the engine (fixed in the alphas BTW). I accomplished what I wanted with the project -- it was more of a demonstration than anything else -- though it isn't a complete game. What I did have was numerous objects that used rigid body physics with some modification/extension done entirely in script using the onCollision() callbacks. It would have worked much cleaner modifying the engine, but it was quicker (and dirtier) to do it his way.
The "bobbles" bounced around the screen, split, merged and changed color. There were sceneObjects mounted to the bobbles to manage "forces" which varied with the size of the bobbles. Computations additionally accounted for the distance between. Given all of these factors there were usually multiple collisions being resolved in each frame. And yet I could throw in things like a timer made up of sceneObjects that stayed grouped as a bundle and could interact physically with everything else (rigid body physics, caused rotation, etc.).
Yes, there was a limit to how many objects could be handled on the screen before getting a slow down, but the physics wasn't a problem at all (aside from the aforementioned and worked-around bug that has been fixed since then).
I'm not trying to say there isn't a bug, but I am noting that I haven't seen a "haywire" problem. What does haywire mean? Is it herky-jerky from being slow? In fact, is it any kind of performance issue or is it a bug-related issue.
Performance issues can be addressed any number of ways depending on the specifics. Bugs are handled by bounding the problem and getting them fixed. A good bug report will be well received.
Torque 3D Owner Stephen Zepp
Not trying to be insulting, but that is absolutely an incorrect statement. Torque does not ever network physics states whatsoever.
The closest it comes is allowing client side prediction of client moves to the client side simulation prior to sending the move to the server for authoritative physics processing. It then receives the updates (positional, not force related whatsoever) and interpolates any prediction errors it originally made to conform with the server's physics.
I know it sounds like I'm mincing words here, but the two descriptions are in fact wildly different.