Game Development Community

Datablocks in TGB

by Daniel D · in Torque Game Builder · 10/30/2006 (2:55 pm) · 8 replies

Need help understanding one last part of datablocks:

Why do I need to send a datablock to the client? Doesn't the client have all the same code that the server has? Wouldn't the client therefore, already have the datablock? Is there something dynamic that needs to be communicated at the beginning of a game?

And In TGB specifically:
What should we use datablocks for? Since they are not networked in TGB, do they still serve a purpose beyond what an object can do?

What I'm trying to do is to send objects from one player to another.
Some of the data for these objects is static, so that led me down a trail of datablock education. I have read that datablocks are the way to go for sharing static data over a network.

The trail seems to end however, with a post from Matthew Langley on Oct 27th:
www.garagegames.com/mg/forums/result.thread.php?qt=45769
"In fact the TGB datablocks aren't networked at all. All that exists is the commandToClient/Server RPC calls."

So that lead me to another post:
www.garagegames.com/mg/forums/result.thread.php?qt=43948
Which recommends making a string out of your object and sending the string across. It still seems like there should be a better way using datablocks.

I have read the definition that states that datablocks allow data to transmit at startup rather than during gameplay.

Daniel D

#1
11/03/2006 (8:57 am)
I'm also wondering why datablocks need to be sent to the client for a networked TGB game. I understand this is not default behavior for TGB networking, but if you add realtime-networking into the code (from the article that Tom Bampton wrote) I still don't understand why any datablocks would need to be sent.
#2
11/03/2006 (9:25 am)
Datablocks are intended to provide static data needed by other objects. They are a networking optimization to allow you to send said static data only once for multiple objects. They are sent when the client connects because that's the only time that it makes sense to send them. You can force datablocks to re-transmit, but using datablocks for anything dynamic is usually a very bad idea.

For example, say you have a bunch of player objects. Since it's a multiplayer game, there'd potentially be lots of players. Some data for the players is clearly unique, for example their name. Other data is the same for all of them, for example physics properties. The shared data can potentially be pretty large, so sending it with every player when it goes into scope would be a significant amount of wasted bandwidth.

TGB repurposed datablocks as arbitrary static data. The only real difference between a datablock and a normal object in TGB is the datablock's ID will be less then 1024 (unless you created the datablock with the new operator, which can be a valid thing to do). All the datablock networking code is missing from TGB (last time I looked, anyway), so if you want real datablocks then you need to use the aforementioned TDN article to copy the code over from TGE. Note that this means you need a TGE license (1.4 or 1.5, doesnt matter which).
#3
11/03/2006 (11:22 am)
Thanks for that great explanation Tom.

However, the question in the original post still remains:

Quote:
Why do I need to send a datablock to the client? Doesn't the client have all the same code that the server has? Wouldn't the client therefore, already have the datablock? Is there something dynamic that needs to be communicated at the beginning of a game?

It seems like since datablocks are created on each client (and the server), I don't see any purpose for sending them across the network - ever.
#4
11/03/2006 (12:26 pm)
Quote:Some data for the players is clearly unique, for example their name. Other data is the same for all of them, for example physics properties. The shared data can potentially be pretty large, so sending it with every player when it goes into scope would be a significant amount of wasted bandwidth.
So does that mean that:
The shared data should be defined in the 'Player' object, so that all clients will already know what a 'Player' is.
The unique data should be bundled up into a datablock, 'PlayerData', at runtime, and sent to the other clients once, when needed.

Or does that mean that:
The shared data should be defined in a datablock, 'PlayerData', so that all clients will already know what a 'Player' is.
The unique data should be defined in the 'Player' object and sent to the other clients every time it changes.

But I still don't understand why a datablock would be sent across the network.

For example, if I define, in FishTutorial.cs, the datablock:
new t2dSceneObjectDatablock(FishConfig)
{
   defaultScriptClass = "AnimFishClass";
   worldLimitMode = "NULL";
   worldLimitMin = "-62.0 -92.0";
   worldLimitMax = "62.0 92.0";
   worldLimitCallback = "1";
}
then I am going to release this code, so all clients will already know what a FishConfig is, as soon as they exec FishTutorial.cs. So why would I need to be sending this datablock to the other clients. Maybe its a bad example.

I never was able to figure this out, even when I was using TGE. What is a good example usage for sending a datablock?

And let me know when I have stepped out of the TGB scope.
#5
11/10/2006 (4:55 pm)
Quote:I never was able to figure this out, even when I was using TGE. What is a good example usage for sending a datablock?

One of the things to keep in mind is TGE is made to a MODable engine. In fact many games made in TGE are meant to MODable using this same framework. So say you have users of your TGE games that want to add more player types. In TGE they would create more PlayerData datablock objects. Well the person who hosts the game has these and when the clients connect it ensures all the datablocks are sent to all the clients, hense modding with datablocks requires no additional files :) Unless of course you add in extra images, models, etc, then you might as well give the clients the data in an extra package.


Now TGB doesn't have this concept of Tribes style MODable engine. For good reasons. So Datablocks were repurposes (as Tom B. has explained well) as static data objects. The name "Datablock" fits very well for this purpose.
#6
12/01/2006 (2:47 pm)
Actually I'm a little confused on networking in real-time (as in "on time and correct") networking in TGB as well. If I were to pass a data structure from server to client that holds all the sprites positions, velocities, rotations, etc... that transmitted every X milliseconds, what other information would I need on the client to keep it in sync? In other words, can I keep all calculations on one machine, then transmit a "good enough" approximation state to another in real time? I imagine if the gameplay is slow enough, this would work? Or am I totally off-base here?

I'd experiment but I'm trying to finish off bigger parts of my game. The local multiplayer is almost done, then I want to add in a simple single-player mode, and add a tournament (local) mode. Networking is my pipe-dream, however, so I'd like to know what a realistic set or requirements good enough real time networking has. :)
#7
12/01/2006 (3:23 pm)
Commander Langley did a demo that shows how close to "real-time" you can get in TGB with the current system. Check it out here - I know he sent out the scripts to a lot of people too.
#8
12/02/2006 (5:01 pm)
Ah, very cool. Did those scripts eventually get posted?