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.

Experimenting with Genre: The Graphical Parser Games

Everyone who knows gaming knows that Text Adventures (or, as many know them now, Interactive Fiction) are a thing, and that Point n Click Adventures came afterward. What not so many know is that there was a middle ground that got explored quite heavily from the late 80s to the mid 90s: The Graphical Parser Games.

Why call them that instead of Graphical Adventure or the like? Because, as I noted, they're an in-between point. They had text adventure style inputs (and later early Point n Click interfaces), or collections of parser you could click on, and graphics. Here, let me show you an early example: Shadowgate. Notice the differences between that and, say, Maniac Mansion (released between this game, and the Atari STE game I'll mention next, in 1987)

Hit self: You die. Open door: You die.

While it's not the earliest example (that would be Deja Vu: A Nightmare Comes True, by the same company, ICOM Simulations), you can see many of the features of the prototypical graphic parse- What? You think it's an RPG? No, 'fraid not. There are no HP in this game, just a series of "You did the wrong thing and died horribly." No, really, there's a lot of that in this damn game. Going into the wrong door at the wrong time could kill you!

But we're not here to talk about the foibles of earlier designers, who often conflated "Dick move" with "Challenge" and "Replayability" because they didn't know better... So let's see... We have an EXITS doohickey we can click in the bottom left (useful, because often we can't look around), A set of verbs, an inventory, a self button, spells, and... Wait, what do we click on?

Ah, here's the "beauty" of these experiments. The items are actually on screen, and that's what you click! Shadowgate, as one of the earliest, actually suffered for this. Good example, under this carpet, or one very much like it, there is an item. The only way to tell this item is even there (and you need it) is to pixel hunt. What's that? Well, nowadays, most of the irritation is finding a small area you can click on to do a thing, mostly because of glitchy context sensitive controls in the games that have those. In older games, with a smaller screen size (Go look up EGA limits to get some idea of how big this would have been, at its best... Or perhaps CGA, for extra magenta funtimes!), the thing you could click on could be as small as... A single pixel. In among, at the time, anything up to 307,200 on the screen (or less, like Shadowgate)

Now you know why I'm a grouchy old sod about games sometimes... Because I grew up with this shit.

In any case, Shadowgate didn't have a great story, but other experiments happened around the same time as ICON's games. Here's Wonderland, as you would see it on an Atari ST.

And this screen, like others in the series, was ANIMATED too!

Pretty neat, huh? No? Well, consider that, at the time the Atari STE came out, you had... Er... GEM. Not even Windows 3.1. Fucking GEM. And these windows you're seeing? They aren't the Atari ST's Little Green Desktop (AKA Crystal, the precursor to GEM), they're a system that's part of the game itself. And all of these windows are resizable, movable, and can be closed out if need be. Of course, not every system got something this sweet. Here's Guild of Thieves on the C64.

Nary a window to be seen.

Not as cool, is it? In fact, apart from the well drawn pixel art (considering the limitations of the system), it's no different from, say... Twin Kingdom Valley, or Questprobe's Marvel graphical text adventures... Where, on most platforms they came out on, you had to specifically request the drawing, and it would look... Well...

You see a cabin in the woods. It is where you put treasure.

...About like that. But like their ICON contemporaries, the Magnetic Scrolls adventure games had a selectable parser. You could, if you were somehow in possession of an Atari ST without a working keyboard (Not completely uncommon, but relatively easy to fix), you could click on a VERB or COMMAND menu, then something either in the room, or in your inventory. It had separate windows for both, with pretty icons. In this way, the Magnetic Scrolls games beat the metaphorical tar out of their compatriots. So let's look at the final compatriot, which did one thing both ICON and the Magnetic Scrolls games didn't quite manage.

Legend Entertainment released their first game in 1990. It was... Er...

Hoo, boy... This is awkward.

...This, Spellcasting 101. If you guessed from this screenshot that the series (for lo, they made three of them!) was on par, writing and tone wise, with Leisure Suit Larry... You'd be quite right. But, regardless of my opinion of the game (Slightly embarassed it exists, thanks for asking), it nonetheless belongs to the subgenre, and Legend (With chief writer and ex-Infocom staffer Steve Meretzky at the helm most of the company's life) went on to better things. Mostly better, anyhoo. Fast forward two years, and you have their first tie-in (A thing they became famous for) ...

Know what impresses me? That item list!

...Frederik Pohl's Gateway. Based on the science fiction series of the same name (And, not oddly at all, the same author), the game was... Actually critically lambasted for feeling out of date, design wise. But suffice to say, it now has quite a cult following, as do Legend in general and Steve Meretzky. Sadly, the sequel to this game (also panned) was the last gasp of the subgenre in the mainstream, and after this, Legend went on to make first person graphical adventure games, with the mostly familiar elements you'd expect. And so history trundled on. But Legend pretty much thrived in this field, whereas ICON and the MS team... Didn't really.

Companions of Xanth: Not Legend's greatest achievement. That would be Callahan's Crosstime Saloon.

Experimenting with the Genre: "Failed" Boulderdash Games

Sometimes, experiments in a genre are missed, or aren't appreciated. I thought I'd start, in my usual "When it occurs to me" way, to take a brief look at various experiments in gaming history, starting with four "Boulderdash Clones" that were released on the BBC Micro over its shelf life: Repton Infinity, Bonecruncher, Clogger, and XOR. XOR, as we'll see, only tentatively fits this category, but some of you, no doubt, are scratching your heads and saying "Er... Bold-Her-Dash?"

Let me explain. This here, in the screenshot below, is a typical Boulderdash screen:

Boulderdash (The Amiga Version) - Prettier than the original 8-bit versions.

Now, there's quite a few things missing on this screen, but three of the absolute basic elements are here: Your hero (named Rockford), who must collect all the diamonds/eggs/whatever the hell thing he's collecting today (Believe me, it varies, but most often it's diamonds, because diamonds were easy to draw on an 8 bit game), while not getting trapped or crushed by rocks (which follow certain rules you can abuse, and later have to abuse), or killed by monsters and fungus. You also have a time limit in each level, which can, in some versions and clones, be reset or added to with a collectible. A nice, simple formula that spawned... Metric fucktons of clones.

But not every game was a lazy clone, and, while all four of the games I'm now going to talk about were moderately popular at the time, they've been relegated to the sidelines of gaming history, for the most part.

First up is Repton Infinity (1988, Superior Software). Repton was the BBC equivalent of Boulderdash, a green lizard man (Rockford's apparently human) who had three main games, a couple of standalone expansions, and Infinity. Infinity was, at its most basic level, a "Make your own Repton", and at first, it doesn't look much more fun to play with, or more powerful, than Boulderdash Construction Kit (released two years earlier than Infinity, in 1986)

But then you actually get into the thing, and you realise (mainly from the demo levels provided) that you can change the rules. Not many of them, but the templates provided allowed for more mechanics than had previously existed across the whole series. Below is one example of the modified rule and tilesets... The worst of the three.

Robbo Doesn't Want to Be Here.

Meet Robbo. Robbo, like Repton, has to collect... Things. But he has different obstacles, and they act somewhat differently to the way they would in the main Repton games: Instead of keys (Which open all diamond-holding safes), he has a computer disk... Which he has to actually put in a computer. There are things he has to hit with a wrench to make them work again. And there are things that don't fall the way you thought they would if you played much Boulderdash or Repton.

The Robbo levels were annoying as hell, but they opened up the game to ever so slightly more than just "I recolour Rockford to be Red, and make maps". I respect that. So, moving on...

Bonecruncher, also from Superior (I'm not promising, but there might be a pattern here), also experimented. It also had resources to collect, and if you could guess from the cover that it involved bones somehow, you'd win yourself an imaginary cookie: Bono, our hero, is the proud owner of a business selling soap to the monsters that surround his island castle. For reasons best left unexplored (IE - Because it's a puzzle game that wasn't actually worried about plot except as a framing device), monster soap is made from very human skeletons strewn around the castle (5 per bar of soap), and winning the level does not, in many cases, require you to grab them all... Just enough to make soap for monsters. Let's take a brief poke at a Bonecruncher screen.

Ahh, the only unhappy folks are Bono and that eggsiwhotsit.

Okay, we've got most of the game's puzzle elements on this screen, good enough (Thanks Wikipedia). Skeletons for soap: Check. Keys for doors: Check. Thing that could be a monster, but is actually your co-worker Fozzy: Check. Eggsiwhotsit that's probably a boulder: Check. But apart from Fozzy, this doesn't seem that different, does it?

Except... That arrow, and the unpictured elements, are what make this one unique. And challenging. See, even though it looks like it's side-view, it's meant to be a top-down look at a floor of Bono's Castle (Just assume I made a St. Bono U2 joke, to save us both some pain), and those eggsiwhotsits (Glooks) don't fall... But they do stampede in the direction of the most recently soaped-up monster. So, let's break down how this is more complex.

• We have to get skeletons. Okay, that's like Boulderdash, think of them as diamonds.
• Glooks, if they roll over us, will kill us, but will also kill anything they trap. Cool.
• Once we have five skeletons, we find a cauldron to make soap. Okay, that's new.
• Once we have a bar of soap, we can hit up a stairway to throw soap to a monster. This changes the Glooks' "fall" direction after a short period of time, allowing us to get to new places, and changing the layout. Ah, that requires a bit of thought...
• We also have two kinds of monsters, like Boulderdash and Repton. Like those games, they're a wall-traveller, and a chaser. Gotcha.
• We won't always have enough skeletons, which is a shitter, but, if we're low on skellies, we can trap chaser type monsters behind Glooks (if they can't move anywhere, they die and turn into a skeleton), or Fozzie can trap them (Don't depend on him though, his AI's a bit erratic)
• Unfortunately, Fozzie can also get killed by being trapped or Glooks.
• If we really want a monster gone, but don't need his sweet, sweet skeleton, there are pits, too. They'll kill anything that walks into them. Including Bono.
• And finally, once we've taken soap to all the moat-monsters, we move on to the next level.

Whew! That was a lot of changes, and some interesting and thought provoking ones at that! Alas, the fact that they weren't always implemented well in the map design, combined with the fact that sometimes reviewers miss the point, meant that it had mixed reviews. I'd hardly call it a "merely average addition to an already jaded format", but obviously, tastes differ.

Clogger, again, is a different beast.

I think it's safe to say... MY MIND!

Clogger is a strange one. Again, the "plot" is only a framework, but collecting things (Apples, in this case) is only half the fun! There was, as an aside, a sort of unwritten rule back then that a game had to have a plot. I've already written about how you don't need plot in a game, and that sometimes it's a waste of time here , and early game devs don't get a pass for this, even if the knowledge wasn't easily disseminated.

Anyhoo, what made this game different? Screenshots don't really tell the whole story, but the two main goals are as follows:

• Collect apples and pies.
• Make a pretty picture by pushing the pieces into place with your shovel attachment.

Now, those of you who've played Sokoban, or any other block puzzle game, will instantly see why this is both different, and very possibly frustrating as hell. You can only push. To make life even more "fun", our poor little Clogger can't go over rough grass (It clogs him up something fierce. Oh ho ho ho ho. Ho. Ho. ho.), although he'll occasionally find a thing that can cut grass when pushed. Not to mention other puzzle elements, like gyroscopes and... Look, it was hella complex, but the goals were shown relatively organically for an early game like this. As with most early games, however, reading the fucking manual was a must. I really should write a GTtMMR about folks not reading the manual, or folks not making good manuals, because it's not fucking rocket science, and people still cock it up! [pant... pant... pant...] Okay, rant over. For now. So that's Clogger. Finally, there's the odd one out here, XOR.

Yes, it says Commodore on it. Multi platform was a thing, even back in the day!

XOR, like the other games in this article, including Repton and Boulderdash, was about finding your way through a maze, collecting all the things, and reaching the exit. But, unlike pretty much every other game in this post, it didn't have a time limit. It didn't need one, because it was a game where failure was really easy. Let's do our best to sum up how it differed from its compatriots. Screenshot, maestro?

Well, that was needlessly abstract!

What's pictured are a few of the main elements: Masks, wot you pick up. Map segments, which show where masks are (but not you, or those wibbly bits), and wibbly forcefields that, depending on the way they point, either block vertical (pointing horizontal) or horizontal (vice versa) movement through them, but get destroyed when you move through them the right way. Also, that shield is us.

Not pictured is the other shield, which is also us (We can switch between them), chickens that always fall down (and can kill you if they fall on you), fish that move sideways (and again, kill you if they hit you from more than one tile away), and these four elements provide the majority of the challenge of XOR. It's all about "How do I get all these masks without dying or getting into a Dead Man Walking scenario?" , and I think the developer was very nice (compared to peers of his time) to not give a time limit for thinking about these things (also a password system and the ability to restart a level. Say "Thank you" !)

If you'd bought the game back in the day, you'd also have been asked by the dev to try and complete the game in a minimum number of moves, for a shiny certificate (Devs liked giving out certificates and letters back then, and I'm sure those who still have their shiny certificates are happy, despite the death-stares child me is throwing them from the ether to this day.) It doesn't look fun, but... Actually, if you like logic puzzles, it straddles that fine line between dickish and engaging with aplomb.

Now, at this point in the post, I imagine some people are expecting some sort of moral, or message beyond "Hey, look at these interesting past experiments in a genre mostly made of the same game, but with different maps for ten years!"

There isn't one. I can't say whether the devs got rewarded for their experimentation, or at least felt they did. I don't think it provides anything clear on the old "Tired Sequel XVIII: The Sequeling versus The New (And Possibly Bad) Hotness" argument (Which is a purely opinion style ballyhoo anyhow.) I don't even think all of them are good (I hate Repton Infinity, for example.) But I do think there's some value in looking at these experiments if you're into game development, seeing how changes to a formula can and can't work in a game. Hell, I think that's a good learning experience overall, for any dev, reviewer, or gamer who wants to know what makes this fucking thing tick. So yeah, they're easily found and played, so give them a shot, see what you think of them, and the changes they made to a formula that, honestly, started boring the tits off me somewhere around 1989.

A Realisation, And A Bridge Burned: Horizon

It's been a year since I last officially reviewed (there's your realisation), and only now do I feel okay with venting my spleen about one of the three games that burned me from reviewing for such a long time (the other two were Record of Agarest War and the Inner World.) Let's talk about Horizon. Another realisation: This is probably burning bridges with some folks. I'll have to live with that, even if they already know what I say.

Horizon is, in the words of LEO Interactive, "inspired by" the Master of Orion games.

No. "Inspired by" is a phrase that belongs to things like GalCiv, Endless Space, and many other 4Xs that followed in their great-grandpappy's footsteps in some fashion or other. "Inspired by" belongs to games that innovate, that change things up in a useful fashion.

Now, before we continue, let's play a game. I'm going to post a few screenshots, and you get to play "How similar is that?"

That one's Horizon. Now for MoO 2.

Now for Horizon again.

Back to MoO 2

Horizon...

MoO 2...

Keep in mind, I could keep this shit up for nearly every UI element in the game. The research screen: Almost identical. The planet screen? Same idea, same problems. The diplomacy screens? Nigh identical. So what, in the end, was actually different?

Well, remember how Master of Orion was slowish? Horizon is slow-er. It'll be a good while before you colonise, and as for a full game? I never finished, because I didn't want to spend three days on a single game. I especially didn't want to do it in "Story mode", which, yes, would have added some nice backstory on the many races and the universe, but would have involved me in a disadvantaged start (less tech, less resources, less systems), where the AI players inevitably found me before I could communicate with them, which led to another quirk of this game.

The AI defaults to a neutral state, and, while they modelled racial diplomacy alright (some races respond better to an aggressive approach, others passive, some like bribes, others won't touch them, etc), I often didn't have a chance in story mode. You see, the longer you know an alien species, without being able to communicate, the more they come to hate you. Oh, you have to be in communication range to communicate, obviously, and your signal strength depends on your tech level. Everyone you meet will eventually declare war on you. The missions, while a potentially interesting addition, are mostly bland and forgettable... Go kill these guys here, conquer this here, research this, loot this... It all adds up to a big, frustrating mess. The techs don't really differentiate much, and the key to winning the game, even now, is building up tourism and trade, and rush-buying. Oh, let's not forget surviving long enough to make these strategies work. Even in the non-story mode of the game, you're going to find people hate you before they even get to know you.

And if you were to purchase this game? That would be £23 you've, essentially, wasted. For that, you could have played Endless Space, Master of Orion 1 and 2, and possibly with enough left over to get one of the older GalCiv games. And any one of those would, awkwardly, be a superior experience.

I'm only sad I waited a year to say that even once.