Another topic got me thinking about this today. Obviously, Mike Roberts still owns tads, so this is entirely a flight of fancy.
But if TADS 4 were in development, what would you like to see in the next version? I’ll start off by saying more modern tooling. TADS has always been awesome for having a real debugger but the Workbench is showing some age.
I don’t have a whole lot of TADS experience, but from my little bit plus reading the problems that people run into on the forum, it seems like TADS gives users the technical tools to solve basically any problem—but not always the legal ones. Interpreter overhauls, support for new image formats, and so on are not allowed under the license.
So based on that, I’d say the biggest thing I’d hope for would be a free software license of some sort. Then the community can do the rest.
Apart from that, a way to make a game straightforwardly playable on the web (i.e. bundle it into a playable website) that doesn’t sacrifice formatting and output capabilities. I greatly enjoy how easy it is nowadays to turn a Z-code file into something that people can click and it will Just Work on pretty much any platform.
isn’t TADS abandonware at this point? the macos installer, for one, hasn’t been touched in 13 years. i installed it a while back and it was exhausting.
Recently, I set up a new Windows PC and installed TADS. The Workbench installation goes pretty smooth, but I wanted to use Adv3lite. This requires getting a little more hands on. In my case, using vscode and having tads as the compiler, I ended up having to set a bunch of paths by hand, not just in tads3-tools extension but also in the t3make file. Don’t get me wrong-the documentation is excellent, and it’s not that hard, but the process is far from automatic. I can see it being intimidating to new users.
I would certainly hope for a console mode debugger, and more accessibility as far as menus are concerned. The way the terps display menus now, they’ve never been that great with accessibility. Such is the reason why I recommend asking if the player is using a screen reader at start, then if so, setting statusLine.statusDispMode to StatusModeText.
Another thing that has never been accessible, but a possible TADS 4 could certainly try, is anything inside banner windows. The status line is easy enough to read, because it’s always at the top of the screen. Everything else either isn’t spoken by the IF interpreters add-on for NVDA that I use (found here), or when read via NVDA’s object or screen review, is jumbled together with the existing text in the main text window.
I think abandonware in the somewhat good sense - it’s stable, works and useful, but the author has moved on. The OS and requirements changing around the project is the current source of instability, I figure.
That said, it would be nice to have maintainers to do those kinds of chores. MacOS I believe is a particular pain.
I’d also love a TADS 4 or equivalent - an IF language with a strong, confident, programmable world model.
Eric Eve’s excellent Adv3Lite is still maintained and improved on a regular basis.
I would like to have the TADS 3 HTML game interface brought up to date.
Yeah I love Adv3lite, it’s pretty great. I’ve never seen another system manage NPC states so well.
Tads3 was so ahead of its time that it still has a lot of unused potential. I would much rather see a Tads3.2 than a Tads4, and an even larger user base.
What Tads3 really could benefit from is a fancier interpreter, with autocompletion, and the ability to run full html support directly from within itself (with some safety guarding rails) instead of only as a server. The interpreter could also benefit from having an automapping feature, and a built in debugger/vm monitor while running in debug mode. I would also enjoy if it had builtin (and optional) integration (via intrinsic functions) with math libraries (like eigen or numpy), and a sqlite integration out of the box. I’m sure there are many other interesting integrations that could be added as intrinsic functions.
I don’t think there are any restrictions in the license to build a better interpreter with more builtin functionality like this and would place energy and effort there instead of trying to improve Tads3 as a language. Michael really made the batteries included but replacable in this regard.
That said, a tads3.2-and above compiler could also benefit from:
My wishlist:
Some of the above could conceivably be met with newer libraries or intrinsic extensions. Those are the kind of things that the community can provide to keep TADS rolling.
What’s more difficult is extending the language itself. I could see someone taking on interpreter improvements, but compiler improvements are a different beast. And, because TADS is a dynamic language, many of those changes have to be reflected in the virtual machine as well, with bytecode additions and the like, which could very well spill over to the debugger.
It’s a tall order!
A few years ago, I took a stab at coding a full JS port of TADS 3. My idea was to build a new interpreter that ran TADS natively in a browser.
I’m well aware of other approaches to running TADS in a browser. I hoped that an interp rewrite would open up some of the above, such as better HTML + CSS support. But, as I said, language improvements were still off the table, without changing (or rewriting!) the compiler.
To cut to the chase, I reached the point that the code could read a .t3 image file and start executing the setup code. Esoteric VM features (such as debugging opcodes) were missing. The intrinsics needed to run a basic game are far more work than you would think.
I also toyed with another idea: No more compilation. Make TADS a scripting language. Write a parser that builds the bytecode at startup, rather than first compile it down to disk. The script could be distributed in a standard ZIP file (.t3z?) that the JS could pull the source files from.
(If nothing else, this would reduce the edit-compile-debug cycle. If people still want to distribute compiled images, they can do that as a final step.)
And that’s where I set it aside. It was a valuable exercise, and I learned a great deal about the VM. But I reached a point where I didn’t merely want TADS native in the browser. I wanted a better language, and direct access to modern tech. That wasn’t going to happen without a lot more work.
I’ve got more to tell, but this is getting long-winded, so I’ll leave this here for now.
This makes a ton of sense to me. Not just in the “programming is hard let’s go scripting” arena, though there’s plenty to be said for that too.
There’s a lot of discussion in the community about dealing with the limits of the Z machine. I don’t mean to be critical-this is all for fun, let’s not forget-but it’s also no longer necessary. I mean, I have raspberry pi’s sitting around my house with EXPONENTIALLY more memory and computing power than what the Z machine was designed to run inside.
It’s fun to see a modern game you wrote booting on a Commodore 64. A lot of clever engineering has gone into some of these projects; I’m sometimes amazed at what folks on this very forum accomplish. Gluxe and the A machine were literally designed to extend 70’s era tech without rocking the boat. In their way, they’re marvels of computer science.
But we live in a time where computing power is cheaper than it’s ever been, in all of human history. Why shouldn’t we pass those dividends on to the author? Even massive IF runs on what is today considered a potato.
VMs running specialized bytecode instruction sets seem a bit like a necessary invention which belongs to the past. Yeah, sure, there’s still reasons to use Java or C#, I get it… But for games, scripting offers so many advantages. Rapid protyping without continuously re-compiling comes to mind.
Modern script runtimes are fast, efficient, and we don’t have to deal with hard object or vocabulary limits. They can effortlessly execute very large games, even inside of a Web browser, or in a low power device like a pi.
I don’t think programming is easier if the code is interpreted instead of compiled. Though beginners have that impression.
But yes, scripting can make porting easy.
I guess it depends on your definition of programming and scripting. People who write Python exclusively consider themselves programmers, not script-writers, but individual Python files are typically called “scripts.” Obligatory reference to Larry Wall’s old essay.
If Python and Ruby are scripting languages in which one programs, I’ll be having BBQ for lunch prepared on my BBQ with a side of BBQ sauce and BBQ chips.
I think it’s fair to say Python straddles the line between traditional scripting languages and traditional programming languages… Or to put it another way, there are tasks where bash and python both seem reasonable options but C++ would be overkill and there are tasks where Python and C++ seem reasonable options but bash would be inadequate… Granted, I suspect all three are Turing Complete up to memory limitations and any computable task could be completed in all 3, and the scripting/programming dichotomy is false and the line blurry, I just get the impression Python crosses that blurry boundary in a way someone familiar with bash and C++ likely has strong opinions about which side any given task falls.
Though, isn’t Twine and it’s variants built on top of JavaScript, arguably the most widely used scripting language of all time?
Though, as someone most comfortable coding in C++, my personal IF coding pipedream would be a cross platform library that facilitates adding a parser interface to a terminal game. Sure, cout and cin can handle a lot, but that basically requires building a parser from scratch if I want to be able to handle more than a small number of hardcoded inputs.
So… Condensing these comments a bit…
Community support is the big one. Current licensing prevents the TADS community from making big changes to the language. It’s not helped by the fact that TADS is enormous, and re-interpreting the compiler and the interpreter are not simple projects.
I’d love to see modern language improvements, something akin to more recent Typescript. There’s a lot of similarities there: Typescript is a C-style language with excellent debugging tools and strong OOP support. Good math support and functional language features are pretty cool too. I agree that multiple inheritance kind of makes a mess.
Adv3lite is fantastic, and still under active development, and uses the newer mercury parser code. We generally agree it’s pretty great and would like it to continue to be supported in some form.
Web-based content rendering, whether we like it or not, seems to be the future. Web interfaces are highly themeable and supported everywhere. Even in fully offline applications, HTML renderers are used everywhere, thanks to stuff like electron and tauri. In fact, for a recent project, tauri kind of shredded the local widget API for performance, just because HTML renderers are so ridiculously optimized.
So getting HTML and css3 isn’t hard, a modern TADS would simply pass the game content to an HTML rendering display layer. That gives a lot of power to the author in terms of how the game is presented, which opens up it’s own set of issues, like accessibility and the user’s own right to set fonts and colors however they want.
I wonder if that’s one reason why we’ve stuck to classic VT style presentation for so long: all the questions are mostly answered there.
There are plenty of excellent tools to write IF that output games in formats which put little or pretty much no constraints on size and complexity. And a lot of people use them.
At the same time, there are thousands of people who want to play IF games on their old 8-bit or 16-bit computer of choice, and when they see a really good new game come out for their favorite computer, they want to download it or even buy a physical copy. These people, and the fact that we enjoy working with these constrained platforms, are the reason why some of us put a lot of work into writing tools and games that make the most of the Z-code format.
I’m reminded of that quote about limitations breeding creativity. Even in more mainstream gaming circles(e.g. where animated graphics, music, and sound effects are baseline presentation, not optional bells and whistles), there’s a counter-intuitively high amount of interest in making new games for old hardware or porting modern indie titles to retro platforms, and even in the realm of modern gaming, there’s a somewhat prevalent sentiment that indie devs making smaller scale projects that stick to one traditional style of gameplay, small, well crafted and lively worlds, and graphics that care more about an aesthetic than raw polygon pushing are producing better results than many Triple-a devs that go out of their way to push the limits of modern hardware with photo realistic graphics, expansive open worlds, and genre blending do everything type gameplay… And it seems like I hear a lot more about people being impressed how oldschool games pulled off things that wowed in their day with what feels like nothing specs by today’s standards or some modern retro game shattering what people thought was possible with the old hardware than I hear about people being wowed by the newest Triple-A blockbuster… Granted, of the 4 forums I frequent, 1 is here, 1 is dedicated to the hacking of Sonic the Hedgehog and seldom talks about anything newer than Generations in the hacking section, and a third is dedicated to audio games and is almost entirely inhabited by the blind, so discussion of modern, mainstream gaming there is mostly in regards to games with native accessiblity or vibe coded accessibility mods, and the fourth is dedicated to mechanical puzzles, I avoid corporate social media like the plague, and the selection of gaming related YouTube channels I have bookmarked might be biased towards the retro side of things.
I’m of two minds on that. Yes, absolutely, limitations breed creativity. However: as an author, I deal with enough limitations just trying to make a game; not just technological but in terms of what I can do with my limited free time on a hobby project. I can’t, say, justify the expense of hiring an artist or an editor to help me craft a perfect interactive experience. Nor can I summon the writing powers of Shakespeare or Adam Cadre to create spectacular prose. We all work within our limitations, both inside and outside ourselves.
So, given that is the case, I’d argue that the IF development system really should stay out of my way whenever possible. Preferably, if I have an idea, there should be no barrier to making it come to life.
Again, it kind of depends on what you want; if you enjoy hacking around with old systems, which a lot of people do, that’s great! There’s some super clever engineering in what smart folks can do on old systems.