Skill prioritization vs. lem info [DISCUSSION]

[Nepster]

In one of the latest experimental versions for NeoLemmix I introduced a new prioritization algorithm for assigning skills to lemmings. This has the unfortunate side-effect, that sometimes NeoLemmix now would assign a skill to a lemming A while displaying detailed info (e.g. being a triathlete) for another lemming B. Here two concrete examples:

1) Two walking lemmings are under the cursor, one a climber&floater and the other a plain walker. The selected skill is an exploder.
- The exploder would be assigned to the plain walker, because it is usually better to keep the powerful athlete.
- The detailed info would show "Athlete 2", because the player may want to check precisely what or how many permanent skills were assigned. "Walker 2" simply isn't that interesting, especially if one doesn't plan to assign any skill yet.

2) Two lemmings are under the cursor, one plain walking lemming and one blocked climber&floater. The selected skill is a builder.
- The builder would be assigned to the plain walker, because the blocker (even if he is an athlete) cannot receive it.
- The detailed info would again show "Athlete 2", again with the same reasoning as above.

But obviously all of this has the draw-back, that a player might think: It says "Athlete" down there, so we assign our skill to the athlete.

Question: What behavior do you expect respectively prefer?

[IchoTolot]

What is written down there -----> that lemming gets the skill. This must be the golden rule!

This side-effect would be extremely confusing and hindering and I would rather encourage the old assignment algorithm than this side-effect.

I think this would greatly influence the gameplay in a negative way.

[Simon]

Icho has nailed it with the golden rule.

Reasoning: The target info is designed to do two things at once, but it can only do one thing.

• Show what lemming is prioritized.
• Show permanents of lemmings with the highest number of permanents.

The priority is important on every assignment. NL has no other way to highlight who will get assigned.

On the other hand, NL recolors non-plain lemmings. To profit from the permanents check, you need a mix of different athletes, mingled with plain lemmings. This is rare.

The exploder would be assigned to the plain walker, because it is usually better to keep the powerful athlete.

This is tricky. It reeks like computer wants to be smarter than the user. I deem this a case for priority invert.

But it's not clear-cut: geoo has requested and since uses a Lix option, preferring batter assignments to walkers over batter assignments to timed exploders. I don't use this option.

-- Simon

[Proxima]

Simon pretty much said what I was going to say, but I'll have a go at putting it in my own words anyway.

"Computer wants to be smarter than the user" is a problem because the user doesn't know whether or not to adjust for this. User observes that climbers / floaters are prioritised over normal walkers in other circumstances, and expects this to be consistent. When it isn't consistent, user doesn't know what is going wrong and thinks they mis-clicked rather than discovering a new rule.

You are arguing against yourself. When an athlete is selected, detailed info should show "Athlete 2" because user wants to know what permanent skills are on the lemming being assigned to. The same reasoning demands that in the second case, where the walker has priority because the athlete is a blocker, the info should show "Walker 2". This conveys the same information -- the number of permanent skills on the lemming being assigned to -- in this case zero. If this is useful, interesting information in one case, then it is in the other.

[Dullstar]

I agree with what basically everyone else has said.  The current method is fairly logical and easy to understand - whatever lemming the game reports as being highlighted is the one that uses a skill when it is assigned.

[namida]

Agreed, again. Changes to the priority algorithm are probably very justified, but there should be no change to lemming displayed = highest priority lemming.

[Nepster]

Everyone agrees - Great! I felt the same after playing a bit more with the new algorithm, so this will change in the next experimental release.

The exploder would be assigned to the plain walker, because it is usually better to keep the powerful athlete.

This is tricky. It reeks like computer wants to be smarter than the user. I deem this a case for priority invert. But it's not clear-cut: [...]

Agreed, but I like to experiment a bit in the experimental releases: Ideally this now gets a bit of real user exposure and people give some feedback what they like and where the experimental release surprised them (in a bad way). So I can only encourage everyone to test the experimental versions, e.g. when playtesting their new level creations, while playing NepsterLems (which is guaranteed 100% solvable in the experimental releases) or on any other occasion. At the very least, I will get some hands-on experience myself about what works and what is better kept as-is. And if it turns out that the V1.43 algorithm is superior, then so be it and we will revert back to the current algorithm.

[namida]

The V1.43n algorithm definitely has room for improvement; it's just a matter of deciding exactly what that improvement should be.

Since you say NepsterLems is possible in the experimental version, I might try using it for future NepsterLems vids (probably from the 3rd rank onwards). This will give me a good chance to test it in a real-usage scenario rather than just made-for-testing ones.

[Simon]

Recolor target lemming, and draw target lemming on top of everybody else.

I've realized how much misery comes from not knowing the target with 100 % accuracy. This sounds even more important than improving the priority algorithm.

-- Simon

[namida]

Nepster: This is fixed in your newer code, right?

[Nepster]

Nepster: This is fixed in your newer code, right?

Yes, unless the code has bugs.

[namida]

Alright then. Since that's possible (and it hasn't had much testing) I'll leave this topic open, but I won't file the bug on the BitBucket issue tracker unless someone confirms there are remaining problems.