Global rule debates, what engines to allow

[Nepster]

One comment on the layout of the first post of a newly started Lemmings contest:
The general rules (which are in general not terribly interesting) are extremely prominent at the moment, especially as they take up the first half of such a post. However the most important part of the post is the theme/design goal. So I would like to suggest to swap the general rules with the contest-specific information in the future. Perhaps one could even hide the general rules inside a spoiler-tag?

[namida]

I would prefer to keep them at the start, but putting them inside a collapsible spoiler tag sounds like a good idea.

[namida]

Okay so, I think it's seeming like allowing Lix is a good idea - it's not really that hard to get used to it (as someone who's barely used Lix before, I had little trouble handling the Lix entry in the latest contest).

Something I would like further input on is the rules around updating levels during the playing phase. As most of you are probably aware, the previous rule was that once entries close levels can no longer be updated for the contest. The latest contest, the rules have changed to have certain "update points" - essentially, extra deadlines by which updated versions may be submitted.

Some previous user-run contests have simply allowed as much updating as the entrants like during the playing phase, and it goes without saying that this option has been proposed and considered for these official contests too.

Advantages of doing it this way would include potentially better-quality final entries, as well as more flexibility for those who have trouble meeting set deadlines. Disdvantages would include that people with more spare time would potentially be able to improve their level more, as well as the constant question of whether a level is in its final form which may be a deterrent to playing it earlier on; as well as that people may need to look through the topic to find the newest versions of levels if the entrants post them themself.

I'd like some input on whether to keep this as it currently is; go back to the original "no updates at all" structure; or something else instead. One possible alternative I've considered is allowing updates whenever the entrants feel like it, up to a certain cutoff point after which no further updates can be made. Another option is a hybrid between this and the current method - have a cutoff point up to which the entrants may post updated versions, then after this also have just one further update point using the current structure (submit via PM, and all updates are posted at the same time).

What are your thoughts on how this should be handled, everyone?

[Simon]

I feel like backroute fixes should happen as free-form as possible. Have the entrants post updates to the contest thread, without the indirection via PM. When people fix something in their project, they want it out ASAP.

The host can fish out the most recent versions, and collect them in the summary post.

If necessary, freeze versions once voting starts.

-- Simon

[namida]

I would rather freeze them at least a few days before voting starts, to give people time to play the finalized versions (without worry of further updates appearing) before the voting period. Free-form up until such a deadline is an option that can be considered.

[GigaLem]

Maybe we can make a more major contest or something like the idea i had a few months ago
and possibly the ability to put in more than 1 submission at a time

[Nepster]

I think, a bigger contest makes only sense if there will be more participants than in the contests so far. Otherwise we will likely end up with only two or three entries in each category.

Concerning backroute-fixes during contests, I second Simon's suggestion.

[namida]

Alright, so it seems that unlimited updates is preferred.

How's this sound regarding future structure:

- Creation phase - Keep it exactly as is (ie: levels are submitted privately, and all released at the same time when the next phase starts)
- Playing phase, Part 1 - Up until a certain point, creators are free to post updates whenever they feel nessecary; for the sake of tidiness we may have a seperate "updates" topic which is only for posting updated versions of the levels, seperate from the main playing phase topic.
- Playing phase, Part 2 - After the cutoff point, no further updates are permitted. This is to give people a chance to play the finalized level before voting phase begins. This would be shorter than Part 1 of the playing phase.
- Voting phase - This, like the creation phase, would stay the same way it currently is

One question regarding the playing phase - should we allow further entries during this time, since we're also allowing updates freely? The downside may be that fewer contests would get 3 levels before the end of the creation phase, due to people thinking "well, I'll just submit it during the playing phase so I have more time". Perhaps a compromise could be that the subission may be first made during this, but people must at least express their intent to submit a level before the creation phase closes (with the main question here becoming - what happens if someone were to intend to, but then be unable to, and thus the contest is left with fewer entries than suspected - particularly if this then causes it to not reach the required 3 levels).

[namida]

Someone asked via PM whether I have any preferred naming scheme for updates. Answer is, no, it really doesn't matter - just submit them with whatever filename you keep them under. I only keep the most-recent copy of levels, for which I name them: [author]_[title without spaces].[lvl / ini / txt]; but honestly, it doesn't bother me at all whether you submit them this way or not - it isn't exactly hard for me to rename them, especially with the "Save As" box when downloading it. So - no, there are no rules (or even preferences) about the filenames of your submissions.

[namida]

So, I'd like some further feedback on how to handle the deadlines.

The current structure is:

Initial submissions
Initially, a deadline is set, which is always midnight (UTC) on a specific date, usually about two weeks from when the rules are posted. Entries will never close before this deadline, overriding the rules below.
However, if entries are received close to the deadline, it is extended. If 3 or less entries have been received, entries close one week from the most recent entry. If 4 or more have been received, entries close 72 hours from the most recent entry.
A level being updated (prior to entries closing) also has the same effect - the deadline is extended from the time of updating by one week / 72 hours as applicable.

Updates
Updates (once entries have closed and the playing phase has begun) work more or less the same way as initial submissions.
The one difference is that the deadline extension is 72 hours, regardless of the number of entries.


What I'm wondering is whether this structure should be kept, or whether it should be changed. Possible suggestions (aside from simply staying how it is now):

- During the initial submissions, only extend the deadline in respect to new entries, not to an already-submitted entry being updated.
- Do not extend the initial submission deadline at all. However, keep the extension for updates, so that the end of the updates-allowed part of the playing phase only comes once no more updates are being made.
- Go back to absolute deadlines in all cases. Even if a submission is made one minute before the deadline, don't extend it.

I'm thinking my preference is the first option - keep extending the deadline for initial submission as long as new entries are coming in (not just updates to existing ones), and make no changes to the current rules in regards to deadline for updates during the playing phase. This is because someone updating their levels during the creation phase isn't really an indication that the creation phase is still going; as this could just as easily be done during the update phase (which would extend as long as the authors feel further updates need to be made).

One point also came up - technically, there's no rule stopping someone from submitting a blank or incomplete level during the creation phase, then finishing the level off during the update phase. Obviously, this isn't the intention of how the update phase should be used, but it would technically be allowed. I figure that anyone who uses this kind of loophole in the first place (which I'd think unlikely in this community) would be equally likely to try and loophole any rule that tries to prohibit it, but perhaps a better solution is to allow for someone to simply indicate their intent to submit a level, and allow them up to the end of the update phase to actually submit one (perhaps with a rule that, if they indicate intent but do not submit a level in the end, they're prevented from simply indicating intent for the next few contests (but could still enter if they actually submit a full-fledged level during the creation phase; and it is of course possible that such a rule could be made to only apply to repeat offenders)). One of the reasons why I see some kind of system like this as nessecary is due to the contests only going ahead if 3+ entries are received (and a difference in the number of prizes between whether 3 entries or 4+ entries are received). I feel that if it's simply a matter of "anyone can join in arbitrarily until the update phase ends", then there's a significant risk of people not submitting their levels by the end of the creation phase, which would skew the number of contests that actually go ahead - hence why I prefer a system of either "levels must be submitted before then" or at least "intent to submit must be indicated before then".

[namida]

It seems that so far, there isn't really any consensus on what to do about the deadlines. Of course it's still open for input, but assuming no general consensus is reached before the next contest, I'm going to go with my preference, which is to extend the initial submission deadline only if new submissions (not updates to existing ones) are received, and keep the status quo for the update deadline.

[Akseli]

I've been missing full score breakdowns in these contests. So far only placements have been revealed, and only for the levels that have made it to the final round. Vote results for each round have always left unrevealed, even though at least I would be very interested in seeing those. Here is an example of thorough results. The results should be revealed after the whole contest is over, and not in parts after every round, for example. This is pretty much the same issue I hoped to see in the voteoffs for the official games, now we don't know how levels succeeded between each other in their own rounds.

So, if no one finds revealing full results a bad idea, I would like to see this in the contests.

[namida]

In regards to SuperLemmini - it seems that this engine is very unpopular. Very little content has been released for it, as far as I can recall it's never been used in a contest entry, and development seems to have halted on it now.

With this in mind, I am considering removing SuperLemmini from the list of accepted engines in future contests (regular Lemmini will remain accepted). Any thoughts on this?

[Crane]

It's a shame because I consider SuperLemmini to have some potential, but with just some annoying quirks that might need to be ironed out, or otherwise some functionality that clashes slightly with other versions of Lemmings.

[namida]

It'd appear I spoke too soon about development being halted; but it does remain an unpopular engine for anything beyond playing the official levels. For now, I won't make any changes to its status of being an acceptable engine; although it appears the contest has now settled into a setup of "majority are NeoLemmix, with a handful of Lix levels, and other engines aren't being used".


Anyway; a point I'd like to discuss is naming for updates. We've had cases where pre-playing phase updates have been labelled "V2" or "V1.1"; and one case where someone labelled their update "V2b". I've ignored these in maintaining the list, instead naming the files (and referring in the topic's first post) as simply "V1", "V2" etc; with the state of the level at the beginning of the playing phase as always "V1", even if there's been updates during the creation phase.

I'm wondering if the rules should explicitly specify a guideline on how update versions should be named, to minimize confusion that may arise from such...