Going Back To BASIC(s) Part 2: Adventure Games Made BASIC.

So, here we are again, and we're back to the Usborne BASIC books. But instead of a mish-mash of genres, we're looking at three books from a single genre: Text Adventure Games, aka Interactive Fiction. There were a lot of IF games back in the day, and authors like Steve Meretzky and Scott Adams made... Well, a lot of IF games. The earliest was made around 1976, Colossal Cave Adventure (ADVENTURE for short), and, for a long while, they bloomed. Even now, there are folks who write Interactive Fiction, some of it extremely witty or thought provoking!

The Hitchhiker's Guide to the Galaxy: Still played today, still people complaining (Rightfully) about that fucking dog.

But we're in the wayback machine right now, and the three books in question are "Write Your Own Adventure Programs For Your Microcomputer", "Island of Secrets", and "The Mystery of Silver Mountain"

This, ladies and gents, is where we get into "More planning" territory. And the authors of each book know this damn well. They even, in some circumstances, tell you how much memory you're going to need if you expand the game. Because hey, RAM was a limited resource back in the day, and tricking the system into doing things cheaper was the way to go. But we'll deal with that soon enough, let's move onto the books.

Requires... 16K? But... Isn't That Tiny?

The latter part is still true, especially now, when descriptions are pretty much expected.

Adventure Programs (to shorten a somewhat unwieldy title), as with the other two books in this post, has a listing for only one game. Like the other two books, it's a book of two halves: The first half deals with what goes into the game, how it's pre-planned (And how you should too), and the second is the listing, with modifications for relevant systems as needed. The program is no slouch-fest to type out, at 214-280 lines (Depending on which 8-bit computer you were wearing out the keyboard on), and needs, at minimum, 16K to run (Your average BBC Micro B had 32K, but later models near the end of the BBC's lifespan had as much as 512K... Less common as they were...)

280 lines of code doesn't sound like much, until you realise that's 64 rooms, with 25 verbs (Actions) you can perform, and 30 items. Another 17 lines adds four (Admittedly awful) sounds to the game, and all of this is done, with deaths and an ending... In a tiny amount of space, for a tiny amount of RAM.

And if you hadn't read the first half of the book, you're not going to understand most of what it's actually doing. It gives you a hint on Page 7, but it takes the rest of the first half to hammer home how very true the first statement on that page is: "An adventure program is really a kind of database." The room names are data. What is in those rooms is data. The Verbs are data which have special cases attached to them, and all the game is doing is checking that if VERB+ITEM is used in ROOM, then a thing happens. Or doesn't happen. Or displays a different, and quite tragic result (Yes, it's an oldschool adventure game, so things can kill you.)

It sounds so simple. But at least three of those 280 lines of code are big, honkin', itemised lists.

Oldschool Values

Baticide: Noted as AEROSOL in the item database. No descriptions for items.

Thing is, this is also a relic of its time, and it shows. All of them do. All three books have treasure to collect. Adventure Programs even states how you can change the concept of treasure to Clues or Spaceship Parts, or whatever the hell... But it will still think of it as treasure throughout the book. Score is another thing. Nowadays, a lot of IF games only use "score" in the abstract, although we've rarely moved completely away from "score", or, more accurately "High(er) Score"... But since this is an 80s adventure game, the Skinner Box is in full effect, and every action towards completing the game rewards you with points. Which you can compare to the total. And bilk yourself out of.

In a reference to Colossal Cave, Light is important. And is in limited supply. There are no death states in the game that I can spot, but it would be pretty easy to put them in. And since there are no descriptions loaded, beyond simple names, you have no actual way of knowing (Except, of course, by being the poor schmuck who typed all this in) that the Aerosol is actually Baticide (Yes, it's Bat-Shark-Repellent.) So it's got its fair share of dick moves, too. How very 80s game design. Also, all three books share the VERB+THING parser that was to be common in IF for... Not a whole lot of years after this book, actually. Oh, did I mention it was called Haunted House? Maybe I should have.

The other two books, in fact, aren't as nice to you, albeit in different ways. The settings differ too: Silver Mountain has a treasure hunt, several uncooperative NPCs, and death states (including at least one Dead Man Walking if you miss an item you won't be able to get back to), all set in a fantasy world with an evil wizard, tyrannical mongol warriors, and, of course, trolls, goblins, and elves. Island of Secrets is somewhat similar, being Science-Fantasy, but has a time limit, strength and "wisdom" (mental strength) counted and changed, and some truly mindbreaking puns (The hero is Alphan, the villain is Omegan. AUUUUUGH!)...

A typical Dead Man Walking scenario. At least the book tells you it will be!

...Look, let's just say the writing of the games themselves is definitely not its strong point. The artwork, on the other hand...

That's one of the character spreads, from Island of Secrets (EDIT: Er... Later in the page). The location spreads are good enough that someone could probably use them as concept art for locations in their own game (So long as they don't mind some places being generic, but looking nice), and, just like every other book in the Usborne BASIC series, the explanations are also riddled with little illustrations showing you analogies for how various programming or gaming terms "work". While Haunted House was 280 lines, Silver Mountain and Island of Secrets both hit at least the 400s, up to 500 lines of code on some systems...

So, What Are We Learning, Here?

For all the flaws inherent in the programmed games, as modern game design would see them, these do adequately teach the more mind numbing side of things. A platformer, even today, is not as difficult as a graphical adventure game. Which isn't as complex as a good Realtime Strategy. Which, in turn, isn't as complex as a good Turn Based Strategy. And the more complicated you get, the more book-keeping you have to do, and the more planning you have to do. In this respect, only Adventure Games gets a free pass, because it tells you the kind of planning you're going to need for a good 10-20 pages. The other two, by contrast, spend most of the time making the locations and characters a hell of a lot more interesting than they mostly end up.

From top to bottom: Swampman (1 interaction), Omegon (3 interactions), Boatman (1 interaction). I do like the art style though!

I like to think of Adventure Games as the low-intermediate end of this set of books, showing you what needs to be done, while the other two show what can be done (Without, necessarily, doing it all).

Next time, we'll be dealing with just one book, that I consider the high end of things... Before we finish up with more of the beginner level stuff, which is, to my mind, the weakest.

...But still important,

Going Back To BASIC(s): Some Early Game Design Books, and Why They Rock/Suck.(Part 1)

So, thanks to a game developer friend, or rather, her retweet of a question about gaming and game-dev books, I dug up a series of old books I remember from my childhood... Well, I only remember some of them, as, naturally, libraries don't always have a complete series in stock. But either way, we're gonna be mentioning most of them... And here they are. You can find them yourself at http://mocagh.org/loadpage.php?getcompany=usborne-hayes , and I recommend you do so if you were ever a BASIC fan, or just want to understand how (ho ho) basic programming could be sometimes, back in the day.

That... Is a fair few books. But, as we'll see, they have a fairly common pattern.

Now, one thing to remember about these books is... They're quite obviously designed for kids, or adults who like kids' educational books. And that's actually a little telling about coding books for this day and age (The series was published between 1983 and 1986, as far as I am aware.)

Why? Because on the one hand, they're more accessible than the programmer's guides for many 8-bit systems of the time, and, for the other, none of these books assume you're an idiot, explaining things without getting patronising, and even offering possible experiments for yourself you could look into.

An Example of not assuming you're an idiot: Telling you that it's easy to make mistakes in coding.

...It really is.

So let's start with the three "lots of small games" books: Computer Space Games, Computer Battle Games, and Weird Computer Games (There was also a fourth, Creepy Computer Games, but it's a bit harder to find.) In a lot of them, we're going to see the name of Usborne Publishing's Editorial Director, Jenny Tyler (Who also wrote a series of puzzle adventures for 8-13 year olds that I sometimes still look at when the mood takes me. :D )

The one thing in common with the games in these books is that they're small, manageable projects. The most complicated programs run in at something like 200 lines of BASIC, and it's not always guaranteed that the largest, most complicated program involves graphics (In fact, in each of these compilation books, the graphical games are between 50 and 70 lines.) However, not all of them are programmed the same way, and not all the books in the series deal with all systems (More on that in later parts.) Also, the games vary widely in "Fun Factor": Playing Hot or Cold with the computer via text was... Pretty disappointing, even in the days where a Scott Adams text adventure was Manna from Heaven. But still, they taught programming, and usually in a fairly logical way. Let's look at a few, shall we?

The Absolute Basics: The Aforementioned Guessing Games

Huh... So... Robots complicated enough to wage war are using single letter defusing codes?

I can feel 5-Year Old Me's skepticism through the mists of time, for some reason...

Two of the books (Battle Games and Space Games) begin with what is essentially "Hot or Cold", albeit with a wide difference in difficulty between the two. They both have simple mini-stories meant to fire the imagination: In Battle Games, it's a battle against the Robots, where you have a limited amount of time to defuse a missile before it goes off in Earth HQ (By guessing which letter of the human alphabet defuses it... Go figure), and in Space Games, you're trying to guess what force you'd need to escape an alien world in a stolen spaceship before the locals capture you.

In a way, these are the best starters, because they only involve simple things: PRINT (text), variables (Storing single bits of data that can be changed or referred to), GOTO (A feature in linear languages where you jumped around to a certain point of the program), IF...THEN statements (Explains itself), random numbers, and FOR loops (Do this thing X times)... Simple stuff. 

In another... God, even to 5 year old me, they were dull and tedious. Here's how playing Starship Takeoff (the Space Games one) usually went for me.

GRAVITY: 10

TYPE IN FORCE

> 100

TOO LOW

TYPE IN FORCE

> 200

TOO LOW

TYPE IN FORCE

[eight attempts later]

YOU FAILED -

THE ALIENS GOT YOU

Wonderful stuff. Properly looking at the code, I could have done better, but this was one of the games that never incentivised me to try. Shame I didn't, because otherwise, I would have realised (as I do now), that there are always only 40 possible answers (The gravity * a number between 1 and 40), and I have 10 attempts. Robot Missile, by comparison, had 26 possibilities (A-Z), and only 4 attempts. Both were frustrating as hell, so I never did.

Of course, there are always variations of this, so there's also multiple variable Hot/Cold (Intergalactic Race... Which was about picking angles and velocities of satellite launch to get it into the right orbit height), Which Monster is Weak to Which Weapon? (Monsters of Galacticon, where the "guesses" were your fellow redshirts), and other types as well. Eventually, these games move into teaching you about arrays, but the guessing games weren't very entertaining, although they were instructive in absolute basics.

Shooting Galleries and Simon Games

Okay, so this isn't code to a shooting gallery game... I just wanted to set something up for later in the post. And the shooting gallery games look boring, anyhow.

Another simple, easy to program category, these generally used the number keys, although it was pretty easy to change them to use arrow keys. But here, another concept gets introduced: Timers. All the timers were loop timers, which sounds a bit kludgy, but hell, it gave pretty consistent times. In any case, the most basic versions went along the lines of "There is an enemy who can pop up in one of X positions. Hit the right key for where they are (Between 1 and X) to shoot them when they appear."

Game wise, despite the ASCII graphics ( "0" for a soldier poking his head up from some battlements, "OO" for the Bug Eyed Monsters of the space version), they were simple, they were fun, and there was no gruesome "OH NOES, THE [THINGUMAJIG] ATE ONE OF YOUR CREW!" messages... More's the pity to the older, bloodthirstier me...

...Actually, come to think of it, I knew how programs worked by this point in both books, and added some in with an IF [score]<5 GOTO [line which then printed out that I'd been nommed on by Bug Eyes, and ended the program]. So young me was a bloodthirsty sort as well.

Of course, some of the games weren't shooting galleries, they were "Quickly work out/memorise this thing, then type an appropriate response." Alien Snipers had you quickly typing a letter that was X letters after the printed letter. Asteroid Belt had you typing a number proportional to the size of the Asteroid (represented by the number of stars it was made of.) Shootout was a straight reflexes game, where it didn't matter what key you pressed, so long as it wasn't BREAK (Which would quit the program on any 8-bit system that had the key), and so long as you did it very quickly after it actually told you to (The other shootist must have been walking backwards, because shooting early would mean you got the "He shot you!" message. :P )

They were definitely among the fun ones. But the main thing they taught was how to kludge the shit out of timers with FOR loops, something that is now... Well, we have dedicated subroutines in most languages now for doing that, so we don't need to be so clumsy ourselves...

A Sidenote: It's Amazing How Many Of These Involve Blind Chance

Even Repton was pissed off at this development!

Of the games in Space Games, Battle Games, and Weird Games, there are three main forces to contend with in pretty much all the games to some degree or another: Reflexes, Blind Luck, and Logic. And that's actually kind of telling. Not because these are basics of videogames (Although the second is only really glorified in the bloody handed Roguelike), but because, in nearly all of these games, they're pretty much all it is. There is no talking to people, no degrees of victory... It's all black and white, do or die: Shoot the Cowboy. Find The Resonant Frequency Of These Robot Guards to Kill Them Before Your Execution. Shoot Robot HQ By Guessing Where It Is In This General Area To Win War.

Multiple types of endings beyond "Win/Lose" weren't actually going to be a thing in games until after these books had seen the light of day. Talking to people would happen, but only in Interactive Fiction, and only in a limited sense (Hell, today is still a limited sense... But a less limited sense). And RNJesus puzzles (Where the answer is to pray to holy hell that the Random Number Generator doesn't hate you this time), are still in some videogames today, mostly received with horror (Repton 2, released a year after Space Games, would be lambasted for an area which had randomly falling asteroids that would kill you on impact, forcing you to restart the whole sodding game.)

So things have changed, and these books seem quite primitive in terms of game design... But not by as much as we'd like to think. More on that later, methinks... For now, back to -

The Outliers

Wait, I... Get to move and shoot?!? (Sort of... Sort of...)

Each book has its own little games that are neither about guesstimates, Hot/Cold, or reflexes. Take, for example, Death Valley. It's an ASCII Tunnel Racer, where you have to move left and right without hitting walls for a specified length of time. I for walls, * for you, so it would look a little like this:

I              I

 I              I

 I              I

  I              I

 I              I

I     *      I

Doesn't look too thrilling, does it? Here's me playing it, at the difficult width of 8 characters spacing, on a BBC Emulator. I still suck at that game, even today.

Doesn't grab you? How about a management game? Space Mines is kind of like the ancient Lemonade Stand game... Except it also has random events, like radiation leaks, or the market glutting, ruining your net take if you do too well on the mining end. These kinds of games thrive by being text, although I'm sure a talented BASIC programmer could add some graphics for funsies.

Weird Games has the biggest proportion of these, though, with an ASCII pachinko game (Skulls of the Pyramid), a sort of pacman game (You are a shark, avoiding a hunter, while eating folks. Sometimes, however, your controls briefly randomise after eating someone!), and a "Bombing Run" style game where you are a witch, trying to pick up spell ingredients by diving onto them (Flying Witch, which, sadly, has an RNJesus death as another core mechanic). There's even a small text adventure, at a whopping... Well, okay, for these three books... 200 lines (or less, depending on system)

Finally, we have the graphical games. There's only two (Missile! and Touchdown), but they both use drawing commands, which shows the downsides of drawing on certain systems (To save your eyes, I'll just tell you... It flickers. A lot. Many old games used User-Defined Symbols instead, to make life easier.)

In the end, it's the outliers that make these books truly interesting, and each one teaches something new. Scrolling (in systems which need a SCROLL command to do so, and just by the text scrolling itself otherwise). More ways to use the RNJesus. Dear god, even realtime games and directional controls!

But the games themselves can only teach so much. Sooner or later, the young game developer has to leave the comfy nest of a DIY book, and get out there and PROGRAM. Do these books help with that? A little.

How Do I Change Stuff?

Awww... You... Actually wait, you should and you did. Bravo.

For me to even pretend I didn't need to learn how to change these games to grow as a programmer would be arrogant. More importantly, it would be untrue, because I certainly struggled, even at a somewhat precocious 10, to fully understand what did what in a linear programming language. But the two books I had, out of the three we've been looking at so far, did help a little. At the end of each is a short programming reference, letting you know what does what, and how to do it. It recommends other books in the series, and some more advanced books (Like, y'know, the thick-ass BBC User's Manual that came with every BBC Micro). And it set you little challenges, simple homework assignments.

How do you make this game more difficult? How do you add a game over message? How do you change messages? (Actually, that one shouldn't really have been in any of the books, because how it described PRINT was pretty fucking obvious, yo... But hey, 5 year old me was chuffed to get such an easy assignment, let's not rain on his parade and cause a paradox where I become even more crusty and salty, eh?) At least half the games had suggestions on things to do, ways to change things, and it didn't take a super-genius to know that a game about shooting bug eyed monsters could just as easily be about throwing chalk at Demanding Teachers, that the context could always be shifted round.

In a way, that was the most important lesson of all: That games could have context wherever the hell you wanted them to have context, and that all the worlds of imagination were yours. It even had sections, like the one pictured, that showed you how to add things, although it didn't get into the complexity of some of the other books.

In the next part, we'll deal with some of the Adventure Game books, and why these really didn't insult your intelligence.