Tell me this book gives more documentation.

#1 Hi Josh,
I was just running through the posts to see whats new lately. I can tell you that I can relate to your frustration. When I first started programming, I thought that all I had to do was memorise some commands and then assemble them into something a computer could run.. Foolish I know..but thats what I really thought.
Then I got into a school for programming. My first test was on paper before being accepted as a student, I had to pass a logic exam that was roughly 30 minutes long.
The test was basically some shapes and number sequences and to pass the test, I had to fill in the blanks with the shape or number that went next into the sequence.
The need for the test didn't make sense to me at first.. although i passed the test, it was really about my ability to notice patterns. The school didn't want students that couln't pass a simple test so that the financial end ( for them ) would continue uninterrupted.
When school started, I was immediately thrown into a room with several other adults at night, after work, to begin our lessons in learning C.
My first thoughts was something like "How in the world am I going to memorise an entire library of functions?"

To my surprise, I didn't need to memorise a library of functions. My teacher told the class that writing programs is simple when you know the basics.
Generally.. you start with a concept of what you want.
Then describe the logic flow in plain english on paper.
Further break that logic into pseudo-code like a flow chart.
Then your ready to begin writing your program.

Writing a program is easy when you know where to get your answers. as example.. If the program will require user input, then I will need functions that are found in the stdio.h header file.
perusing the header files is illuminating and educational at the same time. describing the entire process of making a program is beyond the scope of my post.

What I am really telling you in this post is that no person alive is expected to have any language memorised and you need only to understand basic program logic to write a program in any language.

Lets say you learned the basic principal of variables.. then you learn the basic principal or pointers to those variables etc..
While you are learning those basics,.. you may have had to open a header file or several header files... thats where the experience comes in... Experienced programmers have had to peruse header files of various libraries to achieve an end result for probably a long time.
reading the code in the header files gives you an idea of what that function will do for you and it describes how the function will be used in the .c section of your program.
All thats left for you to do is assemble your program into your logic flow that you have on paper.
Programming really isn't so difficult if you take the steps to produce it in a logical way.. and in small bite size pieces. And when you compile your code in Visual C.. you can get online help in plain english.. about what the error is, where to look for the answer in your files, and even a sample snippit if you need it.

Just telling you,.. You already know how.. all you need is to keep it simple..keep it logical and get it on paper before you attempt to write even one line of code. It helps to keep you on track and focused.
You likely know the basics of C or C++ already.. enough to write your program...
Most books assume the reader already knows the basics of containers, variable, pointers, stack heaps, etc etc.. and they dive right in.. thinking the reader can relate to whats in the book.

I hope I didn't further confuse you with this post. It's just that so many people think like I did when I started.. thinking i'd just punch out a complete program in 1 day ( more then "Hello World ).
Torque isn't really as complicated as I first thought either... When i got the engine I went straight to the header files and started reading, then when i got bored of scanning the code, I went to the Docs and the TDN ( when i was able to connect to it ). And then I went looking at the directory structure.. and finally I opened the scripts and followed the logic flow... eventually it all came together.. coagulated into a mound of something that made logic sense to me. Then to further make what i learned more concrete.. I bought many of the content packs that included all I would need to make something ( depending on that content pack )
then i'd put it intothe engine as described in the readme.txt files.
Even while i did buy both of Fredericks books, nothing helped me more then diving into the engine code to start with.
We all learn differently, maybe you learn faster then me.. or differently than I do.. I guess it's just a question of finding which way you learn best. Some people learn with just a quick lecture.. others need to be shown step by step and why we took those steps in that sequence ( like me ).
If this post means nothing to you at all.. then atleast it distracted you enough to know your not alone. =)

#2

Quote:
What I am really telling you in this post is that no person alive is expected to have any language memorised

Can I correct you? HTML is pretty easy! ;-)

I first found out about Torque through this book, and I was thinking the same thing. It might not work for you, but I read the book, learned all I could from it, and then started messing around with the demos until I understood what everything did and how it worked together.

#3 Thanks for the page-stretcher, Scott. although that's not really what I was getting at. Nathan's short post more resembles my situation, I learned all my codes through expiramentation. But this book just doesen't explain enough. It completely lets you go when you get to the tommy gun. Is there any more comprehensible tutorial out there? One that begins with getting the world to load, terrain, ect?

#4 James, have you tried the Game Programmers Guide to Torque?

Sorry for the long stretch of earlier post, got carried away LOL.

#5 Josh, I totally understand your problem. I just went through it myself. In my opinion, that book is only marginally better than browsing the scripts yourself. It does a few things well, but after a while, you just feel like you're being told to do a bunch of typing without really knowing what in the heck you're writing. To make matters worse, my confidence in what I was reading was drastically destroyed by the fact that the code in the book simply didn't work correctly. Try the multiplayer out? It is jerky as all get out! It really made me question my decision to use Torque. But then I found that all these problems were just peculiar to the book and not to Torque.

I've only started reading it myself, but so far I really like the writing style of this book:
The Game Programmer's Guide To Torque

I also bought this and it's great too, though more of a reference than the first book:
Multiplayer Gaming and Engine Coding for the Torque Game Engine

If you're serious about getting into Torque, I strongly suggest you pick up at least that first book. It is really well-written. Keep in mind, however, that no single book is going to be able to give you a complete understanding of a subject as deep and complex as Torque and game programming. But from what I've read of them so far, those two books are a lot less like drinking from a fire hose (unlike 3D Game Programming All-in-One).

I hope that helps!