Intended use of classes vs behaviors
by Dmitry Yanushkevich · in Torque Game Engine · 02/15/2011 (12:17 am) · 1 replies
Hi guys,
It's been a month since we started use of TGE for our projects. Has been a very nice experience all this time, but there are a few bits here and there that aren't that well explained. Here's one of them, if someone could give a clear explanation -- I'd really appreciate it!
The question is quite simple -- what is the intended use of classes and behaviors? From my point of view, they provide kinda similar functionality, but differ somewhat in what you can/cannot do with them. What I'd like to know is what code I should put into behaviors and what should go into classes?
Right now, for one of the projects (a simple match-3 prototype at the moment), I had a huge behavior module describing the behavior of an in-game tile field. Then it came to me that it could really benefit from factoring the code into one base tile field class and a few child classes with specifics of each one game play mode. And then whoa -- you cannot really do behavior inheritance. And if you say "go with the classes" -- you won't have that nifty behavior fields that are VERY useful to game designers because they show up in TGB. So this is why I had that question -- what should go in class code and what into behaviors?
Many thanks in advance,
Dmitry
It's been a month since we started use of TGE for our projects. Has been a very nice experience all this time, but there are a few bits here and there that aren't that well explained. Here's one of them, if someone could give a clear explanation -- I'd really appreciate it!
The question is quite simple -- what is the intended use of classes and behaviors? From my point of view, they provide kinda similar functionality, but differ somewhat in what you can/cannot do with them. What I'd like to know is what code I should put into behaviors and what should go into classes?
Right now, for one of the projects (a simple match-3 prototype at the moment), I had a huge behavior module describing the behavior of an in-game tile field. Then it came to me that it could really benefit from factoring the code into one base tile field class and a few child classes with specifics of each one game play mode. And then whoa -- you cannot really do behavior inheritance. And if you say "go with the classes" -- you won't have that nifty behavior fields that are VERY useful to game designers because they show up in TGB. So this is why I had that question -- what should go in class code and what into behaviors?
Many thanks in advance,
Dmitry
About the author
Worked here and there, did both game and business development. Finally decided to start own business, and here we are -- a cutie Cat Paw Studio has been born! :D
Torque 3D Owner Ronny Bangsund
Torque Cheerleaders
Classes are just classes - the actual objects you use, with methods. Behaviours extend an object (class) and also put more functionality into the editor. You make behaviours so that artists can configure objects without coding, via strings, check boxes and dropdown menus.
An object is just one class (not "has" - "is"), but can have any number of behaviours attached. So you could have one player character behaviour which ensures input and animations are handled automatically (like in the platformer kit) and another behaviour which adds a particle effect of trailing smoke, for instance.
So basically a behaviour is a class that extends both objects and the editor. You don't write as many custom classes when you have behaviours available. Instead you just make behaviours add fields in the editor to control certain things, and use them in the various behaviour methods to drive the game logic. You can also easily build lists of all objects of a certain kind to add to the dropdown lists, which allows you to pick images and named objects to reference.
An example from my current object: I have a teleporter behaviour which sends the player somewhere different on activation, and in the setup portion of it I get a list of t2dSceneObject elements, which lets me pick from any object with a name and use it as a target. So it's as easy as placing *any* object, giving it a name, adding Teleporter to a trigger object and choosing the target object from its dropdown.
Another is weather, which in the setup portion goes through the particles directory to get a list of specially named effects to present in its dropdown. The object with the behaviour constantly plays the particle effect on its position, starting behind it, adjusted to the width of the attached object (useful for clouds).
If you're just using classes and datablocks all configuration and logic is selected in code, not easily available to artists and level builders.
You can also programmatically add behaviours to objects as they are created in code, which would suit your match.3 example very well.