How easy is it to network TorqueX? (eg. sync object movement)

#1

Quote:I realize that XNA and TorqueX do not provide any networking support

Why do people keep saying this? I've replied like 1000 times to this same statement! TorqueX/XNA don't have CUSTOM networking (as in they didn't do anything to add additional network support for us) but the .net framework has built in networking through the System.Net namespace. You can use UDP, TCP/IP, etc.

#2 This topic is one that could take weeks to discuss, but I'll throw out a couple of points:

--Torque X does not support any networking in and of itself, since it is based on XNA which does not have networking. Of course, what Jonathon says is very true.

--While there is no networking support currently, the original team members of the Torque X initiative were Clark Fagot and John Quigley--two of the top guys at GG on the engine development side when it comes to networking. All of the currently implemented systems and mechanisms were designed with networking in mind, although to be right up front about it: until we know what XNA releases for networking, we can only make educated guesses, not 100% accurate synchronized systems.

--one of the key concepts of synchronized networked physics is the concept of fixed tick physics--which is exactly what Torque X allows (it's not mandatory, so if you base your projects on variable tick physics things can become more complex). Additionally, the concept of control objects exists in the system (the Player Manager and how it works).

--another key concept is the ability to send a variety of partial state, latest state, minimalistic data sets, and various degrees of guaranteed data. None of this is implemented.

--the other major concept when it comes to networked synchronization of simulations is a set of policies that handle simulations running on different time slices--specifically (network) interpolation (not to be confused with interpolateTick(), which is part of rendering interpolation), extrapolation, and client side prediction, and the ability to unwind and rewind the individual simulation's physics for certain objects to apply server directed updates. None of this is implemented at this time.

If you fully understand client-server networking and simulation synchronization (or are at least willing to dig through white papers, TGE/TGE-A code, and other resources), you won't find any "can't do this with Torque X's systems" gotchas...but it's going to be quite a bit of work depending on what your end goal is.

#3 I can agree with Stephens comment that nothing prevents you from doing this. I've done it for a simple action game, and even though it was one of the more challenging things, works pretty well (at least with good connections). You need to implement most of the things Stephen mentioned yourself, but the engine and the ticking system is well suited for that.

There's one issue in the engine that you should be aware of, but there's an easy workaround. There's also more topics in the forum you might find helpful.

Matias

#4 Thanks for all of the replies everybody.

I'm aware of the System.Net library and that is what I plan to use for networking support (or perhaps the Lidgren Network Library), but I'm not sure how to synchronize objects, etc.

I'm familar with the tick concept and how updates are sent every xx ms (32 by default?) but I don't know how to keep things synchronized, etc. (for example, in the thread mentioned above it appears as though ticks must be saved for rewinding or reticking... what does that mean?)

Also, if you implement networking, you can't use the built-in TorqueX physics system, right? (I assume collision detection would still work fine though)

#5 There are many ways of keeping things synchronized, and it all depends on what kind of game you're making. At minimum the client sends updates about player events (key presses) and server about game state updates.

The comment about rewinding and reticking is about what to do when you receive a "late packet" from server. I.e. when server says that something happened in the clients past, one solution is back up to that point, make the change and again forward to current state. And you can do this with Torque physics system also.

There's a lot information available:
opentnl.sourceforge.net/doxydocs/fundamentals.html
www.gamedev.net/community/forums/showfaq.asp?forum_id=15
developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

#6 As a theory purist, one slight addition to what Matias mentions:

By definition, if you apply user inputs directly to the client onto a specific control object and then send that move information to the server for an authoritative decision, (the authoritative server acting as "the boss"), all updates sent on that control object are "late"--the move has already been applied to the client simulation in a prediction mode, but an authoritative update comes down the network pipe at a "later" time.

This little thought of issue means that you have to have some form of compensating for clients being both behind and "in front of" the server when it comes to time, and is one of the reasons why people view multi-player games as a black art :)

#7 I've been hearing that TorqueX is waiting for XNA for network support several times but no one talked about when and what exactly XNA network entails.
As far as I understand, the low level stuff to send packets through UDP/TCP/IP is no brainer.
But the syncronizing objects is something what considered to be complicated and depends on object system design.
TorqueX is built on XNA however, Torque objects need their own syncronization system independent from XNA objects, no?
Therefore if we are just waiting for XNA to support low level networking stuff, I don't see a point of waiting.
If XNA will have syncronization support, it may be worthwhile to wait. But who know what that may be...
Anyone has any info regarding XNA networks?

#8 I think that kind of feature (networking) is something that is extremely game dependent, and I would personally have GG spend their time on improving the graphics, (something I cant do) and spend my own time figuring out how to serialize and send game data (something i can do)

#9 @Jason, true, network is very game dependent at the highest level but there are syncronization stuff that transcend all games, namely, dead-reconing, serializing properties depending on importance/reliablility, peer-to-peer and client/server support, and etc. It's pretty involved when you think about it.
It also needs be integrated with the object system to make it as transparent as possible.
Right now, I'm just hacking things up until it gets supported officially.

#10 I have been told by Krishna of http://xnarocks.spaces.live.com/ that XNA 1.5 will have network code in it. This was said [to everyone] when Microsoft presented XNA @ UMBC back in the spring.

#11 Torque X is a product designed to use XNA, which is not just part of the general .NET environment, but a specific subset of functionality (compact framework for one) that is designed to be "cross-platform", in that code written in XNA will run on both Windows and XB360 with 95% code reusability (Microsoft's number, not ours).

We have other engines for non-XNA development, but it doesn't make any sense for us to write any major networking features into Torque X until XNA writes in the capabilities that work on both windows and XB360. If we were to write in anything at all, it would be almost guaranteed to not work on the 360, and not only would we have to re-write the networking once MS releases the next version of XNA (that includes, I have no info on if Pauliver's statement is correct, although I don't personally doubt it), but you would have to re-write your games as well.

#12 @John Klimek

I've been on a small team developing a game for the past 5 months or so. It's a fully networked multiplayer game running on XNA/TorqueX. So yes, it is possible but not within XNA/TX's design. We had used the Lidgren UDP Networking library to provide client/server connectivity and then wrote an abstraction layer on top of that to power our game code.

Though there isn't a downloadable demo yet, we are doing nightly tests with people and it is running just fine. Screenshot in our news post: www.enddream.com

#13 @Alex: Are you using any TX physics or collision detection? I don't understand how you can synchronize physics objects, etc...

#14 We aren't using TX's built in physics/collision, we had coded our own prior to TX and just ported it to work with TX. But I don't imagine it would be wildly different in terms of concept for network syncing.

Quote:
Does anybody have any thoughts on this? I'm guessing I would need a custom networking component that processes every tick, but only sends data every XX number of ticks. (whats a good rate?)

A networking component would be doable. At the beginning we designed our networking to be based around 'NetObjects'. NetObjects are a subclass of T2DSceneObject. And anything that needed to be ghosted to clients and updated regularly would be subclassed from NetObjects. In retrospect making a NetworkComponent would have probably been cleaner and more re-usable, but at the time we weren't too familar on how TX worked with components and sceneobjects so we designed it as if we were starting from scratch. Later on, we added a type of Network Syncing component that could be added to network objects. This component could control what data was sent and how often it was sent, so we had more refined control over how often things would be updated. For example, instead of sending all of the player data as a large packet frequently, we could send critical pieces more frequently like position and velocity but less important things like scores and stats much less frequently.

As for the rate of updates it really depends on the type of game I believe. fast-paced games of course need more frequent updates than say a turn-based game like chess or something. But the overall goal should be to minimize network traffic. Whenever we coded a new net object we'd generally start out at 1/2 second to a full second ticks for syncing and then tweak from there to get mostly smooth gameplay.

#15 Very interesting Alex, sounds like a cool solution.

Have you had problems with integrating game logic to your syncing? For certain things it's not enough to just update the value, but you need to do some context aware manipulations. I ended up defining explicit message objects and handlers for them in order to include that logic. The down side is that there's some duplication of trivial value parameters in the objects and messages.

But sounds cool,
Matias