My copy is at my parents’ house so I can't check the exact date now, but it's from the mid-to-late '80s and targets 8-bit home computer BASIC (e.g. Commodore 64) and IBM/Microsoft BASIC.
So I presume there were several revisions or additions.
There were several editions. My copy (sitting on my bookshelf as I speak) was the '73 edition (though I think a later printing), but they did revise it including releasing it for the then prevalent home microcomputers.
I first learned programming converting these things to run on my VIC-20 (and later C64). That earliest effort was prior to those later editions... and I'm kinda glad... I had to learn what different things actually meant and judge what was important and not.
Yes. As mentioned in https://github.com/maurymarkowitz/101-BASIC-Computer-Games the first, 1973 version targeting various minicomputer or large-system BASICs was entitled 101 BASIC Computer Games. The 1978 edition https://archive.org/details/basic-computer-games-microcomput... , claiming compatibility with "Microsoft BASIC Version 3.0 or higher" and having various other chainges, is named BASIC Computer Games Microcomputer Edition. (One difference is that the game names in the old 1973 version all obey the classic six-letters-at-most, all-caps filename convention familiar from (non-BASIC) titles like EMACS, SHRDLU, ADVENT, and SCHEME.)
The PDP-11 under RSTS/E gave users a 64kb address space for code and another for data. Systems like the TRS-80 and the Apple ][ gave a "learn to code" experience that was similar and certainly inspired by the minicomputer experience: you didn't get as much RAM and some of the fancy features but you could so some graphics even if you had to PEEK and POKE.
Very early microcomputer BASICs would fit in machines with 4k of RAM but as RAM became affordable almost all the machines evolved so you could fill out the whole address space. The IBM PC had a way user applications could address more than 64k that was half-baked because you were still stuck with 16 bit pointers, but practically I thought it was was really fun to write assembly programs that used the segments.
I was thinking the other day how DEC's VAX died because the addressing modes (especially indirection) couldn't be implemented in a modern high-performance CPU and how the 64-bit Alpha came too late to stop VAX customers from leaving but way too early to attract general interest because hardly anyone could afford to fill out a 32-bit address space. Like Windows 95, NT and Linux were competing in 1995 and 32MB of RAM seemed like a lot then, it wasn't until the early 2000's that you could really afford more than 4GB...
Got it, thanks. I believe that the version I have might be a later printing of the 1978 version, but actually the book I'm remembering most clearly was a later 1986 book by Ahl with a similar title of "Basic Computer Adventures" which has 10 longer adventure games… including an early version of Oregon trail.
I don't think I ever saw source code for Oregon Trail As for text adventures those require fairly exotic programming techniques to pull off. Infocom had the Z machine interpreter written in assembly for many machines but Scott Adams made an interpreter which could be implemented in either BASIC or assembly.
You can't write out a "script" for how the game works out the way most of those BASIC games are written. Rather that kind of game is table-driven and complicated by the fact that BASIC doesn't support structures so you can't write those tables in the "array-of-structures" system but rather have to write in the slightly awkward "structures-of-array". In a normal language you would have pointers, in BASIC everything has to be an index into an array.
A game like that is "object oriented" in the sense that there are rooms and items that share a lot of common attributes that could fit into an ontology. For the most part these things behave the same (pick something up and it goes into your inventory) with a few exceptions (you need to be holding the cage and not holding the rod to pick up the bird) A game like that can have a few if-then-else ladders in it there are keyed by magic numbers. It is maintenance hell (in a world without unit tests!) though you can take the cope that it is hard for somebody to look at the source code to cheat.
Scott Adams put the exceptions entirely into the tables with a very simple and specialized interpreter which was easy to implement in BASIC and also in assembly -- then he went on to make a huge number of games
where the interpreter is the same and the table is different. BTW, the "orginal adventure" was written in an old version of FORTRAN with awkward string handling and arrays but no pointers and uses similar techniques
So I presume there were several revisions or additions.