I’m currently creating a video game, and I’ve been struggling with the idea of how to write about it without spoiling the game itself. With this article, which I’m very non-committingly considering as part 1 of my devlog, I think I’ve found a happy compromise. I’m not sure if this format will work as a devlog or even be interesting at all, but let’s try it anyway.
My dad may have had his flaws (who among us is perfect?), but there are certain things he did for me that turned out to be extraordinarily on-point. One of those things was when he bought me an early version of FutureBASIC, a quirky programming environment and compiler package for classic Macintosh computers, without me asking for it or even knowing it existed. At the time, I had a vague idea that I wanted to make games, as any kid with a video game console probably has had at some point. My dad took the first step towards actually getting me to make games.
My Dad’s Serendipitous Choice
As a kid, I had loosely expressed an interest in the BASIC language. But with our Macintosh LC II, our family’s first really usable computer, there was no obvious way to write programs in BASIC. Unlike the 8-bit computers of the 1980s and earlier, classic Macs lacked a built-in BASIC interpreter. I had somehow gotten a magazine, from school I think, that had some sort of maze game written in BASIC. I wanted to input this game and play it, but of course this was not possible on our Mac. I must have shown this to my dad at some point, but don’t remember exactly. In any case, he noticed my curiosity about programming, as well as my interest in video games and computers in general. He did his own research and found a software package, FutureBASIC, that he thought would encourage my interest in these areas. My dad was by no means a computer expert, but being a college professor and entomologist, he was definitely an expert at researching the unknown. His expertise really paid off in this case, because FutureBASIC ended up introducing me to some solid foundational programming concepts that I don’t know how else I would’ve learned.
FutureBASIC’s Unexpected Potential
In hindsight, FutureBASIC was weird. Its syntax was moderately based on the BASIC language, but program flow and organization was closer to C. It was a lot more powerful than a typical BASIC interpreter. Line numbers were no longer required. You could create and call functions instead of relying on GOTO for flow control, though it did support GOTO and line numbers if you really insisted on using those. In a way, it was like a BASIC-to-C learning bridge. It was compiled, not interpreted, which meant you really could make your own full-fledged self-contained Mac applications. To a kid, this seemed like a box of magic; too good to be true. In fact, it is what brought me to my greatest frustration with the software. It wasn’t enough just to know the language; you also had to know how the Mac OS worked internally. Teaching this skill to a kid was obviously beyond the scope of a single software package. Still, the makers of FutureBASIC really tried, as evidenced by the incredible user guide that came with it.
To create a proper Mac application with Mac-like windows, menus, text input fields, dialog boxes, and general Mac-like behavior, you had to know the appropriate statements and functions to create those elements and interpret user interactions with them. To its credit, FutureBASIC did a fantastic job of providing statements to access these things and describing them in its user guide in full detail. It really was incredibly clever in how it let you access most of the Mac OS functionality through a BASIC-like programming interface. A big chunk of the user guide covers not the language itself, but how to use the language in the context and structure of a typical Mac OS application. In hindsight, this was a wonderful teaching and development tool, especially to come not from Apple itself but with a third-party software package.
But to me as a kid, knowing the OS internals was an unexpected prerequisite with a huge learning curve, and I never quite picked it up. I just wanted to make games, and all this OS stuff was just getting in my way, or so I thought at the time. Learning the language wasn’t too difficult. But when the need arose to access new functionality from the Macintosh Toolbox (Apple’s classic Mac OS API; the functionality built into the Mac ROM on which most if not all Mac applications depended) which had not been included with FutureBASIC out of the box, that was the point at which my 12-year-old mind couldn’t progress any further. Over time, Apple would add new routines to its Toolbox, of which FutureBASIC would have no way of gaining awareness. The FutureBASIC developers foresaw this scenario and did provide a means to extend it to access these new routines, but this was tedious. To do it, some use of assembly language was required. A knowledge of pointers, handles, and memory management was also required. This is where the brilliance of FutureBASIC kind of fell apart, and it had to resort to much less user-friendly tactics to get the job done. I’m sure this wouldn’t have been an issue for mature, knowledgeable programmers, but for a kid learning to program, this is where it failed to be the teaching tool I needed.
I remember figuring out how to do simpler OS things that used FutureBASIC’s built-in statements, like creating a window and a menu, but failing at the more complex nuances of developing GUI apps, like how to successfully execute code whenever a certain menu item was chosen, or how to gracefully respond when the user clicks the mouse or closes a window, or what the heck the “main event loop” was. I also never quite figured out how to access certain QuickDraw and Sound Manager routines, which I thought would be necessary for making games, but which required adding new functions from the Toolbox.
In addition to its user guide, FutureBASIC also came with a thick reference guide, and I read both of these so much that the spines started falling off. These guides described at least some of the Mac Toolbox functions (the ones the FutureBASIC developers were aware of at the time the software was released), but not all of them. Since this was long before the days of online documentation or internet searches or StackOverflow, and even CD-ROM drives were hard to come by, the only way to properly learn the Mac Toolbox was to buy the entire Inside Macintosh book series. Somehow I managed to convince my dad to buy me two Inside Macintosh volumes, but even just those two were very expensive. Owning the whole set just wasn’t an option.
In hindsight, Inside Macintosh wasn’t what I needed; I needed knowledge of how to write a game engine, or at least how to get an existing one and use it. I’m not sure any game engines were ever written in FutureBASIC.
In spite of these limitations, I was actually able to make a few Mac applications. They didn’t do anything important of course…or much of anything at all. The important thing was that it was actually possible to make them, and I was learning.
Functions. Loops. Arrays. Types. FutureBASIC had it all (except for maybe Object-Oriented Programming? I don’t remember it having that, at least not the version that I had.) I had no idea that when I wrote a program to make a series of beeping sounds at different pitches, I was secretly learning these fundamentals of programming. I had no idea that my “BASIC” code was actually working more like a grown-up language like C. I also had no idea of the concept of memory management, and could never figure out why my programs always crashed. This is funny to me now in hindsight; my dad meant to give me a shovel, but he unwittingly gave me a bulldozer.
Bulldozing A Path Towards Game Development
With the way I’ve been describing my childhood, at this point you might think I work as a programmer. The truth is I have never worked as a programmer, nor have I ever wanted to. From the time I began college as a computer science major, I quickly learned that a typical programming career would have been a terribly unhappy choice for me. I just wanted to make games. (I then changed my major and the rest of my college years degraded into a total mess, but that’s a story for another time.)
But, aren’t they basically the same thing? You have to program to make video games, right?
Yes, sort of.
Making games is a multi-disciplinary process. There are all kinds of skills you could apply to it, if you happen to have them. Art, music, programming, storytelling, theater/drama, cartography, marketing, etc. This makes for a different kind of work than pure programming. In fact it’s possible to create games with very little or no programming these days. Much of the heavy coding work has already been done and is included with various game engines. For example: RPG Maker is an engine that makes it convenient to make your own JRPG. It comes with all the functionality a basic JRPG would ever need: A battle system, algorithms for calculating damage and character growth over time, a mapping system, etc. Any programming you do can serve as a bonus to what’s built-in, improving your game beyond what it would be without any.
Without going into detail about my current game-in-progress, I have written a small amount of JavaScript code that adds some huge quality-of-life improvements to it. As a result, the game is now both more enjoyable and less tedious to play. And yet I could have skipped the programming entirely and still created a complete game. It wouldn’t be as sophisticated, but it would be playable. (I also rely heavily on plugins to the engine, which consist of JavaScript code written by others, but the details of that are beyond the scope of this article.)
My FutureBASIC Experience Made JavaScript Easy
When I set out to learn JavaScript so that I could improve my game’s behavior, I thought it would be a big investment in time and effort. Surprisingly, I learned a great deal in a short time. This is because the fundamental concepts were mostly things I already knew, many of which I learned by playing with FutureBASIC in my childhood. To be clear, I wouldn’t say I really know JavaScript. I don’t have it memorized. (In general, I don’t go out of my way to memorize things. I remember things best from repeated use, not from flash card style rote memorization.) What I do know is how to search for the names of functions, etc. in such a way as to make my ideas come together in JavaScript. For example, how to get the current date and time from the system. When I found out how to do that, I added functionality to the RPG Maker engine that puts a timestamp on every save file and displays it on the save/load screen, thereby helping the player remember which save is most recent, and which save is which. Figuring this out only took a few internet searches. That’s a lot easier than the old way of digging through reference manuals trying to find the one thing you’re looking for!
I have my dad and FutureBASIC to thank for introducing me to the world of programming. Even though I don’t want to be a career programmer, I’m thankful I have enough of the skill to be able to apply it to the games I create.