Wednesday 28 May 2014

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.

2 comments:

  1. I'm quite interested in how the AI works, but I'm really curious if the pathfinding bug appears in other ports of Lode Runner. Presumably it would be easy to find a test case in the Apple ][ version and try that same scenario in the ports.

    I could see that it would come through if it were needed to finish a level. Certainly some of the other seemingly "dumb" guard moves are important. Like them running away when you're on a ladder but just a little below a platform they're on.

    ReplyDelete
  2. That's something I intend to investigate further. My MSX disassembly is around 50% complete IIRC; I could probably go back to that and deduce the rest of the logic much more easily now with the original under my belt.

    This page here mentions at least one other version "with original AI" but not sure about the others. I do suspect that in most of the more faithful ports (eg. MSX, C64) the AI was also faithfully reproduced. Especially, as you suggest, that some levels would no doubt have been designed around the specific AI behaviour.

    The above link also mentions that Championship Lode Runner was simply a collection of user-designed levels. That bodes well for the possibility of including those levels into the Coco3 port!

    ReplyDelete