New TGB owner, new methodology, some questions...
by Ricardo Vladimiro · in Torque Game Builder · 03/17/2007 (4:12 am) · 7 replies
Hi everyone, just bought TGB and decided to present myself.
We've used TGB to make a prototype, everything went ok and when we were about to start production, both TGB and Torsion were expired, so we bought the goods and here I am representing Vortix Games.
In the way, we found that somethings were a bit counter-productive or we could live without it, more noticeable, GUI and datablocks.
We started building our own production pipeline within the script for pretty much everthing regarding GUI, buttons, text and so on. I was wondering if anyone else did this and skipped GUI building all around. Personally I'm quite happy with the results. The script is fully reusable and we can pop our own GUI elements. Our text scripts are very useful since we can use sprites to position, blend colours, stretch, fade and so on without using the new text object or having GUI based text.
Any opinions on advantages and disadvantages of this type of methodology? We might not be aware of some issues, and all opinions are welcome.
Second part was not intentional. We don't use any datablocks. Maybe because we do 99% of the work within script and maybe the use of datablocks is more handy within the editor. Regarding this, I have doubts, for instance, Torsion does not auto-complete object variables and I wonder if the use of datablocks would help.
Well, happy to be on this side of the curtain, I hope I can be of use around here.
We've used TGB to make a prototype, everything went ok and when we were about to start production, both TGB and Torsion were expired, so we bought the goods and here I am representing Vortix Games.
In the way, we found that somethings were a bit counter-productive or we could live without it, more noticeable, GUI and datablocks.
We started building our own production pipeline within the script for pretty much everthing regarding GUI, buttons, text and so on. I was wondering if anyone else did this and skipped GUI building all around. Personally I'm quite happy with the results. The script is fully reusable and we can pop our own GUI elements. Our text scripts are very useful since we can use sprites to position, blend colours, stretch, fade and so on without using the new text object or having GUI based text.
Any opinions on advantages and disadvantages of this type of methodology? We might not be aware of some issues, and all opinions are welcome.
Second part was not intentional. We don't use any datablocks. Maybe because we do 99% of the work within script and maybe the use of datablocks is more handy within the editor. Regarding this, I have doubts, for instance, Torsion does not auto-complete object variables and I wonder if the use of datablocks would help.
Well, happy to be on this side of the curtain, I hope I can be of use around here.
#2
But as Ben said, it is a viable approach -- so long as it works, it works ... :)
03/17/2007 (12:23 pm)
Rack Em Up Road Trip, was also created with a very old version of TGB, before it was even called TGB (it was built with an EA version of T2D)But as Ben said, it is a viable approach -- so long as it works, it works ... :)
#3
03/17/2007 (9:32 pm)
About half of the Animation Builder is scripted TGB objects to act like GUI objects (like the scroll windows for both the image fames and the storyboard). If you have a pro license you can look at the source scripts for that and see various objects such as a hover objects, window, etc. Not necissarily the ideal way to do it, but definately worked out better than I anticipated.
#4
Just be sure that you're using separate scene graphs in separate overlaid scene windows for your HUD and GUI elements so you can at any moment unload/reload all GUI/HUD elements without interrupting your gameplay.
03/18/2007 (4:30 am)
There are definite advantages to using overlaid scene windows for menus and HUD systems rather than GUI controls (and make no mistake, if you are using scene objects for HUD or menu systems, you should have at least two scene windows on your Canvas - at least one dedicated exclusively to GUI/HUD). The main drawback is that you are rendering objects in a scene. As long as you treat it as such and load/unload objects at appropriate times (i.e. treat it as a real-time rendering process rather than typical a Flash scene with random garbage sitting on the sidelines), you shouldn't run into any problems. In fact, it's a much more elegant solution than using GUI controls - especially in the most recent version of TGB, with the addition of the last few essential scene object mouse events.Just be sure that you're using separate scene graphs in separate overlaid scene windows for your HUD and GUI elements so you can at any moment unload/reload all GUI/HUD elements without interrupting your gameplay.
#5
I'm quite surprised with Thomas' answer. We are not using overlaid scene windows, we have a layer organization to cope with it. But I found the idea of having several scenewindows (never crossed my mind to be honest) very interesting and something I'll look up in the future.
Appart from that, what you said is exactly what we do. From data point of view, we have a global variable structure to handle everything, from the rendering point of view it's all realtime, elements are created and deleted as needed.
Any thoughts regarding the use (or lack of use) of datablocks?
03/18/2007 (10:54 am)
Thank you very much for your answers.I'm quite surprised with Thomas' answer. We are not using overlaid scene windows, we have a layer organization to cope with it. But I found the idea of having several scenewindows (never crossed my mind to be honest) very interesting and something I'll look up in the future.
Appart from that, what you said is exactly what we do. From data point of view, we have a global variable structure to handle everything, from the rendering point of view it's all realtime, elements are created and deleted as needed.
Any thoughts regarding the use (or lack of use) of datablocks?
#6
03/19/2007 (4:04 pm)
I find datablocks extremely useful, but they are by no means neccesary. They exist more to save you from specifying a bunch of redundant information every time you create an object. They can also save you a lot of headaches. For example, if you have a class that assumes that an object has certain dynamic fields initialized to certain values, you can assign both the class and all the dynamic fields just by specifying a datablock. If that class only ever gets assigned via that datablock, you can pretty much guarantee that the data on the object will at least be valid.
#7
03/20/2007 (1:09 am)
I see. Thank you for the explanation. I think we'll use it as soon as it is a solution for something. At this point with the type of object/class implementation, I personally don't find it useful, but we never know. 
Torque Owner Ben R Vesco