I used to type in quite a few games from magazines back in the 80’s and it was equal parts amazing and frustrating. Amazing because you felt like an actual programmer by typing something in and have the thing run, and frustrating because, if you’re like me, you’d end up typing something wrong and the entire thing wouldn’t work and you’d then spend an age trying to find the thing you’d done wrong. I tended to be a very fast typist but not a very accurate one so pretty much everything I typed would have loads of errors. Sometimes I’d spend longer fixing all the errors than I did typing it all in the first place. And after all that effort, it seemed kind of anti-climactic finally getting to play the game and discovering it wasn’t much cop.
Always worth doing, though. Even if the finished project wasn’t worth playing, seeing how it all worked was always a bonus. I think it was this kind of thing that got me hooked on game writing in the first place.
The first time I do it, I couldn’t even save the program due to lack of tape drive. So, I’d type the program in, run it until the computer shut down due to overheat 2-3 hours later. Repeat the next day…
It helps me to be efficient with my code, making me to be a proficient code golfer.
I suspect us old coders have something to say for the next generation, but I won’t add to this unless somebody makes a separate thread of the subject.
Yep. This was the road that introduced me to programming too. In my case I had an Exidy Sorcerer with its own version of BASIC, so not only did I type them in but also translated/ported on the fly. I still have some of these type-ins which have been ported to various BASIC dialects as time went on and my computers evolved. I still have David Ahl’s 2 Computer Games books as well as The Captain 80 Book of BASIC Computer Games. The great thing about Ahl’s books is that there was a sample run shown as well so you knew if what you typed was right.
Magazine games were a different kettle of fish altogether. Not only did I have to translate from APPLE, PET, TRS80, etc but due to fonts, I had to double check all O & 0 and I, 1, l. A lot of fun, frustration and learning.
I still do this today but into Adrift, Inform 6 & 7 , Quest and Quest JS.
Many of these magazines offered typo-checking software for this reason. For example, Antic magazine had a program called TYPO (later, TYPO II) that hooked into the Atari BASIC interpreter to print a hexadecimal checksum next to each line in the listing. You compared that code with the one printed in the magazine.
I wrote on this topic on the Retrocomputing SE, where others discuss it too:
I usually went to the library and borrowed books with type in games but none of them were text adventures except for one book which I regard as the book that taught me most about programming together with the Commodore 64 user’s manual. It wasn’t just a collection of listings but explained how everything worked.
Most of the adventure games I typed in were from Electron User Magazine which I subscribed to throughout my teenage years. At least one of them used ROT13 or similar to disguise the in-game text while typing it in and translated it at run time. Of course this made typing it in correctly all the more painful and difficult!
The source code was never encoded, otherwise you wouldn’t be able to type it in, particularly in advanced BASICs like the Atari 8-bit that did automatic syntax checking when you pressed Return.
However, there was nothing to stop you encoding the strings. In the early days, all the strings were normal text, then some magazines (or authors) experimented with encoding the text, typically ROT1 or reverse the alphabet. The advantage of this was that you were less likely to see spoilers while you were typing it in. As @J_J_Guest said, the disadvantage was that it was harder to type in and it slowed the program down when decoding the string before printing it on the screen.
Some magazines used a machine language subroutine to speed up the decoding, but all these bells and whistles meant more to type in and it increased the program size in an already restricted environment.