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 
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
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.
4 Likes
ZIL:
- 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.
4 Likes
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 
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
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.
4 Likes
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.
4 Likes
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.