[SUG][PLAYER] Talisman Ideas

[WillLem]

How about talismans for each of the following:

No CPM
No Pause Button
No Directional Arrows
No Frameskip
RR = X

[Proxima]

NL used to support talismans for "keep the RR within a certain range" (which could of course be a single value). I don't remember exactly why this was dropped, though one thing comes to mind -- normally, it would be more of a challenge to be forced to restrict the RR to a high value (e.g. "solve the level at RR 99"), but you can't literally fulfil this condition, since the RR starts at a lower value.

For your other suggestions... there is an obvious problem with all of them. The player could solve the level with convenience features first, then restart, load their previous replay, and let it play out to earn the talisman. Even if we disallowed loading a replay for certain talismans (which comes with its own raft of problems), "no CPM" in particular is easily invalidated since the player could use CPM (or the editor) all they want to learn what is what on the level, then start again and play without CPM.

[namida]

Proxima hit the nail on the head with the first four. With CPM, I'd also like to add that there's generally only three reasons a level might be "harder" without CPM, all of which I do not consider good reason to make a talisman available for it even ignoring the "it wouldn't work that well in practice" factor:
a) because a player needs to figure out exact positioning / distances. Prohibiting CPM in such a case just forces them to figure it out via trial-and-error instead, which makes no difference to how hard it was for them to figure it out, it just becomes more time-consuming.
b) because a player isn't familiar with the style and doesn't know what's what. Again, prohibiting CPM in such a case really just means the player uses trial-and-error instead.
c) because the level is designed to be misleading.

As such, none of those first four will be happening. In general - there will be no talismans for use (or lack thereof) of any UI feature; it will be limited to what the solution achieves / uses, not how that solution was executed.


The release rate one used to exist, as Proxima says. There are two reasons behind it being dropped: Firstly, because it complicated the code quite a bit, and secondly because it was very rarely used. Either of these alone may have been fine, but the combination of the two lead to me deciding it was best culled (and yes - this one is something I culled, not Nepster). If I can be convinced that it'll see more usage this time, I can consider re-implementing it - I'm sure I can find a cleaner way to implement it now, my coding ability is much higher than when I did it the first time.

normally, it would be more of a challenge to be forced to restrict the RR to a high value (e.g. "solve the level at RR 99"), but you can't literally fulfil this condition, since the RR starts at a lower value.

In NL physics, the value of the RR only matters on frames when lemmings spawn. For the purpose of determining pass / fail on the talisman, NL only checked it on these frames IIRC. Although it might have been "check at any time between first lemming spawning and last lemming spawning", but it was definitely possible to have a minimum above the level's starting RR.



I'm going to lock this topic as a clear sign of that the first four ideas are not up for discussion, period. If anyone feels the RR idea is worthwhile and can think of cases they'd use it for (rather than just a general "it'd be nice"), feel free to make a new suggestion topic specifically for that.