I'm among the top DK players, and I am a computer programmer by profession. Furthermore, my primary role at my job is in automation, where I write software that mimics user actions (launching programs, entering keyboard inputs, mouse clicks, etc.). The scripting software I write pilots software in development, and navigates different end-to-end paths based on sometimes planned, and sometimes random choices -- it's even capable of making reactionary choices by searching for objects presented on the screen and acting accordingly. In a sentence, I manage a team of software "robots" that do my job faster and more accurately than I ever could, and they do it without experiencing fatigue.
My co-workers know about my DK hobby, and the question has come up many times before: "So why don't you make one of your robots play Donkey Kong?"
I never want to truly start the conversation where I explain the challenges involved in such an undertaking, so I always just laugh saying "Haha, wouldn't that be something!?"
The truth is, that guy from KOK had it right: "If you could hack into the machine and program it to play itself, you couldn't even program it that well."
I'm confident that a DK playing program is "vaporware." That is to say, it's an idea that could never be correctly implemented.
I say all of this because I run into similar issues at work all the time. The client's understanding of how the automation should work, and a programmer's understanding of how the automation actually does work, is fundamentally different. From one person's perspective, the question is "Couldn't you just... make it work?" From the other person's perspective, the question is "How do I handle every possibility?" The program will only do exactly what you teach it to do.
To offer an example, consider the barrel board.
We know that to some degree you can influence the behavior of the barrels, and sometimes steer them down ladders.
Consequently, when you're playing, even though Jumpman is what you're controlling primarily, your focus is on the screen as a whole. You're anticipating barrels as they cross over ladders, because you might want to steer them down for better/easier groupings, or you may want to steer them down to keep them away from you. Of similar concept, there are times when you will want to return the controls to a "neutral" position so the barrels have a greater chance of continuing across the ladder without coming down it. These decisions occur while you're controlling Jumpman to progress up the screen without dying, while maximizing opportunities to score points.
On a fully populated barrels screen, your program is tasked with tracking 7-8 barrels. In some situations, you begin tracking fewer barrels as Jumpman proceeds up the screen, because at some point a barrel "becomes dead" as it has no more influence on your score. It's difficult to always determine the circumstances as to what makes a dead barrel, because if you're moving down ladders, a barrel that has passed you still has potential for earning more points.
From a programming perspective, you'd have to store the color of barrel (brown, blue), their x,y position, and type (first thrown (predictable), first rolled (can't be controlled), normal (can be controlled), wild (multiple types), bomb). Tracking them would be challenging, because they have different frames of animation, look different when they're grouped on top of each other, and effectively change sprites when they are on the ladder. If a barrel falls off a platform edge, they have a slight bounce to them, meaning that you couldn't necessarily use a static image to track at all times relative to the top pixel of a girder.
When barrels roll through fireballs, the fireball sprite overwrites the barrel sprites. When you jump over a barrel or a group of barrels, the points awarded sprite appears beneath Jumpman at the peak of his jump, often overwriting part of the barrel sprites. Again, using static images, or isolated pixels that are used to track the barrels, turns into a nightmare.
Tracking the fireballs present similar challenges, since fireballs have flippable sprites, that have a slight bounce as they move, and change color when the hammer is held.
Even Jumpman himself is challenging to track, due to his multiple conditions and corresponding sprites: Facing right with no arms showing. Facing left with no arms showing. Facing right with arms showing. Facing left with arms showing. Jumping straight up facing left. Jumping straight up facing right. Jumping left facing left. Jumping left facing right. Jumping right facing right. Jumping right facing right. On the ladder with one foot on a rung. On the ladder sticking your butt out. At the top or bottom of a ladder with both feet on the ground, facing away from the user. With hammer and hammer is on upswing, with hammer and hammer is on downswing. With expiring hammer and hammer is on upswing, with expiring hammer and hammer is on downswing. Landed from a high jump and survived. The death animation.
Most of the Jumpman sprites have the potential to partially touch obstacles (girders, fireballs, barrels) without dying. The Jumpman sprite overwrites girders, while the fireballs and barrels overwrite him.
... I could continue delving into the subject, but I'm not sure it's worth it. When Jeff W came out with his Pauline tool, a companion tool to MAME that tracks your DK pace, I was impressed. As a programmer, I could see the behavior of his tool and understand how he made it. The screen objects that Pauline detects are in fixed positions, to read the score, the current level, and type of level. He put in additional logic to detect if you died, and calculated the pace appropriately. It was awesome.
Now, Jeff's tool is relatively simple compared to the "DK Autopilot" you're suggesting now, but I'm certain that even Jeff's tool had its challenges.
What it really comes down to is that there are two camps. People who understand programming, and people who understand Donkey Kong. People at my work are in the first camp, people on this forum are in the second camp, and a select few belong to both.
I may possess the correct combination of DK understanding and programming experience to attempt this task, but I won't. I believe it is actually easier to beat the DK world record manually, than try to create a program to do it for me. The first challenge is challenge enough. The second challenge is much more work, and a lot less fun.
