![[info]](http://l-stat.livejournal.com/img/community.gif?v=91.6){kind=small}
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=91.6){kind=small}
I'm pleased to announce that the long-delayed TADS 3.1 is finally available. This is a fairly major upgrade; it has two major new feature areas, a raft of little language enhancements, and many bug fixes. The Windows and source code packages can be downloaded from tads.org immediately. (The code has already been ported to Unix and Mac OS, but those still need to be finalized and packaged.)
For full details on the changes, see (as usual) the change history - that's available on tads.org on the Manuals page, along with the current documentation.
The first major new feature area is Web play. It's now possible to design a game for deployment on the Web, so that players can run it in a Web browser without installing any TADS software on their machines. The game and the TADS interpreter run on an Internet server, and the game presents its user interface as essentially an HTML page. The game itself acts as a Web server, serving the HTML/JavaScript/CSS resources that make up its UI.
It's not quite TADS's answer to Parchment: for one thing it doesn't give existing games instant net deployment, since the game has to be built specially for this mode; for another, the .t3 program actually runs on the server and communicates with the browser via AJAX, rather than running entirely inside the browser as javascript the way Parchment does. This second point has some pluses and minuses; the main drawback is that it requires a continuous connection with the server, so you can't play disconnected with a browser. (You actually can play such games disconnected if you install the TADS interpreter on your client machine, since that lets the whole client/server setup run locally without the need for any network connection.)
But there are also some serious pluses. The big one is that TADS now has a true network infrastructure. The obvious possibility this opens up is multi-user play, for building MUDs or multi-PC games. Now, this is just a possibility at this point, since there's no library support for any of that, but the network plumbing is in place to support it. I see a few other possibilities that are also pretty interesting. One is collaborative play - which is more than a possibility, actually, in that the updated Adv3 supports it out of the box. Collaborative play means that multiple people can simultaneously connect to a session - still playing a single-player game, but with each player able to see what the other players see and able to enter commands. The same idea as a couple people huddling around a computer playing together, but remotely via the Internet. Another idea I'd like to explore at some point is using the networking to let the author be involved while people are playing - either directly involved in the sense of actively manipulating the game in response to what the player is trying, or more simply, just gathering ongoing information on where players got stuck, verbs that didn't work, etc., that could go into improving the game in a rapid update cycle. Same idea as beta testing, but continuously after release, and without people having to manually gather logs and send them to the author. I also have this back-of-the-mind idea of using the network as a real-time human supplement to the parser, where commands that aren't recognized by the mechanical parser could be instantly flashed to a network of people who could step in and interpret the commands into something recognizable to the parser, and send it back, so that from the player's perspective the parser seems to understand whatever a human could.
The second big new feature area is dynamic compilation, and a bunch of related improvements in the reflection system. This pushes TADS pretty fully into dynamic language territory. So far it's not something that Adv3 uses at all, but I added it because I have a bunch of library facilities in mind that could take advantage of it. Adv3 or, more likely, the "Mercury" library I've mentioned will probably start taking advantage of it in the next round, and in the meantime, I think it opens up a lot of new possibilities for add-on libraries.
For full details on the changes, see (as usual) the change history - that's available on tads.org on the Manuals page, along with the current documentation.
The first major new feature area is Web play. It's now possible to design a game for deployment on the Web, so that players can run it in a Web browser without installing any TADS software on their machines. The game and the TADS interpreter run on an Internet server, and the game presents its user interface as essentially an HTML page. The game itself acts as a Web server, serving the HTML/JavaScript/CSS resources that make up its UI.
It's not quite TADS's answer to Parchment: for one thing it doesn't give existing games instant net deployment, since the game has to be built specially for this mode; for another, the .t3 program actually runs on the server and communicates with the browser via AJAX, rather than running entirely inside the browser as javascript the way Parchment does. This second point has some pluses and minuses; the main drawback is that it requires a continuous connection with the server, so you can't play disconnected with a browser. (You actually can play such games disconnected if you install the TADS interpreter on your client machine, since that lets the whole client/server setup run locally without the need for any network connection.)
But there are also some serious pluses. The big one is that TADS now has a true network infrastructure. The obvious possibility this opens up is multi-user play, for building MUDs or multi-PC games. Now, this is just a possibility at this point, since there's no library support for any of that, but the network plumbing is in place to support it. I see a few other possibilities that are also pretty interesting. One is collaborative play - which is more than a possibility, actually, in that the updated Adv3 supports it out of the box. Collaborative play means that multiple people can simultaneously connect to a session - still playing a single-player game, but with each player able to see what the other players see and able to enter commands. The same idea as a couple people huddling around a computer playing together, but remotely via the Internet. Another idea I'd like to explore at some point is using the networking to let the author be involved while people are playing - either directly involved in the sense of actively manipulating the game in response to what the player is trying, or more simply, just gathering ongoing information on where players got stuck, verbs that didn't work, etc., that could go into improving the game in a rapid update cycle. Same idea as beta testing, but continuously after release, and without people having to manually gather logs and send them to the author. I also have this back-of-the-mind idea of using the network as a real-time human supplement to the parser, where commands that aren't recognized by the mechanical parser could be instantly flashed to a network of people who could step in and interpret the commands into something recognizable to the parser, and send it back, so that from the player's perspective the parser seems to understand whatever a human could.
The second big new feature area is dynamic compilation, and a bunch of related improvements in the reflection system. This pushes TADS pretty fully into dynamic language territory. So far it's not something that Adv3 uses at all, but I added it because I have a bunch of library facilities in mind that could take advantage of it. Adv3 or, more likely, the "Mercury" library I've mentioned will probably start taking advantage of it in the next round, and in the meantime, I think it opens up a lot of new possibilities for add-on libraries.
