Brackey's 2025.1 Game Jam

One of the coolest things to do when learning game development is to challenge yourself by participating in a game jam. Game jams are essentially online competitions where participants have a limited amount of time—ranging from several months to as short as 24 hours—to conceive and develop a working game. Most jams have "themes" that are announced when the competition begins. The themes vary with each jam, but one consistent rule is that participants must incorporate the theme into their game in some way, whether visually, mechanically, or narratively.

This past week, I had time off from work and discovered that the Brackeys 2025.1 Game Jam was happening, so I challenged myself by signing up. The jam started on Sunday and ran for seven days, with the winning theme, chosen by popular vote, being "NOTHING CAN GO WRONG."

I started brainstorming ideas for the game as soon as the theme was announced, eventually settling on a concept inspired by the Many-Worlds Interpretation in quantum mechanics. This theory posits that multiple timelines or universes are constantly being created and potentially destroyed. I'm kind of a nerd when it comes to physics, so this seemed like a cool basis for a game.

I began developing a simple game where the player controls an object on the screen that leaves a trail (representing the "timeline") while dodging enemy objects that randomly spawn from the top of the screen. To enhance the "moving through space" feel, I created a starfield background using Unity's particle system. One of the trickier mechanics involved spawning duplicate versions of the player whenever a collision occurred—these "alternative timelines" formed the core of the game's challenge. If too many spawned, the game would end. Since enemy spawns increased in intensity the longer the player survived, I realized I needed to balance the difficulty by adding a "good" object that could remove a randomly instantiated timeline. This added a risk/reward element, as players had to maneuver across the screen to collide with these objects and prevent the timeline from spiraling out of control. Fortunately, implementing this was easier than expected, thanks to Unity's prefab system and some trial and error with scripting. Everything was going great—until Day 3.

Disaster Strikes on Day 3

On Day 3, I decided the game needed a start screen. In Unity, this is done by creating a separate scene, which acts as a container for all the assets and code used in that part of the game. While working on this, I noticed that my main game scene still had the default name "SampleScene." Thinking nothing of it, I renamed it to "GameLoop" to make it more descriptive. I then returned to my newly created "StartScene" and began designing a start menu with some simple animations.

Once I was satisfied with the start menu, I saved my progress and went back to the GameLoop scene—only to realize something was very wrong. The game view screen was now completely gray, and all the game objects I had created and set up in the Unity Hierarchy window were gone.

Panic mode.

I quickly quit Unity and reloaded the project, hoping that would restore everything. It didn’t. The scene was still empty. A frantic Google search revealed the awful truth: I had inadvertently deleted my entire game scene by renaming it.

At that moment, I decided it was best to step away from the computer, grab a cup of coffee, and reconsider my options. I briefly thought about quitting the jam entirely and chalking this up as a painful lesson in Unity file management. But after a short break, I examined the empty scene again. My assets, prefabs, and, most importantly, my scripts were still intact in the Project Window.

All hope was not lost!

Rebuilding the game from scratch was still a daunting task, but I decided to give myself one hour to attempt it before making any final decisions. To my surprise, after that hour, I had restored most of the game’s core mechanics. So I kept going.

At the 3.5-hour mark, I had fully reconstructed the scene and even made a few improvements to the game's structure. Lesson learned: 

Rename your scenes BEFORE working on them!

Day 4 – Polishing the Game

Day 4 was all about refining the visuals. I replaced the placeholder geometric shapes I had been using for enemy and helper objects with actual pixel art. I also created a portrait of the player's character for the HUD, inspired by the classic DOOM face from the 1990s game. Eventually, I might even animate it to react when the player collides with an enemy, but for now, I’m quite happy with how it looks. I also fine-tuned the start menu’s timing and tested the game on multiple machines to ensure it functioned smoothly.

Day 5 – Preparing for Submission

Day 5 was spent setting up the itch.io page and adjusting the build settings to ensure the game displayed properly in WebGL. I’ve overlooked this step in past jams, and it can really impact how players experience the game. If a game doesn’t display correctly in the browser window, it can lead to a poor user experience and lower ratings. A little bit of research and testing goes a long way in making sure your hard work is properly showcased.

After a few final playtests on itch.io, I officially published the game and submitted it to the jam.

As of today, the jam ends tomorrow at 6 AM EST. After that, all participants can play and rate each other’s games based on various criteria. I’m excited to see what others have created and to receive feedback on Timeline. Every game jam is a learning experience, and this one definitely pushed me creatively.

If you're interested in playing my game, you can check out Timeline here.

Are You Keeping Up With the Commodore?

The Commodore 64 was an amazing computer, for a number of reasons. It's arguably not only the best-selling home computer of all time, but the one machine that really was able to change the opinion of the masses in terms of how computers could be used. It was the perfect fusion of game machine and home computer, something that other companies during the 1980s had a hard time keeping up with.

 

The downside of all old technology is that things break. I had noticed that the sound quality produced by my Commodore 64 was distorted during some programs. A good example would be the introduction to Activision's "Ghostbusters", when it plays the theme song. Some parts were fine, but others were either extremely distorted or in extreme cases not even present. This is a classic symptom of a failing SID chip in the old Commodores. The SID chip, otherwise known as the "Sound Interface Device", is the IC responsible for producing the lush, 80's sound that the C64's were renown for. The SID was extremely advanced in terms of its ability to produce a wide range of sounds, combining both analog and digital circuitry. The downside, it that overtime, these SID chips have a tendency to fail, causing the same distorted or dropped audio that I have been experiencing on my machine. In serious cases, the chip fails completely producing no sound whatsoever. Also, unfortunately, these chips have not been produced in decades, so fully functional old-stock SID chips can fetch a handsome prince on eBay. So what is one to do if they desire to keep their beige time machine singing sweet tunes? There are some after market options which can emulate the sound of a classic SID, but they are not perfect in their emulation and they can be a bit pricey as well. While pondering this conundrum it occurred to me that I actually had another Commodore 64 that I had acquired in a lot of used and mostly broken electronics. I decided to roll the dice and do a SID swap to see if the chip from the donor machine would work.

 

The actual process of swapping chips is extremely easy. Just open up the case, locate the chip (the year range of my 2 C64s the SID chip used was a 6581, which is printed on the top of the chip.), pull the chips using a chip puller - which is essentially a large set of tweezers - plug the donor chip into the socket. You want to make sure the chip is align *exactly* as it was when you pulled it from the donor machine. Mine had a dot on the chip which made it easier to see which end should be pointed "up" in the socket. After completely the swap I turned on the 64 and loaded up "Ghostbusters" and to my infinite pleasure I was treated to the entire tune during the opening screen. I then loaded up a new Commodore 64 game called "Galencia" - yes, people are still making software for these old workhorses - and was treated to lush sound dripping with that certain je na sais pas that only a fully functional SID chip can produce. After running "SID Bench", a piece of software that tests all of the registers in the chip for functionality and sound quality, I was off to the races! Luckily, the donor machine had a functioning chip. Fixing stuff is fun!

Reviving a dead Atari 2600 (Part One)

 

Anybody who knows me fairly well can probably attest to my love of video games, particularly retro games. In many ways, I grew up alongside the home video game industry. My first console was the venerable (and much-maligned) Atari VCS—later renamed the Atari 2600. A good friend’s family bought one, and as soon as I sat down to play, I was hooked. I pleaded with my parents to get one, and we eventually struck a compromise: if I saved up $100, they would cover the remainder of the cost. It took me well over six months to gather the funds, but I did it, and I’ve been a console owner of some kind ever since.

The 2600 is a special machine, in my opinion. Yes, its graphics are crude by almost any standard, and most of its games are quick simulations or basic shoot-’em-ups. But over time, those early programmers truly mastered how to squeeze lemonade out of those lemons. Games like Demon Attack (Imagic), Pitfall! (Activision), and Yar’s Revenge (Atari) pushed the limits of what even the original engineers thought possible. I’ve always believed that’s the beauty of the system—like most things in life, it’s the limitations that force us to think creatively and come up with novel solutions.

With that in mind, I was stoked to find a very early "Heavy Sixer" listed on eBay for $20 (shipping included). The catch, of course, was that the seller listed it with the caveat: "Dead. Parts Only. As Is." Okay, sounds like a challenge to me…

I was pleasantly surprised when the console arrived. Even though the seller was shipping a broken machine, they had taken the time to package it well, preventing any unnecessary damage in transit. The system didn’t come with a power supply, so I borrowed one from my trusty four-switch "Woody" and hooked it up. After connecting it to a CRT tuned to channel 3 and loading up a copy of E.T., I powered it on—only to find that it did absolutely nothing. No black screen, no glitchy garbage, just the everlasting static of channel 3 on an analog television. The seller was honest! So, I proceeded to open up this relic of my childhood and take a look inside.

The console had about 40 years' worth of "patina," both inside and out—a lot of settled dust, caked in place. I started by blowing it out as thoroughly as I could with some canned air. While I had it apart, I gave the case a good soak in hot water with dishwashing detergent to clean it up. One thing I noticed was the manufacturing date on the RF shielding—May of 1982. That meant this was actually a "Light Sixer," not a Heavy Sixer. The Heavy Sixer/Light Sixer distinction refers to the number and type of switches on the console. The earliest models had six switches, while later versions had four. Heavy Sixers, the earliest models, are highly collectible and command premium prices when in working order. No worries, though—I was still excited to have a cool project to work on.

Looking over the motherboard, everything initially seemed pretty good. There were no noticeable burn marks or swollen/leaky capacitors. However, I did notice that one of the contacts for the power input seemed to be missing some solder. It looked like a chunk had broken off. Two out of the three pads associated with that component had massive mounds of solder, but the first had almost nothing in comparison. I could even see the tab of the component peeking through the board. Could this be it? Could it really be that easy? Maybe.

I grabbed my soldering iron and carefully added solder to the open connection, making sure not to bridge any surrounding gaps. One surefire way to fry these old boards is to accidentally bridge the first and second power connections. The second and third can be bridged, but connecting the first and second? That makes smoke appear—not ideal.

 

Once I finished, I hooked it back up to the CRT and tested it with Space Invaders… and voilà! Well, sort of. The system powered on, loaded the game, and started the familiar color-flipping demo that Space Invaders does. But the sound was full of white noise, and the colors on the screen looked washed out. The game played fine, though, which was a huge success—it proved the machine wasn’t totally dead. It just wasn’t feeling great.

After a quick consultation with an electronics-savvy friend, they suggested I replace the electrolytic capacitors on the board. Over time, capacitors dry out and notoriously cause issues like the ones I was seeing. Fortunately, a diehard community of enthusiasts is dedicated to keeping these machines alive, offering repair and maintenance kits for the Atari 2600. A quick Google search led me to a company selling a "refresh and caps" kit for less than the cost of a couple of decent pizza slices.

I’ll post an update as soon as my kit arrives and I get a chance to swap out the old components!