Confused on how to start

#1 Well, first of all, build the TorqueDemo to get the base Torque engine binaries. You'll also need map2dif, so build that also.

Next, I'd go into the example directory, copy the .DLLs and .EXEs and drop them into a new directory (named whatever you want). Also grab the "common" and "starter.fps" directories, plus the main.cs file.

Rename "starter.fps" to whatever you want, then edit main.cs so that $defaultGame points to the renamed directory. Next, I recommend using a recursive search-and-replace for "starter.fps" to your new directory name for all of the .cs and .mis files.

Starter.fps is still fairly large, because it contains all of the example code and objects from the normal Torque demo. But the structure is a lot simpler than the Torque demo and it makes a good starting point. You can pair it down even more, but you'll have to be careful about what you remove.

At this point, I'd make sure it's all working and then work on your design spec. Once you have a clear idea of what you want from the engine, go about modifying things and testing them out in your stripped-down game base directory.

I hope this helps.

#2 Buying 3D Game Programming All in One, by Ken Finney, is another great way to get a leg up as well. It is entirely about Torque and Torque-compliant tools, and goes over scripting, texturing, world-building, GUIs, models, model skinning, some audio info, and more.

#3 Ok, thanks guys.

The question I still have is why the demo application is over 2MBs big when some other demo I downloaded from the website has an exe that is about 600kb in size. From what I see no real modification to engine code is required, and that 1.4MB shouldn't just come from nothing.

#4 If you build the demo application as debug, it gets even bigger. The thing is that the engine contains so many things... There's the 3-space (TS) library, the interiors (DIF), lighting, shadowing, rigid body dynamics, vehicles (flying, driving, hovering), and more! When people build a game, they might go to task on what they really need in the engine instead of leaving everything in. Just start small, and understand that even if you were a wizard programmer it's going to take a while to get the engine understood. I've been at this for a year plus, and I'm still pretty much a beginner. I must say that when you take on something like adding stencil shadows to the engine, you learn a lot. So, get dirty with the code, the scripts, get Ken's book, and spend some quality time pulling things apart and putting them back together.

Game development isn't easy. Most people who want to make a game think "$100 engine? Man I'll have a game in no time." Well, what you've purchased is 500,000+ lines of code including scripts and a wide open playfield. However, it's gonna take you a lot of work to get from beginning to end. It'll be fun (trust me) and a pain in the butt (trust me) but it'll be worth it (trust me). :-)

- Brett

#5 Actually, we used a neat little tool called UPX to compress the EXE. Works wonders, and really shrinks stuff down.

#6 I know it contians a lot of stuff, and thats why its great and is recommended by many people :). Just because of the time it takes to write a good engine I gave up on doing it myself.
All I have been hearing about the "Ken's book" are praises, it really must be good. Can anybody tell me what it covers in terms of the engine?

If the exe of other applications was compressed, does this mean that the exe created by the Torque demo is not modified in any way for the purposes in of the game demo? (Comparing to the Torque lib project)

#7 The torque you build from the CVS is essentially the same as the torque that is downloaded with the demo (although its been compressed and your build might have a few changes or bugfixes).

In fact, you should be able to copy YOUR executable over the torque demo exe and have it work (Havent tried it, but it should).

Try running UPX on your own build (release build that is) and compare them :)

#8 Slightly off topic, but this comment made me want to describe something we've seen:

Quote:
In fact, you should be able to copy YOUR executable over the torque demo exe and have it work (Havent tried it, but it should).

The environment really appears very flexible when doing things like this. We have a linux, win, and mac build for the demo, and a linux and win build for our code. Our mac build for our code is a bit behind the timeline, so we decided to try dropping the demo mac build into a run-time sandbox (fully updated scripts, etc. in this sandbox). Torque didn't even blink on all the client side functionality--the mac demo exe worked great with all the GUI and state logic checks, and while our dev didn't try to connect, I'm decently confident it would have refused (semi-)gracefully.

We also didn't even bother making a mac full distro package, we simply have our mac users download the windoze full distro package, install it (stuff-it can read/expand but not create .zip files), and the separately download the mac executable. They then drop the mac executable into their runtime environment and it works like a champ.

#9 UPX is indeed good for compressing down .DLLs and .EXEs. I use it all the time, too. (Though archiving your game in a ZIP will compress it down just as good, if not better than using UPX. But it's still a friendly thing to do for your users, so they won't have 2-3 meg .DLLs/EXEs sitting on their HD after installing your game...)

Stephen, another good thing is if I have a crashing issue, I can just grab the Torque demo's binary and drop it into my code base and test from a "known good" state. Sure, some things might not work due to changes I've made to the engine, but the basic game will come up no matter what. (Unless it's my resources which are causing the crash, which is usually the case. ;)