Clarification: script vs behavior vs code
by Nick Rafalski · in Torque Game Builder · 11/02/2009 (3:30 am) · 10 replies
A little intro. I am a current Computer Science student in my 3rd year. I turned to TGB because i was tired of writing C++ programs that, while powerful and useful, were always text in a terminal window. I'm pretty proficient in C/C++. I understand all the terminology, but am just now getting introduced into design patterns and strategies. I also have some python experience. Anyway. I want to make games.
So i found TGB and have the 30 day trial. I did the side scroller shooter tutorial, and really liked it. After the tutorial i added some things like, health, lives, particle effects for missile thrust, and a pretty re-usable healthbar.
Okay now to my question. After searching the forums, i've seen lots of different approaches as far as behavior vs scripting. For instance, even within the realm of the Shooter Tutorial, there is one approach that uses scripting for movement, and one that uses behaviors. both work, obviously, but what are the differences. Along these lines, i noticed that you can script pretty much replace everything in the game builder (graphic utility) with scripting. This got confusing because when i added my health attribute to my playerShip class, i originally did it in the game builder, but it felt funny referencing an object in script that wasn't declared, so i just declared it in script. As another example, in the Shooter tutorial, the player has dynamic fields for vSpeed and hSpeed, now if i add these fields, with the same name, in script, it seems like the scripted variables take precedence over the GB fields. As in, i change the vSpeed in script from 80 to 160, and run the level, and the ship moves twice as fast, but the dynamic field in the game builder still says 80.
I hope that wasn't too confusing. It was just my thoughts that the more i tried to do in the game builder, the more i was tempted to just leave it out and do it in script.
Anyways. that was quite a tangent from my original question. Script vs behavior vs coding. Until i came to the forums, i thought my scripting was 'coding'. I have enough programming experience to actually be good at 'coding' (as long as its C++) but i dont know where or why i would do it.
Oh, and another question, that i haven't made a good enough effort to search for, but its 2:30 am and it just came to me. Datablocks. What is their equivalent in C++? at first i thought they were like dynamically allocated class objects, but after spawning enemies and adding particle effects, i realized that there is something already like that with %var = new t2dParticleEffect/StaticSprite/etc. When would i use datablocks? when i am defining my classes? or when i am actually instantiating them?
And a final question. where is the best place to get this info that i probably shouldn't be asking about? The game documentation seems to be rather minimal and contradictory in places. Additionally, it is more a 'dictionary' of terms where i am looking for a 'cook book' of sorts. Just the basics of where i should be scripting or coding or behavior-making.
Thanks for your time and responses.
So i found TGB and have the 30 day trial. I did the side scroller shooter tutorial, and really liked it. After the tutorial i added some things like, health, lives, particle effects for missile thrust, and a pretty re-usable healthbar.
Okay now to my question. After searching the forums, i've seen lots of different approaches as far as behavior vs scripting. For instance, even within the realm of the Shooter Tutorial, there is one approach that uses scripting for movement, and one that uses behaviors. both work, obviously, but what are the differences. Along these lines, i noticed that you can script pretty much replace everything in the game builder (graphic utility) with scripting. This got confusing because when i added my health attribute to my playerShip class, i originally did it in the game builder, but it felt funny referencing an object in script that wasn't declared, so i just declared it in script. As another example, in the Shooter tutorial, the player has dynamic fields for vSpeed and hSpeed, now if i add these fields, with the same name, in script, it seems like the scripted variables take precedence over the GB fields. As in, i change the vSpeed in script from 80 to 160, and run the level, and the ship moves twice as fast, but the dynamic field in the game builder still says 80.
I hope that wasn't too confusing. It was just my thoughts that the more i tried to do in the game builder, the more i was tempted to just leave it out and do it in script.
Anyways. that was quite a tangent from my original question. Script vs behavior vs coding. Until i came to the forums, i thought my scripting was 'coding'. I have enough programming experience to actually be good at 'coding' (as long as its C++) but i dont know where or why i would do it.
Oh, and another question, that i haven't made a good enough effort to search for, but its 2:30 am and it just came to me. Datablocks. What is their equivalent in C++? at first i thought they were like dynamically allocated class objects, but after spawning enemies and adding particle effects, i realized that there is something already like that with %var = new t2dParticleEffect/StaticSprite/etc. When would i use datablocks? when i am defining my classes? or when i am actually instantiating them?
And a final question. where is the best place to get this info that i probably shouldn't be asking about? The game documentation seems to be rather minimal and contradictory in places. Additionally, it is more a 'dictionary' of terms where i am looking for a 'cook book' of sorts. Just the basics of where i should be scripting or coding or behavior-making.
Thanks for your time and responses.
#2
11/02/2009 (10:34 am)
thank you william. As usual, a very informative and helpful post. I have a follow up question regarding coding though: so how do i go about adding code to my game? do i just write a .cpp file and stick it in my games folder? how does TGB know how to compile it? do i need to edit some kinda makefile? 
#3
I was giong to comment on my take on behaviors vs scripting. One of the things I like about behaviors is that it is a stand alone module that can be applied to any game object that can handle it. I like to use behaviors for things like AI behavior so I can pull it out or drop it in nearly seamlessly instead of integrating it into a specific object's scripts.
11/02/2009 (10:51 am)
I'm not an expert on make files but I'm pretty sure you just add new cpp files to the visual studio project.I was giong to comment on my take on behaviors vs scripting. One of the things I like about behaviors is that it is a stand alone module that can be applied to any game object that can handle it. I like to use behaviors for things like AI behavior so I can pull it out or drop it in nearly seamlessly instead of integrating it into a specific object's scripts.
#4
With non-Pro TGB, you don't get the C++ source code. So it's not possible to add a new C++ class with that version; all you can do is scripting.
11/02/2009 (11:14 am)
Yes, when you add a C++ class you'll need to compile it, although most of us use IDEs rather than make files. When you buy TGB Pro, it includes all of the C++ source code. It doesn't have a compiler of its own, but it does include project files for both Visual Studio and Xcode.With non-Pro TGB, you don't get the C++ source code. So it's not possible to add a new C++ class with that version; all you can do is scripting.
#5
11/02/2009 (11:57 am)
Just curious. When you compile the C++, does that modify your TGB installation, therefor applying those changes to all new projects, or does it just modify a specific project?
#6
Of course, that's just the default behavior. Nothing stops you from tweaking the Visual Studio or Xcode project to make it behave however you want it to. :-)
11/02/2009 (12:13 pm)
When you build a project from within TGB, it copies a "template" executable and your script files into the build directory. Recompiling the C++ code for the template won't change any copies of it that have already been made - to update those, you'd have to run TGB and build your projects again.Of course, that's just the default behavior. Nothing stops you from tweaking the Visual Studio or Xcode project to make it behave however you want it to. :-)
#7
11/02/2009 (12:28 pm)
But when you recompile the C++ code, does that change the template for all TGB projects or just a specific one?
#8
11/02/2009 (1:01 pm)
Like I said, it changes the original template (there is only one) not the copies that were made when you built the TGB projects. 
#9
To start each new project, I copy the entire installation into a new directory. I then open TGB to create a new project. Then I modify the Visual Studio project with a post-build step which copies the executable to the new project's directory. Finally, I build the executable just to have it ready for my changes.
Since my C++ changes are game specific, I don't want them in the general code's baseline.
Also, I keep my C++ changes in a new directory so that I can quickly find my changes for the Mac build. (Although, I break this rule with tweaks and bug fixes to the baseline.)
11/02/2009 (1:48 pm)
I never, ever, use the installed copy to do anything.To start each new project, I copy the entire installation into a new directory. I then open TGB to create a new project. Then I modify the Visual Studio project with a post-build step which copies the executable to the new project's directory. Finally, I build the executable just to have it ready for my changes.
Since my C++ changes are game specific, I don't want them in the general code's baseline.
Also, I keep my C++ changes in a new directory so that I can quickly find my changes for the Mac build. (Although, I break this rule with tweaks and bug fixes to the baseline.)
#10
11/02/2009 (2:08 pm)
@William - That is a great example of the "tweaking the Visual Studio or Xcode project to make it behave however you want it to" I was talking about above. :-) 
Associate William Lee Sims
Machine Code Games
Scripting v. Behaviors I think you'll find that this is a matter of preference. Personally, I use behaviors to mimic GUI behavior using sprites. All of the rest I do with scripting. The idea behind behaviors is that they could be "drop-in" code for non-coders.
Dynamic Fields When you put dynamic fields in TGB, they get saved to the level file. You should modify them in the scripts as necessary (say, for power-ups). But since you don't re-save the level file in the middle of the game, the original values will still be there.
Scripting v. Behaviors v. Code You can get away with just scripting (and/or behaviors). But there will be times when you need a huge speed boost, and that's where you'd write C++ code. For example, in my current game, I'm building a random cave. This algorithm is intensive and takes 8 seconds in scripts to finish. It takes a non-noticeable amount of time in C++. I tend to write a lot of C++, especially to write my own scene objects (something I can add to the scene graph, but has custom rendering code), but that's just me.
Datablocks Imagine them as static sets of data that a lot of objects will have in common. In most cases (like the t2dImageMapDatablock), your object will have a pointer to it. In one case (the Config Datablocks), they are a shortcut in the TGB editor to set a bunch of fields.
There's no great place to go to get all of this information. Your best hope is tdn.garagegames.com/wiki/Torque_Game_Builder.