[Author's note: This is an edited repost of something I wrote for my personal blog precisely five years ago today. I'm currently in the process of burning my old website to the ground, but I thought this was worth sharing.]
When I was 11, there was a computer in our school library that pupils could book in 15 minute time slots on at lunch time, usually to do homework. My friends and I were just starting to sit up and pay serious attention to PCs, and we would often stop by during morning break and try to book multiple sesions between us. At the time, I was excited enough just to be using a PC. There was no internet connection, and the computer wasn't powerful enough to run Warcraft II, but for a time I was quite happy to just noodle around in Windows and DOS. Probably the most exciting activity we could legitimately engage in was to browse Encarta for interesting multimedia clips.
Anyway, events took a dramatic turn one day when a friend came into school with wide eyes and a floppy disk, telling wild stories about a exciting program he had stumbled upon. That program was QBASIC, an IDE created by Microsoft and distributed with later versions of DOS – those of us with PCs at home all had a copy, since we had all installed DOS from the same disks. Later that day, we crowded around the library computer as he revealed the contents of his disk. He had written a simple game about anagrams… a jumble of letters would appear, and the player had to type in the unscrambled word or phrase. There was no randomisation, just a simple model of:
- Display a phrase
- Wait for the player the type in an answer
- If the answer is correct, move on to the next phrase; if not, then repeat the current phrase
It was a terrible game, but we were all interested by the idea of writing our own programs. Like many Brits of a certain age, we had a little experience of writing BASIC code on a BBC Micro in maths class, but this was another world. We all went home that afternoon and began teaching ourselves to code from the Help files – copy/pasting code samples, fiddling with their parameters and observing the results, that sort of thing. We were also delighted to find some sample games were included – NIBBLES (which was basically Snake) and GORILLAS (which was basically Artillery). Both games were far too complicated for us to understand the inner workings of, but they shined a light on what could be achieved.
Soon, we had all mastered the same handful of commands:
- CLS (clears the screen)
- PRINT (displays text on the screen)
- INPUT (allows the user to type things in)
- IF [...] THEN (allows conditional commands – used to create logic gates)
- GOTO (jumps the program to the specified line number)
- END (ends the program)
We used line numbers to create ‘bookmarks’ for useful blocks of code (although in practice we tended to number every line), and learned that putting $ on the end of a word created a string variable (used to store text in speech marks – eg. name$ = “Buck Handsome”) and putting a % on the end of a word created an integer variable (used for numbers, without speech marks – eg. Age% = 47), which could be manipulated using normal operations (eg. AgeNextYear% = Age% + 1). And if you followed all of that, you already have all the tools you need to create your own games in BASIC.
A simple program would look something like this:
20 PRINT “What is the capital of Burkina Faso?”
30 INPUT answer$
40 IF answer$ = “Ouagadougou” THEN GOTO 60
50 GOTO 10
QBASIC programs run as a linear sequence of commands. You can read it very simply, like a book – start at the first line, and simply follow the instructions down, line by line, until you are explicitly redirected by a GOTO command. If you ran this program, it would keep asking you to name the capital of Burkina Faso until you gave the correct answer, whereupon the program would end. I suppose the most confusing part of this example might be the way line numbers are counted in units of ten - Wikipedia offers an explanation.
The important thing, from a ‘game’ perspective, is the logic gate created by lines 40 and 50. If the answer is correct, the program jumps ahead to line 60; if the answer is anything else, the program continues to line 50, which loops back to the start (clearing the screen, asking the question again, etc). The IF [...] THEN command is a simple tool for evaluating the player’s input – it facilitates branching paths that can be layered up to create intricate logic trees. Put simply, it's what makes this program a ‘game’, albeit a very simple one.
To get back to my story, I had a moment of clarity one day – I think it was during the 1996 Easter bank holiday, maybe a year after we first started dabbling in code – and realised that I could use a random number function to simulate dice rolls. By tracking enough variables (x position, y position, hit points, maximum hit points, magic points, maximum magic points, attack, defence, etc), I could therefore model a simple role-playing game, inspired by boardgames such as Talisman and Hero Quest. This was a far more ambitious project than anything my friends and I had previously attempted, but since it was a long weekend and I had nothing better to do, I dived right in and came back to school on Tuesday with a bugged, but complete, first version of Land of the Lotus.
The game was still pretty terrible – a single, square room, 3×3 tiles large, containing one immobile enemy who could only attack in response to the player’s attacks. But it had a locked door with a working key, three different playable characters, and a pleasurable (if generic) set of rules. I was overjoyed!
I showed the game to my friends and some of us got together and tried to build on this success – personally, I don’t think I got round to completing any other games, although I wrote a few little applications to crunch numbers for Warhammer and the like. For one of my friends QBASIC was the starting point for a career as a game programmer, and others (including myself) still use the same basic skills it taught us when writing scripts. The moral of this story is that I think QBASIC is a simple and fun way to learn basic principles of procedural programming. By combining just half a dozen commands in different combinations, you can create all sorts of weird stuff.
[At some point before the heat death of the universe, MAYBE, I might get round to finally uploading the game and its source code, but don't hold your breath]