Need help understanding datablocks

Total noob question here. I've read through the documentation and several of the old books (3D Game Programming AIO, The Game Programmer's Guide to Torque), but I'm having some difficulty wrapping my head around datablocks, more specifically how they are used. Let's say I am making a game with many items and sub-types of items, ie swords: iron sword, steel sword, wooden sword ...; or jars: glass jars, clay jars, big jars, little jars, etc...

Do I create a single datablock for each high level thing (Sword, Jar), and then have objects that inherit from those types? OR, do I create a unique datablock for each sub-type (big jar, little jar)? OR... how do I go about doing this?

Datablocks just contain values for an object type.

You can only use data values that have previously defined in tihe engines source code like this for example: https://github.com/GarageGames/Torque3D/blob/development/Engine/source/T3D/item.cpp#L68-L109

You can build your swords upon the weapon datablocks and other items upon the item datablock.

The sourcecode example has default values, so you only need to enter the values in the datablock you want to change, this can help reduce filesize.

You can also use namespace method to derive a datablock from another.

Like "bigJar : jar" where the bigJar will be derived from jar, so you can make a default datablock for all jars and use namespace if you need to just change certain values for the jar type etc.

For how I've used them, in the datablocks you define the constants.

If something changes all the time in the client then that is a variable of the object instance (for example: position, rotation, health...) and if something is (should be) always the same for that object then it's better in the datablock (like the shape .dae or what weapons are available from the start).

It's this way to save client-server data movement because the data inside the datablock doesn't need to be re-sent constantly as it's defined at the start of the game.

Well, you could create objects in c++ that use no datablock at all (like TSStatic) if you don't mind wasting pack/unpack updates.

In your examples you would use one datablock for each (iron sword, wooden sword, etc...) because constants like max damage and shape are different for each.

But as @Duion said, you would first make a base datablock (sword) and then derive the subsequent children datablocks and define inside them only the minor differences.

One other thing about datablocks that could cause you great pain and confusion if you don't know about it: IIRC, they have a finite block of IDs reserved for them at the front of the list (if you go your_datablock.getID() at the console, it should always be a three digit number, or less) and the side effect of this is there is a finite cap on how many datablocks you can have. Sorry, but I'm not sure if it's 999 or some smaller number, anybody else know?

I think the limit is pretty high, so it shouldn't affect normal game usage, but at one point I was trying to use datablocks for every physics joint and body for every different skeleton I had, and ran into trouble.

And if, by any chance, you are making a single player game or application, they are entirely unnecessary, they are only there to speed up multiplayer games. (Which is what most people are doing with Torque, of course.)

Thanks guys, that helps a ton.

And if, by any chance, you are making a single player game or application, they are entirely unnecessary, they are only there to speed up multiplayer games. (Which is what most people are doing with Torque, of course.)

But wouldn't it be the "Proper" thing to use them, since Torque is such a heavily Server/client oriented engine? I also imagine that if I wanted to make it multiplayer later, using datablocks would be beneficial.

Sure, no reason to break the normal way of doing things, as long as you don't get into astronomical numbers of things needing datablocks.

The allowed numbers for DBs and ghosts and stuff were bumped up a little while ago, so you can use somewhere around 16k datablocks if i remember right.

So while you don't want to go insane with 'em, as chris and the others said, it's not so low a number as something you have to actively fret on normally either.

And if, by any chance, you are making a single player game or application, they are entirely unnecessary, they are only there to speed up multiplayer games. (Which is what most people are doing with Torque, of course.)

This is not correct. Datablocks define the behavior of objects in torque - this is no less true in a single player game than it is in a networked one. As far as the engine is concerned single-player (local) is just multi-player with the software equivalent of a null-modem cable looping everything back between a client and server on a local machine.

The most significant difference between scripting for single-player and multiplayer is probably being able to get away with calling client-side functions (display GUI, push actionmaps, etc.) from server scripts - and vice versa - while having stuff still (generally) work as expected. A single-player game can typically bypass the whole messageClient/commandToServer interplay, directly update server-context variables and objects from a GUI, etc ... but if multi-player ever needs to be added in the future, the shortcuts will probably prove to be a royal pain.

Generally speaking a datablock defines the properties/behavior for an entire group of in-game objects. They don't exist in-game per-se, they tell the things that exist in-game how to behave. I'd hesitate to say there's a fast rule, but typically the datablock class will hold constants that define what the object actually is - the things that will be common to all instances of the object - while the object class proper holds all the stateful stuff required to manifest an individaully-functioning instance distinct from others. Changing the properties of a datablock will impact all objects that implement it whereas changing the properties of an individual object will only impact that object.

Let's say you have created two WheeledVehicle objects named Cheetah1 and Cheetah2 with the same core datablock (CheetahCar). Both Cheetah1 and Cheetah2 have completely independent variables that track their speed, etc. without impacting each other. Yet when the "mass" field in their datablock (CheetahCar) is changed, it impacts both vehicles. And this makes sense - all Cheetahs should be expected to have the same mass.

Some objects, like the WheeledVehicle, make use of multiple datablocks. There is a datablock that defines the vehicle itself; the shape file, audio (which is also implemented using datablocks), etc. But a WheeledVehicle object also holds a datablock to define it's tires and a different one that defines springs. When it comes time to make an actual in-game car object, what you end up with is a main gamebase-derived shape that doesn't have any wheels along with a datablock describing what wheel (tire) should be used for *this* instance of the object and another datablock describing the characteristics of a "spring" that attaches the tire to vehicle proper for *this* instance.

Cheetah1 could use tires defined in a datablock "Tire1" while Cheetah2 uses tires with a different datablock(say, Tire2). In this case, the same rules for datablocks apply to the tires - changing the value on a tire's datablock will change the behavior of all vehicles that implement the tire. Springs work the same way. This provides a flexibility to create a range of similar vehicles with distinct features and can be leveraged provide in-game upgrade mechanisms, etc.

To be effective designing in Torque it is pretty important to master datablocks. The functionality is quite powerful. It's not a matter of "the right way" vs. "wrong way". Game objects literally don't work without them.

This is not correct. Datablocks define the behavior of objects in torque - this is no less true in a single player game than it is in a networked one.

True, my apologies, I should have clarified. When using stock Torque, and dealing with any game objects derived from GameBase, which AFAIK is all of them, datablocks are not optional. What I meant was as a C++ programmer, when designing a class in Torque, you can choose to base something like a physics joint, or a spring on a vehicle, on GameBase and have it use datablocks, or you can choose to store your data in a different way, of which there are many options. My only reason for mentioning this was that in the extreme case where you might need a really huge number of things, you might want to design around dependence on GameBase for every little tiny detail, because you will run out of datablocks eventually.

But for ordinary usage, feel free to not worry about this point.

@Jeffr: Ah, I didn't know it had been bumped up to 16K, thanks for that! My already minor point now has approximately 1/16 of its former relevance. :-)