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. :-)

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.

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.

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, as compiled by Russell Dalenberg.

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, 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 an "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.

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.

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.

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, and if the bug isn't there, report it to me. I'll do my best to despose of the little so-and-so in a maximally humane manner.

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.

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 general belief (and personal experience) that the discipline of a self-imposed constraint is very healthy for channeling creativity in any field, IF being no exception. To quote James Falen:

   Structures, strictures, though they bind,
   Strangely liberate the mind.

   Besides, 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 astral imp and the related descriptions; maybe he'll feature in Adv880, which players keep enquiring about.)

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.

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

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.

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.

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.

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.

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 -- I am always happy to help by supplying obscure hints.

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

Certainly! For those who enjoy reference hunting, here's a list of reference sources, 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! :-)

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 the current version of A-code to other mainstream systems. That's my preference. I don't wish it on you. OK? :-)

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.

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.

It would be a lot of work. And I'd want to put a lot of development work on the A-code engine first. So I am not saying no, but I am not saying yes either. :-)