I have been playing around with 2D game development  and XNA since the first beta of XNA (launched my site basically at the same time). I just recently gave TorqueX  a try this last weekend. I was done playing with it in about an hour.

I guess for me, XNA has made game development so much easier and so much more approachable, that the learning curve of trying to figure out how in the heck I was supposed to use TorqueX just was not worth the time. I did not successfully get anything to work in TorqueX (granted I did not read any documents or tutorials either), but I did not for XNA either and I had something displaying on my screen in five minutes and moving around in another five using XNA only.

I can appreciate the niche that TorqueX is trying to fill, but I am a developer by day and when I code my games at night if I was to use something like TorqueX I would expect it to be instantly intuitive and more drag and drop. That's why I have been recommending it to non-coders and people new to game development. After playing with it this weekend and the level of confusion I had in getting it set up and working on a project and figure out what anything meant, I honestly feel I could explain to them how to code in C# and make a game using XNA faster. 

Again, I recognize most of my opinions are unfair since I did not read anything at all about how to use TorqueX, but my perception of the product was that I would not have to. But since you are looking for some feedback, I still felt I should share my thoughts.

So maybe it is the marketed perception of what Torque is and can do for you that is causing people not to use it? I know for me there was a big disconnect from what my perception of what it was going to be to what I spent a frustrating hour trying to figure out.
 

Blowfish--sorry if I sound obtuse, but I have no idea at all what you are talking about. Honestly, I think you are confusing Torque X with Torque Game Builder, or you were in really early beta.

 

With TorqueX, I feel there is too much Torque, and not enough .Net. Torque was designed for C/C++ developers, and it's wonderful for that crowd. However, I feel TorqueX was simply "ported" to "work with" .Net, not designed with .Net in mind from the ground up. There are a good number of times where things could be done "the .Net way," but instead, they were done with a custom scripting language, outside of the IDE, with no intellisense, strong-typing, etc.

There is no custom scripting language in Torque X--it's C# all the way. From the underlying engine to how you "script" for it, it's all C#. The only IDE is GSE. Torque X was not a "port" of original C++ Torque, but actually a completely redesigned and engineered from the ground up engine layer on top of XNA.

I guess I can see misunderstanding that if you used TGB (c++) with the expectation that this is what Torque X was all about, but it isn't!

Perhaps an example is in order. Let's take the example of exposing "properties" of a game object that I created into the editor. We can get this in the .NET world with the design type support and the kind of attribute-oriented programming that is done with Windows Forms. However, with TorqueX, to expose "properties" into the editor, we now have to peek out into the scripting language _outside_ of .NET and use something that has no intellisense, is completely different from .NET, and is not strongly-typed. It's not easy to discover "what are all the different ways I can expose this property," or "what are the different editing options I can give the user in the editor." It's a very non-.NET-esque way of doing things. This is why it fails more like a "port" to me than a .NET library.

This probably happened after your experiences, but to expose a property to the editor (TGB-X), you do one thing: put a schema tag in front of the public declaration:

        [TorqueXmlSchemaType(DefaultValue = "")]
        public TorqueObjectType Affects
        {
            get { return _affects; }
            set { _affects = value; }
        }

That automagically populates TGB-X with an updated schema of information regarding your class (which is performed as a post-build step, so you must successfully build your project first), and then TGB-X detects the change in the schema, and asks if you wish to reload. Once you reload, it automatically reconfigures the editor to allow you to edit the property.

It even auto-recognizes what type of property it is...for example, in the above code block, TorqueObjectType is basically a bitmask (I'm not up to speed yet on C# concept names, it's probably something different in XNA speak), which has the editor create a different type of input UI, which allows you to select from all the available TorqueObject Type flags, click a button to add or remove that type of flag to the property. It's that simple.

Out of all I've seen, the only things that I can see as being "stumbling blocks" to experienced game developers, and especially C# developers is our concept of OOP. Instead of using inheritence, we use aggregation--you are provided basic object classes such as SceneObjects, AnimatedSprites (not their full class names), etc., and you aggregate properties and behaviors that you have written (or have written previously for other projects, or have gotten from 3rd party sources). Since most experienced developers are used to the "normal" concept of inheritence, best practices for making components (what the aggregate is composed of) can be a bit unusual at first, but out of all the things people have said about Torque X, components are without a doubt a positive and extremely useful feature.

Based on your input especially, I can see that there is a lot of misunderstanding about Torque X's design and utilization--and I'm working on helping out with that as quickly as I can!

Good points all around blowfish.

The only thing that i may be misunderstanding you on though is having to learn script.

With TorqueX you code in C# there is no scripting. All the editors do is allow you to put things together and it saves as a xml file.

Beyond that you consome the classes from torquex that allow  you to handle a lot of the mundane areas a lot quicker.

 

Stephen--

You know I love you guys, but i have to say that it bugs me that i have to dig through forms on the XNA board to find out new information on TorqueX.

I realize a lot of it has to do with GDC but man, it would be nice to read this sort of stuff over there first

-Charlie M

XNADevelopment:

I have been playing around with 2D game development  and XNA since the first beta of XNA (launched my site basically at the same time). I just recently gave TorqueX  a try this last weekend. I was done playing with it in about an hour.

I guess for me, XNA has made game development so much easier and so much more approachable, that the learning curve of trying to figure out how in the heck I was supposed to use TorqueX just was not worth the time. I did not successfully get anything to work in TorqueX (granted I did not read any documents or tutorials either), but I did not for XNA either and I had something displaying on my screen in five minutes and moving around in another five using XNA only.

I can appreciate the niche that TorqueX is trying to fill, but I am a developer by day and when I code my games at night if I was to use something like TorqueX I would expect it to be instantly intuitive and more drag and drop. That's why I have been recommending it to non-coders and people new to game development. After playing with it this weekend and the level of confusion I had in getting it set up and working on a project and figure out what anything meant, I honestly feel I could explain to them how to code in C# and make a game using XNA faster. 

Again, I recognize most of my opinions are unfair since I did not read anything at all about how to use TorqueX, but my perception of the product was that I would not have to. But since you are looking for some feedback, I still felt I should share my thoughts.

So maybe it is the marketed perception of what Torque is and can do for you that is causing people not to use it? I know for me there was a big disconnect from what my perception of what it was going to be to what I spent a frustrating hour trying to figure out.
 

 

This one I can understand for sure--familiarity with existing development tools you are familiar with, vs learning different ways of doing things.

One of the things you very much missed out on by not reading any documentation was the concept of aggregation and how you build up complex objects...you don't inherit anything at all basically at the game development level--you write components, and then aggregate your game objects with those components.

Here is a "developer created" movie that's rather long, but demonstrates a level building using a complex "starter kit" put together as a product GG will be selling as an add on to Torque X that demonstrates the flexibility and capability of aggregation.

Basically, the starter kit developer spent a couple of months analyzing the behaviors and properties of 2D platformer games as a genre, and built a series of components that implement those behaviors, all exposed to the level builder (TGB-X).

The strengths and advantages of this approach is that after that development is complete, the process of making the game is entirely drag and drop. You're watching a compressed version of the "start to play" implementation of a game level using just the starter kit. The entire level building process (by someone that was obviously familar with the kit and the components) took approximately 30 minutes.

The video is about 10 minutes, and does consist mostly of watching someone click on fuzzy images and dragging/dropping things around, so I suggest you skim through it. Gameplay/testing of the level starts at about 8:42 into the video.

You Tube Demo of the Torque X Platformer Starter Kit.

I hesitated to link this video because it is not part of the Creators Club Torque X package (will be sold separately), but I did want to demonstrate what working within the Torque X paradigm can do for game creation!

 

Valrith:

Here is a "developer created" movie that's rather long, but demonstrates a level building using a complex "starter kit" put together as a product GG will be selling as an add on to Torque X that demonstrates the flexibility and capability of aggregation.

Basically, the starter kit developer spent a couple of months analyzing the behaviors and properties of 2D platformer games as a genre, and built a series of components that implement those behaviors, all exposed to the level builder (TGB-X).

The strengths and advantages of this approach is that after that development is complete, the process of making the game is entirely drag and drop. You're watching a compressed version of the "start to play" implementation of a game level using just the starter kit. The entire level building process (by someone that was obviously familar with the kit and the components) took approximately 30 minutes.

The video is about 10 minutes, and does consist mostly of watching someone click on fuzzy images and dragging/dropping things around, so I suggest you skim through it. Gameplay/testing of the level starts at about 8:42 into the video.

You Tube Demo of the Torque X Platformer Starter Kit.

One of my questions that I haven't found in skimming through the material I've read is how creating, say, a typical Mario level would work? Would you still do it like in this video? How would you scroll the level to get at the far ends? I'd love to use TorqueX for what I'm working on but I fear the learning curve wouldn't be easy enough to get my project done in time, especially given the scarcity of documentation. :(

Valrith:

Here is a "developer created" movie that's rather long, but demonstrates a level building using a complex "starter kit" put together as a product GG will be selling as an add on to Torque X that demonstrates the flexibility and capability of aggregation.

I found that video and some other ones on YouTube.  Someone needs to either put up a real-time version, or convert that to a written doc/instructions.

I hesitated to link this video because it is not part of the Creators Club Torque X package (will be sold separately), but I did want to demonstrate what working within the Torque X paradigm can do for game creation!

Thanks for being honest.  So there will be TX Pro and TX Express?  Can you tell us if the beta we have now is basically what CC users will get? Alot of people here are DBP hopefuls, so if the beta is what CC will be getting, it's easy to see why they want to roll their own.  TXPro may attract some people when it's available, but most people are probably not going to wait for that.  TX is really a hard sell without better docs, list of features, and some killer demonstrations.

Machaira:

Valrith:

(snip).

One of my questions that I haven't found in skimming through the material I've read is how creating, say, a typical Mario level would work? Would you still do it like in this video? How would you scroll the level to get at the far ends? I'd love to use TorqueX for what I'm working on but I fear the learning curve wouldn't be easy enough to get my project done in time, especially given the scarcity of documentation. :(

 In this particular example, you simply mount the camera to the player object. From there, everything is done for you scrolling wise--movement inputs go to the player object, and the camera is mounted to that object, so the camera follows along.

I hadn't ever done this myself before, so here's what I did:

--in the stock MovementComponent.cs (where the input maps are set up for your object that will receive inputs from the controller/keypad), I added one line of code:

(T2DSceneGraph.Instance.Camera as T2DSceneCamera).Mount((this.Owner as T2DSceneObject), "", false);

I pulled the current camera object out of the SceneGraph's Instance, cast it as a T2DSceneCamera (which is a T2DSceneObject as well due to inheritence), then used the mount method, which takes three parameters in this version: 

Object to mount to: Since "this" was a component of the object I wanted to mount the camera to, I had to reference the Owner, and since Mount is a method on the T2DSceneObject class, I had to cast it as such.

Name of Link Point to mount to: Since my player object doesn't have link points, I sent an empty string, which defaults to mounting on the mountee's pivot point (center of object)

Owned by Mount: this param controls things like chains of mounted objects that will automatically apply modifications that their mountee has applied, such as isVisible(), etc. I elected false, since it doesn't apply in this particular instance.

I'll be right up front to those that are discussing the lack of documentation: Being that I myself am completely new to Torque X as a user (theory is another thing!), I couldn't find any information about how to find the "current" camera, and had to do a search in a project I new was doing something similar (the platformer demo ironically, for which I had the source), and then figure out what it was doing. This obviously is not user friendly documentation in the least, but I promise it's something we are working on!

 

EDIT/ADD: I am here pretty much full time to help Creators Club members get over the learning curve of Torque X and TGB-X while I'm working on the documentation (and learning it myself!), and I have pretty direct access to the Torque X developers for any questions I can't answer directly.

Right now, the process of question/answer, and more specifically where this should be done (GG forums or this forum) hasn't been ironed out yet since just about all of the parties in both companies to decide that are chin deep in GDC. As soon as I have more guidance on the "where and how" for information, I'll let everyone know!

Waruwaru:

Valrith:

(snip)

I found that video and some other ones on YouTube.  Someone needs to either put up a real-time version, or convert that to a written doc/instructions.

Agreed, and it's part of the Platformer Starter Kit package

I hesitated to link this video because it is not part of the Creators Club Torque X package (will be sold separately), but I did want to demonstrate what working within the Torque X paradigm can do for game creation!

Thanks for being honest.  So there will be TX Pro and TX Express?  Can you tell us if the beta we have now is basically what CC users will get? Alot of people here are DBP hopefuls, so if the beta is what CC will be getting, it's easy to see why they want to roll their own.  TXPro may attract some people when it's available, but most people are probably not going to wait for that.  TX is really a hard sell without better docs, list of features, and some killer demonstrations.

Torque X is currently packaged in two forms:

"Express"--you get complete functionality of the engine, basically as an API, all functionality fully accessable via C# within GSE. This is free.

"Pro"--you get the source code of the above engine. This will have a price tag in the area of $100-$200 (not firm yet)

"TGB-X"--you get the editors and tools that give you the additional ability to do scene management, object creation and aggregation, and all the other things that the tools provide. This will also have a price, but if you own TGB (the c++ 2D engine), it will be free as well.

As far as I am aware right now, when Torque X is general release (it's beta at the moment), CC members will get the "Express" engine binary, and the "TGB-X" editors as part of their CC membership. They will have the option of purchasing the source code for the binary as well, but I have no information as to what the price will be.

Please keep in mind that as a company, GarageGames normally has two tiers of licensing..."Indie" and "Commercial", and we have not yet discussed internally or externally how that will apply to Torque X. The Commercial vs Indie licensing tiers are based on the income of the company purchasing the license, and have different degrees of flexibility for use (Indies have to have a splash screen, commercial licenses do not. If your company makes over $xxx thousands of dollars yearly, you are required to buy a commercial license, etc).

Currently, a lot of the "indie vs commercial" doesn't apply directly to the Creators Club, but I'm reasonably certain that the licenses Creators Club members receive will be "Indie" versions once that's ironed out.

During the beta process of Torque X, CC members will continue to have access to the latest open beta versions of Torque X and TGB-X, and will receive the General Availability versions once they are released as well.

Hope that clears up more than it confuses!

Valrith:

Machaira:

Valrith:

(snip).

One of my questions that I haven't found in skimming through the material I've read is how creating, say, a typical Mario level would work? Would you still do it like in this video? How would you scroll the level to get at the far ends? I'd love to use TorqueX for what I'm working on but I fear the learning curve wouldn't be easy enough to get my project done in time, especially given the scarcity of documentation. :(

 In this particular example, you simply mount the camera to the player object. From there, everything is done for you scrolling wise--movement inputs go to the player object, and the camera is mounted to that object, so the camera follows along.

Is this at design-time (which is what I was referring to)? This sounds like a run-time thing.

Thanks for responding.

Machaira:

Valrith:

Machaira:

Valrith:

(snip).

One of my questions that I haven't found in skimming through the material I've read is how creating, say, a typical Mario level would work? Would you still do it like in this video? How would you scroll the level to get at the far ends? I'd love to use TorqueX for what I'm working on but I fear the learning curve wouldn't be easy enough to get my project done in time, especially given the scarcity of documentation. :(

 In this particular example, you simply mount the camera to the player object. From there, everything is done for you scrolling wise--movement inputs go to the player object, and the camera is mounted to that object, so the camera follows along.

Is this at design-time (which is what I was referring to)? This sounds like a run-time thing.

Thanks for responding.

From looking at the Plane-Tank-Bombing startup kit, it looks like you can do it Design time.  Probably able to do it at run time too.  <just guessing>

That video was pretty impressive.. if I understand what your saying then I'm definitely going to check out torque again tonight. One of my least favorite parts of working on a game is building the level editor. The idea of creating behaviors and then being able to link them to objects from within the editor is very appealing to me. It would definitely speed up the one portion of development (level editor creation) that I just get bogged down on, allowing more time to do the fun game mechanics related coding I don't want to lose by using a traditional drag and drop tool.

I'm going to take another look at it tonight. 

Valrith/Stephen, LOL. TorqueX must have changed quite a bit since I tried it (I tried the 1.0.1.1 Open Beta). I created a SpaceShooter Starter Kit, and I found a document titled componentSpecs.ed.cs that contained code like the following:

$CustomOnAddedDelegates = "SpaceShooter.GameEvents.OnEnemyAddedDelegate";

$CustomOnWorldLimitDelegates = "SpaceShooter.GameEvents.OnPlayerWorldLimitDelegate\t" @

"SpaceShooter.GameEvents.OnProjectileWorldLimitDelegate";

$BounceComponent = TorqueX::registerComponent( "BounceComponent", "SpaceShooter" );

$BounceComponent.addField( "PostBounceLifetime", "Float", "2" );

$SpitEnemiesComponent = TorqueX::registerComponent( "SpitEnemiesComponent", "SpaceShooter" );

$SpitEnemiesComponent.addField( "ShipTemplate", "nameRef", "", "T2DSceneObject" );

$SlingshotComponent = TorqueX::registerComponent( "SlingshotComponent", "SpaceShooter" );

$SlingshotComponent.addField( "Timespan", "Float", "2" );

$SlingshotComponent.addField( "Timespan", "Float", "2" );

$SlingshotComponent = TorqueX::registerComponent( "SlingshotComponent", "SpaceShooter" );

$SlingshotComponent.addField( "Timespan", "Float", "2" );

$SlingshotComponent.addField( "Timespan", "Float", "2" );

That's what I was talking about when I said custom scripting. If all that is gone, BOY, I need to go back and try TorqueX. This was the "disconnect" with .NET and .NET Design that I was talking about and that was very frustrating.
To be honest, my problem isn't with the composition model that TorqueX uses. In fact, I LOVE the composition model that TorqueX uses. In fact, when I rolled my own, I essentially used the same composition model where you're attaching re-usable behaviors to objects.

 Of course, I'd imagine the object model has matured too. It wasn't comforting seeing code like the following in the SpaceShooter starter kit:

// hacky. Get our core's SpawnSpeed prop from its AI

T2DSceneObject mountee = _sceneObject.GetRootMountee();

if (mountee != null)

{

EnemyAIComponent coreAI = mountee.Components.FindComponent<EnemyAIComponent>();

if (coreAI != null)

{

EnemyAIComponent ourAI = _sceneObject.Components.FindComponent<EnemyAIComponent>();

if (ourAI != null)

{

ourAI.Speed = coreAI.SpawnSpeed;

}

}

}

 Trying to understand all the walking up and down the scene graph is not exactly intuitive (especially when this is just the Starter Kit example, let alone something more complex). However, at this point, I think I should shut my mouth, download the latest TorqueX, and re-evalute it :).

 Thanks a LOT for wading through my response and correcting me Stephen :).

Machaira:

(further snip)

 In this particular example, you simply mount the camera to the player object. From there, everything is done for you scrolling wise--movement inputs go to the player object, and the camera is mounted to that object, so the camera follows along.

Is this at design-time (which is what I was referring to)? This sounds like a run-time thing.

Thanks for responding.

 

If I understand what you mean correctly, yes, that's for run time camera control.

To move about your large design screen in the editor, you use the mouse wheel to scroll in/out, and can right click and hold to drag the background about. There are also several hotkey options to center specific objects, etc.

These of course mostly apply to level design, not game mechanics development--while the editor has some interaction with setting components and properties, most of your game mechanics work is done in C# within GSE.

bL0wF1sH:

Valrith/Stephen, LOL. TorqueX must have changed quite a bit since I tried it (I tried the 1.0.1.1 Open Beta). I created a SpaceShooter Starter Kit, and I found a document titled componentSpecs.ed.cs that contained code like the following:

(snip really ugly stuff that is gone now!)

That's what I was talking about when I said custom scripting. If all that is gone, BOY, I need to go back and try TorqueX. This was the "disconnect" with .NET and .NET Design that I was talking about and that was very frustrating.
To be honest, my problem isn't with the composition model that TorqueX uses. In fact, I LOVE the composition model that TorqueX uses. In fact, when I rolled my own, I essentially used the same composition model where you're attaching re-usable behaviors to objects.

Yes, it's much easier now, hehe.

 Of course, I'd imagine the object model has matured too. It wasn't comforting seeing code like the following in the SpaceShooter starter kit:

// hacky. Get our core's SpawnSpeed prop from its AI

T2DSceneObject mountee = _sceneObject.GetRootMountee();

(snip further not so fun stuff)

 Trying to understand all the walking up and down the scene graph is not exactly intuitive (especially when this is just the Starter Kit example, let alone something more complex). However, at this point, I think I should shut my mouth, download the latest TorqueX, and re-evalute it :).

 Thanks a LOT for wading through my response and correcting me Stephen :).

 Well, it has gotten better somewhat, but there are still fundamental things that an engine does for you that are "hidden", that therefore require certain techniques.

For example, Torque X implements object pooling, as an aid for making C#'s innate garbage collection less impact-ful (is that a word!) on your game play. Another example is properly managing objects within the game, and many game developers (myself included, I'm not pointing fingers here!) tend to get sloppy when it comes to proper object management. C# alleviates a lot of things, but it's still strong game development best practices to have your objects all managed abstractly and work within that system.

Hence you see a lot of "XXX as T2DSceneObject" to get a method, etc, etc., as well as a lot of this.Components.FindComponent<ComponentName>(); style references...takes some getting used to, but what if your level designer forgot to put in a particular component on an object that the game mechanics code requires?

You can either have the level editor crash on him, and slow down productivity to a stop while he tries to figure out what the hell GSE is saying to him, or you can handle it via the built in object management system and your own code.

Yet another thing that's new in Torque X is our concept of unit tests. Developers can now include built in unit tests for just about any class or component, and query unit tests dynamically during run time to make sure things haven't been incorrectly modified by someone else, or your QA department can easily QA each build that comes out by simply querying all unit tests that are built in to the project and parse the results. We all know how hard it is to balance refactoring code over simply cut/paste since "I might break something if I go back and change what I worked on 2 months ago", and proper use of unit tests helps mitigate this tremendously. NOTE: Unit tests may not be in the current open beta, but will be next release.

SOLD, I'm going to give it another go then.

 Thanks :).

Valrith:

Well, it has gotten better somewhat, but there are still fundamental things that an engine does for you that are "hidden", that therefore require certain techniques.

For example, Torque X implements object pooling, as an aid for making C#'s innate garbage collection less impact-ful (is that a word!) on your game play. Another example is properly managing objects within the game, and many game developers (myself included, I'm not pointing fingers here!) tend to get sloppy when it comes to proper object management. C# alleviates a lot of things, but it's still strong game development best practices to have your objects all managed abstractly and work within that system.

 I totally agree with you here. These are all things that I've implemented in my own engine, but TorqueX would take care of. Especially when writing games that are running as fast as they should be, being VERY aware of garbage collection becomes very important. This is even more important on the 360 where we don't have a generational garbage collector like there is on Windows.

Valrith:

Hence you see a lot of "XXX as T2DSceneObject" to get a method, etc, etc., as well as a lot of this.Components.FindComponent<ComponentName>(); style references...takes some getting used to, but what if your level designer forgot to put in a particular component on an object that the game mechanics code requires?

I'm not too worried about the lookups. The casting and lookups are fine, and there comfortable to use (and I find them intuitive since we are essentially looking up into the components). It's the "walk the tree two levels, and come back down another level" that can get messy. I'd imagine that if this is happening though, it's more to do with the design of our own components than TorqueX as this is a problem that can occur in any scene graph-type system.

By far the most the most helpful thing for me right now would be forums or some kind of resource where I could go to ask Torque X specific questions, and not just XNA questions. Maybe that exists somewhere, but I'm having a difficult time finding it. Some of the questions I've had to answer myself have been serious newbie questions that I know I could find on any Torque X specific forum if I searched and some of the questions I still have are the same. Is there a forum specifically for XNA development using Torque X and I'm just missing it?

L33Td00d001:

Is there a forum specifically for XNA development using Torque X and I'm just missing it?

How about TorqueX forum on GarageGames?  Traffic is a little low though:

http://www.garagegames.com/mg/forums/result.area.php?qa=53

Waruwaru:

L33Td00d001:

Is there a forum specifically for XNA development using Torque X and I'm just missing it?

How about TorqueX forum on GarageGames?  Traffic is a little low though:

http://www.garagegames.com/mg/forums/result.area.php?qa=53

 That's the probable plan, we (MS and GG) just need to get on board and finish up the rest of the process.

Valrith:

Waruwaru:

L33Td00d001:

Is there a forum specifically for XNA development using Torque X and I'm just missing it?

How about TorqueX forum on GarageGames?  Traffic is a little low though:

http://www.garagegames.com/mg/forums/result.area.php?qa=53

 That's the probable plan, we (MS and GG) just need to get on board and finish up the rest of the process.

I was actually just pointing L33Td00d001 to the existing GG's forum.  You are probably thinking of something else that's in the works... ;)

I have not downloaded or installed TorqueX yet, mostly due to having such a good time learning how to use XNA, that at this point feel it has taken me through many of the places that TorqueX would go to make things easier for me.  Not to mention the internal pride element one would be missing out on when directed to the screen and asked "Is that your game?", being able to reply, "Well the idea is mine, and the artwork".

 
I have been considering the use of TorqueX for a fast one-off for the Dream Build Play competition should time permit in addition to my main entry. However judging by some of the overview from others, it seems like it would be a time consuming thing to try to accomplish on a short 4 month leash with another project.  My perception was much like others, that you would drag and drop a game, tie in some code, and deploy. Either way if time permits I will still give TorqueX a good honest go.

 
I guess it comes down to pride over production. All points for the most part I have to agree with that I have read in this thread  but the one thing that seemed to stand out, was that most of us seem to have be involved with XNA since the beta was released through its initial release and likely have code that we are all comfortable with and familiar with  using we wrote to get there. It is hard to want to give up that security for something that may or may not do exactly what you want it to,  or have to re-learn another framework/api to code or make the engine do what you want it to. Even worse when you hear things like "There isn't enough docs, or tutorials."

I look forward to trying TorqueX and will most likely download it and install it to have a look to have a much more informed opinion, however just feel strange to give up code I have written myself in exchange for something that may provide some extended RAD capabilities. Isn't that what a level editor and tool set is intended for? 

 

 

I've looked at torque and even had my physics engine up and running as a TorqueX component.

 I liked the component architectue once I understood it but I was still a bit worried about the flexibilty of the editor.

 So, maybe I'll ask a question about that.

Is it possible to customize the UI of the editor? Here is an example: When you add a torque physics object to the editor, you do so by placing points on the screen and it draws a nice little polygon for you.  However, the torque physics objects only support convex polygons.

I have physics engine that supports concave polygons and would like to have the same type of interface in my editor for creating these physics polygons.  Can the torque editor be modified in such a way that I could click on the screen and have it layout my concave polygon?

 If not, then that is a bit of a show-stopper for me.  I would have to create my own editor that supported this and that would defeat the whole purpose for using TorqueX's editor.

 I know I can create objects with properties and the Torque editor will expose them for me, but what about more complex functionality that isn't already part of the Torque editor?

JeffWeber:

I've looked at torque and even had my physics engine up and running as a TorqueX component.

 I liked the component architectue once I understood it but I was still a bit worried about the flexibilty of the editor.

 So, maybe I'll ask a question about that.

Is it possible to customize the UI of the editor? Here is an example: When you add a torque physics object to the editor, you do so by placing points on the screen and it draws a nice little polygon for you.  However, the torque physics objects only support convex polygons.

I have physics engine that supports concave polygons and would like to have the same type of interface in my editor for creating these physics polygons.  Can the torque editor be modified in such a way that I could click on the screen and have it layout my concave polygon?

 If not, then that is a bit of a show-stopper for me.  I would have to create my own editor that supported this and that would defeat the whole purpose for using TorqueX's editor.

 I know I can create objects with properties and the Torque editor will expose them for me, but what about more complex functionality that isn't already part of the Torque editor?

 I have to check to confirm, butI think that you get the source code for the editor with a Pro license...not even 50% sure on that however, so don't hold me to it.

It is however a c++ application, not a c# one.

I don't think I'd want to mess with the source code. I don't even like looking at my source once it's written.

 It would be nice if there was an option to just lay down arbitrary points in the editor and then have access to them in the code. Not only would this solve my problem, but it could also be used for things like AI nodes.

 Anyway, thanks for the answer.

I think it also has to do with the fact of just the sheer amount of customization and flexibility you have with a custom engine...