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

[nilsf (Nils Fagerburg)]

@Adam_S

1.1 At no stage, optional or otherwise, should there be a requirment for peripherals such as joypad, joystick, mouse or other controller to interact with your game.

How can a a requirement be optional?

[Adam_S (Adam Sommerfield)]

Thanks for taking the time to review and feedback

As written elsewhere I swear as I get older my spelling gets worse!! I did A Level English if you can believe that!

Re’ the point about submission and registration, I thought about a separate deadline and put a week or month between them but then wondered what that would actually do? I would know ahead of submissions deadline whether we had 5 games or 50, but then what happens next is exactly the same I imagine. Again if I’m missing something then yeah let me know and I’ll rethink it.

Cheers

Adam

[Adam_S (Adam Sommerfield)]

@nilsf

@Adam_S

1.1 At no stage, optional or otherwise, should there be a requirment for peripherals such as joypad, joystick, mouse or other controller to interact with your game.

How can a a requirement be optional?

There can’t, good spot, thanks! One for when I write the final version

Adam

[McTavish (Ade)]

@Adam_S

1.1 At no stage, optional or otherwise, should there be a requirment for peripherals such as joypad, joystick, mouse or other controller to interact with your game

Pretty excited about the comp, but I do disagree with this.

Parser based interaction has come a long way. Having some clicking (i.e. for conversation links) is pretty standard in a lot of modern parser games. What this is saying isn’t ‘ParserComp’ which should allow at least some innovation in how parser developed games interact with the audience, but instead it’s ‘Super Retro-ParserComp’ which I think would be a mistake if we want to encourage a wider audience.

Ade

[Adam_S (Adam Sommerfield)]

@McTavish

Parser based interaction has come a long way. Having some clicking (i.e. for conversation links) is pretty standard in a lot of modern parser games.

It’s a very good conversation to have. I wasn’t sure how best to write this rule and perhaps that’s why it reads as it does.

My thoughts. We have IFComp which has a very wide remit these days, so to my mind ParserComp really does need to keep it tight in terms of what it is & does. That might actually mean less experimentation which I agree would be a shame but then perhaps those boundary pushing works would be better suited to IFComp? Again, that’s just where my head is at the moment.

That said, clicking on key words and have them do something is entirely ok and I did some research to see how common this is as a function (from which I’m happy to allow this) but it needs to be there in addition to the keyboard text entry and onscreen text output, rather than it being possible to traverse the whole game by clicking on words.

But absolutely yes on top of the base of “using keyboard to enter what you want to do, and the computer gives you a text description in return” I’m happy for people to get creative - what this would be I have no idea, but that’s the beauty of boundary pushing. If the answer is “they can’t because the rule isn’t really allowing it” then I’d refer back to the earlier point that IFComp may be the better option.

Thanks for the support and the feedback!

Adam

[fos1]

@Adam_S

“using keyboard to enter what you want to do, and the computer gives you a text description in return”

To me, this is important for parser based IF.

[Adam_S (Adam Sommerfield)]

Me too, and again I think that’s why we need to be careful and keep things fairly tight for ParserComp. I totally understand that “parsing” in 2021 could mean interpretating a series of mouse clicks but that’s not really what I’m looking to do here. As I said right at the start, think Zork with pictures and sounds and you’re there; clicking on key words on top of that is fine but a game where I can play all the way through with a mouse is more IFComp than ParserComp at time of writing.

Adam

[caleb (Caleb Wilson)]

Hmm, something clicked for me when tundish pointed out this isn’t a game jam. I guess the competitions I’ve entered and enjoyed could all be considered game jams, with their shorter development periods and various constraints? In any case it sounds like this might not be a good thing to enter for someone like me who just has a month or so to devote to a game and doesn’t really want to compete with games that could have six months or more of dev time. I still look forward to playing the games though!

[Adam_S (Adam Sommerfield)]

@caleb

it sounds like this might not be a good thing to enter for someone like me who just has a month or so to devote to a game and doesn’t really want to compete with games that could have six months or more of dev time. I still look forward to playing the games though!

No problem, there’s plenty of great Jams around now too so maybe they would be a better fit. No problem at all!

If people can find the time to play and cast their votes that would be great.

Adam

[Denk (Kenneth Pedersen)]

@Adam_S

I totally understand that “parsing” in 2021 could mean interpretating a series of mouse clicks but that’s not really what I’m looking to do here.

As this is a parser comp, the submitted games should definitely be controlled by typing commands. However, when it comes to conversation with NPCs, it is very common that when you talk to a character, you get a numbered menu. You can then type “1” or "2 or…etc…

Typing a number isn’t really parsing either, but I guess that should be allowed. But if the conversation interface hasn’t been developed for typing numbers during conversation yet, only mouse clicks, then we may be disqualifying games, which fundamentally are parser games though the conversations require mouse clicks at the moment instead of hitting a number on the keyboard.

Whatever you decide, I respect it, since you can’t make everyone happy. But I just wanted to mention this in case you haven’t thought about it. One of the best parser games out there, Worldsmith by McTavish, is truly a parser game even though you during conversations must click on the text you want to say. Such an interface could be further developed to allow the user to type the number of the sentence they want to say. But typing menu numbers and hitting return hasn’t much to do with a parser either.

This reminds me, that there are CYOAs out there, made with parser engines, where you simply type numbers or letters given in menus. I don’t think these qualify as parser games either. I think(?) your “rule 1” excludes those, but I am not completely sure if menus within games are allowed, as long as they are not the primary mechanism of control?

[rovarsson]

A few weeks ago I played Gateway 2. It’s a hybrid graphic/text adventure. Using the mouse is very handy in navigating conversations, manipulating locks and keypads, etc… You can also point and click on the graphics to EXAMINE and TAKE. However, it is possible to play the entire game without touching the mouse. It’s a convenient option but not necessary for completing the game. I think this should be the case for any entry in ParserComp.

[Adam_S (Adam Sommerfield)]

@Denk
Thanks for the thoughtful post and making some good points.

Whilst I wanted to avoid a hard list of “this is ok” and “this is not ok” I suspect I may need to do something. And it’s worth mentioning now that some of them will likely end up being slightly contradictory.

Again, starting with the primary interface being text input from a keyboard, I would completey accept the conversation system that allows selection of 1, 2 or 3 etc

For example - Adam Cadre uses this in Photopia. Photopia would completely be eligible for ParserComp. But that’s because everything else is type-in, Adam just replaced the ASK & TELL commands with SPEAK which resulted in a list of things to say. If Photopia was “Select your next action from 1, 2, 3, 4 etc” and nothing else then this isn’t really Parser IF. There’s an engine behind it that’s reading the number selected but it’s not parsing a sentence etc

Hope that makes sense.

Adam

[Adam_S (Adam Sommerfield)]

@rovarsson

It’s a convenient option but not necessary for completing the game. I think this should be the case for any entry in ParserComp.

That’s a very good summary.

[aschultz]

Wow. Good to see such a busy topic.

For the Open Test Repository, do we want to obscure the source code? Because the source code would potentially spoil the game.

For IFComp I’ve always kept the source hidden until the competition started.

Also, are sequels to a previous work okay?

[Adam_S (Adam Sommerfield)]

@aschultz

Also, are sequels to a previous work okay?

Yes, they are indeed

Adam

[Adam_S (Adam Sommerfield)]

@aschultz

For the Open Test Repository, do we want to obscure the source code? Because the source code would potentially spoil the game.

I’m not overly concerned about this myself, is there something specific it avoids (in terms of causing issues during a competition)?

Thanks
Adam

[aschultz]

@Adam_S

I’m not overly concerned about this myself, is there something specific it avoids (in terms of causing issues during a competition)?

Well it wouldn’t ruin anything. I recognize this post is long, but that doesn’t mean it’s a sticking point for me. I just think it’s worth discussing and hasn’t been discussed. Because using source control for a project is good, and it should be encouraged, but uncovering it before a comp starts has real risks.

So just to clarify my intentions:

I think a rule saying “keep any source code/source control repo hidden until the comp starts, then open it to the public if you want” is best, and I’d like it written out. And I think people who are new to source control would appreciate it.

Because of the very readable nature of Inform 7 in particular, the source code could quickly provides an advanced viewing of the game and mechanics for people who are curious enough to poke around. Especially if you have a tests file in your repo saying “test full walkthrough with A/B/C”.

That’s a potential problem for the organizer, because

1. in general, a public repo of source code could be seen as bad-faith back-door promotion/previewing, which is against the actual rules, or the spirit of the competition. Even regular commits saying “I added this neat new feature” might cross the line in spirit.
2. in my case, I’d prefer to keep my source code in a private repository until the comp, as I would rather people see it for the first time and not be able to cheat up on solving/spoiling the game. Especially since I include a walkthrough file as part of the repository. (Also, trolls may be able to spot bugs and not report them, making a troll review easier. That’s not something I worry too much about, or want to, but it is possible.)

Once the comp starts, I’d really like my repo to be public, so 1) people can quickly report bugs (or see if they’ve been reported,) and I can respond to them, whether or not in-comp updates are allowed and 2) give people some idea of what I can/can’t fix and to see my post-comp releases.

That said, if someone forgets to hide their source code, I don’t think they should be punished for it. Just, it should be strongly recommended to keep repos/source code under wraps until the comp starts, and I think most contestants would be glad that rule is in place. It’d be more for guidance than punishment.

ETA: so I think a rule “It is strongly recommended that people who use source control keep their source private until the works are distributed. This will prevent leaks as well as hard feelings and accusations of pre-promotion. If you use source control and don’t know how to make a repo private, ask here or on the hosting website. If you have a current project you’d like to fit into ParserComp, and it is in a public repo, but you want to make it private, that’s okay.” would work. This is a bit wordy, but I hope it is something you can work with.

[Adam_S (Adam Sommerfield)]

Ok yes, that makes sense, thanks

I could write it in as a recommendation but with the caveat that if they choose not to then they do so at the risk of source code being copied etc

Thanks

Adam

[aschultz]

@Adam_S

I could write it in as a recommendation but with the caveat that if they choose not to then they do so at the risk of source code being copied etc

Wow, thanks again for the quick reply! That sounds good and succinct and clear and non-punitive. I like it a lot.

[fos1]

I too believe it would be improper for game source prior to the end of the judging period of comp. It is basically the ultimate walk through and the perfect spoiler. It just lets the cat out of the bag early.