[SUG/DISCUSSION][PLAYER] Expand number of skill types allowed in a level

[IchoTolot]

About removing buttons: I would strongly advice not to and I am completely against removing stuff like pause, nuke, fast forward......

Yes the hotkey is better and faster, I completely agree there, but the reason they are there in the first place is that these functions are not hidden! New players tend to use near to no hotkeys and the functions stay hidden. The nuke button is vital to some levels and players not knowing the hotkey would be screwed!

I would rather merge some buttons in a way like like the 2 in 1 directional select one than removing them. I rather risk having more of them than removing and hiding them.

[Minim]

I might have a method of making this plan work, but it'll need some more icons, hotkeys and programming to pull this off. How about we replace the third and tenth tabs (i.e. where the climber and digger icons are traditionally placed) with a previous/next page button. So when the player clicks one of these two buttons the six skill types shown on the screen are replaced by the next six and so on.

If that can be pulled off, you can have up to 12 or 18 skills at once. In the classic skillset, the seventh and eighth skill won't be lost, it would appear on the next "page".

[namida]

In such a case, you wouldn't need to display the scroll buttons unless there's 9 or more skills - indeed, I would say we shouldn't display them unless there's 9 or more; this way more attention is drawn to that there's extra ones to scroll to.

But overall, page-flipping is essentially just a variation of scrolling, which seems very unpopular as an approach to deal with this. If we do increase the limit, it's most likely going to be one of the following ways:
a) Shrink the minimap
b) Increase the total width of the skill panel
c) Remove or shrink some of the existing buttons

There is of course a limit on how many extra skills we can squeeze in with this - 9 total is definitely doable, 10 should be possible, if we want more than that we'd probably have to use a combination of those approaches. But this is okay - the strongest preference seems to be for just a slight increase.

I would definitely say - regardless of decisions (other than a decision of "don't change anything", which seems extremely unlikely), we should approach this in a way that, the behind-the-scenes code can handle unlimited skill types, and only the UI limits things. This way, it'll make things easier if there's ever a decision in the future to accomodate an even higher limit.

[namida]

In regards to increasing the panel's width - when the current-standard (ie: non-compact, with the extra feature buttons and the larger minimap) panel was introduced, some users complained it appeared too small on their screen, because there wasn't room to zoom it further. Let's consider - on common resolutions, can we add 16px (the width of one button) to each skill panel type, without forcing a lower level of zoom? What about 32px?

To start off with, some details to be aware of:
- I am assuming full-screen here. If anyone has any particularly specific setups using a windowed display that they're concerned about, please mention this so they can be taken into account.
- NeoLemmix is DPI-unaware. This means that, for example, if your display resolution is 1920x1080, but you have Windows scaling set to 150%, NeoLemmix thinks it's running on a 1280x720 resolution display (with the upscaling from that performed by the OS, not by NeoLemmix). I will account for (a) the most common cases, (b) cases that I personally use, or (c) cases that anyone else mentions they personally use.
- When unzoomed, the standard skill panel is 416px wide.
- When unzoomed, the compact skill panel is 320px wide.
- Both skill panels are 40px tall. Irrelevant here, but mentioning for completeness's sake.
- These widths include the minimap, and the height includes the information text above the actual skills. In terms of NeoLemmix's internal workings, this entire area is the skill panel, and is rendered / zoomed as one large area.

Again - please let me know if you use a resolution or zoom factor not covered here, so it can be taken into account to decide whether widening is feasible.

Resolutions overview

Sample resolution
- Standard panel: Current {#1}, +16px {#2}, +32px {#3}
- Compact panel: Current {#1}, +16px {#2}, +32px {#3}
- Importance: {How important do I think accounting for this resolution is?}

#1 - The maximum zoom level the panel can be displayed at, at the current size.
#2 - The maximum zoom level the panel could be displayed at, if the width were increased by 16px.
#3 - The maximum zoom level the panel could be displayed at, if the width were increased by 32px.

640x480
- Standard panel: Current (1x), +16px (1x), +32px (1x)
- Compact panel: Current (2x), +16px (1x), +32px (1x)
- Importance: Probably very low. I suspect few people use this anymore.

800x600
- Standard panel: Current (1x), +16px (1x), +32px (1x)
- Compact panel: Current (2x), +16px (2x), +32px (2x)
- Importance: Also probably very low and not much used anymore. Not to mention, it's completely unaffected by the addition of even 32px, on either panel.

1024x768
- Standard panel: Current (2x), +16px (2x), +32px (2x)
- Compact panel: Current (3x), +16px (3x), +32px (2x)
- Importance: Probably the most common resolution among 4:3 holdouts, so maybe a bit more important than the other 4:3's.

1280x720 and 1280x1024 (Also: 1920x1080 with 150% scaling; 2560x1440 with 200% scaling; 3840x2160 with 300% scaling)
- Standard panel: Current (3x), +16px (2x), +32px (2x)
- Compact panel: Current (4x), +16px (3x), +32px (3x)
- Importance: 1280x720 is probably quite important; as most 1080p displays (which are becoming increasingly common) are by default set to 150% scaling.

1366x768
- Standard panel: Current (3x), +16px (3x), +32px (3x)
- Compact panel: Current (4x), +16px (4x), +32px (3x)
- Importance: Pretty much the most common display resolution these days, especially for laptops, so very important.

1536x864 (Rarely if ever used directly, but 3840x2160 at 250% scaling is this)
- Standard panel: Current (3x), +16px (3x), +32px (3x)
- Compact panel: Current (4x), +16px (4x), +32px (4x)
- Importance: I believe 250% is the default scaling for 4K screens, although 4K screens themself aren't too common yet. But regardless - this one needs no special attention, as everything fits.

1650x1050
- Standard panel: Current (3x), +16px (3x), +32px (3x)
- Compact panel: Current (5x), +16px (4x), +32px (4x)
- Importance: Was common on slightly older hardware, I believe it's pretty rare on newer gear.

1920x1080 (Also: 3840x2160 at 200% scaling)
- Standard panel: Current (4x), +16px (4x), +32px (4x)
- Compact panel: Current (6x), +16px (5x), +32px (5x)
- Importance: Although the resolution itself is very common, use of it without some >100% scaling is rare (though not unheard of - I myself prefer to be at 100% scaling on a 1920x1080 display). However, one counter-argument there is that an effective resolution (ie: the resolution NeoLemmix thinks it's running at, before OS scaling is applied) of 1920x1080 is pretty much the highest that NeoLemmix runs smoothly at even on high-end hardware, so some people might deliberately aim for this.

2560x1440
- Standard panel: Current (6x), +16px (5x), +32px (5x)
- Compact panel: Current (8x), +16px (7x), +32px (7x)
- Importance: Low. NeoLemmix doesn't run smoothly anyway when (it thinks) it's running at resolutions this high.

3840x2160
- Standard panel: Current (9x), +16px (8x), +32px (8x)
- Compact panel: Current (12x), +16px (11x), +32px (10x)
- Importance: Low. NeoLemmix doesn't run smoothly anyway when (it thinks) it's running at resolutions this high.

Overall - the compact panel gets hit much harder by this than the standard one, going against the whole reason it was implemented. This alone might be grounds not to do this for the compact panel (as there's no rule saying we can't eg. increase the with on the standard one, while shrinking the minimap or shrinking the pause / nuke buttons on the compact panel).

The standard panel on the other hand is only affected, out of the common cases, at a (perceived) resolution that's 1280px wide; or at resolutions where NL won't run well anyway. But 1280px wide is one of the most common, possibly even the most common, resolution widths, so it definitely needs to be considered...

[mobius]

Hard-binding Esc is conceivable, I have no opinion on this.

Removing dir select buttons: Careful. What you remove from the UI, the new player will not try. People will not read manuals. Level designers get crazy about making their own skill tutorials (unnecessary, skills are in the panel, tutorial pack exist for skill subtleties that level designers can miss anyway) but haven't/won't make directional select tutorials (with good reason, it's the job of the engine to explain it). Also people won't play tutorials; people play packs, and not every pack has that; if every pack had that, people would skip it. Lix has tooltips for dir select whenever two opposing lixes are under the cursor, but I haven't user-tested those tooltips.

Splat ruler should get a button?

I feel it important to point out that people have been using the directional select literally years (it first existed in the windows port? so 1996ish) before it ever gotten buttons on the skill panel in NL. Again I point out that many games nowadays features so-called hotkeys and no buttons. Pressing keys without any kind of visual button the screen is very common.

Tooltips is an excellent device for new players. I usually find them very helpful in any game/program.

Since everybody is in disagreement over the skill panel maybe making the whole game size bigger as namida suggests in the best solution.

-------------
another idea on 'removing' a button is to place the release rate change function up to overtop of entrances (this is how Revolution worked--you left or right clicked the entrances and the number appeared temporarily above it). That would free up one more space.

[namida]

Again I point out that many games nowadays features so-called hotkeys and no buttons. Pressing keys without any kind of visual button the screen is very common.

Most games nowdays also have gameplay not even remotely comparable to Lemmings. Probably the closest would be RTS games; I'm not familiar with the super-modern ones, but I recall every game in the Age of Empires series would have on-screen buttons for everything - albeit with some of the more advanced features hidden if you don't enable an "advanced mode".

another idea on 'removing' a button is to place the release rate change function up to overtop of entrances (this is how Revolution worked--you left or right clicked the entrances and the number appeared temporarily above it). That would free up one more space.

This might give the impression that each entrance's release rate can be adjusted independently.



I just took a look at what the compact panel looks like - I haven't used it in so long, that I didn't remember off-hand. I know the DOS L1 skill panel (which is also 320px wide) would have room for two more skills, by removing some of the filler between the panels and the minimap / to the right of the minimap - but NL's compact panel has made use of this space for a fast forward button and an increase to the minimap width.

Perhaps this can be reversed - shrink the minimap a tiny bit and remove the fast-forward button. This makes room for two more skills on the compact panel. On the full-size panel, we've got 8 utility buttons that aren't stacked - Pause, Nuke, Fast Forward, Restart, Framestep Back, Framestep Forward, Clear Physics, and Load Replay. (We also have two buttons for directional select, but these are stacked.) Maybe we can stack some of these - I would definitely be okay with stacking the framestep ones in the same way as the directional select. Maybe Fast Forward and Restart can also be stacked - and then, viola, we've got room for two more skills. Perhaps we could stack even more aggressively, to also give a slightly wider minimap - I think this is more beneficial than these buttons being full-height.

[namida]

Poll results are strongly in favor of a small increase (6 votes for small increase, 3 votes for no limit, no votes for keep as-is or large-but-still-limited increase).

Although the poll didn't suggest an exact number, discussion has very strongly favored setting the new limit at 10. Is there anyone who would prefer a different amount for the new limit, other than for reasons along the lines of "it should be as high as possible"?

Personally, I'd lean towards 10, but I would also be okay with 12, provided we can find a way to make it look nice on the skill panel. (I feel an odd number would be weird, that's why I didn't suggest 11.) I personally can't recall any case where I've wanted to use 10, but can recall several where I've wanted to use 9 - but again, even number is preferable to me here, and I think 10 is still a reasonable amount, as well as probably still relatively easy to fit into the skill panel.

That aside, any further comments for how this should work for the skill panel?

At this point, I feel very strongly against the following:
- Any kind of scroll or page-flip (can be hard to follow for the player)
- The same button being a different size on the compact panel vs the full-size panel (difficult to implement)
- Increasing the dimensions of the panels, especially the compact panel
- Vertical-stacking the release rate button (the only logical way to do this, that still displays all information currently displayed, gives an ~8x7 pixels pre-zoom area each for - and +)
- Removing the Pause or Nuke buttons (could leave players without a known way, or in rare cases any way at all, to pause and exit gameplay respectively)

So I think it's down to these options:
- Removing any of the function buttons (other than Pause and Nuke)
- Shrinking the minimap
- Dynamically resizing the minimap when extra skill slots are needed
- Vertically stacking some of the existing buttons - any stacking must apply to both panels
- Some combination of the above

With resizing the minimap - it should be noticed the minimap size on the full-size panel can only decrease, not increase - it would overlap with the time limit / time taken, otherwise. It could indeed get wider on the compact panel, but it's already wider there - what it lacks on the compact panel is height, but not much that can be done about that.



My preferred overall approach at this point - assuming 10 skills here, still - is as follows:

Full-size skill panel - Vertically stack the framestep buttons, and two other buttons - I'm thinking fast-forward and restart, though I don't feel particularly strongly about it. This makes room for two more skill buttons.
Compact skill panel - Remove the fast forward button. Shrink the minimap by 16px (making it the same width as the minimap on the full-size panel). This makes room for two more skill buttons.

I'd rather not lose minimap width on the full-size panel, and the dynamic resizing would be quite a lot of work to implement. The above should be fairly straightforward to do.

[GigaLem]

I think the least harmful option would to just shrink the minimap, it'd still be visible even if its just 16px smaller.
Vertical Stacking some buttons may also prove useful, but it'll depend on its execution.

[Minim]

I voted for all the skills on the panel, but I don't mind 10. I'm starting to agree that that's a reasonable enough amount.

Going for one of namida's plans of removing any of the functional buttons, I'd keep the minimap's size as it is, and remove the frame step buttons. I think these icons will cause new players the most confusion, as they might assume that these are directional buttons. I also realise that some of the other functional buttons will need to be moved to make sure the skills work properly.

[IchoTolot]

I would choose out of these options:

- Shrinking the minimap / Dynamically resizing the minimap when extra skill slots are needed
- Vertically stacking some of the existing buttons (Directional select would be the first target)

[namida]

- Vertically stacking some of the existing buttons (Directional select would be the first target)

Directional select is already vertically stacked.

[IchoTolot]

Directional select is already vertically stacked.

Sorry, I meant single frame-stepping.

[mobius]

what about vertically stacking the RR buttons as well?

I almost never use the "non-compact skill panel" btw, since I'm used to the old one I found no need for the the other buttons. Admittedly I forgot about how many buttons there are now. Considering all these buttons maybe double stacking the panel would be best. In other words have two layers: one for the skill and one for the other buttons. As long as a compact option is still available I won't complain; as I intend to keep using that. The non-compact is not necessary for me; too complicated, and the buttons themselves are too small.
About new players: as pointed out by others they may likely not understand what they do even having them there to see and use. So I don't think it's wholly a matter of ease for new players. For new players simpler is better.

Shrinking the minimap: this would just make the problems I pointed out with it even worse; making it even more useless. Why not just get rid of it?

[namida]

what about vertically stacking the RR buttons as well?

At this point, I feel very strongly against the following:
[...]
- Vertical-stacking the release rate button (the only logical way to do this, that still displays all information currently displayed, gives an ~8x7 pixels pre-zoom area each for - and +)

Unless there's huge support for it, consider this ruled out simply due to the result being kind of impractical.

Double-stacking everything, with full-height buttons, isn't practical. With reduced-height buttons, we'd have to be okay with the buttons being smaller on the compact panel too - I don't want to deal with the same button being different sizes on each panel.

[namida]

Made some progress on this. I've changed the existing code so that the limit of 8 is no longer hardcoded into it; instead, a single constant is specified which sets the skill limit (currently at 8) - with, of course, the catch that changing this constant doesn't automatically make room on the skill panel; so the count can be reduced, but not increased.

I've also tested and confirmed that, if I remove a couple of the other buttons to make some room, increasing the limit works fine - so at this point, I just need to modify the skill panels to make room for it.

EDIT: Aaand, done. (For the compact panel, the Fast Forward button is removed and the minimap is 16px less wide.)