As part of my comment pass on my code I started to notice a few parts of my code I should change. Most of these changes were along the lines of removing superfluous {} pairs in for/if/while statements. These got in because when I am first writing the code I like to have them for definition of the areas and because I am never sure how large a given statement will get. So better to just put it in at the start than to figure out where I need it latter.

However, in going through the code again I realized I could remove a fair number of lines of code(around 10-20 lines in my longer scripts), making things a bit cleaner. I also realized that a small for loop should be in its own function, and called by the game as needed, rather than being in the update section constantly being run.

Now on to the bit of code that sparked this post.

When I was first making this game I had a bunch of ideas. These included having a level editor and being able to share level codes. As such I needed to create a “password” system for these codes. Something that would be abstract enough that a casual user might not realize what was going on but that also carried the relevant data. Then I realized that the base game (all out) was basically a 25 digit binary string. If I took that string and split it up into 4 digit sections (with a trailing 1 or 0) I could then convert those to base 16 (0-9, a, b, c, d, e, and f for the additional numerals). This solved both problems of making the passcodes look like gobbledygook while also preserving the data I needed. (I was also a bit proud of figuring out how to do all the math on my own without using any sources)

When creating the Match puzzle variant it was a simple matter to append a second string for the end state as well as the original start state. Decoding it was a bit more challenging, but simple enough. With all that in place I went about making the 200+ levels for each game mode using this passcode system. By this point I had already abandoned the idea of a level creator, or of ever letting the player see any of these passcodes, but I had a system that worked, so why change it?

Then I made something for which the system would not work.

I created what I call the “Chromatic” version of the puzzle, where each box has 4 states (one “off” and three different “on” states). By the way, it is called chromatic because at first I used different colors to differentiate the states, but quickly changed that as soon as I remembered color blind accessibility, back on target.

The observant have already seen the problem. While the base and match puzzles were basically binary strings of on or off, this new puzzle type didn’t share that simplicity. However, this did not present the problem one might think it would. I simply had the puzzle generate 25 digit codes with 0-3 to indicate a given button’s state. simplicity itself.

Now back to the present. I was looking over my code and re-discovered this discrepancy. The function that interpreted codes for two of my puzzle types was well over 100 lines long, and the function in my “chromatic” puzzle for the same purpose… was less than 20 lines. So I immediately thought “should I just replace this old, outdated, code?” And the answer I came to was: no.

There are two reasons for this. First the less important reason: The code still works just fine. That is not to say it couldn’t work better, but it is functional and not causing issues, which means I don’t have a good argument against the more pressing issue. That being, how long it would take to replace it. Replacing the actual code wouldn’t take much time at all 60-80% of the job would be simple copy and paste work. The real problem is that I have a bit over 400 level codes between the two level types that use this old passcode system, and I would need to either convert them all or make new ones. And that is simply more time and energy than making this “upgrade” is worth.

If I ever find a more pressing reason to make the change I will take that time to do it. But until then this side grade is not worth the several weeks of effort it would take to accomplish.

So when do you not change old, outdated code? When the effort to do so outweighs the benefits of doing so.