Turn-based vs. Realtime Networking...
by C. N. · in Torque Game Builder · 01/03/2006 (5:57 pm) · 3 replies
Hi,
I'm just wondering something about the T2D networking... I'm wondering why T2D doesn't have the same realtime networking like TGE? I read somewhere (in another thread asking a similar question) that it was because of the physics in T2D objects, but I'm asking because: wouldn't TGE objects have at least the same, if not more intense physics (3D physics) for it's game objects? Doesn't TGE have built in physics as well? Wouldn't that make T2D easier for realtime networking?
Sorry, I'm not trying to make anyone tired, lol. I'm just confused about the whole thing.
Thanks.
I'm just wondering something about the T2D networking... I'm wondering why T2D doesn't have the same realtime networking like TGE? I read somewhere (in another thread asking a similar question) that it was because of the physics in T2D objects, but I'm asking because: wouldn't TGE objects have at least the same, if not more intense physics (3D physics) for it's game objects? Doesn't TGE have built in physics as well? Wouldn't that make T2D easier for realtime networking?
Sorry, I'm not trying to make anyone tired, lol. I'm just confused about the whole thing.
Thanks.
#2
From the feedback we've had so far, we seem to be going in the right directlion with people purchasing T2D and then commenting how easy it was just to get stuff working. This probably wouldn't be the case if they had to learn about a client/server model before they began. "It Just Works" is an important aspect of the T2D goals.
It's a fairly short step to "activate" T2D for "realtime" networking. If you look through the code, you'll see commented-out sections that relate to areas that would need altering when a client/server model was in. The core object can also be easily switched to using "NetObject".
The main changes would be the t2dSceneGraph and adding the appropriate streaming values to the "pack/unpack" routines of both the core-object as well as embedded objects such as the physics. The physics integrator would also need some changes for time-control.
Networking has always been on our minds during development and the switch over, whilst complex and time-consuming, shouldn't mean a complete revision of the existing systems. It has, however, taken a lower priority than we originally intended.
- Melv.
01/04/2006 (12:56 am)
Another important aspect has been that we don't want to enforce the client/server model on people who don't want to use it. For starters, it'd be make example scripts more complex and make the step of just "getting up and running" much harder to climb. Ease of use, client-features and stability have so far been the highest priorities.From the feedback we've had so far, we seem to be going in the right directlion with people purchasing T2D and then commenting how easy it was just to get stuff working. This probably wouldn't be the case if they had to learn about a client/server model before they began. "It Just Works" is an important aspect of the T2D goals.
It's a fairly short step to "activate" T2D for "realtime" networking. If you look through the code, you'll see commented-out sections that relate to areas that would need altering when a client/server model was in. The core object can also be easily switched to using "NetObject".
The main changes would be the t2dSceneGraph and adding the appropriate streaming values to the "pack/unpack" routines of both the core-object as well as embedded objects such as the physics. The physics integrator would also need some changes for time-control.
Networking has always been on our minds during development and the switch over, whilst complex and time-consuming, shouldn't mean a complete revision of the existing systems. It has, however, taken a lower priority than we originally intended.
- Melv.
Torque 3D Owner Luke D
Default Studio Name
The more complete answer, again with the limited understanding and knowedge I have, is that in reality the physics and collision systems in T2D are far more complete and robust, focusing on accuracy and flexibility over network functionality whereas TGE's limited physics (the rigid body vehicle physics mostly, and some stuff for projectiles I think) is much thinner an implementation tailored specifically for network performance.
It makes general sense to stabilize the platform and fix bugs in the whole of T2D before implementing network awareness too, aside from the risk of building entire systems that don't lend themselves to network-interopability in the end.