Jolly diurnal cycle, reader! If you’re reading this, then it’s NotGDC time, and your old friend The Mad Welshman, has decided to lay some words on you!

“Wait, who? Is this gent a developer?”

Who becomes rather self evident by browsing around the site some (But, to sum it up, I’m a games critic and hobbyist developer, with a fascination for the lessons of the past) , but yes, I have made things… I just haven’t finished many things. But still, I do have things of use: Namely, learning from the past!

Game Engines of Yore (or “Appreciating We Have It Easier Today”)

Some of you, like me, may be hard up on the scratch, the old moolah. You might want for something shiny, something that will no doubt help you on your way to game developer stardom (be it the not-free versions of popular engines, or tools to help with texturing/modelling/digital art/music for your game.) But have you considered examining older tools?

No?

Well, let’s take a look at one, shall we?

Going Back To BASICS On the 8-Bit Systems

Nowadays, most game engines, even high-level ones like GMS or Unity, use what we call object oriented language. What this means is that you’re no longer stuck running this program or that program in strict sequence, but can instead organise things by scripts and objects. You can even have multiple objects running the same script (all enemies that just go up and down use UpAndDown dot cs , while every enemy uses DEADED dot cs , and so does the player… Well, organised well, it does.)

But in Ye Olden Days of Yore, what we had were procedural languages. What’s the big diff? Well, one program, for a start. One program, running everything, in sequence. Sure, you can go back and forward in a sequence, and even have shorthand for certain kinds of sequences (Generally called procedures) , but you go from line 1 (or 10, a programmer convention for reasons which will become clear) onward, until you hit either the END of a program, or you tell it to END (Useful if the player, for example, dies before reaching the actual END.)

“Not gonna lie, this sounds a bit… Shit.”

Well, yes, by our modern standards, it is a bit shit. In fact, it’s a lot shit, and it’s rather telling that people generally coded things NOT in BASIC, then turned those not-BASIC programs into machine specific Assembly Language (Which tells a computer what to do, bit by bit.) Much the same way high end languages, er… Turn their programs into machine specific assembly language.

I’ll tell you what it does do, though… It teaches you some of the earliest ways to make your life a little bit easier, a little bit tidier, a little bit smaller… That have been around since day one. We’ll get to those, but first, actually using those systems, for real, involves specialist kit. So what we do, is we get an emulator. For all that emulators vary in quality as to how well they emulate the thing they’re meant to, most of the 8-bit systems have free and pretty faithful emulators, and we’ll mention two systems in particular: The C64, and the BBC Micro. The former because it’s the more versatile, popular, and powerful… And the latter because it’s what I had.

Both use their own forms of BASIC, and both, funnily enough, have scads of now public domain BASIC tutorials (even some assembler ones, and many later type-in programs on the C64 were assembler programs), including the Usborne series. The Usborne BASIC books vary widely, from the listings books (mostly containing text only games, but with a few simple graphical games) , to the Write Your Own Fantasy Games book, which has an entire (if small by today’s standards) tile-based RPG engine and editor. What makes these special is that they were aimed at children and young adults (like little old me, back in the day) , and the things they teach… Can be applied elsewhere. Even in adding to these programs, better understanding can be reached.

Take Iceberg, for example. Over the course of a morning (the morning I wrote this, funnily enough), I turned this…

Into this. I could have prettied it up further, and even added sounds (Not that you’d want that, on a BBC Micro. Some of those sounds were dire), but I did it using principles both further in the book (Missile, for custom characters and the VDU command), and in its sister book, Space Games (for PLOT/MOVE/DRAW commands, and the reminder that the BBC originally didn’t do squares, only triangles.) Along the way, I (re-)learned a couple of important lessons.

It Is Important To Have A Plan

BASIC, by and large, doesn’t have an INSERT function. It doesn’t, generally, let you say that everything from 30 onwards is now 1500 onwards. Equally, the further back in a BASIC program a procedure or line of code is, the longer it takes to run, because a BASIC program goes down the list. If it has something in line 30 calling something in line 1500, it goes from line 30 to 1500, checking if any of them are 1500 before doing anything. It will also run things in order, regardless of your wishes. Did you want to draw the square, then the smaller square on top? Put them in the right order, then.

As such, the code you use the least goes at the back of the program, while the code you use the most (that isn’t a PROCEDURE, because those are basically fancy subroutines in BASIC) goes closer to where you called it from (or right bloody there, if you can get away with it.)

Funnily enough, for all the jokes about BASIC programmers, this teaches folks how to subdivide their tasks well. In rewriting “Iceberg”, I knew I wasn’t going to need to define my custom characters (equivalent of sprites for those who don’t want to faff around with DATA statements all day to similarish effect) or draw the background more than once. So it went at the very back of the program. Checking for inputs and moving people, however, was something I wanted to do a lot, so that came, technically, before the program even knew what it was going to be moving when the right key got hit.

I say technically, because it would have thrown up an error if I hadn’t written the whole thing in one go. Something about a procedure not existing because I hadn’t written it…

Still, speaking of custom characters… The way those are done is, itself quite useful!

How Old 2-Bit Sprites Have A Lot Left To Give

Custom characters are, effectively, 2-bit, 8×8 sprites. What’s that mean? Well, they’re additional ASCII… But ASCII you customise. They consist of 8 pixels by 8 pixels, and each pixel can be on (paint this) or off (don’t paint this.) Simple, right? But beyond the fact that I used only 3 of my 20 or so allotted custom characters to prettify Iceberg some (and then another 10 for the title, and another 1 for a “paint over this” character I may not have needed), the way these are constructed is useful for more than just sprites.

No, they’re useful for aaaaaall sorts of things. Let’s take a look.

Each sprite is written, not as 8 series of 0s and 1s, but as 8 numbers, between 0 (no painting here, boss!) and 255 (FILL THIS ROW WITH BLOOOOOD!!!) Each number, however, represents those 0s and 1s. Each number, coincidentally, is a single byte. Not kilobyte, or megabyte. Byte. 8 bits. 1B. 8 bytes makes for a single 8×8 sprite of 1 colour. And this is how it counts.

128 64 32 16 8 4 2 1

A 1 under 16 is 16. 3 of those makes a middle finger. 3 20s, by contrast, is me educating about 2-bit sprites by being vulgar for the second time in a row. A 254 makes the knuckles, two 255s makes the thumb, and two 124s makes the wrist. Congratulations, I have now taught you part of how to be vulgar in 2-bit spriting. But wait, it gets better!

What if, instead, in your modern game engine, you told it that each single number, from 0 to 255 (which can be expressed as a single hexadecimal number, by the by) represented a tile of your map? Now, that isn’t going to make it one byte, sadly. But pretty damn close. 1 byte (let’s say), per tile of your map, representing any one of 256 things (255, if you want 0 to be nothing.) Or, if you only need to know about one thing… One byte representing 8 tiles of your map. Or half a byte for 15 things on a single tile of your map.

This is, friends, a trick still used today in many a tile based game. It’s a trick that lets you write your maps as gobbledegook (that you have the key to… Or at least, I hope you do, and have written it as a comment somewhere in your code!) , while also making it easier for maps to be edited in-engine… While also ensuring that, if you write your own missions as part of the game’s code, means anyone wanting to mess with your beautiful, hand crafted maps can either go take a hike, or spend several weeks with a debugger, trying to work out what’s what. You can even use it in procedural generation (making things according to rules, often with a random or pseudorandom element), because you’re moving numbers round an array.

Oh, and if you have tilesets? That 1/2/15/255 things can instead be “The 15 things specific to this tileset.”

There’s other ways you can take that, but this is a fine example of learning from old methods.

Finally (For This Part) …

BASIC, the books, and the like, teach a couple of things. But one thing they teach, that applies just as much, if not more today than it did then, is this: Games, for the most part, only look complicated, and the magic isn’t, strictly speaking, in the code. With BASIC, what you learn drawing a box, then putting another box on top, another on top, and some text in that box, applies to every time you do that. With Unity, Game Maker Studio, and Unreal effectively narrowing the amount of faff you have to learn around drawing that box, and the box on top of it, etcetera etcetera, you know that you can apply what you know about clicking a button to clicking on an area of the screen. You know, thanks to modern object oriented programming, that once you’ve written a piece of code that makes something bounce up and down, you can apply it to everything that just bounces up and down. Quite literally.

But it’s been a long road to get to this point, friends. And some of the lessons taught, way back in the early days, when you had a massive (HA) 32k of ram to play with (If you were lucky, or rich!) still apply, and are useful, to this day. Go back, sometimes. If not to appreciate that yes, life is easier, and yes, you can do it… To learn a few tricks from the “Good Old Days” where bullshit had to be pulled just so the game could fit.

If you want to experiment, emulating the C64 (considered one of the most versatile 8-bit computers, and with a damn fine music chip) is one option, but others from later periods include STOS and AMOS (Atari ST and Amiga respectively, both competitors of BlitzBasic) , The Quill, SEUCK, or the Graphic Adventure Construction Kit (Multiple platforms for text adventures, multiple platforms for shoot-em-ups, multiple platforms for text adventures with graphics.) Reading the manual, by the way, is usually a good idea with all of these… For a more modern example of programming within limitations, Lexaloffle’s PICO-8 and VOXATRON are both good choices, the latter being voxel based rather than pixel based.