Datablock Analogy
by Eric Robinson · in Torque Game Builder · 03/13/2007 (10:55 pm) · 21 replies
I feel like I'm still coming to grips with Datablocks. I like to work in analogies and would like to see how these ones holds up (in terms of describing Datablocks):
---------
1) A Datablock is a school system. You give birth to your baby object. And it's naked and knows nothing of the world, particularly the world that you are building. In order to bring it up to speed, you assign it to a school. When it graduates, it knows something of the world.
Example: I have a "Soldier" object that's actually a t2dAnimatedSprite. But it's dumb and doesn't know it's a soldier, how much ammo it should have, what weapons it can use... So I send it to the Datablock. The datablock fills in all the holes and produces a veritable "Soldier".) You could homeschool the soldier (tell him he uses a gun, that he needs clips of ammo, etc) but that takes time. What if you have multiple soldiers? Send them all to the same school and your set!
---------
[Cue ACME music from old Warner Bros. cartoons]
2) A Datablock is an assembly line. You create the frame of your object: sturdy but unusable. You then send it down the assembly line and all the parts come together into something useful.
Example: You start with an empty car frame. But, wait. What type of car is it? Is it a Sedan? Send it to the Sedan Assembly Line [datablock]. The assembly line will add the wheels (four), the doors (two or four?), the seats (five), etc. With the Asembly Line you're able to produce any number of Sedans!
---------
These analogies could be easily expanded to take care of Datablock inheritance.
What I'm trying to do is separate Datablocks from other "Objects". These make sense to me because they answer the question of "Why is there ever only one Datablock object of a given type?" You only ever need one assembly line and you only ever need one school (in terms of the simplified programming universe) in order to produce countless similar objects. You don't instantiate the Datablocks, you use them to dress your other objects (with unchangeable variables[?]). Errr... if I'm correct.
Thoughts?
---------
1) A Datablock is a school system. You give birth to your baby object. And it's naked and knows nothing of the world, particularly the world that you are building. In order to bring it up to speed, you assign it to a school. When it graduates, it knows something of the world.
Example: I have a "Soldier" object that's actually a t2dAnimatedSprite. But it's dumb and doesn't know it's a soldier, how much ammo it should have, what weapons it can use... So I send it to the Datablock. The datablock fills in all the holes and produces a veritable "Soldier".) You could homeschool the soldier (tell him he uses a gun, that he needs clips of ammo, etc) but that takes time. What if you have multiple soldiers? Send them all to the same school and your set!
---------
[Cue ACME music from old Warner Bros. cartoons]
2) A Datablock is an assembly line. You create the frame of your object: sturdy but unusable. You then send it down the assembly line and all the parts come together into something useful.
Example: You start with an empty car frame. But, wait. What type of car is it? Is it a Sedan? Send it to the Sedan Assembly Line [datablock]. The assembly line will add the wheels (four), the doors (two or four?), the seats (five), etc. With the Asembly Line you're able to produce any number of Sedans!
---------
These analogies could be easily expanded to take care of Datablock inheritance.
What I'm trying to do is separate Datablocks from other "Objects". These make sense to me because they answer the question of "Why is there ever only one Datablock object of a given type?" You only ever need one assembly line and you only ever need one school (in terms of the simplified programming universe) in order to produce countless similar objects. You don't instantiate the Datablocks, you use them to dress your other objects (with unchangeable variables[?]). Errr... if I'm correct.
Thoughts?
Torque Owner Eric Robinson
%obj.datablock = woopsIMeantThisDatablock;
Or do you have to call some kind of function...?