So I’ve been learning bAtari BASIC using Atari Dev Studio and working on a space-adventure game for the Atari 2600 called Telemachus (you can watch its development videos on my YouTube channel). When I read about Atari’s I, Rebel Game Jam, I wanted to see what kind of game I could come up with during the available timeframe. The game jam ran April 11 - 18, 2025. The night before, Atari emailed participants the theme of the game jam. “A Perfect Beast.” 

Mutatis became the first video game I made since high school. That didn’t even occur to me until I was nearly finished. I suppose because I've been working on Telemachus for awhile.

Although I didn’t have time to write a devlog during the week of the game jam, I decided to write a brief process in retro, a few reflective thoughts-- which won’t include everything because I don't remember everything (yes, even though it was just last week).

******************************

Day One // No Game File

I couldn’t work on the game on the first day of the game jam, but I did go for a walk and during my time with the trees started thinking about gameplay. I decided a single-screen game would be good for the limited timeframe. Then I started brainstorming about how I could use each of the five Atari 2600 sprites. They are: player 0, player1, missile0, missile1, and the ball. 

Right away I thought about throwing the ball and influencing its vertical direction-- but once thrown its horizontal direction would be irreversible until you caught it again.

Then I decided by adjusting the height of the missile, they could be destructible shields on either side of the player0 sprite,  defending against the player1 sprite. A change in sprite definition would give the impression of multiple opponent types. I also thought about using the playfield as a health indicator, by removing a single pixel when the player sprite received damaged.

By the end of the walk I had my basic game design. 

Thank you, trees.

Day One Line Count: 0
Day One Game Size: Infinite

******************************

Day Two // Cytos_001.bas

I sketched out the ideas from the previous day and started programming.

I called the game Cytos because initially I thought the player would be a plant. First I set up my dim variables, including shakescreen (which I later decided to remove), gameLevel to keep track of the levels, shieldObject and mutantEnemy as bit operators to keep track of a multitude of attributes for both the shields and enemy sprites, and some fixed-point math variables for movement and speed of the enemy sprites. Although I intended to used fixed-point math for all moving objects, I ran out of time to change my simple integer math routines during the game jam.

Both player sprites started as a box, and the missiles with a height of 16 (which was a magic guess, because I never changed it). I flipped the side the “attacking” box entered from after each impact. I drew four rows of bars using the playfield, two on top and two on bottom, thinking there would be two attributes to track, one regarding health and the other mutation. Through I removed the idea for the game jam version of the game, I think I will add this back in for the full version of Mutatis.

I developed the system to swap the ball between the shields using the fire button. The ball launched in the opposite direction of the shield which possessed it. The right shield launched the ball left, the left shield launched it right. 

Early object collision checks resulted in simple results to be expanded later, including shield and player damage. At this point I thought maybe the background would change color on every impact. However, I found the flashes distracting. The game ended when both shields were destroyed after being touched by the enemy sprite.

Day Two Line Count: 290
Day Two Game Size: 1878 bytes of ROM space left

NOTE: The standard bAtari BASIC game starts at 4 kilobytes. Atari Dev Studio displays the remaining bytes after each compile. The user has 3k available for their program in a 4k ROM. 1k is used by the display kernel… and other things, I guess. On Day Two I thought maybe the game could fit within 4k.

******************************

Day Three // Cytos_002.bas

I removed the health indicator pixels from the playfield graphic. I thought, instead of having the ball stationary and parked on a shield at a set location, I could animate the ball along the height of each shield, for a more active-looking experience. I would just need to pass along a variable tracking the top and bottom of the currently controlled shield. These values would not be static though, since the player could move the shields up and down on the screen, changing the min and max coordinates. I also needed to keep track of which direction the ball was moving in, so I could tell it when to go the opposite way, having reached the top or bottom of its dynamically changing Y-axis, also keeping in mind the shield height itself would change when damaged. 

This day I made the first enemy sprite, no longer a box but a flying creature of some kind. When it touches a shield it automatically steals a piece of the shield, later called a node. Then the sprite definition switches, showing a version of the creature which includes the shield node drawn between its claws. I make my sprites in Pixquare, which I enjoy using (first image below), then convert them to binary in bAtari BASIC (second image below).

I started making timer variables, not just for animation cycles, but with the idea of time-based enemies entering and exiting the screen. Changing background color values over time, I added a fade-in for the start of the game as the shields animate into position. I started this day to tinker with enemy flight variation, using the time counter to decide when the retreating sprite flies up or down (and I’ll play more with this when I hone the nuance of enemy behavior). I like the uncertainty it introduces. The semi-erratic nature works well with flying insect sprites. 

At this time I called them ‘bonus’ in the code, because (for a hot minute) hitting a creature with the ball turned it into a pick-up that would drift away, which you could then collect. But a bug that sent an insect sprite flying away backward made me realize the storytelling possibility of instead using the sprite as the same creature in retreat. Collisions started racking up, as I started listing them for every possible impact between the five sprites plus the playfield. For aesthetic reasons, I adjusted a shield’s Y position when damaged, to keep it aligned along its center, instead of simply reducing its height, which made it appear to be getting shorter, rather than losing a piece of its overall structure.

Day Three Line Count: 575
Day Three Game Size: 499 bytes of ROM space left

******************************

Day Four // Cytos_003.bas

I changed the Mutatis sprite from a block to some tentacled thing with a hole in the center, meant to be an eye. I had this idea, not fully implemented at the moment, to define the top and bottom of the player0 sprite as part of this containment chamber, to blend it with the playfield, so later I could animate something shooting down (and up) out of this, or maybe something connecting to Mutatis, or just wriggling, give some life to the machinery of the environment, in any case. But I ran out of time. I will explore this later.

I changed the Game Over screen from an empty field to the Mutatis sprite wriggling around over a light gray background. At this point I decided I no longer wanted the game to be grayscale. I’ll save that for a different design. I began experimenting with changing the playfield color as an accent. Note, the playfield and the ball sprite share a color variable. 

I also changed the enemy mutant sprite design. Thought it was too large. Now it's a slightly more bug-like alien.

I started bankswitching the game, which I only recently learned to do, changing the 4k game to a 16k game. I didn’t realize this automatically creates four banks in bAtari BASIC whether you define them or not. Currently, I’m only coding three of the four banks, and yet I see the fourth bank is nearly full, as you will note in the daily game size.

I created a new fixed-point math pair to augment enemy positions. This way I could move the enemy sprite at different speeds depending if it was carrying a shield node or not-- though as I type this, maybe I am overthinking the value changes and only need a single pair. The idea is: change of speed is based on time— the enemy starts slow then speeds up.

I messed around with what leveling up might mean for changing various attributes, including mutating Mutatis and changing its sprite.

I worked on the player damage system, which removes a pixel from the playfield each time the player1 sprite touches the player0 sprite. Refining the reset enemy subroutine lead me to think I could pause the reappearance of an enemy, when it is destroyed or escapes off-screen, and decrease the duration of this pause based on the current level.

Day Four Line Count: 2764
Day Four Game Size:
114 bytes of ROM space left in bank 1
3580 bytes of ROM space left in bank 2
3722 bytes of ROM space left in bank 3
180 bytes of ROM space left in bank 4

******************************

Day Five // Mutatis_004.bas

I renamed the game Mutatis. 

I rethought my timers so I could better control when a level up occurs. I just did trial and error on the timers and used the stopwatch on my phone to check the real-world duration. It’s currently set at 30 seconds per level (or thereabouts— it depends on player interactivity, since I don’t want a level to suddenly change with an unresolved enemy action still on screen— I achieved this by moving the Level Up subroutine from the start of the loop to the Enemy Pause subroutine, so a Level Up can only occur when the player1 sprite is not visible).

The new X position of an enemy spawn just flips from the left side boundary to the right side boundary, but I tried using an array to randomly select a new Y position for the enemy sprite. However, for the life of me I couldn’t get this to work, so I resorted to hard-selecting the values based on my loop timer. Not too elegant.

I gave Mutatis two additional tentacles. Making it an arthropod, I guess? I moved the color cycles for the playfield and ball up to the top of the loop, and experimented with four colors, decided on three. I created a damage color cycle for Mutatis. On this day I implemented giving the player the choice to launch the ball either to the left or to the right, regardless of which shield they currently control. In this version of the game, the background and playfield colors started changing in color pairs based on the current level.

Watching the shield nodes immediately fly back to their respective shield, I realized a dramatic pause would be good. I think this is a nice little detail. Might also try wriggling the sprite in place, too, like it’s excited to fly back, then boom. This shield node is, as you may have guessed, the player1 sprite redefined-- since the Grabber creature was just destroyed and not used until it respawns. Later I will experiment with a brief explosion sprite. If I can use one explosion for all enemy types that would be ideal, to save on k.

A big day as I started to implement sound. I have almost zero experience with generating sound on the Atari 2600. Well, I've gained more this past week! This video by Into the Vertical Blank was a great primer. It takes a look at Ed Federmeyer’s Sound-X (the first Atari 2600 homebrew cartridge?) from 1994. A big help just to see the onscreen register values and simultaneously hear the resulting sound.

So here’s the simple sound technique I'm currently using: on the impact of two objects, I define the audio registers— designate audio channel zero to a tone, a frequency, and a volume. I flip a switch, a bit operator, from false to true, indicating that particular collision is active. Then, after drawscreen, and right before the loop starts again, I check if that particular impact is indeed running, and if it is, I shut it off by changing channel zero’s volume to zero. Then I flip the switch back. I’m using a different switch for each object because I thought it would be nice to have slight pitch differences for the various object pairs (i.e. two shields, two playfield walls). But now I wonder, what if I just turn the sound off in channel zero after every drawscreen, regardless? I could use channel one for more persistent sounds, like the buzz of the aliens? If all sounds from channel zero are meant to be on/off clicks, single game loop beeps and the like, that might work. Thinking out loud.

Day Five Line Count: 2964
Day Five Game Size:
382 bytes of ROM space left in bank 1
826 bytes of ROM space left in bank 2
3259 bytes of ROM space left in bank 3
436 bytes of ROM space left in bank 4

******************************

Day Six // Mutatis_005.bas

This was the day I created the alternate enemy type provisionally called the bomber. In the manual it’s called the Genetic Neutralizer. The idea being, later I will develop a collectable mechanic, where you can collect genetic material to advance the mutation of Mutatis, and this bomber character can nullify those enhancements by dropping into Mutatis. To create a flight pattern for the bomber-- I just hardcoded locations on screen to indicate where the sprite changes directions and then swap sprite definitions to accommodate those new directions. At the moment, the sprite takes hard 90 degree turns. I’d like to smooth out these turns. Currently the Genetic Neutralizer spawns halfway through each level, though I've noticed its appearance can get skipped under conditions I haven't figure out why yet.

This day I also moved a chunk of code from bank 1 to bank 2-- the enemy sprite code, because I was running out space. As a temporary measure, when the program won’t compile because I’ve exceeded bank size, I comment out collisions until I can figure out what to move, as they seem pretty hefty and provide a temporary solution. This includes the collision between the ball and Mutatis. For awhile I used this as a Game Over condition, but that quickly became annoying. Plus, I decided later it's supposed to be the mutant's eye. So instead, I think this collision will develop into the aforementioned genetic material mechanic. The player will collect an object with the Eye of Mutatis and then have to feed it to Mutatis. Unfortunately I don’t remember the specific bugs from each day, but I do feel there were plenty. Some had quick fixes, though. I seem to have a penchant for typing X when I mean Y and 1 when 1 mean 0.

Day Six Line Count:3212
Day Six Game Size:
44 bytes of ROM space left in bank 1
160 bytes of ROM space left in bank 2
3207 bytes of ROM space left in bank 3
276 bytes of ROM space left in bank 4

******************************

Day Seven // Mutatis_006.bas

Since I was now referring to the ball as the Eye of Mutatis I thought it’d be nice to give it some life and have it blink. Since it’s only two pixels high that simply means shutting off one of those pixels now and again. While testing its vertical speed I stumbled into the idea of having the ball move at a different rate on each axis. But! This led to the ball jumping over its collision with the playfield on the top and bottom of the chamber, allowing it to get lost off-screen. My solution was to create an additional unseen boundary just a few pixels above the top and below the bottom playfield. This way, the ball hugs the playfield pixels if the player keeps moving toward it. Also, I like the sound that continuous bounce makes. 

I seem to remember the bomber sprite was giving me issues this day, missing its target, just flying off wherever, or causing the enemy reset subroutine to malfunction and hang-up, but I can’t recall the specifics.

This day I also worked on the game manual, recreating the general layout from the classic 2600 manuals. I don’t like the finished inked drawing of Mutatis, though the pencil version looks okay. Regardless, I’ll redo it, and work on some kind of action pose for the final manual, something more in the spirit of those grand Atari keyart paintings.

Day Seven Line Count: 3230
Day Seven Game Size:
38 bytes of ROM space left in bank 1
160 bytes of ROM space left in bank 2
3032 bytes of ROM space left in bank 3
276 bytes of ROM space left in bank 4

******************************

Day Eight // Mutatis_006b.bas

The final day I scheduled for a devlog video, but that didn’t happen. See, I still didn’t really have any real win or lose condition, and thought it best to at least submit a game that was… well... a game. So I spent day eight figuring that out (placeholders, to be honest) and creating an itchi.io page for the game jam submission.

Here are the bit operators I assigned for the game jam version of Mutatis, giving you an idea of what either/or conditions I’m tracking under the hood. If you haven't used bit operators, I made this video after I learned what they were while working on my game Telemachus. In short, instead of using the full byte of a variable to store a number, you can break it up into 8-bits, labelled 0 - 7, and assign a 0 or a 1 to each of these, thus expanding the number of available variables.

Day Eight Line Count: 3320
Day Eight Game Size:
730 bytes of ROM space left in bank 1
78 bytes of ROM space left in bank 2
1533 bytes of ROM space left in bank 3
276 bytes of ROM space left in bank 4

******************************

The Future

Though I didn’t reach every design goal, I had a lot of fun and learned some things, too. I plan on completing Mutatis beyond the scope of the game jam. Changes will include:

• Squashin’ programming bugs, of course
• Fuller sound implementation
• Exploding enemy sprite animation
• More enemies with varied behaviors
• An added game mechanic with the player affecting the rate of mutation
• Level variation including obstacles for The Eye of Mutatis
• A bonus speed level between level two and three
• A final level with the player directly controlling Mutatis in its final form to escape the chamber
• Game Select options including: Game 1: 30 seconds levels // Game 2: 60 second levels // Game 3: Collect 5 Genetic Nodes // Game 4: Collect 10 Genetic Nodes
• Difficulty Switch options including: Left Switch: Full Speed / Half Speed // Right Switch: Full Shields / Half Shields

If you want to play the version I submitted to the Game Jam, I welcome and appreciate all bug reports on the game’s main itch.io page. 

Thanks for your attention...!

peace,
-william