Torque 2D Game Builder Quick Review
Taking the Plunge Into the Second Dimension!

UPDATE (6-8-06): Due to number of issues that cropped up in RC1 of Torque 2D Game Builder, GarageGames announced Wednesday that they would be pushing back the final release (and the price increase) to address bugs - many of which I brought up in this "First-Time User Experience" review. As of right now, RC2 is available, which should be much more stable. I haven't tried it yet.

I realize that this was a dissapointing event for GarageGames and the TGB devepment team that has been working around-the-clock on this release, but I have heard from these same, overworked developers that they felt strongly that it was the right thing to do. Massive props to GG! I think this speaks highly of their commitment to making TGB a success.


The "Torque Game Builder" (formally known as Torque 2D) is losing it's "Early Adapter" status and is going up in price in a couple of days (June 7). Well, kinda. It's still going to be $100 for a license for indies for the "binary" version without source code. But the price is going to go up to $250 for the indie license with the full source code.

I'd been considering getting TGB for a few months, mainly for rapid prototyping of ideas. When they announced that it was now capable of rendering 3D DTS models, I was sold, but I still hesitated to purchase it because I didn't really need it *right now*. The impending price increase spurred me into action. If you are like me, you have two more days to get it at the reduced price point, after which the price goes up SIGNIFICANTLY if you want to have the source code version. (And I'm gonna say right now - YOU DO).

The Pricing Dilemma
As far as the price is concerned - I think GarageGames has kinda painted itself into a corner. Their initial objective for the Torque Game Engine (back when it was under a different name) was to make an industrial-strength 3D, networked game engine available to ANYONE who wanted it. The $100 price point meant that even a 13-year old kid with dreams of becoming a l33t game designer could mow lawns for a month and afford the engine. This was a great, idealistic goal, and I certainly applaud them for it.

But the problem is... the game engine is available to ANYONE who wants it.

An experience game developer who has worked on 3D or networking engine development knows what a pain in the keister it is to build and maintain something of this scale, and intuitively understands that the bargain-basement price of Torque comes with some concessions. Concessions like less-than-stellar documentation, no one-on-one personal tech support, and so forth. Now, I have not personally worked with a major third-party 3D engine before, but the stories I have heard is that the level of customer support you get for a $500,000+Royalties engine isn't a whole lot better than that.

But then you've got that thirteen-year-old who's been mowing lawns for a MONTH to purchase this game engine. He doesn't have the same perspective - $100 is a lot of money, and he's got plans for making the next Halo. Once he gets past the novelty of loading in his own models into an empty 3D world, he wants to know, "What do I do next?" He needs mentoring and guidance for this monstrosity he's purchased, and nobody's giving it to him. He constantly demands customer service and training to use this expensive piece of software. When he doesn't get it, he gets very frustrated. And when he does get it, he's soaking up resources that could be spent on getting the next revision done.

I believe that what GarageGames is doing with this tiered pricing structure for their Game Builder product is to try and deliver something "safe" to this audience. If you are willing to pay an extra $150 for source code, then you understand the value of it and aren't afraid to dig in and get your hands dirty. The $100 product will take care of the "entry-level" people who just want to tinker.

That's my conjecture, at least. I don't pretend to understand what the minds at GarageGames are actually thinking at this time. But that logic makes sense to me.

What Does It Get You?
But then comes the real question: Is it worth the $100 / $250 price tag for a small indie developer on a tight budget, especially when there are competitive 2D game development options out there like PopCap's free framework (well, free, unless you are selling a game using the built-in audio options, in which case you owe SOMEONE a license fee), SDL (free, open-source), and PTK?

I've only had a couple of days to play with the engine, so I do not have a definitive answer. But here's what I've come up with so far:

The Torque Game Builder is, at its heart, a scripting language for creating 2D games. But it also comes with a lot of tools to make things a little less painful for game developers. Going through the included "Basic Tutorial," you can throw together a playable 2D shooter in a matter of HOURS through the built-in tools. However, what TGB does NOT provide is a "click and play" level of functionality that completely isolates you from the need to code. If you are an artist with no desire to touch the programming side of things, the Torque Game Builder's tools won't magically build your game for you.

However, what the tools DO provide is a very streamlined, fast interface to putting together levels, UI's, and so forth. Getting pictures up on the screen and rudimentary behaviors implemented is extremely quick - or it least it should be. Once some bugs are ironed out and you know what you are doing. Then begins the real work of creating quality content and code.

Getting My Hands Dirty
From my own experience, I started out trying to put together a very basic top-down shooter - the type I enjoyed in the arcades as a kid. I found I had archived some free "SHMUP" (Shoot-Em-Up) 2D space ship art by Nauris Krauze and Craig Fortune. I also had a bunch of old art resources from Void War that I figured I could re-apply to this quick-and-dirty project. I wanted to bring in a 3D model to see how hard it would be to integrate some 3D elements into a 2D game.

Installation didn't go as nicely as I'd have liked. Choosing something other than the default directory resulted in a failed installation. Actually, everything still WORKS, but the desktop shortcuts and the uninstaller never made it. While not a significant issue by any stretch, it does hurt my confidence a bit. But I'm evaluating a release candidate, NOT a final version, and I know from painful experience how these things happen.

My project was based heavily on the "Basic Tutorial," but with some pretty substantial differences. My very first attempt was stymied within an hour. As soon as I had to start creating new script files, I opened up Codeweaver (TorqueDev) and started putting things together. Inexplicably, the next time I tried to load my project into the editor, TGB froze on load and would simply not return. I had to shut it down with ALT-F4 and see the "program is not responding" message. I don't know what I did that caused it, but nothing I could do could fix it. So I ended up having to create a new project.

Starting over from scratch was a pain, but I was able to replicate the previous hour's work in about ten minutes. So that may demonstrate how much more productivity the toolset can provide once you have gotten accustomed to it. I had the player ship, a starfield background in another layer, and an enemy ship waiting off-screen. The player ship was controllable with arrow keys (a quick look-up into another part of the reference documentation revealed that the strings used to detect cursor-control arrow keypresses were, mysteriously, "up," "down," "left," and "right." Go figure!)

One frustrating problem I discovered is that the main T2D tool doesn't recognize changes that have been made to code outside of the editor. I had to get into the habit of leaving the editor shut down, only bringing it up when I really had to. This is unfortunate, as the editor looks like it's trying to become it's own "mini-IDE," left open constantly.

A Taste of 3D
I was still using a 2D sprite for the player ship control at this point, so now I decided to go exotic. Hunting down the old Milkshape model for the Osprey in Void War, I converted it to DTS format. The documentation that comes with TGB says VERY LITTLE about bringing in 3D objects, but a hunt on the "Torque Developer Network" revealed a basic script-based way to make it work. I was going outside the tools, but it was still a pretty trivial scripting job. Ten minutes after finding out this critical information, I was able to replace a 2D sprite with a 3D object, and get it scaled and rotated into position.

Moving the 3D ship left and right was fun, but I wanted to have it bank as it moved left and right. A little more digging revealed the "setShapeAngularVelocity" command, and I thought I was home free. There was a small trick - I needed to be able to switch to banking at a different angle at a moment's notice, before it had completed it's full bank. All it would really take is doing a comparison of the fighter ship's current bank with it's desired bank, and calculate the amount of time it would take to turn the remaining amount, and which direction the new bank should take place.

This is where I discovered that the function that reads the 3D Shape's rotation in does NOT take into consideration accumulated changes from angular velocity. So reading in the rotations just returned the original starting rotation. I posted a message on the bulletin boards to see if anyone had an answer to my query. Nobody did.

Undaunted, I decided to fire up the SOURCE CODE and see what I could find. Sure enough, the ROTATION values were an euler vector being returned by the engine are really just storage - the actual rotation matrix is being calculated by a quaternion class which is being directly modified by angular velocity. But the changes weren't being reflected back in the the euler rotation vector. My initial mathematical hack to eulerize the resulting matrix and stuff those values back into the euler vector didn't work, so I came up with an even less elegant hack. But it worked. A couple of hours later, I was able to read the cumulative changes from Angular Velocity.

Go me! But this required a recompile of the source code - something that would not have been available to someone who had the Binary license.


Finishing Up
After that, everything else pretty much followed the tutorial without a big hitch. Getting the enemy ships to fly past the player along random, mostly-straight paths was easy. Getting collision woking the player's laser shot was a little tricky, simply because I'd left in a statement disallowing callbacks. Once I found and fixed that, things came together quickly.

Working with particle systems using the built-in particle engine editor was a little frustrating, but I was operating it cold, without having read the fine manual (or PDF document) beforehand. It is NOT an intuitive tool.

The game is not yet done, but it's I was fairly impressed with what could be thrown together by a beginner to the tools in a matter of about six hours.

Pros and Cons
So after an admittednly limited evaluation period, here are some of my thoughts on the Pros and Cons of the Torque Game Builder:

PRO
* Inclusion of 3D model support - so you can have an eye-pleasing mixture of 2D and 3D elements in your game
* A nice suite of tools to assist in rapid development and prototyping
* Underlying engine is mature
* Built-in Multiplayer / internet game support
* Reasonably complete documentation and tutorials included with the installation
* Strong community support
* High Performance
* Very pretty particle engine

CON
* Even the RC1 release still feels buggy - IMO, it's not ready for a full release yet (though it's close).
* Inadequate documentation and functionality on the 3D Shape class
* Engine requires 3D hardware, limiting potential market (but not by much, these days)
* Particle Editor was non-intuitive and kept resetting the scale of the graphs on me.


Evaluation
If you get the Torque 2D Game Builder right now for $100 (or $80 if you are a TGE owner), and you plan on creating and selling 2D games in the future, it is my feeling that the TGB is another 'steal'. It's dirt-cheap, it offers a much gentler learning curve than it's older brother, the Torque Game Engine. And I see the inclusion of the new development tools as a speeding up the development process and helping newbies and seasoned vets alike get over those awkward early prototyping stages and into the hardcore dev stages.

I personally do not feel the TGB tools are quite yet "ready for prime-time." I experienced too many bugs in my initial experience to feel comfortable with the tools "as-is." There are also some quirks, like having to restart the main TGB tool anytime you modify the scripts. It's certainly possible that they may have these worked out in the next few days, but I am a little concerned that RC1 feels a little too unstable still with such a short time-frame to release of an official version 1.0. That being said, even earlier versions of TGB have been used for commercial products already --- so this is not a show-stopper.

The "killer feature" for me was the integration of 3D models into the engine, but it seems like this feature is being downplayed right now. The missing functionality and lack of included documentation or direct tool support certainly makes it look like a second-class citizen. Reading the correct rotations for the model was a pain and required a recompile, but simply adding the model to the game was a piece of cake even without tool support.

As a "power user," I have a difficult time recommending the "Binary Only" distribution. Sure, it's only $100... but will it provide all the power someone needs to build a full 2D game? I think so, but it's really hard to say at this point without diving much deeper into the engine. It is definitely a lot more accessible than the Torque Game Engine for a first-time game developer, and most competitive products that offer this layer of abstraction are getting kind of long in the tooth (such as DarkBasic). EVENTUALLY, if GarageGames continues to support this product (and there's no signs that they are going to stop), I think this will eventually be a a reasonable offering.

And the biggie - the $250 indie license for the full source code. Is it worth the extra $150 over the price of the binary? If they manage to clean up the list of outstanding bugs that remain from the last beta and release candidate, then I'd definitely give this the nod of approval. I'm very impressed with the speed at which I was able to go from being a near-total n00b* to getting something resembling a game up on the screen.

The $250 price tag is a bit steep if you are not serious about making a go at it with developing commercial products. If you are only going to be making freeware games or tinkering with projects to satisfy your own curiosity, you may be better off going with the Binary release, or experimenting with one of the free engines out there. But taken as an investment, I can't see how this wouldn't be money well-spent, and would pay for itself from the very first project with reduced development time.

* I do have a bit of experience with the TorqueScript language with TGE. While there are some different classes and utility functions to learn in TGB, the fundamentals of the language carry over very nicely, which eased my transition.

Labels: programming, Torque

- posted by The Rampant Coyote @ 10:30 PM (Permalink)