ParserComp 2021 - The Rules for Participants (Draft; may change!)

[rovarsson]

I wholeheartedly agree. Sophisticated in-game hints are preferable (even worth extra points), but a minimal walkthrough would alleviate frustration and make sure judges can see at least most of the game.

[Warrigal (Garry Francis)]

@robinjohnson

The latter would completely eliminate my and others’ javascript games.

We certainly don’t want that, do we? In your case, the source and the executable are the same. Would you want to make it available in a public source code repository prior to the competition? That seems to be the crux of the discussion. If not, then it’s not a problem.

[Adam_S (Adam Sommerfield)]

@DougOrleans

Rather than make rules for disqualifying a game based on not being “parsery” enough, I think it’s better to just leave it up to the voters, who can decide for themselves whether, how, and how much to factor “parseriness” into their ratings.

Firstly, I like “parsery”, I may use that in the final rules draft

So, I think the short answer is that whilst what defines a Parser game and how far we can stretch the definition is a worthwhile conversation to have, the definition for ParserComp itself needs to be fairly straight and narrow. Again, think Zork, pictures and sounds are allowed, clicking on keywords is allowed providing it isn’t the main mechanism for traversing the game, and SPEAK is fine (for a menu of things to say) but is ideally sitting alongside the more typical ASK and TELL.

Perhaps rather than Zork I should say “think Photopia…”

Adam

[rovarsson]

Maybe I missed it, but has there been any discussion/decision about game length? I’m inclined to say no limits, but then I remember playing World a while back. If something of that size were in ParserComp, I’d use up half the judging time on it. (with walkthrough)

Or might the best suggestion be not to the authors, but to the judges: “Use your time wisely”?

[Adam_S (Adam Sommerfield)]

@rovarsson

has there been any discussion/decision about game length?

I’m happy to accept any length providing its a complete game.

Adam

[Jade]

Amazing work, Adam.

[Adam_S (Adam Sommerfield)]

Thank you, that’s appreciated.

Hopefully will still be the case when then dust settles at the end

Adam

[robinjohnson]

@Warrigal

@robinjohnson

The latter would completely eliminate my and others’ javascript games.

We certainly don’t want that, do we? In your case, the source and the executable are the same. Would you want to make it available in a public source code repository prior to the competition? That seems to be the crux of the discussion. If not, then it’s not a problem.

The bit I was responding to was “or maybe until judging closes”.

I don’t want to make my source code public before the comp, but if someone’s using a public github repo because that’s what you can get for free, and not publicising it, I don’t see a reason to hold it against them. If it turns out to be a problem this year, the rules can always be changed next year.

[FriendOfFred]

@robinjohnson

I don’t want to make my source code public before the comp, but if someone’s using a public github repo because that’s what you can get for free, and not public ising it, I don’t see a reason to hold it against them.

Private GitHub repos are free. (Unless you need the Teams features, which an individual writing an IF game probably doesn’t?) However, I agree that releasing the source code concurrently with the game, even to beta testers, is no problem at all. It’s up to the author whether it’s acceptable for players to “cheat.”

[fos1]

I am all for source code along with a game’s release. (That is one of the meanings of my user name in most places: Free Open Source / Far Out Science)

However, I am not so sure source code should be available during a competition.

[jkj_yuio]

Sorry, i don’t understand this source code thing. Are we talking rule change to mandate the availability of source code?

As i understood it from the draft rules there are no source code requirements, only the ability to get a copy of the game.

If authors wish to give source code, it’s up to them. And when they want to give source code it’s up to them. And if they don’t want to give source code, but instead walkthroughs or hints or even nothing at all, that’s also up to them.

of course, if that means impeding judges, then that’s the way it is, and may well reflect the score.

Or have i got the wrong end of the stick?

[mathbrush (Brian Rushton)]

The gist I’m getting is that very early on in the conversation, someone said they’d love to have a competition where they can finally program their code in a public github repository, since IFComp doesn’t allow it.

So allowing github development was put in as something allowed.

Then others complained that this would be a form of advertising.

Later on, someone said it shouldn’t even be allowed during the comp, since seeing source code is cheating.

Now I think people are pushing back on that a bit and saying that releasing your source code is okay. This still hasn’t gotten back to the original point of whether or not a public repository for development is okay. It’s almost certainly going to have to come down to a decision by @Adam_S, and I’m not sure there’s a solution that will satisfy everyone.

[Adam_S (Adam Sommerfield)]

I think I can help bring the discussion to a close at least in terms of ParserComp specifically, the discussion has been great and I’ve appreciated the time people have taken but I can also see a few topics going back and forth. So…

When I write the final draft of the rules it will include the following…

1. Walkthroughs, guides, hints and any other support documentation is not mandatory and submissions of game only are accepted. However please be aware that these documents are extremely useful to players/judges/voters, many people have expressed the view that if these additional support documents are not provided then they are less willing to play and judge/vote on games. This is entirely their prerogative. As such we very much recommend that you consider making these support documents available as part of your submission.

2. You are not required to submit source code along with your game, but may do so if you wish.

I’m aiming to release the updated rules by the end of this week.

Thanks!

Adam

[Stian]

I really appreciate the way you are handling this, Adam: Listening and decisive. I’m sure it will be an excellent ParserComp!

[Adam_S (Adam Sommerfield)]

Thank you Stian, that means a lot, very much appreciated.

Adam

[aschultz]

@Adam_S

I’m aiming to release the updated rules by the end of this week.

Thanks!

While there’s no rush, it’s good to have the rules finalized as soon as possible. I suppose the details can be hashed out later.

I just want to make sure I’m 1. not doing anything out of line and 2. not missing anything I could’ve done. I suspect other people’s motivations for asking questions were similar. This whole topic has been an interesting read, the sort that encourages and motivates me to visit this site more often. So thanks, everybody.

[Adam_S (Adam Sommerfield)]

@aschultz

I just want to make sure I’m 1. not doing anything out of line and 2. not missing anything I could’ve done.

On that front don’t panic Essentially the rules listed here hold water but just need rewriting to make clearer, then we have additional rules to add in such as the walk-through and source code ones.

In the background I’ve also actually created an email address specific for the competition, created an itch.io account, created the competition page (although at this stage it needs populating with the rules etc) and also created an accompanying YouTube channel so I can do some video content along with the written content here and elsewhere.

Should be a fun week!

Adam

[Adam_S (Adam Sommerfield)]

Updated (Final Draft) rules are now available in this new post:

ParserComp 2021 - The Rules (Final Draft)

To be eligible for participation in ParserComp your game must have text input, a text parser system and text output as the primary mechanism of control. 1.1 Clicking on key words is permitted, again providing the text input/output parser is the primary method of control and the entire game cannot be traversed by clicking on words. 1.2 Graphics are permitted i.e location, NPC, items etc 1.3 Sound effects are permitted. 1.4 Voice input and output are permitted to aid and support players …

[The_Pixie]

With regards to source material and repositories, it looks like you have decided it must not be publicly available before hand. Is that right?

I have a game under development, but it is already on GitHub, and anyone can look at the source code right now. Is the game therefore disqualified (assuming I do not move it, and is not that close to completion)?

[fos1]

Why is a github repository necessary for the development of a parser game? I have never been clear on this issue.

I do all of my development work on my personal computer and store backups on fobs. Git will run on personal computers as well.

Just curious.