The guards are getting smarter!

As I mentioned, the AI for when the guard is on the same row as the player is quite simple; if there's a direct path to the player, then move towards the player! Pretty intuitive stuff.

So this much I've implemented, and I can confirm that it's enough to get the guards escaping from the holes if the player remains on the same level. Yah! I did discover another minor glitch though - when the guard interrupts the digging it isn't cleaned up properly. I'll get to that in due course...

This morning I hit memory problems again (the code is about 3,500 lines and assembles to about 8KB now), so it was time to move the title screen data out of the source code and load it into high memory. Here's the breakdown of the Coco's 64KB memory space so far:

• monochrome screen #1 $0000-$1DFF (8KB)
• monochrome screen #2 $2000-$3DFF (8KB)
• 6502 zero-page memory variables $3F00-$3FFF
• program code & data $4000-$6DFF (assembler output)
• monochrome tile data (4 sets) $8000-$A3C0 (pre-loaded from a disk file)
• monochrome title data $A800-$B993 (pre-loaded from a disk file)

I need to keep in mind that the colour mode will require double the video memory (32KB) which will shift everything up by 16KB and basically then occupy every (8KB) page in the 64KB addressable memory space. Hence the level data will need to be stored in high memory and switched-in as required to generate each level. Or I could swap the DISK BASIC ROM back in and load the levels from disk (potentially messy since I'll need to be mindful of ROM buffer/memory requirements). Haven't decided which way to go on that just yet.

Each colour tile will require twice the data, but since I'll only need two (2) sets instead of four, it should occupy the same space. Likewise since the title screen data is stored in RLE format, I'm not expecting it to require too much more memory either.

Anyway, onwards with the AI for now...