I’ve recently been ferreting under fungus for a working version of TADS 3 that will run on Mac OSX, which isn’t exactly the most obscure platform on the planet, but so far I’ve drawn a blank.
Cocoa TADS, which is only available in “pre-beta” form, won’t even compile the elementary starter game (nor anything else, so far as I can see), while QTads, described by some webpages as the only (text limited) version of the language available to OSX, curtly tells me on launching that it is “not supported on this system”. This system being a 400MHz PowerPC G4 running OSX 10.4.11
I’m busy developing a game which will make use of the wider capabilities TADS3 affords, and my life or death struggle with the arcane syntax is enough of an obstacle to concentrating on fashioning a clever, amusing and original game, without having to play hide and seek for a simple compiler. I’m hoping one of you more experienced types will know of a simple solution.
I don’t want to install a Windows shell just for the purposes of writing a TADS game, and it would be disappointing in the extreme to find that Mac users are completely unsupported. Any ideas?
You can’t run the current T3 Workbench on Mac without Windows emulation of some kind. I think FrobTads allows you to work with your text editor of choice though. However I’m a little confused, are you concerned about playing T3 games on Mac, writing them, or both? What are you using now?
edit: also, Cocoa Tads isn’t meant for compiling, but for playing games, though maybe the latter is what you mean anyway.
If you want to write a TADS 3 game using the Mac as your authoring environment, you have two choices: You can run Workbench in a Windows shell (or using an emulator such as Crossover), or you can use the FrobTads compiler, which is a command-line compiler. Neither choice is ideal, but both are workable.
There is no Mac-native version of Workbench, unfortunately, nor is one likely to appear in the near future.
They still refer to the older version of QTads, which didn’t support multimedia.
I was not aware that PPC-based Macs are still used, which is why I targeted Intel-based Macs with OS X 10.5 and higher. If PPCs are really still used out there, I could look into coming up with a version compatible with them, but I’d need someone who actually owns a PPC to test whether whatever I come up with works at all.
If not, you could also try to contact its author (Uli Kusterer) and hope for an update. Jim, you mentioned in the past that you would be interested in getting together people to donate some cash for a Mac IDE. You might want to target Uli on this and see if he’s interested.
Perhaps several people could try to get in contact with him; people tend to abandon their projects if they feel that no one’s using them or no one’s interested in them.
PPC Macs still exist in the wild. (I have one.) A five-year-old machine is not sparkly-new but could still be used for an IF-playing workhorse, so it’s worth supporting PPC for as long as you’re targetting 10.5.
(My desktop machine is almost ten years old, and I will probably ditch it soon. But the PPC line laster longer than that.)
See para 3. I haven’t used TADS in a couple of years, at which point I was still more interested in authoring than playing the games. It seems to me that “IF” is unique in computer gaming in that its success rests less on programming or graphical skills than on writing talent. The hook lies not in the puzzles or mazes, but in the flavour of the narrative which will intrigue or amuse the player. And if Cocoa TADS is strictly for playing, not writing, games, that was anything but clear on the TADS page I downloaded it from. Will look into FrobTads.
Jim says
– which is blunt enough I suppose. The next question would be why? Why should it be necessary to run a Windows shell on a system that doesn’t require them? What happened to cross-platform portability?
RealNC is astonished to discover that poor people have not all been melted down for glue yet, and some are even using Power PC desktops. It’s a scary world out there, NC. The first computer I used had 1k of RAM, no hard drive, no storage device and a flatpad printed keyboard. I cut my teeth with text adventures on a BBC micro (32k) so I’m unimpressed with hardware one-upmanship. Computers have a longer lifespan than the ecology of relentless software upgrades implies.
Thanks again for your initial responses. As I said, I’m more interested in fashioning an original game and wrassling the bugs out of it than making my Mac conform to some spurious homogeneity. If I cannot write it in TADS, I’ll just have to seek another language, but that’s a pity, as the parser is both subtle and flexible.
This project appears to be about 5 years old. The docs refer to TADS 3.0.8, so I’m doubtful it will work with a current project. I’ll send Uli a message and see if he’s still interested in doing anything with it. I would urge others to do the same!
My offer of money wasn’t for a MacOS Workbench, however; it was for a browser-based T3 terp.
It isn’t Workbench in the same visual sense as the Windows version, but it seems to have most of the basics in place. There’s a code editor with syntax coloring, for instance, and a Build & Run command. What interpreter it will use I don’t yet know, as the project I have lying around on the Mac uses a more recent library, so it won’t compile.
The easy answer is, “Because Mike Roberts doesn’t own a Macintosh.”
This is accurate, I believe, but of course there’s more to the story than that. To refine the answer, I would note that the community of TADS users is not large, and the subset of that community that has professional-level coding skills is even smaller, so if it’s going to happen, Mike is probably going to have to do it himself. Mike does not get paid for his work on TADS, so his enthusiasm for the idea of rushing out and buying a Mac, and then spending weeks learning the MacOS API, in order to support an expanded user base that would consist of, oh, eight or ten new authors at most (I’m guessing) is probably not great.
I agree that it would be swell if older computers continued to be supported. (My first computer was a Kaypro, BTW.) Everything in modern life has become sort of throw-away, hasn’t it?
The more correct answer is that TADS suffers from the same problem as Inform: the main developer isn’t using a portable toolkit to write the IDE. Instead, they opt to use only the native APIs of the platform they happen to be on, making porting to other platforms impossible.
This is quite sad, considering that portable APIs (be it Java, .Net, or if you prefer native, non-emulated applications, Qt, Gtk, FLTK and wxWorks) have been around for more than a decade by now. For Inform at least, there are people who took on the task of writing their own Windows and Linux IDE (though I hear they’re not as good as the Mac IDE, which is the result of not using a portable API in the first place.) Since TADS isn’t as popular as Inform (probably even by orders of magnitude less popular), the potential pool of developers to write an IDE for other platforms is extremely small.
And yes, the above was a rant. If you care a little about portability, pick a portable API to write your app so others can port it easily instead of writing everything from scratch. It’s not rocket science. And, most importantly, your users will thank you.
This is certainly true. On the other hand, if you have a project that (for whatever reason) you failed to start using a portable API, and if you now have years of legacy code that forms the core of the system … at what point are you going to be motivated enough to bite the bullet and port the entire project over to a portable API?
I use a great music production program called FL Studio. It’s Windows-only. However, some users have reported success running it under Wine. The fact that it wasn’t developed using a portable API doesn’t seem to have stopped them.
On a related subject:
Uli Kusterer tells me he’s not interested in pursuing development of his Mac Workbench project. However, if anyone would like to take it over, he will make the source code available.
Well, to be fair, many portable toolkits kind of suck. At least that’s what I found when I set about porting Gargoyle. I had in mind to try to use Gtk, only to discover that it didn’t support the OS X protocol needed to open more than one file at once.
You could invoke it correctly with the first game you tried to launch, of course, because Launch Services would correctly figure out that the file was associated with the app and fire it up. But the second (and each subsequent) file open request would be silently discarded, because the toolkit simply wasn’t set up to respond to those events.
The UI standards for the Mac may make it enough of a special case that this is common to all the portable toolkits. I’d be interested to know if you encountered this problem with the QTads Mac port. I didn’t look at QT since it was fairly heavyweight for my purposes.
In any case, remember that QT’s licensing was problematic a few years ago when the IDEs first appeared: either GPL or commercial, and the GPL can really tie your hands when it comes to third party libraries. Gtk was LGPL but its Quartz port was even more dreadful back then.
I have an Xcode plugin for TADS on my to-do list. I don’t think there’s a public API for Xcode yet, but the existing API has been reverse-engineered to the point where this seems superficially feasible.
This would provide syntax highlighting, various build options, and so on. I’ve never installed TADS workbench for Windows so I’m not clear on what the other must-have features would be. Your thoughts?
When something isn’t supported by the toolkit, you can treat it as a special case and use platform-specific code only in those cases. And that’s what’s done in practice by other projects. Don’t code the whole app in a platform specific way; just the non-portable details.
I didn’t deal with any file associations yet. But the docs contain information about how to handle file open events and that OS X is treated specially. (Btw, I didn’t actually need to port it; it happens to run as-is from the same source.)
True. But I believe there were some other choices too (wxWidgets for example; I mistakenly referred to it as “wxWorks” above.)
As Workbench doesn’t run on Linux either, what about porting Workbench to a portable framework that would run on Linux and Mac? Or is it generally the case that Linux users wouldn’t want Workbench?
This is true for Gargoyle as well; its Glk implementation is completely portable, as are the interpreters. (Setting aside a host of 64-bit issues which continue to vex me.) All of the libraries had already been ported as well. The system-specific bits are encapsulated in two files, and those were the only ones I needed to adapt.
For an application with less modest UI needs, QT is easily the best cross-platform UI toolkit out there by leaps and bounds. It’s tempting to speculate that if it had been available at the current level of polish and with a more flexible license ten years ago, much of the software in the IF world might have a QT interface.
As it stands, many of the critical components (like compilers and interpreters) are fully and easily portable. It’s a shame the UI side gives entirely the opposite impression.
Different people find different features essential, I’m sure. My personal list would include, in no particular order:
A tabbed multi-document interface. Automatic indentation (and un-indentation) in the text editor, along with other editor niceties such as bracket/brace matching and block commenting/uncommenting. A search feature with three radio buttons so you can search (a) the current file; (b) all user files in the project, but no library files; or (c) all code files. Replayable game records in their own window (right-click on “Auto 129” and Workbench will compile the project and then re-run that game). Breakpoints and watch variables for debugging.
The text editor does not, at present, have code folding. That would be nice too. It doesn’t have auto-completion, but I don’t miss that.
In Windows, I use a program called Auto Hot Key to run keyboard macros. For instance, I type the tilde/back-accent key, and that produces the string <./s>, which is a curly apostrophe. I haven’t found anything similar to Auto Hot Key for MacOS; if there isn’t any such utility, then I would say keyboard macros of this sort would be highly desirable.
That’s my rough and ready guide to desirable features. I’m sure I’m leaving out some items.
I feel as though I’ve wandered back into the playroom and found the groan-ups have taken it over. Certainly you’re now discussing techy questions way above my pay grade.
Since asking the initial question, I’ve discovered I had already downloaded and installed Ulli Kusterer’s Workbench (dense of me to forget it) and that is half of the battle perhaps.
My next questions are liable to be elementary programming ones, so perhaps this is not the correct room for those, but I do have a global question before I start to code what should and should not be done with Brazen Bits and Frothy Glaziers, or Pharoah Tooting Common.
What are the respective pro’s and cons of Inform and TADS3 to the dilettante games author?
This is a good forum for asking any sort of elementary programming questions – please feel free to post as many as you like, as often as you like!
The issue with Uli’s Workbench, I believe, is that it doesn’t bundle the current adv3 library. The library is only 3.0.8. I’m sure you can download the current library and copy it into the directory where Uli’s Workbench expects to find it … but what I don’t know, without testing, is whether Uli’s version of the compiler will choke and spit up when handed certain new items in the latest library.
I would definitely recommend that you try this, as the newer library may include things you’ll find useful. Also, the docs (again, they’re downloadable) will refer to the newer features of the library without alerting you to what version they were added in, so the docs might be confusing here or there if you’re using the old library.
I’m speculating here, I haven’t tried any of this. But it’s a possible complication to be aware of if you’re going to use that Workbench.