TADS3 on the Mac OSX

I don’t know the answer to the general question, except that I can’t recall seeing anyone ask for Workbench on Linux. TADS Workbench is based on Scintilla, which suggests that it could perhaps be made to work for Linux. Scintilla’s GTK-based, though, so there’s not much hope for Mac users on that front.

Creating a TADS plugin for Eclipse would be another option, since Eclipse runs virtually everywhere. I don’t really like the Eclipse UI but I suppose it must have fans. Google’s Android SDK is Eclipse-based.

The Xcode plugin idea was inspired by the XNA Game Studio framework on the Windows side, which slots into Visual Studio.

I have. I don’t know about anyone else.

For me, the thing that makes the Workbench indispensable is its plethora of debugging tools. Text highlighting and auto-indent for TADS 3 are easy enough to add to any good text editor - I have it working (slightly buggily) in jEdit. But debugging a TADS 3 project, with the vast and wildly complex adv3 library, is much harder without Workbench’s debugging tools. Being able to set a breakpoint in a misbehaving function, add watch expressions for some key properties, and step through the code to see where it’s going wrong, for instance, just makes debugging so much easier.

Thanks for that. Having read Eric Eve’s thorough (not to say exhausting) article on the relative strengths and felicities, it may well be that I7 is more appropriate to an author (such as myself) who is intimidated by the non-intuitive C++ syntax of TADS3. Which in itself is a pity, since the game I’m developing will be fairly epic in scope (as befits The Bartoks themselves) and will need to implement a good deal of NPC conversation and response logic. But as Dirty Harry once observed, “A man should always know his limitations”.

Too kind. And perhaps what you say below anticipates my first pratfall, in that the Workbench as supplied contains no debug tool. When I compile and run an intro+1 room/no objects starter file for my game, no error is generated but the game fails to launch. Feel free to regard me as a simpleton, and be gentle.

And just to reassure you you are not wasting time on such a neophyte, a little about myself. I was a fan of the Level 9 games in the mid-80s, and set about writing (overly ambitious) projects on the BBC B. My programming skills are slight, but my grasp of logic is not, and I developed an extremely powerful text compacting routine by which all text messages in the main program body were encyphered to a vocab store at the end using, instead of a simple decimal increment for each element of the cypher - £e$Y&tt - a 255 character increment from base ASCII. This reduced redundancy in the text messages by 80% and allowed a fair bit of flavouring narrative within the constraints of 32k RAM.

A few years back I spent some while trying to implement a stranded pirate ship game in TADS2 - the chief hook of which was that all game descriptions, and all responses to player commands, were written in a parboiled Long John Silver English. The fun of a text game lies wholly in the flavour of the text (in my view) and not the cunning of the puzzles themselves. Unfortunately the C++ syntax just defeated my efforts at every turn. My poor brain is locked into pre-OOP mode.

I suppose the optimum solution for me would be a collaboration - I write all the fun stuff (rooms/players/objects/NPCs/conundrums) and get a supine friend to generate the code from that - but I don’t have any slaves in my basement right now with the necessary programming skills.

Eric’s conversation extensions for I7 add much of the TADS functionality to I7. I agree that the deeper levels of TADS syntax take a while to get used to!

In my Mac, the error messages show up in a Terminal window, not in Workbench itself.

There’s a collaborator search/announcement list on this forum. I myself collaborated on a game with Eric Eve, and I think the process went pretty well.

–JA

I wonder if the Workbench debugger could be de-coupled easily from the Workbench and then used externally in a text editor?

The debugger, like the VM, is pretty much a stand-alone entity. You don’t need to decouple it. You need to write something that uses it :stuck_out_tongue:

Neither of these is free. Nor is TypeIt4Me. (Auto Hot Key is free.) Also, I run Workbench under Crossover, which is a Windows emulator. I suppose I could ping these manufacturers to find out whether any of their programs will operate in a pseudo-Windows environment. I’ve tried Auto Hot Key in Crossover, and it doesn’t function.

Oh, well. I have a Windows laptop I can run Workbench on. It isn’t as nice as the Mac, that’s all. No wireless access to the modem, for instance.

Oh cool – then for an editor with an interactive console it should be possible to get a (albeit non-graphical) debugger working. With a syntax file then you’d be in good shape.

edit: probably this is what FrobTads does?

FrobTADS does not offer a debugger :mrgreen:

I wanted to thank Jim and NC for their guidance on my initial question. Having now looked into Inform7, I believe I’m going to have to defect. It does appear at first and second sight as though TADS3 is configured and structured for those who are already familiar with C++ coding, and is rather forbidding to everyone else. Inform7 appears to have been designed for maximum accessibility to non-programmers, allowing one to focus more on the project itself, and not at every turn on the precise syntax to achieve X, Y or Z.

I’m still impressed with the power and scope of the TADS parser, but my technical skills are simply too limited to cope with its internal structure. “Buttock-Up: An Avencher” will have to appear in Inform7, to delight and amaze the planet Arf. But I thank you for the help meanwhile.

I abandon this thread to the mysteries of the “debugger” tool. I have yet to find a program which supplies a “bugger” tool in the interests of fairness and balance.

Off to the Inform room I go.

By the bye, every single time I have tried to log out from this site, the logout button crashes (in Safari). I’m assuming I can’t be the only one to trip in this way on leaving the board.

Just FYI.

People are not born being familiar with C++ coding :stuck_out_tongue: It’s not forbidding to anyone. Such a claim is just wrong.

You’re in for a quite a surprise :wink:

People are not born familiar with Shakespeare or Quantum Mechanics. Therefore they are “not forbidding to anyone”? Such a claim is just fatuous.

Do I detect a hint of schadenfreude? The objective (I would have assumed) is to produce good, innovative and stimulating new “IF” - the means to that end is secondary. Turf wars between alternate browsers, mpg players or parser languages is a bit too adolescent.

I don’t want to embroil myself in a quarrel about syntax and coding semantics. You will just have to take my word for it that many of the conventions TADS employs are counter-intuitive even to those familiar with this kind of program writing. You guys are comfortable with the language and that’s perfectly fine. I would have liked to use it. I just don’t want to divert 12 months into learning C++ (or any other language) before I can grapple with TADS. User friendliness is still a good benchmark to aim for.

You’re still wrong: you don’t need to learn C++ fist, nor Java. Nor Pascal. Or BASIC. Or…

You only need to learn TADS 3. Just because T3’s language is somewhat similar to other languages, it does not mean you have to go and learn them first. It also does not mean that the learning curve is the same as those other languages. Compared to C++ for example, TADS 3 is pretty much a trivial child’s play.

It’s interesting how you interpreted my response as schadenfreude, btw. It was a remark about I7’s fuzzy language where getting the right syntax can be more difficult, especially since it can allow the syntax but might not behave as you intended (which is worse than spitting out an error right away.)

You must get out of the habit of announcing that people who think differently from you are “wrong”. Learn to disagree with good grace.

That’s another matter, and the proof of the pudding will be, and so forth. Maybe in a few months time I will be speaking harshly of the clunky semantics of I7. For the time being I just want to get on with cooking, without having to hunt all over the kitchen for the garlic press and cheese grater.

A few days back I observed - “By the bye, every single time I have tried to log out from this site, the logout button crashes (in Safari). I’m assuming I can’t be the only one to trip in this way on leaving the board. Just FYI.”

And that is still the case. Clunkiness comes in all shapes and sizes, I guess.

I sense some form of negativity or hostility here. I’m not trying to step on your toes. I’m only trying to make it clear that “TADS equals C++” is false. Other people read these posts and they will get the wrong idea when they read that. This is what “you’re still wrong” refers to.

I guess you can report that in the “Feedback” section. Note that you don’t need to actually logout of the forum. It happens automatically if you’re idle for a few minutes. (Unless of course you’re using a public computer, where manually logging out is a good idea.)

Hmm. I did think of posting a few illustrations clipped verbatim from the TADS Guide - curly braces galore - to demonstrate how the syntax to accomplish a fairly simple check/enable sequence would be baffling to lesser mortals. Counter-intuitive was the polite way I put it. But there would be little sense my posting examples to prove the point, when those scanning this thread are overwhelmingly those who are familiar and comfortable with the syntax.

There are people in the world who do not speak Mandarin. It seems easy enough to those who speak it. QED.

My general observation about I7’s syntax is similar to RealNC’s observation, but the way I usually put it is this:

The learning curve for T3 is convex. The learning curve for I7 is concave.

That is, I7 initially appears much easier … and in some ways it is. But as you begin trying to do more complex things, you’ll find that you’re grappling with fuzzy syntax and a multi-layered system (I7 being built atop I6). In T3, it’s kind of the other way around. Initially it appears quite daunting, but as you begin to learn your way around, it actually gets easier.

Each language is right for some people. No one can tell you what’s right for you.

The braces allow you to tell where code begins and ends without actually having to even read that code. And since braces are symbols rather than words, they make begin-end code blocks visually more apparent. This is a tremendous help and allows for better visualizing code structure (again, without having to actually read the code.)

This of course assumes the user is not visually impaired.

While I’m familiar with T3 syntax, I’d still be interested in such illustrations if you have the time and inclination to post them. One of the problems I think in developing IF systems is that the people who develop them don’t have that beginner’s perspective most of the time.

On the other hand, there’s always a period of getting to grips with a new skill, whether you’re learning syntax, hand-eye movements, or whatever. I agree that I7 is successful in making this transition a little easier.