ADV3Lite vs ADV3

The age old question. I’ve spent the last week or so practicing and working to pick up TADS 3’s language, building stuff without the adv3 or adv3lite libraries so I could be more confident when I decided to choose one.

Well now I’m at that point, the adv3lite library looks very appealing especially with its rules and relations, scenes, regions, and similar inform 7 features. It seems like adv3lite is nowadays just as feature complete if not more so than adv3.

adv3lite is easier to pick up of course, but I’m confident enough in my ability to pick either that it’s more of a question of if there’s any reason to go with adv3 over adv3lite? adv3lite seems extremely feature complete and I’m not entirely sure what adv3 offers that it doesn’t at this point.

(Especially considering it has extensions for re-adding room parts, postures, ect)

Hopefully you all can help me out, sorry if this is a tired question!

6 Likes

hello, welcome to the community! glad to see another person interested in the language.

I only use adv3Lite (and I’m a beginner), so my knowledge of Adv3 is limited. my impression is that Adv3 allows more complex messing around with class and object based code–there’s people in this community making world models of constellations and generating markov chains in Adv3. then again, maybe that’s cuz no one tried in adv3Lite!

afaik, most of the community here uses Adv3, so they’re more comfortable and familiar with it, which means you may get more quick support in coding help, but there’re knowledgeable adv3Lite people here for sure (like the guy who made it).

6 Likes

Yeah, I’ve seen that stuff and it’s pretty impressive. I’m sure Adv3lite could handle similar with some tinkering. TADS 3 is a full fledged OOP after all, Adv3lite should be just as expandable as Adv3!

And of course, thanks for the welcome! I always thought text based games were a medium with a lot of potential for complex and interesting mechanics and TADS 3 was specialized enough in text based games to be accessible and broad enough to not be limiting. (I really liked Inform 7 but just feel like TADS is more suitable to the kind of stuff I want to make)

5 Likes

I’ll give later an extensive treatment of the core diff, but now here is a major architectural emergency and I’m waiting for the Capomastro (master carpenter) for a damage assessment and estimate of repair costs…

Best regards from Italy,
dott. Piergiorgio.

4 Likes

I think adv3Lite is superior for certain kinds of games, and adv3 is superior for other kinds of games. (I know, that’s deep.)
Lite specializes in conversation and story-telling, adv3 is more specialized in mechanical/sensory/world-simulation elements. It is also very easy to import Scenes and Regions into adv3 if that’s a deal-breaker. I believe there is also an existing implementation of bring the Doer functionality to adv3 available.
Lite is still being currently updated, but then adv3 is very functional and full-featured as-is, with community members still contributing new patches and add-ons. Lite, being substantially younger, probably has more bugs left to be uncovered.
Lite also contains some extra convenience features, such as briefer vocabulary definitions, defining directions or check() methods with simple double-quoted strings and such.
My game was puzzle-and-simulation-centric, and I have no regrets learning adv3. I have a high respect for Lite’s take and appreciate the author’s contributions to TADS very much.
Whatever your take on that is!

4 Likes

Adv3 also assumes you won’t be changing much about how the game works. It’s easier to remove stuff from Adv3Lite, in my experience. Adv3 will fight you, so you’re better off just adding stuff, than modifying/removing stuff.

But yeah, Adv3 has wild amounts of simulation.

5 Likes

My “modify [Class]” section is probably larger than some IFComp games :laughing:
The modify clauses are one of the best parts of TADS…

4 Likes

They’re so good

5 Likes

For my part, I regret not picking up adv3lite initially, before getting pot committed to a large adv3 implementation. It’s not that adv3 is prohibitive or inferior, and certainly the documentation is just peerless. For me, the value of an active library developer/supporter vs essentially a ‘dead end’ implementation is incalculable.

I have run into a series of (very niche) adv3 bugs, and some quality of play issues that clash with my personal preferences… enough so that I have a personal adv3jjmcc module of bug fixes and gameplay tweaks. Triple endorsed on modify [Class]!

Why didn’t I pick up adv3lite back then? I had the mistaken impression that it was not yet mature, and didn’t ask any body.

All that said, there are plenty of deeply talented adv3 developers here whose support keeps it from feeling dead. I am still having tremendous fun with adv3.

9 Likes

At this point I kinda regret not just writing a new library from scratch. Although I have a lot of what I imagine are probably fairly atypical design goals. That is, compared to some notional “typical adv3 game”.

6 Likes

Lol, I think you kinda HAVE :stuck_out_tongue_winking_eye:

4 Likes

Now, my take…

I have even successfully shifted the dev of a large story from adv3 to adv3lite, a feat duly reported (and described…) here in past :wink:

Actually some of the main features of adv3Lite was anticipated in various adv3 contributed extensions (I call these “contribs”), by no less that Eric itself.

(I think that https://www.ifarchive.org/if-archive/programming/tads3/library/contributions/scenes.t is a major case in point; I recommend comparising this and adv3Lite’s scene system…)

Onward, I think that Zieg’s broad categorisation can be enough for planning; but on more specifics, the easiness of adv3lite coding came with a price, namely, a bigger story file, mainly because many thing which in adv3 are in specific classes are put straight in the Thing overclass, cutting many classes (e.g. Readable: an adv3 Readable in adv3Lite is simply a Thing with a non-nil ReadDesc) so every Thing borne with all flags, methods and variables needed for being nearby every adv3 class)

in the porting from adv3 to a3Lite, only two things was sacrificated; a custom posture, which was rather too simulationist, as was noted by too many alpha testers, and the transparency of a liquor cabinet (albeit I’m undecided about a sort of “booze label puzzle” I have lying around half-cooked, opening the cabinet is more than enough for putting the readables in-scope; incidentally, an a3Lite bottle can have a “label” synonym AND be readable, at the price of, well, questionable inputs like “read whiskey”; whose reeks of “alcoholmancy”…)

an a3Lite issue I have is the handling of thinking: personally I dislike having separate, say “crown” and “tcrown”, the latter for THINK ABOUT CROWN; I wonder why wasn’t implemented also a, say, “thinkDesc”; granted that the thinking mechanism allows thinking on abstract concept without dealing with scope, but there’s also simpler, much more material thinking… (remember that I think :wink: that THINKing is a much more immersive alternative to HINTS…)

on heavy modifying, I let the ouvre speak for itself: the successful separation of the siamese twins, TOUCH and FEEL:

// separating, once and for all, the siamese FEEL and TOUCH 
//240911: you siamese idiots, should be fully separated now !!
modify grammar predicate (Feel):

    'feel'  dobjList
    : 
    verbPhrase = 'feel/feeling (what)'
    missingQ = 'what do you want to feel'
;

DefineTAction(Touch);

VerbRule(Touch)
        'touch' dobjList
        : VerbProduction
        action = Touch
        verbPhrase = 'touch/touching (what)'
        missingQ = 'what do you want to touch'
;

modify Thing
touchDesc = "Touching {the dobj}, {i} don't discover nothing new."
basicExamineTouch() {touchDesc;}

dobjFor(Touch)
    {
      /* Obviously, we have to be able to touch it */
      preCond = [touchObj]
      verify() { }
      action()
      {
        /* show our "touch" description */
        display(&touchDesc);
      }
	}
	;
;

modify Actor 
feelDesc = "feeling {dobj}, {i} don't discover nothing interesting."
basicExamineFeel() {feelDesc;}

dobjFor(Feel)
    {
      /* Obviously, we have to be able to touch it */
      preCond = [touchObj]
      verify() { }
      action()
      {
        /* show our "touch" description */
        display(&feelDesc);
      }
	}
	;
;

speaks for itself on the modifying adv3Lite.

I think that is enough for now…

Best regards from Italy,
dott. Piergiorgio.

5 Likes

Mood.

3 Likes

@inventor200
Since some of your projects involved, IIRC, making use of TADS’ notoriously slow bignums, I’m surprised you aren’t lamenting not writing a whole VM from scratch…

EDIT: whoops, somehow ended up replying to the wrong user

3 Likes

I mean, that is why I switched to making IF-Octane lol.

3 Likes

That shouldn’t be necessary. You could just define:

+ Thought @crown
     "You think it would look good on the king."
;

If you want the player to be able to THINK ABOUT CROWN before the player character has encountered the crown, you can just define familiar = true on the crown object (which I assure here is the Thing used to define the physical crown). There shouldn’t be any need for a separate lcrown object just to implement this.

I’m not entirely sure what you mean here. I think you’re suggesting adding a thinkDesc property to the Thing class to handle THINK ABOUT WHATEVER. One potential problem is that this could cut across the way THINK ABOUT is currently handled in adv3Lite, but I think I’ve come up with a way round that which I’ll incorporate in the next update. This involves a modification to the DefaultThought class so that it will display the thinkDesc of the object it matches provided that object defines a non-nil thinkDesc property.

7 Likes

I said a new library.

3 Likes

Thanks for the warning and heads-up. My main chagrin is that I feel natural placing the PC’s thought on an object or location (or NPC…) under its definition instead of under the thoughtManager (and its rather prone-to-bug + construct; I often rearrange up and down inside the source files…)

So, I’m toying with this idea:

Modify Thought
location = [ToughtManager's programmatical name]

but I strongly suspect that this will heavily interfere with thoughtManager’s preinit…

Best regards from Italy,
dott. Piergiorgio.

2 Likes

I’m just making the changes to make that possible. The existing method of placing Thoughts under the thoughtManager will still work unaffected, but if there’s no thoughtManager defined in the game, THINK ABOUT will use the target’s thinkDesc instead. If there is a thoughtManager defined, and a DefaultThought is defined under it, that DefaultThought with also use the thinkDesc of the Thing or Topic matched.

6 Likes

Thanks, Eric !

Best regards from Italy,
dott. Piergiorgio.

3 Likes