TADS 3, questions about converting a game over

Hey all.

I started the year working on an Inform 7 game, and even ran a quick beta test on the first part of it with some kind folks who volunteered.

Man, is Inform 7 made of awesome…but, well, when I wanted to do stuff programmatically, it’s simply not designed for it.

This isn’t meant as a “vs” comparison thing between the systems though, as great games have been made with both Inform 7 and TADS, hell even Atari BASIC.

But the ability to use multiple source files to keep things from getting hectic with one huge source file, the string handling, etc. of TADS may allow me to break past some of the blocks I ran into with the game so far. For example, I have a secret language these mysterious people left messages behind in (simple Unicode substitution cypher), and Inform doesn’t allow string manipulation, so I couldn’t write a routine to decode these with, say, a spell or some such.

So I’m pondering TADS. I am a programmer, so I’m not scared off by the syntax. Basically, I wanted to hear some opinions on pitfalls, or how many folks play TADS games, if you’ve all found it fun to develop with, and if it’s worth it in the end to move to TADS for the game in question. I notice there hasn’t been any updates to TADS in a long long time, unless I’m missing something, and no OS X version of the Workbench (and Wine is a little goofy running it for whatever reason).

So any pointers, warnings, or tips would be appreciated (and I know this is a vague post, but I’m just interested in hearing anyone’s opinions on the system before I dive in)

In Inform, there’s an extension though…

inform7.com/extensions/Luca%20G% … doc_0.html ?

More broadly, you can do string manipulation in Inform - see chapter 20 in the manual. Inform even implements regular expressions (§20.6).

TADS’s method of string manipulation is definitely more “traditional”, however. If you’re used to thinking in procedural code, TADS may be a good fit for you.

I am relatively new (and/or noob) in working with both Inform7 and TADS3 - I didn’t write anything serious, just messing around with both to see how comfortable I am with writing stuff.
Personally I reached a conclusion that I prefer TADS3 over Inform7, for multiple reasons:

  • Inform7 feels too much “magic” to me, with too few exact syntatic rules and many times I found looking up either non-intuitive or too explicit syntax that is hard to remember properly.
  • Several small things annoyed me in Inform7 - for example, I haven’t found how to customize player character by giving a different base class than a default one. (I don’t think it is possible in Inform7). In TADS3 it was trivial to do so.
  • Procedurally generating a map/NPCs/anything else in Inform7 is more difficult than in TADS3 as you cannot dynamically allocate new objects in Inform7. TADS 3 on the other hand allows dynamic object allocation and has GC that is very similar to Java/.Net

Have you seen the article the following article by Eric Eve?

brasslantern.org/writers/iftheor … andi7.html

The comparison between Inform and TADS he’s doing goes beyond the capabilities of the two systems (which are largely equivalent) and addresses how the world modelling and development cycles go with the two systems.

There is also this one by Jim Aikin:

musicwords.net/if/MovingFromI7toT3.pdf

My personal take is that if you are looking for a system that feels like a classical programming language and won’t eventually stump you with opaques constructs then TADS pretty much lives up to that promise. There is nothing black-boxish about it, as the syntax is consistent and the library code is very well documented and encourages you to look at it. (In fact, it encourages you to hack into it in a structured way via the modify mechanism in those few cases where what it provides out of the box doesn’t fulfill your needs.) If you are the sort of self-reliant person who likes to sort problems on their own and doesn’t mind wading through a large code base in order to take full advantage from it, then TADS helps you do that. (Though admittedly being able to use Workbench’s debugger helps a lot, even though it’s not critical.)

I’m not saying that Inform is opaque and will eventually stump you, mind. For one thing I don’t have experience with Inform and have no basis to make any such claim. And for another I can plainly see, from existing games, that Inform is just as capable and flexible as TADS. I’m only saying that if you do have that preference for traditional programming languages and that self-reliant mindset, then you should find that TADS won’t disappoint you.

That said, what TADS doesn’t have is

  • a smooth learning curve,
  • a large user base,
  • maximum cross platform availability.

In other words, you’ll probably need time and effort to become proficient with TADS.

Also, if a reasonably large user base is important for you (be it to have many people to turn towards for help or for the simple sense of belonging to a dynamic community), then TADS may be disappointing. That’s not to say the TADS community as it is isn’t helpful - in fact a technical question rarely gets unanswered for long on this forum - but it relies on two or three regulars as opposed to perhaps a few dozens for Inform.

Finally, TADS games are playable on narrower range of platforms than Inform, especially if you want multimedia capability: then you are pretty much limited to desktop platforms, plus web play. It is true that web play mitigates the limited availability on mobile platforms, but even so, web play for TADS requires a continuous connection to a server during play, whereas Inform games are playable offline thanks to the existence of pure-JavaScript interpreters. If maximising your audience is important to you then this may be an important consideration.

(A tangent: of course, if maximising your audience is important to the point that the lack of an offline mobile multimedia interpreter rules out TADS, then the question arises as to whether parser-based IF is the right medium in the first place. Emily Short recently made the point in no uncertain terms that parser IF is perceived as much more inaccessible than choice-based IF by many potential players:

emshort.blog/2017/05/04/mailbag … more-32431

I’m personally more worried about that than about choosing the wrong authoring system.)

(Another tangent: it’s possible that a pure-JavaScript TADS interpreter may exist someday based on Emscripten, but as of now the TADS community seems to lack the bandwidth or momentum to create one.)

My recommendation would be:

1/ if your primary goal is to create a parser game with maximum availability, then stick with Inform.

2/ if a community of a certain size is important to you, stick with Inform and leverage on the community to get past the stumbling blocks.

3/ otherwise, try out TADS for a few days. If you find TADS frustrates you significantly less than Inform then it may be worth migrating your project to TADS. After all, availability is one thing, but this only matters if your project reaches completion. For this you’ll need to sustain your motivation, and it’s important to choose a system you’ll find pleasant to work with. This is such a subjective concern though that it’ll be hard to decide without trying by yourself.

If you decide to go for TADS, then a decision to be taken early is whether to use the adv3Lite library or the classical adv3 library (as they are mutually incompatible).

The adv3 library, for all its power, has a reputation of sometimes trying to be a little too helpful, and people have found themselves struggling to deactivate features they don’t want, which may be a source of frustration in its own right. The adv3Lite library intends to address this by removing the most complex and least used features, while adding some other nice built-in features such as commands to travel to a remote location by name, among other things.

For this reason some people consider adv3Lite a better choice overall. My personal opinion is different though, as I have found adv3Lite to be less mature than adv3, and ultimately more frustrating because of that. (That’s not the author’s fault: adv3Lite has been less tested than adv3, and came into existence at a time when the TADS user base dropped significantly). The consequence is that I ended up migrating my own work-eternally-in-progress back to adv3, which I prefer. But this is only my opinion, which doesn’t seem to reflect that of the majority, so you’d do well to listen to other voices and make your own mind.

I am new to both tads and inform 7 but like the clarity of tads better. (I’m using adv3Lite)

Inform 7 is very wordy and I sometimes try wording things in different ways to get what I want. Tads is more clear and feels like programming and you follow the syntax rules so seems easier for me.

After reading about possible cross platform support for running the games almost switched back to inform 7.

However you can run tads pretty much anywhere you would want to from what I have found with my little test game. (NOTE: don’t have the debug symbols in the game you want to run on the ios interpreter as it won’t work)

IOS:
Frotz - works great.

Android:
Thunderword - the experimental version works great.
Thunderword - the beta version works but not as nice as the experimental version

Windows / Mac OS / Linux:
qTads - full multimedia support works great.
frob - works great for my games but is character based only so no multimedia but I believe it supports the full html character formatting.

I have not tested the web version of tads but it should work pretty much anywhere.

QUESTION:

Is is possible to package up a tads game into a stand alone product outside of windows for mac os and linux?

Similar to what the github.com/erkyrath/lectrote does for zcode / glux / hugo etc.

Thanks,
Anthony

I’m more than new to IF, but I have a programming background. After spotting an app for android that played interactive stories, I was very curious, because I was effectively writing my own “language” and interpreter. There is no doubt that Inform is impressive in how it parses commands, but I feels, after reading half of a coding manual 2 days ago, it was easy to see the language’s limitations, especially the length limitation. Inform compiles using their Inform6 compiler, an old c-code library with memory limitations, and Inform7 is just a wrapper for I6N that tries to eliminate those limitations. Also, loops are a mouthful. Inform has a Prolog feel to it, but it’s not an a.i. language from my understanding. But one advantage of Inform over Tads, from 2 days of research, is that Inform can better understand how to handle verbs. Perhaps I’m wrong though.

Tads has a Java-like API that is simple to understand if you have a programming background, and the syntax is easy to pick up. If you understand object-oriented programming, you understand Tads. There’s also way more online books that can be read for free. Tasks like cramming adjectives into an object (noun) is super easy in tads, whereas Inform requires more work. In fact, Inform requires a shitload more work to get the same job done. And if you don’t know every object offered in Tads because you’re new at it, you can cut time and simply write your own in less time than sifting through the library.

That is my understanding after examining the two after two days.

That’s a good summary, yes. I’m no longer actively writing IF, but I’ve written games in both T3 and I7. My suspicion is that I7 is attractive to new authors for several reasons:

  • If you’re a non-programmer, I7 looks easy (even though it’s not)!
  • If you’re a programmer and want to explore an entirely different type of syntax, it looks sexy.
  • The I7 IDE is cross-platform.
  • The adv3 library is massively complex and kinda scary. (adv3lite has some I7-like features, and is much easier to learn.)

I wouldn’t call it sexy at all. Perhaps intriguing is a better way to describe it.

One thing TADS3 could benefit from is something like Microsoft’s Intellisense. I’m not sure how to call it. Eclipse, Netbeans, and NuSphere has it too. It lists properties and methods that can be used given an object being typed. For instance, if I type “self.” in the TADS workbench, a list of everything I can use for that object would appear in a popup beside the period, and all of the documentation would appear beside each highlighted item I’m selecting from that popup list. So instead of sifting through the online API to see what I can do, it all appears at the cursor. It’s frustrating to look at the OutdoorRoom class on the online API, then having to check the methods and properties that that class inherits from Room, then Thing, and so on.

Another frustrating thing about TADS is that the parameters in methods on the API have no “type”, so I’m never sure what kind of variable type I must pass as a parameter. Technically speaking, everything goes, but that doesn’t mean an exception wouldn’t be raised within the method I’m calling. Glancing through the source code also shows me that there is no type checking. Everything is an object, just like javascript or other high-level “script” languages, which makes me wonder why hasn’t the creator of this library simply convert the code to javascript and have it run client-side rather than offering Webui; it would be more flexible. I guess TADS want to keep proprietary control, to answer my question, and I don’t blame them for that.

My guess would be, so few people are using TADS that Mike Roberts has little incentive to develop it any further. Converting everything to javascript would take months of full-time work, if not a year.

Twenty years ago, text-based games were still a somewhat exciting thing, even though the technology was already obsolete. Today, I suspect people who want to do exciting things with computers would shy away from developing text games even if they had ever heard of them.

I’ll probably get flamed for saying this, but I don’t think either TADS or Inform offers a very good development environment in the 2nd decade of the 21st century. And they’re the best choices! Other systems (Inklewriter, Undum, Quest, whatever) are even less viable. I mean, you can make a nice interactive story with any of them, but they’re not professional tools – and the reason they’re not is that there’s no money in IF.

You’ve pointed out a couple of issues – lack of type-checking in the T3 library, and some refinements that would improve Workbench. But that’s the tip of the iceberg. Workbench isn’t even cross-platform – you can run it in MacOS in a Windows emulator, but the last time I looked (several years ago) there were some minor issues in doing that. The Inform 7 “natural language” syntax is, in my personal opinion, a mess. I wrote two games in I7, so I’m entitled to an opinion, but as I lurk around on the I7 forum here and glance at coding questions, I shudder. On the TADS side, I don’t know if the WebUI has ever been properly documented; it was certainly released without documentation, I remember that.

It would be lovely if someone would put together a team to do a proper IF authoring system for the 21st century, but nobody is going to do it, first because there’s no money in it and second because the IF community is just too darn small. The areas where you can get decent free tools are where the demand is 100 or 1,000 times greater. That demand encourages public-spirited programmers to roll up their sleeves and do a decent job of creating the tools.

Mmmm. No doubt. I’m not even sure if javascript can handle “objects” the way Tads can.

I think you’re right, but I also think that with the right programming language, cough java/c# cough, people would be more interested in developing them because it would require less time to make the games.

I know what you mean. But there’s only so many ways you can describe reality through a programming language. There’s only so many ways to reinvent the wheel, and as you said, there’s no money in it. We’re a long way from Star Trek’s holodeck. “Computer, create a bikini model. Give her blue eyes and lock the arch.”

I’m not even going to touch Inform. I read some of the documentation and I was turned off instantly. Not only is the syntax mysterious, but they admit that there’s a crack under the hood and all they did was patch it. (I7 being a memory wrapper for I6).

I’ve been trying something out.

I copy all the source code from here (for instance), http://www.tads.org/t3doc/doc/libref/object/Thing.html (or this) view-source:http://www.tads.org/t3doc/doc/libref/object/Thing.html

I just created this fiddle: https://jsfiddle.net/x559g11w/43/ where I paste the source code into the html area, then I run the code. Then I copy the output onto a c# document and presto. Within a day I but I can at least get Visual Studio intellisense to help me figure out what to code.

Using a program I made a while ago, that applies a list of regexes to replace copied text with a beautified one, I end up with this.

    /// <summary>
    /// The native collection type - this is the base class for lists, vectors, and other objects that represent collections of values. intrinsic class Collection :   Object
    /// </summary>
    [Serializable()]
    public class Collection: Object {
        /// <summary>
        /// Create an iterator for the collection. This returns a new Iterator object that can be used to iterate over the values in the collection. The Iterator will use a snapshot of the collection that will never change, even if the collection is changed after the iterator is created.
        /// </summary>
        public virtual void createIterator (){ return; }
        /// <summary>
        /// Create a "live iterator" for the collection. This returns a new Iterator object that refers directly to the original collection; if the original collection changes, the iterator will reflect the changes in its iteration. As a result, the iterator is not guaranteed to visit all of the elements in the collection if the collection changes during the course of the iteration. If consistent results are required, use createIterator() instead.
        /// </summary>
        public virtual void createLiveIterator (){ return; }
    }

It could still use some work. But I’m satisfied.

Ha. The original programmer actually changes the collection as he iterates through it. :confused: Going from the top element to the first avoids the “not guaranteed to visit all of the elements” problem…

One specific thing about Inform 7 is the IDE is complete. You can write, test, debug, and release the game all from the same interface without worrying much about libraries, plugins, compilers, a text editor, etc. Extensions, which build specific types of functionality, are stored in a library at the user’s discretion and invoked easily with one line of code.

I personally am not an experienced coder/developer and get spooked easily when a system has instructions that say “now install node.js” or “run the compiler from the command line” and Inform 7 does none of this. It’s a completely self-contained system if one wants to make text adventures in the classic Infocom style. True, it’s mostly a dead art form but has a hard core niche of devotees.

I once commented that text adventure programming is like Latin: it’s not specifically used in the real world but gives the user a very solid meta-concept of how to create games.

Text adventures (choice-based and parser) is one of the few outlets that allows someone with no multimedia art/music/sound creation ability to make a game.

I know what you mean. Inform really holds user’s hands. It’s very obvious why it’s that popular.

It’s not everyone that can be both artistic and highly logical in terms of how their minds work. It’s usually either/or, and probably even more frequently, neither. https://www.youtube.com/watch?v=ocDli45faiw

The user or the programmer? There is a difference. Programmers have to treat all users as low-I.Q, mouth-breathing…err… individuals. The reason for that is to make applications as accessible as possible.

I’ll dispute that. It doesn’t take much to create a “game”. Anyone can scribe a tic-tac-toe onto a piece of paper. To create a video game, it requires programming skills. I guess Inform counts as a programming language, so congratulations, you’re a programmer. The bad news is that creating a game isn’t enough, since anyone can create bad games.

https://youtu.be/h6DtVHqyYts?t=48s

With respect to “now install node.js”, I have observed that real programmers sometimes underestimate the amount of overhead that would be required to write a game in something like javascript. Undum/Vorple gives you a great platform for beautiful-looking browser-based interactive stories, but the coding is NOT something that the average author of text adventures is likely to want to grapple with. Both Inform and TADS do a very respectable job of hiding the guts of the interactive system from the game author.

On the other hand, I wrote my first game (in 1998) in Inform 6, and yes, I ran the compiler from the command line. That’s not hard to do.

Over and over in the Inform forum here, I see people who are wanting to do things that go somewhat beyond “the classic Infocom style.” They want to add graphics or sound. They want inventory in a sidebar, and clickable navigation links, and (God help us) combat systems that tally damage points.

Me, I’m a certified geezer. I was introduced to Adventure on a Kaypro, by a guy who picked it up at a software swap meet. To me, part of the point of a text adventure is that you have to think of examining the vase on the mantel. Making the word VASE a clickable link to examine it pretty much destroys the IF experience. But that’s just me. I’m a geezer.

1 Like

My guess – and bear in mind, I’m not a real programmer, just a ham-fisted amateur – is that java or c# would be a very poor choice for IF programming. I did teach myself the rudiments of C++ once, many years ago, so I can toss out an example of what I’m talking about. To write an in-game object in C++, you would have to declare the object in a header file (including its parameters and methods) and then instantiate it later, adding data to make this instance of the object work. The compilers for I6, I7, and T3 totally eliminate that dual definition system. You declare an in-game object in only one place.

The business of sending text output to the game window – again, an IF authoring system makes that as simple as possible. In java, javascript, or C++ (and I’m sure in Python too) it gets much messier.

With respect to I7 being built on top of I6, I think you’re doing I7 a profound disservice in calling it a memory wrapper. I’m not a programmer – I don’t know what a memory wrapper is – but the point of I7 is that it presents the game author with what is, at least at a first approximation, a much more facile way to “write an interactive story” without being in any sense a programmer. The difficulty, I would say, is that this friendly appearance, so appealing to the novice, is deeply misleading. The I7 syntax is, in the end, a mess precisely because it attempts to be friendly. When the author begins by thinking, “How would I write this in English,” there are many, many ways to do it wrong. In a conventional programming language, it’s harder to get the syntax screwed up. You can see at once, “Oh, I left out a curly brace,” or whatever.

People keep posing this argument, that the natural language syntax of Inform 7 makes it hard to learn or program in, but I’ve found the opposite to be true. I found I7 easier to learn than any of the other languages I’ve dabbled in: C, C++, Python, Perl, Basic, Pascal etc.

The first stage in learning a programming language for me is by looking at other people’s working code and trying to understand how it works. The similarity of I7 to English or pseudocode is a great help here, making this easier than in any other language I’ve tried, perhaps with the exception of Applescript. Basically you can understand most of it without having to learn it.

The second stage is trying to make the language do what I want, more or less by trial and error, trying to guess the right syntax, and here again I find the similarity to English actually helps. When learning a more conventional programming language, you usually go through a lot of frustration, getting it wrong many times before getting it right, even with modern IDEs with auto-complete and syntax checking. Often it is not obvious where you, say, forgot that curly brace. I found that in I7 you actually sometimes can get it right on the first try. It is simply easier to make educated (and correct) guesses despite not having a full grasp of the language.

The flip side is that you sometimes get tripped up even when you are more proficient, and write things that are correct English but incorrect Inform 7, despite knowing better. Still, I’ve found this to be pretty rare.

In my experience, had I not found Inform 7 with its natural language syntax, I never would have gotten into creating text games like the ones I loved in my youth.

It is more naturally intuitive to me as a writer to write “Parlor is a room. A chair is a supporter in Parlor. Chair is enterable.” than it does to first have to understand how code works and needs to be laid out and learn a bunch of cryptic commands and the structure of curly braces and library databases before doing anything.

I7 meets someone used to reading and writing about 80% of the way. The last 20% can be a hurdle and consists of learning and understanding the ways that I7 code is different from English, but faulting it for that is like being the person who insists shouting louder at a non-native English speaker is more productive than learning to rephrase what they’ve said in a comprehensible manner the listener will understand.

Yes, that part is easy. But of course that’s not the whole story.

It’s the “learning to rephrase” business that’s the problem. That and finding a workable rephrase in the documentation.

And then there’s the I6 layer. It’s a built-in kludge. Bottom line (for me, anyway): If you’re satisfied to do simple, off-the-shelf things in your text game, I7 is certainly preferable to T3. But the moment you feel a need to do non-simple things, that equation turns upside down. The things you learned in writing your first simple game won’t help you when you set out to build a better mousetrap. Whereas, conversely, in T3 the things you learned will help you, because there’s only one kind of code, because the structure of that code is logical and unambiguous, and because the techniques you’ve learned apply all the way down the line.

1 Like

I wouldn’t say that the need to drop into Inform 6 really has much to do with the natural language syntax. That is more a result of missing functionality and performance problems of Inform 7.

And yet it’s done for other languages. My point is that making one for javascript would long and arduous, but then gifting it away so that others can use it freely without anything to show for it isn’t something that anyone would want to do, because we must make a living somehow. And so that is why it isn’t, or hasn’t been done.

I’m new to IF, so I’ll try to look them up. …

Uh-huh. I suppose we all are entitled to our opinions.

Yup. I7 and T3 holds your hand through it.

Yes, it’s “tougher”. But if you use javascript, the advantages is displaying shit, because it has access to HTML and CSS. In other words, the browser is doing all the displaying work. Plug in “HTML5 games” on the search bar and watch the possibilities. A good game engine is all that is needed.

http://inform7.com/learn/man/WI_2_14.html

Syntax checking is trivial using Eclipse, or Visual Studio.