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.

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.

Well, from the screenshots alone, it looks like the Level Select screen is being displayed correctly - the icons aren't supposed to be much bigger than that. The recently-added tooltip hints should help with these in the meantime, and I'll look at what can be done to improve the Level Select screen in general (a full overhaul isn't completely out of the question, but it may take some time).

Meanwhile, from the in-game screenshot it looks likely that your laptop's display has a max resolution of 1280 x 768. With that being the case, unfortunately it simply isn't wide enough to fit the full panel on the screen at 2x zoom in hi-res. Most laptops nowadays have a standard resolution of 1920 x 1080, and that's what I'm working to with SLX. We could consider reducing the number of possible skill types to 12 instead of 14 - and, I did in fact consider this for some time, but concluded that it would be a relatively drastic change to make for the sake of supporting older screen resolutions.

Definitely do double-check your laptop's display settings; it's possible that you may be able to go to a higher resolution, and this is what you'd need to do. If this isn't an option, then as a workaround for now you can head to the Config menu (F2 from the main menu screen), go to the Graphics tab, and un-check "Show Minimap". This will increase the size of the panel buttons considerably, and you can use the Zoom In/Out function to quickly move to another part of the level.

I'm also considering adding "Nudge Left/Right" hotkeys, which would quickly jump the screen left or right. Now that "Show Minimap" is optional, it seems like it might be a worthwhile feature.