I have to admit that’s not quite my view … I’ve included my source with my last several IFComp works so people who want to look into the guts of the game can. I enjoy seeing others’ code.
But it brings up two interesting points. There are bigger points to discuss, but I hope these are worth mentioning.
Having the source code available may make easter eggs easier to find. This may artificially bump up people’s estimation of the game, because they can find something that was otherwise obscured. So the source code files would act as feelies, in a way.
On the other hand, it may allow a programmer a mulligan for something they meant to put in but forgot, and it may also allow someone to say “Hey! Clean up this bug!” just by looking at the source. So then the entrant knows what to fix, and people following the repo will know it is fixed and be able to replay the game. This may give an advantage (unfair or otherwise) to those who include the source.
I feel very strongly that, while competitions should have objective end rankings based on scores etc., they should also help people shake out bugs they and their testers did not have the energy to find, so I’m all for including source. But others may feel differently.
(Note: if you want to have source control AND easter eggs, you could simply make an “Easter Eggs” extension you do not commit to source control. Or have one you branch to an extension you choose not to push until AFTER the competition. You can use different .gitignore for different branches, if using git.)
Can I make three observations based (primarily) on the above discussions:
You should be able to play the game from beginning to end using text entry from the keyboard alone. Any other form of input using arrow keys on the keyboard, mouse, joystick, screen taps and so on, should be allowed, providing they are an alternative (or shortcut) to the keyboard entry. A short numeric or alphabetic menu for disambiguation or conversation trees should be discouraged, but permitted, providing it is used sparingly.
No one has made a distinction between the source code and the executable (or data file) in source code repositories. I think the source code should be kept private until submissions close (or maybe judging closes), but the executable (or data file) may be made available to testers for testing purposes.
I don’t think a walkthrough or solution should be provided until judging closes, but hints are permissible.
Finally, a question: Is it permissible to do bug fixes during the judging phase?
Registration is essentially an expression of interest. It is equivalent to the ‘intent’ used for IFComp. It basically means you intend to make a submission, but there is no guarantee that you will actually finish the game and make that final submission. It has two advantages:
Psychological. The organisers and the participants can gauge the level of interest. It’s a great feeling to see those registration numbers increase in the early days of the competition. People feel encouraged and excited to be a part of the competition. If the registrations are 0, then you feel like you’re the only one participating.
Practical. The organiser can send emails to the registered participants to notify them of rule changes, send them a reminder that the closing date is coming up and so on. You can’t do that if you don’t have registrations.
Submission is when you submit your entry. I don’t think you need to be registered to make a submission, but I’m not sure about that.
When you make a submission, itch.io allows the organiser to provide a form where you can fill out any details pertinant to the game. You could, for example, provide questions related to authoring system used, development time, estimated playing time, genre and so on. IFComp has something similar. The answers to these questions appear on the game’s submission page, so they can help a player determine which games they want to play and judge. Give some thought to this beforehand.
Both registrations and submissions automatically close at the end of the submission period and the judging period starts automatically.
One other thing to keep in mind is the rating categories. You can specify any number of categories for the ratings. Try to make these as objective as possible. Consider things like spelling/grammar/punctuation/capitalisation, plot/story, originality, vocabulary/responses to unexpected input, graphics (if appropriate), fun/enjoyment, PUZZLES! Give some thought to these and make the categories known to authors on the competition page, so that authors know what they need to address to get the best result for their game. The winner can be based on all these categories or only one (or maybe some combination of categories, I’m not sure about that).
One other thing. Make sure you specify the time zone when giving the start and end dates and times in any notifications. itch.io will present these to users as local time. So if the closing time for submissions is midnight on 31 July 2021 UK time, that will be shown to me as 10 a.m. 1 August 2021.
IFComp intents make life much easier for the organizer. The organizer can start doing the behind-the-scenes scutwork well ahead of the submission deadline – setting up spreadsheets, packaging up games, creating the voting forms. They don’t have all the data needed for launch, but they do know what data they don’t have. The scope of work can’t unexpectedly triple in the last twelve hours of submission time, and the surprises (there are always surprises) are much more likely to be visible earlier.
When you’re running an event that hits 80-100 games, this is really pretty important.
(Of course, ParserComp almost certainly won’t be that large. So you don’t have to consider this as a big issue.)
I don’t think menu-based conversations should be discouraged, as it is quite normal in parser games, which uses “Talk to character” instead of the ASK/TELL method. I actually prefer the “Talk to character”-method over the ASK/TELL method.
I don’t think it’s quite ‘normal’. Maybe this is an Inform 7 thing. I’ve played hundreds of games and I can only recall two that used menu-based conversations. One was written with SUDS and the other was written with Inform 7. In both cases, the menu-based conversation detracted from the game, but that was the author’s choice.
Personally, I use TALK to talk about nothing in particular and ASK to ask for further information about anything of interest.
This is quite interesting. Most interactive fiction comps on itch.io have several categories you can rate, but the winner is usually based on the category “Overall”. It could actually be fun if scores were calculated from the sum of all relevant categories.instead. Categories like “Graphics” should not influence who wins, as games without graphics would then have a disadvantage.
For parser games, the categories could perhaps be something like:
Puzzles (I guess most entries will have puzzles)
Atmosphere (some may focus on writing, others on graphics or sound)
Emotional impact (funny, sad, thrilling etc.)
Overall [calculated from the categories above]
I thought about proposing the category “Parser” but that would be unfair to those who choose to go with a two-word parser instead of e.g. Inform.
I like the idea of ratings being divided into categories to focus on the strengths/weaknesses of entries. I don’t, however, like the idea of an “Overall” rating calculated from the other categories and determining the winner. “Best in Contest” (or something to that effect) should be awarded based on a separate category (Awesomeness) that reflects the completely subjective playing experience of the judge. Many great games have a certain je-ne-sais-quoi that lifts them above narrower categories like “Puzzles”, “Writing”, etc…
It is of course a matter of taste, which type of conversation the player likes. I agree, that if we include the thousands of old text adventures from the 80s, conversation menus are not normal. I should have said “nowadays”. If we look at e.g. IFcomp, there are several parser entries each year nowadays with conversation menus. I just skimmed IFcomp 2020 briefly, and saw both a couple of Inform games (probably more) and an ADRIFT game.
It is my impression that conversation menus are often not part of the default library in parser authoring tools, so many don’t know how to create conversation menus, while others simply prefer the Ask/Tell-system.
I guess you are right that this would be more fair than calculating the winner from several categories. What you propose also seems to be the norm, at least for EctoComp and Adventuron competitions on itch.io. I thought it could be fun for a change that the winner was based on all categories, but I understand why most will prefer what your propose instead.
I don’t see any problem with having source code available. The competition isn’t judging who plays, but who writes. If you write a great game and every single person who plays it cheats, that shouldn’t disqualify the game.
In a broader sense, having spent a lot of time over the last few years trying to advertise my games and source code, my opinion is that even if you threw up your source code on github and spent weeks trying as hard as you can to get people to look at it, you might possibly get 4-5 views total.
This worries me. I’d probably bail out of judging as a result. A walk through is a lot easier for authors to provide than hints, especially in game hints. Without adequate hinting I’m out as a judge. I tend to have huge difficulties judging IFComp parser games without a walkthrough or sufficiently detailed hints.
A walkthrough existing doesn’t force judges to use it, but the lack of a walkthrough certainly means no-one can.
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. Of course you can specify some guidelines for what you want to encourage/discourage, but trying to make rulings up front is probably not worth the hassle and debates it might cause.
