If you’re considering learning programming with TGB as your medium, I have to issue a warning:

Watch out with “easy” scripting languages.

I haven’t used the 2D TGB, but for years I was a Tribes 2 junkie, so I have used TorqueScript in their 3D game engine. I’m a professional (non-game) developer, and I did a few hobby projects.

I found that with the 3D Toque scripting, it was very easy to accomplish something the script designers expected you to want to accomplish, but that it could be pretty tough to step outside their predictions. I imagine this is probably true of most game scripting because those scripts are inherently running on top of a hard-coded engine.

Maybe this is too much developer detail, but if you want a taste of what I mean, you can read on…

I created a modified version of the Deathmatch gametype, partly inspired by some of your discussions about the enforceability requirement for game rules — ie no unwritten “house rules.” (This is available at ricefrog.webhop.org, the readme file talks about the house rules it seeks to eliminate. If anybody wanted to see the code you could just rename the .vl2 file to .zip and then unzip it.)

I also fooled around with bot combat AI and created a single-player “survivor” gametype as a testbed for the new AI enemies.

Anyway, back to the point that it’s very easy to do things they expect you to do, and tough to do those things they don’t expect…

For example, it was generally accepted that flash grenades should not be allowed in the deathmatch type in Tribes 2, because a player could ruin everyone’s day by spending all his time jumping into the middle of big fights and spamming flashes everywhere. Here’s how easy it was to completely remove flash grenades from the game:

$InvBanList[FrogDM, “FlashGrenade”] = 1;

They have a global variable called $InvBanList just WAITING for you to disallow stuff. Great! But good thing they saw my need coming…

What happens when they don’t?

Tribes 2 combat was heavily about movement, and during my AI experiments, I was struggling with a way to reconcile the multiple, often conflicting, demands for movement. I eventually settled on an idea of stepping over a set of needs (ie chase/flee, weave side-to-side perpendicular to people shooting at you, avoid an incoming projectile, etc) and have each of these needs add a vector to a “wish list”. This wish list of vectors would then be summed up and the bot would run, jump, or fire its jetpack to move in the resulting direction.

This would be pretty cool, because a bot might come tearing at you to get into a close-range attack, but it would simultaneously be weaving side-to-side as you tried to fire on it, and then it would leap out of the way as you fired at it.

Sadly, the “list of vectors” part was a problem, because after I created a class to represent a vector, I discovered that, as far as I could see, there was no list class that I could put them in. No List!!? I had to code one myself, which wasn’t THAT bad, but it would have been ugly for someone just learning programming.

Far worse, I discovered that analyzing projectiles was something that the designers never expected me to do. There was no way to walk over a list of projectiles to evaluate them for dodging logic. I can’t remember exactly the details, but I did some all-nighter hardcore investigating and I found that you could access a list of “stuff” that included far more than projectiles. And using certain properties of the “stuff” in this list, you could weed some of them out as definitely not being projectiles. And I think that some of the projectiles were not even in the list for some reason.

But in the end, there was absolutely no way to uniquely identify an incoming mortar shell from other, much more innocent stuff.

It was a huge disappointment to me, but I couldn’t find a way around it.

So in the end I was left with bots that would run for their lives when you shined the targetting lazer on them, but might not get out of the way of a plasma blast.

And even to get them that far would have been hell on earth for somebody who wasn’t experienced in debugging code and exploring APIs.

My point is that when you’re working with these scripting systems, you rely heavily on examples and documentation, and they make things look easy. But the second you step off the beaten path you’re rolling the dice. You might find an easy or slick answer just waiting for you to pluck it, but then you might say “ok, now for the easy part” only to find that when you thought was simple is actually not even possible, because nobody ever thought you might want to do it.

Discovering what can and can’t be done in that way can be extremely frustrating, and I imagine it would be far more so if you’re just learning about how to debug code.

I don’t want to discourage you because I think MY life would improve if Sirlin Games was a one-man game-cranking machine, but I’m just saying that if you do settle in to learn to program on a game-scripting platform, bring your lunch pail and your hard hat and be ready to work past some frustration.

Disclaimer: Please note that I’m not an expert in Torque stuff, and I undestand that TGB and TGE are two different products, and that Tribes 2 is an old-school ancestor and the new stuff is probably much better and far more general.

If you every have any issues or need any help be sure to visit the TGB private forums… we have a lot of active community members and some of us at GG like to scan the forums and help out when we have some time :) Glad you enjoy the engine and also please post any feedback and/or suggestions on the forums to, we are always trying to make it better.

Matthew Langley
Lead Documentation Engineer
GarageGames

Additionally, I have worked on numerous design proposals to get Backbone new contracts. Some of them we did get, and the best ones never got their shot because of various business issues that cut things short (mostly about who really turned out to have rights to this or that, or about management randomly changing at other companies in the middle of things). Anyway, I can’t talk about any of that, but if I did, I would definitely be on the “front page of the internet” for one day. I’ll bite my tongue though.

–Sirlin

From this article, you’re obviously not a coder/software developer, and apparently not a designer. What is it that you do then? Besides show people how to kick ass at SF2T, anyway.

If you are doing it peer to peer the server doesn’t matter much but then you have to deal with security and other issues like that.

Anyway, the efforts to make an online version are currently entirely centered around the first game, called Yomi: Fighting Card Game. The client is being written in TGB (by a programmer, not by me), and the backend (matchmaking, accounts, records, payment system) was planned to be in python, then in ruby, and now perhaps in python after all. That should be an indication that the backend has no progressed much, lol. Unfortunately, neither has the game client, but this is not at all due to lack of skill of the programmer involved. It’s entirely due to his day job going into overdrive, leaving him with very little free time. There’s an ironic statement on time vs. skill in there somewhere.

It’s actually been 5 months since I first started working with these two programmers on the online version. I guess that’s somewhat embarrassing that we don’t have much worth showing yet.

–Sirlin