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!
32k seemed so big back then. On the Beeb you had to compromise between resolution+colours and free memory, but most stuff I wrote was pretty small. Years later I would be fighting for memory on MS-DOS 4 or 5 and trying DR-DOS with various settings to get the most from 640k. Now we have gigabytes, but that can get eaten up. I guess going back to the old machines makes you think more about optimising code.
I always think that back in the day, the code had to be much more efficient as there were so many hardware limitations and the need for better software drove the hardware development unlike later when there was almost unlimited hardware resource and so code often became a little lazy and bloated. I think we've lived through amazing times in the development of tech.
Hope you're well and have a great weekend :-)
Thanks for your contribution to the STEMsocial community. Feel free to join us on discord to get to know the rest of us!
Please consider delegating to the @stemsocial account (85% of the curation rewards are returned).
You may also include @stemsocial as a beneficiary of the rewards of this post to get a stronger support.