-
Notifications
You must be signed in to change notification settings - Fork 11
Design Aims
The suffix -Lite in adv3Lite may suggest something cut-down and less functional than the parent adv3, but that would be misleading. Adv3Lite may have started out which some such conception but has evolved into something much more than a kind of baby adv3 or adv3-. If we were to start over, it might have been better to call it adv3Mod (where 'Mod' would imply both modified and modular. Here we explain the origins and the developing design aims of adv3Lite to show how it has grown into a feature-rich but potentially less cumbersome to the original adv3 library that comes with TADS 3 and why some TADS 3 Interactive Fiction authors may prefer it to the original adv3 library (which nevertheless remains a robust, feature-rich alternative).
Adv3Lite originated from two, or perhaps three, different sources.
The first of these was its author's experimental attempt to write a basic IF library as a fun programming exercise. In its earliest stages this comprised a fairly basic world model and an extremely primitive parser.
The second was Mike Roberts's Mercury library, which he began work on to provide a simpler alternative to the existing adv3 library, but never completed. The Mercury library did, however, reach the point of implementing a fully functioning sophisticated parser, several neat ideas such as routing player Commands through Doers, better ways of defining library messages and object vocabulary, a revised way of handling message substitution parameters (the mechanism that allows messages to adapt automatically to person, number, tense, and the particular objects involved) and a few other such things. On the other hand, it did not get as far as implementing a world model or any specific action handling, although it did have the basis of a Thing class.
When Mike Roberts realized that he was unlikely to find the time to get much further with his Mercury library, he invited anyone who cared to do so to take over what he had done so far and make it the basis of his own work. Since what was to become adv3Lite contained at least a basic world model but only a barely usable parser, while the Mercury library implemented a full functional parser (along with some other neat features) it seemed a good idea to take Mike Roberts up on his offer and attempt to combine the two. Adv3Lite is the result of this combination.
That said, adv3Lite differs in many respects from what Mike Roberts's vision for Mercury seems to have been, not least because adv3Lite ended up resembling adv3 more closely than Mike Roberts appeared to intend. One feature of Mercury that didn't make it into adv3Lite was a revised containment model in which all four types of containment (in, on, under and behind) were maintained through four separate lists on every Thing. This clashed with the more adv3-like way in which proto-adv3Lite implemented containment and so was largely dropped (apart from a few vestiges that still remain). Again, it looks as if the Mercury library intended all commands to be handled by Doers (although this isn't entirely clear), whereas adv3Lite handles actions in a manner much closer to that of adv3 (whose design appeared to the author of asdv3Lite to be basically sound).
The early iterations of adv3Lite, therefore, were taken up with knitting together the bulk of the Mercury library with existing proto-adv3Lite code into a coherent whole that ironed out any conflicts and duplications (a process that might still be traceable by software archaeologists or program code redaction/source critics). What did not change, however, were the original intentions of Mercury and adv3Lite to provide a simpler alternative to adv3, although the understanding of "simpler" evolved along with the development of the adv3Lite library.
Inform 7 made its first appearance around the same time as work started on adv3Lite, and offered what, at the time, appeared to be a revolutionary new method of writing parser-based Interactive Fiction. This in no way discouraged work on adv3Lite, but it did provide a further source of neat ideas (such as Scenes and Regions) which inspired the addition of analogous features to adv3Lite, along with a couple of extensions for implementing features such as Rules and Relations in a somewhat Inform-like way.
These various streams came together to result in an adv3Lite library that makes few compromises on functionality, but which nevertheless retains its original aim of being simpler and easier to use than adv3. How these seemingly contradictory aims were achieved will be described below.
To understand in what way adv3Lite ended up being 'Lite' in relation to adv3, it is first necessary to summarize why adv3 was felt, at least, in some quarters to be too complex for many game authors. In many ways adv3 was excellent, catering for every detail of world simulation that one could wish for. But this led to two commonly perceived problems. The first is that the adv3 class hierarchy ended up being massive, to an extent that many potential users found intimidating. The second is that adv3 provided many simulation details that many if most game could do perfectly well without (such as postures - whether the persons simulated in the game were sitting, standing, or lying - room parts (walls, floors and ceilings) and lighting levels, all of which game code then had to cater for simply because the adv3 library defined them and because its design was so tightly couples that there was no easy means for game authors to opt out of them.
The two simplifications aimed at by adv3Lite were therefore:
- To drastically cut down on the number of classes (especially those used to define simulation objects) without significant loss of functionality.
- To arrange the adv3Lite library in a far more modular fashion, so that beyond certain core modules, game code could readily exclude any functionality it doesn't need (and consequently not be forced to implement details such as character posture if it doesn't want to).
We'll say a bit more about modularity below. Simplifying the class hierarchy was largely achieved by abandoning adv3's strictly purist approach to object-oriented programming (at least in the way it related functionality to its class hierarchy) in favour of a more hybrid approach (somewhere between adv3 and Inform) in which functionality was in part controlled by a series of properties. So, for example, while adv3Lite does define a Fixture class (for convenience of use and clarity of game code), in adv3Lite it's simply defined as:
Fixture: Thing
isFixed = true
;
And, indeed, one could achieve exactly the same thing by defining the object in question as a Thing and setting its isFixed property to true. A less trivial example is the use of a lockability property, also defined on the Thing class, which can be set to one of notLockable, lockableWithoutKey, lockableWithKey or indirectLockable without the need to define a whole set of additional classes to handle these possibilities (as they might apply to both containers and doors).
The adv3Lite library is defined into three sections:
- The core library (the modules every adv3Lite game needs to work at all)
- Optional modules (modules that many or more games will probably use, but can be opted out of)
- Extensions (modules that offer more specialized behaviour that some games may need and can opt into)
(In this context, "module" pretty much equates to "individual source file, i.e., file with a .t extension).
The Core Library is what you get if you choose to create a game with adv3liter. It contains the parser, the mechanism for handling commands and translating them into actions, for starting and ending a game and running the turn cycle, and basic game simulation objects such as Things, Rooms, Doors. The Core Library implements enough to write a simple work of interactive fiction, although probably the main reasons for restricting oneself to using the Core library only (aka adv3Liter) would either be to set oneself a challenge or as a learning exercise aimed at mastering the core elements of the library before going on to anything else.
The Optional Modules are those that add functionality or at least convenience that most or at least many games are likely to need. For example, the extras.t file defines a whole lot of classes such as Container, Surface, Passage and Switch, many of which could be defined as Things without too much difficulty, soke of which add a bit more functionality, but all of which are likely to be commonly used and convenient to have. Other files add feature such as Daemons and Fuses, various kinds of EventLists, Menus, Hints, Scoring, Scenes and Pathfinding, which many if not most games are likely to find useful.
Together the Core Library and the Optional Modules make up the Standard Library, which is what you get by default if you start from the adv3Lite library. You can opt out of one or more of the Optional Modules if your game doesn't need them, but there is seldom any need to. The presence of a redundant module in your game code won't require you to implement anything you don't want to, and on any even moderately modern computer, won't make any significant impact either on compiled file size or speed of execution.
Extensions are a further set of modules that game authors need explicitly to opt into (i.e., include in their game builds) if they want to use them. They typically implement more specialist features that only a minority of adv3Lite games are likely to need. These include some of the features the main adv3Lite library excludes from adv3 (such as postures, room parts, weight, more sophisticated handling of smells and sounds, and, as from adv3Lite version 1.6, different lighting levels), some features borrowed from Inform 7, like rules and relations, and a few other things such as the objective or subjective passage of time (it's not a good idea to use both of those at once), viewports (modelling the view through a window or via a remote camera, for example).