Why SHOULD I Read The Fucking Manual?

Manuals for games are a big can of worms, because there is this feeling in game design these days that it's just plain better to design things so you don't need a manual. Games are, after all, meant to be for everyone, including those of us who don't fink so gud. That's inclusive, and inclusivity is a nice thing... But I'm not entirely sure I agree, for several reasons. Still, let's start this discussion off with "What the heck do game manuals look like, and why did we need them way back when?"

This here is the original game box for Wasteland, an RPG you may have heard of considering it recently got a sequel, currently in Early Access, and both its director (Brian Fargo) and its spiritual successor (Fallout) are pretty well known. Now, look a lil' closer, and you will see... Holy shit, that's a big ol' honkin' book, isn't it? And there's more than one of 'em! Gaaaaahd, how could you be expected to read that shit?

Well, firstly, you were expected to read dat shit because RPGs are often quite complex, and limitations of the systems they were on meant that you couldn't fit everything into the game. In Wasteland's case, there are two books: The actual manual, which describes the stats, how they interact, some skills (manuals of the time sometimes had misleading information for reasons of plot or designer dickishness. Not quite cricket, I know), and how to control what, at the time, was a fairly complex game (and, to be fair, still is). The manual served a second purpose, which is part of why manuals largely fell out of vogue: It allowed the designers to take shortcuts. Why work harder to make your UI more intuitive, when you can have a manual to describe it?

(Sometimes, though, folks are just bad at UI design...)

The other book, however, was the real doozy. It was a combination of copy protection, and a way to get around size limitations. See those floppy squares? Those are 5.25" Floppy Disks, and they had a maximum filesize of... 360 Kilobytes. Go look at your "My Computer" screen, or equivalent, and let's go downward. I have a 500 Gigabyte and a 3 Terabyte Hard Drive. My DVD-RWs for Let's Play backups have a 4.75 GB limit. Tera... Giga... Mega... Wow. Them's some tiny files, right?

The Wasteland Paragraph Book contains any long talky bits for the game, along with fake talky bits so anyone who wanted to try and skip ahead in the story could very easily fuck up, and it had something like 500 paragraphs. Let's assume the paragraphs had an average of 50 words, with an average of 5 characters. That's 125,000 characters. Each one of those characters takes, effectively, 1 Byte, so encoded in the game files, that would be 125 KB, or slightly less than half the allowed filesize on a disk of the time. In practice, it would end up a fair bit smaller (Probably around 40-60 KB), but like I said, it doubled as an anti-piracy measure.

It also ended up getting around another limitation. Here's a Wasteland screenshot.

Hrm. That's something like 20 words. They could have displayed the paragraphs, but it would make the game a lot more tedious to play. Since it's not really real-time, it takes very little effort to flick through the book, and everyone's happy.

But anti-piracy measures moved on from something as easily circumvented as "Read The Fucking Book/Take numbers off a card", and I'm actually sort of glad about that, because while they sometimes got inventive in a good way, they also started doing such boneheaded things as black text on carbon paper (which is red), and really small fonts, in order to discourage copying. If anything, this had the opposite effect, and I remember Dad and I tearing our hair out at trying to decipher the codes on the TMNT anti-piracy sheet, and eventually writing what codes we could on a TXT file and printing it off. Since not many folks I knew even had a PC at the time, this wasn't a ticket to easy pocket money either, more's the pity... Because the TMNT game in question was shit.

Another hotly contested thing manuals did was set up the lore for the world, or provide a miniature encyclopedia. "But Jamie!" I hear you cry "You can have an in-game encyclopedia now!"

This is a bad in-game encyclopedia. Partly because it's badly written, but mostly because it's a FUCKING RACING GAME.

Yes. Yes you can. But it has exactly the same potential flaws as a lore-book, and it has one flaw that printed versions don't have: You can't read it outside of the game. Why would you want to read it outside of the game? Well, if your in-game encyclopedia is actually good, it would be because you wanted to learn more about this strange world you'd found your character in, to know things the designers didn't put in.

And here's where it gets complicated. Because modern game design quite rightly states that the hierarchy of tutorial methods (and, to a lesser extent, world building) is Do > Show > Tell. Whenever you can, it is better to either outright show an aspect of a culture in a game, or at least imply it. However, to show that it's not all that simple (Give respect to game designers, yo, they have a hard job), we have to consider flow.

Whoops. Somebody fucked up their flow!

Flow is not, as some believe, a nebulous, arty farty game design concept, but something any good game designer has to worry about. Ever had that "Ugggh, this cutscene came in the middle of a fucking boss fight, and he attacks right after!" or "God-fucking dammit, now I have to look at my journal while I'm being attacked!" ? That's bad flow. It's not always on the game itself, as well: I've complained, in the past, of "Ugh, fighting breaks the flow of this game too hard" in Mirror's Edge, and in fact, that was a common complaint when it came out. But on examination? A lot of that was me, not the game. There are rarely places where you have to fight, and those places, it's pretty clear that, well, that's the only way out. The rest of the time, you have lots of options for just plain avoiding the cops that try and bar your way, and the game's simple visual language means you have very little excuse for not using the environment well.

In a turn based game, you don't have to worry about flow so much, so you can leave lavish descriptions and lovingly crafted stat pages right there in the game (although most double down and have a PDF you can alt-tab to or print sections of.) But in a more action oriented game, you just don't want to know right now, thanks! So doing this well helps a lot. I'm Let's Playing the series now, and have a soft spot for it, so let's talk briefly about lore done right in the Wipeout series.

It helped that the game was fairly pretty for the time, too.

Wipeout's manual was pretty simple. It had to be, because PS1 manuals were generally quite small. But they wanted us to care about the world and teams. So they had team profiles they felt they couldn't fit in the game. Okay, we get a favourite team (Qirex for the win, as an aside!) But they also had little press releases that told us about the world... And it wasn't as nice a place as you'd think, considering Anti-Gravity had pretty much decimated Big Oil, and helped the environment a little bit. They had track blurb, that also added to this, and later games in the series also had tidbits of lore tucked into press releases on the official site, a timeline we could build up of the world... It was a technical racing game, but we had added reason to want to play it because the world was interesting!

That, and PS1 parties at raves, were both pretty useful marketing tactics, and the series sold pretty well, for the most part. So manuals can serve a useful purpose that isn't just "haha, you need this manual, noob!"

But the biggest concern, the one that really nails the lid shut, is that it's a) not cost effective to print manuals much anymore, especially when you have the PDF, cutting printing costs entirely, and b) It's more environmentally friendly. But there's a good reason Official Guidebooks, especially ones that hint at the larger world, or give info that just couldn't be put into the game, still exist, and sell like hotcakes.

So how do we resolve this? Well, different companies resolve it in different ways. Portal and Dark Souls both do the "Implied world" and "Teaching through play", and that mostly works. I say mostly, because sometimes, not even excellent design can help some folks. Yes, you've tried to put a portal on not-white surfaces for the last half hour, dude, maybe it's time to try something different?

There is nowhere here to put a portal. Stop fucking trying.

Thief (the original one, not the bastard child of 2014) had optional lore, a tutorial mission, and again, implying details about its grim world, often through the hilarity of some seriously obnoxious guards (In a good way... You'd have to have played to understand why "Y'wanna go to the bear-pits tomorrow?" can send me into peals of laughter)

Paradox strategy games, and many others, do indeed have big honkin' manuals, and lengthy tutorials, and ohgodihavetoomanyindustrialistswhygodwhy... Maybe Paradox, as much as I love them, aren't the best example... And many RPGs have... the same WALLS OF TEXT AND LORE, but in dialogues with other characters. That's... a double edged sword, because when the writing and the voice acting is good, just like a manual, it's engaging, but when it isn't, you get "And LO, Did The Archimandrite Of Thessalinicamanica Blah Blah Blah Blah Blah Why Haven't You Hit Skip Already [important info] Blah Blah Blah."

So, when you're designing a game, spare a thought for the manual. It's good design not to rely on it, but it, and your in-game encyclopedia and whatnot, are important tools, even in something as simple as, say... A twin-stick shooter series. It can give players a reason to care about your game, it can clue players in to advanced strategies. You have to account for the fact that folks might not read it, but if you're going to do it, do it well. In game or out, it may well help deflect that old saw of "UGH, THIS GAME SUCKS BECAUSE [Long rant translated to: I didn't pay any attention whatsoever to the game] !"

It's still a valid option, even today.

Games Journalism: We Are *All* Only Human.

For anyone keeping up with gaming news, Peter Molyneux recently got it in the pants over Godus. Bigtime. While some things needed to be said to the British GameDev Wunderkind, others didn't, and it made me think of something we tend to forget: Everyone in the Games Biz, from the devs to the journos, to the players, are only human. And we tend to forget this. All of us.

The Devs

Warren Spector, from Martian Dreams.

Richard Garriott. Warren Spector. Graeme Devine. John Romero. These, and many more, are names to conjure with in the games industry. But we, both players and games press, tend to overlook the oddities and failings of these folk. Go look at Martian Dreams and Savage Worlds. You'll find a literal self insert of Warren Spector in both. In fact, Wikipedia has a selection of his self-inserts on the page about him.

They're good folks, but they're not rockstars. They have their failings. Tabula Rasa was a flop. Thief: Deadly Shadows definitely had flaws. Even the series I'm currently Let's Playing, Wipeout, Made Mistakes.

But we have a tendency to ignore this, and when we do discover folks have their human qualities, not necessarily good ones? We tend not to react too well. An extreme case in point: Phil Fish. Phil Fish is another dev who's been raked over the coals, for the crime of... Being abrasive and temperamental. And because he is a public figure, a celebrity... The reaction is disproportionate.

But let's look at the other two sides here.

The Journos

As someone who used to review, I'm just as guilty as every other game journo out there for being attracted by something that just... Doesn't... Work. In my particular case, a prime example would be Nuclear Dawn.

If you can instinctively make sense of this, congratulations, you could be a Nuclear Dawn Commander!

What, you haven't heard of it? But it rewards good team-based play, actually talking to other players, and... Oh, yeah, it didn't do very well because it wasn't accessible to the average player. See, the average player, for various reasons, just wants to god-damn play. They want to shoot mans, not stand in a corridor waiting for an enemy push they're not sure will come. They definitely don't want some asshole telling them what to do (Especially if said asshole turns out to be incompetent), and they don't want to spend time guarding said asshole from the enemy, even if that's a vital element of the game.

So what ended up happening was that whoever co-ordinated and/or had a decent team leader would steamroll the pubbies. Again. And Again. And Again. And lo, it Wasn't Fun. So the servers were nigh ghost towns, and the game didn't do nearly as well as its interesting gameplay could have gotten.

On the other end of things, for me, was Blur, by Bizarre Creations. Blur had problems. The track design meant that a reasonably skilled player could DNF (Did Not Finish) all the other racers on many tracks, people were having connection issues out the wazoo, and a third to half the vehicles were basically reskins. But the first part and the third in our equation, Players and Devs, came into play here...

Blur: The Big Boys Mario Kart. Oh ho. Ho ho ho ho ho.

...You see, Bizarre Creations also made Project Gotham Racing, which was, in many folks' minds, a Good Series. So when a review score was lower than expected, they came out to complain. I didn't get a whole lot of complaints (A whole ten, I think... I'm not a celebrity writer, never was), but, on the strength of those, my editor at the time claimed that I had been "experiencing day-one issues".

Three months later, I issued a re-review (Something many game journos will tell you is a bad idea), and nobody appeared to care one way or another. Bizarre, you see, had started copy-pasting responses to bug reports, claiming it was being fixed, while already talking about a sequel, and working on another game (Bloodstone, which also Had Problems).

They folded a few months after my re-review. Now, here comes the weird part. The players came out again, but they didn't yell at me (Who scored the game pretty low). No, I opened up the letters page of PC Gamer, to find someone blaming them for the demise of Blur. This was pretty irrational, as PC Gamer had been a lot nicer than I had, and didn't even mention many of the issues seen with the game.

It was a head-shaking experience. But it leads us nicely to the third part of our little equation.

The Players

The Bush-Wookie in his natural habitat.

In a very real sense, the players are a more diverse group than either the developers or gaming press. But what you see isn't that diverse at all, because what most folks see of a playerbase are comments, forum posts, and meeting them in actual play... And the bad tends to stick out like a sore thumb.

The Mass Effect 3 Ending. Starbound's "Caveman Tier" play. Fucking Bush-Wookies. The list of things players complain about, not always making sense, is immense. Let's take the Bush-Wookies as an example.

Bush-Wookie is a nickname for Snipers in the Battlefield series, especially Bad Company 2, because their camouflage... Well, it makes them look like Wookies from Star Wars. Also because it helps them hide in bushes. Duh.

The problem is, a good sniper, in pretty much any multiplayer game, can lock down entire areas of the map. And it's a massive pain in the arse to dig them out. Never is this more prevalent than in the Heavy Metal map of Bad Company 2.

Heavy Metal, aka OH FUCK LEAVE THE SERVER.

The map doesn't show it very well, but the middle capture point here is flanked by two hills, and there's an AA gun in the village, just off to one side of the point itself. Snipers/engineers in those hills can fire as far away as either of the other capture points, and getting them out often requires air support, which... Oh. Oh. Again, we find that the fun of the game is instantly ruined for the average player if they're up against a co-ordinated team. And, in the case of BC2, it doesn't even have to be voice co-ordinated, because the classes make it fairly obvious where you should go. The snipers will graduate to the hills, because there's a lot of cover and disguise up there. The engineers will graduate to the hills, because it's relatively safe from the AA guns, and allows them to kill the vehicles they're meant to. Meanwhile, the medics will assist the assaults, who will die in droves as they either try to take the next point along (Which will have everything coming their way), or try to take B (Which will be protected by a force that can efficiently deny you entry if they're even halfway competent)

In this map, among others, snipers are a massive force multiplier. It doesn't help that playing a sniper as realistically as possible (Moving after shots, not revealing themselves as best they can, staying outside the range of the other classes) means that the sniper has a reputation as a player out to ruin other people's fun.

It's not an entirely unfair point either, because some of them genuinely are. Which is annoying, because there's no easy solution. Battlefield 3 went with making snipers easier to spot and more likely to get into short range firefights (Which they'll often lose), but this makes playing a sniper less fun.

Wait, that's not the right image... DAMN YOU, GOOGLE SEARCH, YOU SHOULD HAVE TOLD ME WHAT TO LOOK FOR!!!

Part of this problem though, is that players go in with expectations, and when those expectations aren't met, they're unhappy, whether because it wasn't properly explained what sort of game it is, or because the mechanic was genuinely badly designed... Often, it's because they just don't get it. Good example of that: The Portal Gun. The Portal Gun doesn't make portals on anything but white walls (Covered in moon-dust, apparently), and both games try to show you this. But, because they don't explicitly tell you, and remind you, you get folks who completely fail to understand how it works.

Those people aren't necessarily stupid. The game isn't necessarily bad. But the players' expectations coming into the game may be unrealistic, or the game isn't communicating to the level of the average player.

Even this commentary on expectations is going to be subject to problems. I've seen these points examined before, and you know what I hear when they're discussed?

Entitled. No Moron Left Behind Policy. I Shouldn't Need A Tutorial, Or To Read The Manual.

Yeah, okay, players can be entitled (Oh, dear lord, they can be entitled!) It only takes a quick look at comments on negative reviews to see that ("How DARE you give X a 6/10! It's CLEARLY PERFECT!"). But many of these are knee-jerk reactions, whether on the part of devs, or players, or journos, and there's no easy fix for any of it.

No, really. We could say "Devs, please try to be more human", but that won't work without players shifting their worldview, and journos not instantly squeeing the moment Big Name is mentioned, and a lot of other things, too. We could say "Journos, please think more critically", but that would require devs and players alike agreeing what that means... And we've all seen how well that's been going so far... We could say "Players, please try to read tutorials more/shift expectations", but that's massive generalisations about a very diverse group, and it can't help but offend at least some of them.

We could say a lot of things, but a lot of it has to do with one basic principle, which I fully understand is hard for people (myself included). Be More Aware. For example, be aware that once a game has a flaw baked into it, it's often going to be very hard, even if you genuinely are a rockstar super-developer, to change it and/or get it out. Be aware that sometimes, you're not going to like the writing in a game, but that's no reason to scream bloody murder (Sometimes quite literally). Be aware that not all games are for you, specifically, unless you truly want to learn how to play them. There's a lot of "Be Aware", and while all those examples were for players, there's a lot of others for the journos and the devs too.

Funnily enough, this blog post isn't about fixing the problem. It's about Being Aware That It's There.

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.

New Ideas: Why Listening to Other Perspectives *Helps*

So, while it may not seem it, I've been working on a game at a glacial pace (Mainly because, before concentrating on gamedev, or reviewing, or a number of other things, I want my life to be stable, and, quite honestly? It isn't, not really...), and writing down other ideas for the time when I'm actually able to work on them.

But recent events, and new acquaintances (Hopefully friends, but I'm not going to be presumptuous and assume such) have encouraged me to go back to the drawing board. I actually rewrote that last sentence, because I said "made", when, in reality, "encouraged" is a much better word. I should also note that while I go into two folks here (and a third group), there are many more, so if I don't mention you, don't take that the wrong way, please!

You see, these perspectives have not only given me new ideas, but also, before they're even fully fleshed out, criticisms of those ideas, areas I can improve. And, as anyone who's worked on creative projects knows, a well constructed criticism before you've set your projects in at least clay is extremely useful. Obviously, a less well constructed (or destructive) criticism can sink a project, but since this isn't the case, we'll merely mention that, and move on to the folks I've met, and their perspectives.

Let's start with Veerender Jubbal . Veerender is one of the nicest people I've met in recent months, he happens to be a Person of Colour, and he happens to be a Sikh. Despite my saying "happens to be", these are actually both quite important. Because just like women, the video-games industry does not appear to have much of a PoC perspective, and Veerender was the first person in a while to remind me of this. More folks followed, and one group in particular will also be mentioned. But let's take a brief moment to digress on my main project (I'm not afraid of someone "stealing" the idea, because A: Not a lot of folks read my lil' ol' blog, and B: Each developer puts different touches on much the same basic idea. This is a kind of diversity, but not in the sense we're going to discuss.)

My main project at the moment is a game called Section M. It's inspired by three things: the works of Charles Stross (Which I may never live up to), the works of Howard Phillips Lovecraft (Which, in a sense we're going to go into, I don't want to "live up to"), and Covert Action, by Microprose. Set in an alternate 1930s-50s (Still haven't *fully* decided yet), it is planned to have similar approaches to Covert Action (Minigames as a mechanic for the duties of a covert operative attempting to disrupt the plans of various organisations in a Cold War setting), but set in a world where the Great Old Ones were given temporary lease on the world, which led to horrors greater than World War II, changes to the geopolitical structure, and the bringing to the fore of the dangers and wonders of the supernatural.

Obviously, I am somewhat of an idiot for making this my first major game project (Which is why I'm also, when time permits, working on smaller games to make sure my skills are up to the task), but Veerender has highlighted a certain aspect of this idea that, to my shame, I didn't actually notice that much before.

Where are the Sikhs? Where are the People of Colour? Many games in the modern day (A little less so in earlier games, where characters were more of a Tabula Rasa (Blank slate you project yourself onto)) have all the main characters as white heterosexuals, often male, and when People of Colour are put into games, it's in roles already noted as ideologically contested (Meaning, generally, offensive stereotyping and creepiness... Not the best summary, but it'll do for now). The Spirit Warrior (Native American), the Token Black Guy Who Dies To Save The White Hero, The Mystic Indian... There's a big ol' list of stereotypes, and even many games today include them, unaware of how somewhere out there, there's an entire segment of folks they just pissed off with one character.

Now, this goes back into a comment I've thrown out a few paragraphs back: I don't want to emulate all of Lovecraft's themes. I specifically don't want to emulate the fact that he projected his own dislike/fear of People of Colour and his attitude toward "miscegenation" (Interracial relationships, and I put it in quotes because the term itself is... Well, not the most enlightened, as it deeply implies biological differences between white folks like me, and People of Colour that weren't, and aren't actually there.)

Go read a bit of Lovecraft. Notice that many of the villainous individuals and groups in his works are, in one form or another, interracial ethnicities. As an important aside, I grew up with the term "half-caste" for folks who are children of white and non-white groupings, and, even fully aware that it's considered an offensive term in the modern day, I have to edit myself not to use it as a description... Which, if you think I'm the tolerant and open-minded person I believe myself to have become, is a single example of why racism is so problematic to deal with... Because often, those of us who grew up with certain words still reflexively use them, even though they fully understand why it's not a good idea to do so. (Caste means "purity" or "race", so... Half-pure, half a "race".)

So this now leads me to feeling that I want to actually think about other cultures within this world, outside of "They exist", and to explore, somehow, somewhere, the cultural identity of these fantastical races that may have cropped up in universe. Which neatly ties into the next person I wish to talk about.

But before I do, let me link you to a stepping off point for exploring this yourself: I Need Diverse Games (and their Twitter feed), a Tumblr Blog exploring issues of race in videogames, and some other perspectives you may want to explore if you're a game dev.

Okay, so we mentioned cultural identity. Cultural identity encompasses a lot of things, because, surprise surprise, there are a lot of cultures out there, all with differing attitudes to beauty, women, men, LGBT issues, race issues, politics... And religion. Now, I fancy myself somewhat of a hobby scholar when it comes to religion, but there are those who seriously study the subject, and those who then apply this thought to the theory of game design. One of those individuals is Jenni Goodchild , who studies Theology and Philosophy. And she, also, has made me seriously consider aspects I am ashamed to say I had not considered seriously before. Namely, religion in video games.

I won't go into too much detail on that one, except to say that my own perspective is a syncretic belief, essentially pantheist in nature, that nonetheless does not place deities very highly on the trust scale. I'm also going to start by linking a video, specifically a recent talk Jenni presented for VideoBrains: Playing Games with Gods: Why Games Need Religion

Don't worry, this blog post won't go anywhere while you watch it, I can quite happily wait. Especially as it raises many valid points about how we don't really think about these things. And, because I wish to change this, I will quite happily own up to being guilty of this. Points to especially listen to so far include how Bioware might not have thought their "different" religion through, how Civilisation: Beyond Earth deals with religion in a very interesting way, and how the Elder Scrolls series, essentially... Doesn't (or rather, kludges it somewhat). That's just from the first half of the talk, by the way.

So now, I find myself quite happy with this "predicament", because both of these people have highlighted more places for me to potentially explore. Yes, okay, I now have more work to do before I can consider the game's setting, lore, and the mechanical support I may have to introduce into my project, but at the same time, these two people have, by drawing attention to how little I've previously thought about these things, opened up whole new cans of worms for me to slop my hands into, feel, and examine... If that sounds gross to you, many folks who work in creative fields, even as a hobby, think of concepts as things we can explore, dissect, get our hands dirty in, and we love it. We also love folks who give us ideas, especially by pointing out areas we can improve in, and, more to the point, how to improve them.

So be fully aware, game devs, that more perspectives may be, at times, confusing, distracting, more than a little heartbreaking... But by taking in, by wishing to know other viewpoints, and to understand how your viewpoint will nearly always be lacking in some area compared to someone else's, you can not only improve your games... You can improve yourself.

I only hope I do at least an okay job of that. And I hope you do too.

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.

So... Ludum Dare 30...

In approximately 9 and a half hours at the time of writing this sentence, I am going to be taking part in Ludum Dare #30 , a 48 hour game developement competition. I only know vaguely what themes are going to be presented (as the final vote is tallied pretty darn close to the start time), and for those who don't know, the only assets you're able to create beforehand are code snippets, which have to be approved beforehand. Everything else is done in the 48 hours, code, assets... everything.

So let's talk about prepping. Even though it's a really good idea to have some code snippets handy to save you time, I'm not doing this, because, beyond the fact that it will involve pixels, I don't want to prejudice myself with code snippets specifically for a platformer, or a tile-based RPG thing, or... You get the picture. I also know one of my biggest problems here is going to be organisation, so I didn't want to suffer for that early by having to waste time hunting through code snippets.

No, most of my prepping right now is psychological. I've tidied up the flat a bit, and am listening to various tunes (including the modern Lost In Space theme by Apollo 440... That's a really peppy piece.)

As far as tools, right now, I'm pretty determined to use Gamemaker Studio. No piece of kit is without flaw, but this'll hopefully save me some time. Apart from that, I have Paint.NET (for blog stuff, as opposed to dev stuff, but it's workable for asset stuff), GraphicsGale Free (for pretty pixels), LMMS (for music, if I end up having time for that), Audacity (for voice work, should the game warrant it), and Notepad++ (because I like writing shit down.)

Finally, there's me. I know a little bit of coding, am okay at assets, am okay at music, and do voice things for shits and giggles. I am a jack-of-all-trades. Hence why I'm not in it to win it, but to see what needs working on with my practices under pressure.

One other piece of psychological buffing I've done, silly as it sounds...

...That's right. Monitor JuJu.