OK, by now we have many different possible recolourings in SuperLemmix - normally mandatory (i.e. any custom sprite sets need to specify recolouring data for this state), but optional where noted:

Normals
Neutrals
Zombies
Athletes
Selected
Swimmers (optional - if not specified, the lem will be recoloured as an athlete as usual)
Invincibles (optional - if not specified, the lem's existing colour state will be preserved)

And, there's the upcoming Rivals - this will also be a mandatory recolouring state.

Invincibles have an overlay similar to Sonic The Hedgehog's invincibility state*, which helps to further distinguish them even in the absence of recolouring. Zombies, meanwhile, have a different Walker animation and move more slowly. And Selected lems are always under the cursor, so it's clear what's happening there.

That still leaves 5 remaining states that rely on colour alone in order to be distinguishable - Normals, Rivals, Neutrals, Athletes and Swimmers. Even if we take Swimmers out of the equation (which are not a mandatory recolouring state, whereas the others are), it's still a lot.

So, I'm thinking of giving Neutrals their own overlay and renaming them to "Shadows". The overlay would help to distinguish them as Shadows, meaning that they absolutely couldn't be mistaken for another lem type. The influence here is very much from Pokemon, which gives Shadow Pokemon a purple cloudy overlay (and red eyes). The effect would be exactly the same (i.e. these lems would ignore assignments), and we can still recolour the tunic (I'd suggest to dark grey). Here's a mockup:



Meanwhile, we can implement the WIP "De-neutralizer" as a "Purifier" in SuperLemmix, and overlay "Purified" lems in a similar way. The "Neutralizer" would then become a "Shadowmaker", and the same overlays could be integrated into the object animations in order to make it very clear what they are.

Bonus suggestion:

We could even go a step further and only allow Shadow lems to be saved once they've been Purified - this would require any levels featuring Shadow lems to also include a Purifier if those lems need to count towards the save requirement. However, it would also break existing levels featuring Neutrals, so we'd have to be sure we want this even if the fix is simple enough (i.e. place a Purifier near the exit).

One thing that won't happen is for Shadows to be a different type, and keep Neutrals. The proposal here is that Shadows should replace Neutrals, regardless of whether or not the state is expanded to include other properties/features - the main goal of this is to provide a state that's distinguishable by something other than tunic or hair recolouring.

---

*Here's what Invincible lems look like, in case you haven't already seen:

Well, I love a good spreadsheet so here's what we can possibly do for each of the sound cues :

N/A means Not Applicable - we won't use a Visual SFX cue here.
TBA means To Be Announced - we either won't use a Visual SFX cue here, or we need to decide on one.

Sound Cue	Text VSFX	Symbol VSFX	Panel Message (off-screen events only)
Level Start	"LET'S GO!" (above entrances/pre-placed lems)	TBA	N/A (off-screen level start areas shouldn't be formally supported)
Zombie Level Start	"BRAAAINS!" (above zombie entrances/pre-placed zombies)	TBA	N/A
Builder/Stacker/Platformer Warning	"CHINK" (above working lems)	Frustration lines (above working lems)	<- Bricks are running out! ->
(Time)Bomber 'Oh No' State	"OH-NO!" (above lem)	N/A	N/A
(Time)Bomber/Freezer Explosion / Balloon Pop	"POP" (above lem)	N/A	N/A
Hit Steel/OWW	"BONK"	TBA	<- Action interrupted ->
Lemming Death	"YIKES!"	N/A	<- Lemming lost ->
Time Up	"TIME UP" (above exits)	Clock (above exits)	Time is up!
All Collectibles Gathered	"WELL DONE"	Star (above lem)	N/A
Button Click	"CLICK"	N/A	<- Button Pressed ->
Exit Unlocked	TBA	TBA	<- Exit Unlocked ->
Lemming Exit	"YIPPEE!"	N/A	N/A

Made significant progress with this. The feature is working a treat so far, including recolouring (which took some doing to get everything to line up, but it seems to be playing along nicely).

A few concerns have arisen, which will need to be addressed before I'm happy to release this feature:

1) How should Rival exits be marked?

This is where those decorative flags might finally come in handy for something. It would be fairly arbitrary to design a different-looking exit (which to all intents and purposes would still just look like... an exit!). There are also cases where a Rival exit would need to behave like a normal exit code-side anyway (more on this later). So, how about this for starters (note that these lems are going to their correct exits!)?



For the default ohno/orig Rival Exits, the red flag can be baked in to the animation. This should prompt designers to manually apply the blue flag for Normals.

There may even be a way to detect the presence of the flags within a certain radius of the exit's trigger area, and enforce this code-side if the level contains Rival lemmings. That does seem a bit drastic, though. Let's hope that designers choose to mark the exits appropriately if they're creating a Rivals level, and give them a nudge in the right direction if they choose not to or genuinely don't realise that they should.

2) What should happen when a level has only Rival lemmings but only Normal Exit(s) (or vice-versa)?

This one should be fairly easy to deal with: if there is only one type of lemming (Normal or Rival), then any exits present behave like regular exits for that lemming type. The way that Rivals code has been implemented so far could easily support this, and it would mean that people could make legit levels featuring only Rival lemmings should they wish to do so, whilst also preventing troll levels/genuine mistakes.

In the absence of any better ideas, that's how I'll probably solve this one.

3) What should happen when a level has a mix of Rival & Normal lemmings but only Normal or Rival Exit(s)?

This one is more difficult. At present, it would be possible to create the following level:

20 Normals + 20 Rivals
Save requirement of >20
0 Cloners in skillset
1 Normal exit

Such a level would be impossible to complete, and this is a scenario which could come up fairly innocently. So, it feels like it should be handled code-side. I can see 3 possible solutions:

Solution A would be to default the save requirement to the amount of Normal lems. That way, the Rival lems could still be used as part of the level's solution, it would just be necessary to divert them away from the exit.

Meanwhile, the more complex Solution B would be to subtract the number of Rivals from the current save requirement, and have the resulting figure be the new save requirement. So, for example, in this scenario...

20 Normals + 20 Rivals
Save requirement of 25
0 Cloners in skillset
1 Normal exit

...the save requirement would become 5. This would essentially completely disregard the presence of Rivals in the level. So, if the solution requires that 15 lems be sacrificed, those lems could be either Rivals or Normals and it would still be possible to meet the save requirement.

Meanwhile, Solution C would be to change the Rival lems to Normals. This would be the cleanest code-side, and would at least allow the level to be loaded and played.

Note that in any of the proposed solutions A, B and C, the same logic would apply vice-versa for (mixed lems + Rival exit).

Finally, Solution D would be to not load the level at all unless there is at least 1 Normal and 1 Rival exit, in the case that there is a mixture of Normal and Rival lemmings. This is probably my preferred solution out of all of them as it bypasses Rivals being used for unintended purposes and keeps the feature clean, but it does mean that the potential puzzle benefits of solutions A and B are discarded.

Thoughts? Could do with some feedback on this as either solution requires a fair amount of commitment to that solution before plowing ahead.

---

EDIT: Another possible solution is to not implement "Rival Exit" as its own Exit type, and instead check for a "Rival Exit Marker" within a certain radius of a regular Exit. This would at least enforce marking the Exits.

It would be interesting to know how the 2-Player Exits in OG Lemmings were handled. We know that only 1 Exit type existed, plus the flags. The flags must have had more of an effect under-the-hood, which is perhaps what needs to happen here.

Glad to have approval for this. It'll be present in 2.8 for sure

One thing I am now wondering though is whether the regular status text (athlete info, etc) should also be hue-shifted... this is where I might be overthinking it a bit. Let's leave things as they are for now!

I didn't think the "chink" text looked too bad.  Maybe if text vfx were implemented, there could be an option to either have them turned off (default), turned on on their own, or turned on with symbol vfx

Text, symbols or none could work, this is a good idea. Of course, it would always be possible to swap out the graphics for whatever you like anyway, but maybe this is one to support at base level for accessibility reasons. It should only be a small handful of files anyway.

That idea for off-screen vfx to the left and right of the screen is fab!  Could be very useful for sound-off/hard-of-hearing situations,  The only thing that could be an issue is the vfx obscuring what is occurring on the viewable screen area.

Definitely worth considering, particularly if it ends up being very difficult (or, not at all possible) for the game to "know" whether something is happening "off-screen", or to draw graphics to an overlaid layer (which doesn't currently exist, and would eat up rendering resources).

Perhaps the hints could be displayed at the top of the game window, in the centre, with an arrow pointing left and right, something like this:



Or, more preferable, we could even use the panel display (this is coming in handy for a lot of things recently!):



Obviously, this would temporarily obscure the display, but the likelihood is that whatever is happening to prompts the hint is more important anyway, and we can always make them clickable-to-stop-showing.

In fact, one very large benefit to using the panel is that we wouldn't need another rendering layer; this might end up being the way to go with it.

It might be pretty cool too if, for the builder vfx, if three bars would appear when three bricks remain, two bars, when two, one when one, then the exclamation mark when the builder is about to give up and walk on.

I like the idea, but let's keep it simple to begin with (i.e. the same graphic each time) and see how necessary this is.

Is there really any point in a "Let's Go" vfx? ...  Still, if it's optional and not too difficult to implement alongside other vfx, then why not, I guess.

The only two that I would consider necessary from an accessibility point of view are the Builder/Stacker/Platformer alert, and a lemming death that might have happened off-screen. All others are purely cosmetic. At some point I'll get a list together of the various sound cues that might need Visual SFX and we can decide what to do about each.

Does having the visual element as well make the timing process much more difficult, then?

Not really, it's essentially the same process of passing a message per-lemming to cue the graphic. I understand a bit better now how things work than when I first attempted to implement this, so my next attempt should be more successful.

In fact, in order to bring this feature closer to something that feels manageable, I'll go ahead and make the call that off-screen hints will be shown in the panel area. This will greatly simplify the feature; we already have code to get the Lemming's position, and we already have code to draw a message to the panel.

OK, I've gone ahead and enabled notifications for this topic so I won't miss another post. Only just realised this is possible!

OK, I have double-checked my laptop screen resolution and the highest it will go is 1366x768.

Ah yes, I meant to say 1366 x 768 rather than 1280 x 720. The issue is the same, though - it can manage 3x zoom in low res but only 1x zoom in hi-res (which is the same size, but higher resolution, as 2x zoom low-res).

And indeed, the DPI settings won't make any difference if it's a screen res issue.

I have tried, as you suggested, turning off the minimap, which definitely filled the entire width of the panel/screen.  The two attached screen photos show the results.

Thanks for sharing these, it's good to see how things look on different machines. I can of course simulate 1366 and other resolutions on my machine, but it's still good to have an actual comparison.

I do appreciate that my laptop is now a little long in the tooth and doesn't support 1920x1080, which would be ideal.  I will have to look into upgrading it soon.

I was careful not to outright suggest that you buy a new laptop, since that's a pretty naff support response! But yes, if you can treat yourself sometime, go for it

I will also try playing SLX on my desktop PC - which is older, but I have a really good 1080p IPS monitor, and run Windows 10 in 1920x1080.  I expect that I'll get more favourable results on that.

Almost certainly!

In the meantime though, one of the jobs on my list is to look at dynamic resizing of the skill panel so that it always matches the width of the game window. I've wanted to do that ever since I began with SLX, and now that it's been brought to my attention by someone who actually uses the program I'll definitely bring it up the priority list.

Much better!



Implemented in Commit 2afcb82c5 with Config menu option added in Commit ae0af2f3f.