How easily can I implement real-time networking with TorqueX?

#1 XNA has built-in networking for PC games, just not for Xbox360 games. If you are targeting the PC, then you already will get networking support from TXE through the XNA framework. You use the System.Net namespace to access the networking layer.

#2 Thanks for the reply...

I'm aware of the System.Net namespace (which is part of the .NET framework and not XNA, if I understand correctly), but I'm not sure how I would use this to interface with TorqueX.

For example, how would I keep objects in sync, etc, etc...

#3 Yes, System.Net is for .net, not XNA.

Any C# networking library (or any other language so long as it's .net) should work fine with TXE.

www.c-sharpcorner.com/Networking.asp
www.lidgren.net/wiki/doku.php?id=lidgren.library.network

The second one is UDP only.

If you want TCP, check out the first link as using System.Net is fairly straightforward.

GG? Are you guys planning networking support in the near future? If not, I might just toss together a basic networking component.

#4 Garage Games engines in general have very robust support for networking integral to their structure. However, I don't think it's available in TGBX yet, because it's still in Beta, and also I think MS is still working out some details as it pertains to the XBOX. I think you need to be patient and wait. Perhaps an GG Employee can confirm?

#5 We cannot implement Torque X specific networking until Microsoft lays out how they want XNA GSE to handle cross-platform (360 specifically) networking.

Once Microsoft produces their XNA layer for 360, we'll implement it as well (at a delay of course, we have to take what they have and work from it).

#6 Can I somehow interface the existing TorqueX engine with my own networking layer?

If so, can you give me any pointers on where to start? (eg. every tick of TorqueX I would need to send data across the network I'd guess?)

#7 If you could, I don't think it would be supported on the 360 platform

#8 Right, it wouldn't work on the 360 but that's OK.

I'd like to use TorqueX only for the PC (for the time being).

#9 @Stephen - Thanks for the info. Have you heard from MS about a cross-platform networking layer and timeframe? I assumed it would be two seperate layers since you use TCP/IP and UDP for PC and you utalize XBL for the 360 which, from what I've read, are quite different.

@John - Is your networking layer in .net?

#10 @JohnK - you certainly can interface TorqueX with your own networking layer. How you do it depends mostly on your networking layer. You can access the position and velocity of objects pretty directly. I guess you'd then just send those over the wire and do whatever interpolation corrections you need.

At some point we'd certainly like to integrate TNL with TorqueX and we set the engine up with this in mind (which is one reason why we have a ticking mechanism rather than simply updating by variable time). But as Stephen mentioned we are still in a wait and see state on that one.

#11 I should also add that turn based networking (which is all scorched earth needs, right?) would be much easier than real time networking. For turn based networking you'd simply introduce some sort of hand shaking scheme and exchange moves between peers as they happen with no need to be in exact synch between the peers.

#12 @Jonathon: I haven't written any networking layers, but whatever I write (or use) will be in .NET.

@Clark: The problem with exchanging moves is that if I simple say "fire a projectile at 20 degrees and 100 strength", and then let TorqueX take over is that the projectile will not follow the same path and will not collide in exactly the same spots on every machine. This is the problem I had with creating my game in TGB (which I also own along with TGE).

If I could somehow use TorqueX's physic engine in a deterministic manner (eg. every machine would perform the exact same way) that would solve nearly every single problem for me.

#13 Send "fire at 20 degrees, strength 100, impact at point ____" and whatever else you feel would need to be duplicated.

#14 @John - You can roll your own then in .net and tie it into TXE as Clark has stated. There are some networking APIs already out there if you see my links a few posts above this one.

I was about to say what Ben said so I'll just elaborate a bit. If you 'look ahead' at where the 'firing at 20 degrees at 100 strength' would put the projectile, then you can simply tell the rest of them where the projectile needs to end up and compute the rest depending on what's up.

#15 @Stephen - Thanks for the info. Have you heard from MS about a cross-platform networking layer and timeframe? I assumed it would be two seperate layers since you use TCP/IP and UDP for PC and you utalize XBL for the 360 which, from what I've read, are quite different.

Is there a real reason to be waiting for MS to decide on 360 support? The Creator's Club is quite limited in what you can and can't do (at least in the immediate future)... it'd seem to be more appropriate to target the Windows platform where there aren't those limitations.

#16 The creator's club is limited because XNA is limited. XNA has no built in way to handle Xbox Live, which is the platform used for networking Xbox360 games.

#17 @Johnk - you can handle lack of determinism in a couple ways. We actually faced this with our billiards game which was done in T2D.

The initial way that we handled it was to do something similar to what was suggested by a couple people above: send not only the initial move but the end result, and then make any corrections when the move is over. In pool we went to the extreme of recording when each collision was supposed to occur and what the resolution was supposed to be.

That isn't an elegant solution but it did the job.

The second way to do it, and the preferred method if you can pull it off, is to make things deterministic or damn close to it (cross platform issues can make this impossible, e.g., different fpu results, but you can get pretty darn close). The most important ingredient for determinism is to have constant ticks. T2D didn't have constant ticks when we did billiards. Adding fixed ticks made the game much more deterministic (and in fact we probably didn't needour brute force solution in the end but redundant solutions isn't a bad thing). TorqueX uses constant ticks so you will probably have better luck than you did in T2D initially. (Melv has since patched up T2D to have fixed ticks so you should have better luck with T2D now than you did before).

BTW, tracking down things like sources of indeterminism is a fun task. I've been meaning to post a plan on GG one of these days about a couple technical issues I worked on for the billiards team, including deterministic performance. Other than constant ticks, the next biggest source of indeterminism was controlling the order that collision responses were computed. By default, the order depends on the order that balls are returned from the container query when the striking ball moves. That can be pretty random, so it's important to sort the balls by number before applying the collision response.

#18 Yeah, that Billiards game is exactly what I'm looking to do... (deterministic physics)

Quote: In pool we went to the extreme of recording when each collision was supposed to occur and what the resolution was supposed to be.

So you kept some kind of consistent time across all clients? ...and what does the resolution mean?

Quote:The most important ingredient for determinism is to have constant ticks.

I think you are referring to SetPhysicsFPSActive() and it's related calls. It causes the physics engine to run at a fixed rate. However, if a client can't keep up with the minimum physics FPS rate then it will start to iterate and become non-deterministic (if I understand everything correctly).

Any more information you can give me on how you did Billiards would be GREATLY appriciated.

Thanks!

#19 @Johnk -

(Note: when I say "we" I mean GG, of course. I only worked on billiards a little. Robert Blanchette Jr. was lead and did the multiplayer code).

No effort was made to keep time consistent, but generally two computers will advance time at the same rate just because those time chips are pretty accurate. But the observers move would always begin a second or so after the actors move.

Resolution = collision resolution.

Original T2D used a mechanism like SetPhysicsFPSActive to give you constant time updates as long as the computer could handle the rate. That doesn't work since it fails on slower computers. You need constant ticks. T2D has this now (maybe that version hasn't been released yet but it will be soon) and TX has had this from the beginning.

For scorthed earth, you should be fine using constant ticks.