This, I suspect, may be the one item that needs discussion and a firm decision (which will almost certainly not please everyone, but I will try).
Typical rule of most IF competitions is that the game you are entering must not have been released and/or made publicly available prior to the competition.
Seemingly a straight forward enough criteria, how strictly is this typically applied? For example, if an author is using GitHub or one of the many alternatives and a limited number of people have been assisting them in some form (be it coding, testing etc) then is this still allowed or typically not allowed?
I’ll start. My intention, unless the discussion that follows here sways me (and it may, that’s the beauty of discussion ), is to allow games to be entered into ParserComp which have been (are being) developed in a Hub somewhere providing it hasn’t been announced and/or promoted in forums etc.
So if you have a small group of trusted people who are working with you, even if the Hub is open, then my current view is that this is fine.
My rationale is that in reality the odds of a game being developed in this way artificially inflating a games chances of winning are minimal. In reality, it likely won’t “boost” or “promote” a game unfairly providing it hasn’t been promoted or regularly discussed in a forum.
That said, let me have your thoughts on this now so we hear from all sides.
The IFComp had been quite strict. All access to the story file for beta testing must be restricted. You can make a public request for beta testing here, and even discuss it a little, but if you upload your entry as an attachment to a public post then you would be disqualified.
I can see arguments for and against this. Other competitions could allow for public beta testing, but I imagine they would want to still have some criteria to distinguish beta testing and public release. And in particular they’d want to think about authors attempting to game the system, through eternal betas and the like.
There’s always a risk, for sure. I’m going to take the position that people entering are moral folk that won’t use any dodgy tactics. If it happens and they get caught then that can be managed, if it happens and they don’t get caught then is unfortunate but I like to believe that won’t happen.
At the risk of being a little egotistical here I’ve got a longer term plan in mind, so I’m going to assume that ParserComp 2021 goes sufficiently well that I’m not removed via pitch forks , this being the case I want to keep the first comp as flexible as possible and then ongoing we may need to implement rules that insist on restricted development hubs etc
Basically what you’ve written is spot on, asking for assistance is fine, general opinion gathering is fine, specifically stating “I’m writing a game about X for ParserComp and it’s going to be awesome, here’s a link to the development hub so you can try it out” is obviously a big no-no.
Then again what I’ve just written is public beta testing isn’t it. Ok I see the challenge.
So it shouldn’t be too egregious, the author can ask for testers but they need to actually exchange links offline ideally. Pinging a link into IntFiction or Facebook or Discord to the Hub for people to try the game is running the risk of essentially giving people a playable demo.
I have always been confused by entries into Intro Comp. Intro Comp is specifically for game fragments, partial games, ideas and the resulting feedback. However, any entry Into Comp is a disqualifier intro other competitions.
IMHO, that makes an entry into Intro Comp useless if you have any aspirations of developing a game for entry into another comp.
It is not a general rule, but every comp I have looked into strictly prohibits an entry into any other comp or any public release beyond a restricted access beta.
Gotcha. I honestly don’t feel that a public beta will skew results. But in return I’ll be lookng for some common sense ie asking for a few testers = good, saying “hey everyone, come and test drive my entry into ParserComp” = not good.
As for a game that’s already been entered into IntroComp, I think unfortunately yeah I will need to align with that. I know you probably won’t agree but as I say I can’t please everyone, I think just generally if a game has been through a competition already then by default it can’t enter into ParserComp.
It is not a problem. I am planning to enter my small i6 game into IntroComp. Mainly for the feedback. I have let a couple of beta testers give it a try and they seem to do a lot of head scratching. I didn’t think it was so bad but I guess I have inside information. It will be nice to get feedback from serious game players.
I will have to make sure that one of the TADS games is ready for entry.
You’re right! This is the pertinent part of Spring Thing’s rules:
Can I submit a revised version of a previously released game?
The general idea behind the “new” guideline is that games should feel like a debut: they should have mostly new content. An extensively fleshed out version of a game prototyped in IntroComp or Ludum Dare would probably be cool; a minor improvement to an already existing game, not so much.
Well spotted and thank you for raising! That clarifies nicely.
I think we can safely align ParserComp to that. Like my thoughts on the “open beta testing” there will need to be an element of common sense on both sides.
Thanks for checking and providing that, much appreciated.
It makes sense to mirror that then.
There’s an element of common sense and fair play, much like how I’m thinking to approach the open beta test. And again like that I’m happy to trust in the process and the participant not to take liberties with it.
I think it may be unwise as the organizer to say that you “trust in the process.” It’s not so much about whether you have faith in humanity, but about defending the competition to entrants (or potential entrants) who think that the competition won’t be fair to them.
“Oh, I couldn’t possibly beat Game X by Author Y, because Game X has been in public beta for months now and has built up a fan base. As a result, the only way to win this competition is to do exactly as Author Y did. In fact, this whole competition is nothing more than a marketing competition for released games in public beta. Submitting the best game certainly helps you build up a fan base, but it’s neither necessary nor sufficient to win.”
In this case, nobody’s directly accusing Author Y of “cheating” or “dodgy tactics.” They’re “accusing” Author Y of doing the honest, hard work of building up a fan base! They’re saying the spirit of the competition is that the best game should win, but that the rules aren’t designed properly to ensure that the best game actually does win.
As I see this problem, here’s the spectrum of release states:
never released to anyone
offline beta
private beta and the author can name the testers (note that the list can be long and the author can name all of intfiction users there just for giggles)
semi-public release where the link is accessible but hidden (poorly)
patreon-like model, gated enough so the author can still name the people who got the beta copy
public release
As the organizer, you see only the public release and you can verify a semi-public one if you get the link early. There can be a thousand people in a discord server somewhere and you won’t have a clue.
On the hub releases, they are definitely public. A prominent author can have hundreds of random people subscribed to their new repository RSS feed. They don’t get a memo not to share the link, so when one of the followers just blabs about it here, you have to strike the author for that.
I think you do have to consider any kind of Hub release as a fully public release.
The danger for well-known authors is as Oreolek described above. You could perhaps argue that a first-time or otherwise unknown author would be lost in the noise and nobody would actually find it except the few they intended to ask to collaborate or test – but firstly, while a someone might not be known as an IF author that doesn’t mean they don’t have people following them for other reasons, who might find it and spread it around. And secondly, the Hubs are available to search (both on the site itself and via general search engines), and anyone in general may stumble across the work-in-progress while looking for related concepts.
For the people who want to collaborate and still enter, this is unfortunate; but there are other options available, even if these are less attractive (such as purchasing a private account, or self-hosting a repository and doing without a lot of the collaborative features provided by the Hubs).
Are random people (or random members of existing fanbases) stumbling across an unannounced project sufficient to distort potential review and/or judging? That one, I’m less sure about. My first inclination would be that they wouldn’t matter – provided that none of these influenced people submit a review for the game in question, or recuse themselves from judging. However I imagine that since we’re a relatively small community, there could be considerable overlap between the groups of people interested in submitting a review or judging a story and those interested in following past authors of stories to learn about new works, which may complicate matters, and make it harder to fairly judge works from popular authors, ironically. (Still, the same can occur even without “public release”, with a large enough group of beta testers also drawn from the same small community pool.)
I’ve never personally been involved in any of the competitions (in any capacity), so I don’t really have any way to judge what might be typical or reasonable in that context, or how serious it might be.
Very good point, thanks for the input. If the availability of a public beta is essentially drumming up votes then that’s not in the interest of fairness.
), is to allow games to be entered into ParserComp which have been (are being) developed in a Hub somewhere providing it hasn’t been announced and/or promoted in forums etc.
