I played around with the Adventurescape generator at school, but for reasons best known to itself I can't actually make it produce a working game at the end. No matter I wanted to play around with its guts anyway.

Its funny how the mind plays tricks on you, I forgot what a pain in the butt it is to make everything, and that annoying 4 letter verb limit. I do recall a wad of paper notes though, hand drawn map, etc. I do have a print out of what I made all those years ago, its not that good to be honest.

Plans for Adventurescape 3.0 (assuming I can use the name)
* No limits on word length for verbs and objects [sample code complete]
* Option for game images (static in graphic window)
* Upgrade the naming method and general editing on objects.
* Standardise datafile names, should be 4 letter game name and 3 letter type. eg: xxxxloc xxxxmes etc, and put each game file set in its own directory.
* Generally fix workflow in game editor, eg enter game name once instead of 4 or 5 file names over and over.
* Fix bugs which leaves files open when an error occurs (really annoying).
* auto menu for games, just copy the game's folder over and the main menu finds it.
* Some sort of text based automap, even if only for the editor.

Not sure if I'll have a way to import and upgrade adventures made with an earlier version, should be possible. Most people have CF cards and the like, so disk space is no longer such an issue.

Should be fun to use the generator once I get rid of all the enter filename, enter item short name, Y/N nonsense everywhere.

Real question is should I put any good code from the original in the new version, or just fix what is already there. Undecided at the moment so just making small programs to test various bits of code.

I'm of the opinion that it sometimes can be a lot more work and a bigger headache trying to persuade existing code to work in a way it was not originally designed to do rather than starting from scratch.

However, I've never looked at the code for Adventurescape so I don't know if this would be the case in this instance.

Kind regards,

Francis

Sounds like an interesting project, Paul.

I trust you've come across ascape at the IF archive, which might help you with writing a new interpreter?

Always good to see new adventure tools ... tho we really need some new games to actually go with them, too! It's on my lengthy TODO list to write something with the Inform / Z-Machine v1.1 (Infocom v3) Development Environment eventually.

Will definitely be good to see how you get on. Another place you might get support/beta-testers when you need it, is the forum over at The Classic Adventures Solution Archive (CASA). Great bunch of adventure fans over there, who know how to use a beeb emulator and have experience with Adventurescape games. Plus there's always the busier intfiction.org and the newsgroups rec.arts.int-fiction and rec.games.int-fiction.

When you reach the point where you have something to post, be it screenshots or demos etc., and if you'd like a hand starting a page on the Retro Software wiki and/or want a forum creating for it here, just give me a shout.

Sam.

I found Ascape while looking for instructions and other games. It does mention different versions 1.0, 1.1, 1.5, 2.0 of Adventurescape. I guess what I need is a way to tell what files are from what version, something to do later.

Not much work done on the code today, was fixing my rom cartridge. However I do have a function to convert strings to all caps. Going to use it to convert item names so a copy can be in uppercase in memory but not on the drive, needed for text input decoding.

I'm looking at the code used in xanadu which is v 1.1, will have to look at a v2 game as well and see how that works.

The code isn't too bad, uses procedures but the text input string processing code seems spread everywhere and could be a lot better. S$ is used for both input strings and strings printed on screen, which will need fixing.

I've added back in code from Xanandu (adventurescape 1.5) a bit at a time with some tweeks and var renaming. The renaming was needed as it was very hard to follow the code with var names like Cy% (object state).

Blocks reinstalled are:
a) get/drop object
b) examine object
c) look
d) inventory
e) the puzzle code, though not working yet some minor bugs to find.
f) move, I changed the byte ordering so its NESWUD instead of NEWSUD, so its like a compass.

The verb list also allows the disabling of inbuilt commands, 'wear' for examine, need to relocate the 'I don't know how to xxx' code as a result though. I added some extra code to allow worn items to be removed rather than just dropped.

Currently stuck on the Puzzles section of the code, some undocumented flags in there. The editor doesn't really describe what they do, and neither does the code.

Editor still doesn't create a working adventure, not entirely sure why. So going to try plugging values directly into the arrays in version 3.0 code I'm working on. Should have a working adventure soon then.

I'm the author of the ascape interpreter, which I sort of hacked together over about 3 or 4 nights.

The 1.0, 2.0 version number etc. was something I used internally to describe the different versions to myself to help me with the code, and probably not something that Mr Evans would agree with.

If you need me to help in anyway with some of the finer points, give me a shout!

Just another thought, Heyley Software used the adventurescape system and enhanced it for all their adventures and IIRC, they also released an updated version of it on the Amiga.

Howard Roberts has a page about it here. I haven't tried contacting him, but it may be useful.

Ok the Stranded! game for download on his site is an upgraded version of Adventurescape. What I like is they upgraded the things I was considering, but not anything I had already implemented. Only downside is the "load" function is disabled, but not problem to fix that.

I'll send you some questions I have soon.

Just a few thoughts about what sort of things would make the system contain more modern IF stuff (of course, if you implemented everything you'd run out of memory, so this is more a wishlist):

1. Compressed text (to minimise memory) Rob O'Leary did release a converter from Adventurescape messages to MIDGE (the Robico format) on one of the A&B Computing disks. I've reversed engineered several forms of MIDGE, so this would be quite easy to implement.
2. A better parser. Adventurescape just allows the conventional verb noun parser, but it would be nice to have (in order of preference):
   
   1. Adjectives: more information for describing nouns, for example we can have the SHINY SWORD and the RUSTY SWORD.
   2. Articles: allow semantic sugar, such as THE or A, e.g. KILL THE ORC
   3. Dative (2nd noun): Usually used with WITH, for example KILL ORC WITH RUSTY SWORD. There should also be a way of specifying the 2nd noun if not included, e.g.
      
      Code:
      Command? KILL ORC
      With what? THE RUSTY SWORD
      The Orc dies.
      
   4. Implied nouns: If something is done and uses a certain type of noun, then this can be implied by the game, e.g. KILL without a dative should guess that any carried weapons should be used, so something like:
      
      Code:
      Command? KILL ORC
      [with rusty sword]
      The Orc dies.
      
   5. Conjunctions between commands: Tying commands together through AND THEN , e.g. KILL ORC WITH RUSTY SWORD AND N
   6. Mass selection of objects: Allowing multiple objects to be selected in one command, e.g. GET ALL or GET ALL KEYS or GET RUSTY SWORD, BLUE KEY AND LAMP (where each expanded noun counts as one action).
   7. Exclusions: As a modifier to the above, allow the user to choose something not to be applied to, e.g. GET ALL BUT THE SHINY SWORD
   8. Adverbs: I've only seen these used rarely, this is a modifier to the verb, such as KILL THE ORC QUICKLY WITH THE RUSTY SWORD
3. Containers, essentially an object that can contain other objects with their own weight etc. limitations.
4. Actors, other "characters" that can move around, perform actions, interact with the PC, be controlled by the PCs etc., depending on a pre-determined path.

I can probably think of a load more!

With regards to the text parser you may want to have a look at the one I wrote (see viewtopic.php?f=29&t=98) which allows you to have something as complicated as "GO NORTH AND THEN GO WEST. PICK UP THE SWORD, GO NORTH AND THEN DROP THE TREASURE. USE THE KEY WITH THE DOOR."

My parser was functional although, if my memory serves, could do with a bit more refinement.

Kind regards,

Francis

I thought of another thing for the parser: prepositions, e.g. LOOK UNDER BED

My thoughts around an advanced parser is to do it in several stages:
1. A basic tokeniser that will take wordlists of each type and turn them into a basic bytecode
2. A basic bytecode interpreter that will form the verb and noun phrases of each statement in the input and conjunctons
3. These are then passed to the separate commands for them to handle.

A sort of example with the phrase GET THE SWORD, FISH AND RED KEY. THEN KILL THE ORC QUICKLY WITH THE SWORD.

Step 1, we tokenise into bytecode:

Leading to a byte code stream of:

Which is in sets of 2 bytes; the first being type, the second the specific example.

Then we can use some simple logic to work out the noun and verb phrases, so working through the stream we have:
verb, noun, conjunction, noun, conjunction, adjective, noun, conjunction, conjunction, verb, noun, adverb, dative, noun

We can apply the rules:

1. A conjunction followed by a conjunction is equal to one conjunction.
2. A conjunction surrounded by nouns groups nouns controlled by the same verb
3. A conjunction with a verb immediately before or after it is a new sentence

So we can reduce it to the following sentences:
verb, noun, noun, adjective, noun
verb, noun, adverb, dative, noun

The we can go through it again splitting verb and noun phrases, so we have:
1st sentence
VP = GET
NP = SWORD, FISH, RED KEY

2nd sentence
VP = KILL QUICKLY
NP = ORC
DP = SWORD

Which can be directly passed to the command interpreter.

I've been trying to hack up some proof of concept code to show this is a lot easier than it sounds, but it's been 20 years since I've coded in BBC BASIC and it's turning out to be harder than I thought (too many good habits)!

I like your ideas, even though they are going to be tricky to implement. My first challenge is to get the data out of an existing Adventurescape game so I can figure out how everything works, the Puzzles code is still somewhat of a problem.

But none of this is going to happen due to a couple of hardware faults, first with the BBC Master, and secondly with the PC I use as an emulator which also uses its TV tuner as a monitor for the BBC.

So no machine to program on for some time, in theory I can fix the BBC hardware and the old TV by next week. Its a bit iffy about fixing the TV so easily, and the micro relies on parts that are in the post still. The PC can be fixed too if its just a simple buffer chip, like I suspect.

I'll be honest, when I wrote ascape, I just translated from BBC BASIC to C for the actions and parser as it seemed to be the safest way. In ascape, the functions loadv1database and loadv2database actually read all the files into memory at once

In general format earlier AS games just use openout/in format for storing integers and strings. Only the puzzles are stored as 10 bytes for condition, 10 bytes for action.

For puzzles, checkcondition and performaction do all the work, but it may be easier to understand it from the database dumper bit a bit further up. It's basically if the byte <> 0, then it contains the object/room that the action/condition needs.

I got a physical copy of the Graphics Adventure Creator, so I could study how it works as well. The never opened before manual is very helpful, as I know Adventurescape needs a book.

Taken me a good few days to figure out a way past the copy protection or whatever that cripples the main menu and makes it impossible use. Its written in basic at least so a spot of hex editing the ssd and pasting it into a new file fixed most of the problems.

Going to try it and some other things out on the real hardware now, the emulators are never 100% compatable, and it can be annoying.

I also wrote an interpreter for GAC games called grackle (it only works for on Spectrum and Amstrad CPC, which is ironic as I did all my reverse engineering on the BBC version). I'm current reverse engineering the BBC Quill data format, which is different from the other Spectrum/CPC Quill format.

But GAC maybe a false lead as the actions are done in a totally different way:

Adventurescape uses two sets of 10 bytes (for condition and action) with byte number being the directive and the value being the parameter, for example if we have the byte stream:

This is interpreted as:

Whereas GAC uses a proper stack based byte code to represent a programmed action (and actions can be of 3 different types, depending on whether they happen before the input, after the input or are room specific), for example, the following bytes:

Which disassembles to:

Which then decompiles to:


The Quill is somewhere in the middle: it has a byte code of conditions and actions, but doesn't go for the full stack implementation.

Finally found the information I needed on the file format etc, in the 'generator' folder is a pair of subfolders called 'X' ie generator.X.X

In there is the documentation and some other nodes for the program itself and some games. Odd thing is its got some sort of markup codes in it, and neither view or anything else I have uses all of them.

How strange, maybe they are printer codes for bold, italics etc.

Looks like another project will be to make these into more usable documents, that is something loadable from the menu that can be scrolled around in.

Have you tried reading them in Wordwise Plus, Mini Office II and maybe Interword?

Those would be the other beeb word processing programs I would try, thinking off the top of my head.

Sam.

If it's none of those, you could try ProWord by T Hall - he's the bloke who wrote Twin Kingdom Valley.

It's what I used to for word processing on my Beeb.