Game Development Community

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 =)
Page «Previous 1 2 3 Last »
#1
03/08/2006 (10:56 am)
Hmm, I wouldn't try using too much physics over a network at all. T2D's physics model is what has led to the "turn-based multiplayer" reasoning behind it. Physics over networks isn't a good idea (from what I understand). I'd shut off the physics and just use some vector math to fire your projectiles. Physics is just too much work/syncronization for the server.

I think it works something like this:

1) You fire a missle at an opponent from your machine (client)
2) Then your machine sends the position of your missle to the server every (let's say) 1/2 second
3) The server then sends those "1/2 second positions only" to your opponents machine (or everybody's machine)
4) Your opponents machine then interpolates between them and draws the missle on his machine on the path that you fired your missle on

The same principle works for everybody's position in the game world. Positions are transmitted in short, timed intervals to the server which are gathered by everbody's machines, interpolated, then drawn.

I'm sure it works pretty close to this. Any corrections are welcome. :)

Edit: So, with that in mind, every T2D client should perform exactly the same (minus issues out of your control, like one player is on 56k, the other two are on high-speed, etc).
#2
03/08/2006 (11:35 am)
Chris - I'm pretty sure T2D physics are going to be entirely realtime network ready for release.
#3
03/08/2006 (11:49 am)
Thanks for the reply...

However, what I'm talking about is having each client perform the physics and not worrying about the server for synchronization.

For example, the server would tell the clients "Fire bullet from 100, 200 at a velocity of 300 at 45 degrees". Each client would then spawn a bullet at 100, 200 and use setImpulseForcePolar to fire the bullet.

What I'm wondering though, is if each client would perform the physics exactly the same (eg. would the bullet land in the EXACT same spot on each machine).
#4
03/08/2006 (12:08 pm)
In the current beta 1.1 I don't bet in that.
My player jumps slightly different in different
machines with different specs.
In alpha stage that was obvious
now is slightly perceivable...
Try for yourself if your game lowers its FPs below 15 or 10 fps
even for an instant the physics go nuts...
#5
03/08/2006 (12:23 pm)
Hmmm... that kind of makes the physics engine kinda worthless, huh? (if it doesn't act reliably on all machines) It also makes the multiplayer aspect of my game near impossible... (which was going to be the MAIN aspect of my game... [single player games are boring])
#6
03/08/2006 (1:09 pm)
Quote:
Chris - I'm pretty sure T2D physics are going to be entirely realtime network ready for release.

No.
#7
03/08/2006 (1:58 pm)
Quote:
It also makes the multiplayer aspect of my game near impossible...

You don't have to use the physics engine. Calculate the projectiles' paths via some mathematical formula that does not depend on the physics engine. You can still use the collision system and everything else. And you can use the physics where it doesn't matter if they are out of sync (effects..).
#8
03/08/2006 (6:00 pm)
Where/How would I use custom physics? How would that prevent the problems of the built-in physics engine? (are there any tutorials/examples of doing this?)
#9
03/08/2006 (6:56 pm)
The collision callback
#10
03/09/2006 (8:13 am)
Huh? What do you mean?

The physics move the object and if the object isn't moving to the EXACT same place on every computer then I don't see collission detection (eg. the collision callback) could help...

On one computer maybe the objects didn't even collide? (assuming the physics were calculated differently on each machine which is what you're saying)
#11
03/09/2006 (8:22 am)
You can do your own interpolation set up in engine manually.
#12
03/09/2006 (8:46 am)
I'm sorry but I'm still not understanding....
#13
03/09/2006 (9:06 am)
It's just that you don't use the physics system for anything that needs to stay in sync on every client. You can use a mathematical formula for calculacting the trajectory of the projectiles. Something like a parabola or a top-down square function. The client sends the parameters for the function to the server, the server sends it to the other client. Then you let the projectile follow the parabola with setPosition. Something like that.
What Matt means is that you can still use the collision callbacks to determine when a collision happens.
#14
03/09/2006 (9:50 am)
Ok... what functions should I look at for drawing the parabola, etc? (some kind of onTimer function?)

Would I do it time-based or constantly update the velocity?

For example...

Method #1:
x = (velocity_x * cos(a)) * time;
y = (velocity_y * sin(a)) * time - (gravity * t^2)/2;

Method #2:
x = obj_x + velocity_x;
y = obj_y + velocity_y;

Thanks for the help guys...


EDIT: TGB can't export it's physics functions somehow does it? I mean, can TGB calculate my formulas and then I can send them to each client?
#15
03/09/2006 (10:06 am)
T2D physics will not operate over the network? That seems kinda lame. So none of the super cool physics will work over the network, which probably means the collision wont either... So what WILL realtime networked games have, rendering?
#16
03/09/2006 (10:34 am)
There is a difference between physics operating over a network and guaranteeing that all of your physics needs will be met in a networked environment with 100% efficiency. I do not doubt that physics will be possible in real-time networked games, but it would be dependent upon your needs and testing to determine just how accurate you need them to be. The key would be determining which elements need to be networked rather than having everything be. Just like most network setups.

Of course, I've also only used the rudimentary basics and haven't even gone through the checkers demo code yet, so I have no idea how much will or will not be there.
#17
03/09/2006 (10:49 am)
Maybe I'm still confused or something, but my game is not real-time. It is turned based. I do not need clients to be updated every second of each projectile.

All I need is for the physics to work reliably. That means every computer would render the projectiles at the exact same spot on each computer...

For example, if I fire a projectile at 45 degrees at 100 force. That projectile should land in the EXACT same spot on each computer. If it doesn't, that means the physics are broken...

This really doesn't have anything to do with networking. All it has to do with is having Torque2D physics perform the exact same way on every machine... Physics should not be machine-dependant (eg. higher framerate means the projectiles moves further? Huh?? It shouldn't work that way...)
#18
03/09/2006 (11:13 am)
The problem with the physics system is that floating point operations are not accurate. The small errors in calculation build up over time until they are noticable. Since different machines (and even the same machines at different times) got different update-rates these errors are (inpredictably) different too.

so, a projectile at 45 degrees at 100 force can indeed hit a different spot on another computer.

The trick is to do your crucial calculations in a way that these accuracy errors cannot accumulate over time.
#19
03/09/2006 (11:52 am)
T2d physics targets what, 900 or so updates per second? and each of those updates is performing physics calculations on an arbitrarily large data set... and you want to pass that over the network with how many clients?

I think the point that should be made is that, as a developer, your job is to aproximate your world so that it behaves reasonably well under the conditions you need. If you need networking type physics, then stock t2d physics isnt going to work for you (at least not in the traditional sence.. you could for instance pass via network when collisions happen, but collisions != physics), just like if you want a game MMO with 10,000 players, stock *anything* isnt going to work for you.
#20
03/09/2006 (11:53 am)
A different update rate should not change the physics output, if the result is a different one, then the physic system would definitely be bugged.

In the turnbased situation it theoretically should work without problems.
But if you want to test, I might offer to be the second player. I've a P-M so at least a different CPU architecture than most others have. Although this should not make a difference, as x86 architecture is standardized.
Page «Previous 1 2 3 Last »