[DISC][PLAYER] Potential new object - Permanent skill assigner

[namida]

This proposal is considered a strong contender.

This proposal is for an object which, when a lemming enters the trigger area of, the lemming gains a permanent skill. (Assuming it doesn't already have that skill, or another skill that's incompatible with it (ie: Floater vs Glider).)

Considerations:
- Should they be single-use or infinite-use? (If infinite-use, they will be constant; ie: like fire, not like triggered traps.)

Other notes:
- Removers / state changers (ie: to/from Zombie and Neutral) exist as seperate suggestions and are not part of this one.

[WillLem]

+1

Generally in favour of this, since it removes the need to skill-spam at certain points in a level requiring multiple lemming to be assigned permanent skills.

[Kingshadow3]

There is also the thought of what happens when a Floater triggers the Permanent skill assigner for a Glider (And vice versa) since these are mutually exclusive.
Either:
1. The Lemming doesn't get assigned a Glider and remains a Floater.
2. The Lemming loses the Floater skill and is replaced with the Glider Skill.

Which of these do you think should happen?

[namida]

^ That's a great point. I'd personally lean towards "nothing happens", including that if we go with a one-shot or one-lemming-at-a-time ("trap-style" infinite) variant, a lemming that can't receive the skill should not trigger the object at all. This could work well together with the skill remover, in situations where one must remove the Glider skill before adding the Floater (or vice versa).

[GigaLem]

I'll copy and paste most of my thoughts from the remover fields topic

I am for this object type and same way with its polar opposite

I'd imagine it being a infinite use object, if finite use ones had to exist, it should have a number over the skill to list how many until the object shuts down, like with the finite exits

The object should show the skill outside of the clear physics mode, show the Skill and a Plus right next to it. if it adds one skill, the skill is the one you see it adds, however I know it can't add all at once so a "+ALL" one wouldn't be able to exist, closest you'd get is one that shows four or five skills that'll it'll add

The best way of visualizing it is like the one way field, considering that one way fields force a lemming back despite the lack of a wall, this basically acts similarly minus the forcing a direction

You could combo this with some puzzle that remove and add with two gate areas at a time. a "Skill swapper" area if you will.

[namida]

- Should a single object be able to grant multiple skills? (How often do situations arise where simply placing two objects - one for each skill - next to each other, wouldn't be suitable?)

After further thought on this one, I'm going to go with "only one skill".

- What should occur when a Floater encounters a Glider object, or vice versa? Keep the existing skill, or lose it and gain the new one?

Thinking about this - trying to assign a Floater to a Glider doesn't replace, it just can't be done. Much like assigning a Climber to an already-Climber can't be done, for example. I'd expect a one-shot or triggered assigner to ignore a lemming that already has the exact skill in question; and I'd argue consistency would suggest the same should happen for the Floater/Glider scenario.

- Should they be single-use or infinite-use?
- If infinite-use, should they be one-at-a-time (like traps) or constant (like fire / water / exits)?

These are still open questions. However - the one thing here is that I want the answer to these to be the same for both assigner and remover. However, it's still an open question whether the remover is skill-specific or remove-all.

Further to this, after re-reading over the three topics (neutral equivalent included), I've decided to rule out triggered one-at-a-time.

[Dullstar]

I think for this specific object type, a customizable quantity really makes a lot of sense. Plus, it's consistent with how pickup skills already work. That said, considering there's currently a proposal for a remover as well, it would make sense to also offer an infinite use option. There's precedent for how this could work: it's already how exits function: if the level designer doesn't specify, it defaults to being infinite, and if the level designer specifies a limit, that's how many lemmings can use it.

[Strato Incendus]

I'm definitely for this type of object; it's one of the primary things that enabled several great puzzles in Star Wars: Pit Lems, by assigning colours or tools to different droids depending on the route they took. In Pit Lems, this mainly served the purpose of having them pass through colour- or tool-specific barriers or enter exits that were restricted to those colours or tools.

I don't think we'll have skill-specific exits in NeoLemmix (i.e., no exit objects that only allow Climbers to enter). But this can easily be set up by modifying the terrain accordingly (if you want an exit that only Climbers can exit, place it on top of a vertical wall; if you want one that only Floaters and Gliders can exit, place it in mid-air; if you want one only Swimmers can exit, place it in the water, etc.).

[Proxima]

I don't think we'll have skill-specific exits in NeoLemmix (i.e., no exit objects that only allow Climbers to enter).

Indeed, that has been rejected some time ago, for the reason you state: it's easy to get the same effect without a dedicated object.

[WillLem]

this can easily be set up by modifying the terrain accordingly (if you want an exit that only Climbers can exit, place it on top of a vertical wall; if you want one that only Floaters and Gliders can exit, place it in mid-air; if you want one only Swimmers can exit, place it in the water, etc.).

it's easy to get the same effect without a dedicated object.

Ah, this old chestnut

I strongly disagree, and I find the "it can be simulated" argument generally a very dreary and lazy counterpoint; it doesn't actually state that the idea is a bad one (and in fact goes some way to reinforcing that the idea is good enough to be at least simulated), but rather makes it appear "not worth bothering with", resulting a depressing stalemate. Furthermore, it's also often incorrect in its assumptions about how the idea may be implemented; whilst I can concede that some setups can be adequately simulated, there are others which just can't.

With that said, and to address this one specifically: sure, you can place an exit that only Climbers can reach, but this is not an adequate simulation of a "Climbers only" exit; there must surely be an exit somewhere else in the level that non-Climbers can reach, so why not just send all of the lemmings there? Same goes for all other permanent skills. The level would need to contain further complications to enforce use of the "otherwise unreachable" exit. A "this skill only" exit, by contrast, could be placed anywhere. I'm not saying that either level setup would necessarily be better than the other, just pointing out that the ideas are in fact different, and simulation can't cover all possible/desirable setups.

Furthermore, if it is desirable to simulate something, then it's desirable enough to have the real deal if possible.

Anyway, that was a more general discussion about ideas. Regarding the topic itself:

a customizable quantity really makes a lot of sense

Agreed, and +1 for Dullstar's comments in general.

After further thought on this one, I'm going to go with "only one skill".

Good shout. Although you could always simulate a "multiple-skill" one by stacking them (I'm joking, of course!)

But seriously, multiple-skills could be handled the same way as pre-assigned windows (i.e. icons above), thus keeping it neat and consistent with existing objects. That said, "single skill" assigners could be placed in a row if multiple skills are required, somewhat sacrificing neatness for better clarity... either way seems good.

[Proxima]

I strongly disagree, and I find the "it can be simulated" argument generally a very dreary and lazy counterpoint; it doesn't actually state that the idea is a bad one

Of course not, because it isn't. That's kind of the point.

Suppose someone were to propose a direct-drop exit -- not the "vortex" that was considered at one point, but an exit exactly like the existing ones in all respects except that it permits direct drop. New puzzles are enabled, and people who dislike direct drop can still use the normal exit, so everyone's happy. Must be a great idea for a new object, right?

Except that -- as you know -- you can just put an updraft above an exit, so there's no need for a dedicated object. "It is vain to do with more what can be done with fewer," indeed.

With that said, and to address this one specifically: sure, you can place an exit that only Climbers can reach, but this is not an adequate simulation of a "Climbers only" exit; there must surely be an exit somewhere else in the level that non-Climbers can reach, so why not just send all of the lemmings there? Same goes for all other permanent skills. The level would need to contain further complications to enforce use of the "otherwise unreachable" exit. A "this skill only" exit, by contrast, could be placed anywhere.

I don't follow this at all. If you have a climbers-only exit, and a second exit that everyone can reach, then the player can just send all the lemmings to the second exit, true. But it's equally true whether the climbers-only exit is a dedicated object or a normal exit at the top of a wall. So you haven't provided a scenario where the dedicated object enables a puzzle that the terrain setup doesn't.

(The most common scenario where skill-specific exits enable a puzzle is not to have one skill-specific exit and one exit for everyone, but to have one climbers-only exit and one floaters-only exit.)

[WillLem]

as you know -- you can just put an updraft above an exit, so there's no need for a dedicated object. "It is vain to do with more what can be done with fewer," indeed.

Simulating something is "doing with more what can be done with fewer." Often, the problem with resorting to simulation is that the level ends up messier (or at least less neat) than it could be, with multiple objects being used in place of just the one (your example requires both and exit and an updraft in place of a direct-drop-enabled exit).

As stated in my previous post, I can concede that some setups are absolutely possible to adequately simulate (i.e. the effect provided by the simulation is, to all intents and purposes, identical to the desired result). However, these are not without their own problems, if only in terms of aesthetics. Also, as my post goes on to discuss, some setups are not possible to simulate exactly. In both cases, a dedicated object is more desirable.

But it's equally true whether the climbers-only exit is a dedicated object or a normal exit at the top of a wall. So you haven't provided a scenario where the dedicated object enables a puzzle that the terrain setup doesn't

Admittedly not. However, rather than get bogged down in discussing specific examples at this point, my goal here is simply to point out that the two setups are different: a "Climber-specific" exit can have all non-Climbers walk right past it, whereas a "reachable only by Climbers" exit is reachable only by Climbers. These two situations are clearly different; one is not an acceptable simulation of the other, but rather the two are distinctly separate setups. Even without getting into a discussion of the specific puzzle potential of each, this shows that a dedicated object is still potentially desirable.

[namida]

With that said, and to address this one specifically: sure, you can place an exit that only Climbers can reach, but this is not an adequate simulation of a "Climbers only" exit; there must surely be an exit somewhere else in the level that non-Climbers can reach, so why not just send all of the lemmings there?

Because it requires another skill that needs to be given to non-Climbers, or because it is an exit that Climbers (instead of non-Climbers) can't reach. (This latter case of course can only really be done with Climbers, Gliders or Sliders.)

I strongly disagree, and I find the "it can be simulated" argument generally a very dreary and lazy counterpoint

It's not all that common that a single argument determines the entire decision (and exceptions to this tend to be either "accepted because it's an extremely useful and simple to implement idea" or "rejected because it very obviously goes against the spirit of NL"). It's one point that gets taken into account, that shifts the balance in one direction or another. Keeping in mind that NeoLemmix is something that must be coded by someone (generally me, though others have contributed in the past, in particular Nepster), and not a magic box where you can simply request a feature and it appears at no cost to anyone; as well as that players must keep in mind how every object that exists works and how to differentiate between them even if the objects themself could be magicked out of thin air; it becomes about not just what can be done or is marginally beneficial, but what's really worth putting the time and effort into, and expecting the players to also put their time and effort into learning to interact with.

As I have mentioned before - at one point, NeoLemmix did indeed approach things with a "if I can think of it, in it goes!" approach. This just lead to too many features, some of which were rarely used and/or downright bad in hindsight, and many of which eventually caused a mess (and for a while, people refusing to update to new versions in protest, though thankfully people seem to have moved on from that now...) when they needed to be culled.

[Dullstar]

Since no one's brought it up, you can further enforce the whole exits thing with lemming limits. If the regular lemming exit only takes 15 and you gotta save 20 and you got 5 climbers, those 5 climbers are gonna have to go to the exit that only the climbers can reach. Plus, you'd specified a permanent skills only exit... but not an exit that prohibits permanent skills, so you'd still have the whole, "Why not send the climbers to the everyone else exit too?" Although in that way it becomes a stronger case against the object, because then we'd need two objects to really cover the case, and that's a lot of visual communication for not a lot of apparent value.

Although that by itself isn't a complete argument against it... I've said this a few times in various threads when WillLem's brought stuff up, but personally when there are simple ways to simulate something, I like to see visual examples of ideas that a new object would make the idea work better than it works with existing tools, rather than a hypothetical "this might be fun to play with!" Some potential objects are very easy to simulate with existing objects and skills, while others are very hard to simulate. Lots of very niche objects can bloat things somewhat - but something that's a very common use case that's also very kludgy to set up a simulation for is much more desirable to add.

In any case, it's off topic. This thread isn't about exits.

[WillLem]

Because it requires another skill that needs to be given to non-Climbers, or because it is an exit that Climbers (instead of non-Climbers) can't reach. (This latter case of course can only really be done with Climbers, Gliders or Sliders.)

How can there be an exit that Climbers can't reach, but non-Climbers can? Same question for a skill that "needs to be given to non-Climbers" - why can't it be given to the Climbers as well?

It's not all that common that a single argument determines the entire decision ... it becomes about not just what can be done or is marginally beneficial, but what's really worth putting the time and effort into, and expecting the players to also put their time and effort into learning to interact with

Of course I'm aware of the hard work and effort that yourself (and others) have put into NeoLemmix over the years, that's never in doubt. NeoLemmix is nothing short of a marvel at this point, and we as Lemmings fans are lucky to have it. One of the reasons I discuss these things so extensively and passionately at times is precisely because I think NeoLemmix is worth discussing!

Regarding feature bloat and players having to learn new stuff, I guess I'm unlucky to have missed out on the really experimental phase of NeoLemmix's development in the past, because I likely would have benefitted a lot from seeing some of that stuff in action and being part of the discussion around it at the time.

Having said that, I have seen some features get tested and dismissed (such as Spearers {yuck!} and Grenaders {yay!}), and so I have seen some "good idea in theory, not quite so good in practice" stuff which has helped to contextualise this concept for me; it's become very clear that even if an idea kind of works and is generally good, it can open up a massive can of worms when it comes to physics, UI and player interaction, for sure.

I've also had a chance to play around with SuperLemmini's code a bit recently, and I tried out an idea I'd had for a while regarding the status display (IN/OUT/HOME); it became clear very quickly that this idea wouldn't work in quite the way I had imagined, and in fact needed an extensive re-think.

For me personally, seeing the idea in practice is often the only satisfactory way to make or break it; theoretical talk around it, particularly that which seems to repel the idea, often seems like nothing more than a hinderance to getting it done and tested (which, of course, is not always possible). I've said many times that we're lucky to have an active developer who's prepared to even listen to and consider ideas, let alone implement and test them. Make no mistake - I'm grateful for this! I guess it does mean, though, that I'm always likely to push for ideas to at least be tested before any decision is made one way or the other. I sometimes forget that a lot of the "learning" has already been done.

Since no one's brought it up, you can further enforce the whole exits thing with lemming limits

Sure. But, again, it's more stuff instead of less stuff for the player to worry about.

In any case, it's off topic. This thread isn't about exits.

Good shout

My thoughts on the permanent skill assigner:

It should be visualised as some sort of archway that the lems walk through, with a clear indication of which skill will be assigned to them (maybe have something similar to a pickup graphic above the archway, requiring space for this in any custom designs). One-skill-per-archway seems the best way to go to keep this easy and simple for the player to see what's going on.

The archway could have an animation, but (as is being discussed for the Portal) it should ideally still allow multiple lems to pass through and gain the skill assignment (i.e. infinite rather than triggered, which already seems to have been decided upon anyway).