Obviously I'm biased, but I've noticed a massive majority of posters here commenting, or implying, that they are rolling their own engine(s) for their games.

 With Torque X not directly supporting 3D quite yet I can of course see the reasons why people might not be exploring it, but with that reason aside, is there a specific issue with the engine itself that is having people roll their own, or is it lack of knowledge regarding what it's about?

The main reason I ask is that if it's lack of knowledge of the engine (Torque X) itself, I'd be more than happy to answer and explain whatever I can--I just need to know what needs to be known, so to speak!

Alot of people will want to have the option of 3D, theres plenty of nice 3D samples out there, and its not really that hard to compliish 3D. Other than its probably a case of being too limited. I.E. not having source/easy way to do any custom thing they want in terms of rendering at least.

If someone was making a simple 2D game, it would not make sense to roll your own. Microsoft are saying "Save yourself some time while the others slog away at an engine", so why not take advantage of it. :)

I don't know about others, but if it will help, here's a few reasons why I haven't messed around with Torque X

• Not sure what it is capable of.  I've only seen the tankbuster game and that didn't blow me away (no offense).  Maybe if I knew more about what it can do to make programming my game easier, I would consider it
• There's a learning curve involved, and I could use that time digging into XNA or making my game
• Lack of 3D

~Rockstar

I've worked on few games where a publisher required the team on was on to use this engine or that engine. Development always went better when the team wrote everything from the ground up themselves. It's been my experience that it doesn't really save any time or effort to start with an engine. One of the major problems is that most often an engine is designed around a game type. No matter how tenuous this basis is, if you are trying to make a game that doesn't fit this type you end up rewriting significant pieces of the engine to make it do what you need it to do.

Anyway, XNA is pretty easy, the games I want to make are small, and I want to learn. If I wanted to make what is basicly a mod, I'd forget about XNA and move onto Half-Life or whatever the hot game is at the moment. 

I'm currently rolling my own 2d shooter engine from scratch, but that's more for learning than due to something missing in TorqueX. I've never programmed a game before, and I feel that by doing it from the bottom up, I'll get better insight into how it's all structured and tied together than if I used a finished engine that came prebuilt with most of the necessary functionality.

I've poked around with the TorqueX beta a bit though, in general it seems very nice, I just have two objections about it. The first being the unfinished documentation, there might be more online, but I admit I didn't look very hard. Just read the included stuff.

The other one (though to expect as it is a complete engine) is that it uses a quite different component architecture than the XNA Game and GameComponent classes. Since that both requires me to learn a new architecture and as an effect renders all the game components and tutorials on the various XNA sites unusable, it makes me a bit reluctant to start using it.

I might very well end up using TorqueX  for my DBP entry though. I'll have a look at it again after I finish my current project. :-)

Points well taken on documentation--in fact, I'm currently writing a textbook on Torque X itself, and I know what it's like to have to search for information.

Realize that the source code is available for purchase ($100 iirc), although doesn't come as part of the Creators Club offering.

I think that the most important thing right now for me to offer to all of you is a quick and dirty of what it's capable of...I'm almost 100% certain that the concerns about "made for game type X" will go away once people understand the nature of our aggregation object construction, and the use of components (yes, they are completely different than XNA components, but are designed for use in very different ways).

As an FYI, the 3D stuff actually -is- there (admittedly in very rough form), it's just not exposed currently. Marble Blast Ultra was actually ported to Torque X in under 3 weeks, and has a full polysoup collision interface, as well as quite a few other 3D oriented functionality.

The team is currently finishing up the 2D World Layer, while actively developing the 3D World Layer, and once it's available to the public I'll certainly let folks know.

I downloaded the TorqueX beta as soon as it was made available.  I played with it a little bit but decided my time was better spent understanding XNA first.  I figured that knowing what the underlying framework is capable of, and what it's limitations are, would help me to evaluate the usefulness of any tools.  And, of course, at the time I had no idea it would be made available to me as part of the Creator's Club membership.

I'm currently trying to decide whether to go with TorqueX for my DBP entry.  I have a working, although simplistic, prototype of my game running on my own (rather basic) engine.  Whether I go with TorqueX will be based on how quickly I think I can reimplement what I have so far, and how much more it will allow me to do without requiring too much of a learning curve.

If you guys could provide some samples and tutorials similar to what Shawn and the rest of the Microsoft team here have provided -- short, to-the-point, samples showing exactly how TorqueX can simplify a seemingly complex problem -- that would be a big help.

I've done some looking through the Starter Kits you provided (the Geometry Wars-like shooter is *very* cool and I'm impressed with how easy it is to do with Torque), but I'm thinking of shorter, more directed samples.  Something that makes us look at it and say, "wow, now that I see how easy it is to do that with Torque, I definitely need to learn more."

Tom

Stephen,

I'm not sure that the kind of response you are seeing here is indicative of the general audience for XNA. Most of the people who are currently on this forum are people who have been with XNA since the betas and have coded a lot with XNA with no third party libraries. Many have developed their own tutorials and are actively involved in answering user questions on the forums, etc. So by nature a lot of people here are in the roll-your-own phase. Especially if they see that 3D is not fully supported at this point, they know that they can get 3D working with XNA without other libraries.

A similar thing happened with XNA before Beta 2, where the Content Pipeline was not yet available. Many people, including myself, said "let's just do 2D for now until the content pipeline is in place". Well now you're getting an attitude of "I'll check out TorqueX once they have full support for 3D" and I think a lot will change one that's in place.

I agree though that a series of samples on TorqueX from the ground up would get more people to check it out and hopefully convince them. If these samples already exist, it's not obvious enough as to where they can be located. 

Lack of documentation is number one for me. What documentation there is seems to assume a long-time familiarity with the Torque products. There isn't anything that tells you where to go in the code to make a change. There are code files everywhere and it's really hard to figure out what goes where. There are a ton of classes/objects and, without complete documentation, they are all pretty much useless since you have no idea what they do, what properties they have, etc.

The funny thing is that I'm a TGE early adopter and had the same problem with TGE. What little documentation there was, and virtually all of the tutorials available, seemed to make the assumption that the user has spent years working with Torque. In many cases, the user is referred to the book written for the Torque engine. Of course, none of the TGE stuff is in there, so it's hard to relate the code in the book to TGE. To this day, there isn't really any better documentation than what was available in the beginning. (Although what's available now is prettier than the old stuff.)

The bottom line is - drag and drop interfaces are nice, but at some point you have to write some code. Right now, there is very little information on what to do at that point. The tutorials say "Open this .cs file and put this here. Open that .cs file and put this there." That's not helpful if you don't know why something goes in a particular file.

The Torque X framework isn't well documented in terms of either structure or api. That has to be fixed before anyone can make effective use of it. Also, it needs to be documented for everyone, not just Torque users. NO ASSUMPTIONS other than that the reader knows C#.

For me, there's a sense of "Look, I wrote all of this code myself!" when I share my games with my friends. If I use torque, then I can't really say I did it all by myself, because so much functionality is already built in. However, i'm sure I will eventually come out of this phase, because realistically, every game will almost always contain somebody else's code.

However, since I'm not creating games to make money or anything, I'm not under a time constraint. I want to learn my way around game programming bit by bit, doing most of it myself to learn the most things. All the "aha!" moments make programming fun for me. In addition, I was browsing through a local bookstore and came across a book that uses the torque engine. Flipping through it, I noticed that it inolved scripting quite a bit, and not that much programming. It doesn't use TorqueX or Torque GameBuilder, but I don't want to script games, I want to code them.

In addition, torque has always remained in my mind as a beginner's 2d drag-and-drop program. Ever since I saw the tank buster game, which I saw invovled dragging and dropping, I was a bit turned off. I know it's much more, as torque employees keep reminding us, but nothing has given me an impression otherwise.

I know I sound a bit elitist; sorry about that, but there's just this stigma about torque for me that won't go away. I don't know how many other people think this way, but I know i'm not alone here. The main big thing that would change my mind would be 3D functionality. A couple of more videos wouldn't hurt either.

ProfEclipse:

Lack of documentation is number one for me. What documentation there is seems to assume a long-time familiarity with the Torque products. There isn't anything that tells you where to go in the code to make a change. There are code files everywhere and it's really hard to figure out what goes where. There are a ton of classes/objects and, without complete documentation, they are all pretty much useless since you have no idea what they do, what properties they have, etc.

The funny thing is that I'm a TGE early adopter and had the same problem with TGE. What little documentation there was, and virtually all of the tutorials available, seemed to make the assumption that the user has spent years working with Torque. In many cases, the user is referred to the book written for the Torque engine. Of course, none of the TGE stuff is in there, so it's hard to relate the code in the book to TGE. To this day, there isn't really any better documentation than what was available in the beginning. (Although what's available now is prettier than the old stuff.)

The bottom line is - drag and drop interfaces are nice, but at some point you have to write some code. Right now, there is very little information on what to do at that point. The tutorials say "Open this .cs file and put this here. Open that .cs file and put this there." That's not helpful if you don't know why something goes in a particular file.

The Torque X framework isn't well documented in terms of either structure or api. That has to be fixed before anyone can make effective use of it. Also, it needs to be documented for everyone, not just Torque users. NO ASSUMPTIONS other than that the reader knows C#.

 

QFT! 

All good points, and well taken :)

 Couple of points though:

--videos of what? gameplay, or use of the tool? Folks have said that drag 'n drop is part of what turns them off, yet videos of the tool don't make sense if you're hacking code

--folks also focus on the drag 'n drop, but the main strength of when it comes out is production, not development. Level creation when you are doing 50 levels for a platformer, or something like a breakout game is much more productive when you can give your level designers (or yourself) a drag and drop interface off the bat. Torque X and TGB-X are even more amazing with that, since any public variable pretty much automatically has an editor auto-generated for it.

--Torque X documentation is certainly behind...but it's due to active development as opposed to being ignored. An additional benefit of XNA is that you can simply dump everything to XML via serialization (I've been told, not that much of an XNA or .NET expert yet). I do certainly agree that present state isn't nearly enough for what is needed, but I don't personally think it's that far behind...today was the very first time I've used Torque X (and it's nothing like any of our other engines, for what it's worth), written anything in C#, or used GSE, and in a little over 8 hours I have all of the behaviours prototyped for a complete game...need to refactor some components for general use, and then pop out some additional level building widgets and it will be complete.

 Again, thanks for all the thoughts and perspectives--being that Torque X is part of Creators Club, we want to make it as useful as possible for everyone involved, and the information here helps greatly!

I downloaded the beta last night, installed it, managed to play with it a little.  Here are some thoughts:

• the lack of doc/tutorial makes XNA look easier
• the switching between GSE and TX editor bit gets old. But I understant there isn't much you can do until Game Studio use VS2005 Std/Pro integration
• was bitten by the save level doesn't seem to push changes to GSE issue.
• tried to access tdn to find more doc/tutorial, but get "Sorry, you must own a GG developer product (TGE, TSE, T2D, RTS-SK, Lighting pack, or Constructor) or be a GG Associate in order to qualify for the TDN beta."
• lack of 3D examples

I felt more positive about it after I ran all of the starter kits.  But the lack of doc/tutorial makes it hard to tell which part of the sample is TorqueX, which part is extra.

I've been massively testing the upcoming tutorials and documentation for the next open beta, and it should help quite a bit.

--"save level doesn't seem to push changes to GSE" issue: could you expand on that? There isn't anything in a level that goes to GSE--after building GSE and starting debug, it then executes the code that loads in the level created from the editor, but the only push is from a post-build to TGB-X (which allows you to on the fly reconfigure your editors).

--ironically, TDN isn't where the first couple of iterations of documentation will be coming from--it's an interactive (local) web page that will be part of the download.

--yes, 3D isn't yet fully implemented--what is implemented is several layers of abstraction for managing objects, game processing loops, memory management (including object pools), test harnesses, editor integration, aggregation based object composition, and quite a bit more. I'm going to do a short doco to describe the features more in depth so that folks can make informed decisions based on their goals: for pure game making, here's what the engine does for you, etc.

I'm looking forward to checking out torque as soon as the 3D portion is complete. Until then I'm using XNA in the raw in order to understand it at the lower level so that when the time comes I'll feel like I can properly evaluate Torque X and the other engines that are popping up.

I believe that most of the people here are the early adopters of XNA and are interested in it more as a technology than having a specific game they want to produce seriously right off the bat. Since there is no distribution channel for xna games yet and no financial incentive other than the DBP prizes people are in it more for the learning and experimenting at this time.. seeing what XNA and their 360's are capable of. The best way to do that and really understand what's going on is to 'roll your own.' I think that once people become more comfortable with XNA and begin serious work then they will start looking for ways to speed up production and standardize on tools and engines like Torque X.

That's just my opinion, and I could be way of base on my assumptions, but it's where I am right now and I think there are others of the same mindset.

As for the engine itself - Full 3D and some sample projects showing off the benefits over plain XNA are what it'll take for me to really pay attention and give it a good hard look.

Personally, I'm using TorqueX for my project. I come from a reasonably strong programming background with some openGL. I don't want to build it from scratch, which is why I was attracted to XNA in the first place.I ran through most of the XNA tutorials I could find and then started looking for engines. Torque X jumped out at me and after mulling around with the included projects, I've decided to use it for my project. Since I've got a 10-week deadline, it's a clearly better choice than rolling my own solution and I have a feeling that in trying to implement some of the wierd concepts I want to try out, I'll get my hands dirty on plenty of XNA stuff along with the TorqueX stuff.

 If I had no deadline and was more interested in exploring XNA than interested in completing a project, I can see where I might skip TorqueX entirely.
 

Valrith:

--"save level doesn't seem to push changes to GSE" issue: could you expand on that? There isn't anything in a level that goes to GSE--after building GSE and starting debug, it then executes the code that loads in the level created from the editor, but the only push is from a post-build to TGB-X (which allows you to on the fly reconfigure your editors).

It's good to hear that more doc/tutorials are coming.  Looking forward to them

I was following the TGBX documentation tutorial for hooking up movement to the sprite, did savel level in TGBX, pressed F5 in GSE a few times and couldn't get the sprite to move.  It eventually started working, I am still not sure what happened.

Thanks for the reply.

I own pretty much every version of Torque (with source). So far I can say I wish I had not spent the money. It's definitely not for beginners. While I'm no beginner, I'm not one for spending months pouring over code to work out what should have been explained in an API doc.

Torque X is just as bad, except at this time we don't have the source code, and the starter kits serve to make things more confusing I'm afraid.

XNA is far from complete, but what is there, and what docs it come with, combined with other resources all over the internet (which don't exist for Torque), makes XNA 100 times more usable than Torque.

picoligance:

For me, there's a sense of "Look, I wrote all of this code myself!" when I share my games with my friends. If I use torque, then I can't really say I did it all by myself, because so much functionality is already built in. However, i'm sure I will eventually come out of this phase, because realistically, every game will almost always contain somebody else's code.

However, since I'm not creating games to make money or anything, I'm not under a time constraint. I want to learn my way around game programming bit by bit, doing most of it myself to learn the most things. All the "aha!" moments make programming fun for me. In addition, I was browsing through a local bookstore and came across a book that uses the torque engine. Flipping through it, I noticed that it inolved scripting quite a bit, and not that much programming. It doesn't use TorqueX or Torque GameBuilder, but I don't want to script games, I want to code them.

In addition, torque has always remained in my mind as a beginner's 2d drag-and-drop program. Ever since I saw the tank buster game, which I saw invovled dragging and dropping, I was a bit turned off. I know it's much more, as torque employees keep reminding us, but nothing has given me an impression otherwise.

Three words - Marble Blast Ultra. J

It's been hard to see the benefits of TorqueX without the 3D portion, but I think the engine has a lot of potential for us XNA indies. 

picoligance:

I know I sound a bit elitist; sorry about that, but there's just this stigma about torque for me that won't go away. I don't know how many other people think this way, but I know i'm not alone here. The main big thing that would change my mind would be 3D functionality. A couple of more videos wouldn't hurt either.

The 3D portion is what I'm really waiting for.

For me, it's a question of 'return on learning investment'. As someone who was new to game programming until XNA (but with a decent coding background), it's really a question of what will benefit me more in the long term, when my goal is not to push a product out the door in 'x' months, but to learn.

Using an engine like Torque, at the stage of learning I am at, makes no sense - the learning curve involved isn't significantly different from raw XNA (and in fact, learning Torque would add additional complexity when you're a beginner). What attracts me to XNA is that it makes the boring things simple, and provides me with easy ways to store, manipulate and use all the raw data I want - user input, textures, models, etc. That's the beauty of it - I can get to the interesting parts right away. The things that Torque offers to do for me are fundamentally the things I want to learn to do for myself. That doesn't mean Torque isn't an excellent product or worthwhile - it means I'm not your target market.

I have to say, I think XNA is both a curse and a boon to a product like Torque. XNA may draw more people in to game development that would otherwise stay clear, but I suspect a fair number of those will find that XNA handles enough of the boilerplate that they no longer have any want/need for a pre-developed engine. Effectively, XNA lowers the barrier to entry for coding your own engine. Just my thoughts.

I have 3 main reasons for rolling my own.

1. its more fun, less limiting, more benefitial to my future career as a gamemaker (especialy being im new to game programming),and makes me feel prouder to make my own

 2.i dont like oop and my engine is just a set of functions and structs (i use an oop sdk like xna because xbox360 is pretty tempting ;P )

 3.  Between a doitall engine and my own rendering/animation/physics functions specificaly designed to do only what i need them to do, my own will be faster and more efficient.   Ive seen some benchmarks (cant find the link) where a guy did the same demo in directx, opengl,managed directx, irrlicht and torque. and irrlicht and torque got their asses kicked as far as performance.  He must have been a pretty efficient coder as well, because he got managed directx nearly as fast as normal directx.

but the biggest reason is, much more fun to make myown 

There are three main reasons I'm not using TorqueX:

 1 - I simply want to build my own :). I'm a kind of guy that like to learn the internals of how something works. By using XNA directly and building my own on top of it, I can get to know what XNA can do, rather than what TorqueX can do. Plus, I tend to be a framework kind of guy. I perhaps enjoy building the framework more than the game itself.

2 - Lack of documentation. When I downloaded the Beta, the lack of documentation was a problem. TorqueX already has a high enough learning curve. The lack of good documentation just makes this worse (and no, the starter kits code is _not_ self documenting for people new to TorqueX).

3 - This is perhaps the one I'm most passionate about. There is a disconnect between .NET and TorqueX. If I'm working with XNA, I'm living in C# code all the time (assuming I'm not doing shader development). However, with TorqueX, because of the way it integrates with the editor, I not only have to learn the TorqueX framework from .NET, but I also have to learn the custom scripting language in order to know how to develop my own behaviors and plug them in to my game objects.

 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.

 If you want to develop your own framework built for .Net that other developers will be using, I think anyone in this position should read the book .NET Framework Design Guidelines. To me, it just felt like TorqueX was designed by native developers that were just getting up to speed with managed code. This not only makes the learning curve problem worse, but it leads to (or has led to) a framework that is, shall we say, less than intuitive.

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.

I think if you are new to TorqueX (and have never used Torque before), than you can actually roll your own faster in some ways (of course, depending on the timeline and the type of game because this statement could easily be false :P). However, the disconnect above for me is a breaking point. In the long run, code that is in .Net and uses the same paradigms we all know and love is a lot easier to maintain. It's too easy to mis-type something in a custom script along with a bunch of other changes, and then have to spend a lot of time trying to find out why something isn't working (when it was really that you just mis-typed one letter).

That's just my gut reaction after working with TorqueX in beta. Please keep in mind that all this was based on my Beta experience, so if it has radically changed, my apologies.