I wasn't too surprised that my game didn't fit into the 3.5KB available on an unexpanded Vic 20, but I was sad to see it won't fit into a Commodore 16!
Fortunately, the target Commodore PET has 32KB, and as the name suggests, the C64 has 64KB.
This means so long as I can keep trimming the fat, I can at least have this game run on a whole bunch of classic systems, and of course anything modern.
Heck, it would likely run on a smart fridge.
With all that in mind, any future features will have a two steps forward, one step back approach.
For example, today I trimmed some bloat but then added doors. You guessed it, that put me over the 32KB memory again.
Adding the doors involves finding an available space, as with placing the character or enemies, but with some extra logic.
Imagine this is the map before we add doors:
#############
#.......#...#
####........#
#.......#...#
#.......#...#
#############
A door needs to go where there is space above and to the sides, but also needs to go where there is a wall either above and below.
Easy enough? Well, I forgot an element and ended up with cupboards ...
#############
#..+....#...#
####........#
#.......#...#
#.......##+##
#############
Being right up against a wall is a pretty useless door. And even adding one space made it a pretty unlikely room.
Who is going to waste a key opening a door to nowhere?
So now my placement code for a vertical door 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, using '+' to represent a door, because that is what most rogue-like games use. Eventually I will be able to replace that with more pretty characters, user defined characters, or even graphics.
Adding this logic meant something had to be jettisoned.
Thinking things through, the main reason I had the map centering code was because the map might have to fit into different sized screens.
Eventually I realized I was unlikely to be able to port the game to smaller screens than 40 columns wide while they also have less RAM.
Larger screens than 40 columns aren't that much of a problem so long as the game looks good at 40 columns, even if the screen is then left aligned.
Removing that code and the associated arrays got me back down within the PET 32KB limits, so a sacrifice but worthwhile!