

I wasn’t particularly shocked that my game exceeded the 3.5KB limit of an unexpanded Vic 20, but it was disappointing to find that it also won’t fit on a Commodore 16!
Luckily, the target commodore PET offers 32KB, and as the name implies, the C64 has 64KB.
This means that as long as I can keep trimming unnecessary code, I can run this game on a variety of classic systems—and of course, on modern devices too.
In fact, it might even run on a smart fridge!
With all that in perspective, any future enhancements will follow a two-steps-forward, one-step-back strategy.
For instance, today I removed some surplus code but then added doors, which naturally pushed me over the 32KB limit again.
Placing the doors involves locating suitable spaces, similar to character or enemy placement, but requires some additional logic.
Here’s how the map appeared before adding doors:
#############
#.......#...#
####........#
#.......#...#
#.......#...#
#############
A door should be positioned in areas with space above and on the sides and must also be adjacent to walls above and below.
Sounds simple enough, right? I overlooked a key element and ended up with cupboards instead…
#############
#..+....#...#
####........#
#.......#...#
#.......##+##
#############
Having a door right next to a wall is not very useful. Even introducing just one space makes it an unlikely room.
Who would waste a key unlocking a door to nowhere?
Thus, my code for placing a vertical door now looks like this:
void placeHDoor(void) {
int row, col;
unsigned char tile;
tile = '+';
do {
row = (rand() % (PLAYABLE_HEIGHT - 2)) + HUD_TOP + 1;
col = (rand() % (MAP_WIDTH - 2)) + 1;
} while ( map[row][col] != '.' ||
map[row][col-1] != '.' || map[row][col-2] != '#' ||
map[row][col+1] != '.' || map[row][col+2] != '#' ||
map[row-1][col] != '.' || map[row+1][col] != '.' ||
map[row-2][col] != '.' || map[row+2][col] != '.'
);
map[row][col] = tile;
map[row][col-1] = '#';
map[row][col+1] = '#';
}
Currently, I am using ‘+’ to represent a door, as is standard in many rogue-like games. Eventually, I aim to replace it with more visually appealing characters, user-defined symbols, or even graphics.
Additions like this require some sacrifices elsewhere.
After reflecting, I realized the primary reason for my map centering code was to accommodate various screen sizes.
Ultimately, I recognized that it’s unlikely to port the game to screens narrower than 40 columns while also having less RAM.
Larger screens beyond 40 columns pose minimal issues as long as the game looks good at 40 columns, even if it is aligned to the left.
Removing that code and the related arrays allowed me to scale back within the PET’s 32KB limits, making the sacrifice worthwhile!
Original article by retrogamecoders.com


