ParserComp 2021 ~ Bug Fixes ENABLED (and other) During Voting

Hi all,

I had ticked the box which prevented uploads during the voting period - apologies.

This is now corrected, sorry for the inconvenience and hopefully it won’t cause too many issues.





I want to attract your attention in one direction.
Info under platform filter on left hand of main screen is wrong and incomplete. All files released *.z5 , *.blorb *.gblorb, *.zblorb, *.ulx can be run under any platform with the properly intrepreter.


That … is an extremely good point. I suspect there isn’t anything immediate we can do, but i’ll contact to see if they would consider reviewing this and adding the “virtual” machines.

Good spot.



1 Like

Hey, I’m grateful for the chance to fix an obvious bug so quickly. And as a competitor, I am glad to see you giving other competitors to present themselves at their best, to fix any mistakes where they clearly knew better. Of course, the IFComp-style note that nobody has to play the updated version applies.

Is there any way authors should specifically note bug fixes on their game’s page? I think we should, just for full disclosure. I also imagine we should keep the original, in case some judges do not wish to play updates. And I also imagine there should be some restrictions on announcing updates publicly.

Below’s an example of in-comp update listings from the Adventuron jam earlier this year that worked well for me as a judge/observer. The author has links to devlogs that describe their fixes in more detail. So I think it is well done. And I think it’s useful for me to expound on my thoughts of why and how a bug slipped through.

But I don’t know how that clashes with the rules to avoid excessive self-promotion. While I don’t suspect it does, I do want to make sure.

These questions feel picayune asking them, but I hope they’re worth a brief clear-up, and there’s a chance other authors may be wondering, too.


One of the reviewers found an embarassing bug in one of my games. I’ve fixed it, but haven’t posted an update and I’m not sure whether I should until the comp is over, just in case there are any others yet to be found.

I know that I’m allowed to do updates for bug fixes and am grateful for that. When posting an update, the blog is probably a handy feature to use, just as Ricardo did in your example.


Is it a critical, game-breaking bug or is the game still completable in the unfixed version?

It’s a trivial thing that most players are unlikely to encounter, otherwise I would have updated it straight away.

I think it’s worthwhile to update a small thing and, if possible, post, because it’s that much more evidence you’re dedicated to your craft and not just in it for the competition or to say “hey, look, I wrote a game!”

I’ve found eventually small updates get exhausting. Then they can be lumped into a quick post-comp release. But I also feel the longer the comp goes on, the less value you or judges will get from minor fixes, because they’ll have less time to play the games, and they may not have time for a detailed playthrough.

As for how long to wait … one rule I have for updating is to wait 12-24 hours before submitting an update in case there are any related issues. An example might be if someone notes a room didn’t list certain exits. I might fix that room, then later look at all the others.

For more technical bug fixes I want to wait to think of special side cases my code might not have fixed, or even if my code introduced a regression. I don’t need to make a full test plan, but it’s important to have time to step back and say, okay, here’s something that could break, and here’s something that might be broken, because I don’t want to need to update quickly again.