Which Development System?

I’m starting to think about writing a new game. Having mostly finished revising my Inform Handbook (look for it in a few weeks), I’m reasonably conversant with Inform again, so now I have to think about whether to use Inform or T3/adv3Lite.

The advantages of Inform are that it has a rich set of clever Extensions and that it’s probably more robust at producing a game that includes some graphics and sound. I’ve done TADS games with both graphics and music, but anything beyond bare embedded files is likely to be difficult. There is no TADS equivalent to Vorple. Also, I have an obscure desire to really feel that I’ve mastered Inform, especially in its new incarnation. I don’t feel that way yet.

The main advantages of TADS are that I’m faster at it because I know it better and that it compiles a lot quicker during game development. When you’re compiling your game a couple of thousand times, this is not a trivial factor. Also, the code syntax of TADS is inherently less prone to ambiguity. It just does what it’s supposed to do, with less fussing about.

As far as the features of the finished game go, it’s probably a toss-up. Both systems are excellent.

Both partisan and non-partisan comments are welcome. What would you do?


For whatever reason, forum-wise, I always thought of you as ‘a TADS guy.’

I feel like you’ve spent so much time publicly debating with yourself which is good or better or suitable or better documented, the answer to the question can only be yours, even if the act of you asking it suggests it’s not, or you don’t want it to be :slight_smile:

I’d say if there’s some dealbreaker, logistical or otherwise, let that determine the answer. (Is it hard to put TADS games online, still? We know it’s easy to put Inform ones online. Do you really want to use Vorple? I’ve never used it. I’ve got Inform games with plenty of Inform-native graphics and sound, but the sound still isn’t functional online with the current online interpreters.)

If there’s not a dealbreaker(s), use whichever one you’d rather program in.



I often hear that this is very dependent on the version of Inform you’re using.

Honestly, I feel like if you’re making an IF game that stays near the modern parser expectation for game mechanics, then you should absolutely take Inform for a spin. It’s pretty optimized and powerful with that sorta thing. Use a version that lets you add on a few Extensions, which should handle most of your non-standard mechanics, and rules can structure the rest of the outline for your game. Heck, use Vorple too, if you’re feeling wild.

There’s a huge amount of community knowledge available, and Inform basically has 24/7 tech support, lol.

This sounds like the decision has already been made, lol. Climb your mountains, man! Once you’ve finished this challenge, you can tell us all in TADS-land how it went!


Well, TADS’s extensions are more time-proof (I use scenes.h, whose gives me the main functionality of a3Lite’s scenes (actually, I think that scenes.h, among other Eric’s extensions, was the starting point of what eventually became adv3Lite…), and indeed I have tested successfully some early-to-mid aughties Tads3/Adv3 extensions…

TADS3’s forte is in NPC handling, more so with a3Lite, (albeit I miss the NpcGuidedTourState, whose I needed for some simpler NPC-driven scene, not needing the full functionality of A3Lite’s scene, and since 3.1.10 has a good adaptive prose handling, and ad prose handling remain Inform 7’s forte.

Inform 7’s natural language allow easier coding for non-programmers, but is still in fitting-out phase (shipbuilder sense) and has not few backward compatibility issues, the more relevant being the extensions issue, but promise, when fitted out and fully commissioned, to be a solid and powerful language.

from my perspective, I use I7 “by the book”, avoiding wild trickery, but on T3, I often experiment and apply interesting trickery (the most recent, abusing the Candle class for implementing a volatile odor, dissolving in a pair of turn…) and this reflect not the pros and cons of the language, but the state of development.

In the long, long run, the new front-end/back-end architecture of I10 can teoretically lead to even having a TADS 2/3 front end for an “universal” back end (I fess up, my ideal IF is a glulx story file compiled from TADS3 source…)

summing up, what should be the discriminating factor, is the approach to coding, TADS following the true and tested coding method, I7 and I10 following the “natural” coding method, and has all potential for becoming the first true fully-fledged NL programming language, a thing I’m watching with interest and curiosity.

Best regards from Italy,
dott. Piergiorgio.


I’m going to be contrarian and say Dialog, because now that you have experience with both TADS and Inform, why not try something new?


Once the game gets over 100k words, you can really feel this.


I’d be interested to see what you have in mind with the high graphics demands…


Not necessarily directed at you, Drew, but this is a PSA that if you’re using the Windows IDE, the built-in antivirus can dramatically slow down compile times. Details and workarounds in this thread: Inform7 slow compiling Windows 10 (windows defender problem)


I remember digging around after Windows Defender thought one of the interpreters in the IDE was a virus, and I’ve had Inform stuff excluded ever since. It still feels slow to me, though I admit that I haven’t benchmarked other systems.


If the Dialog web page is to be believed, Dialog compiles to Z-machine. I’m curious, though: What advantages does Dialog offer?


One of my large games, “A Flustered Duck,” was written in Inform. That was almost 15 years ago. Since then I’ve been using TADS.

There are things I like about Inform, and things that drive me crazy. There’s nothing about T3/adv3Lite that drives me crazy except trying to step through in the debugger.


Not really. If you go to the IFDB, the T3 games have Play Online buttons. Whether the playing process is as robust as with Inform games I wouldn’t know. I do know that T3 games don’t play sounds when played online in that system, because my “White Bull” game has opening music. I have the impression Inform games don’t play sound in the online interpreter either.


I haven’t thought it through. I’m not a graphic artist, so at the moment the need for graphics is more theoretical than practical.


In terms of how you use it, it feels like it’s fulfilling the main promises of Inform 7 without the natural language syntax. Everything is based on rules, or “predicates”, in Dialog terminology.

For example, from my unfinished port of Adventure:

(aboveground #endofroad)

The “end of road” object is above ground. Setting a property. Nice and simple.

But then:

(room (aboveground $))
(dwarves avoid (aboveground $)) %% Dwarves stay in the caves
~(inherently dark (aboveground $))

This specifies that if something is aboveground, then it is a room (i.e. “aboveground” is a property of rooms); if something is aboveground, then dwarves avoid it; and if something is aboveground, then it is not inherently dark.

Or maybe you want a bit more specificity in these definitions. You can specify that, perhaps, the dwarves avoid a certain room only if the magic sword is there:

(dwarves avoid #reliquary)
	(#sword is #in #reliquary)

In other words, “dwarves avoid” can be treated as a simple property that you set true or false on different rooms, OR it can be calculated dynamically by rules. In Dialog, there’s no distinction between these things. In my opinion, one of the big weaknesses of Inform’s rule-based system is that you can’t write rules for everything: you can’t write rules that say, for example, anything with a FROTZ spell on it is glowing, and a lantern is also glowing if it’s lit. You have to apply the property yourself every time these things change.

In Dialog, meanwhile…

((frotzed $) provides light)
(#lantern provides light)
	(#lantern is turned on)

Anything frotzed provides light. The lantern provides light if it’s lit, even if it’s not frotzed. Otherwise, things are dark.

It’s also a relatively new language, which means it doesn’t have two decades of cruft in its library. As a result it feels extremely sleek and elegant.


Well, then Inform is for you because it doesn’t have a debugger. :laughing:


Very nice. How far does this go? Can you bind values or just properties, for instance?

1 Like

well, A flustered duck was compiled with the venerable 5U92, since then, many water has passed under the bridges of Inform 7/10… perhaps some of the Inform things driving crazy you is no more, or I’m wrong ?

Best regards &c. from Italy,
dott. Piergiorgio.

1 Like

Is this somehow different from the TADS ability to interchangeably define properties as simple values or methods?

1 Like

I actually thought “Dialog is the best here” but didn’t mention it because you didn’t ask about it.

It has an extremely easy way to add links, images and sounds by using the ‘resources’ predicate:

(define resource #lighthouse)
media/lighthouse.png; A small model of a lighthouse.

(style class @center)
margin-top: 1em;
margin-bottom: 1em;
text-align: center;

(name *) lighthouse
(dict *) small tiny model silver
(descr *)
It's a tiny model of a lighthouse, made of silver.
(if) (interpreter can embed *) (then)
(div @center) (embed resource *)
The lighthouse glistens in the moonlight.



It’s similar, but rules don’t belong to specific objects. If you want to have a special exception happen when the player unlocks the trapped chest with the magic key in the presence of a troll, should that go in the player object, the chest object, the key object, or the troll object? Inform and Dialog bypass that question entirely.