October 16, 2020

Happy October! The temperature is dropping, the leaves are changing, and there couldn’t be a better time to sit back and reflect on making a Halloween-themed game for the NES. Spook-o’-tron numbers as the third SGP release, and it was the first game that I programmed myself. The project had its ups and downs, took much longer than it should have, and in the end taught me a lot about independent game creation and publishing. I suppose that probably makes for a better story than a string of easy successes, but only in hindsight! This story is a bit more personal than announcements of game releases or such, but all of those details are what contributed to the game ending up as it did.

By way of a timeline, initial ideas began brewing in 2015, and the last copies owed to Kickstarter backers shipped in early 2019. There is a lot of ground to cover, so the story will be split across three parts. Thus begins the tale of making an NES homebrew game…

*An early version of the following was included as a physical pack-in with the NA edition of Spook-o’-tron *

Spook-o’-tron began life, like most creative acts, as an idea. Before I wrote a single line of code I had been kicking the idea around for a game that might make use of the Virtual Boy controller. I remember mentioning something about it to Joe Parsell (AKA Memblers) on one of my visits to his place in 2015. It was rather late at night, and I suspect that he thought I was a little too sleepy for clear thinking. Then again, he’s the king of wild hardware ideas.

At that point, I had released Swords and Runes, was working on the release of 0-to-X, and was spending my coding time on an Oregon Trail-like game tentatively called Family Vacation. A component of that last project was that instead of the “hunting” portion found in The Oregon Trail, the player would have to play arcade games in order to earn tickets that could be exchanged for food and other items on the journey.

I wanted these mini-games to be takes on classic arcade games. Like the games of old, their purpose was to get the player to spend money, and the faster the better. As I looked around at the possibilities a twin-stick shooter à la Robotron seemed like it might be a good fit. Additionally, this could be an ideal use for the Virtual Boy controller, which gave concrete form to my hope of making use of that peripheral. It was also important to me that the NES had not received a port of Robotron. The desire to be at least somewhat original was a strong component in my thought, even if it was a quasi-port in its initial conception. As if that was not enough reason to begin the project, I also realized that a game of this sort would allow me to become familiar with my weakest area of programming, namely, sprites.

Indeed, one of my reasons for choosing to do Family Vacation in the first place was that it involved minimal use of sprites. At this point I was about three years into learning to program for the NES, having spent this time attempting to build a Zelda-like action adventure. I had some things up and running, but I had gotten stuck on how sprites worked. They were somewhat functional, but I could tell that I was missing a key piece of logic in how they operated. When contemplating a twin-stick shooter it was obvious that something like Robotron would use nearly every sprite available to the NES, and what better way to learn than to attempt such a game! Challenge, innovation, and the need for a mini-game became the three guiding factors to the project long before any code had been written, or even written notes taken.

All of that was slowly coming together over the fall of 2015. For better or worse I had quit my day job right before I released Swords and Runes, and I had 0-to-X waiting in the wings, so the pressure to release a full game that I had programmed myself was minimal. In fact, I had three more nearly finished games made by nemesys, the fellow who did those two games, sitting on my hard drive waiting to be released (CityZen, Swords and Runes II, and Swords and Runes III). I had started on Family Vacation in the summer of 2015 and progress was so swift that I imagined being done by December. It all fit with a master plan, but that lack of pressure allowed me plenty of time to play around with side ideas, such as the Virtual Boy controller.

In January of 2016 I built a test program to see if the VB controller would register reads on the NES. I had stumbled across a forum post where a fellow had modified one for use on the console. He noted that the left and down buttons on the right d-pad functioned as A and B on the NES. In order to be able to use A and B on the VB controller for games, he had bridged the PCB to make the connections NES-like. As I read this I realized that if the NES could detect the buttons, then it had to be reading them in some way. Back then I knew very little about hardware (eh, I still don’t), but I did know that the SNES controller could be used on the NES. I guessed that the principle must be the same, so I casually asked Brian Parker (bunnyboy) of retroUSB about how that worked. Even with him, I was rather careful to guard what I was really after. I certainly was not going to publicly post on a forum asking for help!

With Parker’s help, I built a pair of test programs, one for twelve reads (SNES), and one for fourteen reads (VB). All this program did was graphically change a single tile on the screen based on which button was pressed. That would allow me to empirically figure out the order of writes for the controllers. I wired up the SNES and VB controllers to an NES extension cable via jumper wires and then took note of what happened, revising the program a few times as I got confused about the order of things.

Part of the reason for my secrecy about the VB controller was the desire to be original, but another key factor was that I was a tad embarrassed that this was the way that I was going about it all. I am sure that there was documentation or specs online at the time that would have revealed the results without literally wiring it up to an NES, but that was beyond my skills (it probably still is). Talking with “real” programmers always leaves me feeling a bit inept as they talk over my head about busses, gates, or whatever other words that cause my brain to glaze over. Probably not their intent, but I do not come from any kind of computer background. Thankfully there is now a NESDev wiki page on how to use the VB controller on the NES, for those interested in doing so.

Right about this time progress on Family Vacation ground to a crashing halt. I had a lot of the game finished, but I had encountered a bug when the characters in the game perished. To me this is what really made the project into a “game”; a crucial moment. If the player could lose then that completed the circle of gameplay. I was very excited… but then strange things started happening, and nothing was functioning in the tight and logical way that computer programming is supposed to work. Since that is part of another story I will just say that the solution to that problem did not dawn on me for a couple of years. It was one of those inherent errors of logic due to the self-taught nature of my programming education, and to be honest I am not really sure how I ever got anything at all to work on the NES, then or after.

In February Kevin Hanley came to visit for a couple of weeks. As part of his visit we went to MagFest that year, a first for both of us. We saw a lot of people that we already knew, and also met some new folks like Andrew Reitano (Batsly Adams), who had launched his Kickstarter for Super Russian Roulette the morning that the show started. With MagFest being more or less a twenty four hour party, I was pretty exhausted, but I knew that something was not right with my health, and that only increased as the show wore on. Instead of looking around at exhibits or hanging out playing games, I could more likely be found sitting on the hard concrete floor up against a wall. Hanley and I even left for an entire day of the show to drive up to a comic book shop in Jersey, for which I was quite thankful.

The issue with my health was that I was experiencing reduced feeling from the waist down; I could hardly feel my legs. I have had back troubles most of my adult life, but this was a new problem that had begun the previous October. Another Kevin, Kevin Hershberger (K3vbot), had come over to my grandparents’ house in Indiana, where I had been building the 0-to-X LEs. I had already worked out the prototype, so Kev was there to help me churn out thirty of them based on the plan that I had worked out. This involved painting the boxes with an undercoat of whatever color the tile was supposed to be, and then applying stencil over which coats of black would be applied. My job in this process was to cut the stencils and apply them. This task involved sitting on the floor bent over while cutting things. Part way through the day, when I stood up, I realized that my legs felt kind of funny. They were a bit numb, which was odd, but I did not think much of it. A few months later, at MagFest, it had gotten much worse. I was constantly fatigued and regularly loosing my balance and falling.

I made it through the show, and Hanley stayed a few more days after we got back to Buffalo. Since my wife was working, he volunteered to take me to an MRI that I had scheduled prior to the show to begin investigating what the issue might be. He left a few days later, and I went in for my follow-up appointment the next week. That was a Thursday, and for all I knew I was just going in to chat with the doctor. Within a few minutes of the meeting, however, I was told that I would need immediate surgery. It was not a discussion, and they transferred me to the soonest available surgeon on the spot. I was a tad shocked to say the least, but it all happened so fast that I had little time to worry about any of it. I figured that I would live through it, and if not then there was not much that I could do about it. Looking back on it now terrifies me more than it did at the time, and thank goodness my wife had amazing insurance. I had more MRIs, doctor visits, and pre-surgery tests over the next week, and then I went under the knife.

In terms of programming, everything was put on hold. I was right in the midst of the Family Vacation bug, trying anything and everything that I could think of to fix it. The doctor told me what to expect post-surgery in terms of being able to work, and that was not much. I was basically not going to be able to do anything except sit and sleep for a while, and then getting back on my feet was going to take months. In preparation for that I closed my Family Vacation files and set up my room for gaming as if it was going to be my new job. I did not want to lose all of that time to unproductive nothingness (meaning the internet), so I made a list of things to play in order to begin officially researching how to make the RPG that I had always wanted to make. The Zelda-like, Family Vacation, and whatever else that I had messed around with were all stepping stones to making an RPG, but it was something that I had not felt I was ready for just yet. I still was not, but with so much time to do little else other than game (I am not a big TV watcher), it seemed like an ideal time to begin the quest.

Well, I made it through surgery and then gamed as much as I was able. I put in at least forty hours a week for the next month, which was about all I could do between being drugged and in pain. It was a good month, sitting bolt upright in a lawn chair and slogging through terrible games like WOZZ, ones that I really should have given up on within a few hours. I did play through some great titles, though, and revisited some old favorites, but whether good or bad they all taught me something and my notebooks began to fill out. I had a lot of time to think, both about what I wanted to make and also what I needed to be doing with my time. RPGs are large and daunting by nature, and I knew that my dream project would be years off, even if research had finally begun. On the other hand, Family Vacation had stalled out due to the game crashing bug, and looking ahead I knew that I still needed to make the ten projected mini-games for that project.

I took a trip home to visit family about a month after surgery. I was still in a neck brace, and had not done any programming. I hen peck when I type, as fast as I can think and probably without looking at the keys much, so I had not been able to start on anything during that time, whether I wanted to or not. When I went home, however, I became dreadfully bored. I had started to walk some but that just gave me more time to think! Within a few days, and without telling my wife, or Hanley, or anyone else, I rigged up a setup at which I could program. I used the box that Rob Bryant (Sly Dog Studios) had shipped his 3-in-1 2P Pak LE in, placing a 3-ring binder on top of it to get the angle just right, and then putting my laptop on top of that. This put the keyboard right about eye level, which meant that I had to raise my arms quite high in order to be able to type. Having had a break from Family Vacation, and with the VB controller scheme already worked out, I decided to start on a new project.

This is how Spook-o’-tron was born, and within a few days of sitting at that desk with my make shift setup I had a lot happening on screen. Things were loading and the player was able to shoot and move in eight directions. I worked out the basic design of the arena, and used sprites from Michael Swanson’s (Mario’s Right Nut) The Grind, one of the few games that used smaller, 8×8 pixel entities in an effective manner. He, along with Hanley, had taken the time to help answer my questions when I was first starting out and The Grind, at least in terms of some of its core design, was a big influence on my thought at this time.

I returned to Buffalo and kept at it, still working in secret since it felt good to do so. I wanted to wow and impress my friends and family, and within a few weeks I had the basic framework for a twin-stick shooter in place. I even flashed the game to a GTROM board and printed off a label, which I shipped to Hanley as a true surprise. It took him weeks to fire it up, which was rather disappointing, but it has given me something to hassle him about ever since!

In the meantime I kept working on the game. It grew rather organically, from the player, to projectiles, to enemies, to collisions, to all of the things that touched on these points. Games at this stage do not always take a lot of forethought, since they tend to grow based on the game’s simple needs. If you create the ability for the player to shoot, then the next logical step is that those projectiles would do something when they hit either an enemy or a wall. As the game became more complex I worked through bugs as I found them, which is my usual practice to this day.

Gameplay-wise, this first build of the untitled twin-stick shooter was a lot closer to Robotron than the final game would be. In order to get around the hassle that can be level design, which is an area of game design that I have always been a bit hesitant toward, I decided to build a high level of randomness into the game. The plan at this stage was for levels to be based off of a scattering of spawn points in the arena, and that there would be more points than enemies. The enemy spawning routines would start at a random place in the map, which would mean that the same level would never play the same way twice, whether from a fresh start or when making a second (or third, or fourth, or fifth) attempt at it. The extra coordinates would also allow the spawn map to be re-used for several levels without the player getting wise to my shortcut, and I think that I envisioned about ten such coordinate maps. The real challenge and variety in the game, much like Robotron, would come not from enemy placement, but enemy composition.

The only enemy in the proof of concept build was what would become the pumpkin. This enemy continuously moves toward the player in eight directions. The way that I envisioned programming the levels worked perfect with this type of enemy, and the game was largely built around it. What I found to be fun about this type of game was the sense of being continually put into a nearly un-winnable situation, but managing to escape unscathed. The first few times that the game was attempted the player was bound to lose, but before long he or she would be making short work of the critters.

The ability to beat any level in one life was, from the very first, a central tenet of the game’s design. As programming went on, however, this began to conflict with the high degree of randomness that was initially planned. Due to this I started to look for ways to build more structured levels, while still keeping some degree of uncertainty. The testers that I brought on board to help with the project put the final nail in the coffin of randomness, as few of them enjoyed either playing or building levels that involved it. Interestingly, that initial concept level, which seemed so easy after a few attempts, survived into the final game. Once ordered with the rest of the levels in terms of difficulty, it became the very last level. Not quite as easy as it seemed!

In terms of theme, Parker had his 8-Bit XMAS series, and I wanted to do something similar. Since Christmas was already taken, I decided on a Halloween theme. Please remember, this was all happening during the spring/summer of 2016, before all of the other Halloween-themed homebrew games had appeared. The game was minimal in terms of graphical requirements, but I had some vague ideas of little costumed characters running around. During my convalescence, besides playing games, I could for brief periods lay in bed and hold my phone up to my face. I spent a fair amount of time on Twitter, and came across sprite work by Chris Cacciatore (now Dullahan Software). I sent him some brief messages about his work, and then decided to reach out to him for assets.

Cacciatore was interested in attempting the project, so I drew up a rough list of what might thematically work. The staple Halloween creatures were all in there such as witches, pumpkins, werewolves, vampires, ghosts, skeletons, and zombies, but there were also some more abstract ones like “flame.” Looking back now, I do not know exactly what I had in mind for that last one, but he came up with an adorable little candle character (his personal favorite). For the main character my notes read, “Hero:? Still not sure on this one, I guess a spaceman could work.” I wasn’t exactly scraping the barrel for ideas, but I had not given them much thought either. What I needed were characters that mostly shared the same colors, in order to get around the NES palette restrictions, and that would look stellar as tiny sprites.

I remember where I was when I saw his take on my list of proposed characters. I was out walking, and had to look closely under the shade of a tree; they were not what I had envisioned. Finally seeing the form that a vision takes goes one of two ways, it either aligns with it or it does not. If it doesn’t, then some choices have to be made. Perhaps it is even better than what one wanted, but in this case I was not sure. I had pictured something darker and more serious, and he had drawn some candy-sweet characters in bright colors. At this point in life, after having read other friends’ writing, or when evaluating their early progress on game ideas, I knew better than to say anything. Instead I sat on it and looked at it every few hours or minutes. I sent it to Hanley and he was blown away, so maybe I was missing something.

This was one of those cases where I needed to let Chris’ vision intercept mine. He had done a genuinely nice job, particularly given the constraints. The characters were clearly defined and it was easy to see that they could be animated well. They used a few too many colors as a whole, which would limit the diversity of enemies that could appear on the screen at any given time, but that was inevitable. I never want to make a contributor to a project wait too long for feedback, but within a day or two I was convinced that what he had drawn was superb in every way and that the old vision needed to go. I sent him a message congratulating him on his work and asking for a few more assets based on gameplay, such as projectiles and a death animation, while giving the go ahead to continue with animations.

One area that Chris had taken some liberties with was that he had only drawn the side-views for the characters, while I had specified the need for up and down facings. This was another area of the game where I decided to listen to his advice, which was based on his own observations of Robotron. In terms of programming, the solution on my end was to quickly duplicate the art for those frames. That is one of the reasons why the graphics file in Spook-o’-tron look so cluttered (for those that have peeked). Indeed, if one were to hack the CHR file of the final game, and replace the frames of a character with the four arrow graphics also found in there, he or she would find that all of the characters are animating in four directions, not two. I also feared having asymmetrical animations and the mess that those would become, so sprites were never simply flipped for left and right, but were instead given unique frames. All of that is a huge waste of memory, and it looks as sloppy as can be, but that is because a lot more is going on than what meets the eye.

I was also hesitant to cut any of that extra programming in the end for two reasons. The first was that I had (and maybe still have), plans to expand the engine some day. There is quite a bit drawn up and planned for a sequel of sorts, though that has dropped in order of priority over the years. The second reason was that there was no need to cut things out. The game functioned the same in any event, and beyond impressing the very few people who would ever look at exactly what I had done, there was no practical reason to get overly intense with memory or coding finesse. Functionally, I still needed the four directions for movement and projectiles, so there was not much CPU time to be saved in cutting the animations (which unlike memory was a concern).

That decision more or less underlines the philosophy that I take with all of my projects. I try to build things with future use in mind and I do not get hung up on needless optimization. In the years since, I have written some rather complex routines, but generally with those things in mind. I use variables instead of hard values, just in case I want to change that value later, and I always have my eye on a possible other use for a routine.

After I had the theme of the game decided, and some of the artwork in hand, I needed a name for the game. Up to this point, the project had existed as “Controller Fun 1.1” or “VBControllerGame” in my files, not exactly public-ready names. I am notoriously bad at coming up with names, but with Robotron clones, even if they stray far from the blueprint laid down by Eugene Jarvis, there is a tradition of naming games along the format of ____-atron or ____-otron. Looking over an article in Retro Gamer around this time, which covered the history of Robotron and its various clones, left me feeling pretty safe that I was in the clear as far as copyright went if I named the game “something”-o/a-tron.

This naming scheme also aligned with the Halloween mainstay of the jack-o’-lantern, which is why I added an apostrophe to any would be title. I tried out various names, but I could not come up with anything that really sounded right. I started calling the game “Spook-o’-tron” simply so I could talk about it with other people. I never did come up with a better name, and in the end the testers liked it enough for it to stick around.

With a somewhat functional engine, graphics, most of the design planned out, and a temporary name, Spook-o’-tron was set to move into a new phase of development. Thanks to Cacciatore’s art, new enemy types needed to be programmed, and the task of designing levels could begin. The game was still based around the more random format of level design, but with the first wave of beta testing about to begin that was soon to change. That is another chapter in the story, however, which we will have to get to in a future post.