We can’t have stuff at the root – sorry! It needs to stay in the subfolders.
This is great. I remember when these books were new and I didn’t yet have a computer so I bought books and learned BASIC before I could afford a computer. I actually have a copy of the More book that is in excellent condition. Not sure if I have the first book or not. These books really were exciting at the time.
I’ve been thinking about doing something similar for the 1980s Usborne computer books, especially the longer programs like Write Your Own Fantasy Games’ “Dungeon of Doom” roguelike and the text adventures in Write Your Own Adventure Programs, The Mystery of Silver Mountain and Island of Secrets. The Usborne programs are less constrained, sometimes taking advantage of '80s-micro sound and graphics where the original Ahl collection seems to be limited to tty interface, and sometimes using more memory or even cassette-tape multiloads. (Which obviously brings both advantages and disadvantages.) The visual presentation and storytelling in the original Usborne books is very engaging.
It should be added, though, that the book and the programs weren’t originally for microcomputers. (Which is why there was a later Microcomputer Edition, after all.) The programs were written for, and on, timesharing systems with teletype UIs like the original Dartmouth BASIC machine and the many other microcomputers which ended up running a BASIC port. In fact my hunch is that it was this already-existing library of fun, understandable and reasonably short programs which made BASIC support a must for the Altair 8800 and its early imitators.
So the plan is to create at least 8x96 implementations of the original games, written by possibly as many people in as many styles? And one of the goals is to stay as true as possible to the original input, output and gameplay?
I’d say that this calls for an official test harness. Given that these are terminal games it should be possible to hook stdin and stdout up to a game runner. The verification could be generated by actually playing the original game.
Just an idea.
That’s right, and it is covered in the wikipedia entry for the book!
The timeline was truly a pivotal moment in computing history:
- 1971 – Ahl ports the programs from FOCAL to BASIC
- 1973 – 101 BASIC Computer Games is first published by DEC
- 1974 – Ahl founds Creative Computing magazine and acquires the rights to the book from DEC
- 1977 – the “trinity” of Apple II , PET , and TRS-80 microcomputers are released to the public, all with BASIC built in, at prices regular people could mostly afford
- 1978 – second edition of BASIC Computer Games is released, this time published by Ahl himself.
As you can see, there’s no way average people in 1973-1976 were doing a whole lot with BASIC programs, as they had no microcomputers capable of running BASIC to buy!
I thought about that but whoo boy that’s a big chunk of effort. I think we have to figure this out as we go, and refactor along the way.
Example: the JavaScript ports need a standardized way to provide console output per the GitHub issue.
(I’m also pretty sure there are bugs in these programs, so that’s another question, do we fix the bugs or preserve them?)
Hi, I’m Al Sweigart, the author of Automate the Boring Stuff. My next book is The Big Book of Small Python Projects from No Starch Press, and it covers exactly this concept: small, text-based games that offer examples of complete programs (not code snippets) for beginner programmers. I have a collection of over 100 games/animations/science demos in this repo: GitHub - asweigart/gamesbyexample: A collection of text-based games in Python and other languages.
You can play them by running pip install gamesbyexample
and python -m gamesbyexample
to run the launcher program.
I started on this three years ago, and the style of the programs are 1) short (under 256 lines, as an arbitrary limit) s2) text only (so that readers can link cause-effect between the print() calls and the text that appears on the screen 3) requires no additional libraries outside the standard library 4) fits in one source code file for easy copy-pasting, along with some other guidelines.
My main fear is that I’m just old, and I’m mistaking the nostalgia of how I learned to program for good pedagogy in modern times (this is a mistake the One Laptop Per Child project made). But I figure this might be a good start for beginners who want to see what programs “look like”. I already have JavaScript, Java, C#, Kotlin, and Go versions also planned. The books, like all of mine, will be released under Creative Commons licenses. The first book should be out in a few months.
Also, the book Tiny Python Projects also follows the same pattern as Basic Computer Games and is out right now.
Valid points!
Regarding “should we fix the bugs from the original?”. It would be preferable not to fix them in 8 different ways for each game.
Either the original BASIC (or whatever version is runnable today) is the reference, or this project creates one reference implementation (with bug fixes) that sets the rules for how the other ports should work.
I’ve noticed at least two errors in the .BAS files’ strings - probably things that crept up in the scanning process that didn’t interfere with running the programs. I’ve taken the liberty of correcting the text in both the .BAS file as well as my Python file, but I haven’t followed up by checking to see if any other languages require the change.
For A-mazing, I just committed a single *.cs
file, but I noticed that others committed .sln
& .csproj
files too. What is preferred?
I think it’s fine to commit the solution file… we want to avoid too much cruft, but a little bit of helper stuff to make editing / running the code easier is probably OK.
We can’t have stuff at the root – sorry! It needs to stay in the subfolders.
The problem is that is doesn’t belong to any one of the individual games. (I was planning on adding a Common assembly to be used by multiple games).
So, could we have a top-level “Misc” (or “Common” or “etc” or “attic” or whatever) folder where things like this can be stashed?
I dunno, aesthetically that feels quite wrong to me. Each program should be its own standalone thing, in its own folder.
I have now had a look at some of the .bas
files. Oh such happy memories this brings back. I was never old enough to actually be part of this when the books came out. But I have tried more than once to make something modern out of “Stuga”, a Swedish text adventure game of much fame. The first version was written in DEC Basic in 1978. That game is written by three 10, 12 and 14 year old boys and it is 2763 lines of pure spaghetti goodness. BUT there is now an annotated version of the source that explains (some of) the strange GOTOs and variables. More information is available in Swedish if anyone is interested. There’s actually someone working on a BASIC interpreter in JavaScript, with the sole purpose of being able to run the original game code (!).
Could we consider an analysis of the sources of these games and adding comments? This could be in a separate file if we want to keep the original .bas
untouched. This would be both to help the porting effort and for historical documentation of why certain things were done the way they were in BASIC at the time these gems were created. I assume there was some form of description in the actual book, but having line by line comments of at least the more interesting parts of the spaghetti would be nice.
Should we file issues for errors in game logic? As in where a port differs in output or behaviour from the original.
A funny fact that will make you an ACE in aceyducey.bas
:
negative bets are allowed and will increase your stash with the absolute value of the bet in case of a LOSS
Sure, if the program is sufficiently complex and you feel it warrants another markdown document in the folder for that program, go for it.
I’d like to contribute C# implementations for some games. I’ll start with ‘Name’ as it’s really simple. It’s been best part of thirty years since I wrote any BASIC, and then I was a child using a Spectrum 128K copying code from Your Sinclair magazine.
I’m thinking we should add a Known Bugs section to the readme.md for each program in the root. I’ll try to get that done, because it will affect each implementation.
We might also need a Conversion Tips section for some of the programs that are extra clever in the way they use BASIC, per the above.
I created a Java impl. of PIZZA.BAS
but someone already beat me to it, should I announce this before trying? (It’s ok, the existing IMPL looks cleaner than mine)
I’m not sure… someone did this weird “send a draft pull request” thing you can see on GitHub:
Perhaps you could try that?