Sometimes you code a thing and hate it while you’re doing it. You figure “eh, it’ll be fine, I probably won’t need to mess with this again” and for a while you’re probably even right.
As you start your work you realize that the fragile thing you’ve created, wrestled with while you were making it the first time, and then forgotten about entirely, was in fact just waiting to come back and bite you. The time has come around where you discover it has lots of teeth.
In this case, the code Fracterebus shows you when you beat the game, which is called the verify code, was waiting to blow up. It keeps track of a bunch of things about the run through the game that you just finished, and I needed it to have 2 more things and to change its form a bit. Due to the complexity of the verify code, it was barely holding together as it was, but adding to it and changing a few fields within it was enough for it to blow up in my face.
I needed to revise my approach entirely and it took me almost two whole days of work to weave those changes through it. The cool part is that the structure of the verify code is now considerably easier to change and supports more features than before, but there is a bit of a lesson to be had here. There was a phrase I recall from back in the day, and sadly I don’t remember where I heard it, but it went kind of like this: “Always write code as though it will be you that gets stuck maintaining it.” More often than not, you will be.