TorqueX 3.0

#21 With all due respect, Mr. Stevens, I would put my own record of shipped titles on myriad platforms over the past 25+ years up against yours any day of the week. But this isn't a fight about who has the larger gnads.

I'm offering free advice to GG if they'll choose to listen. Ultimately I won't care because my games will ship even if I have to do everything myself. The only reason I care is because TorqueX has potential and it's very sad to see its fruit die on the vine due to an incompetent lack of focus and priority.


As to some of your specific points...

>> I forgot to check the 'this is what's required to be considered a true game engine' list to ensure that was on it.

Apparently you're unfamiliar with XNA, which can do that with trivial ease. That's why it's unforgivable for Tx not to offer the same functionality. If a library is written on TOP of another one, it shouldn't MASK functionality. That's downright stupid.


>> If you can't get a simple game demo going in TX in 2 weeks, then you didn't
>> get one going in XNA in a couple hours.

Believe what you will. My project doesn't depend upon the ego of a 17-year-old any more than it depends upon TorqueX functionality. And if this is the level of discourse common to the GG "community" then it's even more clear that we should avoid Torque altogether. There are plenty of other options. Thank you for crystalizing that point.


>> TX is on top of XNA and makes things MUCH simpler.

Not in my case. But feel free to come by my office in Las Vegas at any time and I'll go over the requirements with you. We'll gladly pay you $44/hour for your expert advice if it proves useful.


>> I build a complete game, front to back in less than 4 days during GDC 2 years ago

Please send me a download link and I'll be glad to offer you advice for FREE. I'd wager I can point out many ways in which it's not a complete game.


>> TX is feature complete with what was promised.

Nobody promised me anything and I'm not basing my criticism or technology choice on promises. I need to do real things in real products TODAY and TorqueX can't handle the task when straight XNA can. Pretty simple.


>> If something is missing, code it in yourself.

I did. For the demo I had to present to Management yesterday I kludged it to go "underneath" TorqueX and use the XNA calls directly for the rotatable text -- but that's shouldn't have been necessary.

If I'm going to have to write the whole damned library on my own because I can't make heads nor tails of TorqueX then I'm going to save myself a crapload of wasted time and just write my own version of Tx2D from scratch. I've done it dozens of times with less to start with than XNA so I'm sure I can do it again.

As mentioned at the beginning of this, however, that's not the point. The point is GG is missing out on market opportunities because their priorities are scrambled. And like another poster said, they've been promising better docs for T2D/TGB/Tx for over FOUR years now. They will never deliver because it's not a priority for their company. That should be obvious to everyone by now.


>> If certain functionality doesn't exist, that doesn't make the product incomplete.

LoL, that's the very DEFINITION of incomplete!


>> In case you missed it, GG just sold themselves for what must have been an incredible
>> chunk of change. I think they're doing just fine without your business Anthony.

I really couldn't care less who sold what to whom. Maybe we'll get lucky and the new owners will have some focus on real priorities, but other than that you need to be more aware of how the world works.

It never hurts to have more high profile customers in your database, especially when you can show a much broader demographic and applicability for your technology. I can assure you, even the HUGELY "successful" GG people could benefit from it.


>> I'm no GG fanboy either, I simply point out what I see.

Coulda fooled me.


>> XNA didn't even have network support (outside of system.net) until 2.0

That's not part of my requirements list because I'm using a separate, encrypted TCP/IP stack due to regulatory statutes. Remember, my thread is about evaluating using the product for MY project.

I can name thousands of things TorqueX doesn't do, XNA doesn't do, PopCap doesn't do, Flash doesn't do, and on and on. That's why it's necessary to narrow the focus of research to at-hand requirements. It's also why I'm coding the exact same test project in half a dozen different engines.

Fact is, XNA meets more of my requirements than TorqueX. How do you explain that, given Tx is supposed to be "on top of" and therefore "in addition to" and "better than" and "simpler than" XNA?


>> The difference between a game developer and a hobbiest is typically that the hobbiest
>> just takes what's available and pieces them together and hopes for the best

Yep, that's what they do at those GDC contests.


>> where a developer adds what's missing

SMART programmers are intellectually LAZY. If you don't understand what I mean by that, you've got a lot of learning and growing ahead of you. One axiom of this philosophy, however, is avoiding reinvention of "the wheel".

I want to find the library that minimizes the number of wheels I must reinvent, even though I'm perfectly capable of reinventing them all. It's a matter of economics and market timing. But that topic is, of course, outside the knowledge domain of most hobbyists.

ALF

#22 John:

>> I still managed to produce over 50 game prototypes - just by dissecting the code.

That's great, but game prototypes aren't the same thing that I'm building. Ultimately, I'm building a technology PLATFORM on top of XNA/Tx/Dx/OpenGL/whatever. This platform will be deployed into a highly-regulated environment (casinos) that requires VERIFIABLE stability, maintainability, extensibility, and long up times.

In order to accomplish that goal, I can't just cut & paste some code from sample apps and HOPE I'm doing the right thing. I've got to KNOW it's the right way to do things and I've got to know WHY it's the right way to do things because I must develop documentation and workflow tools for my own platform that will be use by hundreds of other artists, designers, programmers, testers, and government regulatory agencies.

Let me repeat that. The PROBLEM with a "look at the sample programs" approach is they don't tell the whole story. I need to know the WHYS of the system as much as the whats. Even worse, there's NO TorqueX sample code ANYWHERE that does ANY of the things I do in my test/demo application. Add "no docs" to that and it's a miracle I got anything running at all, even for this demo.

To add insult to injury, I've received no help whatsoever from GG on my problems. I'm trying to SELL their products within my company so I'm on THEIR side here. The least they could do is help me make them money. My management could avoid using Torque products based on this experience alone. If GG really doesn't care then they've simply bolstered the point.


>> My only point is that there are definitely bugs in Torque X, but it's not "unusable".

I disagree. I have a ton of experience creating 2D graphics engines from scratch as well as many published titles to my credit and I had a helluva time getting TorqueX to do ANYTHING. Sure, once you already know the answers you can get things done -- but the learning curve for TorqueX is ridiculously steep due to the lack of documentation and lack of support. I'd PAY for support if it were an option -- but nobody at GG seems to care.


>> And I've personally seen newcomers build basic games in Torque X 2D within a day.

My guess is whatever they created looked a heck of a lot like the demo apps that ships with the SDK. Just like people who create games with Torque3D seem to create games that look a heck of a lot like Tribes.


>> I think the most honest assessment is that Torque X is a good engine
>> for hobbyists/developers that already have game creation experience.

I'm living proof that's not the case, though I'm probably the only one with balls enough to say so. Too many people have been telling the Emperor his new clothes make him look slimmer.


>> I know that GarageGames has comitment to Torque X and a long roadmap for the engine.

Great! That's one of the requirements for my platform.


>> I suspect that a 2.X release will be coming out before the 3.0 release that
>> incorporates a lot of bug fixes and some minor features.

LoL, but no documentation...


>> Also, when you come across bugs, be sure to log them here in the forums, since that drives the bug-fix list.

I'll tell you what. Outside of my employer, GG can teach me how to use TorqueX from the ground up and I'll create the documentation for free. I can guarantee it will be what people actually need.

ALF

#23 ALF, it definitely sounds like you're building something pretty big; maybe something that's way beyond the scope of Torque X's ability today. I prefer to read your posts as offering constructive advice and take away the following main points: a) lack of documentation is the top frustration b) missing features (such as text manipulation) is a problem c) there are some geniune bugs d) more useful sample code is desired, and e) some formal product support from GarageGames would be nice. Ideally, a Torque X 2.x release would tackle most of these pain points, though probably not the last point.

John K.

#24 Thanks, John. You definitely got the main gist of the feedback. Hopefully it's useful for you guys.

As for our project, it probably is a bit larger in scope than what a lot of Torque(*) users create. But the main thing is it's a vertical game SDK on top of rendering, comm, and other technologies. By vertical I mean the SDK will make it trivial to create certain kinds of games (casinos) by being completely data-driven.

Since we'll be maintaining and extending this platform for potentially decades, it's critical that the engineering team FULLY comprehend every aspect of it. When bugs happen, we need to fix the problem not the symptom. Lifting code from sample apps may get a demo running, but it doesn't lead to comprehensive understanding.

A great example of where TorqueX works for us is the sprite system with physics components. I don't really understand what GG intends as the "correct" way to code up a physics model and that would be an area where documentation would help. But I do understand the sprite & scene system -- perhaps because they require less documentation to understand.

The nuances of what's the "proper" place and time to set component properties and/or extend a component is also unclear, though TorqueX provides several places to do so. Anyhow, the point is this sprite/physics model is one I like but need help understanding. Text and a few other things, on the other hand, are completely obfuscated from my perspective. Hopefully the 2.x version addresses both kinds of issues.

Regards,
ALF

#25 This makes a lot of sense, given your line of business. You're probably often subjected to audits, to make sure the code doesn't have logic, like:

if(user==ALF)
_million_dollar_jackpot = true;

A lot of "serious games" or simulation creators in the government sector are probably faced with the same maintenance requirements. The good news (at least what has really helped me) is that the Torque X source code is very well commented, compared to the other Torque engines. I've also found it to be much faster and easier to march through the managed C# engine code than decrypting pointer reference and virtual functions within large monolithic C++ engines. As far as clear documentation goes, that's clearly a Torque X weakness that needs to be tackled.

John K.

#26 How about this for bugs, why has tx2.0 been out this long and we still cannot export custom delegates to be seen by TXB?