Introduction
Hello everybody, Happy Black History Month. Although it's late in the month, I wanted to write about a game that was developed by a person of color. And by that, I mean a game that I developed myself. Over the past few weeks, I've been working on a simple arcade-style indie game called Mega's Nuclear Waste Dump, a puzzler inspired by Uncle Henry's Nuclear Waste Dump for the 8-bit Atari line of computers.
Since this is a game I made myself, this post will not be a traditional game overview like my other blog posts. It will also obviously be missing things like an additional media section, developer interviews, character descriptions, or anything of that nature. That said, what this post will be is an explanation of the game's mechanics, the tools I used to program it, the assets used, my inspirations, and my personal thoughts. So sit back and get comfy as I take you to the waste dump!
To be a bit less opaque for a moment though, you may remember that in both of my articles on 16bit Sensation and Mario Kart Zero, I mentioned that I was working on an indie game. This game is NOT the same indie game I previously mentioned. To be blunt, the original project’s code started turning into spaghetti code, I was running into a ton of logic errors, everything was disorganized and unoptimized, the library I was using was too limiting for the scope of the project, and I didn't have a clear development timeline or scope defined. Ultimately, I felt it was a better idea to restart that project from scratch using a different program. While I’m sitting back and deciding how I want to handle that larger project, I’ve been working on several smaller game-related projects. And this game, Mega's Nuclear Waste Dump, is essentially a filler project in between the larger projects.
Uncle Henry and His Waste Dump
Anyways, before talking about my game, I want to give some history on the game it was based on: Uncle Henry's Nuclear Waste Dump, which, from here on out, I will abbreviate as UHNWD. UHNWD was an 8-bit Atari game written by James Hague and published by Antic Publishing in December of 1986. It was a type-in listing for Antic Magazine Vol. 5 No. 8, which, if you don’t know, means that the source code was printed in a home computer magazine or book. Readers were meant to manually enter the code via keyboard and then save it to a cassette tape or floppy disk. Most type-in programs were written in either BASIC or machine code. UHNWD was one of the ones written in BASIC.
According to the magazine page, the game follows an "old cuss" named Uncle Henry who's trying to make a quick buck. He recently discovered that thousands of corporations have tons of nuclear waste…for some reason, and they need somewhere to dispose of it. So, after six months, Uncle Henry decided to open a nuclear waste dump behind the local Sloppy Joe Hut. However, with all the waste being sent his way, he needed some employees. That's where you—yeah, you!—come in.
The waste containers are represented as blocks of different shapes and colors falling from the top of the screen. They hover at the top for a few seconds while the player selects which column to drop them into. When time runs out, the container of waste falls.
Despite being written in BASIC, the game itself is actually pretty elaborate. While many puzzle games revolve around matching colors or clearing rows while avoiding a full board, this game flips the formula. Instead, the goal is to avoid matching colors. If two containers of the same color touch, they explode, and you lose, and then you die. The objective is to strategically fill the play area to the top without triggering a meltdown.
But wait, there’s more! When you stack a block on top of another, it doesn’t just stay there. If there’s an open space to the bottom left, the block will roll down into that spot. The same applies to the bottom right. This adds an extra layer of strategy when deciding where to place each block and it’s a really unique take on the formula.
Hague would go on to work on other games and software and is still active in the gaming industry today. He also later wrote a book called Halcyon Days, in which he interviewed classic game programmers and discussed several other Atari 8-bit games. The book is free to read on his website, which I will link here.
In 2015, Hague briefly mentioned Uncle Henry’s Nuclear Waste Dump, stating that he made the game in just five days one summer without ever knowing what Tetris—which had come out two years prior—even was. He also claimed, "That’s probably the only thing interesting about this game." I find that a bit sad to hear because I think the game is pretty impressive for what it is. Even after all these years, I haven’t seen many other games adopt a similar premise in terms of gameplay. With some touch-ups, dusting, and some WD-40, I believe this game could genuinely be a fun addition to a party or friendly gathering.
Since the original game is very difficult to play nowadays—being a type-in listing from an old magazine for a system that very few people still own—I was inspired to create a semi-remake. My goal was to introduce more people to its unique mechanics, allow them to engage with the original game's ideas in a modern platform, and potentially learn about the original Atari game.
Programming
When developing my first game—or any creative project in general—one of the biggest issues I’ve run into is not following a good methodology. In software development, there are two main methodologies: Agile and Waterfall. Agile is more flexible and adaptable to changes in ideas or scope. It’s a good methodology to use when working on something that involves a lot of customer feedback or has uncertain requirements.
Waterfall, on the other hand, is much more linear and structured. Each phase is completed in a strict order, and you only move on to the next phase once the previous one is finished. If you're a perfectionist, prone to feature creep, or easily distracted like me, I highly recommend using a Waterfall approach when building games.
That’s exactly what I did with this project—I strictly followed a simple Programming → Art Assets → Music timeline and only went back to make touch-ups once the full game was about 90% complete. Using an Agile methodology for a project like this runs the risk of jumping all over the place, constantly wanting to add new features, getting distracted, losing focus, rewriting the same code multiple times, and ultimately never finishing your project. It’s like the developer’s version of rewriting the first chapter of your book 50 times and never finishing it.
That being said, for the programming, I wrote the code in a modified version of Notepad++ using C. Specifically, I used the Raylib library, a game-making library created by a guy named Raysun—but we'll call him Ray 😎.
Raylib is a pretty handy and easy-to-use library for making games, though it’s best if you want to write something smaller scaled like an arcade-style game, or something similar to a flash game, or a simple mobile game. You’re not going to be making Skyrim or Assassin’s Creed using Raylib, or anything like that…well idk, maybe you could. I’ve seen impressive things made in Raylib.
Pacman Remake written by Lerkel in Raylib
On the Raylib website, there are several templates for different classic games that anyone can use and modify to create their own, including Breakout, a general space shooter, Asteroids, and Tetris. My game is a modified version of the Tetris template, but beyond just aesthetics, I had to make several changes to the game’s logic—many of which aren’t as obvious as one might expect.
For one, I had to change the Tetrominoes into 1x1-sized blocks. On top of that, I had to assign colors to them randomly as they spawned. That wasn’t too difficult to do, since I had a decent amount of resources and online assistance. One issue I had though was that when the blocks stopped moving, they turned into the default gray blocks again, and having them remain the same color wasn’t as easy as adding an extra line of code to make non-moving blocks colored too. Trying that would just cause the non-moving blocks to change into the color of the currently falling one.
To amend this, I had to store the color data in a matrix called grid[][]. So, when a block fell, the specific place it fell in corresponded to a coordinate in the grid matrix, and its color was stored in that location, reflecting on the game board. So, I got the colors to load, and stay loaded properly, which was mostly simple. I did run into one semi-error, but it doesn’t really come into play until later on, so I’ll hold off.
After I assigned colors to the blocks, I then had to modify the game logic to give the player a game over if two of the same colored blocks touched one another. Since grid was just implemented in the previous paragraph, adding a method that checks the color of the adjacent tile was a relatively simple procedure, and without much error, I got it to work. The next thing I wanted to do was make it so that when a block was stacked on top of another block, it fell to the side in the same way it does in the Atari game.
I initially hoped that it would be as simple as checking the grid and implementing something akin to “if (grid[i-1][j-1] == EMPTY) {grid[i][j] = grid[i-1][j-1]} and if (grid[i+1][j-1] == EMPTY) {grid[i][j] = grid[i+1][j-1]}.” …It was not that simple at all. I’m not sure what I was doing wrong, because at first, the blocks would move over regardless of whether the adjacent tiles were empty or not. To make things worse, instead of rolling down, they’d defy the laws of physics and roll up! I tried tinkering with the values, but they’d keep on just rolling up into the sky. Eventually, the tiles would eventually just start duplicating sometimes as well and breaking outside of the playfield. It was stressful. I don’t even know what I did to fix the problem, because eventually, it just started working as intended.
After that, though, I ran into another problem—I neglected to account for how to handle blocks falling from greater heights. If there were multiple available spaces for a block to roll down to, it would fall one tile below and then stop. Fortunately, this wasn’t too difficult to figure out—I simply turned the previous algorithm into a while loop.
The next issue I encountered was with the "Upcoming Piece" preview. The blocks still appeared as gray, as per the template, and unlike the board tiles, I couldn’t refer to the matrix. Adding a color value to the upcoming pieces just made them appear as the same color as the piece currently on the board. Honestly, I didn’t have the patience to fix this, so I removed the preview altogether and replaced it with a sign reading “!!! DANGER !!!”
With that, most of the core algorithm was coded and designed. However, I decided to make a few changes to the original game. The first difference was that rather than requiring the player to fill the play area, you simply have to make rows, as I wanted it to function more like an endless game. I also wasn’t sure how fun it would be if filling the entire area was the only objective.
The second change was that, instead of having the pieces hover at the top before falling into the chosen column, they now immediately start falling from the top, and the player can move them mid-air—similar to Tetris. Like Tetris, the rate at which they fall also increases as you clear more lines.
At this point, though, I noticed some minor issues. The first was one I alluded to earlier—simply put, it’s way too easy to get screwed by bad RNG. The board is 10 columns wide, so if you got really unlucky at the start and six blue blocks spawned in a row, you’d instantly lose. I wanted to implement an algorithm to ensure that the first three blocks to spawn would always be red, blue, and yellow (in that order), but by the time I realized this, implementing it would have required around 100 or so more lines of code and a complete rework of some earlier methods. So I said, “Fuck it—it’s not intrusive enough to happen too often.”
Another bug I noticed was that, for whatever reason, when you made a match, some blocks had a chance of changing colors. I didn’t catch this until very late in development, but it wasn’t a big enough issue for me to bother fixing. So, I took the classic "it’s not a bug, it’s a feature" approach.
The last problem I had was that the transition to the game over screen was way too abrupt. This issue applied to all the templates—if you died, the game would immediately boot you to the game over screen on the same frame. In a game like this, it’s hard for the player to even notice what caused them to lose. This was a problem I actually went out of my way to fix, but it required me to modify how the Game Over function worked (before I later modified it again to incorporate the title screen and Game Over graphics).
What I needed to do was add two variables: a boolean called gameOverTriggered, which is set to false by default, and an int called gameOverTimer, which is set to 120. Then, I set them up in the following method: when two blocks of the same color touched, the trigger would be set to true. Setting the trigger to true causes the timer to count down every frame. Since the game runs at 60 FPS, the game will stall for 120/60 = 2 seconds before sending the player to the game over screen.
In the original Atari game, the screen displayed an explosion when two of the same tiles touched before booting you out, but for this version, I did not implement that. Art and music assets, in general, were something I was really wary about.
On that note, the last programming-related task I needed to complete was implementing a title screen and a tutorial screen.
To do this, I had to create an array that held four different game states: TITLE_SCREEN, TUTORIAL, PLAYING, and GAME_OVER. Whenever the player performed an action—such as pressing Enter on the title screen or losing in-game—the game would switch to the appropriate state.
Each of these screens is pretty self-explanatory. I moved the main game logic into the PLAYING state and modified the template's game-over condition into the GAME_OVER state. In addition, for now, the title and tutorial screens are just placeholder text.
Art and Design
While I enjoy art and drawing, sprite art is something I struggle with quite a bit. I wanted to keep the art assets rather limited because working with numerous detailed sprites would extend the development time of this project from a few days to a few decades—that’s only a slight exaggeration.
I aimed for a 16-bit style similar to many Super Famicom games. However, creating 1:1 sprites was tricky since the SFC screen resolution is 256 × 224 pixels, whereas my game window was 840 × 620. To make the sprites accurate, I would have needed to upscale them… I did not do this.
Anyway, I started by designing the game screen. I already had an idea in mind for the background—I took the Oil Ocean zone background from Sonic 2 and modified it by adding buildings and other details. Then, I drew the main arena, which was essentially just a big "U" with barricade tape. After this, the screen still looked a bit empty, so I added two small platforms—one holding empty containers (which I also planned to use for the falling blocks) and another with a mascot character cheering you on, similar to the adorable Patrako from Cleopatra’s Fortune. With that, the basic design was completed.
After this, I implemented the background into the game, and it looked great. Next on the docket though was replacing the blocks with the sprites I made. I made three sprites: the yellow container, which comes from the oil barrel from Donkey Kong, the red container, which is a barrel from Donkey Kong, and the blue container, a block from Super Mario World. Please don’t think about the logistics behind putting nuclear waste in something that looks like a red wooden barrel.
Replacing the block graphics was much harder than I expected though, since I wasn’t aware that I had to essentially rework how the blocks spawned. After finding out the method though, I still ran into several errors like blocks spawning as invisible or the game outright crashing. I messed around with the code for a while but just couldn’t figure it out. After considering throwing in the towel for the night, and getting ready to go to bed, I realized that my dumbass didn’t save the barrel graphics in the right folder. When I moved the graphics over, they spawned in perfectly fine…
I also designed a game over screen to replace the placeholder. For this, I just looked for a stock image of a ruined city and put Uncle Henry’s iconic quote “Good help is so hard to find” followed by your score and the high score. It’s not the most aesthetically pleasing game over screen, but it’s a game over screen.
I also included a title screen, which you saw at the start of this blog post. I made the white grid lines a bit fainter, changed the in-game text to standard case instead of all uppercase, and adjusted how the game records your score using the following formulae.
You lose 200 points upon a Game Over.
For every line you make, you get 56 points plus the number of lines you currently have times 98, I wanted the scoring system to be more momentum-based.
For every tile you drop, you get one point, plus the absolute value of 19 - 2 times the number of lines you have, plus one and all divided by four. I was a bit drunk when I wrote this portion. Aside from that, you also get one point for every container that rolls down from a higher location.
With all those changes, the last few things I needed to do were draw the tutorial screen and my OC for the playing and tutorial states. For my OC, I already had Mega-chan—Mega, Meg, Meggie, or Whatsherface—a design that was originally created by someone I used to know a few years ago. The basic design was inspired by many of the middle Pegasus sisters from the Fire Emblem series, like Farina, Thea, Tana, and especially Catria, who was my favorite Fire Emblem character at the time. Her shoulder pads were Koopa shells with a turtle icon on the booby-plate, referencing my username, and she wore a little scarf and bandana, which was part of a server inside joke.
Design drawn by CardCaph
I did make some changes to the general idea over time though, like typically drawing her with darker skin to make her closer to my actual appearance and giving her pointy elf ears, because I really like elf girls. Aside from that, since this game is a more urban setting and not a medieval fantasy, her armor was removed in favor of a standard brown long-sleeve and a mini-skirt. For the basic mockup for the sprite, I used a sprite of Patrako from Cleopatra’s Fortune S-Tribute as a heavy reference.
I think the sprite came out pretty well aside from the huge Yaoi hands.
Like Patrako, I wanted to make several cheering sprites of Mega-chan rooting for the player and reacting to stuff like having two containers of the same color touch one another. As you’d expect though, that was outside of the scope of this project. Additionally, I wanted to draw a different sprite of Mega-chan for the tutorial screen, but time constraints resulted in me simply resizing the original sprite I made previously, mirroring it, and closing her mouth.
I’m not lazy, I swear. I just wanted this game to see the light of day sooner rather than never ðŸ˜
I also wrote a little fanfic about Uncle Henry retiring, Mega-chan taking up his ownership, and the player, who is the new employee, taking up the original guy’s responsibilities. I also added a screenshot of early gameplay. I turned the gameplay image to the left slightly to make it look cooler, I don’t know if I succeeded.
Music
The very last thing I added was the music, and for simplicity’s sake, I only implemented one song. Additionally, there are no sound effects or anything like that. However, I knew exactly what song I wanted to add from the get-go. Well, I guess technically, at first, I wanted to play The Wastelands theme from Mario Strikers Charged, because y’know, it’s nuclear waste. But later I figured that Crystal Canyon from the same game fit the vibe of the game much better.
I didn’t just want to use the song as is though, I wanted a 16-bit rendition of the song to play during gameplay to fit with the general graphics. This was when I went out and started looking for a midi of the song. The usual sites didn’t have what I was looking for, but I did eventually find something on YouTube. A user by the name of PaperMikes uploaded a piano tutorial of this song back in 2019 and provided a downloadable midi of their version of the song in the video description, so I downloaded that and got to work.
Well okay, technically, I couldn’t get to work right away. I needed a soundfont. At first, I downloaded a soundfont simply called Super_Nintendo_Unofficial_update.sf2 and tried to assign the proper instruments to the various channels. I made the first draft, but I wasn’t really sure how I felt about it.
I’m someone who has no musical aptitude to speak of. It doesn’t take much for me to really enjoy a song, and it’s hard for me to describe what exactly I like about one. If you’ve noticed in my other blog posts, when talking about music, my main criteria usually don’t go beyond “it’s catchy” or “it plays at a memorable part of the game.” As such, I don’t really know what makes a song good or bad on a technical level, so working with music was a lot of trial and error. The first version of the song felt too high-pitched and a bit ear-piercing at around the 1:20 portion, and I wasn’t sure which instruments would better suit each channel.
I then decided to use EarthBound’s soundfont, which came out a lot better and was lighter on the ears. With the main programming, art, and music completed, I went back to do some final touches, and finally, I had a game on my hands!
Conclusion
I know that for many people, documentation like this isn’t exactly their preferred choice of reading material—after all, this is essentially just an extended readme file. But I was pretty proud of this little project and how it turned out, despite some corner-cutting and lack of polish. I just wanted to briefly share my experience with others and also bring awareness to the original Atari game, since it’s one of the more interesting titles I’ve come across, especially considering that the puzzle genre wasn’t as well-established at the time.
I hope to continue improving my skills and creating more games and software like this. I had a lot of fun, and one of the most rewarding parts of working on these games, blog posts, or drawings is being able to look at a finished piece—physical or digital—and say, “I have crafted this into existence,” while also sharing a part of myself with others. That said, as much as I'd love to link to my project within this post, there's still quite a lot of stuff I want to do before uploading it, mostly encryption and format-related things.
Enough babbling, though. As always, I don’t have much else to say in terms of concluding thoughts, so have a good day, stay safe, and I hope you’ll be back again to read my next blog post!
References
ThisIsPete. (2019, July 9). Uncle Henry’s Nuclear Waste Dump for Atari 8-bit shows why good help is hard to find | Atari A to Z. YouTube. https://www.youtube.com/watch?v=cX283Xi5A_c
James Hague - MobyGames. (2022). MobyGames. https://www.mobygames.com/person/45045/james-hague/
Game of the Month: Uncle Henry’s Nuclear Waste Dump. (2025). Atarimagazines.com. https://www.atarimagazines.com/v5n8/NuclearWasteDump.html
No comments:
Post a Comment