[SUG] Option to display Spawn Interval instead of Release Rate

Started by Dullstar, March 02, 2023, 07:40:29 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Should SuperLemmix include the option to display Spawn Interval instead of Release Rate?

Yes, I like to know precisely what to expect when changing this value in-game
2 (33.3%)
Yes, because I used it in NeoLemmix and I'm now accustomed to seeing it displayed that way
2 (33.3%)
Yes, for a reason not mentioned above (please reply)
2 (33.3%)
I don't mind either way
2 (33.3%)
No, because I don't want my levels to be played in such a way that this figure could needlessly be interpreted too precisely
1 (16.7%)
No, because I prefer the OG way of doing things
1 (16.7%)
No, for a reason not mentioned above (please reply)
0 (0%)

Total Members Voted: 6

Voting closed: March 23, 2023, 10:44:38 PM

Simon

Quote
You can do the same with RR, how is SI more helpful in this case?

Right, for memorizing specific values, all scales work. We can define Blub = 2SI and memorize useful values in Blub.

It's merely easier to learn one scale than several. SI has advantages elsewhere. If RR were a useful abstraction, sure, it would help thinking here. But RR doesn't help here, and it's not a useful abstraction elsewhere either; it's a longcut elsewhere.

Pruning longcuts, much like pruning rubbish, tends to allow efficiencies and progresses that are hard to even imagine otherwise. E.g., the insight with the prime spawn intervals to produce nice-looking holding pits: Yes, after explanation, it's understandable in either scale, but it's immediately obvious in SI even before explanation. Or, e.g, how efficent framestepping and replay insert mode were designed to avoid undo from scratch, but have led to novel ways of level solving and experimentation. If you understand this, you should understand why, if given the ternary choice between L1 RR, NL RR, or SI (ignoring your numberless widget for now), I have a deep preference for SI beyond mere familiarity.

Contrast longcuts with abstraction, e.g., allowing the player to toggle only between fast/slow spawn interval. There is little need for precise numbers. Fast/slow looks like a useful abstraction here.

QuoteUltimately, though, it's necessary to learn which values are useful for either RR or SI. You've learned SI, hence your preference.

Learning, yes.

But familiarity is only one source of my preference.

I've considered the reasons for SI before I learned it. Those reasons still hold after all these years, I still enjoy the benefits, and I like those benefits. The familiarity grew only afterwards.

Unfamiliarity is only one source of frustration, the obvious source, when you don't provide SI, but nonetheless provide RR, especially NL's RR. You'd give me 98 % of what I want and then refuse to give the obvious and easy remaining 2 %. It would be insidious. But there is also the deeper annoyance in how RR is not a useful abstraction of anything, and there is dissatisfaction in seeing that inflicted.

When I argue for SI, I feel as Michael Hartl must feel when he argues for τ = 6.28... instead of π. Tau is the more useful concept and incurs no drawbacks other than breaking tradition. Yet it's so hard convincing others of that usefulness. People want what is familiar and perceive that as simple, or as on equal footing.

Quote from: WillLem on March 10, 2023, 07:21:45 PM


The gut reaction is that I like this widget better than displaying 103 − SI and better than 107 − 2 × SI. This feels sufficiently far removed from the precise numbers, yeah.

Depends on how fine-grained that widget will react to mouse clicks. Will it inflict pixel-precise clicking on top of learning another scale?

Consider ditching variable spawn interval altogether. That will cut all annoying RR fidgeting and give you panel space to boost. An instant fix for all your problems!




Related to the familiarity argument: Lix github #441: The editor should visualize the chosen spawn interval, e.g., with a picture or animation right beside the SI-setting widget.

-- Simon

WillLem

Quote from: Simon on March 14, 2023, 06:43:01 AM
It's merely easier to learn one scale than several

I've learned RR. Sure, I could learn SI as well, then I guess I'd have more ways of understanding what is essentially the same thing.

I guess the question I should be asking really is how does SI translate to what's seen on-screen in a way that RR specifically does not? Maybe this will help me to see why it's more useful, because at the moment it just looks and feels like an equally useful way of enumerating the RR effect, not a more useful one.

Quote from: Simon on March 14, 2023, 06:43:01 AM
Yes, after explanation, it's understandable in either scale, but it's immediately obvious in SI even before explanation

How?

Quote from: Simon on March 14, 2023, 06:43:01 AM
The gut reaction is that I like this widget better than displaying 103 − SI and better than 107 − 2 × SI. This feels sufficiently far removed from the precise numbers, yeah.

If I knew how to code the slider, I'd probably do it! At the moment it's nothing more than a mockup graphic.

Quote from: Simon on March 14, 2023, 06:43:01 AM
Depends on how fine-grained that widget will react to mouse clicks. Will it inflict pixel-precise clicking on top of learning another scale?

I suppose this depends entirely on how many pixels the graphic can be. If, say, 40px high with 33 of those being value-assignable, then each pixel would increase the RR by 3.

Quote from: Simon on March 14, 2023, 06:43:01 AM
Consider ditching variable spawn interval altogether. That will cut all annoying RR fidgeting and give you panel space to boost. An instant fix for all your problems!

Heh! Tempting for sure, but doing this would break many levels in L1 and OhNo!, requiring lowered lem counts and/or raised time limits to fix the levels. Yes, SLX is not interested in content preservation, but the OG levels are an exception since they're bundled with the app and a lot of what I'm doing with SLX is aimed at making those levels relevant again.

Besides, I've always liked the variable RR feature and it's definitely something I would want to include anyway, even if building a brand new Lemmings clone from scratch (I'd almost certainly do it as a slider).

Finding a way to make it fit only 1 button space is a tempting prospect, though. Perhaps the existing split-button code could come in handy here, and the number could be displayed in the centre...

WillLem

Currently, I'm leaning much more towards not including the option. There are 3 main reasons for this:

1) I'm currently attempting to add it into the Config menu such that it's {unchecked and unavailable} when in Classic Mode. This is easy to achieve in itself, however it may lead some users who prefer the SI display to not hit the "Activate Classic Mode" button, and instead individually check all of the Classic Mode options that are displayed in the config.

The problem with this is that those users will not actually be in Classic Mode, since the mode actually implements a number of other features which affect gameplay (assign-whilst-paused, min/max RR jumping, savestates and replay behaviour, etc) but which don't warrant having their own checkbox. NOTE: This is explained in a "hint" when hovering over the "Activate Classic Mode" button, so these additional features are not completely "hidden" from the user.

It's my guess that those who want to use Classic Mode will prefer the RR display. So, as a compromise, activating Classic Mode will {uncheck} the "Activate Spawn Interval Display" checkbox, but keep the option {available} for re-checking. This is so that those who prefer SI don't have to resort to the above workaround. It's a wonky solution to the problem, though, and I'm now that bit less happy with the formerly cleaner Config menu.

So, when re-implementing the option I have to choose between 'keep the config menu clean' and 'always display RR in Classic Mode'; it's not really feasible to do both. Meanwhile, my own preference of not including the option at all satisfies both of these conditions.

2) I still haven't really seen a compelling argument as to why offering both RR and SI as hatch-speed-displays is worth it. OK, the votes have been somewhat in favour of keeping the option, but there have also been a couple of "don't mind" votes, and of course there are my own feelings on it.

3) I'm currently designing a new panel which will ideally have the button graphics drawn directly onto it; retaining support for displaying SI in this scenario will become even more problematic, since the individual -/+ graphics will (again, ideally) no longer exist to be swapped.

Simon

I want to buy a car. I pick one and ask the dealer for how much it costs. He says: −29,897 Rrollars. I'm happy because the figure is very useful to me. After all, I know that I have to pay less than that other model at −34,897.

I want to get a job. I'm negotiating a salary. Should I negotiate a yearly salary figure (that's paid in 12 parts, one per month), a monthly salary (that's paid as-is), hmmm, I think it's most useful to negotiate a 8-year-7-month salary figure (that's paid in 103 parts, one per month). The HR person is very happy about this and hires me. He won't have to convert anything and can immediately type my offer into his system that records 8-year-7-month salaries, the industry standard.

I want to post an enumerated list. Instead of 1), 2), 3) as you did, I write 102), 101), 100), 99). Nobody bats an eye because these numbers are very useful.

New keyboards will be produced. Instead of the "1" key, they have a "102" key. If we don't want the two extra digits when we type, we can erase them afterwards every time. I'll buy this keyboard, I think that keyboard is as useful as the ones we have. 102 is a natural figure to type often; after all, most people start counting from here.




This is how RR relates to things on the screen.

If it hasn't sunken in from this, I doubt I can help you understand the issue better. There are UI considerations other than swapping the buttons, e.g., you make a symbol for fast and a symbol for slow, then you don't have to swap them. But if you don't gain insight into why some ways of presenting figures are more useful than others, I doubt I can convince you to invest even more work here.

-- Simon

Simon

Quote from: WillLem on March 15, 2023, 12:13:11 AM
how does SI translate to what's seen on-screen in a way that RR specifically does not?

See attachment. The SI of 28 manifests on the screen in the distance between lemmings.

Nowhere here you see the value 50 (= 107 − 2 ×28 + off by one) or 75 (= 103 − 28).

-- Simon


WillLem

Quote from: Simon
I want to post an enumerated list. Instead of 1), 2), 3) as you did, I write 102), 101), 100), 99). Nobody bats an eye because these numbers are very useful.

RR looks like this to me:

1, 2, 3, 4, 5, 6, 7, 8, 9 ... 99, with the lowest number meaning "lems come out slowly" and the highest number meaning "lems come out quickly." This makes sense, works as I need it to in-game, and no further information is required.

SI, on the other hand, looks like this:

107, 106, 105, 104 ... 4, with the highest number meaning "lems come out slowly" and the lowest number meaning "lems come out quickly." OK so far, I guess, but now I need more information ... why is the lowest number 4? Why does it stop at 4 and not go all the way to 1? Why does it start at 107? These are questions that, as a player, I am bound to ask whether I've seen a Lemmings game before or not.

So, maybe I take the time to find out that it's the number of pixels between lemmings. OK, I understand it a bit more now but... is the game really going to expect me to know about pixel distance between lemmings? As a casual player, that's a bit of a red flag!

1 - 99 is intuitive and simple; I can see that, when the number is higher, the lems come out faster. A scale going from 107 - 4 makes far less intuitive sense to me personally, even when I know what it means. I don't care about the exact pixel distance between the lems, I only care how it translates to what's actually happening on screen, and I can find out by playing the game what sort of figures are useful.

Quote from: Simon
New keyboards will be produced. Instead of the "1" key, they have a "102" key. If we don't want the two extra digits when we type, we can erase them afterwards every time. I'll buy this keyboard, I think that keyboard is as useful as the ones we have. 102 is a natural figure to type often; after all, most people start counting from here.

Heh, good way of illustrating your point :crylaugh: But, I don't actually agree that RR presents this sort of problem. "Low is slow, high is fast" is all the player needs to know, and wherever exact figures come into play, "RR75" means just as much as "SI28" if what you're seeing on screen is the same result.

Quote from: Simon
you make a symbol for fast and a symbol for slow, then you don't have to swap them

Yes, great idea. UP and DOWN arrows could work, or maybe a single right-facing arrow for "slow" and 3 stacked right-facing arrows for "fast"; I'll see about making a split button with the number displayed in the centre. That way, continuing to support both RR and SI should be easy enough even without graphic-swapping. That solves the third issue.

If the votes remain as they are, I'll likely keep the option and not try to crowbar it into Classic Mode. That way, I can forget about it, those who want to use it can do so, and the Config menu is kept relatively clean and tidy.

WillLem

OK, so now that I've had a few days break from working on SuperLemmix, I've realised that there is actually a very easy fix to the SI/Classic Mode conundrum that was previously eluding me, most likely due to learning burnout.

Basically, I want Classic Mode to always display RR, and I was attempting to implement this via the Config perameter checkboxes, which was a very messy way to do it, both for the UI and in the code itself.

The correct way to do it, of course, is to simply add "and not GameParams.ClassicMode" wherever there is an "if GameParams.SpawnInterval" statement.

This has now been done, and it's tested and working, so I'm that much happier to re-implement the option :)




And it's done. Re-added in Commit f8e154773