
                                Adv770  FAQ

                                Version 1.7

                         Mike Arnautov, 17 Oct 2006


This Adv770 FAQ is based on queries and observations made by players of the
game.

Questions:

 1. Why bother? Adventure is history. Why re-hash it?

 2. So what's particularly special about this version? Or is it just same
    old Adventure with knobs on?

 3. Why did it take you so long to finish it?

 4. I get confused by all those Adventure versions and their
    relationships.

 5. Where do I find an Adv770 walkthrough?

 6. Why don't you publish the A-code source of Adv770?

 7. How many treasures are there in Adv770?

 8. After all that testing, are there any bugs left? And what should I do
    if I find some?

 9. A few passage directions in Adv770 differ from both Adv550 and Adv660
    - why?

10. Why just verb/noun commands? It's soooo primitive! Can't you write a
    decent parser?

11. Why didn't you take the opportunity to clean up all those horrible
    UK/US spelling discrepancies?

12. How does Adv770 compare in size with other versions of Adventure?

13. I hate your "little joke". It sucks! Why would you go and do something
    like that???

14. I keep getting lost in the dark forest. Was it really necessary to
    have it?

15. I am stuck! What should I do?

16. What's the minimal number of moves in which the game could be
    completed?

17. There is a Monty Python reference in the original Adventure, and some
    other references in Adv550. Are there any new ones in Adv770?

18. Why didn't you use of of the mainstream IF systems?

19. What are "text morphing" and "text switches" that you keep blurbing on
    about at every opportunity?

20. So what are the text handling improvements in Adv770?


============================================================================

Answers:

 1. Why bother? Adventure is history. Why re-hash it?

    My feelings exactly. Or rather, those were my feelings. Except that
    almost every time somebody connected my person with the author of
    Adv660, one of the first questions was: "Do you have any plans to
    expand it further?". It would seem that, there is an unsatisfied demand
    for adventure-style games of pure exploration, unencumbered by plot,
    complex NPC interactions and such-like.

    Once I started considering the idea at all, I realised that it would
    give me a chance to deal with some unfinished business in the 660
    points version. As anybody who played it will confirm, it has a number
    of loose ends and fairly pointless red herrings -- some inherited from
    earlier versions, some of my own invention. But above all, it has one
    awful cop-out: I couldn't work out a clever way of getting rid of the
    picnicking giant (which of course one must do in Adv660), and in the
    end, having had enough of the whole affair, I made the Jinn scare the
    Giant away and left it at that. And it had been bugging me ever since!
    Producing a superset of the 660 allowed me to deal with the matter to
    my satisfaction.

    Even that might not have been enough, but the idea got me thinking
    again about text morphing (yes, a simple version of that was invented
    by Dave Platt, even though most published versions of the code of
    Adv550 lack it), and about the ways it could be usefully extended.
    Which led to further thoughts on the subject of adventure text handling
    in general, and how it might be improved in novel ways. And in the end
    that did it. I am an improver. There is no better way of firing my
    creativity than giving me something to improve upon. Don't ask me to
    start with a clean sheet. :-)

----------------------------------------------------------------------------

 2. So what's particularly special about this version? Or is it just same
    old Adventure with knobs on?

    It's a bit of both, I suppose. It certainly was my intention to stick
    to the spirit of the original game, but I think that in some ways
    Adv770 is significantly different from its predecessors (and from many
    other adventure games).

    The most obvious difference is in the variability of the game's
    responses to many "correct"and "incorrect" commands. In this Adv770
    builds on the legacy of Adv550 and Adv660, but goes much further than
    either of these, in exploiting the text morphing features of the A-code
    engine.

    Once you start poking about, another difference should become obvious:
    I tried to ensure that the player can examine just about anything that
    the game refers to. For instance, the well-house has always been
    described as a brick structure, so it makes sense for the player to
    examine the bricks (or walls, or roof for that matter). Are there gold
    veins in a cave wall? Again, the player should be able to examine those
    too. Now, I don't claim that I've managed to be absolutely successful
    in covering everything, but the amount of effort that's gone into this
    aspect of the game is probably rather unusual. (And BTW, if you do find
    things I've missed, please let me know - I do want to fix even such
    small niggles.)

    Another difference is that while it retains the simple verb/noun
    command structure, Adv770 pushes this structure to its limits by
    allowing complex commands which are reducible to a series of verb/noun
    ones. So for instance DROP ALL BUT LAMP AND ROD THEN EXIT is a
    perfectly legal command.

    And the game also attempts to correct simple typos, while making care
    that in doing so it does not reveal anything the player should not yet
    know about.

----------------------------------------------------------------------------

 3. Why did it take you so long to finish it?

    When I started working on Adv770 in 1999, I never expected it to take
    four years, which is how long it did take in the end. Firstly, other
    aspects of my life kept "interfering". Secondly, it turned out to be
    surprsingly difficult to recruit good beta-testers. Thirdly, the three
    outstanding beta-testers who did eventually come forward, identified
    such a mountain of niggles in need of fixing, that I had to put in a
    lot of work after closing the first phase of beta-testing. This of
    course necessitated further testing afterwards... I am biased, of
    course, but I reckon the game's all the better for it.

----------------------------------------------------------------------------

 4. I get confused by all those Adventure versions and their
    relationships.

    To quote a famous physicist (yeah, OK, Paul Dirac, if you must know!),
    that's not a question but a statement. But I'll be kinder than Dirac
    and answer the implied plea for help.

    What you need is a good look at the Adventure Family Tree
    (http://mipmip.org/adv/advfamily.shtml), as compiled by Russell
    Dalenberg.

----------------------------------------------------------------------------

 5. Where do I find an Adv770 walkthrough?

    You don't. Not for a while yet. Not if I can help it. It was hard
    enough to write, so try putting some thought and effort into playing
    it!

    And no, there's no hint-sheet either, but there is something better
    than that - me! I offer a personalised hint service (mla@mipmip.org),
    tailored to players' specific circumstances. Not giving away answers,
    but nudging players in the right direction. It is ever so much more
    satisfying to have the "aha!" moment of your own, than to be simply
    told the answer to a problem.

    Why am I doing that? Simple. As far as I am concerned, the game is and
    will remain in the "gamma-testing" stage, and a direct contact with
    players is extremely useful in highlighting areas for further
    improvement.

----------------------------------------------------------------------------

 6. Why don't you publish the A-code source of Adv770?

    Partly for the same reason as not providing a walkthrough. But there is
    another reason too. The game has a "deep secret" buried in it, and it
    would seem that nobody's yet come within a sniffing distance of it. I
    am sure I'd hear about it if somebody had! :-) The nature of this
    secret would be very obvious even from a cursory examination of the
    A-code source, so for the time being the derived C source is all you
    get.

----------------------------------------------------------------------------

 7. How many treasures are there in Adv770?

    Let me answer this one very carefully: in order to achieve the maximal
    score, you need to collect 41 treasures.

    Why am I being careful? Because the question can be answered in several
    slightly different ways. The above reply has the advantage of being
    concise and scrupulously correct, as well as unambiguous.

----------------------------------------------------------------------------

 8. After all that testing, are there any bugs left? And what should I do
    if I find some?

    I would be AMAZED if there are no bugs left, despite the valiant
    efforts of several testers, and Dave Picton's post-release bug safari.
    That's not to say I am happy to leave any remaining insect life
    unmolested. If you find some, please check the Adv770 bug list
    (http://mipmip.org/adv770/bugs.shtml), and if the bug isn't there,
    report it to me (mla@mipmip.org). I'll do my best to despose of the
    little so-and-so in a maximally humane manner.

----------------------------------------------------------------------------

 9. A few passage directions in Adv770 differ from both Adv550 and Adv660
    - why?

    True, I made a couple of minor changes in the old parts of the cave
    geography. This was in response to some complaints from Adv660 playes
    unfamiliar with earlier versions, who were objecting to two quite
    un-obvious, and rather pointless passage U-bends near the Hall of the
    Mountain King.

    Specifically, I swapped the Hall exits towards the Morion Room and
    towards the Tool Room, which got rid of one U-bend. I also straightened
    the passage leading to the Spherical Room. It looks like I can't win,
    though - now I have an Adv550/Adv660 player complaining about these
    changes. :-)

    It would seem that whatever I do now, somebody will complain, so on
    balance I think the changes stay. The intro may comment on cave
    passages twisting a lot, but from my reading of player logs, it would
    seem wiser not to have un-heralded passage U-bends quite so near the
    start of the game.

    Once we are at it, it is also true that, as Dave Picton observed,
    Adv660 dropped a couple of locations from the Adv440 map, even though
    they didn't clash with Adv550. Adv770 also omits these locations.

    One is the Stable, just off the Chapel - removed because it suggested
    some further game development, and nobody could work out or remember
    what had been intended there (not even Jack Pike or Peter Luckett
    themselves!):

        You are in a room that appears to be a stable for a fearsome
        animal. Against one wall is a battered and dirty trough that is
        quite empty and on the other wall is a huge harness. Beside the
        harness is a small window that overlooks a courtyard. The courtyard
        is deserted and shows no sign of any recent activity. At the far
        end of the stable is a wooden partition that has numerous dents and
        holes in it and you can see that it is securely fixed to the
        massive stone walls so that whatever is behind it cannot get out.
        If you listen carefully, you can hear the muted sounds of growling
        and the scratching of claws against wood. The only exit is the way
        you came in.

    The other is an extra location on the way to the dragon from the Slab
    Room. It had features strongly suggestive of some purpose, but in fact
    quite pointless and thus liable to mislead players:

        You are at the west end of a very large and long tunnel. To the
        west the way is almost blocked by rock falls. Several very large
        footprints can be seen indistinctly in the dust. High above you
        there is a huge arrow on the wall pointing east.

    On the plus side, though the dwarf tower steps locations first appeared
    in Adv440, they were commented out in that version. Adv660 reinstated
    these locations, but made no use of them - the tower essentially became
    a large red herring, which fact was slyly acknowledged by the drawing
    above its entrance. Adv770, on the other hand, adds to the tower, and
    makes it an essential part of the game.

----------------------------------------------------------------------------

10. Why just verb/noun commands? It's soooo primitive! Can't you write a
    decent parser?

    I imagine I can. And one of these days I might do just that, just for
    the fun of it. But for Adv770 I deliberately decided to stick with the
    "primitive" verb/noun command structure. This may not be immediately
    obvious, since the parser does allow commands such as DROP TREASURE
    EXCEPT RUG, RING AND SPYGLASS or GET ALL, THEN SAY FEE FIE FOE FOO, but
    these are trivially reducible to a series of verb/noun commands. What
    the parser lacks is the ability to process adjectives or prepositions
    with associated indirect objects. The lack of adjectives is no great
    grief in Adventure, which was written and extended with that
    restriction in mind. It is the inability to use prepositions and
    instruments that one has to adjust to when playing the game.

    So, why only verb/noun? There are three reasons.

     1. All the ancestral versions of the 770 were verb/noun games.
        Tradition is not a strong enough reason to carry on in the same
        manner (a deeply un-British thought though this may be! :-), but
        once I started thinking about Adventure with a more sophisticated
        parser, I quickly came to the conclusion that I would have to do
        one heck of a lot of work on the inherited parts of the game, in
        order to allow for the much greater variety of possible commands.
        This would have made it much harder to preserve the character of
        the game to my satisfaction.

     2. More generally, it has long been my conviction that
        over-sophisticated parsers were bad news for IF games. This is not
        to say that complex command parsing is bad in itself. It's just
        that such parsers arrived far too early, before some positive
        features of Adventure command handling had a chance to become the
        established norm. Instead, the norm is now a parser behaving like a
        pedantic moron, which detracts from the pleasure of playing the
        game. It also deeply offends my software designer sensibilities.
        Yet this state of affairs appears to be accepted as something
        natural -- an inescapable fact of life, to which novice players
        have to learn to adjust. On rare occasions when I get sufficiently
        irritated to bring up the subject in public, the response is blank
        incomprehension, often coupled with an outright denial of any such
        problem.

        Yet starting with Zork, I've played too many adventures with
        parsers manifestly too powerful for their own good. Unless handled
        with great care, such a parser doesn't add to one's enjoyment of
        the game. Instead, it exposes some of the inadequacies of the game
        itself. The more freedom the player has to express himself, the
        more often will the game respond "sorry, I don't understand", or
        worse, react in an inappropriate manner. Even responding to parsing
        failures becomes tricky. My pet hate is this kind of exchange:

           ? dig 
           You must supply a direct object. 
           ? dig soil 
           You must supply an indirect object. 
           ? dig soil with spade 
           You can't do that! 
           ? AAAAARRRRGGGGGGhhhhhh!!!!...... 
           You can't do that! 

        Admittedly an extreme example, but you have probably met some less
        extreme variants yourself. The temptation is strong for the writer
        to develop the world, the plot (if there is one :-), the characters
        (if there are any) and not to worry about making sure that the game
        can sensibly respond to all possible commands permitted by the
        parser. As the result the player is left floundering in the
        exponential riches of all possible, syntactically correct commands,
        without any clear idea as to the necessarily limited parsing
        sophistication, which is actually supported by the game. You can
        bet money on the fact that the author programmed for complex
        commands only where necessary, simply because it would have been
        too much work to do more than that.

        Avoiding this pitfall is hard enough even in verb/noun games,
        though things are easier with a primitive parser: if the player
        can't put his command into the verb/noun format, he is almost
        certainly on the wrong track anyway. And the game can say so loud
        and clear.

     3. It is furthermore my belief that the discipline of a self-imposed
        constraint is very healthy for channeling creativity in any field,
        IF being no exception. Sticking to verb/noun commands constrained
        the nature of problems I could pose to players in Adv770, making it
        much easier to avoid the sin of "Zorkishness". Now, I have nothing
        against Zork, honest! But it has a flavour very different from
        Adventure, and in my judgment some of Adventure expansions sinned
        by mixing the two rather tastelessly. Having a simple parser made
        it much simpler to avoid the temptation. Whenever I could not work
        out how the player would solve a problem using verb/noun commands
        only, I eventually came to see that the problem in question was
        inappropriate for Adventure and had to be modified or dropped.
        (There are still vestiges of one such dropped problem in Adv770 --
        I didn't have the heart to zap the relevant descriptions.)

----------------------------------------------------------------------------

11. Why didn't you take the opportunity to clean up all those horrible
    UK/US spelling discrepancies?

    It's a dilemma, this one, isn't it? In the end I decided to ignore the
    problem, rather than giving Crowther, Woods and Platt an English
    accent, or pretending that Luckett and Pike wrote in Americanese. In
    case you ask who are all those people and why they matter, they wrote
    the ancestral versions of Adventure. See the Adventure family tree
    (http://mipmip.org/adv/advfamily.shtml).

    Me? Well, what about me? My accent is unique, but I tend to English
    spellings. :-)

----------------------------------------------------------------------------

12. How does Adv770 compare in size with other versions of Adventure?

    It's bigger.

    Oh, you wanted to know how much bigger? Well, that's a bit hard to
    measure. But let's try comparing it with Adv550 and Adv660. The below
    table originally included object/NPC counts, but I've taken them out,
    because what appears to a player as a single object, may or may not be
    one, and furthermore the distinction between objects and features
    (pseudo-objects) is really too arbitrary.

       Game      Bytes of text   Locations   Vocabulary   Lines of A-code

      Adv550        120203          248          425           7358
      Adv660        226676          329          611          12805
      Adv770        508778          478         1239          33722

    Mind you, "lines of code" is rather deceptive. If I were to re-write
    Adv550 using all my A-code improvements, its code line count would
    shrink, and to a lesser extent, the same would be true for Adv660.
    Ditto for the number of text bytes for both games.

    Anyway, the upshot is -- it's quite a bit bigger.

----------------------------------------------------------------------------

13. I hate your "little joke". It sucks! Why would you go and do something
    like that??? Take it out!

    Because I felt like it. And it does have a purpose too. Far too many
    players seem to approach the game on an "adventure auto-pilot" and I
    would like to persuade them to switch it off when playing Adv770.

    But OK, too many players have moaned, so I have relented. A bit,
    anyway. From version 1.61 the problem is easier to solve.

----------------------------------------------------------------------------

14. I keep getting lost in the dark forest. Was it really necessary to
    have it?

    The dark forest was there in Adv660, but it would seem that few players
    explored around the house. Now that they have to, they keep getting
    lost. When this happens to you, thrash your way out and then pay
    attention to forest descriptions. The "you'll get lost there"
    directions are easy enough to spot.

----------------------------------------------------------------------------

15. I am stuck! What should I do?

    Firstly, use the HELP command at places where you are stuck. There is a
    number of hints available in the game, but players seem to be very
    reluctant to ask for help.

    Secondly, examine things. This is more important in Adv770 then it was
    in any of its ancestral versions. In fact you should examine things
    anyway - important or not. I went out of my way to allow you to examine
    things, even if they are just irrelevant scenery. You may even enjoy
    some of the responses. :-)

    Thirdly, do try to be inventive (but make sure you save the game, or at
    least "memorize" it).

    Fourthly, if still stuck, drop me a note (mla@mipmip.org) -- I am
    always happy to help by supplying obscure hints.

----------------------------------------------------------------------------

16. What's the minimal number of moves in which the game could be
    completed?

    I've seen an anonymous player run through the game in 1184 moves. Can
    one do better? I don't know. Over to you! :-)

----------------------------------------------------------------------------

17. There is a Monty Python reference in the original Adventure, and some
    other references in Adv550. Are there any new ones in Adv770?

    Certainly! For those who enjoy reference hunting, there's a list of
    reference sources (http://mipmip.org/adv770/references.shtml), sorted
    by the version of the game in which they first appeared. Let me know if
    you find some not on the list, which you think should be included -- I
    may have missed some.

    Warning: some of these references do not occur on the main "play-path",
    and some can be only found by players who attempt really strange
    things. Then again, players do -- I've seen enough game logs to be sure
    of that. :-)

    The list is not meant to include absolutely everything. Some of the
    references embedded in the game are simply common figures of speach,
    originally derived from a literary quote. Others are too obscure, and
    will be only comprehensible to very few players, if any, since they
    refer to specific persons or incidents. E.g. if you happen to run into
    George, he is quite real, but I'd be amazed if any Adv770 players
    actually recognised him. (Hi there, George! No offence meant -- 'twas
    Blundy's spirits that made me do it! :-)

----------------------------------------------------------------------------

18. Why didn't you use one of the mainstream IF systems?

    Mainly because I am lazy. A-code was something I already knew, had put
    some work into, and it would do the job. Why bother to learn anything
    else? "Portability!" I hear you cry. Well, A-code is as portable as any
    ANSI C program, because a C compiler and an A-code-to-C translator
    (also written in C) are all you need to build an executable from an
    A-code source. Yes, I know that ANSI C isn't believed to be very
    portable, but it all depends on what you do with it. If you stick to
    the basics, there is no problem. And since I don't hold with
    new-fangled innovations such as colour, mouse control, split windows
    etc., I don't find portability to be a constraint. A-code games have
    been built on a sufficient number of sufficiently different platforms
    for me to say that with some confidence.

    But there was a deeper reason as well. As noted in (1) above, one of
    the strong motivations for writing Adv770 was to implement some pet
    notions of mine to do with ways of handling text, and also with some
    other aspects of IF games. That meant that I needed to be able to twist
    the IF engine itself, and the A-code one was handy, and what is more, I
    already knew my own version of it backwards. So it was a logical choice
    for experimentation.

    And finally, call me a Luddite, but I really prefer A-code (version 11)
    to other mainstream systems. That's my preference. I don't wish it on
    you. OK? :-)

----------------------------------------------------------------------------

19. What are "text morphing" and "text switches" that you keep blurbing on
    about at every opportunity?

    Text morphing is the term I use to describe any consistent technique
    which has the effect of "spontaneous" changes in text being output,
    without the game code making explicit adjustments to the text between
    its uses.

    Here's a specific example from Adv770 of one particular aspect of the
    technique. The game defines a piece of text with the symbolic name
    spoon.still.tarnished. To print a text (morphed or not), A-code uses
    the standard program instruction say (not to be confused with the
    player command SAY) like this:

    say spoon.still.tarnished

    Using this instruction repeatedly, with no other intervening code,
    results in:

     1. First time: You rub the spoon, and it becomes marginally cleaner,
        but not any less tarnished. Ravages of age cannot be undone with a
        rub or two, as you will doubtless discover with years to come...

     2. Second time: You rub the spoon, but it is already as clean as it
        could be, though just as tarnished as before. Why this compulsive
        interest in a worthless spoon? Were you hoping to discover that it
        was a rare example of a Bohemian Ear Spoon? Sorry... it's just a
        piece of old junk, washed up on the shores of this game by tides of
        the sea - or tides of sewage, as the case may be.

     3. Third time: You rub the spoon and nothing happens. I hope this
        doesn't come as a surprise

     4. Thereafter: You rub the spoon. Nothing happens.

    Yes, I am wall aware that the same effect can be achieved in
    practically any other language, including (manifestly!) the machine
    code. However, a system (such a A-code) which offers a support for text
    morphing, has to have this functionality built into the language in a
    generic form, so that you can use it or ignore it, as suits. To use an
    analogy, you can do C-style data structures in Assembler, but why
    bother when C (and other languages) provide you with a ready-made
    framework for it?

    The way the above example works can be seen from the definition of
    spoon.still.tarnished (note that the use of upper case in the
    definition is due to my coding conventions - A-code is case
    insensitive):

      TEXT increment SPOON.STILL.TARNISHED 
          You rub the spoon[, and it becomes marginally cleaner, but not
          any less tarnished. Ravages of age cannot be undone with a rub or
          two, as you will doubtless discover with years to come../, but it
          is already as clean as it could be, though just as tarnished as
          before. Why this compulsive interest in a worthless spoon? Were
          you hoping to discover that it was a rare example of a Bohemian
          Ear Spoon? Sorry... it's just a piece of old junk, washed up on
          the shores of this game by tides of the sea - or tides of sewage,
          as the case may be/ and nothing happens. I hope this doesn't come
          as a surprise/. Nothing happens].

    In effect, text morphing replaces procedural handling of text with
    declarative structuring of text. All the associated house-keeping is
    performed by the A-code kernel, by treating all texts as objects,
    posessing internal attributes and methods. The adventure writer only
    needs to know the declarative syntax. The rest happens automagically.
    And if this morphing syntax is not present, the text is just a text
    with no special properties.

    You can judge how useful I find the technique, from the fact that at
    the time of writing, 3415 text definitions in Adv770 contain 1298 text
    switches (lists of text components, as in the above example). Yes, all
    right, one *can* overdo it. I admit the following to be a bit over the
    top. It's economical, but the result is rather hard to read. I was
    learning the use of my new tool, OK? :-)

      TEXT GRATE.NOW 
          [The grate/=/I am taking the liberty of assuming that you meant
          to unlock the grate first. It] [clicks itself/is now]
          [locked/unlocked][/. Anticipating your next wish, I've opened it
          for you as well/ and opened].

    These are just trivial examples of text morphing. A fuller description
    is beyond the scope of this FAQ.

----------------------------------------------------------------------------

20. So what are these text handling improvements in Adv770?

    They are not specific to Adv770, but form a part of the version 11 of
    the A-code engine. Some will be apparent to players, since they are to
    do with handling of player's input, which is also text:

     1. Approximate matching

        Everybody makes mistakes in typing. The A-code parser now attempts
        to correct single typo errors in words typed in by the player.
        Obviously enough, great care has to be taken that typo-correction
        does not reveal the existence of words the player is not supposed
        to aware of yet. Less obviously, experience shows that to avoid
        massive confusion, it is just as important to explain to player
        exactly what correction was performed. The A-code kernel allows the
        adventure author to suppress approximate matching, ignore
        approximate matches or accept them, optionally reporting such
        corrections to the player.

     2. Disambiguating noun abbreviations in a context-sensitive manner

        A-code engine always allowed players to use minimal unambiguous
        abbreviations. From version 11 A-code does its best to work out
        from context what is the player likely to mean by using an
        ambiguous abbreviation.

     3. Scanning of recent descriptions and messages for unknown words

        Players often go to great length in attempting to manipulate
        features present in location, object or event descriptions, even
        though these features are mere "window-dressing". The A-code engine
        now keeps a list of all words used in any output produced by the
        game since the player last moved. If a word entered by the player
        is not found in the vocabulary, this list is searched and if a
        match is found, a flag is set, enabling the game code to tell the
        player that he is wasting his time.

        To my surprise, this innovation proved less useful than I expected.
        Firstly, I was forced to introduce the additional rule that only
        words longer than four characters were to be placed in the "scenery
        list" to avoid confusing players. Secondly, despite my efforts to
        create a variety of responses, the result was still too mechanical
        to my taste. Eventually I added code explicitly handling all
        meaningful scenery words, though the scanning mechanism is still
        there, to intercept whatever I might have missed.

     4. Inferring the meaning of syntactically bad constructs

        Even though Adv770 carries very explicit instructions on the use of
        commas as object list separators (as in "get lamp, keys"), and of
        semicolons (or full stops) as command separators (as in "get
        bottle; read notice"), players persist in using commas instead of
        semicolons to separate commands. The parser now attempts to infer
        and correct such "inappropriate" use of commas, though this is not
        always possible.

     5. Hiding nouns not yet encountered by the player

        A-code now provides dynamic vocabulary handling. Firstly, the game
        refuses to acknowledge references to objects not yet seen by the
        player. This is particularly important because the parser allows
        abbreviations and approximate matching, which between them could
        otherwise reveal more than the game author intended. Secondly, a
        special A-code directive is provided to enable construction of noun
        lists, which automatically hide nouns according to a nominated
        object flag (the SEEN flag in the case of Adv770). This allows the
        author to provide a safe vocabulary listing, limited to nouns
        applicable to objects already encountered by the player.

     6. Responding correctly to errors in "get/drop all" commands.

        You wouldn't expect this to be a problem. I didn't when I decided
        that error reporting could do with some improvement. But the game
        has to cater in a natural way for all possible permutations of the
        following factors:

          *  Non-specific "objects" all and treasure can be used with the
            get and drop verbs.

          *  The except syntax may be used with these non-specific
            "objects".

          *  Errors of three different types may occur within any command,
            including an exceptions list: a word may be completely unknown,
            it may be an unambiguous (corrected) typo or it may be an
            ambiguous (uncorrected) typo

          *  Player may be wearing some objects and may or may not have
            other objects to drop.

          *  A get/drop exception list may contain objects which are not
            available for getting/dropping. In the case of a get command,
            they may be already carried by the player, or they may be just
            absent altogether.

          *  As a matter of principle, even the same repeated error should
            result in at least a small variety of responses.

        It looks less simple now, doesn't it? :-) But getting it right does
        matter!

    Other innovations are to do with A-code handling of text: implicit text
    qualifiers, text nesting, tying and gluing. These probably wouldn't
    mean much to you anyway, unless you have a special interest in
    adventure writing systems and techniques. One of these days I'll get
    around to a fuller description, just in case somebody might be
    interested.

============================================================================

    Mike Arnautov (mla@mipmip.org), 17 Oct 2006
