Prototype Week Results
by Simon Love · 06/22/2014 (8:57 pm) · 4 comments
First, 3 minutes of Torque 2D stuff
Youtube apparently likes adding artefacting. cool...
Now, a brief rundown of the T2D systems used to make these.
Intro
A simple sequence of GuiFadeinBitmapCtrl, I've added a script callback when the Fadeout ends so I can sequence the next fade in or the actual prototype.
The Eyes
The eyes are spine animations, using my own version of T2D 3.0. The one thing in this demo that can't be done with stock T2D 3.0 is that I override the pupil+iris of each eye to follow the mouse cursor. This is done by overriding the Bone's position in script, via a behavior.
UFO
A quick, messy drawing with an attached Particle Effect which I've tweaked using the Particle Effects Editor!. I then manually modify the Emitter's spin and colors to give an effect.
The UFO is controlled by the Xbox 360 controller, using the triggers to tilt it to one side or the other. Kinda jittery but still fun to do.
Cars and road
First thing to note are the message boxes. This is a SceneObject with a Gui attached to it, set to autosize.
The Gui is a button (using Jesse Allen's buttons, which are awesome] which contains a guiMLTextCtrl. I've added a behavior to scale the sceneobject on a timer and another to type in the text one character at a time, taking a longer pause when it encounters punctuation in the string.
Also had to figure out how to use actual fonts (not Imagefonts) properly in T2D, pretty simple actually!
The map is a CompositeSprite, the tollbooths are standard animated sprites and the cars are simple Sprites.
The Cars move from tile to tile using Moveto and rotateto, which looks a bit funky but it works!
The dude walking beneath the clouds
This entire one took 3 hours to make, including animating the character in Spine. Granted, he looks like he has to go to the bathroom but this was just to see if I could whip up something neat in a short time.
The starry sky is one Scenewindow, the Clouds are in their own dedicated scenewindow as well and the bottom part is another scenewindow. I've used scrollers for the background movement so there's no actual movement in that scene.
Conclusion
I just wanted to see how many ideas I could throw out there in a work week and the results are pretty satisfying. That's 4 separate games, every module and system in there 100% reusable in other projects.
USE BEHAVIORS. The amount of time I've wasted trying to make things work without behaviors is insane; every idea I've had turned from a few hundred lines of spaghetti-code into a few neat, easy-to-read script files when I've switched to using behaviors. Most importantly, it was incredibly easy to debug whenever something weird happened. USE. BEHAVIORS. ALWAYS.
It's also pretty clear to me now that T2D can handle everything you throw at it, something which (imho) wasn't true one year ago. The system is more stable, and developing in Torque Script is fun, fast and flexible. Most bugs have been ironed out and you can literally get a game concept running in a few minutes.
If you have any questions on the topics covered here, use the comments below; I'll be more than happy to help you guys any way I can.
About the author
I am here to help. I've worked at every imaginable position in game development, having entered the field originally as an audio guy.
#2
Aside from re-usability, behaviors fix many issues one might have with T2D when first approaching it. The Sandbox examples use behaviors in one or two toys, which I think goes against what would be a more obvious learning path for new users. Granted, some of the toys are extremely simple but could all be refactored to use behaviors. It would also allow new users to have easy-to-use behaviors from all existing Sandbox examples when starting out vs. having to dig in the script to find the lines of code they need.
I've also exposed "cancelpendingevents" to script, it really becomes powerful when used on behaviors and avoids many headaches from callback functions that get triggerred somewhere the designer doesn't expect.
06/22/2014 (11:09 pm)
@Mike : I enjoy what I do! :)Aside from re-usability, behaviors fix many issues one might have with T2D when first approaching it. The Sandbox examples use behaviors in one or two toys, which I think goes against what would be a more obvious learning path for new users. Granted, some of the toys are extremely simple but could all be refactored to use behaviors. It would also allow new users to have easy-to-use behaviors from all existing Sandbox examples when starting out vs. having to dig in the script to find the lines of code they need.
I've also exposed "cancelpendingevents" to script, it really becomes powerful when used on behaviors and avoids many headaches from callback functions that get triggerred somewhere the designer doesn't expect.
#3
I'm a bit torn on whether to teach beginner users of T2D behaviors right away though. Using behaviors, yes, but writing (good) behaviors is not a simple topic. First you have template/instance concept, and all the fun that %this and %this.owner bring inside behaviors. Then, breaking things down into the simplest components, or making them generic enough to use in multiple projects also takes some time to properly learn. It's easy to fall into a trap of "oh, here's a player behavior - this takes care of keyboard bindings, movement, animation states, etc", so you're back at this big blob of a script where mistakes can easily slip in.
The first tutorials from TGB always had you using class-based scripts. I don't know if that's simply from history - where at first TGB didn't have behaviors, or if it's simply an easier concept for new users to grasp while learning TorqueScript.
In any case, one of the things that Mich's editor work has inspired me to look at is the use of Event Managers. It's a new object for me, so I'm trying to behavior-ize it and see if I can come up with any easy to use system to allow for behaviors to communicate with each other across objects, which is an area where behavior connections struggle in my opinion. Hopefully I can throw up a post on that in the coming weeks.
06/23/2014 (3:58 am)
Yes, having a collection of behaviors would be good. TGB had this with the behavior playground demo. Once a scene editor is in place where you can easily attach behaviors to objects, then you get into the ease-of-use that the Game Makers/Constructs/Torque Game Builders of the world allow. It'a good first step for beginners or artists/designers looking to put a game together. Whether this happens through a Sandbox refactor or some other intro module in post-editor T2D world, we'll have to see.I'm a bit torn on whether to teach beginner users of T2D behaviors right away though. Using behaviors, yes, but writing (good) behaviors is not a simple topic. First you have template/instance concept, and all the fun that %this and %this.owner bring inside behaviors. Then, breaking things down into the simplest components, or making them generic enough to use in multiple projects also takes some time to properly learn. It's easy to fall into a trap of "oh, here's a player behavior - this takes care of keyboard bindings, movement, animation states, etc", so you're back at this big blob of a script where mistakes can easily slip in.
The first tutorials from TGB always had you using class-based scripts. I don't know if that's simply from history - where at first TGB didn't have behaviors, or if it's simply an easier concept for new users to grasp while learning TorqueScript.
In any case, one of the things that Mich's editor work has inspired me to look at is the use of Event Managers. It's a new object for me, so I'm trying to behavior-ize it and see if I can come up with any easy to use system to allow for behaviors to communicate with each other across objects, which is an area where behavior connections struggle in my opinion. Hopefully I can throw up a post on that in the coming weeks.
#4
Outstanding! That's the kind of thing I want to hear. As both a valued supporter and well informed critic, hearing this from you is high praise. This is overall motivational. I need to get off my ass and get those editors in my repo.
06/23/2014 (6:53 am)
Fantastic blog as usual, Simon.Quote:It's also pretty clear to me now that T2D can handle everything you throw at it, something which (imho) wasn't true one year ago.
Outstanding! That's the kind of thing I want to hear. As both a valued supporter and well informed critic, hearing this from you is high praise. This is overall motivational. I need to get off my ass and get those editors in my repo.
Associate Mike Lilligreen
Retired T2Der
I agree with the "use behaviors" suggestion. I have a collection of behaviors plus some generic (and not so generic) TAML objects on my hard drive. Makes it easy to quickly throw a test module or prototype together - if the behaviors I need already exist, the only work that needs to be done is simply some XML editing of the TAML objects to tweak their properties and add behaviors to them. The AudioToy is a reflection of my approach in that regard.