The strengths and weaknesses of different IF languages

I’m sorry if this has been asked before (I couldn’t find anything quite like it here), but what would you say are the different strengths and weaknesses of different IF languages? I have seen some information on the Internet about it but nothing comprehensive other than Eric Eve’s article comparing and contrasting Inform and TADS.
It is my understanding that…

Inform is good at:

  • adaptive prose
  • handling events or acts

TADS:

  • simulations
  • NPC interactions

ALAN:

  • completely customizable parser that can range from two-word to something really sophisticated
  • easy to learn

Hugo:

  • easy to learn

How accurate is my understanding. What makes these languages good at those things? What else do they excel at? Why?

2 Likes

This is hard to answer. If Inform’s natural syntax seems natural to you (no pun intended) then it’s the easiest language to learn. But some people find it extremely unintuitive, and for them, Inform is very hard to learn. So do we call that a strength of Inform or not?

All of the mature languages have extremely customizable parsers. All of them have models for NPCs, for sequences of events, etc.

From my point of view, Inform 7’s rule-based programming model is best for large and complex games. This is because you can write general cases for game effects first, and then start specifying more specific cases, one rule at a time. You don’t wind up with bloated, fragile functions – which was my experience in older procedural languages like Inform 6. (Or Hugo, etc.)

But this is a pretty subtle advantage. It allowed me to write Hadean Lands, but you wouldn’t care when you’re learning the language or writing your first game.

4 Likes

ADRIFT is very easy. Almost everything can be done with drop-down menus. If you want to stick with traditional adventures (exploring the map, finding and manipulating objects, talking to NPCs), you can create pretty much your entire game from the map-view.
It does require the author to be very careful about creating general commands (SHOOT {anything}) and overruling those with specific commands {SHOOT GUN). If one cuts corners with this, the parser gets very wonky very fast.
If you do put in the extra effort, ADRIFT is a great low-threshold IF creation system. If you ask around on the ADRIFT-forum ( ADRIFT: Create your own Interactive Fiction) you can talk to people who can get a lot (and I mean a lot) more out of the language. This requires more coding skills and specialized libraries.

(This reminds me. I should really get back to work on The Tree (working title). It’s been sitting on my computer for months now…)

EDIT: A very annoying problem is that the ADRIFT downloadable package does not get along with a lot of computer protection programs. You have to declare the files to be safe and/or retrieve them out of quarantine manually.

1 Like

Thanks for the replies thus far! I suppose I should clarify, though, that even though I have limited experience writing IF, I’m not exactly a newbie. I have used TADS 2 in the past. I am interested in branching out since a lot has changed since the heyday of TADS 2, and, hey, maybe I’ll get some ideas for my own language if I ever decide one day to write one (even if only as a hobby).

In regards to what I’m alluding to, here are some quotes from other people:

TADS 3 has by far the best support for NPC handling, when I7 has by far the best support for act-based IF and an excellent handling of adaptive prose (said handling even got implemented in TADS3.1.x), and ALAN has the maximum flexibility in parser definition (from verb-noun to a sophisticated one) and together with Hugo, are the easiest to code. TADS 2 and Inform 6 are very flexible and have a large contribuition library, and are the twin foundation stones of IF programming. IMO, a serious IF coder must know both as their hands. Lastly, Dialog is the “black horse”, based on goal-orienting general-use language (Prolog), and I think that a goal-oriented language can be be an interesting innovation in IF coding.
So does TADS 3 have "by far the best support for NPC handling"? How so? Does Inform 7 have "by far the best support for act-based IF and an excellent handling of adaptive prose"? How so? Does ALAN have "the maximum flexibility in parser definition (from verb-noun to a sophisticated one)"? How so?

Eric Eve writes:

Multiple inheritance and the encapsulation of code and data clearly enable programming strategies that can be pursued readily in TADS 3 but only with difficulty in Inform 7 — this is one barrier I've found to providing an Inform 7 version of the TADS conversation system I'm really happy with.
Is TADS's conversation system so much better than Inform's? How so?

These are just some things I’ve come across and which I’m providing for some context.

IMO, the advantages and disadvantages of the various languages aren’t nearly as important as the platforms each language supports.

AFAIK there’s no way at all to play ALAN, Hugo, or ADRIFT games on mobile iOS. You can use iFrotz for iOS to play games in Inform, TADS, Dialog, and ZIL.

EDIT: @tayruh pointed out that Fabularium can play ALAN, Hugo, and ADRIFT games.

Furthermore, Inform has a feature that isn’t conveniently available for TADS, ALAN, or Hugo: you can play Inform games on the web, without requiring an interpreter. As a result, you can play Inform games on any device with a browser, just by clicking the link.

(TADS 3.1 has (had?) a “Web UI” mode, but it never worked well, because it required the browser to do a network request every time you type a command, so it worked very slowly, and, worse, AFAIK, all of the servers that used to run Web UI games are now down, so Web UI doesn’t work at all now.)

4 Likes

That’s not actually true. Fabularium supports all three. Its Adrift support is really poor though.

For Adrift it has two interpreters — Bebek and Scare — and you swap between them by editing the config file, which is obviously a pain. Scare is the better interpreter but doesn’t support Adrift 5.

2 Likes

Of course the answer is, it depends.

It depends on the mental model you have for the piece of work.

Do you want to present an essentially linear narrative, but allowing freedom for exploration of side narratives?
Or do you have in mind something more location-based, where objects are important, and the story reveals itself through puzzles?

The best language/framework/runtime will be the one with the lowest impedance to your mental model.

4 Likes

Could you tell me which languages are best for which mental models?

2 Likes

It’s maybe worth pointing out, too, that there are many systems that don’t work, or don’t work well, on macOS and Linux. ADRIFT isn’t just not mobile friendly; it’s essentially Windows-only. (There an ADRIFT runner that’s supposed to work on other OSes, but I’ve never got it working under Linux; and the web interface is theoretically plausible, but seems to slow to a crawl before I can finish a game.) Quest seems to be the same way. It’s been a long time since I tried to get the ALAN runner going on Linux, but I never did it before, and the current website goes straight to a 404 page when I try to download it. There’s Hugor, which works fine under Linux, but it’s less configurable than the 'terps I generally play other games with, and having to install yet another 'terp that I can’t configure instead of just opening up Gargoyle to run whatever I want makes Hugo just a little bit of a second-class language for me. (Though I’ve played and enjoyed Hugo games on Hugor under Linux too, to be fair.)

2 Likes

I’d very much like to, but then we’d have to agree on a taxonomy of interactive fiction.
I am fairly new here and not the person to help with that very much :wink:

Barely.

As @Rovarsson pointed out, it has some serious issues with modern windows. The author pretty much abandoned the project at this point and it really needs to be updated.

Third party support is also difficult because unlike other systems that embed the engine logic into the game file and just read op codes for output, Adrift puts all of its engine code into the player, because the player is also the editor. It makes for a very fragile environment and difficult to port to other languages because you basically have to rewrite the entire engine and game library. And of course it’s written in VisualBasic of all things.

1 Like

There are still people putting a lot of good work into making ADRIFT better. @Denk is one of them. To my knowledge, they are mostly improving the library though, not updating the core of the language. I doubt the program is open for outsiders to work on at this point in time.

I must add that personally, I love writing in ADRIFT. The drop-down menus make it a tangible and intuitive experience, the write-from-the-map approach is very rewarding and the ease of creating alternative descriptions for changing gamestates invites creative writing.

2 Likes

How is the “write-from-the-map approach” very rewarding? How is it easier to create alternative descriptions for changing game states?

Don’t get me wrong: Adrift is a really cool authoring system. It’s like the love child of TADS, Twine (web UI) and RPG Maker. I’m just griping over the fact that the internal design wasn’t very future proof.

1 Like

You have your map-grid in front of you. Double-click to create location, click on location to pop up location window, create everything in or about that location (objects, NPCs and all their commands and tasks) with drop-down menus within the location window. Click and drag to make pathways to other locations. Repeat a few times and you’re good to go.

Click bottom of description window to create alternative description. Use drop-down menu to select conditions under which alternative description should be shown to player.

Make that two of us.

1 Like

Thanks! I don’t think I’ll use ADRIFT, but that is the sort of detailed reply I was looking for!

2 Likes

Speaking as a creator, I think there’s merit in using simpler systems such as Twine or even ScottKit. I can quickly implement the design using Examine, Go, Take, Drop, Use, and Combine. That may not be too sophisticated for experienced users, but it allows quick prototyping my games. As a plus, Scott Adams system is simple enough that I can hard code it using any coding platform, including old style BASIC, if need be.

Another consideration for such simpler system is the user interface. What if you want the simplicity of web interface without typing? It’s possible with DIALOG, as the Bottle adventure game proved. Sorry I forgot the complete name by Linus. Anyway, if you look at SA datafile, then it’s a simple table listing of matches, conditionals, and actions. That’s all. Which means, assuming that you don’t mind writing your own routines, you can output a list of commands that matches all conditions, negating the dreaded “You can’t do that yet” type of response. Since it’s also limited to Verb-Noun construct, you can also present it as click Verb , click Noun type of game, which is similar to “Mickey’s Space Adventure” game.

In other words, with proper UI implementation (and this includes Web UI), you can have a game presents the UI progressing from Troll Tales to Mickey’s Space Adventure to Pirate Adventure (Choice, P&C, Parser) all in one game, differing only by the method the interpreter executes the code. You don’t need to change the game data at all!

Linus mentioned it in his postmortem of his game that having multiple interface options allows people to graduate from PnC to Parser, a gentle way for beginner to get used to the rich parser input possibilities. I wonder if this is something that interests people, or does this strictly belong to the experimental IF genre?

Edit: Name of game is The Impossible Bottle.

3 Likes

I meant to also say …

My impression is that TADS makes writing conversations easy out of the box, and it’s harder in Inform. (I have only played a little bit with TADS, though, and I’m currently writing a large first project in Inform 7.) TADS made some elementary decisions on the behalf of the author that makes it easier to get started, but that have to be walked back if the author wants to set up a system other than ASK/TELL along the lines envisoned by the system itself; whereas Inform 7 makes fewer basic decisions in this regard than TADS does, but that means more work for individual authors setting up the basic mechanics (or selecting an extension).

As I say, I’ve worked very little in TADS, but I’ve seen a lot of people saying essentially that on this forum and in other places.

On the other hand, there are several different conversation systems available for Inform as extensions, and if you want TADS-style conversation-writing in Inform, Eric Eve’s Conversation Package will give it to you so you don’t have to set it up from scratch.

1 Like
Another consideration for such simpler system is the user interface... if you look at SA datafile, then it’s a simple table listing of matches, conditionals, and actions. That’s all... with proper UI implementation... you can have a game [that] presents the UI progressing from Troll Tales to Mickey’s Space Adventure to Pirate Adventure (Choice, P&C, Parser) all in one game, differing only by the method the interpreter executes the code. You don’t need to change the game data at all!
Interesting! It sounds a lot like the Model-View-Controller (MVC) scheme long used by programmers!
1 Like

Ah! That makes sense! The article I quoted from by Eric Eve actually gives me the impression that Inform 7 is like ordering a meal a la carte whereas TADS 3 is more like a Swiss Army knife. But Inform 7 also seems to be bare bones whereas TADS 3 can suffer from a lack of cohesion.

1 Like