I don't see how that could have been accidentally discovered. It is so esoteric and time consuming, that even if someone owned an arcade and could set the machine to free play, what kind of thought process from historical hacks prior to 1982 would have inspired that kind of a search space? Much like easter eggs in early Microsoft Office products from ca. 1990, I can't imagine. Like maybe trying to run down a shot counter might have been on the agenda, but those two specific aliens just cinch it for me. Now, as to whether it is a bug or not.
Looking at the forensics of the original ROM at the provided URL[0], the fix is nontrivial. It looks like a bug, IMHO. But if it is a bug, who stumbled upon it? I would think that if the author put that in there to get the high score all the time, it certainly is obfuscated enough, but he would run the risk of being discovered. Perhaps the cheat is obfuscated in order to sneak it through code review and not be fired by Namco?
What really supports the bug theory is that the flight pattern of the far left bees has to be altered to account for their location on the screen. This REALLY feels like a bug, because when I'm trying to alter a corner case in code, I can rarely see the second-order consequences without code coverage/fuzzing. This is a total code smell IMHO.
But again, how would someone even exploit this flaw without the ROM. Which leads me back to the intentional cheat by the programmer.
I'm legit ambivalent about this. But if I was pushed, I'd have to say it was an intentional cheat slipped into the code, because programmers were just too good back then.
I completely disagree; it's easy to imagine someone in the first few days of the game's availability deciding for fun that instead of beating the first level, they were going to see how long they could keep it going. At that point, the natural thing to do is kill all but one enemy, and eventually it would stop shooting, which would be very attention-grabbing.
Then of course word would spread and investigations would begin as to how to reproduce and optimize the phenomenon.
Like the movie ready player one. No one went backwards in that race? This was written by people who do not game but know the flash of it. Watch any of the thousands of vids on youtube of people doing crazy things in speed runs and you will see different.
This is something I like to bring up to programmers/designers in context of application security. And that is any assumptions on how the user is going to use said program you come up with will be broken. If you say "No one will do ______" you will likely be incorrect.
The ** is code review? Most places didn't even have version control. Version control in most game development studios was "let me copy my source files on to another 5+1/4 floppy just in case disaster happens."
If lucky to have access to a mini computer with a hard drive then you kept separate directories for backups of your code. And you got cussed out by the high priest of IT because your backups were taking up more than 500KB of drive space. Maybe you got SCCS that would happily destroy your work regularly if you breathed wrong. If your company was rich it had a fully paid up copy of RCS runing on the Perkin-Elmer mini computer with 1MB of RAM and a 200MB HDD hooked up to a data station that looked like it was stolen off the set of Silent Running along with a 32kbps serial cable to your ICE box plugged in to the arcade board. And you got cussed out by the high priest of IT because now your RCS directory was bigger than your backup directory. And then inevitably someone wasn't paying attention one day and did an 'rm -rf *' on the wrong directory and the version control repository for your project got erased.
Code merging on non-UNIX development was usually "give me your floppy and I'll re-type bits of code you changed in that text file into my text file and then I'll give you back a fresh copy of the file to work with." If you were both smart about it, you worked in separate files and just had one or two common files that you played hot potato with, which was the fashion back in the day. Or you had a nifty little tool that would concatenate all the files together and then deleted duplicate lines and kept only the last version of changed lines because we believed we were too manly to use real development tools but the real reason was the company was too tight fisted to pay for them. "Hard drives are for the weak and why do you programmers need the high quality DS/DD floppies from Fujitsu anyway!?! Look, I've got this little gadget I bought for you that'll punch a notch in the other corner so you can just flip the disc over and use the other side too."
> and not be fired by Namco?
Nobody would have gotten fired over that even if they had purposely put it in there. The QA team would have found it, severity would have been decided, and it would have probably be pushed to "eh, there's not enough bytes in the ROM to patch it, it doesn't crash the machine and we've just burned enough PROMs on the gang programmer that the cost of pulling the PROMs off of arcade boards, junking a few thousand ICs and doing over is too great." It is almost certain that someone on the QA team found the bug, wrote it up, it was discussed, and then WNF'd, and then a little later on, news about it leaked out.
This also assumes of course they had a QA team and it wasn't just Bob who took a smoke break between running his bare hand over the live wiring looms feeling for shorts and exposed wiring to kill a few burbling aliens.
That's an interesting historical perspective of a code review from 50 years ago. Especially where you state that the Q&A team would review the code and decide to patch it or not. Did I used the wrong term from the 21st century? Clearly I was hypothesizing. I'm disappointed you couldn't just inform us without being so snarky.
One man's snark is another man's war story. There was no code review because video game development, and arcade video game development was the epitome of the Wild West and the lone cowboys who had late night coding sessions trying to figuring out how to shave 173 bytes from the build by changing JMP absolute (three bytes) to BEQ/BNE relative (two bytes) without suffering a page boundary cycle penalty so they could squeeze the game into two 8K PROMs instead of two 16KB PROMs. The primary concern in arcade game development was "does this bug make the game crash or visually glitch?" and "will the player get free time?" and if the answer was "no" to both of those, the bug was relegated to WNF (will not fix). QA in most companies really was Bob on the assembly line who put little dayglo stickers on the inside and wrote his initials under below the line that read "Q.C."
This is why I'm glad to see the old guard boy's club fading into a memory, despite the loss of skills that we may never see again as a culture. It's a mixed blessing.
The "old guard boy's club" has been around a long time, and is still around. The gatekeeping/exclusionary mindset cannot die off fast enough as far as I am concerned. Unfortunately, it won't. Where ever nerds of a culture gather, there you will find them. The old guard. Arms crossed. Legs akimbo. Judging you not worthy. Thinking they are cleverer than you because they read some obscure fact on a usenet group.
It's quite different incentive when you play for free - why waste your time dodging shots when you can fight but if you were playing in an arcade, some players might try and prolong the experience and enjoy the challenge of evading shots.
Looking at the forensics of the original ROM at the provided URL[0], the fix is nontrivial. It looks like a bug, IMHO. But if it is a bug, who stumbled upon it? I would think that if the author put that in there to get the high score all the time, it certainly is obfuscated enough, but he would run the risk of being discovered. Perhaps the cheat is obfuscated in order to sneak it through code review and not be fired by Namco?
What really supports the bug theory is that the flight pattern of the far left bees has to be altered to account for their location on the screen. This REALLY feels like a bug, because when I'm trying to alter a corner case in code, I can rarely see the second-order consequences without code coverage/fuzzing. This is a total code smell IMHO.
But again, how would someone even exploit this flaw without the ROM. Which leads me back to the intentional cheat by the programmer.
I'm legit ambivalent about this. But if I was pushed, I'd have to say it was an intentional cheat slipped into the code, because programmers were just too good back then.
TEAM CHEAT FTW.
[0] https://www.computerarcheology.com/Arcade/Galaga/