I want to share the graphical interactive fiction authoring tool “adventshark”, that I’ve been working on. It’s meant to be used with the various Scott Adams interpreters out there, like ScottFree (or PerlScott).

It can be downloaded from the homepage The homepage also contains some additional information about how to use the program.

Using adventshark demands a little bit of familiarity with the Scott Adams format, but there’s an example game on the home page and it’s also possible to convert existing games (including Scott Adams’ “Adventure Land” and TheRealEasterBunny’s “R”) to the editor file format, for figuring out how things work.

As a Linux user and a sometimes Windows user, it was important to me personally that the tool should be both open source and multi-platform. That’s why adventshark currently runs on Windows, Linux and MacOS.

Please note that (as in most software) there will be bugs and blemishes in this initial release of the program, many of which I don’t know about or remember. I’ll happily fix what I can. If you have any suggestions on how to improve things, I promise to listen attentively. If you want to fix things yourself, I also accept pull requests on GitHub :slight_smile:

A little bit of history: It all began when I made the PerlScott game interpreter. I got very familiar with the basic ideas of the game engine, but I needed some way of testing and debugging the interpreter. I tried using TheRealEasterBunny’s Visionary which I sadly couldn’t get to work in Linux. I also tried using Mike Taylor’s awesome ScottKit, but I wanted something graphical that better represented how I personally saw the game engine. In the end I made the mistake of saying to myself: “How hard can it be?” (As it often turns out, harder than you’d think.)

I hope that this can give someone as much pleasure and fun to use, as went into making it.


I like it!

Just had a go at editing adv5, added an object and an operation and it worked!

A few ideas;

  • When a new object is added and given a “noun”, it could automatically create that noun word.

  • Renumbering the objects (eg alphabetically) would be useful.

  • It’s useful to add as many “comments” as possible to find the appropriate Action, maybe have an option not to export these into the .dat to save space.

However, these are all fine points. Impressive work!

Thanks for using it!

While adventshark is fully usable, it still needs some improvements to be more fun and friendly to use. Every little bit of assistance in making it better helps. :slight_smile:

  • When a new object is added and given a “noun”, it could automatically create that noun word.

This is a good feature to have, but I don’t know how to implement it (yet). Perhaps by adding a “Create object noun in noun list” button somewhere. I’ll add it as a feature request on GitHub to keep track of it.

  • Renumbering the objects (eg alphabetically) would be useful.

Being able to sort items would be super useful for words and rooms too. I’ll add a feature request for that as well. Sorting actions is more complicated, but perhaps they can be re-ordered in a way that splits Auto actions and Verb-Noun actions into separate parts of the list at least.

  • It’s useful to add as many “comments” as possible to find the appropriate Action, maybe have an option not to export these into the .dat to save space.

That’s a great idea. I also find myself creating “dummy” subroutine actions, just for the sake of documentation, like ### OBJECT ACTIONS BELOW, which perhaps could optionally be weeded out automatically from the .dat files as well.

On Scott stuff;

I had been vaguely toying with the idea of another “pointless project” to run a Scott system on a real TRS-80.

The Scottfree interpreter has some TRS-80 bits in it, and this would be cool to have.

How it would work:

  1. Terp derived from Scottfree in “C” and compiled to z80.

  2. .dat files would be converted into initialised “C” structures by a utility and compiled into the binary. This would save a lot of “loader” code and be faster.

  3. OR, we could load .dat files, but this would make the cassette version not very nice.

Things we could do to as well;

  1. Upgrade the parser a bit.

  2. Compress strings (slightly) to allow bigger games.

  3. Add graphics!!

  4. Put newer Scott games on a real TRS-80 that never did!

And many other cool things that will make peoples’ brain hurt!

Is there any interest out there in this mad idea?

I’ve been thinking about this as well. That’s partly why I chose to use this particular JSON based intermediate file format for adventshark. I wanted to simplify the data structure to the point where it could be easily extended or translated into a smaller footprint binary format representation suitable for platforms such as an arduino or the original TRS-80.

My thoughts have run along these lines:

  1. Custom runtime code with a focus on speed and size.
  2. For string compression, I would be tempted to use a global word pool for everything from messages to descriptions (I think it was done this way for Planet of Death on ZX81 as well as The Hobbit).
  3. Support multi-word “verb phrases” and “noun phrases” for more complex “parser” behavior. (For example “slowly kill dragon with poison” would be split up into verb phrase slowly kill and noun phrase dragon with poison) This would be an easy workaround but it would also break compatibility with existing interpreters for the .dat format though, which needs consideration.

I’ll admit that doing graphics scares me. Especially in a multi-platform domain. I have no idea how to make that work in a satisfactory way.

I have a number of “pointless projects” on the go for the TRS-80, so i would just use my existing codebase and swap in the Scottfree guts.

These ideas are for the TRS-80, other platforms might be totally different.


I’ve been using sdcc, which I’ve found produces reasonably good z80 code. The trick is to make as many things unsigned char as possible such as loops and small counters.

For these old machines small = fast anyhow, so i always optimise for size as much as possible.


We have a few options with string compression;

  1. Really simple 7 bit packing.
  2. Fixed tree Huffman
  3. Some sort of word pool or substring factorisation.


For the parser, i was thinking;

  1. Allow multiple commands to be put together
    eg get key then drop key

  2. Allow pronouns
    eg get key then drop it
    (would work by substitution)

  3. Allow multiple nouns for some commands
    eg get lamp and key
    (would work by expanding into get lamp then get key)

  4. Allow articles; the, a,an`.

However, all these tricks would still essentially reduce to the VERB NOUN pattern underneath, so the system worked.


We would make use of the Scott “split screen” format, where below the line would be the transcript and above the line, where the room, objects and exits live, we’d add a small graphic area.

This area would have animated sprites.

My usual TRS-80 spites work by describing a sprite as a vertical list of horizontal graphic “on/off” bands. We only have one color!


We can have this too. I have working code that can play tunes!

Here’s a sprite test for one about half the screen size. The problem is drawing it fast enough to avoid “fishtailing”. Here I’m testing the clipping.

Pixel stuff!

1 Like

I’m very intrigued by this! My preferred way to play the Adventure International games is in a BBC Micro emulator, since I first experienced them on an Acorn machine. Scottfree is great, but I miss the little double-flicker you get as the screen updates - silly, really!

I played around with Adventshark a bit this evening, and managed to make a little game that ran on Scottfree, but it crashed when I tried to load the demonstration game on Windows 10. It crashed once whilst I was using it, too, but I can’t remember the circumstances. I’ll have another go at the weekend.


So i compiled up scottfree for the TRS-80. Here’s a screenshot of ADV5 (the count), running on a TRS-80 emulator.

Some of the text is a bit wrong, but it turned out the faults are in the adv05.dat file i got from scottkit. Not sure why this is.

1 Like

Thanks for using it. :slight_smile:
Crashes are good because they’re usually easy to fix. Please let me know how/where it crashed and I’ll try to fix it soon. Alternatively, you can log a bug report on GitHub:

I did not seriously expect that it was possible to get scottfree running on a TRS-80 Model 1. I guess it partly demonstrates the efficiency of the Adventure International engine. Good work. Very impressive! :open_mouth:

Which TRS-80 emulator are you using?

Glad you like it!

This shot was taken using SDLTRS, but the binary should work on any of the others including TRS32 as well as, of course, a real TRS-80!

The game works, although i haven’t played it through to check for bugs. Also scottfree needs a bit more of a tidy up. There’s a lot of inefficient code in there that makes no odds for modern PCs, but a few tweaks would help these old 8 bitters a lot.

There’s also some dead code to remove, since it’d like it to fit in a 16K machine.

I’ll get it tidied up and put the lot on github for anyone interested.

Putting it on github sounds like a great idea. Who knows; maybe it could be tweaked to run on other Z80 platforms such as Sinclair ZX Spectrum (or the 16k ABC-80 which never had Adventure International games running on it before).

Or the BBC Micro :stuck_out_tongue:

It would require a C compiler that makes 6502 code for the BBC Micro as a target without too much fuss. Not sure which one would do that best. I’d like to know this as well, since I have a BBC Master 512 in the attic gathering dust.

1 Like

Sorry for delay, i’ve been away.

Here’s the github repo.

There’s a prebuilt version of adv05.dsk and adv05.cas which can be run under an emulator.


There’s a project on GitHub called “sagarework” that aims to make Scott Adams game files runnable on a BBC Micro (or perhaps only on a BBC Master), but I’m not sure that the code’s in a finished or usable state currently:

The same developer has also posted a game for the BBC Master on the CASA forum:

Here’s the developer’s diary:

With regard to C compilers for the BBC Micro, there’s been some discussion on the Stardot forum about two apparently different ones, but I’m not sure how usable either one of them actually is:


1 Like

There were indeed two versions of the interpreter for the Beeb. The Mac Jukic version was bugged, and in adv05 (“The Count”) you couldn’t get back in through the window after climbing out meaning that the game was unwinnable. The Brian Howarth version was fine.

I wonder if it’s possible to isolate Howarth’s interpreter code and use that to run new games made using Adventshark?

Yes, I think that that’s essentially the aim of the GitHub project I linked to above. But the project seems to be incomplete. :slightly_frowning_face:

That’s my github account - the engine there is a total rewrite from the ground up that was designed to be as compact as possible so I could squeeze graphics onto a BBC Micro port. It is mostly finished and all the Brian Howarth games are playable with graphics. The basic Scott Adams games are playable without graphics (the graphics scheme on the Scott Adams games is quite disc space intensive - although I may be able to abuse the PC version of the graphics).

At the moment it will only work on a BBC Master - mainly because the BBC Master has a build in flood fill routine; although it should be possible to add a simple BBC Micro version.

I sort of shelved the project about eight years ago because i had other things to do.

It’s 3.5 KB of handcoded 6502 which is significantly smaller than either the Howard or Jukic engines. It may be possible to port to other 6502 machines (e.g. C64, Apple II); but it uses the BBC micro OS routines for text, so would need some conversion.

Anyway, I update my github to add a couple of pre-built disk images you can shift-break to load the game straight up.


Sample screen on BeebEm: