What are Dialog’s pros & cons compared to TADS?
One potential disadvantage of Dialog is that it’s rule-based (similar to Prolog and perhaps a tiny bit to Make). It’s very different from the normal imperative programming. This can be difficult to learn, or (if you are affine to this way of thinking) it can be easy.
I was actually going to jump into that thread and talk about Dialog! I made a game with it recently. I have no TADS experience in programming, so I’ll just assume it behaves similar to a standard programming language like C or C++. I do have some experience in playing.
Dialog’s biggest benefit compared to TADS is its great integration with online play. Dialog can basically do multimedia and links really well online with little work. Offline, it doesn’t have any advantages over HTML TADS.
Another benefit of Dialog is that all of it is based on predicates, so that once you understand predicates you can do just about everything in the same way. There’s not really a need to memorize most stuff, you can just wing things.
The biggest drawback to Dialog is its lack of documentation and example texts. Few people can help you with Dialog either. Also, I personally really struggled to use basic math in Dialog like having a global number variable that went up and down. Local variables are a lot easier.
Conversation-wise, TADS has some great built-in tools for asking and telling topics. Dialog has a very sophisticated choice-based conversation system for making ‘nodes’ and connecting them and changing them.
I wrote about my experience using Dialog here:
Dialog’s biggest benefit, imo, is its elegance. Everything works the same way and it doesn’t have the decades of exceptions and special cases that Inform and TADS have accumulated. The standard library (including the parser) is a single file of standard Dialog and every aspect of it can be modified very easily.
I really wanna give Dialog a shot! But the lack of documentation makes it difficult.
Actually Dialog has a good documentation, but isn’t comparable with the extensiveness of TADS 3 and Inform 7’s documentation:
(whose is included in the Dialog release DL and can be consulted offline)
Best regards from Italy,
I have experimented with Dialog. It is very capable as mentioned above.
Just a point: it is still in beta and hasn’t been updated in quite some time. The author seems to have lost interest.
Dialog has a number of benefits, two of which I would have seen as enormous blessings while writing my interactive fiction work House. Using TADS 3, I was never able to do what I had set out to do with the work. The short version is that I wanted to create hybrid objects—objects that had traits associated with two different TADS 3 library classes. It was something that I definitely could not do out of the box, and if it was possible at all, it would have required me to rewrite a significant portion of the TADS 3 library I used. For me that would have been not only time-consuming but also more or less impossible as the library required code that never stopped being opaque to me. In my opinion Dialog succeeds in at least one of the ways Linus wanted it to: Once you know the language, you know how to rewrite the library.
Interestingly enough though, I would not have had to rewrite the Dialog standard library to do what I had wanted to do. That brings me to the other advantage of Dialog—the “thin” objects. Unlike TADS 3 objects, Dialog does not have the objects of object-oriented programming. On the practical side that means they do not come with a lot of baggage; it is usually possible (and easy!) to make an object with traits that no one ever thought to use together without resulting in unexpected problems. Do you want an object that can be used to cut things, used as a topic of conversation, and used as the node in choice-based dialog? Well, what’s stopping you? Certainly not Dialog!
This is really interesting. And here’s where I think examples come in really handy for people trying to look at code constructs between languages.
What you say here may sound intriguing to someone but they might struggle to see why it matters or how often something like this would be useful to have.
A phrase that some would cue into is “traits that no one ever thought to use together” which carries connotations of emergent style gameplay. (“Emergence” being a term often very mis-used in game design circles.)
The reason I call this out is because when someone talks about a pro or a con of TADS 3 or Dialog and if we go by your example, two questions immediately occur:
(1) Can this be done in both languages?
(2) Is it easier or harder in one or the other language?
Note how those can be parallel to “Why would I need this in the first place?”
Regarding (2), “easier or harder” is of course in the eye of the beholder, which is where specific examples would help people understand how something is implemented between languages.
I would say the same applies to an earlier comment:
Intriguing! But how does that differ from TADS 3? Or, rather, someone might ask: “Okay, but if everything in TADS is based on objects as opposed to predicates, and once I understand those objects, can’t I just do everything in the same way?”
I’ve admired Dialog from a distance but have never felt compelled to use it mainly because I never felt drawn in by the source examples I’ve seen. But the statements above intrigue me so I would be curious about how these could be turned into operationally specific examples showing what is meant.
I found the learning curve to be steep but well worth the effort. I was amazed by the power of logic programming, and to my knowledge we have yet to scratch the surface of what we as IF writers could do with it. If you will excuse me for revisiting a topic I have harped on previously, there are some impressive NPCs waiting to be born. I have thought I would write a booklet on how to code them if the interest were there.
Time has been coming at a premium lately, so I will not promise to give detailed examples. But I will say this: One of the things I remember about learning how to make emergent games is that it is good practice to code adjectives rather than nouns. In Dialog this is not just possible; it is the idiomatic way of doing things. The standard library has traits like
(sharp $) where the libraries of other languages might have a knife class and traits like
(openable $) and
(pushable $) that do what you think they do.
I’ve barely scratched the surface of TADS, so I don’t know how easy or difficult TADS makes it, but here’s something I now find myself longing for in Inform: dynamic relations.
Suppose I have a relation between objects and “positions” indicating whether you can hide in that position (under it, on top of it, behind it, etc). Inform’s good at this and makes it easy to do a bunch of convenient things with this relation, like finding the nearest object to the player that allows one specific position, in case the command was ambiguous.
Now suppose I want to say “you can hide behind the hull material iff it’s not in the Precipice”. Inform makes this incredibly difficult! Relations in Inform generally work like variables, so you can set and unset them, but you can’t have their value be universally defined by something else, only for some specific objects. (You can have their value be universally defined by something else…but only if that’s true for the relation as a whole, not just for this one object.)
Dialog makes this trivial, because these sorts of “predicates” are exactly what it’s best at.
(Someone who’s better than me at TADS, can you tell me how easy this example would be: most objects allow a specific, static subset of the positions, but for a few objects, that subset needs to be defined dynamically? From what I’ve heard, I imagine the parkour system in I Am Prey has to involve something broadly similar, though I’m still waiting for the post-comp release to play it.)
I’ll be honest, I can’t exactly tell what you’re going for in terms of a game transcript, responses to commands involved etc., but it doesn’t sound like something that would pose a problem in TADS if you knew what you were trying to arrive at… @inventor200 may have a better answer…
(By positions do you mean PC postures, or something else?)
There is a lot you can do with NestedRooms which are the basic TADS representations of sub spaces within a typical Room… putting conditions on when you can enter them (or in which postures) seems trivial…
Could you elaborate on what troubles you had? Were you trying to accomplish something that would not work by making a new class which subclasses from the two classes in question?
Something like postures. A specification might be…
Every object allows the player to hide in some subset of positions, whether that’s “none at all” for a toilet, “only on top” for a bookshelf, or “either behind, underneath, or inside” for an overturned packing crate. For most objects, this never changes in play, and the author needs to be able to specify it efficiently. It also needs to be easy (and efficient) to find things like “the nearest object that allows the underneath position”.
For some objects, though, this subset depends on the state of the world. The air vent allows the inside position only if the ladder is open and in the same location.
In Inform, this is remarkably difficult to do in an elegant way (though not impossible). In Dialog it’s trivial. I have no idea which side TADS comes down on.
The application of conditions (to most things imaginable) I would call trivial. If you’re talking about multiple hiding places in one Room, you’d have to do some kind of subclassing to create your own idea of distances between things within that room, but I don’t think it would be hard if you knew what you wanted out of it (for determining “nearest” to what, another hiding place in the same room?)
The way this is handled in TADS (Adv3Lite) (and is used for I Am Prey) is an object can be made of subcomponents that are given a specific set of tasks to handle. If no subcomponent handles the task, then the object handles it.
Subcomponents rarely get their own vocab and do not get their own descriptions; that’s handled by the object.
Subcomponents can be containers, and automatically volunteer for storage and search tasks, depending on if the subcomponent qualifies as “on”, “in”, “under”, or “behind”. There are other modes as well, but these are the primary ones.
From here, a container can also be marked as “something the player can occupy”.
In I Am Prey, I also added a check that determines if the container could hide the player from outside view. Sometimes this requires the player to put extra items in the container as camouflage.
Hopefully this answers your question; I can clarify, otherwise
First, some context that will hopefully make what follows comprehensible: The conceit behind House was that it was a new take on an old IF standby, namely the maze. The plan was that the PC, rather than navigating a physical space, would navigate a conversation, and the NPC would effectively tell the player whether they were getting “hotter” or “colder”. At some point I figured that as long as I was structuring the conversation like a maze, I could make it function as a traditional, 3D maze that I could enter during debugging. My idea was to make a room that corresponded to each conversation node and a door that corresponded to each topic used to access the “room”.
One of the things I tried was making an object that doubled as a door and a topic, a conversation node that doubled as a room, or both. I can hardly remember the details now, but whatever they were, I could not get all the parts to work.
My next idea was to generate doors and rooms at run time based on the conversation topics and nodes. If I remember correctly, I could generate the rooms and doors no problem, but I could not get the doors to actually take me anywhere.
I am sorry I cannot remember more details.
Sounds like a fun challenge. Also sounds like it could be tricky, but I have a feeling there would be a way to pull it off without rewriting the library. Sorry it didn’t work out for you! Did you ever carry your idea to completion through another route?