PackData() - unpackData() Tightly Coupled?
by Greg Baker · in Torque Game Engine Advanced · 02/20/2007 (6:37 am) · 2 replies
I'm not entirely sure where the best place for this post would be, so I apologize in advance if this question is better suited to another location.
I purchased TGEA last night and began the process of merging the networking code into TGB Pro using a guideline provided in the TDN for integrating real-time networking into TGB. Before I started making any code changes I spent a couple of hours tracking down and reading through the source code for packing and unpacking datablocks. I wasn't able to go through too many examples, but from the couple of datablocks I did review, it's obvious that there's a very tight coupling between the byte structure of the class and the networking code for packing and unpacking the data.
With the tightly coupled code, I didn't see any mechanism for packing or unpacking dynamic fields. By a dynamic field I'm referring to the ability on the Torquescript side to arbitrarily create new fields for an object. At least I know this is the case in TGB, and I'm assuming this is also true for TSEA. Are dynamic fields not supported in TGEA? If they are supported, how are those fields packed and unpacked for transmission across the network?
Deriving my own classes and overriding packData() and upackData() to support my custom fields is easy enough, but is there a built-in mechanism for supporting the transmission of dynamic fields without requiring a derived c++ class?
I'm also curious if anyone has tried to develop a more generic solution to the packing and unpacking of data. It caused me a bit of consternation to see such a tightly coupled solution in the engine code, though I can certainly appreciate and understand why it's done the way it is. The state masking to only transmit 'dirty' data was particularly nice to see, but it still gets my panties in a bunch to see such a rigid approach in the pack/unpack code. Not that I have a generic solution for it all ready to go, and there may not be one that's efficient enough, but it's certainly got the gears turning in my head. :)
I purchased TGEA last night and began the process of merging the networking code into TGB Pro using a guideline provided in the TDN for integrating real-time networking into TGB. Before I started making any code changes I spent a couple of hours tracking down and reading through the source code for packing and unpacking datablocks. I wasn't able to go through too many examples, but from the couple of datablocks I did review, it's obvious that there's a very tight coupling between the byte structure of the class and the networking code for packing and unpacking the data.
With the tightly coupled code, I didn't see any mechanism for packing or unpacking dynamic fields. By a dynamic field I'm referring to the ability on the Torquescript side to arbitrarily create new fields for an object. At least I know this is the case in TGB, and I'm assuming this is also true for TSEA. Are dynamic fields not supported in TGEA? If they are supported, how are those fields packed and unpacked for transmission across the network?
Deriving my own classes and overriding packData() and upackData() to support my custom fields is easy enough, but is there a built-in mechanism for supporting the transmission of dynamic fields without requiring a derived c++ class?
I'm also curious if anyone has tried to develop a more generic solution to the packing and unpacking of data. It caused me a bit of consternation to see such a tightly coupled solution in the engine code, though I can certainly appreciate and understand why it's done the way it is. The state masking to only transmit 'dirty' data was particularly nice to see, but it still gets my panties in a bunch to see such a rigid approach in the pack/unpack code. Not that I have a generic solution for it all ready to go, and there may not be one that's efficient enough, but it's certainly got the gears turning in my head. :)
#2
I have the need for a real-time networked 2D game which is stating the obvious I suppose. :) I have the prototype running in TGB, which is a great RAD tool, but things started to fall apart once I began prototyping the multi-player support. Now I'm at a cross-road...I could add real-time networking to TGB, but that approach may well force me into a design paradigm that ultimately has better native support in TGE/A. The other alternative would be to create the game in TGE/A and use some tricks to pull off a 2D looking game.
Decision, decisions, decision...looks like another prototype is in order. :)
02/20/2007 (10:41 am)
Stephen, thanks for the response. I'll take a look at the article you referenced.I have the need for a real-time networked 2D game which is stating the obvious I suppose. :) I have the prototype running in TGB, which is a great RAD tool, but things started to fall apart once I began prototyping the multi-player support. Now I'm at a cross-road...I could add real-time networking to TGB, but that approach may well force me into a design paradigm that ultimately has better native support in TGE/A. The other alternative would be to create the game in TGE/A and use some tricks to pull off a 2D looking game.
Decision, decisions, decision...looks like another prototype is in order. :)
Torque 3D Owner Stephen Zepp
The reasons they are tightly coupled have to do with the fact that networked objects are so brutal on bandwidth if not properly optimized. We literally want to optimize ghost updates down to the bit level, and since by definition dynamic fields are fully script based (they have no associated member variables within the underlying class like persistent fields do), there is no strong way to "pre-optimize" network transmission--all you can really do is treat them as strings and network the entire string as ASCII characters--which is highly unoptimized.
There is a pretty good article (well, I had to say that, since I wrote it!) on the challenges, strategies, and implementations of networking multi-player games that can be found on TDN: TorqueNetworking.