Which Development System?

Authoring General Design Discussions
3

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!

7 Likes
4

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.

5 Likes
5

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?

5 Likes
6

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

5 Likes
7

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

5 Likes
8

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)

5 Likes
9

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.

3 Likes
10

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

2 Likes
11

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.

7 Likes
12

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.

5 Likes
13

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.

3 Likes
14

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.

7 Likes
15

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

3 Likes
16

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

1 Like
17

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
18

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

1 Like
19

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;

#lighthouse
(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 *)
(endif)
The lighthouse glistens in the moonlight.

https://www.linusakesson.net/dialog/docs/io.html

3 Likes
20

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.

3 Likes
21

This is certainly a valid criticism of TADS. It can lead to messy code. The first-approximation answer, of course, is that you should put it in the troll, because it’s a special condition that only comes into play when the troll is present. But there might be five or six different weird things that can happen when you unlock the chest, in which case putting the code in the chest would be the right approach, as you can consolidate all of those weird things in one code block.

A related but more general situation that can trip up a TADS author is that with a two-object action (such as UNLOCK CHEST WITH KEY), there are always two code blocks – the dobjFor(Unlock) in the chest object and the iobjFor(Unlock) in the key object. If you’re not careful, you can cause duplicated things to happen because you wrote them into both code blocks. Again, this doesn’t happen in Inform, because there’s only one rule that applies to that command … unless you do something weird, I suppose.

2 Likes
22

That may be a question an author frequently has to ask oneself, but it’s also not the only way of handling things. Almighty “insteads” like that could be defined in the Thing class from which all meaningful parts of the game descend; or a statement could be added to multiple possible methods in the parse/execute cycle; or the situation could be caught and handled in a player’s beforeAction/afterAction; or a constantly running monitor Daemon could handle certain things of that nature… I’m just saying that without a greater understanding of how Dialog works, it kind of sounds like a difference of syntax rather than the ability to do something fundamentally different…

2 Likes