### Hello, World!

By tradition, programming language books always start with an example program that displays "hello, world" and exits. This isn't exactly a book, but the "hello, world" is still the right place to start. So, here's the obligatory sample program; copy this into a file called `mygame.t`:

    #include "tads.h"

    main(args)

    {

        "Hello from TADS 3!!!\b";

    }

After you've saved the file, open a command line window and change your working directory to the directory containing the file (on Windows, use the CD command). Make sure your path is set up to include the directory containing your TADS 3 tools. Type this command:

       t3make mygame.t

This will compile and link the program, producing a file called `mygame.t3`, the "image file" containing the T3 executable version of your program. To run the program, type this:

       t3run mygame.t3

If you've used previous versions of TADS, some of this probably looks familiar, but some is new. The `#include` directive should be familiar, but the file included isn't – this is a system header that defines intrinsic function sets (more on these later). Next comes something called `main` – if you've used Java or C, you'll recognize this as a function definition, and you'll also recognize it as the main program entrypoint, where execution begins. Functions work the same way in TADS 3 as they did in previous versions, but the unusual syntax that TADS formerly used is gone; TADS 3 function definitions are now essentially the same as Java or C definitions, except that the return datatype and formal parameter types are still not specified.

`main()`, as we mentioned, is a special function. When the program starts running, execution will start here. (Actually, execution will start in some library code that the compiler automatically adds, but `main` is the part of our code where execution begins.) The argument is a list containing a set of strings, one for each argument on the command line that started the program running.

Inside `main()`, the program displays a string, by writing the string to display inside double quotes. This works a lot like it did in TADS 2 – when a line containing a double-quoted string is executed, the VM displays the string. (The only difference is that the VM calls the "default display function" to do the actual displaying; the library startup code establishes the default display function, but you can optionally define your own to customize how strings are displayed.)

You might be wondering where things like the `init()` function and the `startroom` object are. In TADS 3, these are no longer part of the system. (Similar things are defined in the standard adventure game library, which you'd almost certainly use to write a game with TADS 3; at the moment, though, we're talking about the system itself, without any extensions from libraries.) Whereas earlier versions of TADS did all sorts of things automatically before your program ever got control, the TADS 3 interpreter merely loads your program and calls `main()`. When `main()` returns, the program is finished, and the TADS 3 interpreter terminates.

It might sound like TADS 3 is a big step backwards from TADS 2, since TADS 2 did so much more automatically. It's true that the game program is responsible for doing a lot more in TADS 3, but this actually makes things better – no longer will you be forced to use the command loop that was built in to TADS 2. Instead, the sorts of things that were built directly into TADS 2 are instead implemented in the library in TADS 3; so you still won't have to write any of those things yourself, but you can change them if you want to, and as much as you want to, because the library is all written in the same language as your game program is.