I really think something like "CC2LPn" is too confusing. I suggest maybe something like "CCXn" for Chip's Challenge Expansion, which is really what CC2 is. Or how about "C3P0" for Chip's Challenge Community Pack 0?
Anyway, we really need something more readable than a lengthy sequence of letters and numbers that looks more like someone's password than a levelset title.
I'm still a fan of 150 levels. 200 feels like too many, especially when many of them would be heavier than the CC2 main game. No real reason to stick with 149 so why not go for the round number, as the amount of levels in CC1 packs hits a sweet spot.
Ditto. 200 was all right for the main levelset, because there were so many short levels. I expect the average community pack will have fewer short levels, so 200 would feel like a bit too much.
I'm inclined to say no to this unless the level has a very good reason to use CC1 boot rules and it's made clear in a hint that CC1 Boot rules are in effect.
I agree; it's better if the boot rules can be consistent within any given levelset. But IMO an exception should specifically be made for any level that was designed for CC1 and then converted. It's not fair to require a CC1 designer to go to possibly enormous effort to adapt his level for CC2 boot rules, just for the sake of consistency.
No to enforced viewport size. Some levels can work better with the smaller one- I'd say 10x10 should be relatively standard unless the aesthetics/window shopping would call for 9x9, similar to Oasis in the CCLP4 port. Likewise, no to map size limit. I imagine very few levels larger than 40x40 (which is already nearly double the play area of a CC1 level!) will even be submitted, this would rule out very long and very tall levels, rule out huge mechanisms in small play spaces... if the level is too hard due to its length or too tedious then it won't do well during set construction, and that phase will weed out levels that (ab)use the size.
Ditto and ditto.
Zero-directional blocks and blank "no" signs should be expressly permitted. Their functions are really just extensions of their base elements' functions, rather than the result of bugs that might later be fixed. This is why they're available as standard elements in my editor.
Other non-standard elements, including the ones in the correspondingly-named tab of my editor, and especially elements that require hacking, including "voodoo" tiles, should be banned. As far as I can see they are all the result of definite bugs, not just an extension of existing game logic. This means we cannot be sure they will continue to be supported in future updates to CC2.
The trackless railroad tile is an edge case. Like zero-directional blocks and blank "no" signs, its "behavior" is just an extension of the base element's behavior. The trouble is, its extended behavior is not actually useful for anything that any number of other elements can't do, thus its only real value is for deceiving the player with "fake gravel". Is fake gravel something we really need or want? I'm not sure, which is why I have chosen not to add it to CCCreator (though eventually you'll be able to edit regular railroad tiles and delete the tracks, if you really want to). I would however lean toward banning it in official community packs, unless someone designs a level that demonstrates a really cool, and not unfair, way to use it.
Block slapping should be a pretty well-known behavior by now and is specifically designed into the game logic. It should definitely be allowed, and should even be officially encouraged so that the community has the opportunity to become more familiar with it. I would even go so far as to say the first community CC2 pack should have a block-slapping tutorial.
Most other gimmicks are, I believe, the result of bugs rather than obscure, but intended, behavior. None of these gimmicks should be allowed, for the same reason as non-standard tiles.
Aesthetic balance should be done with the default tileset, as well, if necessary.
Good thought, and agreed.
Yeah, they're bonus flags; it should not be a requirement on the designer that they're all obtainable.
Good idea; I presume though that the solutions would be deleted prior to release of the set?
What about standards for hiding logic (either by the Hide Logic flag or by the level layout) and RNG mode?
Some level names (e.g. ones with question marks) cannot be used as C2M filenames. Should there be a standard for file naming that takes this into account?
Are designers allowed to submit music tracks to accompany their levels? The staff could accept submissions while reserving the right to decide whether or not to actually use them. Also, submissions could be limited to those tracks that come with the base game, or could be open to any (freeware) tracks, which could be bundled with the set.
Should the staff delete non-hint text from the level's Comment box, or replace it with their own comments, or leave it alone (maybe seek the designer's permission to delete any comments deemed inappropriate)?
If I think of anything else I'll edit this post to add it.