Overall "Development Philosophy" of TGB
by Michael Stout · in Torque Game Builder · 07/07/2009 (3:19 am) · 3 replies
Hello All,
I've gone through and read many of the documents and tutorials and I'm having a hard time wrapping my name around this.
What would you say is the overall development philosophy of Torque Game Builder.
For example:
Some of the engines I've worked with have worked thusly:
* Entities' behaviors are coded entirely in C with exposed variables available to the editor.
* Entities are placed in the editor, and exposed variables are tweaked (entities are linked to each other, entities are linked to volumes, variable numerical values are set, etc)
Other engines have worked like so:
* Entities are coded mostly in C and the programmers write script commands for the entities
* Entities are placed and named in the editor and named
* Global scripts are written that interact with the entities and let them know any special-case behaviors they can use. This is specified by the script commands the programmers exposed (for example, checking to see if entities are inside volumes, checking to see if exposed entity variables are related to constants and so forth.
Thus far, TGB seems to work very differently than what I describe above -- so if anyone well versed in TGB please describe their overall development philosophy or workflow to me, that would help me greatly.
Thanks!
~ Mike
I've gone through and read many of the documents and tutorials and I'm having a hard time wrapping my name around this.
What would you say is the overall development philosophy of Torque Game Builder.
For example:
Some of the engines I've worked with have worked thusly:
* Entities' behaviors are coded entirely in C with exposed variables available to the editor.
* Entities are placed in the editor, and exposed variables are tweaked (entities are linked to each other, entities are linked to volumes, variable numerical values are set, etc)
Other engines have worked like so:
* Entities are coded mostly in C and the programmers write script commands for the entities
* Entities are placed and named in the editor and named
* Global scripts are written that interact with the entities and let them know any special-case behaviors they can use. This is specified by the script commands the programmers exposed (for example, checking to see if entities are inside volumes, checking to see if exposed entity variables are related to constants and so forth.
Thus far, TGB seems to work very differently than what I describe above -- so if anyone well versed in TGB please describe their overall development philosophy or workflow to me, that would help me greatly.
Thanks!
~ Mike
#2
TGB is a retained graphics system which means you create an object, add it to a scene, associate the scene to a window and it'll continue to render/move/response until you delete it. There's no draw-line here, draw-rectangle there.
The main idea is that you perform most of your code logic in script. This script is called from the engine via script-callbacks. The core engine provides callbacks during specific events, most of which you can configure.
For instance you can place scripts in the scene-update callback that is called each frame to perform some basic logic. More useful though are per-object callbacks which happen when interesting events occur for animation, collision etc. These callbacks allow you to perform your game logic on a per-object basis and/or coordinate with the larger game state.
The level-builder is there to hopefully provide a large chunk the declarative game state in the form of game levels. A project is comprised of an unlimited number of levels.
TGB comes with a stock script-setup that provides initialisation for all the core sub-systems. It also provides callback "hooks" that allow you to perform interesting logic such as level-loads etc.
TorqueScript is fairly powerful in many areas but it's never going to be able to do heavy-lifting. The engine exposes lots of functionality to TS and there are many classes that can help you process game state such as ScriptObject, SimSet, SimGroup etc. Also, you can use dynamic-fields to assign state to any object. You typically use these fields to apply custom state/references. Most objects also have static-fields which are used/defined by the object itself and provides you with access to interesting features.
The main thing to realise about TS though is that all parameter passing is done via strings. This can make it slow and even worse, you loose type safety so you need to be careful. A good editor like Torsion will help a little.
For the heavy-lifting though, you will need to turn to C++. You can create a C++ class and expose it to TS very quickly. You can easily hook into the engine and/or sub-class existing classes, especially the TGB ones. I definately wouldn't jump into that side first though.
07/07/2009 (7:53 am)
As always, it depends on what your specific game requirements are however, the main idea is that TGB provides for you a good selection of pre-baked functionality split-up into common rendering types such as static-sprites (not animation), animated-sprites, scrollers, text etc. It also provides functionality like triggers etc.TGB is a retained graphics system which means you create an object, add it to a scene, associate the scene to a window and it'll continue to render/move/response until you delete it. There's no draw-line here, draw-rectangle there.
The main idea is that you perform most of your code logic in script. This script is called from the engine via script-callbacks. The core engine provides callbacks during specific events, most of which you can configure.
For instance you can place scripts in the scene-update callback that is called each frame to perform some basic logic. More useful though are per-object callbacks which happen when interesting events occur for animation, collision etc. These callbacks allow you to perform your game logic on a per-object basis and/or coordinate with the larger game state.
The level-builder is there to hopefully provide a large chunk the declarative game state in the form of game levels. A project is comprised of an unlimited number of levels.
TGB comes with a stock script-setup that provides initialisation for all the core sub-systems. It also provides callback "hooks" that allow you to perform interesting logic such as level-loads etc.
TorqueScript is fairly powerful in many areas but it's never going to be able to do heavy-lifting. The engine exposes lots of functionality to TS and there are many classes that can help you process game state such as ScriptObject, SimSet, SimGroup etc. Also, you can use dynamic-fields to assign state to any object. You typically use these fields to apply custom state/references. Most objects also have static-fields which are used/defined by the object itself and provides you with access to interesting features.
The main thing to realise about TS though is that all parameter passing is done via strings. This can make it slow and even worse, you loose type safety so you need to be careful. A good editor like Torsion will help a little.
For the heavy-lifting though, you will need to turn to C++. You can create a C++ class and expose it to TS very quickly. You can easily hook into the engine and/or sub-class existing classes, especially the TGB ones. I definately wouldn't jump into that side first though.
#3
07/08/2009 (2:12 am)
Thanks guys, that's exactly what I needed. =)
Torque 3D Owner Ronny Bangsund
Torque Cheerleaders
For speed (heavy math, additional physics library linking) you either write logic in C++ and expose to script (funcion calls, objects) or stick to pure C++. Some people here swear by it, since they're more efficient like that. If you feel that $= to compare strings is against your belief system, consider C++ :)
You can place entities in the editor and give them variables, with a linked script. You can write them in script and set variables there. You can of course also create them in C++.
I suggest going through different tutorials, especially the video tutorials (since they're most up to date). Even the old outdated ones on TDN show some different approaches.