💾 Archived View for capsule.usebox.net › gemlog › 20210505-on-software-preservation.gmi captured on 2024-08-18 at 17:27:06. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Posted Wed 5 May, 2021.
When I released "Brick Rick: Graveyard Shift" *checks notes* two months ago (and it really feels like ages ago!), I had the usual QA round, like I always do with my games. Which is essentially: let a group of good friends play the game.
Besides of being good friends, they have special skills, because my games are not easy, yet almost all them finish the game several times before the testing round is finished. And those special skills include "patience", because testing a game is not necessarily fun all the time. There's a lot of repetition, a lot of trying to crash the game, and sometimes trying to reproduce an elusive bug (we had one of those in this game).
We work hard, even if is not our professional activity, as in: we do this for fun (and for free). But it is almost inevitable that a few minor bugs remain in the released game and those will require fixes, usually the same week the game has been published. Unfortunately this may make some of the physical copies "rare" and "eBay expensive", because if the game is released in cassette, there's no DLC for that (even if you can always download the fixed copy from my website, and for free).
So my usual process is: fix the bug, test the fix, run some more general smoke tests, and replace the buggy release on my website. Then announce the fix, and move on. And I always delete the old version.
Why do I do that? Because that's a broken version of the game. OK, very often we are talking about minor bugs that are only worth fixing because a new release is "cheap". Perhaps "broken" is a bit strong way of putting it, but the truth is that is not the experience I want for the players. A bug fix doesn't remove or add functionality. The game doesn't change other than removing a defect that shouldn't be there.
So it makes sense to remove those old releases. Or, at least, that's what I thought!
I got contacted by a MAME developer that streams games using MAME. Usually arcade games, but turns out MAME can also emulate microcomputers (to some capacity at least), and that includes the ZX Spectrum. And during the stream, he found a bug. Embarrassing, but extremely useful to have a video of the issue (and it didn't crash the game, yay!).
That was very lucky, because it was one of those bugs that is very easy to fix, but extremely hard to reproduce if you don't know what are you looking for (it could only be reproduced in 4 screens of 50). So I went through the whole process of fixing, testing, releasing, etc.
And then he asked me to consider my decision of removing the buggy versions from my website, because the main purpose of project MAME is to preserve software history, and in a way I was actively making that harder (or impossible). And I felt terribly bad about that because he helped me to fix a bug (he also seems a nice guy).
In a lot of cases, the user communities of the old microcomputers are involved in preservation initiatives, so the old catalogue of those machines from the 80s is not lost; and that includes new releases. Very often they keep record of all my releases for me.
I'm still undecided. In a way, keeping those releases is a reminder of my own mistakes and failure as software engineer, but at the same time I see the point of my friend's request.
For now I can postpone any decision because I didn't have to make any new releases (is the game bug free? sure!), and I don't have copies of the old releases to restore them. So we will see with my next game. Perhaps the answer is to make a game that is bug free with just one release!