One of the landmarks in computer science history is the invention of the binary tree, circa 1960, by
P.F. Windley, A.D. Booth, A.J.T. Colin, and T.N. Hibbard
with Booth and Colin’s contribution showing up in On the Efficiency of a New Method of Dictionary Construction. An illustration from the paper is below.
Our tale today is focused on A.J.T Colin, aka Professor Andrew Colin, who started with an engineering degree from the University of Oxford (“The lectures were dull and required lots of note-taking, and I dropped them altogether after three weeks”), went to an assistant lectureship at Birkbeck College, and eventually became the first professor of Computer Science at Strathclyde in Glasgow.
He taught programming using an ICL 1904A mainframe with punchcards, which had to go through the standard batch processing: students submitted their cards (or cribbed off someone else’s) to be run with a large stack and hoped they didn’t make a mistake.

From vintage-icl-computers.
When personal computers first starting coming on the scene, they were not necessarily well-regarded by academics with access to large mainframes, but Andrew Colin realized that they would allow for much better learning experience. According to Andrew Colin himself:
Although most of my colleagues regarded personal computers as children’s toys, I still managed to get the University to buy and install 105 Commodore PETs.
He wrote a tutorial text — pushing away from his past experience with painful lectures — which allowed “students to learn at their own rate, without frustrating waits to get their results back”. His text for student learning eventually got converted into An Introduction to BASIC by Commodore.
Commodore got hold of my text, and decided that something similar would be useful for their VIC 20 and C64 computers. Always happy to write, I tried to negotiate a fixed price, but they insisted on paying me by the number of copies sold.
In the event the books did extremely well. They were translated into many languages, and I was paid much more than I expected. I should say that Commodore was always a good firm to deal with, and the machine (for its time) an exceptionally good design.
The book/tape package sold in Part 1 and Part 2 for both machines.

From Collections WA.
The VIC-20 aspect is important; if you recall from my prior writings, it was not by any means a powerful computer, and the focus of our interest — Dungeon, a simple text adventure from part 2 — did have a version in the VIC-20 book, with the base machine augmented 8K of memory to a mere 11,775 bytes available (typical TRS-80 games or anything by Scott Adams use 16K). For the purposes of the Project I was unable to locate the C64 version so played on VIC-20 instead.
With “learning games” the whole point is not necessarily to make a “fun game” but to demonstrate a program with easy lessons to extract and the ability to mod it further. “Success” of one of these game/article hybrids might be considered simply how many games clearly were derived from it; for example, the Ken Reed article from August 1980 ended up having a significant lineage after, even though the demo game wasn’t even complete!

Before Dungeon comes a multiple choice game, Graff. I was not able to get the game working but it just is a choice game with the entire structure shown here.
Having said all that, the Introduction to BASIC game Dungeon is kind of dodgy even for a test game.
It doesn’t have a parser. All you can do is choose to pick an item up when you see one (see above) or pick a direction. If you exceed 3 items in inventory you drop your longest-held item.
Quite randomly — they don’t move around the map or stay in consistent positions or anything — various monsters appear. There is a random chance, first of all, that you may be able to run away. This drops you into a random spot on the map (from places 1-11). After running away, there may be another encounter, so I’ve had it happen where I get multiple “teleports” across the map from running away from things.
If you aren’t able to run, you have to fight. If you don’t have the right item in your inventory to engage with the particular enemy, you die.
If you do have the right weapon, you have defeated the monster and it can no longer randomly appear. (I should emphasize that running takes priority, even when you have the right weapon, which can be quite frustrating since running might land you with a monster that you don’t have the right weapon for.) The spider is killed with a stave, the dragon is killed with a sword (which you start the game with), the enchantress is defeated via magic potion, wasps are defeated via flyspray, the slimy belly-fish needs a flamegun.
In addition to the monsters appearing at random, the weapons are distributed at random.
The way to win is to get up to room 13, so the princess will start following you, then walk all the way back to the start (room 1) and go south. This is very hard to do.
There is no control over monster appearances, and whatever weapon being held is also generally random. You do get a modicum of choice if you have three weapons and you want to drop the one you’ve held onto the longest, but the only reason to do that is if you’ve already used that weapon, and in practice that is rare. Since all monsters appear with the same frequency there is thus no real reason to prefer one weapon or another, and no real choices.
Because of the randomness, the best bet is to simply hang around as little as possible — don’t explore the side rooms — and make a beeline for the princess and the exit, hoping you get lucky. I finally managed after about 50 tries.
I discussed, with Conquest of Memory Alpha, an adventure game being like Solitaire where there is only a random chance of winning, and skillful play can tweak your odds but not make a win 100% possible. Here, there aren’t really any ways of tweaking the odds at all. Playing this game is a slot machine. I do see how it illustrates various coding structures, so I’m not going to rake it over any coals, but I sincerely doubt this game was copied in the same manner as Conquest of Memory Alpha.
Professor Andrew Colin, sadly, died recently. And I feel odd focusing on just a handful of pages when the books as a whole are clear and well done. So I want to end on a positive note: the sound tutorial portions are excellent, with an interesting library of sound effects and music that plays to the strengths of the Commodore sound chip. The video below is a rendition of The Entrance of the Queen of Sheba from the C64 version of the book.
The C64 programming manuals where were I first learned both BASIC and assembler programming. Fond memories.
I think learning books like this haven’t had enough attention by historians, they clearly left their mark on people. (For me it was an IBM PC Jr programming book, which I still have, although the cover is torn off now.)
This is one of the best articles that I have read in quite some time. It is a pleasant trip into the past in which I have fond memories.
Thank you!
You are welcome! Thanks for reading!
I’ve really enjoyed this narration. It is really amazing that this professor were able to see the potential of home computers, even using Basic to program them.
I expected him to write a compiler of Fortran for those PETs, but then it is clear these machines (nor the VIC20s), had the power to support something like that.
The VIC-20 aspect is important; if you recall from my prior writings, it was not by any means a powerful computer, and the focus of our interest — Dungeon, a simple text adventure from part 2 — did have a version in the VIC-20 book, stuffed into a mere 8K of memory (that is half of our typical TRS-80 games, or anything by Scott Adams).
It was actually worse than that — quite a lot worse. The VIC-20 came five 5 Kb of memory, ot eight. But half a Kb was used for the memory-mapped screen, another half Kb for the colours of that screen, and third for miscellaneous purposes such as zero-page. As a result, you had only 3.5 Kb to hold your program and its runtime data.
That’s why so many commercial VIC-20 games required the 8 Kb expansion — including my own Magic Mirror, which I hope you get to soon! http://www.miketaylor.org.uk/tech/advent/mm
(Published in 1983, but written in 1982.)
I suppose I should have phrased more clearly — this game requires the 8K expansion.
I guess if I’m doing it as a sum, 11.5K?
If I understand the game correctly, there is a reason to swap weapons even if you haven’t used the one you’ve held the longest. As long as the new weapon hasn’t been used, and one of your existing weapons has, it would be better to swap so as to move the used weapon closer to the “held the longest” status. Since you are just as likely to encounter the monster killed by your new weapon as you are the one killed by the one held the longest, it doesn’t cost you anything to make the swap, and it moves you closer to being able to swap out the now useless weapon for one that is still useful.
The other very tiny probability tweak I can think of that normally, you shouldn’t bother with side passages, but maybe if you’ve killed X monsters you’re better off checking for a weapon.
Pretty much 49/50 of the games have un-preventable death anyway. I think the variables could be tweaked to make it a _little_ more fun but without the random death it is too easy to coast to the princess and back, so I’m not sure exactly the fix.
Giving you the option to fight before running would open up a little more strategic choice. I can kill this monster for sure and not have to worry where fleeing might land me, but then I have a reduced chance against the next monster I encounter (because one of the ones I could kill won’t come up any more). Depends in part on how the monster generation code is written – if a killed monster type comes up, does it just not do that encounter, or is the encounter already determined and it just picks a different type.