- Why don't I get the browser display?
Probably because you already have the appropriate browser running,
and it is either minimised out of the way, or obscured by other windows.
Or maybe you are using tabbed browsing and the game simply opened
a new tab in the browser.
That's assuming that you are using a browser-capable version. Browser
display is only used on Unix/Linux/MacOS and only since game version
1.89. On Windows it only came with version 2.05.
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
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
And the game also attempts to correct simple
typos, while taking care that in doing so it does not reveal
anything the player should not yet know about.
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.
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, as compiled by Russell Dalenberg.
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,
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
Why don't you publish the A-code source of Adv770?
Er... I have done! (Even though nobody seem to have spotted my second
joke as yet. :-))
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.
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, 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.
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.
Why just verb/noun commands? It's soooo primitive! Can't you write a
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.
- 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.
- 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:
You must supply a direct object.
? dig soil
You must supply an indirect object.
? dig soil with spade
You can't do that!
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
- 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 ("if it come"), which players keep enquiring about.
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.
Me? Well, what about me? My accent is unique, but I tend to English
How does Adv770 compare in size with other versions of Adventure?
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.
||Bytes of text
||Lines of A-code
Mind you, "lines of code" is rather deceptive. No, I don't
count comment lines! It's just that 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.
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
But OK, too many players have moaned, so I have relented. A bit, anyway.
From version 1.61 the problem of entering the game for the first time
is easier to solve.
I keep getting lost in the dark forest. Was it really necessary to
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.
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 – I am always happy to help by supplying obscure
What's the minimal number of moves in which the game could be
I've seen an anonymous player run through the game in 1184 moves.
Other than that I have to rely on player reports. After an extensive
analysis of the game, Brian Ball reports managing it in 1125 moves.
And I have a screenshot from Dave Haskell showing that he did it in 999
– a truly remarkable achievement! To tell the truth, I did not
think it possible.
Can one do better? Who knows! Over to you... :-)
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, 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! :-) )
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
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.
As it happens, the A-code-to-C translation approach turned out in
practice to have one massive advantage over a virtual machine one
(Dave Platt's implementation being an instance of the latter).
Subject to simple data (objects, places etc.) declaration rules, it
allowed upward compatibility of saved games even when the game code
was significantly restructured and/or augmented. As the result I could
treat the game after its public release as a gamma-test version and
effectively to continue its development on the basis of player
communications and the CGI-mode player logs, while recommending that
players upgrade to the latest version without the fear of
invalidating previously saved games.
But there was a deeper reason as well. As noted in (2) 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 wanted 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
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? :-)
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)
Using this instruction repeatedly, with no other intervening code,
- 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...
- 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.
- Third time:
You rub the spoon and nothing happens. I hope this doesn't come as
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
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
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, 3427 text definitions in Adv770 contain 1314
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? :-)
[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, but if you are interested,
http://mipmip.org/acode/acode-texts.html goes into the gory
detail of the very powerful text handling mechanisms of A-code.
So what are these text handling improvements in Adv770?
They are not specific to Adv770, but form a part of the
A-code engine (from version 11). Some will be apparent to players,
since they are to do with handling of player's input, which is also text:
- 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
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.
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.
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.
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.
Responding correctly to errors in "get/drop all"
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
- Non-specific "objects" all and
treasure can be used with the
get and drop verbs.
- The except syntax may be used with these
- Errors of three different types may occur within any command that
includes 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
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. For those few souls who might be
interested, there is a separate
document giving a detailed description of A-code text gandling
in all its glory.
Adv770 has been fun, but how about Adv880?
It would be a lot of work. And I'd want to
put a lot of development work into the A-code engine first. So I am not
saying no, but I am not saying yes either. Let's settle for a definite