Real-time Networking

#1 I am in exactly the same situation as you are... (I'm also considering regular Torque to build a 2.5D game in 3D)

All I want in TGB is real-time networking. If TGB didn't add a single new feature except real-time networking (and bug fixes) I would be absolutely THRILLED.

However, Garage Games seems to be extremely silent on TGB networking. The answer I've gotten for past six months is "Real-time networking has not been implemented."

Heck, I'd pay another $50 right now if somebody promised me real-time networking within a month or so.

#2 If you want real time networking now, you can add it yourself (if you have TGE) by following the TDN article I wrote on it.

If you do that, then you will understand why there's quite a lot more then a month of work to make an implementation general enough for the average TGB user. However, for a game specific implementation, its not really that hard provided you know what you're doing.

T.

#3 Tim,

I don't own TGE, but I'm willing to purchase it for the sole purpose of adding networking to TGB...

However, I'm unsure on something...

Do the changes listed in your article allow synchronization of objects between clients and servers?

For example, in my game it uses the physics engine to launch a projectile across the screen. Would your changes allow every client to have the projectile in the same exact position? (eg. automatic location synchronization)

I've read the TDN Wiki about "ghosting" and from what I've read it sounds like it is what TGE/TNL uses to have the server automatically keep objects in sync. (eg. you set the ghost flag and everything else is taken care of for you) Is this correct? Do your changes allow this?

To summarize, all I'm wondering is if your changes would allow me to make simple games and keep player and objects locations in sync with each other......

#4 It provides working networked datablocks (datablocks are "broken" in TGB because they were repurposed) and working ghosting, etc. Proper scoping is game specific and thus you will need to implement it for your game, but thats dead simple.

The big problem, and this is what takes the time, is that no TGB objects are networked. So, anything that you need networked, you will have to write the neccessary code yourself. It's not generally that hard, but for things like players and projectiles, you're probably going to have to implement client side prediction.

You will also find that some design decisions made about TGB in the early days (particularly the repurposing of datablocks) will bite you in the ass when it comes to networking. The only viable solution here is to fix TGB so that it does things in the "correct" way. This is another big time sink, especially where the C++ API passes around names of objects rather then pointers. I'm thinking mostly of the tile map code there, so may not be relevant to you.

T.

#5 It didn't sound that bad until you said "client side prediction".

From your article on the wiki it seems like most datablocks are easy to implement pack/unpack methods (which I assume is all that is really needed?).

How would you even go about implementing client side prediction? It seems like doing this in 2D would be MUCH simpler than it's 3D counterpart, but I'm guessing it's still rather complicated. I'd try implementing this myself, but I'm not sure I would be able to.

It would seem like all objects would be handled the same way though; they keep moving in their current direction with their current velocity until a new network update comes along, no?

I really appriciate your help and information on this!

#6 The best way to get up to speed with that kind of stuff is to look at how TGE does it. The implementation for T2D would be fairly similar.

You're correct on the datablock thing. They're really easy to get networked, and in fact can be done mostly with copy/paste and a couple of macros. The net objects would be a little tricker, but its not rocket science. Unless, of course, you're making a rocket based game ;-)

T.

#7 Could'nt the TGE article on networking be made viewable for TGB owners? I think that'd really help.. I don't really like the idear of paying a hundred bucks to view some article..

thanks :)

#8 I think it uses code from TGE so you need to have the license to view it.

#9 Tom is right... it wouldn't be much use without TGE since a lot of what it explains is in the TGE networking code.

#10 Hi

I looked at the realtime networking article on the wiki , is there some way that we can receive the relevant code needed from tge (even if modified etc.) ,
because buying tge just for the code is not really a great option ?

Or can someone perhaps point to the code in the opentnl.org library ?

Thanks guys

#11 @Le Roi
You will run into a number of problems with combining TNL and TGB. If you search the forums, you'll find where Tom noted some of the difficulties he had with it and the reasons he used TGE. Plus, it would be a much wiser investment for an indie to purchase TGE ($100) than TNL ($295) since the GPL is incompatible with the TGB licensing scheme.

What I would recommend first is to dig into the TGB networking model and see if it fits your game. From your other topic, it doesn't seem that you've done that yet. For a lot of games, it is a great fit. For some, not so much. If you're making NetLumines, it could be used nicely. If you're making MMORadiant Silvergun, you might have a couple of problems.

#12 Thanks for clearing that up ,

Yes I'll spend some time with the networking layer of TGB - its just i've been looking and I can't seem to find documentation about the available script functions / callbacks that use the networking layer ? -
where should I look for this ?

Thanks
Le Roi