Compilation. One of the odd things about Avvy is that only the code was compiled, not the data. The data was a significant part of the whole, and these days I would have created it in some easy-to-edit format and compiled it. But in those days, with a few exceptions, I first designed the binary format in which it would ship, and then wrote an editor for it. So I think, in order to make it at all useful, one of the things I'm going to have to write is a decompiler for all the data formats, so you can read them as XML or something. How the images got included. This actually extended to having to write a general image editor "hiz" for Avaricius, because I didn't have any information on the save file format of any image editors I had access to. But for Avalot I wrote a screenshot program and my brother used Dr Genius to edit the images (he drew almost all the images in Avalot, which is good, because the images I drew in Avaricius rather sucked). Why EGA? The game required EGA (and used sixteen colours) because we didn't have VGA when coding started. By release time we had VGA, but the only concession to it was to use its ability to redefine colours to make change "bright magenta" to be more Caucasian-flesh-coloured. Codename. Avalot was codenamed "Project Minstrel" during development. Dogfood. One of the jokes that was so laboured that I never explained it: the minstrel who plays games against you was briefly called "Winalot", because almost all the characters' names ended in -alot; "Winalot" is a brand of dogfood, so he was soon renamed "Dogfood". Cameos. Dogfood, Spludwick, and Baron du Lustie were cameo appearances by the development team. Beta testing. We had different beta testers complain that both the Dogfood and Jacques puzzles were both incredibly difficult and ridiculously easy. Scroll drivers. You could embed ASCII control codes in what was effectively standard output (the "scroll drivers"), which would otherwise have gone into dialogue boxes on the screen, and affect lots of things about the game. Much of the moment-to-moment control of the game happened in this way. Wordwrap. The scroll drivers in Avaricius didn't do wordwrap, so I had to do all the wordwrap by hand. Big mistake, rectified in Avalot. Bootloaders. "avalot.exe" was merely a bootloader that allocated a few kilobytes of empty memory and ran "avalot9.exe", which was the real program. It pointed one of the user interrupts to the empty memory, and by manipulating this memory the child processes could instruct the bootloader either to load a given other child process after they quit, or to quit itself. This meant that a lot of the cut scenes could be implemented in separate executables. There was also space in the empty memory to store the current game state, so that you could seamlessly return to the game. One of the possible subprocesses was command.com, so that you could shell out to DOS and not have Avvy resident in memory, so there was actually space enough to do something. Edna. The save-game format ("edna") had generalised header information which meant that if you attempted to load a file from any other Avvy game, the correct game could be loaded to handle it. Chunk. Each room had a set of associated sub-pictures in a format called "chunk" which could be set to display at set intervals, meaning that animations could be put together without changing the code. Also. There was a resources format called "also" which allowed you to define things about each room such as where the doors connected to the next room and what direction you'd be walking in when you got there, and it had a set of opcodes which could be made to run a given cut scene, put up a given piece of boilerplate text, etc, when you walked into a given area or touched a line between two given points. Strangely, I never unified these opcodes with the scroll driver control characters. Skellern. There was the usual routine which hooked the clock interrupt to slow the game down. Around the time I was writing it I heard a song called Slow Down by Peter Skellern, and the whole subsystem is littered with references to that song. In particular, the slowdown routine couldn't be enabled during debugging, and therefore was disabled during development in general, so there was a standalone terminate-stay-resident utility called "skellern" which stood in for the real thing. The onion puzzle. This is the puzzle I'm most proud of. People were still asking how to solve it almost a decade later on Usenet. Avalanche. The whole magic opcodes system was going to be generalised in the third game "Avaroid" into an architecture for a virtual machine called "avalanche". I had no idea about virtual machines; I pretty much made up the idea. But the third game never shipped because I went to university. Z-machine. I've occasionally thought of doing a Z-machine port, as a plain-text adventure. I've never actually started it, though. I think it would be ineligible for the IFcomp.

My brother Andrew knows where the disks are and will find them when he comes home for Christmas vacation

My brother Mark is one of the copyright holders so we have to clear it with him as well, so there's no knowing what'll happen until he decides.

I am going to contact my parents tomorrow and ask for the source code of Avaricius and Avalot so that I can release them as free software. (It was written in Turbo Pascal.) This may mean finding a way to read 5½" floppies. I wonder if I can just buy a very cheap very old computer and hook it up with a serial cable.Some of the nifty things about Avaricius and Avalot, just from memory:I am wondering what else I'll discover when I finally find the source.I just phoned my parents:More news as we get it.