One of the things that I’ve been blessed with is the opportunity to start programming from a young age. What follows is the start of that story, what abstractions and tools I picked up then, and what crazy things I was trying to do with them (more than I knew what I was getting into, usually). This post covers the 12-14 year old me learning ropes of programming (as remembered 8 years hence).
I started in programming for the same reason as many others: I had video game ideas that I wanted to make on the computer. My father, a Bible translator, set me up with QBASIC. My textbook was a pile of Boy Scout magazines that I found in the kid’s room at the Pioneer Bible Translators offices.
I started by copying a relatively short program out that described a dog sled race. It was around 20 lines of code, but it had more going on than I could easily understand. IF statements seemed natural enough, but the FOR loop syntax was tricky to copy correctly. I was able to get it working however, and found that I understood enough to try my own ideas.
From this sprung my two great tools for working in QBasic: IF and GOTO. From those I formed my loops, as the QBasic FOR loop syntax escaped my 12 year old mind. IF and GOTO I understood, FOR I 1 TO 10 ... Next and While ... Wend, not so much. I typed in line numbers so that I could mimic the Boy Scout magazine coding style, and learned how 20 INPUT NAME$ was different than 20 INPUT NAME (one is a string, the other is a number).
One of my first programs was a Samwise Gamgee vs a Goblin RPG game round. “Choose 1) for Stab or 2) Sam’s Fury” was the prompt. Damage was calculated by multiplying your integer choice by 10, (10 damage for a dagger, 20 for a sword). Upon dealing 40 damage to the goblin, you won the game, provided that you survived his dicey assault.
Eager to share my accomplishment, I recruited my brother to test the game. It didn’t take him long to chose attack option 20 instead of 1 or 2. That attack hit for 200 damage, killing my 40 hit point orc in one blow. Thus I learned the importance of validating user inputs. It took me 45 minutes to patch that, if I recall correctly).
My most finished program in QBasic was a simple 15 line calculator application that didn’t have a good user experience. It didn’t really explain itself, but could apply the 4 basic operations too a pair of numbers. That was the one that I could show to guests as an example of my computing prowess. The fact that said program ran in a CMD prompt was +5 to its coolness.
I then proceeded straight into biting more than I could chew. My game concept was "Final Frontier", a text-based based trading and combat game set in outer space. It was going to have 3 different spaceships, 4 trading ports, secret pirate bases, asteroid fields where combat took place and colored text!
As I was learning QBasic, I discovered this magical thing called a SUBROUTINE that could be used to split work across several windows (it looked like several files). SUBROUTINEs kept me from progressing on Final Frontier, mainly by being hard to understand.
My first mistake with SUBROUTINEs was assuming that reaching the end of one would terminate the program. That lead to this exchange:
Me: “Dad, why does the program keep going after the end of the code?”
Dad: “The subroutine goes back to where you started it from when it’s finished.”
Me: “Oh, so that’s what’s going on…”
My reasoning, though flawed, makes sense in retrospect:
One must understand that I had no concept of the stack, or any solid understanding of function calls.
But, this newly corrected knowledge in hand, I attempted to use SUBROUTINEs to break up Final Frontier into pieces. The first one worked well for my main menu and intro sequence (I used terminal colors to make things look cool. Red text was rocking awesome for me in 2007!). But using SUBROUTINEs broke down as soon as I shifted to the code for the market place (my second SUBROUTINE). The intro sequence stored the ship choice of the player into a variable, but the marketing subroutine couldn’t see that variable.
For that matter, every time I came back into the marketing SUBROUTINE, I couldn’t see the variables from the other subroutines. That mean that I couldn’t tell where I had come from, or what ship I was using! How was I too solve this? The problem proved to be too much for my attention span and resources at the time, especially since I didn’t know how to Google very well. I did spend several hours trying to get it to work, trawling the help documents for information. This didn’t help much, as the documentation was opaque to non-programmers.
Such was my development in QBasic, foiled by lack of a way to share global variables between SUBROUTINE files. Why I didn’t just forget about SUBROUTINEs and move all the code into one file escapes me at the moment, but I suspect it had something to do with a stubborness or a lack of creative problem solving on that point. Or just not spending quite enough time with it. I was only 13 at time, with school and family taking precendce, so my attention to the problem was limited.
I did attempt another text-based game, this one a fantasy game with a main character called “Leonar” (becuase cool name), and did some other fiddling around with QBasic, but nothing else major resulted from that. My next set of adventures was with Evelop Basic, which is now more dead than QBasic.
Published April 28th, 2014