ADV770 FAQVersion 1.15, 05 Feb 2016 This Adv770 FAQ is based on queries and observations made by players of the game. Any comments or further questions are welcome! Questions:
Answers: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 ways in which it could be usefully extended. That 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. :-) So what's special about this version? Or is it just the 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 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. Why don't I get 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 came to Unix/Linux/MacOS since game version 1.89 and to Windows since version 2.05. Where do I find an Adv770 walkthrough? You don't. Not if I can help it. :-) It was hard enough to write, so try putting some thought and effort into playing it! In any case, there is something better than a walkthrough. 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. Why such a long delay in publishing the A-code source of Adv770? Mainly because I was curious whether anybody would spot my other joke without examining the A-code source. But it would seem that nobody did -- perhaps I'd hiden it too well. :-) Even now, as far as I am aware, only Brian Ball got there by studying the source files. How many treasures are there in Adv770? Let me answer this one very carefully: in order to score 770 points 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. Note, however, that I am not saying that there are 41 treasures in the game, because that's where things get complicated. After all that testing, are there any bugs left? And what should I do if I find some? I would be amazed if there were 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 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.
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 all those people are 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. :-) 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.
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 playing Adv770. 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. Why the game save/restore penalty? It is pointless and irritating! This penalty is easily avoided with a bit of patience. Just don't continue playing after saving a game and wait at least 10 minutes before restoring a saved game. As for a quick try of something potentially risky, use remember/recall commands, which carry a minimal penalty. Beyond that, I am tempted to say "because it is traditional", but there is in fact a better reason – you can treat accumulating penalties as a game problem to be solved. While this is not necessary for completing the game, an adventurous explorer can find a way of having all penalties retrospectively cancelled. How? Er... This is a FAQ, not a hint sheet! 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. 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 hints. 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. 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 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. 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 experimentation. And finally, call me a Luddite, but I really prefer the current version of A-code to other mainstream systems, largely for its unique text handling features. 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) like this: say spoon.still.tarnished Using this instruction repeatedly, with no other intervening code, results in:
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, 3430 text definitions in Adv770 contain 1329 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, 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. What are command 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:
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 handling 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 maybe. :-)
| ||||||||||||||||||||||||