First thoughts on 3DGPAI1
by Chris · in Torque Game Engine · 06/12/2006 (8:58 am) · 1 replies
I'm new to Torque and I'm using 3DGPAI1 as my launching point. I wanted to comment on a few points.
I'm not sure yet what I think of the book's approach. I think the idea is like learning to drive: You don't need to know how to pull an engine apart to make the car work. So we have this car, and we can make it work (run one of the demo programs), and then we learn about one system at a time -- the steering, the brakes, the exhaust (or the control client files, the control server files, eventually we see the common files). We get to install a steering system that we've built into an otherwise working car. If the car crashes, the steering is presumed to be at fault. But was it the directions, or our ability to follow directions that caused the crash?
After getting emaga4 to perform as expected, I realized that every problem that kept it from working was one I had introduced -- after finding and removing my typos, it worked fine. I'm also finding that my problems with emaga5 (still working on it!) so far have also been my typos, not the book's.
Something I've learned, though, is that the problem and the cure may be seemingly unrelated. Maybe I typed in the steering, the brakes, and the exhaust, but the error appears in the winshield washer. This makes debugging difficult, since I've only worked on certain components, and don't necessarily see how they fit with the rest of the car.
The trade-off seems to be that by starting with a nearly complete program and typing-in a few components, we get to see a result quickly. But it makes debugging difficult because we don't necessarily know where to look to find the errors. (right now, when I run emaga5, after I start the game, it loads several files, including several lighting files, where it hangs. Oddly enough, I've tracked the error down to the weapons/weapon.cs file -- I never would have thought to look there initially). If we had all the tools explained one at a time, the final result would be a long way off, and we'd have a lot of info with no frame connecting it. I generally learn better the latter way, but I can appreciate the method the book uses, even if I find it frustrating at times.
Finally, I'd like to note that several posts have commented that the book is buggy, includes typos in the code, etc. But as I said before, all the code typos I've found so far have been my own. If I find any book/code typos, I'll post them. I really don't believe in the notion of "well, it doesn't work, so just skip to the next chapter, it gets better."
I'm not sure yet what I think of the book's approach. I think the idea is like learning to drive: You don't need to know how to pull an engine apart to make the car work. So we have this car, and we can make it work (run one of the demo programs), and then we learn about one system at a time -- the steering, the brakes, the exhaust (or the control client files, the control server files, eventually we see the common files). We get to install a steering system that we've built into an otherwise working car. If the car crashes, the steering is presumed to be at fault. But was it the directions, or our ability to follow directions that caused the crash?
After getting emaga4 to perform as expected, I realized that every problem that kept it from working was one I had introduced -- after finding and removing my typos, it worked fine. I'm also finding that my problems with emaga5 (still working on it!) so far have also been my typos, not the book's.
Something I've learned, though, is that the problem and the cure may be seemingly unrelated. Maybe I typed in the steering, the brakes, and the exhaust, but the error appears in the winshield washer. This makes debugging difficult, since I've only worked on certain components, and don't necessarily see how they fit with the rest of the car.
The trade-off seems to be that by starting with a nearly complete program and typing-in a few components, we get to see a result quickly. But it makes debugging difficult because we don't necessarily know where to look to find the errors. (right now, when I run emaga5, after I start the game, it loads several files, including several lighting files, where it hangs. Oddly enough, I've tracked the error down to the weapons/weapon.cs file -- I never would have thought to look there initially). If we had all the tools explained one at a time, the final result would be a long way off, and we'd have a lot of info with no frame connecting it. I generally learn better the latter way, but I can appreciate the method the book uses, even if I find it frustrating at times.
Finally, I'd like to note that several posts have commented that the book is buggy, includes typos in the code, etc. But as I said before, all the code typos I've found so far have been my own. If I find any book/code typos, I'll post them. I really don't believe in the notion of "well, it doesn't work, so just skip to the next chapter, it gets better."
About the author
Anthony C
That isnt the case here. However, after talking to a few people on the forums, so far I have just been fiddling around with the demo, and theory crafting as to how things all fit together. I'm sure if I had a license or access to the tutorials that come with the engine I would understand better.
That said, *my* personal attack plan was to write down what would be my first step, or goal. That to me is to just be able to load up a guy in a world that he can walk around in. So im in the process of reading up on the steps to get there. They may be simple steps, but thats where I plan to start :)