2 Datablock or Not 2 Datablock?
by DELETE · in General Discussion · 03/10/2006 (11:44 am) · 5 replies
This time round I have bought Advanced 3d game progamming all in one. This time no e-book. Nothing like flesh to paper. But anyway. Being that I just reading it this go round to get a feel I have come to OBJECTS. And I'm posting this to make sure that I understand correctly. There are two types of objects NORMAL Objects and Datablock Objects (well actually a third but don't care about that one right now). My question is 'Is Datablock Objects used for things the player interact with like weapons, enemies, vehicles and ammo etc.' And what is Normal Objects actually used for?(trees and stuff like that? What?)
About the author
#2
To understand datablocks you have to think of Torque as an engine built around networking from the ground up. Having datablocks allows for some huge networking optimizations. Let me explain in a little more detail =)
Say for example, if you had a racing game you might have 3 different types of cars. Each of those types of car may have a top speed, a top acceleration, a braking configuration, and a maximum chassis size associated with them. This is the shared data among each of those types of car. You also might have data that isn't shared like their positions in the world or the mesh they are using for their tires or body. There is data that is shared among multiple cars and there is data that is unique to each car, right? Follow me so far?
If you take a look at the datablock for a WheeledVehicle in the demo you can see that we identified 85 common characteristics among most WheeledVehicles (this can vary a bit per the requirements of your game). 85 pieces of data that include many 3 float vectors and long character strings can be quite costly to send over the network, especially if you are sending multiple WheeledVehicle datablocks. If this data was sent every time you saw a WheeledVehicle on your screen or even just the first time you saw the WheeledVehicle you would some rather nasty hitches because the rest of your network updates would have to wait till all of it was transmitted. If that is so, how should we handle sending all of that data?
Here is where the writers of the Torque Game Engine does something clever. It preloads all of this shared data and sends it down only once during connection/mission load when the user is a lot more willing to wait through transmission and loading. Then when you actually see a WheeledVehicle you only get sent the data that is unique to that car. Stuff like its position/rotation, its current velocity, its steering angle, or even what mesh it is using for its body (if you want that to be configurable by the user). This *much* smaller subset of data is going to disrupt your network updates *far* less. It is even optimized to allow you to only send some of the data once or less often than every tick (the body mesh is something that only needs to be sent once...the position needs to be sent continuously).
By caching up all of the shared data and only transmitting the unique data for each object the engine is able to have a huge bandwidth savings for your networking. It is an essential key in why Torque's networking is so good and so scalable. Unfortunately, till you get used to using datablocks they can be a little confusing =P
03/14/2006 (11:40 am)
Datablocks are all of the data that is shared among multiple instances of an object type. What exactly does that mean? Why is it built that way? Why have datablocks at all?To understand datablocks you have to think of Torque as an engine built around networking from the ground up. Having datablocks allows for some huge networking optimizations. Let me explain in a little more detail =)
Say for example, if you had a racing game you might have 3 different types of cars. Each of those types of car may have a top speed, a top acceleration, a braking configuration, and a maximum chassis size associated with them. This is the shared data among each of those types of car. You also might have data that isn't shared like their positions in the world or the mesh they are using for their tires or body. There is data that is shared among multiple cars and there is data that is unique to each car, right? Follow me so far?
If you take a look at the datablock for a WheeledVehicle in the demo you can see that we identified 85 common characteristics among most WheeledVehicles (this can vary a bit per the requirements of your game). 85 pieces of data that include many 3 float vectors and long character strings can be quite costly to send over the network, especially if you are sending multiple WheeledVehicle datablocks. If this data was sent every time you saw a WheeledVehicle on your screen or even just the first time you saw the WheeledVehicle you would some rather nasty hitches because the rest of your network updates would have to wait till all of it was transmitted. If that is so, how should we handle sending all of that data?
Here is where the writers of the Torque Game Engine does something clever. It preloads all of this shared data and sends it down only once during connection/mission load when the user is a lot more willing to wait through transmission and loading. Then when you actually see a WheeledVehicle you only get sent the data that is unique to that car. Stuff like its position/rotation, its current velocity, its steering angle, or even what mesh it is using for its body (if you want that to be configurable by the user). This *much* smaller subset of data is going to disrupt your network updates *far* less. It is even optimized to allow you to only send some of the data once or less often than every tick (the body mesh is something that only needs to be sent once...the position needs to be sent continuously).
By caching up all of the shared data and only transmitting the unique data for each object the engine is able to have a huge bandwidth savings for your networking. It is an essential key in why Torque's networking is so good and so scalable. Unfortunately, till you get used to using datablocks they can be a little confusing =P
#3
the reason I ask, is that tgb, which I work with, obviously doesnt have the datablock support in it's networking, and me, being the punk I am, hate datablocks (because it is pretty wonky translating that concept to C#).
obviously I cant ditch them all together (as some objects require datablocks be passed to them on creation) but if there is some other mysterious engine-voodoo reason why they are a "Good Thing (TM)" then I'd like to know.
Thanks,
-Jason
03/14/2006 (12:16 pm)
@Matt: is there any other "good" reason to use datablocks? (such as engine performance or something)the reason I ask, is that tgb, which I work with, obviously doesnt have the datablock support in it's networking, and me, being the punk I am, hate datablocks (because it is pretty wonky translating that concept to C#).
obviously I cant ditch them all together (as some objects require datablocks be passed to them on creation) but if there is some other mysterious engine-voodoo reason why they are a "Good Thing (TM)" then I'd like to know.
Thanks,
-Jason
#4
Not really. The only other "good" reason to use them is for organizational purposes (grouping like objects, data, and functions together...a lot of the script functions/callbacks are in the datablock namespaces and not in the object namespaces for this reason). Other than that they are a primarily networking optimization.
I can tell you from personal experience that while you are in development they can be a bit of a hassle but when you get close to shipping and your data/class/types/selections have begun to solidify and not change any more then they are easy to work with and can be somewhat handy. For example, I might write a "car" class that has the wheel mesh property be per object so that I can easily tweak but by the end of the development cycle I may realize that I only ever have 1 or 2 different tire meshes on my cars. Since this is no longer a highly object dependent option I might look at moving this property from the car properties into the car's datablock properties.
03/14/2006 (12:25 pm)
Jason,Not really. The only other "good" reason to use them is for organizational purposes (grouping like objects, data, and functions together...a lot of the script functions/callbacks are in the datablock namespaces and not in the object namespaces for this reason). Other than that they are a primarily networking optimization.
I can tell you from personal experience that while you are in development they can be a bit of a hassle but when you get close to shipping and your data/class/types/selections have begun to solidify and not change any more then they are easy to work with and can be somewhat handy. For example, I might write a "car" class that has the wheel mesh property be per object so that I can easily tweak but by the end of the development cycle I may realize that I only ever have 1 or 2 different tire meshes on my cars. Since this is no longer a highly object dependent option I might look at moving this property from the car properties into the car's datablock properties.
Torque Owner Bruno Grieco
Datablocks would be closer to a static object. There is only one instance of a datablock that is transmitted only once from the server to the client.
Datablocks are used to store "constant" data, like how much your player can run, jump, etc. When you create a player ( or an AIplayer) , you create an object, you may have as many objects you want, but each object will have a datablock that's shared among others.
Say you want to create trees. You may have two different kinds of trees, oaks and pines, you would create several tree objects with the pine datablock and several tree objects with the oak datablock. The datablocks would contain the shape of the tree which would be constant among all pines and oaks.
Understanding the differences between datablocks and objects is one of the "difficulties" of TGE and every new developer passes thru this.