Guarded optimism

I've spent the last few sessions - several hours - reverse-engineering the code for the guards.

I've long suspected (and by long, I mean a good quarter of a century) that the design of the guards - in the player's image - was solely to enable the use of the same movement logic & code. As it turns out, I'm only half right; the code is very, very similar but it is duplicated in its entirety for the guards.

The good news is that it's very simple to reverse-engineer, for the most part, as a lot of it really is a carbon copy of the player movement code. The bad news is - there's an awful lot of it! More than the player movement code because it needs to handle 5 guards, and it needs to handle other logic like re-spawning.

There are three main areas of guard code that I need to implement; the death of the guards when they fall into a hole and get filled-in (fairly trivial), the movement (both AI and mechanics) of the guards, and the re-spawning of the guards when they are resurrected.

Of course the guard code only deals with the current guard; a table of state data gets copied to-and-fro for each of the guards during the main loop iteration. The guards also need a bit more state data than the player, such as dead/alive and whether or not they're carrying gold.

As it is, I've probably done enough to get a start on the porting, and the rest should come out in the wash while I'm doing so. I've located the AI routine but haven't yet peeked inside it - that will come last. I've already decided that for testing the guard mechanics, I'll simply have them mirror the player's movements, which will of course allow me to manoeuvre them manually. Furthermore, I've already worked out exactly how to do that!

Given the amount of code that needs to be ported, I'd expect it'll be a week or so before I have the mechanics in place, but I'm optimistic that it will be quite straightforward.

The AI is another issue altogether.