More on the AI and overall progress

Last night I finished commenting the guard AI code. FTR there's approximately 700 lines of 6502 assembler to produce almost exactly 1KB of object code for the AI. It's straight-forward enough to decipher on a line-by-line basis; it's when I try to wrap my head around the algorithm as a whole that it takes a few more brain cells. I'm most of the way there I think.

It also doesn't help that one of the first sections of the algorithm that I tackled has a bug. I'm yet to confirm this, but I believe that this bug is (at least partly) responsible for the instances where the guards actually run away from the player. You may be tempted to suggest that it's a feature rather than a bug, but the very nature of it suggests to me that it is indeed a bug, even if the behaviour was an unintended side-effect that Doug Smith decided to retain.

Roughly speaking, as far as I've deduced the guards attempt to get themselves - first and foremost - onto the same level (row) as the player, and the search algorithm for a path is quite exhaustive, which means a lot of code gets executed. When scanning down to see if the guard can get to the same level, it (also) checks each side of that column to see if there is a route to the left or right. Checking the route to the left is OK, but when checking to the right, under some circumstances the aforementioned bug causes it to check the wrong row. So it sometimes sees an obstruction when there isn't one, and will run away when in fact the guard is only a few (empty) tiles away from the player. Other times the guard will get stuck trying to follow a non-existent route (e.g. when you see them looping on ladders).

Anyway, I'm yet to port the code and when I've done so, I'll experiment more to document the exact behaviour caused by the bug. I can also 'fix' it and see if the game is any harder.

I also did a quick 'audit' of the original code and I'm satisfied that I've identified most of the code and that those sections that I haven't commented can be attributed to the level editor or other sections that I know about but haven't ported yet. On this note, a list of what is yet to be ported includes:

• Accurate game speed throttling
• Circular wipe at the start and end of each level/life
• Spinning 'GAME OVER' text animation
• Restoration of game screen after High Score screen displayed mid-game
• High score table (itself)
• High score determination and name entry
• Storage and loading of the entire 150 levels
• And last but certainly not least - sound!

EDIT: updated list above

 Aside from the above, there's only the matter of saving/loading high scores (if I opt to implement that) and of course the level editor, which I have no plans to port at this stage.

And for the case of the Coco3, it'll be tight but I still believe it will be possible to have a 4-colour mode version of the game. The cartridge version is looking a little less likely at this stage, at least without some fancy bank-switching hardware on the cartridge itself.

I've also come across a few small sections of dead code. This includes a look-up table that determines the time that a guard will remain in a hole before attempting to escape, whose index is determined not only by the number of guards on the level, but also by an unknown variable whose value never appears to be set to anything other than zero - unless there is a problem loading/displaying the level!?! Weird...

Right now I need to finish porting the AI and then ensure that the demo levels run correctly. Once I'm satisfied that the game-play is intact and 100% faithful to the original, I'll release a playable demo of the first 5 (or so) levels whilst I finish off the bells and whistles.