Look at the subroutine `EnemyMoveGetMaxRowBot` starting at line #9353. On #9414 the data row pointer is set to the enemy's current row. On #9441 it checks if the column to the left is a pole. On #9516 it checks if the column to the right is a pole. Now notice that on #9461 the row pointer is moved to the row below so it can check for a walkable tile (brick or ladder). When the right-side check is done after a left-side check the row pointer will be on the wrong row.
Here it is in C (from my own notes)
SetCurrentRow1(y);
if (CURROW1[x] != 0) {
if (x != 0) {
if (CURROW1[x-1] == 4) {
TargetY = y;
if (y >= PlayerY)
return y;
} else {
SetCurrentRow1(y+1);
if (CURROW1[x-1] == 1 || CURROW1[x-1] == 2 || CURROW1[x-1] == 3) {
TargetY = y;
if (y >= PlayerY)
return y;
}
}
}
if (x < 27) {
if (CURROW1[x+1] == 4) {
TargetY = y;
if (y >= PlayerY)
return y;
} else {
SetCurrentRow1(y+1);
if (CURROW1[x+1] == 1 || CURROW1[x+1] == 2 || CURROW1[x+1] == 3) {
TargetY = y;
if (y >= PlayerY)
return y;
}
}
}
}
The bug can be seen on level 29 if you stand on the left set of blocks that has a single gold in it. The enemies will get stuck on the second ladder which has a pole on the right side.
The Apple II, Atari 8-bit, Commodore 64, and naturally the VIC-20 versions of the game have this bug since they were all made by Broderbund. But interestingly so does the Hudson Soft NES port. The later Macintosh version, which is otherwise a direct port of the Apple II code, fixed it. The IBM-PC version didn't have this bug because it was rewritten with the memory layout column-ordered instead of row-ordered. But then introduced a similar bug by subtracting when it should be adding.
(edit: I hadn't checked until just now but I'm amused to find that Lode Runner Legacy from 2017 preserved this bug in the classic game mode.)
You just dredged up a deep memory. Is this the thing where the enemies would keep going up and down a ladder just generally speaking? I don’t know if I ever made it to level 29, my memory is not that good lol, but I do have memories of enemies just constantly going up and down ladders occasionally.
An enemy will try to reach the same floor height as the player, and if it can't it will prefer climbing up over climbing down. It also looks left then right for another ladder or free-fall that might bring it closer to the player's height.
In the case of level 29[1], the best position on the second ladder is to move to the top then use the horizontal pole to move left. That's what it will do when below the right-side pole. But when it gets above that it switches to thinking it should move down. Because the goal changes it gets stuck in the loop of moving up then moving down.
What you may be thinking of is when the "best" position is at the top of a ladder but no clear path left or right. It will climb to the top so the only way to go next is down. But after moving down immediately wants to go up again.
Original source, I imagine, would be very tersely commented, if only to fit in memory / floppy, and would have very short variable and subroutine names, and lots of mess and commented-out lines from experiments.
I just went to a talk at Portland Retro Game Festival by the dutch guy that made an official Atari Lode Runner port. He said he found a japanese book that had the C source in it and got the enemy AI from that.
Interesting, the only DOS version I know of is the official Broderbund version, which I played the hell out of as a kid. I still consider this the best game ever made
Aaaaah it's one 21k assembly file (including data in hex format). Step #1 for anyone trying to port this to another platform will be to split it up into smaller files, no doubt.
fortunately, you don't have to care about those details, just go and do it ;) I don't think the original person who decompiled someone else's intellectual property has too much ground to stand on here lol
Here is the repository owner explaining the process himself: https://github.com/Piddewitt/C64-Game-Source-Code
Nice work and interesting still, but maybe we can correct the title?