Is ADV3Lite Even Needed?

Authoring TADS
21

You can separate TADS 3 and adv3 easily enough; just don’t include the adv3 library in your project. But what you then have is a programming language without a world model, not something you can write Interactive Fiction it at all (unless you’re prepared to build the entire world model, parser and all, from scratch, but that’s not a challenge most IF authors want to take on).

The adv3 library doesn’t make it easy to achieve a clean split between “core” classes and “add-ons”, because everything is so tightly integrated and coupled together. One of the aims of the adv3Lite library is to make precisely this split easier to achieve. I don’t know if you’ve looked at the adv3Lite manual but it’s divided in precisely this way, with a section on “core” classes followed by one on the optional extras. The adv3Lite conversation system, which can get quite complex, is effectively one of those optional extras; if you don’t want it, you can simply exclude the entire file in which it resides (and, if you wish, replace it with your own implementation).

I did initially think in terms of an “adv3min” which might be closer to what you had in mind, i.e. an absolutely minimalistic library with a totally barebones world model, but I quickly came to the conclusion that it would be too minimalistic to be of any practical use in writing Interactive Fiction. I suspect then that we wouldn’t be in agreement on what needs to be included in the “core” library and what constitutes an optional extra; there is in any case no objectively correct “right” answer to that, it’s simply a judgement call on which people will inevitably disagree. My concern is that if you leave too much out of the core you risk actually making it harder for people by forcing them to reinvent commonly-used wheels. To you “Taking away the complexity without removing the sophistication” may look like a recipe for failure, but from my perspective it’s a necessary compromise.

Experience suggests that a novice pretty soon will need doors and connectors (a door, after all, is just a special kind of connector); these are not easy thing for most novices to craft unaided. As I said, if you don’t want a conversation system you can easily ditch actor.t and you don’t need to use it (it’s much easier to get rid of than it is in adv3, since adv3Lite is a lot more modular). The “core” library of adv3Lite doesn’t really contain any “exotic special cases” that I can see (though perhaps your notion of what constitutes an “exotic special case” in Interactive Fiction differs from mine).

One might perhaps question some of your assumptions, such as that novices in general will only require a rudimentary conversation system, and that they’ll always be ready to reconsider if they really need x, y or z. Maybe it would be better if they were prepared to reconsider that, but many novices seem to me to be a bit more ambitious than you imply, and they don’t always give up that easily on their more ambitious ideas. Again, a rudimentary conversation system makes it hard to produce anything but a rudimentary conversation. Maybe that’s okay if that’s all your game needs, but if a novice wants a to write game in which interaction with NPCs plays a significant role, a rudimentary conversation system may very quickly become extremely limiting, and devising a more sophisticated one from scratch may be a bit of a tall order for a novice. Of course you could argue that the absolute novice would be well advised to stay away from something as difficult as conversation in the first place, and there may be some wisdom in that, but at some point along the line the more ambition not-quite-such-a-novice will often want to tackle more than rudimentary conversation, and if the library s/he’s using doesn’t provide for it, s/he may be a bit stuck.

To put it more briefly, adv3Lite is intended to be scalable, so that the complete novice can indeed start with the kind of core basics you envisage, but having invested time and effort in learning the basics of adv3Lite can go on using to to a higher degree of sophistication without having to move to adv3 (or some other system) straight away. If adv3Lite didn’t possess that potential, it would simply be a throwaway learning tool, not a serious contender as an IF library at all.

22

Yes, “scalability” is probably the word I’ve been looking for all the time…

I do have my doubts that it’ll ever be possible to implement a sophisticated world model that a novice could master easily; the complexity lies in the nature of the task, not in the use of the tool. But I’ll check the adv3Lite manual and give it a shot, and let you know how I’m faring with that.

Cheers, and thanks for the explanation,

syzygy

23

Quite so. But unless the world model has a reasonable degree of sophistication it’s probably not going to be possible to write any worthwhile IF in it; at least the danger is that even a novice would pretty quickly run up against the limitations of the system. That’s why I suspect that scalability up to at least a moderate level of sophistication is the least bad option.

That would be great! You might also like to know that there’s also an adv3Lite tutorial in preparation which is aimed more at the novice. (The manual is more of a reference tool, even though it does try to present stuff as “core” and “optional” along the lines indicated). If you think you’l like to take a look at the tutorial, drop me a line and I’ll send you what I’ve done so far (it’s incomplete and only at the draft stage, though).

You’re welcome!

24

Your descriptions of what you want adv3lite to be are making me wonder if “lite” was really the right name for it. Intuitively I’d assume the “lite” version of a library is one with less in it. But it sounds like what you’re going for here is a library with stuff layered instead of monolithic, which isn’t necessarily going to be lighter that way - just more “peelable”.

The real intuitive implication of calling it “lite” is that people will think “If I use this there’s going to be a lot missing” rather than “if I use this I can choose to have stuff missing.”

Right now I’m sticking with adv3 because it’s all there. If the intent is to eventually get all the functionality from adv3 into adv3lite but have it organized as separate modules that can be added or removed at will, that may change things.

25

How can you criticize something if you never actually used it?

26

If you look at the various descriptions of adv3Lite features I give at http://ericeve.livejournal.com you’ll see that adv3Lite is indeed intended to have less in it than adv3; it is not simply a layered version of the same thing. In particular, to reproduce the text of one of the earliest posts there:

First, adv3Lite omits many of the features that not many games use in practice but which together help to make the adv3 library so complex. These include postures, room parts, different lighting levels, complex sense passing, the option for real-time processing, and the transcript. It’s not that these are never needed in a game, and where they are the standard adv3 library probably remains the best choice; but a great many games don’t really need them and the adv3Lite library is able to achieve considerable simplification by leaving them out.

Second, adv3Lite drastically reduces the class hierarchy, which is the other main feature of the adv3 library that some of its users (or would-be users) find particularly daunting.

27

Well I guess in that case in answer to the thread topic I’d say I probably won’t be using adv3lite then. The fact that adv3 is a very large class tree with lots of pieces doesn’t really give me any trouble usually. I’d rather have the complexity and not need it than the other way around, as switching from adv3lite to adv3 halfway through development would probably be a lot more effort than just dealing with adv3 being more complex than I needed. Dealing with having to dig through lots of documentation of classes and subclasses and subclasses to find the bit I’m looking for is pretty standard fare for dealing with libraries in OOP systems. Dealing with, for example, the many different types of Container in adv3 isn’t nearly as daunting as dealing with the many different types of Stream in Java.

28

I suppose it’s fair to say that if you don’t have a problem with adv3’s complexity you’re not in the target group of a project that aims to make a library for people who have a problem with adv3’s complexity.

29

Then, as Juhana remarks, you’re not part the target group at which adv3Lite is aimed. Not that there’s any reason at all why you should be; the fact that adv3 has a very large class tree with lots of pieces doesn’t give me much trouble either, and of course I recognize that there are plenty of people who are perfectly happy with adv3 (myself among them). adv3Lite is in no way intended as a replacement for adv3, but simply as an alternative for people who find adv3 a bit too daunting (which clearly doesn’t include you). (Of course that doesn’t mean I mightn’t be tempted to use adv3Lite once I’ve finished it; it does have one or two nice features that aren’t built into adv3).

Of course it would, and I wouldn’t recommend that anyone attempted such a switch (except, perhaps, if they were so very early on in a project they had little or nothing to lose by doing do). Moreover, if you’ve got a game that really needs all the power, complexity and sophistication of the adv3 library, then that’s almost certainly the right tool to use for the job.

Sure, and if you’re happy doing that (and the TADS 3 Library Reference Manual goes a long way to making it relatively painless, IMHO), then you’re probably right to stick with adv3 (which I’m not knocking for a second). It’s just that not everybody is!

30

Well, yes I know, but … you did ask, so I’m weighing in. If you start a thread with the title “Is ADV3Lite Even Needed?”, then it’s perfectly legitimate for someone to weigh in with a vote of “not for me”.

31

Eric didn’t start the thread, mind you. :slight_smile:

32

Fair enough.
Still, my point stands that what I was saying is a legitimate answer to the question in the thread, even if Eric Eve isn’t the one who asked it.

33

Isn’t that why Unicode was invented? Looking at the TADS docs, I see that it indeed has Unicode support, and uses that internally. That makes me wonder why “us-ascii” is still the default in code examples and things like that. Wouldn’t it be better to get everyone to use Unicode? (Unless I’m mistaken, UTF-8 is pretty much the standard encoding on Mac and Linux, and most people on Windows are using the workbench.)

34

The default character set for all source files can be specified in the makefile. You only need to specify it in the source file if it’s different than what you’ve set as the global default. The option is “-cs”:

-cs xxx - source file character set is 'xxx'
35

Workbench is unable to display and edit files in unicode (it’s editor on windows inherits system default codepage and cannot be switched - I’ve asked and it’s impractically lots of work to change this limitation now, see bug #146). So I’m sometimes switching between encodings on the fly if I need to do some debugging in Workbench. And I know about other people using workbench too. And as I’m mainly developing on linux in unicode and activelly using some extended typographical character, it can be nice feature, that one can mix encodings a little.

So what one can see as a “clearly a confusing line” can be quite a nice feature for other. It’s not a big deal, I’ve just offered a different point of view.

36

Yes, adv3lite (or something like it) is absolutely needed.

adv3 is complex and intertwined in a way that makes it impossible to just ignore the pieces you don’t want to use. adv3 also is complex in ways that force you to have a deep understanding of how the underlying library code works in order to achieve even simple changes. (Do I need to override this particular method in the verify stage, or the check stage? What on earth is producing this particular bit of text?)

As someone who has gone back and forth between T2 and T3, I can say that every time I go back to TADS 2, it feels like a breath of fresh air. I can refresh my memory on the whole library in a couple of hours and immediately start turning out something that matches my vision. It’s fun. When I dive into adv3, it is grueling every step of the way. The end result is very polished, but it feels like work, not a hobby. If I lived in some parallel universe where I worked professionally as a programmer of interactive fiction, it would be well worth it to master adv3. As it is, I revisit IF programming sporadically, and I just don’t retain the details of the adv3 library after a long break from it.

It’s this last point that Michael J. Roberts emphasized when he announced his vision for TADS Mercury. He pointed out that, ironically, he only codes IF sporadically, and adv3 had gotten so big he noticed it was hard for him to keep it all fresh in his head as a casual programmer of IF.

I think the TADS 2 library hit a really nice sweet spot in terms of power and ease of use. However, there are a few specific things I want that are only possible in TADS 3:

  • the underlying programming language improvements
  • The nested + syntax
  • Templates
  • shorthand for various event cyclers
  • Ability to compile for the web UI
  • Optional access to adv3’s more sophisticated conversation system
  • Optional access to adv3’s automatic exit listing system
  • Optional access to adv3’s hint menu system

Notice that on this list, nearly all the things are about the language, not the library. And actually, exit listing and hint menu extensions are available for T2. So as far as adv3 the library goes, the only thing I really covet is the enhanced conversation system.

Basically, my ideal IF development system would be a port of the T2 library to the T3 language, with a few of the best library extensions available as add-ons. That’s not what adv3lite, but adv3lite is clearly moving in the right direction – away from complexity and towards something more modular.

I’ve been playing around with adv3lite, and one thing I’ll say is that Eric Eve is amazingly receptive to feedback. If you have even the slightest interest in a “lite” T3, you absolutely should try it out, because now is the window of opportunity where you’ll be able to influence its direction and shape the final result.

Actually, I’ll go further than that and say that the name “adv3lite” doesn’t do justice to what Eric has created. The reality is that adv3lite is very comparable in power and expressiveness to adv3. In fact, it includes some powerful new concepts that Michael developed but has not yet added to adv3 (e.g., Doers which can be used to create Inform-like rules) and some things Eric borrowed from Inform like scenes and regions. For the most part, Eric has just smoothed out the rough edges of adv3, making it simpler to understand and customize, and making it easier to ignore the parts of the library you don’t want to use.

So really, even if you’re not in the market for a “lite” version, you might want to check out adv3lite. You may just find you like it better.

1 Like