Some of you might remember a year ago we had a discussion on our Slack channel about the ability to send post-deadline fixes , and debated on the details of what’s allowed and what is not. Given we still had it raised this year again made me realize I didn’t properly solve the issue back then in the first place.
(For TL;DR scroll down to the very bottom of this post.)
History of post-deadline fixes
To do that though I need to explain how it all started. So, before we had the new and shiny submit form with drafts, I was manually validating and accepting all entries submitted through a simple one-page input form. You’ve entered the title, description, some other details, attached your zip and that’s it - the game was submitted to the competition. This, given most folks did that in the last hours, or even worse minutes before the deadline, caused some entries to have bugs. Critical ones preventing games from being played, mostly wrong paths to files. I was usually fixing that myself manually as there was no easy way for participants to fix or resubmit an entry themselves.
Initially the official rule was simple: absolutely no changes past the deadline, after all the voting had to start as soon as possible. At some point though, some devs kindly asked if they can send a new zip with critical fixes, since sometimes it was something a bit more complicated than missing a slash in the url. I knew those developers had good intentions and only wanted to improve something they somehow missed, and it wasn’t a dump of new features disguised as a one line fix, so I started accepting those. Each edition people were sending me updated zips with mostly critical fixes, but also small improvements since I was already accepting a new build, within the first hours after the deadline and still before the voting was starting.
It wasn’t common knowledge as it wasn’t written in the Rules, but it also wasn’t a secret - I was open about it on our Slack. Those who knew, knew, which didn’t seem like an issue at first. After all I didn’t want to stop helping making games the best they could be, and at the same time this was all manual work and I didn’t want all participants to now use the extra hours to work on their entries updating everything they could, as it was exhausting updating the amount of entries I did already while trying to wrap the submissions and start the voting.
Fast forward a few years, and we ended up with a group of folks who knew they can update their games, and newcomers who didn’t have the idea, since this wasn’t in the rules at all. This sparked the discussion about fairness of the ability to update (or not) your entry past the deadline, which is one aspect to what this blog post is going to cover. The other one was: what is actually allowed as a fix.
What is a bugfix?
Given the amount of new requests to update the zip “with just this small fix” increased, it was more and more difficult to verify what actually changed, since it was about unpacking a single minified zip sent via a private message on Slack and uploading it through an FTP. The competition’s website didn’t run the games from a GitHub repo, but a PHP backend made in 2013. It was simpler for me to just accept what was coming, remembering the good intentions of those sending the updated zips.
Fast forward again and we ended up with the vague idea of “yeah, you can send important fixes if you’re nice to Ender in a private message, but remember he’s busy”. The crucial part was the word important. By default it was an update to fix a critical bug preventing the game from being played, but in time it was watered down to anything important to developers that they were able to fix and improve in that few hour window. Of course there was no time to add entirely new features. Plus it was accepted anyway, and people knew about it, so what’s the problem?
Over the years this was a bit of a gray area, but it worked. There were no complaints. This wasn’t formalized to not end up with potentially everyone doing it and adding even more manual work, but I couldn’t simply stop accepting those fixes either as folks could do it for so many years already and there were no complaints so far, so what’s the problem?
Too gray area
The first fact that some people knew they could update their games past the deadline (while some others had no idea it’s even possible) and the second fact that some of those people could submit minor improvements over critical fixes culminated in a big Slack thread a year ago. The critical mass was reached and everything exploded.
Apologies needed
This is the right moment to say that I should’ve written and published this exact blog post a year ago, but I somehow didn’t want to upset some of the people from the community who liked how things worked so far. I also should’ve strongly voiced my opinion about all this (and put it in the Rules!) instead of hoping it will just automagically solve itself. I didn’t want to hurt people’s feelings, and so this year we ended up with more people being angry and upset than before, as shockingly the issues didn’t disappear.
I sincerely apologize for the whole situation. I know the next steps I’ve chosen might upset even more people, but I do hope that those who are going to stay will know exactly what to expect from this competition in the future, and that the rules will be transparent and fair to everyone from now on.
Next steps
First, I’ve decided to limit the ability to send post-deadline updates to the first 24 hours. You will be able to fix minor bugs before the voting starts, but you will have to send a Pull Request via GitHub with all the changes being listed in detail, and no new features are allowed. This means you will be allowed to optimize your game’s difficulty, but not add sounds or a new level if they weren’t present in the submitted version.
Second, initially designed to be allowed for 24 hours as well, I’ve decided to allow critical fixes throughout the whole voting period. And by critical fixes I do mean things that break your game: paths are wrong and I can’t play the game on the website at all. An issue with the packer blocked all input and I can’t control the player. Updating the balance, changing the text, adjusting the UI, or adding new features is not a critical fix and won’t be accepted past the first 24 hour window.
Some bugs might slip through and we might still end up with entries that on some specific setups the author didn’t have simply don’t work, that’s why this process is not limited to the first day. Your random seed makes the game unwinnable? That’s quite serious. Game over screen wrongly calculates your total score? Not so much.
This still leaves things open to interpretation, but it’s a much smaller “gray area” than we used to have. I think this year’s few cases clearly showcased what was a critical fix and what wasn’t. The point is to have a deadline, clear rules, and stick to those.
The point is also to finally have this written, and the Rules updated properly. I’ve done that already, and so every single participant from now on will have the exact same chance at participating and fixing potential critical issues.
Given we serve the games from a GitHub repo, it will be done via Pull Requests: you’ll have 24 hours to submit a PR with well documented updates, and I will personally investigate the changes to make sure it’s all ok. Same goes for voting period and submitting critical fixes - I’ll make sure those accepted are only actual critical ones. You will be free to raise a discussion if you won’t be agreeing with the decision, as all will be public. This is to ensure that the whole process is transparent and available to everyone.
Arcade portal with infinite updates
I know some of you wanted to have the ability to update your games for a week, or a month, or even indefinitely, and fix whatever’s broken even if it meant a typo in the game over screen. I do understand the arguments, I’d love to see js13kGames become a games Portal and your portfolio at the same time, where you can showcase the best possible version of your game. We do have Director’s Cut already, but it’s an external link, while it could be an updated game that still fits within the 13 kilobyte size limitation. I really do get that, and I love the idea. Years ago we even had an attempt at a js13kGames Arcade with features popular game portals have.
The thing is: js13kGames is, first and foremost, a competition with a clear deadline. You make a game, submit it, judge other entries, receive feedback, and optionally win something. Then we all celebrate, and move on. This is not a game portal where you can host your constantly updated 13 kilobyte game. Again, as much as I love the idea itself, I’m not sure there’s a good way to have both at the same time.
Also, I don’t want people to feel the extra week or three we’d possibly agree to have as a window for potential fixes big and small is a good approach either. This would effectively change “a month-long competition” to “a month-and-some-more competition”, and then there would be a hard deadline, but after 45 days.
As much as we could have a third link, next to the first with the original vanilla version of what was submitted in the original deadline, and the second being Director’s Cut which is an external link to whatever you can do with your original idea, this would complicate things even more. In the perfect world, and given our competition is so unique, the third link would be version 1.1 (I’d prefer 1.3 or 1.13 though) which you can update on top of the already submitted 1.0 version. This is effectively still extending the deadline though — one day, a week, a month, or a year. We present three different versions of the game over two, all when the Director’s Cut was confusing for some already.
I’m not saying this is impossible and we will never have it, I’m only saying I don’t think this is crucial right now. I’m open to discuss that though.
Unranked as a solution
This brings us to a discussion proposal about the ability to send non-critical updates past the deadline (and the initial 24 hour fix window), but being moved to an Unranked “category”, where your game still receives votes and feedback, but is ultimately not present in the list of winners. Something between the regular entry and Unfinished, which is not judged at all.
Again, I do understand this concept makes sense, as you might have the unstoppable urge to fix your game’s balance or anything else beyond what’s considered “critical” to a point that you can exclude yourself from the overall standings, but you still want people’s feedback. I’m not even sure if that would be easy enough to implement in the current website or not, I like the idea and could imagine having this sometime in the future as a nice addition, but I don’t think we need this right now either.
The rules have to be short and strict: you have 24 hours for any minor fixes, and that’s it. This isn’t a weekend-long hackathon where you choose caffeinated drinks and pizza over sleep, the drafts are there for you to test your game throughout the whole month. Of course mistakes can happen, and if you mess things up bad enough that your game is unplayable, I will help you fix that. You can still update the Director’s Cut version, we might end up with the third link eventually, or morph into a games portal, but so far js13kGames is a competition with a clear deadline. You make sure to submit the best possible version of the game you are capable of creating, and then that’s it - the voting begins. You are locked.
Your feedback is welcomed
I understand I made a strong statement here, and there will be people who disagree. I encourage everyone (those agreeing as well) to leave their feedback in this discussion thread on GitHub with anything that you have a strong opinion about. Why do you think this approach makes sense, or why it doesn’t. Maybe you have a totally different idea you’d like to present? Go ahead! All I’m asking is focusing on facts and constructive criticism - any attempts at derailing the thread and personally attacking anyone will result in permanent bans from the community.
TL;DR
I’ve formalized the fact that participants can submit any minor fixes to their entries within the first 24 hours after the deadline, but this will be manually verified by me personally on a case-by-case basis and you need to document your update. Also, participants will have the whole voting period to submit critical fixes preventing the game from being launched, played, or finished, but only actual critical fixes will be accepted. The Rules were updated accordingly and are in effect for the upcoming editions already, nothing else was added or changed.
Top comments (0)