Quote from: namida on September 04, 2024, 12:52:00 AM
One other possibility that comes to mind is, during the non-mixed phase, hold all three rules' votes simultaneously. This wouldn't cut down on the number of votes, but would get them done much quicker (and can also potentially be combined with other ideas).

I think this would help streamline things a bit. The combination of the sheer number of voting rounds is a major factor in why the voting takes so long, but it's further exacerbated by the fact that we only run one round at a time even when the rounds don't have dependencies on each other.

It's already been brought up but I would like to explicitly mention support for the idea of changing the rule design from 1st place makes all 3 rules to each of the top 3 makes 1 rule; if someone is trying to earn that reward, hitting top 3 should be more attainable.

Quote from: Flopsy on August 26, 2024, 03:38:18 AM
AFK kicking wouldn't work because it would probably kick spectators too and they aren't able to make inputs while a game is in progress.

A possible solution that would address this problem would be, instead of kicking, automatically set afk players to spectator mode.

Quote from: FlopsyIt is annoying but unreadying people when a change in colour occurs is necessary. Ironically I know who you are on about when you say this also!

I think a simple improvement to this would be to change it so that this only unreadies players in the event that teams have changed. I don't think it's necessary to unready everyone when the sole player of a certain color switches to a different unoccupied color.

I'd like to say that I don't think players should be forced to use the nuke when they can no longer improve their standing, particularly in matches with a lot of players. You can still try to lower the amount by which you lose, or cause chaos, and either way it's more fun than just sitting there waiting for everyone else to finish.

I'll note that you can still have some fun with the learning process (though there will probably inevitably be a few parts that you don't like working on but you gotta do it anyway) -- just don't go for the "dream project" right away because that's how you set yourself up for failure by encountering an insurmountable obstacle. Starting small does not need to mean starting boring.

I'd also add that we haven't touched much on the actual complexity here. Scratch is very much designed to be easy to work with and is going to abstract away tons of complexity behind the scenes. But many of those abstractions rely on being able to run it, and your proposed operating system will, at first, have no way to do so; your operating system would need to provide all of the facilities necessary for it to run (even if it's something that runs in a web browser, this is still dependent on having a platform that is capable of running a web browser). And as it turns out it's a lot easier to use e.g. a function that draws a picture on the screen than it is to write that function. Or consider responding to the user pressing a key on the keyboard: instead of simply having some sort of is_key_pressed or get_keyboard_state function or on_key_press callback, you'll have to worry about things like how the keyboard actually communicates. Alternatively, if you want to target older hardware like the NES, you still have to hand-roll a lot of stuff because the hardware is so underpowered that pretty much any level of abstraction can be expensive, so the code is going to be much more complicated than Scratch for sure.

It might be interesting to go a bit further and examine a few more things:

How many designers enter? How far do they normally get?

If we think recognition is helpful for encouraging participation, then I think there might be some merit to having another voting category that explicitly excludes levels from the strongest competitors (as determined by past contest results).

Consider the actual visual representations of objects, i.e. how they are presented to the player, not how the game sees them internally.

Water and continuous traps such as fire don't represent an inconsistency regardless of how direct drop is handled. For example, suppose you enter a fire: it doesn't matter if you walked into it, fell into it, flew, whatever: by occupying the space you are getting completely roasted. The experience is probably not going to be particularly good for your health, to say the least. If you fall into water, you are in the water now; falling will not cause you to pass through it.

Many triggered traps, on the other hand, involve an object that doesn't really pose an active threat to your health until the trigger has been activated. Most of these traps appear to be something along the lines of pressure plates, but you could imagine a variety of mechanisms. A pressure plate would only activate if you stepped on it. A tripwire, on the other hand, can be triggered by passing through the space. While the game implements them all the same, it wouldn't necessarily be unreasonable for individual traps to have different rules about whether fallers should be able to trigger them. On the other hand, it's not really needed, because the game is consistent about how different types of traps are placed. Most of them are always placed on the ground, but for example the pillar spike trap is always attached to a wall (and thus its trigger area is mid-air). Because of this, allowing them to work mid-air is quite convenient: it means the spike traps can share code with the other traps, and since the other traps are going to be on the ground anyway, it doesn't really meaningfully change their behavior (if they fail to trigger the trap mid-air, then they just immediately trigger it when they land). Similarly, direct drop into a trap generally doesn't change things much; the lemming is dead either way and the only real difference is what goes on the death certificate. While you could certainly make a level relying on the behavior (a triggered trap can only kill one lemming at a time and splatters are already doomed, thus a trap triggered by a splatter is effectively wasting its time), none of the official levels do (nor do they really contain direct drops onto traps at all, unless you intentionally go out of your way to make it happen). Arguably for most traps the most logical behavior would be for a mix of the two where the lemming splats but the trap is still triggered regardless.

The visual design of exits is basically a building with stairs, and in official levels. I mean, judging from the door, it looks like there's a portal too, but it looks more like the sort of portal you would have to walk into, rather than one that sucks you in. The animations and boing sound effect also seem to communicate more that the Lemmings actively leap into the exit, rather than passively get sucked in. Thus, this suggests direct drop is probably an oversight rather than an intended feature: because the exit doesn't appear to be sucking them in, how exactly would it break a fall?

Quote from: WillLem on May 13, 2024, 09:58:26 PM
OK, I'll give it a try. Can't promise anything, because I currently have no idea what an enum is, let alone how it works or how to properly implement it. With that said, lack of prior knowledge hasn't exactly stopped me so far

The syntax will of course vary by language, but I think an example will be the easiest way to show it:

Note that this example isn't Delphi, as it's not a language I've worked with. This is more about the concept of enums in general, not how to write them in your language of choice.
enum Colors
{
    Red,
    Orange,
    Yellow,
    Green,
    Blue,
    Purple
}

Basically we've just created a new type* that can only hold these values**. Internally, they're probably just ints where Red = 0, Orange = 1... Purple = 5, but code that wants a Color doesn't need to care about that. When saving/loading from a file, we can convert them to/from strings as needed; some languages offer features to do this automatically, but if not, well, if we had to do some if/else to read/write anyway without the enums, we can do it with enums too. Many languages allow you to explicitly choose an underlying type and assign your own values, but there will usually be sensible defaults.

<sub>*Well, symbolically anyway. Languages vary in whether their type system considers enums to be different from their underlying types.

**Among languages that consider it to be a separate type, they also vary in whether or not you can force it to convert a value from the underlying type to the enum type even if that value isn't part of the enum, but fortunately in many (most?) languages it's difficult to do this accidentally.</sub>

---

_{Well, there's also the somewhat more complex Rust enums which basically merge unions and enums into one feature, but let's not worry about those.}

Quote from: WillLem on May 09, 2024, 12:09:56 AM
I understand your desire for the singular option, but there are benefits to keeping them separate (and, identified by strings rather than numbers). My instinct on this one is, let's keep it as it is at least for now.

I agree with Simon here regarding the use of an enum. There *should* always be one and exactly one of the options active, but an enum will consistently enforce it across the entire codebase. Even if everything's correct now, this has maintenance benefits long-term. It shows that it's intended that exactly one of the options is true, and you won't have to worry about any bad behavior as a result of attempting to run multiple options at once (sure, maybe setting them all to true doesn't misbehave for now... until some other change happens and it no longer gets handled gracefully but nobody checked).

You can still identify them with strings in the options file, and the enum values have names so it's not like you need to remember that "OptionA" is 0, "OptionB" is 1... keeping track of that is the compiler's responsibility.

Tip for replicating L2's style: Lemmings 2's terrain is strictly grid-aligned; this is why L2_classic is not a direct port of orig_pillar: orig_pillar's tiles would not have been the right size for L2's grid, and many of them don't align nicely with any grid size, so they had to redesign them. If I'm not mistaken the smallest size piece you can place is 16x8.

---

Is disallowing Water in Rule 3 intentional, or is it an oversight (since the stated reasoning is "Anything that was not available in Lemmings 2 is not allowed")? Water is present in L2 and the Classic water tiles are not unused in L2: they appear in 9 of the 10 official Classic levels.

There are also several unused tiles and objects in the set, which I still chose to include when I put L2_Classic together (using a rip made by... I think it was Icho?), but it's probably worth clarifying if these tiles are allowed. To my knowledge they are:

Steel: steel_01, steel_02, steel_03, steel_06, steel_07 (basically, just the small 16x16 square and one variant of the tiny 16x8 rectangle is used).
Wood: wood_14 to wood_24 are unused.
Misc: gray_block, pillar_end_03, pillar_end_05, pillar_end_06
Objects: trap_01, trap_02 (plus NeoLemmix standard objects: owa_down, owa_left, owa_right, lemming, pickup, button, updraft, flag_blue, flag_green)

It's probably easiest to allow all the blocks and objects that are in the style, but personally this is what I would consider:

Allow variants of used tiles:
- steel_06, steel_07 (variations of steel_05), pillar_end_03 (it's the right-facing version of left-facing pillar_end_02)

Gray area (use sparingly):
- steel_01, steel_02, steel_03 (these steel pieces are larger than the ones that were used), pillar_end_05, pillar_end_06 (the vertical pillar ends 7 and 8 were used, but maybe these horizontal pillar ends didn't work nicely with the grid?)

Don't use completely unused tile types:
- gray_block (it doesn't even fit with the rest of the style), wood_14 to wood_24, trap_01, trap_02

Regarding forks, if namida was okay with it my suggestion would be to keep the NL name (perhaps with a prefix/suffix) until breaking changes are made. If it's just an enhanced version of NeoLemmix but the physics and file formats are the same, so content made for one will work perfectly in the other, then I think a new name would just introduce confusion; conversely, if it's merely compatible with NL content, but its content is not compatible with NL, then calling it NL would be confusing.

I don't think the forum software supports it out of the box, if at all, but I wonder if there's a way we could implement ranked choice.

I agree that the arrow version is better, as the animation is more of an enhancement to the visuals rather than outright required to figure out what you're looking at. I don't like to go *too* far with the picture puzzle mentality but it's much more convenient the fewer things I need to go send a lemming to test (particularly if just figuring out how to get a lemming over to the thing I want to test in the first place is part of the puzzle!) And when I'm inspecting the level I will generally have the game paused so I don't have distractions from things happening elsewhere.

Though I wonder if it might be a good idea to have an option to continue playing idle animations while the game is paused (triggered animations, such as those for triggered traps, would be a bad idea since it would make it less clear when the trap is active again). Maybe that's a dumb idea, idk. Just throwing it out there, really.

To clarify, by "larger resolutions" I'm considering this any resolution that's larger than the monitor's native resolution. We certainly wouldn't want to reject a resolution that we're not 100% certain shouldn't fit.

But I suppose the "larger than the monitor" part probably isn't the actual problem. Just hazarding a guess: could excessively large resolutions just use too much e.g. VRAM and then the application doesn't know what to do?

From looking at what's been posted here, I do have a possible guess as to why Forestidia got a different behavior than Silken: from other reports we know Silken prefers hardware fullscreen, so it's possible the behavior may be dependent on it.

Ruler Snap like in Lix is probably the best solution.

Rather than making the end multi-colored, I think a better solution (although it would require changes to the code) would be to make the colors change. It wouldn't be entirely new functionality at least, since that visual effect is used in clear physics mode, just not with the splat ruler.