What defines a "never previously released game"?

See, and again as @dfabulich says above, it’s the “building up of support & fans” for a game that I want to avoid. I’ve got no issue with a beta being publicly available so as to encourage testing but if - even inadvertently - it builds up votes then this would be unfair.

Two related questions then…

  1. Can beta testers typically also vote? If no then this would reduce the risk (it wouldn’t eliminate it but would reduce it). Appreciate they’re invisible so it would be hard to manage/enforce.

  2. Spring Thing allows games from IntroComp to be submitted, but how is this different to the public beta situation? In essence it can’t be, can it?


1 Like

These are all great points folks, thanks for your inputs on this, all appreciated and I will soak these all up.


It’s not quite the same, at least according to my interpretation from the quote above.

A game typically remains largely unchanged between a public beta and a release; perhaps with some scenes reworded a little or bugs in corner cases squashed, but still essentially the same story and gameplay.

What the Spring Thing quote was saying (as I understand it) is that such a game would not be eligible, it’s more for the sort of thing where Narbacular Drop was submitted to a previous competition but then Portal was entered into this one – the same authors and the same core concept, but a vastly different actual game.

1 Like

I must say that I’m enjoying the thoughtful discussion from you people.

The idea behind IntroComp is to encourage authors to provide the start of a game or a fragment of a game, somewhat like submitting chapter 1 of a proposed 10 or 20 chapter book. The author is then expected to finish the full game within 12 months in order to earn any prizes. (Or something like that.)

There aren’t too many IntroComp entries that actually end up as a full-blown game. In order to remove any arguments over whether the IntroComp entry changed significantly enough for the ParserComp entry, I tend to think that they should not be eligible for entry.

The rule related to previous release should be something along the lines of “The game has not previously been advertised, promoted or released to the general public.”

The normal process would be something like this:

  • A request for beta testers is placed on intfiction.org or other social media.
  • Potential beta testers send the author a personal message or express their interest and the author sends them a personal message.
  • The author sends beta testers a link to download the game and a password.
  • The author tells beta testers that they are sworn to secrecy and must not discuss the game in public or pass the link and password to anyone else.

I haven’t used GitHub, GitLab or any other public repositories for saving source code (yet), but I’m told that projects can be made private. A private project is certainly not a public release. A public project is questionable, even if it hasn’t been promoted in any way.


Then why does Spring Thing allow entries from Intro Comp? Why would the same not be possible with Parser Comp? That needs clarification.

I do sometimes idly wonder how significant the “it might affect the rankings” issue is in practice for things like IFComp…I can see the argument, but I suspect there are other factors which have nearly as much effect, like “the creator has a fan base” or “is it a 1:45-long humorous parser game (or one with a parser-like world model) with good puzzles?” I’ve definitely seen fan-base affect voting in other, non-IF jams, so I can see that going either way.

But that aside, I’ve always thought the “never previously released” rule was interesting precisely because it is a little arbitrary and maybe not something you’d expect, and it’s cheap to follow if you know the rule exists. So it feels like it comes as close to being a pure “good citizenship” test as you can expect to get. This question asks: are you the kind of person who’s going to try to make the organizer’s lives easier by actually reading the rules and trying to follow them even if you don’t agree with them, or are you the kind of oblivious person who’s going to go, oh, I’m a decent human being, obviously I’m not going to mistakenly do something against the rules? And…if I were an organizer I feel like I’d be OK with saying that actually reading the rules is a minimum requirement for entry.

But you should know that it does seem to disqualify some people from IFComp every year who just weren’t paying attention and weren’t intentionally breaking the rules. And that definitely puts some people off and deters them from coming back. For instance, just before 59 minutes in this Script Lock podcast episode you have two professional writers talking about how one of them disqualified “the best Twine she ever wrote” by doing the obvious thing of asking for feedback on a forum devoted to that purpose, and both of them pointing out how much it sucks when that happens to you and how these rules are from the stone age and are long overdue to have been changed.

So…thought I should point out that you’re probably going to get a biased response in this forum because some of the people who would be put off by the rule have been…well, put off, and don’t post here.

So if you don’t have the rule, how much is it going to bias your results, and how much are the results of a competition somewhat arbitrary anyway (you probably don’t have enough voters to smooth out the random fluctuations, if nothing else), and how high are the stakes if you get robbed of your ParserComp victory by someone who has been maliciously building a fan base for their story ahead of time? :slight_smile:


I was always under the impression that the ‘not previously published’ rule was to encourage new games. Discussion of the game prior to publication is probably a different issue.

It’s good to be discussing these things now, so that we get an equitable outcome. To be quite honest, I really don’t care what that outcome is, so long as we get some great new games.


I’m really appreciating the views and inputs, it’s brilliant, very much appreciated.

I’ll probably run a poll here, Facebook, Twitter, Reddit etc to take a general tally and then make a decision using the viewpoints here to support the process.

Now, it’s an obvious statement but I feel its worth making, clearly whichever way we go there will be strong opinions who feel it should have gone the other way. As I’ve said already (and again it’s stating the obvious) I can’t please everyone. In the end I’ll take everything into account and make a decision.


Adam :slightly_smiling_face::+1:


Perhaps it’s worth enumerating the harms the competition wishes to avoid. To declare those, and then to define rules to avoid them.

There is a difference between a previously-released game and one which has been developed in a public fashion over the timescale of the competition.

It is evident to me, perhaps not to everyone, that a public Git repository is an excellent platform for verifying that the development did indeed occur over the competition timescale and did not begin with a massive dump of code from a previous piece of work.


So, here’s how PyWeek deals with this issue: Games are to be written from scratch.

Just to be clear, I’m not saying this is the answer to the ‘public release’ question, only an example of how to deal with it.

1 Like

That’s not the same rule and it can be checked only for games in Python, where you can see the code. Most parser games are compiled, not interpreted.

1 Like

IF competitions are not necessarily game jams (though a few are?). Dusting off an old WIP and finishing it up is generally fine. AFAICT the rule is about the potential effects on judging: not wanting to have people jump in to rate just a single game that they already know they like…

Sure. But how does that affect the “no prior publication” rule? Unless you’re expecting organizers to monitor your repository throughout the competition (and who has time for that?) couldn’t your purpose be achieved just as well by a private repository that is made public when the judging period starts? IIRC all the major git hosting platforms allow private repositories for free now…

(also, how many IF authors use version control?)


I don’t know if it’s written anywhere, but one of the IFComp personnel at one time explained to me that “unreleased” means “the author knows exactly which specific individuals have access to the game files” - ostensibly to credit them as testers.

1 Like

Yeah, I guess I’m conflating the two issues.

What does it mean to release on GitHub?

I have a number of games in a public repository on GitHub at various stages in development (and most unlikely to get beyond that). But none of them are released.

The difference is that the raw files are public available, but they are not packaged in a way for them to be readily played. There are flags set to help debugging etc. so the play will be different.

It is certainly possible for anyone to get the files from the repository, and assemble them himself to play the game. Nevertheless, I would not consider that to be released. Hopefully compentitions would not either…?


Some do, some don’t, there are legitimate reasons why in both cases.

I’ll be writing up the high level rules for ParserComp very soon, I won’t say any more at the moment. :slightly_smiling_face: