Thursday 29 January 2015

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.

No comments:

Post a Comment