Torque Game Builder
So I've been trying to learn Torque Game Builder lately. It's an engine that lets you create 2D games, and it seems pretty great actually. It has a visual level editor that's especially good at letting you set up where various objects are on various layers (sort of like photoshop) and also set up collision for those objects, and a million other variables.
It's all powered by a scripting system, and you can use an IDE like Torsion to do debugging on your scripts. (I'm having big troubles getting debugging to work though. When I F5 to start the game with debugging (so breakpoints will trigger), the game doesn't launch at all and instead starts this phantom process called TGB.exe in my task manager that doesn't do anything).
Anyway, the scripting, for better or for worse, is a lot like programming. The syntax is similar to C, but you don't have to worry about managing memory, defining variables before you use them, or making sure data types all match up. So it's easier than real programming in C, but it's still basically programming.
Peter Norvig, Director of Research at Google, wrote an article called Teach Yourself Programming in 10 Years. That also jives with the Scientific American article I linked to earlier; both say that it takes about 10 years to really fully grasp a new subject, though that number can adjusted up or down based on how much coasting versus "effortful study" you put in.
Oh, before we get into that, I also like that Torque Game Builder is cross platform, working easily on Mac and PC, as well as on linux, I think, if you get some help from linux hobbyists. Even better, it can all be ported to Xbox 360 pretty easily, so you have an "end game" upside in case you make something awesome. What's also great is that scripting system and general approach in TGB also apply to Torque Game Engine (and TGE Advanced), the 3D versions of Torque. So if you want to make the leap from 2D to 3D, you still get to leverage a lot of what you've learned.
Anyway, back to the 10 years part. I am currently very bad at this, and it's just painful being bad at something. Going from non-programmer to someone who could create something at all worthwhile (even in TGB) is a big step, and I'm nowhere near it after only a few days. I'm a little torn whether I should continue down this road (for years) until I go have competence in implementing my own stuff. The benefits are obvious, but perhaps that road would never lead to anything as good as gathering some real programmers together right now, and working with them. Design is a full-time job and managing a company (Sirlin Games) is another full-time job, so I probably don't need a third one of being a programmer/scriptor, too.
So far, finding programmers who are competent and have free time and have remotely similar views on the wide variety of games I'd make--has been impossible. That middle requirement (has enough free time) can be fixed by simply paying them enough to quit their jobs. That's a big leap (for both sides here), but perhaps I should think about doing that. Or perhaps I should just keep learning TGB, lol.
Meanwhile, Backbone has lost 8 designers in the last year. 3 were fired and 5 quit. Maybe we lost more that I'm forgetting. I think that's something like twice as many people lost as are currently even still in the design department. So the current leadership there has seen something like 200% turnover rate and a string of games rated 60% on metacritic (or 70% at best) all with low sales, as well as a high profile game cancelled. And I'm personally not even classified as a designer there(ha!) because it's thought that I don't "play ball" with the right people in management. Well, maybe you can see why! The team needs a new coach, but it would be far easier to start a new team if the goal is simply to create good games. But no programmers, no team.
Ok, back to reading Torque documentation for me.
--Sirlin
March 26th, 2007 at 2:06 am
[…] Original post by Sirlin […]
March 26th, 2007 at 10:14 am
Learning new things is noble but at this point you are probably better off finding people.
However if you aren’t willing to pay you probably won’t find anybody competent unless the time committment you ask for is very small. Your best bet is to design something very simple programming wise or else suck it up and pay people, either enough to leave their jobs or enough to ditch all their other free-time activities.
March 26th, 2007 at 12:05 pm
I’m no ninja programmer myself, but these days I think if you feel your design ideas are solid, I think you can get a lot done with the tools available (Torque sounds like one such tool). It will still take work but you can probably put together a playable demo of your core concepts– in a lot less than 10 years, at least. :) I wouldn’t expect to get as far as a title for XBox though, quality control being one major hurdle, I’d imagine. But at the very least, after attempting it, you will have more genuine appreciation for what others on a team have to go through.
Incidentally, I just completed the first version of a small programming project which isn’t a game, but works with video footage. It will be free and I can share the source if you’re interested (not in Torque though). Right now I’m asking jchensor and some friends for some feedback first but let me know if you’d like to try an early version.
On an unrelated note, you guys might find this interesting- Forbes breaks down the costs of a game:
http://www.forbes.com/2006/12/19/ps3-xbox360-costs-tech-cx_rr_game06_1219expensivegames.html
March 26th, 2007 at 10:51 pm
Ugh. I worked on a gaming project for a class once, and all 3 groups used TGB. There were so many strange problems with collision detection and such that did something like triple our planned programming time.
Best of luck getting started and getting TGB working properly though.
March 26th, 2007 at 11:26 pm
I’m definitely interested. I’ve been considering a job in video gaming. Can you download TGB somewhere?
Also, blogs look fun. You can rant.
March 26th, 2007 at 11:32 pm
x1372: Oh, it has collision detection problems? That’s bad, I haven’t run into that yet.
Hitaro: www.garagegames.com
March 27th, 2007 at 2:26 am
The version we were working on did anyway, I dunno if they fixed them. We had several issues where the player character would walk into a supposedly solid object, at certain angles, and would mysteriously teleport through the object. Additionally, the NPCs that were supposed to “chase” the main character if he got within a certain range also had some collision issues, and in some cases would be walking directly into the main character without triggering the battle sequence (or, as the project team called it, “humping the hero”).
Again, this was with the version of TGB that was the “new” one in September of 2006. Updates and fixes have been released since then, so the issues that plagued our game may have already been rectified. I know my group had a lot of headaches dealing with TGB, though in the end we were able to work through it and get our demo finished.
I’m not sure I could reccomend TGB for a professional game setup, but for somethign to mess around with and design a 2D game I say go for it.
March 27th, 2007 at 7:00 am
What’s that they say about getting things done right?
You may be able to get better returns on your time by cribbing from others (AKA using examples) or getting advice from more experienced programmers.
Regardless, a large factor for what course of action is most expedient depends on the scale and timeframe of what you’re trying to do.
March 27th, 2007 at 10:24 pm
I wouldn’t necessarily count it against TGB that your programming time was higher than expected.
Unless you’re very experienced in making estimates for delivering code, a good rule of thumb is to double the amount of time you expect it to take. You’ll still be too low, but you’ll be closer. And that’s for environments you’re familiar with.
March 27th, 2007 at 10:35 pm
So, how easy is Torque to learn for someone whose only actual coding experience is, say, a year of high school VB6 from an incompetent teacher who I knew more than after the third week?
Or at least, compared to something else like Multimedia Fusion?
March 28th, 2007 at 12:17 am
In response to the Backbone jab, it is worth mentioning that the CEO of Backbone/Foundation 9 had a self promoting article in GameDeveloper magazine this month speaking about how important employee retention is. Ironic.
March 28th, 2007 at 2:29 am
“So, how easy is Torque to learn for someone whose only actual coding experience is, say, a year of high school VB6 from an incompetent teacher who I knew more than after the third week?”
I don’t have any experience with TGB, but, generally speaking, but most successful programmers are significantly self-taught.
March 28th, 2007 at 3:36 am
@Rufus:
That’s pretty encouraging, since the whole of game design and creation looks pretty daunting. Still, I think I’m up for the challenge.
March 28th, 2007 at 4:47 am
Sirlin your cool and all and I respect you as a fighting game player. But you have to learn how to manipulte tthe people and the situations around you towards your goal.
Furthermore, if that is not your game then you have to learn the basic concepts that govern thought. The full extent of the power of thought. From how effects yourself and how it attracts the events in your life.
I think it’s time for me to teach you the
“SECRET OF THE UNIVERSE!!!!!”
Once learned, success in any vent ure is preaty much guranteed. For I grow tired of your little sentence long laments of your unsuccessfulness. Mastered winning in games you have, but I shall teach you the secret that will allow you to master LIFE ITSELF!
For who but I, the FINAL BOSS IN THE GAME OF LIFE, could tell one the secret of life!
expect an e-mail soon. . .
March 28th, 2007 at 5:34 am
You do seem pretty unhappy lately. Why don’t you pick out a project that is doable, like an online card game, and find some people to work on it? Or mock it up yourself?
March 28th, 2007 at 6:33 am
Rydell: Some stuff in TGB is very easy. Importing art, placing objects, setting layers for those objects, setting properties like collision or very basic physics on those objects. Anyone could do it. But when it comes to really controlling how the game works, you need to do lots of scripting in a syntax similar to C. It’s not as difficult as actual C because there’s no need to worry about memory management or data types, but it still requires the mindset of programming.
Margalis: I thought I was already doing that. Two programmers (one for game client, one for backend) are working on the online card game now, as well as another artist/designer and another contract artist or two when they have time. It’s all painfully slow because everyone else involved spends too much time at their respective day jobs, heh. In fact, it’s so slow that I could start another entire project in parallel with other people or something.
–Sirlin
March 28th, 2007 at 11:37 am
I tried to take TGB for a test drive earlier today and ran into similar problems when I was trying to start their level builder/tester interface thing, it only worked properly (I hope) after I reinstalled it. TGB.exe appears to be the script interpreter for their games.
March 29th, 2007 at 1:35 am
(sorry another plug) I currently am making a game using RpgMakerXP. It’s really quite wonderful. One could easily make ANY sort of game with the tools it provides. To the point though–there are many resources available that are free and with no property rights/ownership issues. I requested with a fairly generous stipen, a bunch of scripts I needed for my game, but noone delivered. But by taking some pre-made scripts or engines and tweaking them, you can get a lot done. After a few days (though it spanned about a month), I finally got a grasp on some ‘chunks’ of code within the engine I found that I could change quite a bit. With that I could come to understand, a little more intuitively, what exactly I was doing and HOW the programming actually read it. With that I realized I could safely mess around with all sorts of stuff. After a few more days, I overhauled the active time battle system i downloaded to fit my tastes as well as implemented my own combo and counter attacking system.
A thing to note, at least in that community, is that many of the scripts found are universal and you literally just drop them into your game–which is quite nice. However, much more easily you just go into the existing code and start plugging in new variables, switches, and calls. It can’t be shared as easily, but you can tailor it more specifically to your own game and it becomes way easy. I had two semesters of programming one C++ the other visual basic, in high school. The only thing they really helped with is how programming works, no real working knowledge, so I believe anyone could do this after a bit of hard work.
It may seem daunting/sketchy/lame to use pre-made stuff, but I think of it like this. 3d modelling takes a lot of work, so many artists at the beginner level, use pre made skeletons or full blown models to build off of. They do that more and more, changing them more dramatically, taking risks, and reading tutorials until they can easily start making their own from scratch or from a way basic model that has to signs of that in the end. I believe programming can be done similarly with these new non-programmer friendly tools. You could also think of it as playing to win–i don’t know if you are, but I had qualms at first using pre-made stuff, but realized I changed them enought that they became my own. I literally stipped the engine down to nothing and brought up ONLY the things I wanted and am currently altering them to be as perfect for my game as they can be as I add new content as well. Hopefully there’re enough basic resources for Torque as well.
My rpg started as a fighting game, but I hope to take those sprites and bring them back into a fighting game, probably using Torque–and if your description of how its script works is what I take it to be, it should go quite well.
March 29th, 2007 at 5:05 am
Kicks, you make a good case for RPG Maker XP. Here are some concerns. The tool is Windows-only and the output is Windows-only. If you want to create a Mac app, you’re out of luck (much less linux) and if you want to port to Xbox 360, it’s not a given as it is seems to be in Torque. Also, correct me if I’m wrong, but everything I’ve seen come out of RPG Maker looks like a SNES game or worse. Meanwhile, torque has some at decent looking games on Xbox live right now.
–Sirlin
March 29th, 2007 at 6:43 am
On online card game should be quick to do a proof of concept of.
I have been working on and off for a while on an online game that is a cross between Magic: The Gathering and Advance Wars. (Kind of similar to PoxNora that came out recently) Not only does it have your typical client and server and such but it has a 3D map and all that jazz.
It is slow going because I work on it on and off by myself, so I lose motivation sometimes, but getting to a working demo probably took 80 hours of work I would guess.
March 29th, 2007 at 6:44 am
What are you using for client side and server side tech? And are you trying to produce a proof of concept, a demo, or an actual game?
March 29th, 2007 at 10:51 am
Everything you mentioned is true. Though I was mostly interested in portraying that ‘I believe’ in the idea that a not-so-programmer can get the programming work done, in slight defense of RMXP: while most of the stuff does definitely look like SNES, it supports much better than that. The problem is mostly the community–they just don’t try very hard in that area. Though i’m not sure if 3d could be possible, it’s mainly 2d stuff. Any 2d screens i’ve seen of torque, rmxp can do it too (based on looks at least). The only thing it might not handle well is paralax and layering. It would take a little more work than it would in torque.
As for the console and non-windows stuff… yeah, that part totally blows. Some claim that you can get it going on a 360 or psp but apparently they run a form of windows. Otherwise it’s more likely that they’d be emulated rather than ported on another system. But all limited ‘evidence’ of rmxp games on consoles has been very very laggy.
March 29th, 2007 at 11:55 am
Margalis: My goal is not a demo or proof of concept, but an actual online card game. I already have proof of concept that the game is fun and works after playtests with physical cards. I actually have a series of 3 card games planned. The first one is very far along and has lots of testing. The second has only a bit of testing, but shows promise. All the design data is not yet in place, but getting there. The third game is the most ambitious and has had a few tests with physical cards, but I’m delaying development there until the first two games are more in place.
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
March 29th, 2007 at 2:39 pm
Choice of back end is not going to be trivial unless this is a peer to peer game. My project is client-server so the server really does most of the work. (All the game state tracking and such)
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.
March 29th, 2007 at 9:46 pm
For peer to peer or proof of concept, it can’t be that hard to stick a custom card database into mindless automaton or some other generic card engine. The hard part of things like this is probably going to be:
Ease of use
Game rules enforcement
Security and dealing with money
March 30th, 2007 at 12:10 am
“And I’m personally not even classified as a designer there(ha!) because it’s thought that I don’t “play ball” with the right people in management.”
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.
March 30th, 2007 at 1:24 am
Forty, I was a designer on Death Jr. 1 (PSP) and a producer on Capcom Classics 1, remixed, 2, and Sega Genesis Collection. I also did whatever “design” was needed on those things, such writing the game “tips,” desiging button config, overall layout of the collections, the tutorial videos, the Quiz and Dragons remake (wrote hundreds of new questions), and things of that nature.
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
March 30th, 2007 at 2:46 am
Thanks for the response — and the interesting blogs.
April 3rd, 2007 at 5:49 am
Great Blog and great comment discussions.
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
May 9th, 2007 at 9:59 pm
TGB sounds pretty interesting, maybe I’ll fool around with it next time I’m bored in front of a PC. I understand the license is really cheap, but can you download it for free before paying, just to play around?
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.
May 21st, 2007 at 8:25 pm
I’ll probably have to take back that warning above… I grabbed the beta of the Torque X version of TGB (TGBX). So far I’ve just been reading the docs, but it seems really cool. It’s already a world of difference between that and the Tribes 2 hacking.
June 2nd, 2007 at 7:15 am
JustOwnin: share the wealth! What’s the secret of the universe?