Where's the beef

#81 I think the issue is not about what to expect for $100. The issue is how to maximize the productivity of the people that is developing with Torque and the level of the community in general from prototyping to delivering. The more information you have, and the more structured, accessible, complete and integrated is, the faster you can develop and keep focused on your project. The more focused in your project you are, chances are that you can create more complex and sophisticated ideas and share with the community even more atonishing resources, contributing and helping to expand the capabilities of the engine faster, reducing the gap with the top of the line engines even faster.

All the suggestions placed above are not intended to demand more for what we have paid (everybody understands what they paid for), is to make sure that the community becomes stronger, to minimize the risk for the people of getting lost in details, and to help grow Torque engine in a consistent direction, as robust and complete as it can be.

There is a lot of great talent in the community and most of them have shared their knowledge and experience to it, helping to grow and expand the engine well beyond the original expectations. What all of us are trying to say is that we need to a little more effort, so we can maximize all the benefits given by Garage Games and their products, while minimizing the potential threaths and problems.

#82 I have to highlight Sebastian Potter post..
I think no one is asking or should ask GG to teach them how to program...
I bought a few books on programming, AI and anything else I need to learn.

Maybe Jeff was mixing the request for better documentation/tutorials for Torque Scripting and the Torque way of working with requests about how to code in C++?

Nah... forget about that... just focus on the engine and teach customers how to use it...
How to actually program is not a task GG should spend time teaching.... even if teaching people how to use Torque Scritping may require a few tutorials and examples to get newbie up to scratch.... We always here how you should be able to make a game by just using Torque Scripting without knowledge of C++... well yes in that case GG should teach people how to use Torque Scripting I guess....

#83

Quote:Is it just a waste of time and resources to continue to keep our primary focus on the indy community?

Not cool at all. Go for it, lets see GG drop the indy support, i'll just wait and watch.

#84 I keep seeing a lot of criticism of the documentation in general but I am not seeing anyone mention specific areas where it is lacking. What information do you think is missing? Be very specific...topics that could be written out in a few pages like a resource.

For example, "How the engine works" tells us nothing about what information you need to know how the engine works...what exactly are you looking for when you say "How the engine works"? How is the current documentation about "How the engine works" lacking? Give examples and details.

"Getting Started Tutorials" is another bad example. Tell us exactly what you think should be a part of such tutorials. Be as specific as possible. The more detailed you can make your documentation requests, the easier it is for us to help you.

Couple of other things I wanted to address:
Information - we have to be very careful about what information we reveal and when we reveal it. Bad or misleading information is far worse than no information. For example, if I were to say that Constructor is supposed to ship next week (its not!) and it didn't then we would have a lot of angry and disappointed people who would be a lot more hesitant to believe the next bit of information that we share. Because we are under the scrutiny of such an active community, we have to be more careful than that. We can only share information that we know is as accurate as possible. And, trust me, we aren't sitting on top of a perfect set of deadlines and finished projects holding back on telling you about them out of cruelty! The other thing to consider is that some information isn't ours to share. We are often bound by NDA's with other parties for projects we are involved in and can not legally share information related to it. This is standard operating procedure for the industry (for much of the reasons I jsut listed above).

Trust me...we like to tell you what we are doing! When we don't, it is for good reason.

Quote:
I think no one is asking or should ask GG to teach them how to program...

Rubbish.

A fair amount of the questions and complaints on the forums and IRC are exactly this. A good chunk of the negative feedback we receive on our documentation is not because the documentation is lacking but because the readers of it don't understand. Sure, the questions are rarely so direct as "I don't understand what static_cast<> does" but after a few back and forths with the person it becomes obvious that they are attempting to do something that is well beyond their programming skill level (it took me less than an hour to remove the hardcoded limit on dts collision meshes...something which the community had been complaining about and attempting to do for four years).

This trend is worse among the artists than the coders though. An experienced 3ds max artist can walk through the docs that Joe wrote and will have little to no issues and look upon the complainers about Torque having a "hard art pipeline" like they were insane. They might not like some parts of the art pipeline (like the lack of multiple uvs or convex collision meshes) but they will have no issue using it within those constraints. Now, throw someone who doesn't know Max very well into the same doc where they read "create a dummy object" when they don't know what a dummy object is or how to create one and suddenly we have a "hard art pipeline". In my experience the average hobbyist programmer is better equipped to deal with Torque than the average hobbyist artist.

Now, that is not to say that we can't continue to improve our docs (teaching them to program or use max or milkshape or constructor or whatever) and we are doing just that. It takes time though. Writing good and thorough documentation requires knowledge, skill, time, and a knack for communication and for the most part those of us who meet all of those requirements are incredibly busy with improving Torque or related products in other areas than documentation. And there aren't all that many of us!

#85 Very well put Matthew!

The obvious problems are teams and inexperience. We would all love to make our own games but not someone elses. I dont even think easier tools will help this matter. It may make some teams quicker to build their games they will complete anyway, however it wont help the lot of us who are too stupid to work together to make a game. I have been a hobbyist not an indie, hopefully in a couple months I can change my hours at work and become an indie the smart way, join a team who has true goals, learn from people around me and accomplish small tasks just as I know I should.

#86 Pictures are worth a thousand words.....here is a list of the following pages in the "General Torque Documentation" that is missing a picture or pictures:

http://www.garagegames.com/docs/tge/general/ch04s06.php
http://www.garagegames.com/docs/tge/general/ch04s08.php
http://www.garagegames.com/docs/tge/general/ch07s03.php
http://www.garagegames.com/docs/tge/general/ch07s04.php
http://www.garagegames.com/docs/tge/general/ch07s05.php
http://www.garagegames.com/docs/tge/general/ch07s06.php
http://www.garagegames.com/docs/tge/general/ch07s07.php
http://www.garagegames.com/docs/tge/general/ch07s08.php
http://www.garagegames.com/docs/tge/general/ch08s03.php
http://www.garagegames.com/docs/tge/general/ch08s05.php
http://www.garagegames.com/docs/tge/general/ch08s06.php
http://www.garagegames.com/docs/tge/general/ch09s02.php
http://www.garagegames.com/docs/tge/general/ch09s05.php

I also created 6 threads the other day to find out some info about community members.
The thread As a beginner, what is your biggest hurdle so far? has only 14 responses so far. One person said it right.... Motivation / Direction. I think back and this was me. I did not have any direction as a beginner on what to do. Then the book "3D Game Progamming All In One" and "Essential Guide to Torque Lite" was released, gave me the info to start making a game with TGE. Without direction is lack of motivation.

My other thread How many team members? has 19 posts so far. Mostly small teams. I read how it took companies 2-3 years with 50 - 100 people to complete a game. Some good , some not. So my question is everyone trying to take their time and make a quality game? Or lots of beginners out there that don't know where to start? Or is it a combination of things (experience, direction, motivation, and team size)?

Well our team (2 people) has been working on our game for three months now. We are moving foward slowly. Our biggest problem has been with the interiors (Light leaks). We are basically making a rough draft of a game and then refine it later. How long this will take? I don't know... never made a 3D game before. We are in a learning process. How many others in GG community are doing the same? I don't think people are asking GG to teach them how to program. But they are trying to learn an engine, tools, programming and all the stuff related to making a game at one time. This is a big learning curve. This could be why not many games have been made.

Another factor is time. Look at the thread How many hours do you spend working on your project? People work day jobs as well as spending time with the family. This slows down the time span of making a game. These are not excuses but reality. Tell the wife you are to busy making a game...then see what happens.

We are basically taking a break from making our game until the first of August. So in that time I will scan and report missing links/pictures in the documents. Go through the tutorials and see what works. Maybe some other people will help as well.

Overall, I am making a game. By no means am I going to quit on it. It is just going to take a while. I hope GG will not quit making or improving engines/tools for Indies!

#87 I don't usually comment on my own .plans, however I never, at any point, said we were even considering dropping support, and Jeff made it clear that we were not considering that either.

Do not read in what isn't there. There is no desire, from anyone at GarageGames, to abandon indies, or abandon indie development ourselves.

#88

Quote:As I see it, the sooner TSE is ready, the sooner a lot of us can start serious work on our projects.

Another reason there is NO BEEF! People are waiting around for TSE instead of hacking the awesome, stable, fast TGE 1.3 today :-)

I'm pretty sure I've seen GG staff post in the forums to the effect that we really need to start building our games with TGE and if desired upgrade to TSE when it's released, not wait for TSE to be released. It makes a lot of sense because if your game sucks, really, having realtime shaders is not going to to save your game. Besides, you have to own a TGE license to be a TSE early adopter.

TGE is not outdated and is not being abandoned. It stands to reap a lot of enhancements and bug fixes from the active TSE development going on. For example updates to the rendering pipeline and the terrain engine (presumably) might find their way back into TGE. Maybe some good stuff from TSE has already been checked back into TGE 1.4 release which should be "Real Soon Now"

#89 I wanted to leave a quick positive comment saying that I for one am very happy with the quality of engine that GG has put at there for the price range. I've left a couple of comments as to why I personally (since that was one of the original topics) was unable to get anything out the door, and areas that could be improved. All in all though Torque is still the best available solution for an independent developer in my opinion, but that's not to say that it doesn't have room for improvement.

#90 I worked on a failed Indie Project once and can say that for us the main reason we couldnt finish it was that we didnt have enough artists on one hand and we didnt have much spare time for it on the other hand. We literally took 2 years of work to get a halfway playable prototype done. Actually we got several prototypes done because even our prototypes changed during the course of two years. Another problem was that noone actually knew what he was doing before he started to do it. I mean most of us where "school grade kids" trying to make the best MMORPG ever. As for the Artists problem: We didnt have any real artists but rather had people who are still learning their tools.

The project finally died when the team leader said that he would leave the project.
www.freelists.org/list/pythian (the last entries in 2004 are actually the official dead of the project)

There is no beef because most people decide that they prefer being a vegetarian

What i was trying to say with this was: i agree in that that a 3D Game is very demanding. T2D can produce faster results and therefore people arent squashed by lots of dull work and loose interest. Torque is a very good Engine and helps alot in that it makes programming 3D Games easier. I know of many projects that start with: I want to write a 3D engine for my game and all will be good. I hear it everytime but i hardly hear a "i'm done with the game, go buy it".
Torque is an awesome help in creating games but nobody can expect that it is the "Eierlegende Wollmilchsau" (Egglaying wool-milk-pig) that will produce games with a fingersnap. People tend to think that it is and buy a license. But as soon as they realize that they cant get a game done in a fingersnap they start abandoning it.

There will be people that will overcome all obstacles and produce a good game. Just be patient on it.

#91 @Matthew Fairfax, re documentation:

I would love to see a lot more code-level documentation throughout. The vast majority of the dOxygen web pages lists the member functions for each class, but with no explanation of what the functions do, what the arguments mean, or how to use them properly.

For a more specific example, how can I mount objects in code? When I call this->mountObject(dingus, slot), what happens? Am I mounting "dingus" on "this"? Or am I mounting "this" on "dingus"? What is the difference between mountImage() and mountObject()? When would I want to use each one?

Or how about PlaneF? It has a constructor that takes two points. I thought a plane was defined by three points! Ideally, the arguments would be named something like, "a_point_on_the_plane" and "normal_vector" rather than "p" and "n". Sure, I figured it out, but I shouldn't have to. And what does that intersect function really do? http://www.garagegames.com/mg/forums/result.thread.php?qt=1671

A codebase for a single project with a stable team doesn't *need* this kind of documentation (nice though it would be). But GG is trying to support a codebase for thousands of programmers with very unstable teams. I *am* my team. So I find myself touching the Torque codebase everywhere, usually in minor ways. I usually have to read the internals of a function to figure out what it does. Sometimes, I can grep the code for ways in which people have used it, and that can help a lot- if they commented their code.

You say that it was very easy for you to remove the hardcoded limit on dts collision meshes.... I expect that you had a leg up on most of us. Code style familiarity, which files deal with collision meshes, the basics of how collision meshes work, or even the fact that collision meshes exist. Do a search on the words "dts collision mesh" on the site. If there is strong documentation on dts collision meshes, I expect it to show up on early in the results. Indeed, page one has two links to the docs on specifying and exporting collision meshes at asset creation time. However, after unhiding similar search results and paging through page 8, there is nothing on the code internals. Lots of GREAT forum entries, though. Most of my Torque experience has taught me to go to the forums before the docs.

In my utopian dreams, every function has long, descriptive argument names and several lines of comments above the declaration. Then MSVC/VAssist would show me the documentation every time I rest my cursor over a call to a function.... Heaven!

Often, people in the forums ask, "How can I do X?" Your answer is frequently "Go in the there and change the code." That answer is exactly as it should be; no codebase will solve everyone's problems. But I would prefer to see effort going into making it easier for me to make my custom changes and build on what Torque already has than into adding new whizzy features.

Then again, documentation is not sexy. It's not fun. It's hard work. Whizzy features are sexy and fun... and hard work. :-)

I am not complaining about value for my money, not at all. Torque is a great deal! But it would be more valuable still if I could see solid, function-level documentation. One more reason that T2D is easier than TGE might be that there is less to understand, and thus less to learn and document. :-)

#92 Well, could there be kind of Wikipedia of functions..and..umm..all the other stuff Andrew mentioned (I`m a fancy pants artist, I`m supposed to sound dumb :)? I mean - its obvious that some people find out what this or that means, but they cant share knowledge other than answering forum posts, provided they have time at the moment and have seen the question in the first place. If there was kinda centralised and searchable "community notes" section where people could make new entries, elaborate on others notes forum-style, it could probably solve lots of problems?

#93 Nauris,
TDN (torque devopler network) is being worked on and is going to be wiki based.

#94 Well, there you go then :)

#95 Any news about the new Fennech book on Torque?
I hope I'm spelling the name correctly

#96 Jeez.. My lengthy answer was just dumped the moment I clicked "Notify when new comments are posted" prior to pressing Post Comment.

here is the rehash...

Andrew Grant is right on the money when he outlines the shortcomings of Doxygen. In my opinion, the style of documentation they enable is hardly worth having, though I don't know if it is beyond their capacity of simply the format they encourage. And the issue is one of focusing on documenting functions and parameters at the expense of documentation at the class and subsystem level. And, indeed, the most helpful documentation is at a very high level - overviews, discussion of the threading model, clear descriptions of object ownership models.

Some examples: there is a platformI*.h set of files offering cross-platform Thread, Semaphore, Mutex, etc. but nowhere is there a description of when you might choose to use them for an external thread, or when you need to refrain from thinking along those lines. One can read the source code, but there is no explicit description that Thread is really meant to be subclassed, and the run() method can then contain the code and the class can have any context data required. Someone did a fairly good job there, yet the constructor blinds the neophyte to this design and tempts him into supplying a C-style callback with a single integer parameter. Such a nice design will thus be negated for a fair number of those trying to work past a lack of explanatory text.

A vital adjunct step in producing new documentation is to destroy and remove (or relegate to a separate archive) the old documentation, as well as the resources. It should be possible to read through the documentation easily without being distracted by resources written by the same eager but unproductive licensees who inspired this post (and I do count myself amongst them). The resouces have value, but they are NOT documentation.

#97 @ Hokuto: do you mean Kenneth Finney's new book: Advanced 3D Programming All In One? You can pre order it now at Amazon, Barnes & Noble, BAMM or Wal-mart. August release date.

#98 Mark - Yes.
Thanks

#99 I'll through in my 2 cents.

People buy the engine and immediately try to bite off more than they can chew.

The promises Torque makes are simple and clear, and they warn repeatedly, start small, scale up. You can't just jump in and make the game you've always wanted to make.

Regardless, there are a lot of 1/2 man teams attempting just that, throwing every ounce they get into a huge wall of requirements, (well you hope they are requirements, or even bothered with a real design doc). We can bitch about documentation, un-ideal support in some areas, but ultimately I'm 99% sure peoples projects simply dont take off because they can't scale down.

I think thats one major hurdle. I think another big one is that frankly what Torque promises, only a bigger team can immediately capitalize on. You relaly need a full fledged game dev team- a team of audio engineers who understand sound, a composer, a 3d artist/texture maker, a game designer, programmers, scripters, qa, biz dev, marketing. All these needs dont just evaporate when a coder buys a license.

I think Torque is ideal for its price and proven track record; my friend and I have a well defined design doc, and are fleshing out the details, and we've been doing this for weeks now; simply figuring out all the needs is one of the hardest challenges of the dev cycle. Its funny because our game is almost as simple as soccer... (no telling, i want to keep it a surprise)

Regardless of what the current project is, I had to talk myself down from my massive air/land/water battle mecha super war sim/action thrill/dynamic mult-live video audio feed mega action/strategy game, and I think people who get the license aren't able to make that first, hard, but terminally crucial step.

start small, start simple, and the rest will fall into place.

As for people complaining about the source, well you're just a girly man if you think that source code is poorly documentated and unreadble in any fashion whatsoever. Maybe you should go take a job refactoring software products built during the dotcom boom...

There's another thought- we're all anti-social nerds incapable of forming and sustaining successful teams, and games are very much a team-developed entity... hmm.

#100 You have very few games in 3D and lots in 2D, reason is pretty simple, art!
A good 2D artist is alot easier to come by than a good 3D artist.

Another good strong possibility is the severe lack of tools in the art department. I mean we have to pay extra for ShowTool, which should honestly be offered as a bundled app, even if you boosted the license fees to compensate, same thing goes for the as yet unseen Constructor. In fact I would say Constructor is my biggest hold up in getting a game out the door. I have almost no interiors with which my game can be built around, and working exclusively in Linux, there are precisely 0 interior making tools, that I can legally use, the free resources are Ok, but those are almost all limited to "free for non-commercial use", and while I would LOVE to buy Tim Aste's content packs, ATM purchasing them is not within the budget I have set aside for this project (it might be if I could get a price on Constructor, but until then I have put a freeze on acquisitions).

I really hope that you guys will bundle TST, Constructor and maybe a content pack or two into sub $100 TFA(Torque For Artists) package.

My final reason for a severe lack of games would be the fact that in all honesty there doesn't appear to be a way to sell the games you do make... I know you can find the info if you search hard enough, but come on, GG's secondary purpose is to sell games, and as such a "How to get us to sell your game" page should be in the main menu bar, and also linked to from the main page.