The funny thing about releasing a game on Xbox Live Indie games is that you start to view prices in terms of unit sales of your game.
7 copies of Legend of the Rune Lords.
With Monterrey Jack cheese, most definitely.
Indie license for TorqueX 2D ($150)?
214 copies of Legend of the Rune Lords.
Now that’s a good question…
What is Torque X 2D?
For those who don’t know, Torque X 2D (TX2D) is a 2D game engine written in C# using XNA. It’s a member of the Torque family of engines released by GarageGames for various platforms at prices targeted towards independent developers and small studios. TX2D is essentially a C# port of GarageGames’s PC-oriented Torque Game Builder (TGB). It doesn’t quite get the same attention its PC-bound cousin gets, so TX2D isn’t as up-to-date as TGB.
So, how valuable is TX2D for developing a game for XBLIG? It’s… complicated.
Well, TX2D itself isn’t complicated. It’s actually pretty simple and easy-to-use. The tutorials and documentation are a bit of a mixed bag, generally being at various levels of out-of-date, but the developer forums are fairly active and there’s a lot of information to be had. The source code for the engine itself is relatively straight-forward and clean. With the version of TX2D I used, I had some trouble with the RenderMask feature not working as documented, but it was easy to implement the fix I found in the forums.
Core features like building levels in the provided editor, extending object behavior with Torque’s component system, resource handling, texture animation, multiplatform (Win/360) support, all worked without a hitch. I did have a bit of trouble with some exceptions caused by badly configured particle emitters on the 360. However, there was a fair bit of forum traffic on that problem, so it wasn’t too hard to fix. What TX2D does, it does pretty well. The caveat, of course, is that what TX2D doesn’t do can hurt in it’s omission.
TX2D is primarily a single-threaded engine. This helps keep the engine simple, but it does mean that you’re leaving a lot of the 360’s processing power untouched on the table. The biggest place I felt this one was in texture loading. Towards the end of my project, I was dealing with a nearly 30 second load-time going between maps. When I tracked it down, it seemed like most of my time was spent in texture loads, many of which didn’t even seem to be involved with the map being loaded. I haven’t managed to confirm this, but it almost seemed like TX2D was loading every texture I had registered in the editor every time I unloaded then loaded a new map. Ouch. I eventually managed to find a setting that allowed me to load textures just-in-time instead of all up front which allowed me to spread the texture load time across the map while the player was actually playing. The downside was that, because texture load was a synchronous process, I had the framerate hitch every time I encountered a previously unloaded texture. So, I had to choose between extremely long loads or framerate hitches during the first moments of a new map. I settled on the latter, but no one likes dropping frames for something like file access.
The TX2D editor is functional and gets the job done. It manages to do pretty well in keeping the XNA content database up-to-date and keeps itself aware of new components that you add through Visual Studio. Where the editor doesn’t do so well is when you want to work with large numbers of animations or animations with large numbers of frames. The drag-and-drop interface for animation authoring is slow and it’s easy to lose track of where you were in the process when trying to create subtle animations. I eventually got to the point where, if I needed to create a large number of animations, I would edit the level data files manually in Visual Studio (they are in an XML format) as opposed to using the editor. Also, I also couldn’t find a way to mount objects onto other objects through the editor which caused me to write more code than really should have been necessary.
Speaking of animation, the only animation paradigm TX2D supports out of the box is texture animations. That is, anything you animate via their animation system has to be a frame from a sprite sheet. That’s all well and good, but I found the lack of a keyframe-based animation system for modifying the rotation, position, and scale of objects through the editor to be particularly painful. Having to dive into code just to make an object slide into view or zoom in from the center of the screen is just a waste. It is possible to do some keyframe animation using the particle system (and its integrated curve editor; yay curves!), but it’s not particularly intuitive and makes a dodgy interface for animation editing. If a newer version TX2D were to come out with even a moderately well-featured keyframe-and-curve animation system I would be all over that.
I’ve just talked a lot about what I didn’t like about TX2D, but in all fairness there is a lot that it provides in its base functionality. What it provides are a solid implementation of the less-exciting (but necessary) features of a game engine. The features I talked about would definitely make the game creation experience more efficient and pleasurable but they are also fairly non-trivial and would require a significant amount to development time to get right. The old truism about getting what you pay for seems to apply here.
That being said, even implementing the functionality that TX2D does provide can constitute a significant time investment if you do it yourself. Given the two month time-frame I gave myself to develop Legend of the Rune Lords, shelling out for an engine and using it as a springboard for development was almost certainly the right choice.
However, and this is true when using any 3rd-party engine, while you save yourself development time (and, most likely, money) when using someone else’s engine, you also have to give up a certain level of choice regarding how many features are implemented (unless you want to re-implement them yourself.) When in Rome, do as the Romans do. When in Torque, do as the Torque Devs would do.