The strengths and weaknesses of different IF languages

To add a bit to Patrick’s answer – as far as I know, these are some of the features:

  • you can use it to implement a hybrid ASK/TELL system with topic suggestions:

“(You could ask Charlie about Dave, or tell him about Edgar.)”

  • the topics can also be used to model PC knowledge (and extended for NPCs)
  • it supports forms of greetings and goodbyes, making conversations more natural
  • NPCs can initiate conversations
  • NPCs can continue talking to the PC, even if the PC is doing something else in the middle of the conversation
  • the system has a notion of “nodes” which lend structure to the conversation, affecting the topics which are available at certain points
  • you can define one-off commands which are only valid at particular nodes:

“(You could sigh, shake your head, or accuse him of lying.)”

You can dive into the details in the TADS 3 Technical Manual, “Programming Conversations with NPCs”.

Quoting from the summary there (click to expand):

“The ActorState class helps structure the code for actors that can exhibit several different behaviors; TopicEntry and related classes let you build a database of knowledge for your characters, and help manage the database as character knowledge and game conditions change; ConversationReadyState and InConversationState help give interactions the form of real conversations; ConvNode lets you create internal context and structure within a conversation; and SpecialTopic lets you go beyond ASK/TELL when conversations require more nuance.”

The rationale for this is described in “Choosing a Conversation System”.

As Patrick said, Eric implemented a similar conversation system for Inform 7, cf. this directory at the I7 extensions github repo. Another possibility is to use “Threaded Conversation” by Chris Conley.



  • If you master it, you are the King of IF Nerds and receive mandatory tithes of nerd lunch money.
  • If you try and fail, however, all the other nerds beat you up and take your lunch money.

Or you could just try Adventuron.


Hi hi hi… you can play Adrift v3 and v4, AdvSys, AGT, Glulx, Level 9, Magnegitc Scrolls, Scott Adams, TADS and Z-machine interactive pieces on Ubuntu Touch (mobile and table… far soon on computers)
Sorry :wink:

1 Like

The source code for ADRIFT was made public back in 2018, I believe.

AFAIK you need a professional version of Visual Studio and possibly a commercial third party library to compile it though.

An official update (5.0.36) was released in August 2020, so the software isn’t dead yet.

1 Like

I can’t judge whether it has the best support, especially since at least TADS 3 also has these capabilites. But here are some concrete points:

“act-based IF”

This might refer to Inform’s action handling rules, and/or to its Scenes mechanism (if we understand “act” in a theatrical sense).

Action handling

Inform gives you a lot of possibilities to modify when and how actions take place. Specifically, the Before, Instead, Check, Carry Out, After, and Report rules allow you to hook into the process at various stages and fine-tune everything.

See chapters 12.2 How actions are processed and 12.21 Guidelines on how to write rules about actions in the docs for a short overview.

You can also differentiate further by making some rules more specific than others, as zarf already said above (for example, restricting them to a class of things, or to a Scene, see below).

A slight drawback is that it can sometimes become a bit difficult to sort out what exactly you need to do in order to get a certain desired behaviour, when you have a big pile of rules which might apply in any given situation.

Two simple examples for illustration: (click to expand)

You might use an “Instead of jumping” rule to quickly override some default behaviour, but you have to keep in mind that this means that the action did not actually take place, as far as Inform is concerned (because we have done something else instead). So later checks for “If we have jumped” will turn out false, which might not be what you intended.

Or you might use a Carry Out rule to customize what an action does, and then find out that the Standard Rules have a Report rule which tacks on a message that’s incongruent with what you just implemented.

But of course, you can solve these problems by studying the documentation and the examples and by using the RULES and ACTIONS testing/debugging commands.

And arguably, drawbacks like these are hard to avoid in any system of a certain power and complexity. For example, in TADS 3, you might use multiple inheritance to give a subclass the characteristics of more than one parent class. When you then call a method which could theoretically be inherited from several parent classes, you need to understand which method will actually be executed by TADS. For details, see “The Object Inheritance Model” in the T3 System Manual, “Multiple Inheritance” in the T3 Technical Manual, and the WP article on the “diamond problem” of multiple inheritance.


Scenes are a way to organize plot events and other goings-on in time. Basically, they are global flags which you can check in order to make rules conditional on them. For example, you could define a scene called “the Apocalypse” and write “Every turn during the Apocalypse: [...]”.

Scenes can also have properties:
A scene can be dangerous or relaxed. The Car Chase is a dangerous scene. The Apocalypse is a dangerous scene. The Beach Party is a relaxed scene.
And then you can define stuff conditional on whether “a dangerous scene is happening”, for example you could forbid the player to WAIT or to otherwise waste time.

By the way, note that there is a known bug (Reports here and here):
Contrary to what the manual says, the syntax “... during a dangerous scene” does not work (while the same syntax does work for referring directly to a scene, as in “during the Apocalypse”). The workaround is to use:
when a dangerous scene is happening”.

Scenes can also end in various ways, see chapter 10.8.

In the end, that’s nothing that you couldn’t implement in other ways in different systems, but it’s nice to have the functionality & the “scaffolding” already built in.

For TADS 3, see Eric Eve’s scenes.t.


Yes, it seems to be the old problem of flexibility vs. cohesion. Inform 7 offers the flexibility of lists and tables while TADS offers the cohesion of encapsulation. Apparently, the former can lead to a piecemeal approach, though, while the latter can to the problem of trying include just a banana, only to get the gorilla holding the banana and the entire jungle the gorilla is in because the jungle is the implicit environment that the banana and the gorilla are attached to.

Perhaps the ideal approach would be something that offers

  • Something which resembles prototype-based object-oriented programming for the “meat” of the source code but which also allows for Inform-style rules because the whole thing is ultimately transformed into a list, tree, or table at compile time
  • Something like Prolog for figuring out non-trivial goals like parsing and path finding
  • Separate files or modules for the “controller” (whether choice-based, point-and-click, parser-based, or even some combination of all three, or something else entirely), the model (the “meat” or “heart” of the program’s internal logic), and the view (which could be handled by something like HTML and CSS).
1 Like

I know that it was mentioned earlier, but did you get to check out Dialog yet? It’s based on the same concepts as prolog (hence the name).

There haven’t been a ton of games made in it because it’s still fairly new (only a few years old) but it’s really complete. I think it’ll eventually become the third in the “big three” languages instead of Inform and TADS being the big two. It also compiles to zcode so it runs in any interpreter that runs Inform, along with having its own browser implementation that handles clickable links.

Dialog site


Wow! That look great! Since it’s still in development, I should get in touch with that Linus Akesson fellow at some! I am a little concerned an ENTIRE language resembling Prolog might suffer from performance problems, though.

You’d think, but people have been running dialog games on C64s. Maybe it’s okay because it compiles to zcode? I’m not sure, but it seems to be really optimized.

Come to think of it, if I’m going to use a mixed-language analogy for IF scripting language, it would be like this:

  • CSS or Prolog for the controller
  • Javascript for the protoypes/classes and objects in the model
  • SQL for the rules in the model
  • CSS and HTML for the view

I see. Would you say it has the same drawbacks as Inform 7, though? (Namely, the ad-hoc, piecemeal approach Inform seems to promote.)

I’d say yes. But depending on your angle, it’s not actually a drawback.

Now, keep in mind that I haven’t actually made anything with dialog (I prefer to make CYOA style games), so take what I say with a grain of salt, but I’ve read the manual and lurked on the dialog subforum quite a bit.

Anyway, Dialog doesn’t have an object model. It’s not an object oriented language. The objects act the way they do because they’re the result of a bunch of global rules that manipulate the game logic to give the appearance of objects. So it’s even more adhock than Inform 7 which still has an object and class system alongside its rules.

This could be considered a drawback, but it can also be considered a benefit. I’m not good enough in dialog to give you any examples, sadly, but it can be used in some really powerful ways that would be difficult to implement in other languages.

Linus actually posted a side-by-side source code comparison of Inform 7 vs Dialog online if you’d like to check it out. Maybe you can infer the differences.

Craverly Heights comparison


Linus has written several fairly large and complex stories including The Impossible Bottle as mentioned earlier, none of them have exhibited any performance issues.

(A lot of the performance advantages come when Dialog is compiled to the new native Å-machine format. Dialog-to-z-code games aren’t slow compared to Inform 7, but they’re “not fast” for 20th century devices.)


I’ll make a point to check out The Impossible Bottle then.

I can’t second this highly enough; I discovered Dialog a couple of weeks ago, and completely fell in love with it. It’s really a joy to program in, right down to being able to write unit tests in the language itself, and you get a lot of the things I spent a lot of time in past decades implementing in other languages right out of the box.


I’m hosting some Hugo games made by myself and others here: - it uses the HugoJS interpreter. =)


well, first problem, English isn’t my mothertongue, so the wording perhaps is not precisely great (the lone WIP whose actually reached closed beta status (for an IFComp) gives encouraging results, though). I remember the effort in rendering the Italian “di gran lunga” in the english “by far”, and that I actually was not convinced of the quality of the xlation.

On the “How so”, in the TADS 3 case, many merits lies in the library, with the plethora of functions available for NPC handling, supported by one of the best documentation in the IF environment (albeit not 100% synced with the compiler and library)

In Inform 7’s case, I admittely leaved it somewhat behind in my IF messing/coding, mainly because of the known issues under Linux, but I fooled around enough for reckoning the value of the scene handling and the adaptive prose (I fiddle with concepts similiar to First things First, being an historian…)

In ALAN’s case, the flexibility was a strength and a weakness together, because there’s not much of core/standard library (especially for ALAN 2.x), but if you want a non-conventional structure of the world and/or parser, perhaps ALAN can be the best choice.

Hope to have explained better my thinking; if something is not clear, if not even murky, please ask.

Best regards from Italy,
dott. Piergiorgio.

well, first problem, English isn’t my mothertongue
Then maybe I can help out a bit here. Using some translation software and examining each word individually, it seems that a literal translation of “di gran lunga” would be "of great length". So "by far" would most likely be the most accurate translation that in English.

I’ll paraphrase as best I can:

As for how in TADS 3 has by far the best support for NPC handling, the answer lies in the library, with its plethora of functions for NPC handling and its outstanding documentation in the integrated development environment (IDE) (though it's not 100% synced with the compiler and library).
Yes, Patrick Mooney mentioned how TADS, out of the box, makes some elementary decisions on the behalf of the author, and that makes it easier to get started, but also that has to be walked back if the author wants to set up a system other than ASK/TELL along the lines envisioned by the system's creator.

OK, I think what you’re trying to say here is:

In Inform 7’s case, I admittedly stopped using it because of my tendency to write messy code in it. [Something to do with Linux? I had a little trouble understanding you here.] But I still fooled around with it long enough to see how good it is at handling scenes and how good its adaptive prose is. (Being a historian, I approach things first by fiddling around with them to see what makes them tick.)
OK, so what makes it so good at handling scenes? Could you tell me more about its adaptive prose?


In ALAN’s case, the flexibility was both a strength and a weakness because there’s not much of core/standard library (especially for ALAN 2.x), but if you want an unconventional structure of the world and/or parser, perhaps ALAN can be the best choice.
OK, so how does the paucity of a standard library make ALAN's parser's flexibility both a strength and a weakness?