The aesthetics of IF languages

I don’t intend to get into a(nother) flamewar with Steve Breslin, but he’s said some false things about me recently, and some provocatively semi-true ones about IF languages and the state of IF discourse. Though what follows starts out with some newsgroup politics, it winds up as some more general stuff about language design and what I consider the strengths and weaknesses of Inform.

Breslin has recently launched an argument that I, personally, have stifled productive discussion on the newsgroups by failing to control my “supporters” who attacked those criticizing Inform 7. I am thus responsible for a decline in exciting developments in IF, first because I have promoted a stunted development system and second because I have systematically silenced all those who would protest.

This is (perhaps unsurprisingly) not how I remember things happening. First, I have no “supporters”; the newsgroup is anarchical, there is no power hierarchy, and I have no power to control anyone. I don’t want the job, and no one wants to be controlled by me, so this works out nicely.

Second, lots of people have offered criticism of Inform 7; the one who has chiefly been attacked in personal terms is Breslin himself, and this I think is a reaction to his own tendency to introduce personal insults into some of his discussions. While I think it is childish to use “he started it!” as an excuse, and I don’t condone people posting nasty things about him, I haven’t really seen that as relevant to I7/TADS 3 discussion; only to interpersonal reactions. These things are impossible to tidy up from the outside. One can only wait them out, perhaps guiltily chuckling if one side or another says something witty, but for the most part feeling a sense of growing irritation and distress at the waste of time and community goodwill.

There have been some people — especially early on — who felt that they “couldn’t” say anything critical about Inform 7 because it would be perceived as part of Breslin’s flamewar. (Multiple people told me this on multiple occasions.) I think that effect is happening somewhat less now, and there have been some enlightening critical discussions about what does and doesn’t work in Inform 7. The more practical of these we have tried to take as guidance for future improvements; the more theoretical are harder to address, but that doesn’t make them invalid.

Anyway, to a couple of specific points. Breslin wrote:

On Oct 23, 12:29 pm, steve.bres…@gmail.com wrote:
> Thanks. Chasing down another reference… In that post, the thread
> which Emily maligned as
>
> >the GRR RAR WHAT GOES ON WITH I7??? thread
>
> is probably:
>
> http://groups.google.com/group/rec.arts.int-fiction/browse_frm/thread…

This is false, as a comparison of the date stamps will make clear: I am referring to something that started before the “deathmatch” thread, not two days afterward, as Steve’s linked thread does. The thread I was referring to was this one, in which the private beta cycle of I7 was framed as a sign of malice, cliquishness and ego on the part of the people working on it.

> (“GRR RAR” etc. [complete with all-caps] is another wild and hostile
> mischaracterization, coming from the same place as “steel-cage
> deathmatch”)

It’s possible, I suppose, to read these comments in this way, if one doesn’t pick up my intended tone (and perhaps I didn’t convey it well). In both cases, I was trying to make light of some hostile discussion in order to get past it to something a bit healthier.

In the case of the “deathmatch” comment, this is because, from the earliest discussion of I7, Steve had a tendency to take positive or even neutral remarks about Inform 7 as a slam against TADS 3; in this particular thread (to pick only one of numerous examples) he sees Graham’s desire to have a manual ready when I7 goes into public beta as an attack on TADS 3 for *not* having a manual at the same point in its development cycle. I didn’t think this was a particularly productive mode of discussing either language, and said so, a number of times.

This should not be confused with a desire to silence critique or discussion in general.

I do not at all regard TADS 3’s creators as my antagonists — in fact I have the greatest respect for MJR (as its creator) and Eric Eve (as its chief tutorial writer and documenter). I also believe that, yes, the language provided does affect the kind of output produced — not only through what it is or isn’t capable of, but also (though more subtly) through the rhetoric surrounding its presentation; the assumptions that are built into the library and documentation about what is necessary to a piece of IF; and the community discourse that springs up around it.

It is possible that a thoughtful critique of those features of both languages will, in fact, lead to the conclusion that one is better than the other in certain circumstances — or even in most circumstances — that is to say, a value judgment may eventually enter in. I am willing to entertain the possibility.

I am not kept awake nights by the fear that someone will do a theoretical proof conclusively showing Inform 7 to have been a waste of time, though: too much interesting work has already come out of it.

That includes, in fact, exactly the kind of work that Breslin claims needs to be done: Stephen Granade’s “Child’s Play”, for instance, has some of the most successfully-incorporated goal-seeking AI I’ve seen in IF. For that matter, “When in Rome 2” and “Glass” are early I7 examples on my part that explore goal-seeking as well, and even “Bronze” uses some limited AI to work out how to give puzzle advice to the player. Aaron Reed has done some more work along the same lines with his extension for puzzle hinting. Other I7 authors have expressed a strong interest in more intelligently (and procedurally) arranged text, taking into account player knowledge and the progression of the narrative, or aesthetic principles; “Room Description Control” is an attempt to provide some tools for that in describing places, and there has been a good bit of other discussion on and off about how to achieve narratively-compelling prose effects.

What I don’t quite understand is why Breslin either ignores or dismisses these examples, since they would seem to be more or less in line with the increasing procedural sophistication he’s asking for.

The one I7 AI piece he has expressed interest in is “Mystery House Possessed” — a game I released before the public beta, which was written so early on that it had to invent its own pathfinding because I7 didn’t have any built in yet. (I had help writing the pathfinding routine, which is good, because I doubt I could have optimized it myself.) As an effort, it’s pretty darned rough around the edges; there wasn’t time for as much testing as I would have liked (and skipping the deadline was, for once, not an option); it doesn’t entirely work as a story, and as a game I am not sure it is fairly designed. At the beginning of each game, a murderer is selected at random from among the other characters, who goes around killing off victims and leaving clues about. With enough plays of the game, you can start to recognize the kinds of clues that get left and, perhaps, identify the culprit fast enough to kill him before he strikes too many times. But it’s clunky; it’s too often too obvious that there’s goal-seeking going on, and too obvious how it’s working. Though NPC movements are collated together into paragraph-like reports, the formulaic repetition makes the code pattern visible under the surface.

By contrast, in “Child’s Play”, it’s far harder to tell from the outside which pieces of NPC behavior are scripted and which are the result of goal-seeking code. All the player can really tell is that the other babies react to the player’s actions in uncannily appropriate ways, with varying and charming prose. The goal-seeking makes it robust, without making it tedious to read. To my mind, that is a triumph.

But perhaps there is an aesthetic angle from which that is not a positive development. In fact, Breslin himself has said elsewhere:

Artificiality is not a weakness to be minimized, but a strength, a necessity — indeed it’s what makes the whole project worthwhile and enjoyable. People won’t play “the party” because it’s fun to go to parties, but because (let us hope, anyway) it’s fun to go to artificial parties. — Grand Text Auto

and also, in praise of my early work

Short always strongly foregrounds the program. The mechanism isn’t a means to an end, but the inspiration itself. — also Grand Text Auto

(For what it’s worth, he completely misunderstands the internals of Mystery House Possessed in his subsequent discussion: it was the most process-intensive and completely-simulated thing I’d ever written at the time.)

But leaving aside the mischaracterization, what is attractive to him about “Mystery House Possessed” is perhaps exactly what I consider its weakness: the raw quality, the obvious artificiality, the narrative jerkiness. From my point of view it was only a step along the way towards something potentially much better. From that perspective, the fact that “Glass” (say) moves procedurally towards conversational goals is neither interesting or valuable, because of the effort that has gone into making that movement smooth. It uses simulation techniques to produce a more robust, more flexible behavior behind output that still looks hand-crafted. It is therefore not approachable as a mechanism to be toyed with in the same way.

If that is really the source of Breslin’s objection, then I think I can see better than before why he might find Inform 7 contrary to his purposes.

The question is only partly one of procedural efficacy: while I7 is not as general-purpose a programming language as TADS 3, it is sophisticated enough to handle various procedural advances. In fact, the possibility of using it for mild AI was very much in my mind when I wrote my parts of the documentation. This is why some of the most longwinded and, I suspect, little-used examples are in there: I wanted to offer a sort of sketch of how someone might go about writing some goal-seeking behavior, or an intelligently adaptive hint system, or maybe even a plot manager (though that example doesn’t go very far). I hoped that authors would see possibilities and experiment in those directions.

But the natural language surface of Inform 7, and the book metaphor in the IDE, and all of the trappings that accompany it, do seem strongly to say “you are making a story, not a mechanical toy”. That was deliberate. I think it may be productive in some ways; I suspect it may have problems in others. But it almost certainly does promote a set of aesthetic values directly at odds with the ones that Breslin prefers. While I7 does not (in my experience) preclude procedural simulation, its library encourages the author to focus his procedural efforts where they are needed for the interaction of the game.

That is obviously not the only way to approach IF; and that fact is why it is so important for us to have multiple, thriving IF languages.

Moreover, there are cases (as Jeff Nyman attests) where I7 is perhaps not yet (or not ever? but I prefer to think not yet) flexible enough to handle the ambitions of the narratively-minded author. He particularly cites the ability to interfere with UNDO output: not impossible in I7, I think, but it would take some hacking. There may be other points, which I hope he will share in due course.

I have a few items on my own list. To my mind, the biggest indictment of I7’s procedural capabilities is the “Noisy Cricket” example, in which mixtures of liquids are analyzed using linear algebra to determine which recipe most closely approximates the contents of the container, regardless of the total amount of liquid currently measured out. It also works out in what respect the mixture most *deviates* from the recipe, so that it can say things like “minty grasshopper”, where a smaller mint component would make the drink more like a typical grasshopper.

It’s possible to do this for a small number of components, but the difficulty of juggling table entries, and the absence of floating point math, make it ugly source and limited in practice. One of my private goals has always been the ability to recode Noisy Cricket cleanly and easily in native I7. We have occasionally talked about working more on I7’s handling of math, and that remains on the table; so I hope that any tackling of that problem would take us in the right direction.

If the example of liquid-mixing seems too narratively bleak to be compelling, consider that a similar kind of math could be used to take a number of different mood vectors (annoyance, excitement, lust, whatever) and find the specific emotional state that best conveyed that mixture of moods.

But the reason I’m interested in doing all that is because I think it’s important in translating abstract numerical information back into something that looks like hand-tailored text. You take a bunch of numbers — too many to efficiently look up in a table in a conventional sense — and reduce them to a much smaller set of predefined nodes; and then you use that information to build output for the player. The numbers are useful because they allow incremental adjustments (action X makes your aunt Lucy 1 point angrier) to be effectively incorporated into larger state (she’s somewhat angry but also much too worried about the car accident to react much) without requiring such large steps as one gets from a “mood maze” or simple state machine. In essence, what I’m talking about is using a Chris Crawford-esque approach to numerical modeling of character state, but adding a layer to turn that data back into something qualitative before attempting to use it in a story context. So what I created with such mechanics would probably still be very far from the fascinating toy machine that Breslin considers the ideal future of IF.

I’ve put all this down here not to take a prolonged swipe at Steve Breslin. On the contrary, I often want to engage his ideas (or at least some of them) but have not had a great deal of success discussing them with him directly. Whoever is at fault for that, he’s right: critical discussion about these languages is not as rich as it could be. I agree with him that that is at least partly due to the rhetorical spin added by some members of the discussion. I (predictably) disagree with him about where that rhetorical spin entered the system.

But if he is sincere about wishing that I would make a statement in favor of more extensive, thoughtful, and civil critique of IF languages — well, I just did.

27 thoughts on “The aesthetics of IF languages”

  1. I think sometimes we are too focused on doing things that are “computationally interesting” as opposed to things that lead to a compelling story.

    In your examples about goal-seeking behavior in IF, you mentioned Child’s Play, and said: “it’s far harder to tell from the outside which pieces of NPC behavior are scripted and which are the result of goal-seeking code. All the player can really tell is that the other babies react to the player’s actions in uncannily appropriate ways, with varying and charming prose.”

    I would submit that from the perspective of the player it really shouldn’t matter what is scripted and what is procedurally generated. Perhaps the player doesn’t even understand the distinction, and that’s fine. I’m currently in the midst of coding a seemingly never-ending IF epic, and when I played Child’s Play I thought not at all about the nature of the coding behind it. I was approaching it as a reader / player, not a programmer. From the perspective of a player, it really shouldn’t matter whether the author hand-crafted every event or whether the story is made up on the spot by an artificial intelligence that makes HAL look like a cretin. What matters is her experience of the story.

    I would like to see more authors start with a great story they want to tell, and then figure out what coding techniques they need to use to successfully tell it. Too often for my taste, authors seem to start with a technique and cobble together a story to make use of it.

    Take something like Mystery House Possessed: it is indeed very impressive from a technical point of view, more impressive than you (in your usual modest way) let on. Yet… would you be more interested in a procedural masterpiece that randomly generates a situation and builds an acceptable narrative arc from it every time you play? Or would you rather have a game that tells just one set story each time? — BUT said story is far better than just acceptable. In fact, it’s absolutely compelling.

    I would choose the latter, a fact which I’m sure surprises no one at this point. I suspect that many others would find the former more interesting. No one is right or wrong, but I think this may illustrate some of the divide in approaches to modern IF.

    When I used to read his posts, Mr. Breslin never struck me as being, shall we say, the literary type. (His complete misreadings of various attempts at subtlety and irony illustrated that literary nuance is not exactly his strong suit.) I would thus place him the opposite group from me, and think this may explain some of the disconnect. Do we approach IF as a technical toy, or as a literary toy?

    Of course, very few approach the form as strictly one or the other. And the two camps can feed off one another: technical developments and proof of concept games can lead to compelling storytelling experiences that make use of these new technical tools. And most of us, myself included, have enjoyed plenty of almost story-less puzzle boxes over the years.

    But still, I think that the future of the form, if it has one outside this small insular community, lies in telling better stories. Technical advances like the procedural techniques you mentioned can help with that, but I don’t think our tools are the main thing holding us back anymore. (Which is itself a tribute to BOTH TADS 3 and Inform 7 — a few years ago I don’t think I would have felt comfortable making this statement.) I am particularly excited by Inform 7 because it does seem to invite its authors to approach their works as narrative experiences rather than technical demonstrations or ludic challenges.

    That said, TADS 3 boggles my mind with its powers, but I have to note that I’m not sure anyone other than Mr. Roberts and Mr. Eve have ever really taken advantage of all the system has to offer. There’s a real technical barrier to entry there that doesn’t seem to exist with Inform 7. And I think that accessibility DOES matter if we want to attract more and better WRITERS and STORY DESIGNERS (as opposed to programmers) to the form. I’m sure it’s possible to do things — useful things — in TADS 3 that are currently impossible in Inform 7. For authors who are comfortable with TADS 3, that’s great. I’m thrilled it’s out there. But a powerful system is not valuable if no one is making use of that power. And it seems to me that very few are utilizing TADS 3 to its potential. I don’t think that situation would be any different if Inform 7 had never been created.

    Thus, it seems to me this idea that the community’s slavish embrace of Inform 7 is holding it back from advancing the form is really quite absurd. (This is the gist of Breslin’s argument as I understand it.) If Inform 7 didn’t exist, I don’t think we’d have a hugely greater number of TADS 3 games, and no more interesting (from a literary OR technical standpoint) games as a whole than we do right now. Actually, I’d say we’d have significantly less.

  2. Yet… would you be more interested in a procedural masterpiece that randomly generates a situation and builds an acceptable narrative arc from it every time you play? Or would you rather have a game that tells just one set story each time? — BUT said story is far better than just acceptable. In fact, it’s absolutely compelling.

    Well, er, I would be fascinated by both, really, but of course I take your point. In any case I think there may be another outcome available besides these.

    I am currently, for instance, wrestling with a conversation-heavy WIP. It is fairly structured: there is predetermined sequence of scenes, and most of them are obligatory. (Up until the final act, the story doesn’t so much branch as feature different thematic emphases depending on what the player does, and that means that there some optional scenes. The plot structure isn’t a tree, though.)

    But one of the things I need to do is come up with a good way of tracking the cumulative effects of all these conversations on a couple of key relationships in the game, in order to work out better what happens at the end. I was planning to do this with some if-then statements, but there is now too much content and too much divergence possible in the early parts of the game; explicitly checking flags to determine the possibilities of the final act would be hackish and prone to breaking any time I changed conversational content.

    On the other hand, the emotional arc of the story is too complicated, and takes place over too much time, to be represented with simple states or counters for the NPCs. *One* comment the player makes shouldn’t (except in very rare, critical scenes) be enough to shift the NPC’s whole attitude; instead it should be interpreted against, and have an effect based on, the whole state of the relationship so far.

    What that means is that I could use some more sophisticated numerical approach to handle this — maybe the sort of Noisy Cricket AI I described, maybe some variation; I’m willing to slip into I6 if that makes it easier to do, as ideologically impure as that is, but that may not be necessary if I think it out right.

    One doesn’t have to approach this question as an either-or choice between narrative and mechanics, in other words. For what I want to do — a story with a fairly well-defined arc where the player nonetheless has choices to make all along and quite a lot of agency by the end — I need some mechanical sophistication under the surface in order to ensure that the finished product is solid and consistent.

    Which is what I was kind of getting at with Child’s Play as well: the machinery was there to keep the interaction robust and fun. It doesn’t take over the foreground; it doesn’t become more important as machinery than the story; it doesn’t cause the prose to turn out ugly.

  3. Of course, mechanics are important. Tools are important. If they weren’t, I wouldn’t get that sinking feeling when I see the next game on my Comp to-play list is coded from scratch — or even written in ADRIFT for that matter.

    So, you’ve just said you have a story you want to tell (or, if you prefer, an experience you want to empower your player to discover for herself). You are finding that the technical tools at your disposal are not quite adequete, and are therefore looking into developing new ones. That’s great. No, really, that’s awesome. That’s the way I’d like to see things work.

    You know what would be really great? If when you release your WIP, everyone just can’t wait to talk about what a neat experience it was, and can’t wait to compare notes about it. “You said THAT and she did WHAT????” They are excited about the experience of the game rather than the technique behind it, in other words.

    Perhaps later there will be some quieter discussion among serious authors. “So, Emily, I have this game I’m working on where you play a so-and-so doing such-and-such, and I think I could use some of the techniques you used to create such believable interpersonal interactions in your last game. How exactly did you ?”

    That’s the sort of the place I’d like to get to.

  4. If when you release your WIP, everyone just can’t wait to talk about what a neat experience it was, and can’t wait to compare notes about it.

    I would like that too, of course, but we will see whether it comes out being anywhere near that compelling…

    That said, I think there is some value in the community’s desire to understand how things work, in detail, in order to expand the roster of techniques available to authors. Especially if a technique appears well-integrated within the game, it may not be obvious that anything special was done unless the author takes the initiative to document the making-of process. I really appreciate, for instance, Stephen’s choosing to write up an article about what he learned from writing Child’s Play.

  5. > There have been some people — especially early on — who felt that they “couldn’t” say anything critical about Inform 7 because it would be perceived as part of Breslin’s flamewar.

    I felt that way early on. I don’t any more, and I suspect the rest of the newsgroup doesn’t either. This is because Breslin has become transparently ludicrous. (Viz. the notion that it is your job to restrain the mindless hordes of people interested in your work, lest they destroy civilization.)

    On the topic of IF, however…

    > If the example of liquid-mixing seems too narratively bleak to be compelling, consider that a similar kind of math could be used to take a number of different mood vectors (annoyance, excitement, lust, whatever) and find the specific emotional state that best conveyed that mixture of moods.

    That manages to make the idea of character development sound as narratively bleak as mixing watercolor paint.

    I can see it working as a subtle background tool, rather than an up-front mechanism to play with. But that rather implies that a rougher, less math-intensive approximation would work as well. (On the other hand, tools get used when they’re available, so I might just be dismissing this with the “Well, *I’ve* never needed it” of any grumpy obsolescent hand-crafter. :)

  6. I can see it working as a subtle background tool, rather than an up-front mechanism to play with. But that rather implies that a rougher, less math-intensive approximation would work as well.

    I definitely mean it as a background mechanism, and one that would, moreover, be strongly controlled by the nature of the story to which it belonged.

    I also suspect that this kind of thing is less necessary in short works. It’s only in my long WIP, with its large number of slight differences, where I find myself wanting this. What I want is to be able to take account of how much the player has strengthened relationship X and how much relationship Y (and so on) through many incremental steps, and then translate those to a handful of outcome states.

  7. But a powerful system is not valuable if no one is making use of that power. And it seems to me that very few are utilizing TADS 3 to its potential. I don’t think that situation would be any different if Inform 7 had never been created.

    Thus, it seems to me this idea that the community’s slavish embrace of Inform 7 is holding it back from advancing the form is really quite absurd. (This is the gist of Breslin’s argument as I understand it.) If Inform 7 didn’t exist, I don’t think we’d have a hugely greater number of TADS 3 games, and no more interesting (from a literary OR technical standpoint) games as a whole than we do right now. Actually, I’d say we’d have significantly less.

    While I agree with the general thrust of this, I’d like to qualify it a little. I think it very probably is the case that many (if not most) of the people who have taken up Inform 7 would not have taken up TADS 3 had Inform 7 not existed. At least, the impression I get from various postings on RAIF is that many of the people who have been attracted by Inform 7 would be more than a bit intimidated by TADS 3 (which may be part of the point Jimmy is making). Moreover, I think GN and MJR were aiming their systems at different target users; in particular I don’t think newbie-friendliness was ever a very high priority in the design of TADS 3; discussions on the TADS 3 list during development suggested that MJR (and I) tended to prefer power and flexibility over newbie ease of use whenever there was a perceived conflict. That doesn’t mean that I think that TADS 3 is necessarily hard to use, but I get the feeling it was always envisaged as primarily something of a “power-user” tool (although I don’t wish either to put words into MJR’s keyboard or thoughts into MJR’s mind).

    That said, although Inform 7 seems to have been very succesful at attracting new IF authors, it has also been highly successful at attracting more experienced ones. I don’t find this at all surprising; Inform 7 is a high-quality product designed by people with an excellent understanding of the needs of IF authors. Experienced authors formerly using Inform 6 or TADS 2 (say) would very naturally perceive Inform 7 as something well worth trading up to. These experienced authors are likely to be much the same people as TADS 3’s target clientelle. Inform 7 has thus very likely attracted some users of this type who might otherwise have become users of TADS 3. Of course this is a testimony to Inform 7’s virtues, not a cause to call anathemas down on its head, but my suspicion is that there would have been a few more experienced IF authors using TADS 3 had Inform 7 not existed. If Jimmy is write that only a handful of TADS 3 users are getting the best out of the system, it would only take a few more experienced IF authors to have taken it up to make a substantial difference in percentage terms.

    A further contributory factor, I suspect, is one I’ve already discussed with Emily elsewhere, namely that TADS 3’s support for non-Windows systems is less than ideal. If there were a version of TADS 3 Workbench (the TADS 3 IDE) equivalent in functionality to the Windows version available to run natively on Macs then TADS 3 might well appear a rather more attractive option to Mac users. Again, it would not take many Mac-using experienced IF authors switching to TADS 3 to make a significant impact in percentage terms.

    Whether any of this matters is another issue. Like other contributors to this thread I think it’s healthy for IF authors to have a choice of system. A larger set of active TADS 3 authors might make that choice more of a real rather than a default one for everyone else. And whereas I personally think it is rather futile to debate whether TADS 3 or Inform 7 is better overall (having written reasonably substantial games in both systems the question feels a bit meaningless to me), I do sometimes feel that TADS 3’s strengths are not always well understood, and its differences from Inform 7 sometimes caricatured. To that extent I sometimes find myself at least in partial agreement with some of what Steve Breslin says, if only because he does have a sound grasp of TADS 3.

    Too much of the comparison between Inform 7 and TADS 3 has taken the form of counting the number of classes that implement specialized widgets in the TADS 3 library compared with Inform 7’s sparser world model (true, but not nearly as relevant in my own practical experience as seems commonly to be supposed); or of somewhat abstract arguments over the relative merits of rule-based and object-oriented programming (again, in my own practical experience of using both systems, each may have its strengths and weaknesses in individual instances, but neither feels better than the other overall – just different). There are considerable differences between Inform 7 and TADS 3 in many areas, but arguably the most important ones are the least discussed (perhaps because they’re more complex and less apparent on the surface). For example, if one strips away any polemic, Steve Breslin is basically correct, say, that TADS 3’s built-in handling of implicit actions is both more satisfactory and more robust than what you get with Inform 7 plus my Implicit Actions extensions (though the differences may be rather less apparent to players than to authors) (I know SB didn’t cite this specific example, but it exemplifies things he has said). Conversely, Inform I7’s “Understand” statements can do some things that would be far trickier or more laborious in TADS 3. My own view is that any comparison of the two system really needs to proceed at that kind of level of detail to be fruitful (the more obvious differences now already being fairly well known).

  8. My own view is that any comparison of the two system really needs to proceed at that kind of level of detail to be fruitful (the more obvious differences now already being fairly well known).

    This is something I think a lot of us would like to see more of, but few of us have enough experience to do ourselves, so your insights on the topic are very welcome.

  9. This is something I think a lot of us would like to see more of, but few of us have enough experience to do ourselves, so your insights on the topic are very welcome.

    Should I take that as an invitation to expand? One way to do so may be to contrast the ways in which a tiny game coded in I7 and TADS 3 work when both systems are used “as-is” (i.e. with just their standard libraries).

    Here’s the I7 version:

    The Kitchen is a room. “A brown door leads north and a black door south. There’s a cabinet mounted on the wall.”

    The table is a supporter in the Kitchen.

    On the table are an orange, an orange mug, and a brown mug.
    The orange is edible.

    The cabinet is a closed scenery openable container in the Kitchen.

    A door is usually scenery.

    The brown door is an openable door. It is north of the Kitchen.
    The black door is an openable door. It is south of the Kitchen.

    From this we might get a transcript like this:

    >take orange
    Which do you mean, the orange or the orange mug?

    >take mug
    Which do you mean, the orange mug or the brown mug?

    >orange
    Taken.

    >take brown
    (the brown mug)
    Taken.

    >open brown
    (the brown mug)
    That’s not something you can open.

    >drop brown
    (the brown mug)
    Dropped.

    >open brown
    (the brown mug)
    That’s not something you can open.

    >open brown door
    You open the brown door.

    >close door
    Which do you mean, the brown door or the black door?

    >brown
    You close the brown door.

    >put brown in cabinet
    (the brown mug in the cabinet)
    You need to be holding the brown mug before you can put it into something else.

    >take brown
    (the brown mug)
    Taken.

    >put brown in cabinet
    (the brown mug in the cabinet)
    The cabinet is closed.

    >open cabinet
    You open the cabinet.

    >put brown in cabinet
    (the brown mug in the cabinet)
    You put the brown mug into the cabinet.

    The TADS 3 equivalent would be:

    me: Actor
    location = kitchen
    ;

    kitchen: Room ‘Kitchen’
    “A brown door leads north and a black door south. There’s a cabinet mounted on the wall. ”
    north = brownDoor
    south = blackDoor
    ;

    + brownDoor: Door ‘brown door’ ‘brown door’;

    + blackDoor: Door ‘black door’ ‘black door’;

    + Surface, Heavy ‘table’ ‘table’;

    ++ Food ‘orange’ ‘orange’;

    ++ Thing ‘orange mug’ ‘orange mug’;

    ++ Thing ‘brown mug’ ‘brown mug’;

    ++ OpenableContainer, Fixture ‘cabinet’ ‘cabinet’;

    From which the equivalent transcript might look like this:

    >take orange
    Taken.

    >take mug
    Which mug do you mean, the brown mug, or the orange mug?

    >orange
    Taken.

    >take brown
    Taken.

    >open brown
    Opened.

    >drop brown
    Dropped.

    >close door
    Closed.

    >put brown in cabinet
    (first taking the brown mug, then opening the cabinet)
    Done.

    At a first approximation, the TADS 3 version is better at doing what the player wants without making a fuss about it, while the Inform 7 version is better at telling the player what it’s doing.

    In terms of coding the two versions, there’s not a great deal to choose. The TADS 3 version looks a little more repetitive in that we have to specify both the vocab words that apply to an object as well as the name that will be displayed (and the internal name of the object, if we want one, though we can leave objects anonymous if we don’t).

    When it comes to choosing between the orange (fruit) and the orange mug the I7 leaves the player no way to refer to the fruit (of course this can be fixed with a “does the player mean” statement or by using Jon Ingold’s Disambiguation Control extension; I’m just comparing how things work “out of the box”). For the TADS 3 version this isn’t a problem, since the TADS 3 parser recognizes “orange” in “orange mug” as an adjective and automatically prefers the noun match. This is an advantage in most typical cases, but makes it a bit harder to define objects described by non-standard noun phrases such as “the path to the north” (which an I7 Understand statement would have no particular difficulty with).

    The TADS 3 parser is smart enough to work out that the mugs (but not the doors) are portable while the doors (but not the mugs) are openable, so that TAKE and DROP probably refer to the former and OPEN and CLOSE to the latter. This allows TADS 3 to avoid a whole lot of disambiguation questions asked by Inform 7. The TADS 3 parser knows it’s more logical to close an open door than a closed one, so it avoids asking which door the player means in response to CLOSE DOOR when only one door is open. On the other hand TADS 3’s responses to these actions are so laconic that it may not be immediately obvious to the player what effect his/her command has just had.

    Finally (in this example), TADS 3 does a much better job of handling PUT BROWN IN CABINET by performing a sequence of implicit actions rather than forcing players explicitly to do the obvious intermediate actions of taking the brown mug and opening the cabinet. TADS 3 also neatly gathers all the explicit action reports together into a single parenthesised summary. Although much of this functionality can be made available in Inform 7 by using my Implicit Actions extension, the TADS 3 implementation is more robust and, I think, easier to customize for exceptional cases. Part of the reason for that is that TADS 3 buffers all output through what it calls the “transcript” before displaying it on the screen, so that, for example, it can gather all implicit action reports into one before displaying them. My I7 Implicit Actions extensions tries to do the same thing, but (a) can’t manage any case and (b) comes horribly unstuck if used in conjuction with a debugging command like RULES, which could then try to write to the temporary text buffer with potentially catastrophic results.

    That said, one can certainly add in many of the TADS 3 features mentioned above into an I7 game using extensions and various language features, just as one can make the TADS 3 version give better feedback on how it is interpreting the player’s commands. Moreover, just because there are clear differences in the way the two systems behave, it doesn’t mean that those differences are always important; in many games the behaviour of one system or the other ‘out of the box’ or with easily included extensions may be quite good enough. Nonetheless there are differences here, and while I’m inclined to agree with Jimmy Maher that what matters to players is more likely to be the story than the details of the game mechanics, that does rather presuppose that the game mechanics manage to remain reasonably unobtrusive. In the above example, the TADS 3 version is arguably giving players a smoother player experience than the I7 version; or, to put it another way, the I7 author has a bit more work to do to make the I7 version carry out the intelligent disambiguation and implicit actions that come as standard with TADS 3.

    It’s also arguably the case that the TADS 3 implementation of these features is easier to customize than the I7 equivalents (though this perception may be due to my greater familiarity with TADS 3). For example, while in I7 you have to specify in an action definition whether objects need to be touchable or visible for that action, or whether the action applies to something preferably held, in TADS 3 this is defined on the class or object, by the same mechanism that triggers implicit actions. So, for example, if I need to be holding the pen but not the mountain to show one or the other object to an actor, I can define an objHeld precondition on the pen and a objVisible precondition on the mountain (for that object). It’s less clear to me how one would do the equivalent in I7.

    Likewise, although Jon Ingold’s Disambiguation Control extension goes a considerable way to closing the gap, I’m inclined to think that TADS 3’s verify() methods provide rather a neat way to do what one needs a combination of check rules and does the player mean rules in I7, and ends up with something that’s arguably a bit more flexible (or, to put it another way), something that allows finer degrees of control. The TADS 3 standard library takes full advantage of this to implement the kind of ‘out of the box’ intelligent disambiguation illustrated above (although it’s clear that the I7 has at least some equivalent features built in). Once one wants to move beyond the standard library default behaviour, though, I suspect that many authors will find optimal use of TADS 3 verify statements harder to master than that of I7’s check and ‘does the player mean’ rules.

    Lest this is starting to sound a little like a party political broadcast on behalf of the TADS 3 faction, let me end with a couple of examples to I7’s advantage. Suppose in a purely hypothetical game we have a single bell-push, and for this object alone it would make sense for the player to RING BELL as well as PUSH BELL (both commands meaning the same thing). In I7 we can simply write:

    Understand “ring [bell]” as pushing.

    If there’s a way of doing this in TADS 3 I haven’t discovered it yet. In particular there may be some way of defining new tokens of grammar in TADS 3, but that aspect of the parser is totally opaque to be, and my brain gets totally tied in knots long before I come close to any real understanding of it, whereas in a case like the above, in I7 it is simplicity itself.

    In TADS 3 one would have to define a new ring action plus its grammar, plus its default behaviour on the Thing class, and then finally on the bell add a line like:

    dobjFor(Ring) as dobjFor(Push)

    This is doable, but a lot more work.

    Likewise, in I7 we can define:

    The cup can be broken or unbroken.
    Understand the unbroken property as describing the vase.

    This is perhaps easier to deal with in TADS 3 than the “push bell” example (and there are several ways of dealing with it), but it’s more work than this brief I7 code. The way I’d probably go about it is:

    brokenState: ThingState
    stateTokens = [‘broken’]
    ;

    unbrokenState: ThingState
    stateTokens = [‘unbroken’]
    ;

    vase: Container ‘broken unbroken vase’ ‘vase’
    allStates = [brokenState, unbrokenState]
    getState = (isBroken ? brokenState: unbrokenState)
    isBroken = nil
    ;

    Not too bad, but quite a bit more busy-work than the I7 equivalent.

    Well, this has turned out to be quite a long post, with perhaps more detail than anyone ever wanted, but it’s an attempt to spell out in more detail what a comparison of I7 and TADS 3 might look like once we stop obsessing about OO vs rules or the huge class hierarchy in the TADS 3 standard library and start looking at some of the subtler differencess instead. This isn’t a contribution to an argument that one system is better than the other; it’s rather an attempt to illustrate the kind of things that might be at stake in choosing one system or the other for a given project, or in assessing which might better match a particular author’s needs, proclivities and tastes.

  10. Just a couple of comments clarifying a few things I mentioned before and speaking more to Eric’s first post than to his (excellent) more involved discussion of the mechanics of TADS 3 and Inform 7…

    There ARE a fair number of TADS 3 authors, producing I’d guess to be perhaps a dozen or so new games per year. While this quantity is obviously dwarfed by the quantity produced using Inform 7, it also in turn dwarfs the number of games produced with any OTHER IF development system, with the exception of ADRIFT. (Well, there’s also Inform 6 and TADS 2, both of which are still fairly commonly used, but you get the point…)

    My disappointment with TADS 3 games does not really relate to the absolute quantity of games being produced, but rather that so few of them really do anything to take advantage of TADS 3’s strengths. TADS 3 game after TADS 3 game, with the exception of Eric’s own work and Mike Roberts’s single game, could just as easily have been written in TADS 2, Inform 6, or even ADRIFT. TADS 3, with the few exceptions I just mentioned, has not done a lot to really push the state of IF forward. I honestly don’t know quite why that is, but I do feel quite certain that it’s not Inform 7’s fault. Inform 7, meanwhile, and in spite of a rather disappointing crop of games in this year’s Comp, has led not just to more IF but to better IF. Just the fact that it’s led to authors more fully describe their scenery justifies its existence for me. :)

    I can offer my own observations on the two systems. I was very excited by TADS 3, and had initially planned to write my current WIP using that system. I just found it really, really hard to wrap my head around, though, and this in spite of the fact that I am a reasonably experienced programmer. When I eventually gave Inform 7 an extended try, I decided it was the system for me. This is no great insight to offer, but here goes: Inform 7 feels like writing, while TADS 3 feels like programming. TADS 3 presents me with debuggers and stack tracers and an IDE and all the rest; Inform 7 encourages me just to think about my story and my design. For all its power, TADS 3 is a 3rd generation programming language; Inform 7 is a 4th generation language.

    But now this is starting to read like a slam on TADS 3, and that’s not my intention. If IF was generally produced differently — say, a programmer working with a writer / designer — TADS 3 would be the ideal system. As it is, though, I do perceive a little bit of cognitive dissonance in trying to craft a solid story with good prose in an IDE that looks like Visual BASIC and in a language that looks like C++. Maybe I just have more trouble than others bringing together the programmer side of my personality with the writer side, but Inform 7 just feels more natural for crafting a work of fiction.

    Another huge problem TADS 3 has, which Eric alluded to, is the lack of support for platforms beyond Windows. Not only is the nice IDE only available on Windows, but a proper multimedia interpreter is ALSO only available on that platform. This is really a huge problem in IF circles, where my gut tells me that at least 50% of active players are NOT using Windows. I think maybe the greatest technical service anyone could do for the community right now would be to write a proper OS X and Linux multimedia-capable TADS 3 terp. (Yes, I know it’s a tall order.) Every time I see someone announce yet another Z-Machine terp, I wish someone would apply their skills to this project instead.

    Still and all, I’m still jealous of all the power under the hood in TADS 3. I’ve often thought that a wonderful project would be to build a library of Inform 7 extensions incorporating these features into that language in a modular fashion. Not a project I have the time or (likely) the skills for, unfortunately. :)

  11. Jimmy Maher wrote:
    There ARE a fair number of TADS 3 authors, producing I’d guess to be perhaps a dozen or so new games per year. While this quantity is obviously dwarfed by the quantity produced using Inform 7, it also in turn dwarfs the number of games produced with any OTHER IF development system, with the exception of ADRIFT [and Inform 6].

    … and with the exception of Quest, too! See the “Games Released in 2008” and “Games Released in 2007” pages from the IFWiki. Yes, some things are a little strange in the world of interactive fiction.

    And I agree that Eric Eve’s long post comparing TADS 3 and Inform 7 is interesting. As a comment in a blog, it might be read by too few people; so perhaps it could be expanded (with other examples added) as articles which could be published on his website (and/or Brass Lantern, SPAG, etc.)? Maybe Jeff Nyman could also write or co-write such articles, because he seems to have studied the differences between Inform 7 and TADS 3 very much, too.

  12. “I do perceive a little bit of cognitive dissonance in trying to craft a solid story with good prose in an IDE that looks like Visual BASIC and in a language that looks like C++.”

    Just to throw in my two cents: I have exactly the opposite view. The chief deciding factor that made me work in TADS 3 rather than Inform was that I didn’t like the way I7 conflated the code behind the game with the prose the user sees.

    To my way of thinking, the code (whether it’s C-like or natural language) is like ‘back-stage’ where you have stage-hands running around assembling the props and half-dressed actors trying to remember their lines. I feel more comfortable working as if there’s a solid dividing line between what the audience sees, and the machinery behind the curtain.

  13. Jimmy Maher wrote:
    My disappointment with TADS 3 games does not really relate to the absolute quantity of games being produced, but rather that so few of them really do anything to take advantage of TADS 3’s strengths.

    Part of what I had in mind is that if there were more TADS 3 games, the chances are there’d be more that did something interesting with the system (on the assumption that the good/mediocre/dross ratio remained constant). Another part of what I was thinking is that for whatever reason very few established IF authors (among whom one might expect to find people willing and able to take advantage of TADS 3’s strengths) have in fact taken up TADS 3. Lack of adequate non-Windows support could be a factor in that, as could the attractiveness of I7 as an alternative front-rank system. Other factors could well be at work as well, such as those you mentioned in formulating your own preferences, namely:

    Inform 7 feels like writing, while TADS 3 feels like programming. TADS 3 presents me with debuggers and stack tracers and an IDE and all the rest; Inform 7 encourages me just to think about my story and my design. For all its power, TADS 3 is a 3rd generation programming language; Inform 7 is a 4th generation language.

    I think it’s fairly clear that you’re not alone in feeling this (indeed, this seems to be the kind of reaction I7’s design philosophy was in part designed to address, evidently with considerable succeess). That said, Jeff Nyman’s work with writers suggests that this is not everyone’s reaction. The only conclusion I can draw from this is that what kind of system one is more comfortable with is very much a matter of subjective preference, or how one’s mind happens to work.

    But to get back to your earlier point about the disappointingly small use of TADS 3’s more advanced features, I can’t disagree with you. That there hasn’t been a rush of games taking advantage of some of the more arcane features of the TADS 3 library (its support for sense passing, sensory emanations and sensory events, for example) is perhaps not so surprising, since only a minority of IF works are likely to benefit from experimentation in these areas, and if the experimentation is done well the results may appear relatively unobtrusive to most players (who, after all, may be neither aware of nor interested in how the text they’re reading was produced under the hood). What I do find disappointing is how little use has been made of TADS 3 conversation and NPC-handling tools, which I should have thought would have been much more central to potential developments in narratively-focused IF. To me, these are among the most compelling ‘must have’ features TADS 3 has to offer compared with other systems, and among the features I’ve been most interested in exploiting and extending in my own work. Not everyone likes what are sometimes termed ‘conversation heavy’ games, so this may be one reason why these features haven’t been exploited more. Another (although this is pure speculation) is that taking full advantage of TADS 3 conversation requires a lot of work. TADS 3 makes the actual coding as much of a doddle as it could be; what’s laborious is writing dozens of quips and ensuring that you’ve got the right logic for having them fire in the appropriate places. Again TADS 3 Conversation Nodes provide an excellent mechanism for writing threaded conversations, but to write a sequence of Conversation Node properly (i.e. each of which makes the NPC insist on an answer and covers all the things the player might do instead of providing one) is also quite laborious; so much so that I can seldom find the energy to build a chain of more than a few ConvNodes at a time.

    Another under-exploited NPC feature of the TADS 3 library is the AgendaItem, which has the potential to implement goal-directed NPC behaviour in a vaguely rulebook-like way; I’ve used AgendaItems in my own work, but I’ve yet to exploit their full potential.

    As an aside, I would say that I enjoy working both with TADS 3 and with Inform 7, and have every intention of continuing to use both, switching between them as the fancy takes me, or, less arbitrarily, according to my estimation of which is better likely to suit the sort of game I have in mind. As things stand at the moment, I’d be much more likely to choose TADS 3 for a conversation-heavy game, or one in which I wanted to push the boundaries of IF conversation. Although I’ve written a couple of conversation extensions for I7 intended to provide TADS 3-like conversation features for I7, I’d only be happy to use them in games that only needed to make relatively light use of them (of course I’m aware that other kinds of conversation system can fruitfully be implemented in I7, and that Emily’s doing a lot of interesting work in this area).

    Which brings me to:
    I’ve often thought that a wonderful project would be to build a library of Inform 7 extensions incorporating these features into that language in a modular fashion.

    Well, at the risk of expelling too much breath through my own brass instrument, in a small way this is something I’ve been doing with some of my own I7 extensions. Exit Lister, Epistemology, Underside, Adaptive Hints, Bulk Limiter, Implicit Actions and Conversation Package (and its component parts) are all attempts to add TADS 3 features to I7. Most of them are not as fully-functional and robust as the TADS 3 originals they’re cribbed from, so if I wanted to make heavy use of the features they provide I’d personally be inclined to use TADS 3, but for a lot of purposes I think they provide a good enough approximation to the equivalent TADS 3 features (apart from any bugs they may still contain!).

    Eriorg wrote:
    And I agree that Eric Eve’s long post comparing TADS 3 and Inform 7 is interesting. As a comment in a blog, it might be read by too few people; so perhaps it could be expanded (with other examples added) as articles which could be published on his website (and/or Brass Lantern, SPAG, etc.)? Maybe Jeff Nyman could also write or co-write such articles, because he seems to have studied the differences between Inform 7 and TADS 3 very much, too.

    You’re right, of course (I mean about the best place to post this kind of comparison). I posted it here since it seemed an appropriate response to the ongoing conversation in this thread, but though I considered posting more of the same, I likewise felt this probably wasn’t the best place for it, and I’d already vaguely thought that my website might be a better place. If anyone can think of a better place, by all means let me know; and if Jeff Nyman is reading this and is interested in the kind of collaboration you suggest I’d be happy to hear from him. None of which should be taken as a promise to rush off instantly and devote lots of man-days to producing the relevant documentation by Christmas!

  14. Jimmy Maher said: “I do perceive a little bit of cognitive dissonance in trying to craft a solid story with good prose in an IDE that looks like Visual BASIC and in a language that looks like C++.”

    I agree with Pacian on this point. I prefer to keep the prose writing in a different bin in my brain from the coding. But it’s entirely a matter of personal preference, and I can readily understand than many people prefer to stream everything onto the page (oops, I mean “screen”) together.

    Eric has, with his usual deep insight and rhetorical precision, highlighted some real differences between the two languages. Since I’m mainly a writer, not a programmer, these points strike me as more useful o know about than whether one can craft AI that will work out an NPC’s current emotional state along three simultaneous axes. But again, others may find the latter necessary for their story, or just fun to implement.

    I’ve been contemplating whether to propose co-writing (with Eric or with someone else) a single game in both I7 and T3, with the following criteria:

    1) The output should be, to the extent that can be achieved, line-for-line identical.

    2) The game design should explore a fair number of the special features of each language.

    3) Both sets of source code should be released along with the game, and should be commented with cross-references, so that authors can study the differences.

    I’m reluctant to wade into such a project, both because my time is limited and because I’m barely proficient in T3 and nowhere near proficient in I7. But I guess it’s time to toss the idea out there. Does anyone else feel such a project would add some useful information to the discussion? Well, obviously … but would the amount of useful information be sufficient to justify the work involved?

  15. Eric, or anyone else who’s contemplating comparing the languages in a more formal article: I’d be thrilled to have something like that at Brass Lantern. My time to write such articles is severely limited these days.

    Take the things I’m about to say comparing the languages with a grain of salt. I last used TADS 3 extensively some three years ago, when it was still very much in flux.

    There is a lot I like about TADS 3. One of the biggest features I miss in I7 is the ability to filter output text before it’s displayed. There were a number of places in Child’s Play where I wanted to collate reports by post-processing output, something I7 just cannot do without abandoning the Z machine entirely.

    I spent some time writing a game that made heavy use of Conversation Nodes, and ran into the problem Eric mentioned. I ended up writing a perl script to parse a text file and turn it into the appropriate ConvNodes, but it was painful enough that I eventually stopped. This is not a weakness of T3 per se, since doing the same thing in I7 via tables or ConvNode-like structures would have the same difficulty.

    I’ve never finished any of the games I’ve started in T3. I find it hard to hold enough of the library and its interactions in my head to make much progress. I spent a lot of time figuring out where I should hook into the library for whatever effect I’m after. This is especially troublesome given how I work. When I’m going outside the bounds of what a system’s library provides, I tend to make tiny experiments to test out new functionality. Doing this with the T3 library was for me an exercise in frustration, as the library interfaces were myriad and opaque. In writing Child’s Play in I7, I started with a simple NPC model and added to its complexity as I went, something I’d had trouble doing in T3.

    The biggest win for me in I7 is being able to target the Z machine. It’s ported widely and well. T3 and Glulx interpreters are not as widely ported, and the ports tend to be more fragile. Child’s Play would never have shown up at JayIsGames had it targeted the T3 or Glulx VMs.

  16. Eric,

    I am indeed well aware of your work adding some of some of TADS 3’s features to Inform 7 . In fact, I’m using your conversation extensions to an absolutely massive extent in my WIP. I really don’t know where I’d be without them. So, thanks for that! I guess I was thinking of building an Inform 7 version of the TADS 3 library in a more systematic way (somewhat like the old Inform 6 OR library), adding the more esoteric or simulation-oriented features for those who want them. Whether such a project is possible or even desirable is of course an open question.

    Yes, I am writing a conversation-heavy game in Inform 7, and while it’s undeniably been a massive pain in the rear, I think that’s more down to the difficulty of the task on a design level — keeping track of who knows what, etc. — than to any unwieldiness on Inform 7’s (or your extensions’) part. I absolutely love the way the TADS 3 conversation system works in your games, which is why I wanted to crib the TADS 3 system for my own Inform 7 work. However, when I played around with coding conversations in TADS 3 it didn’t seem any more elegant than doing so in Inform 7 with your extensions. My impression of the TADS 3 system is that it’s elegant and intuitive from the player’s perspective, but pretty difficult and clunky to work with for the author. Like most aspects of IF coding, in other words. :) Obviously this is just a first impression, of course.

    When I talk about being disappointed with TADS 3 games, conversation is indeed the main thing I am thinking of. (And Jim, although I played and greatly enjoyed Last Resort on Glulx, I haven’t played the TADS 3 port. So if you did make better use of TADS 3’s conversation features, I apologize for not making note of that.)

  17. Stephen Granade wrote:

    There were a number of places in Child’s Play where I wanted to collate reports by post-processing output, something I7 just cannot do without abandoning the Z machine entirely.

    I *think* some of the issues for which one would want the transcript feature could be dealt with if the Standard Rules changed in such a way that printing anything from check rules would be delayed until the entire action had been run, and a report of failed-action printed (if necessary) or else a report of intermediate implicit actions assembled as part of reporting how the action as a whole went. This I think would help a great deal both with regular player activities and with creating nice output for NPC actions. But it’s not a trivial change to make, and I haven’t figured out all the details of how I would want it to behave.

    Jim Aikin wrote:

    I’ve been contemplating whether to propose co-writing (with Eric or with someone else) a single game in both I7 and T3…

    I am sure that would be a very interesting resource to have — a kind of super Cloak of Darkness.

    Jimmy Maher wrote:

    When I talk about being disappointed with TADS 3 games, conversation is indeed the main thing I am thinking of.

    If you haven’t, you should check out also Pacian’s Snowblind Aces. It’s not flawless, but it’s fun and more conversationally ambitious than the average TADS 3 game by a long shot. (So is Shadows on the Mirror, but that’s old enough (2003) that I don’t know whether it uses anything like the current version of the TADS 3 conversation system or whether it is largely custom code under the hood.)

    I do very much agree with the sentiment that the difficulty of using conversation tools (in I7, and perhaps also in TADS 3, from what people have said) is now a more significant problem than the quality of output when the tools are used right.

    This may be compounded in the case of Inform by the nature of the examples offered: my intention when I was designing was to offer a bunch of different and deliberately conflicting ways to handle conversation. The point of that, rhetorically (and the Recipe Book section on conversation says this) was that different games will benefit from different models of conversation, so the author should plan carefully. I’m not sure that that message gets through as clearly as I’d like, though — I think some people have started out with a very lightweight table-based implementation of conversation and then realized partway into the project that they chose wrong; but somehow they had the impression that the manual was presenting this as a default option.

    But there are solid tools that can produce fairly good conversational flow: NPCs who avoid repeating the same dialogue, track what has been said, answer based on the current conversation state, ask questions, repeat questions if they go unanswered, present multi-turn speeches that can be interrupted (or multi-turn speeches that *can’t* be interrupted), react sensibly to the PC leaving during the conversation, etc.

    My current project is partly an attempt to work on the authoring side of the problem — to make it easier to write large amounts of dialogue, and to minimize the amount of busywork that the author has to do in order to control conversation flow.

    The extension package has reached a relatively stable state now: it still needs a few more features, but I haven’t changed the internal code very much in some months. More critically, I am determined not to release it until I have finished writing at least one full-sized game with it, in order to prove to myself that it is adequate. I’m especially concerned about performance issues, because with a lot of calculation under the hood, it would be easy to write something that looks fine on a small example piece but performs unacceptably once there are any realistic number of conversation options in the mix.

    Anyway. All vaporware at the moment, I realize.

  18. I find it hard to hold enough of the library and its interactions in my head to make much progress. I spent a lot of time figuring out where I should hook into the library for whatever effect I’m after.

    Stephen’s comments here echo my experiences with T3 pretty closely. It is hard to hold enough of the library in your head at once, the way that I somehow could hold all of Inform 6 and TADS 2 up there and get to work.

    I haven’t given up on T3, but I have gotten frustrated on many occasions, my enthusiasm drying up on the vine, as I try to figure out how the T3 library is put together, so that I understand what to use and why it works. Sometimes it seems to literally lead in circles, or to a wild goose chain where there’s no actual functionality, just a definition pointing to a definition pointing to a placeholder and a comment saying that it’s there if some author wants to use it.

    I think in fact my problem is that I’ve spent too much time trying to rely on the built-in functions instead of writing my own, but there’s a sense of waste to that, too. I didn’t mean to turn this into a rant; I’ve been saving up my comments on T3 to put them in order and lay out constructive criticism.

    And as for its NPC conversation power, what I keep thinking again and again is that I need to write a tool that provides a bridge between the author and the library hooks, but I haven’t managed to create such a thing yet.

  19. And as for its NPC conversation power, what I keep thinking again and again is that I need to write a tool that provides a bridge between the author and the library hooks, but I haven’t managed to create such a thing yet.

    I’ve seen this comment come up a few times now, and I’m wondering if a general purpose application for conversation creation, that could output text to suit the syntax of both I7 and TADS 3, is worthwhile, or if each language is better served by individual abstractions? What would be the specification for such an application if it did exist?

  20. I’ve seen this comment come up a few times now, and I’m wondering if a general purpose application for conversation creation, that could output text to suit the syntax of both I7 and TADS 3, is worthwhile, or if each language is better served by individual abstractions? What would be the specification for such an application if it did exist?

    Off the top of my head I think it would be hard to come up with something that would work equally well for TADS 3 and Inform 7, not least because whereas there’s a sophisticated conversation system built into the TADS 3 library, Inform 7 only comes with a bare outline, and many people are likely to use a conversational extension (but not necessarily the same one, especially since I7 encourages diversity in this area).

    But then, to be honest, I’m having a bit of a hard job seeing why people find the TADS 3 system all that difficult to code (beyond, that is, the labour of writing all the quips and making sure the logic of when they become available is correct, but this is work one would have to do in any case). A lot of the actual coding takes the form of stuff like (in this example to respond to ASK BOB ABOUT MONEY):

    + AskTopic @tMoney
    “<q>What do you think about money?</q&gt you ask.\b
    <q>Must be nice for those who have it,</q> Bob grunts.”
    ;

    It’s difficult to see how this could be reduced to anything much briefer and still contain the necessary information. It’s also unclear to me how it could be made much simpler.

    And as I said, I’m also a bit puzzled why this is seen as so difficult. My best guess is that people are having difficulty remembering the names of the classes to use, or how the templates work; maybe I’ve become so familiar with them that they’re so much second nature to me that I can no longer feel the difficulty. Admittedly I’ve used a particularly simple example here, and things get more complicated when you want to do something more sophisticated, so maybe it’s the complications that people are finding difficult to keep in their heads.

    But then, of course, I’ve now written so much conversational code in TADS 3 that I’ve probably simply forgotten what it was like to be a beginner!

  21. Eric wrote:

    It’s difficult to see how this could be reduced to anything much briefer and still contain the necessary information. It’s also unclear to me how it could be made much simpler.

    I can’t really speak to the TADS 3 situation, but I can speak to writing large games with conversation systems that I designed myself in I6 and I7, where (obviously) I understood the syntax fine.

    What’s hard isn’t writing the individual pieces; what’s hard is keeping the shape of the dialogue in my head, managing dialogue flow, and (most of all) preventing the meticulous work of writing quip objects from making the dialogue itself come out stilted or mechanical. That last is a big one. Any lack of attention in creating the very detailed, very repetitive, very BORING quip objects meant buggy or uncompilable dialogue — but the mindset I needed for that was the absolute opposite of the mindset I needed to write convincing character exchanges. The coding was choppy and meticulous; the content needed to flow and be intuitive; and these two activities were more closely coupled than, say, writing an object’s code and then filling in its prose description.

    For City of Secrets, I eventually came up with a system of writing a whole scene as a nested script with light markup: indentation levels indicated which lines followed which others, and I had a symbol to mean something like “this quip is available only *directly* after the previous quip” vs. “this quip is available any time after the previous quip has been spoken”. (There were some other symbols too; I’ve forgotten all the details.) I then ran that through a perl script to get code, which I could then revise with any additional logic I needed to add. (IIRC — it’s been a while now — Dan Shiovitz wrote the script for me, and we used a similar markup-to-code conversion for the dialogue I contributed to Max Blaster; it wasn’t really hard to repurpose the method for TADS 3.)

    Anyway, once I put that system in place for CoS, writing the conversations got much less laborious (if I’d been remotely smart I would have come up with such a system much earlier in the process and probably saved myself dozens and dozens of hours).

    Just to give a sense of scale, Galatea uses 300-400 quips, City of Secrets more on the order of 3500. My current WIP has 450 or so. It’s longish but it has fewer characters and is much more focused than CoS — but I anticipate that at least doubling once I’ve finished the last couple of scenes and go back to flesh out optional dialogue throughout the game. I’m working on the absolutely-necessary-skeleton dialogue first, because I find if I go for breadth first, I get bogged down and never finish, and also that half of the “fun” stuff I add in has to be edited out again later because it turns out to be wrong for where the story is going. So I focus on making each scene possible to complete, including any necessary branches, and then come back and add optional quips later.

    So I guess the point here is really that though — as you say — it is necessary to do the conversational logic stuff no matter how you code it, there are more and less laborious ways of expressing conversational logic; and if that’s done well, and the code auto-generated, then the writing process is freed to be more expressive. In my experience. I think that is what people would be seeking in a code generator.

  22. (beyond, that is, the labour of writing all the quips and making sure the logic of when they become available is correct, but this is work one would have to do in any case)

    Well, yes, that is a lot of what I want a tool to help me with. And I suppose the bulk of my (and other people’s) seeming confusion comes from reading the first several hundred lines of actor.t, up to the definition of the Actor class itself. Maybe 98% of it can be ignored and simplified to +AskTopic @tWhatever, but there’s a lot of material there that is tempting to want to use.

    The phantom notion of a tool is the expression of a desire to have an interface that allows access to all of it but simplifies and organizes the presentation of it, I think.

  23. J. Robinson Wheeler wrote:

    And I suppose the bulk of my (and other people’s) seeming confusion comes from reading the first several hundred lines of actor.t, up to the definition of the Actor class itself.

    Yes, that would probably confuse anyone – or anyone who didn’t already have a good working knowledge of the TADS 3 library. It certainly isn’t how I’d recommend anyone went about learning the TADS 3 conversation system or any other part of TADS 3.

    Maybe 98% of it can be ignored and simplified to +AskTopic @tWhatever, but there’s a lot of material there that is tempting to want to use.

    If not 98% of it, then quite a bit of it, and I’d strongly recommend anyone learning TADS 3 to ignore the complications and stick to the simpe +AskTopic @tWhatever until they’re comfortable with what that (and related basic stuff) can do.

    Emily wrote:

    So I guess the point here is really that though — as you say — it is necessary to do the conversational logic stuff no matter how you code it, there are more and less laborious ways of expressing conversational logic; and if that’s done well, and the code auto-generated, then the writing process is freed to be more expressive. In my experience. I think that is what people would be seeking in a code generator.

    Okay, I see what you mean, but I guess my brain must work a bit differently. At least, with TADS 3, I’ve never felt the need to go through this intermediate step (although my dialogue might have been better if I had) partly since, for me, the TADS 3 code lays out the conversation logic about as clearly as any other system I’d be likely to devise to express it (with the possible exception of one that didn’t give the full text of the quips). This may, of course, simply be the failure of my imagination to come up with a better conversation-designing notation!

    That said, my guess is that even if someone did come up with a conversation-code generating tool in TADS 3 I’d still prefer to write my own conversation code by hand, since I’d feel I had finer control over what was going on. So that probably does say something about the way my mind works!

  24. I’ve been thinking a bit more about Eric’s comment here:

    For example, while in I7 you have to specify in an action definition whether objects need to be touchable or visible for that action, or whether the action applies to something preferably held, in TADS 3 this is defined on the class or object, by the same mechanism that triggers implicit actions. So, for example, if I need to be holding the pen but not the mountain to show one or the other object to an actor, I can define an objHeld precondition on the pen and a objVisible precondition on the mountain (for that object). It’s less clear to me how one would do the equivalent in I7.

    This is possible to override; the shortest way to do it is probably with a procedural rule. While one wants to avoid overusing procedural rules, there are times when they’re really handy, and this is one of them. Here’s what I came up with:

    Include Plurality by Emily Short.

    Procedural rule when showing scenery to someone:
    ignore the carrying requirements rule.

    The can’t show small unheld objects rule is listed instead of the can’t show what you haven’t got rule in the check showing it to rules.

    This is the can’t show small unheld objects rule:
    if the noun is not scenery and the player does not carry the noun:
    say “[The noun] [is-are] small enough that you can’t show [it-them] to someone unless you’re holding [it-them].” instead.

    Forest is a room. Some trees are scenery in Forest. Sam is a man in Forest. The interesting rock is a thing in Forest. The little mushroom is a fixed in place thing in Forest. Instead of taking the little mushroom: say “It is far more firmly rooted than you would have thought possible.”

    The player carries a hat.

    Test me with “show hat to Sam / show rock to Sam / show mushroom to Sam / show trees to Sam”.

    [Sam is disappointingly bored by all these objects, but at least they are being correctly shown under the right circumstances.]

    My own aesthetic of I7 programming prefers to write general rules whenever possible, so I’ve adapted the example so that it will show any scenery object to an NPC without trying to pick it up — but this is a matter of taste and one could construct the example to handle individual objects or allow a property to be set on some objects indicating that they were showable from a distance, instead.

Leave a comment