Lemmings Forums
NeoLemmix => Bugs & Suggestions => Closed => Topic started by: ∫tan x dx on April 08, 2021, 07:15:34 PM
-
As mentioned in the title, this is an idea for a talisman criteron.
When the level ends, either by all regular lemming exiting or otherwise dying, a check is made to see if any zombies remain alive. If all are dead, the talisman is awarded.
Since the nuke option also kills all zombies, the nuke would presumably disable the win criteria. Unless it is possible to determine that all zombies have been killed before the nuke is used?
-
I'm not sure how much traction this idea will gain, but I'm not outright averse to it.
On the technical side, the way I'd foresee this working is:
- When the save requirement is met, NL checks if any zombies are alive on the level. If not, the talisman is awarded.
- When a zombie dies, NL checks if the save requirement has been met yet. If it has, NL then checks if any zombies are alive on the level. If not, the talisman is awarded.
The postview screen is basically UI fluff at this point. Records (including talisman unlocks / completion status) are registered the moment you achieve the requirements in-game, so eg. if you reach a level's save requirement, then instant-restart via hotkey, then exit, the level will still be marked as completed in your save data (because you did reach the save requirement, even if you didn't proceed to the postview screen afterwards). I will stress that it is only recently that NL started fully working this way, V12.10 or V12.11 (I forget which).
-
+1 for this idea.
We need more talismans that aren't just skill limits, and this is a good idea which doesn't involve changing anything about the way the game currently works.
-
+1 :thumbsup:
After all, Lemmings World Tour had its name kind of inspired by "Worms World Party". And these "battle-type" levels are precisely what we could have more of with such a talisman. Too often when I made a level that was about killing the Zombies, people backrouted them with timing-based solutions, i.e. slipping past the Zombies when they're far enough away, or by merely trapping the Zombies somewhere instead of getting rid of them for good.
-
I wasn't expecting such positive feedback for this idea, but I'll happily +1 this idea
-
It looks like there's a fair bit of support for this, including from multiple people who I'd believe would actually use it. I'll look into this as a possible 12.13 feature.
Some considerations:
- Nuke is obviously an auto-kill. Option A here is "if nuke is activated, talisman cannot be obtained". Option B is "if a zombie specifically dies from the nuke, talisman cannot be obtained" - so if you activate the nuke, but all zombies are killed before their timer runs out, you can still get the talisman.
- If a zombifier object is introduced in the future, how does it interact with this talisman? One possibility is that it's simply an "at the time" check - if at any point, the save requirement is met and no zombies are alive, the talisman is obtained, even if the possibility is there for a lemming to become a zombie later.
(Obviously, replace "talisman is obtained" with "this condition is met" in cases where the talisman has this condition as well as others.)
-
I prefer Option B.
Plus if a normal lemmings is zombified during the nuke is activated, the talisman cannot be obtained.(unless he is killed before he dies from nuke.)
For potential interaction with zombifier, I agree with you all.
-
Implemented in commit 0a82e23.
To keep it simpler, I have simply made the rule that the talisman cannot be obtained once the nuke has been activated.
-
A further thought that has come to mind, is that special handling may be needed for a case where the last zombie is still alive when the last regular/neutral dies or exits, but if the level were allowed to continue playing, that zombie would end up dying eventually.
Perhaps this should be generalized to "do not ever auto-exit gameplay" (follow-on: "unless the nuke has been triggered, and has completed"). Alternatively, it could simply be that remaining zombies prevent exit in the same way remaining regulars/neutrals do.
-
Okay so - I know I've already coded this feature in and of itself.
However, other issues remain in order to make it more practical, as noted above. Three months after theywere raised, no one, including those who suggested or supported this idea, has come forward to offer any solutions - which suggests this idea is not a particularly high priority even to those who do like it (EDIT: or, alternatively, that there is no good solution).
Between all of these factors, I am going to decide at this point to undo the implementation of this idea and reject it, so that effort can be directed instead towards features with stronger interest and/or benefits (or those that are very straightforward to make happen in a practical way that won't lead to a need for more and more changes at a later time).