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

[Dullstar]

For what it's worth, when NL redefined Release Rate in order to remove the duplicated values in the original, I switched my config to Spawn Interval because I figured if I was going to have to relearn the values, I may as well use Spawn Interval because the definition is very unambiguous about what you get when you use it: the spawn interval is the number of frames between spawns, whereas release rate is an entirely arbitrary scale.

[WillLem]

Added a poll.

It wouldn't be too much work to add this back in, but I'd personally rather not. If there is enough interest in the feature, I'll definitely consider it for the next release.

[WillLem]

2:1 in favour of no Spawn interval. I'd have to agree, so... I'll leave it as it is

[Simon]

2:1 in favour of no Spawn interval.

I don't think Dullstar has even voted. The 1 vote for spawn interval is mine.

Do non-maintainers who prefer the release rate really want to force their default on everybody? There would be no strong reason behind it. It can't be diversion of your time: NL has implemented the choice already. You'd spend more time removing the feature than just leaving it in place.

If the poll wording is accurate, then your intrerpretation is off. You ask X if X wants Y, the answer is no, then you draw the conclusion that X wants Z to not have Y.

The NL level format has spawn interval because it's unambiguous. Like Dullstar, I have no feeling for NL's arbitrary values either, other than how 99 means 4.

-- Simon

[WillLem]

NL has implemented the choice already. You'd spend more time removing the feature than just leaving it in place.

It takes up space in the config menu, and it's a feature I'm not particularly keen on. So, the decision to remove it is in part based on my own preference, as I stated in the post announcing the poll. I'm aiming to streamline the interface and revitalise the original game's aesthetics. RR is very much part of this.

You ask X if X wants Y, the answer is no, then you draw the conclusion that X wants Z to not have Y.

Don't quite follow you here tbh. I haven't asked anything about what people want for other users, that isn't part of the question. I'm asking X if they want Y; there is no Z in the equation.

FWIW, I've spoken to Icho about this on Discord and have realised that I need to be way more careful about my poll-taking now that I'm an active developer rather than simply a participant in the discussion. From now on, I'll be more clear about exactly what I'm asking and what results (if any) pollers can expect.

Chalk this one up to experience. Poll is closed, the new config will stay as it is.

[Simon]

YIKES! I pressed Modify instead of Quote, I keep doing this out of habit. Can the original message be re-instated? - WL

Simon: Not automatically, but I'm retyping from your quotes and from memory.

original game's aesthetics. RR is very much part of this.

Well, remember to revert to L1 RR then, where RR 1 is SI 53 and you have two RR values per SI value.

I haven't asked anything about what people want for other users, that isn't part of the question. I'm asking X if they want Y; there is no Z in the equation.

Options like this one (that we expect each player to set once and then stick for years with the setting) are always for other users (Z).

(A short paragraph about perfidous wording of the poll.)

But you can do what seems right to you. It's a free world. You can inflict the conversion of the spawn interval (what both the format explicitly and engine internally already use) to 107 − 2 × SI like L1 does, instead of showing the meaningful value as it is. You can do it even despite two people here spending their time to discuss SI/RR instead of working on their own projects.

Take the rant with a grain of salt. I've become involved with SuperLemmix via creating the board and discussing Lix's timing code. I'll be interested in all progress towards the zoom bug, and I'm looking forward for cross-pollination. I merely doubt I'll play SuperLemmix much with all the removed convenience.
   
-- Simon

[Dullstar]

Simon correctly deduced that I didn't vote in this poll, and I can see from the timestamps exactly how long it was open. I can never remember if the forum software gets my local timezone right, though, so I can't be certain what I was doing during that time, but I think we can all agree that it's a little silly to not get your voice heard because you were busy with something else when the poll happened -- it's not like I knew it was coming ahead of time to be able to make time for it!

Simon has already touched on making sure you understand how you're interpreting "no" votes. He correctly notes that "You ask X if X wants Y, the answer is no, then you draw the conclusion that X wants Z to not have Y." You at least had a "don't care" option, but that doesn't necessarily mean people won't just vote for their preferred option. If we're debating if something should be an option or not, and I already prefer the default, then there's not a strong incentive to keep that option alive because I get what I want regardless. Sometimes it's worth fighting against the option, if you can make a case why the option is a problem (e.g. the old debates on having direct drop as an option for the user or developer, where the inconsistent engine behavior can lead to problems with level design), but I don't think this is one of those times, as SI vs. RR is purely cosmetic.

Generally, I'd say 24 hours is a minimum time you should leave a poll open, and ideally probably a week. There forums don't generally move very quickly, so it's quite realistic to expect many people may only check once a day; maybe a few times a week; or even once a week! Only call it early if it's extremely one-sided, and err on the side of caution (if in doubt, don't close early). You may have thought this poll was one-sided, but it wasn't open very long, and there were only 3 votes. If a high ratio regardless of the number of the votes is the sole criteria for deciding when to call a poll, then you may as well just close every poll after the first vote, because 100% of people who voted picked whichever option the first voter picked.

I could probably make a case that you closed the vote early because it showed the result that you wanted, and I'm not sure a reputation for biasing feature votes in your favor is something you want if you want your development journey to be relatively drama free.



Incidentally, I believe I asked you a while back what your design philosophy for SuperLemmix was, when I was suggesting you should really decide who you're targeting this to instead of trying to make everyone happy, and you said you wanted to try to make everyone happy.

Now, making everyone happy is pretty much impossible (see: timed bombers), but you're now actively failing what's pretty much a freebie test: you say you want to try to make everyone as happy as possible, and then you go cull some random harmless cosmetic option nobody complained about that wasn't causing anyone any problems because you don't like using it.

[WillLem]

Well, remember to revert to L1 RR then, where RR 1 is SI 53 and you have two RR values per SI value.

I realise you've said this partially in jest, but just to take the point seriously for a second... it's the aesthetic of the RR that interests me more than the actual numbers.

The fact that RR is arbitrary means that you're concentrating more on its actual in-game effect rather than mathematically working out with pinpoint accuracy what the expected result of changing the figure should be. I'm less interested in trying to preserve or encourage that sort of gameplay with this engine, since doing so was virtually impossible in OG Lemmings and that's partly what makes it enjoyable for me personally.

Options like this one (that we expect each player to set once and then stick for years with the setting) are always for other users (Z).

Noted, and lesson learned. As I've said, I'll be more careful with polls in the future.

You can inflict the conversion of the spawn interval (what both the format explicitly and engine internally already use) to 107 − 2 × SI like L1 does, instead of showing the meaningful value as it is

Grain of salt added

I'm only doing what I feel is right based on preserving the aesthetics of the game I enjoy, not trying to inflict annoyance on anybody. I really hope that you and anybody who plays SuperLemmix understands that.

I merely doubt I'll play SuperLemmix much with all the removed convenience.

I'll give you the removal of the SI option if you really want to see that as removed convenience, but other than that all of the player-helper are still available in SuperLemmix; Classic Mode toggles them all off in one go, but you don't ever have to play in Classic Mode if you don't want to.

The only exception to this is Activity Projection Shadows (not to be confused with Skill Shadows), which I feel are way too big a step in the direction towards reducing Lemmings to a 'picture puzzle' (as opposed to a motional video game) - these have been removed. But I have no plans to remove any of the others, even I use them much of the time and I agree they're excellent for helping the player to work their way through a level.

Ultimately, I just want players to also be able to enjoy the game as it was first designed - Classic Mode is an additional feature, not a subtractive one.

it's a little silly to not get your voice heard because you were busy with something else when the poll happened
---
it's not like I knew it was coming ahead of time to be able to make time for it!

The poll was open when you posted your reply, so I'm not sure why you didn't see it? Genuine mistake, I've just seen that I added the poll after your initial response. My apologies.

Simon has already touched on making sure you understand how you're interpreting "no" votes
---
I'd say 24 hours is a minimum time you should leave a poll open, and ideally probably a week

Yes, and I've already addressed this. I will take more care with polls in future. I've closed this one earlier than I usually would for this reason; I now regret having the poll at all. I made a decision to remove the feature and I'm happy to stick with that decision.

I could probably make a case that you closed the vote early because it showed the result that you wanted, and I'm not sure a reputation for biasing feature votes in your favor is something you want if you want your development journey to be relatively drama free.

Two things here:

1) I didn't close the vote early, I closed it today in response to Simon's comments which made me realise I do need to be a bit more careful with polling now that I'm an active developer.

2) I don't appreciate you outright accusing me of biasing the vote, I didn't do that. I commented that I was happy to leave the option as-is after I saw the 3 votes were swung that way and the poll had been open a couple of days at that point, but I left it open just in case things changed.

I'm not going to rise to the rest of your comment, but I'd appreciate it if you'd stop speaking to me with the condescending and antagonistic tone you're currently choosing to employ. SuperLemmix is a learning experience for me and a bit of fun which I'm happy to share with other fans of Lemmings. If you don't like what I'm doing with it, then you can ignore it, or by all means do as you've suggested you might do and go ahead with your own fork with features that you like, nobody is stopping you.

[WillLem]

Can't believe I forgot to mention this, but one of the biggest reasons I decided to cull the SI/RR option is because the current codebase only supports up to 32 options. Since I have implemented a lot of new options (and have plans to add even more), something had to make way, so I chose to cull options that I either don't agree with or don't see a use for.

With that said, from now on I don't wish to needlessly antagonise people by removing a feature that they may be used to, rely on and/or enjoy without giving the opportunity to discuss it first. So, I'm re-opening the poll for the SI/RR option. I'll wait until it reaches 10 votes either way (pollers can choose 2 options, so that's at least 5 people voting), or until 2 weeks from today, (whichever comes first), before making a final decision on it.

Note that my decision may not necessarily reflect the votes. I want to get rid of the option, so votes to remove it will have more weight, naturally. Reasons matter as well; I'd appreciate some feedback as to why keeping the option is important, for those that have voted to keep it. So far, the fact that it allows more precise use of the "hatch speed" isn't really a convincing enough argument to keep it, since I want to try and remove that level of precision from the game generally, and therefore it convinces me further that removing it is the way to go.

It has previously been suggested that there should be as few as 5 speeds for RR: 1, 25, 50, 75 and 99 (which could be re-labelled as Super-Slow, Slow, Medium, Fast and Super-Fast, for instance). I prefer this idea to allowing the Spawn Interval to be displayed, because SI is too close to the inner workings of the game and not far enough removed that players are concentrating on the effect rather than the numbers.

The only reason I'd rather not implement the 5-speeds idea is because I do hold the OG as a standard to aim for rather than deviate from, as many of its sequels, clones and remakes have done. And, I personally prefer more variation than having only 5 speeds would allow. So, I mention it only as a comparison (i.e there are things I'd rather do than display Spawn Interval that I won't be doing). Since SI is a feature that's been around for a while and that players may be significantly used to, though, it's up for discussion.

So, the conversation and voting is re-open and I'm genuinely interested to hear what people have to say. If no arguments for keeping the option are forthcoming, or if not enough people are interested enough to vote, then the option will remain culled.

[Proxima]

It has previously been suggested that there should be as few as 5 speeds for RR: 1, 25, 50, 75 and 99 (which could be re-labelled as Super-Slow, Slow, Medium, Fast and Super-Fast, for instance). I prefer this idea to allowing the Spawn Interval to be displayed, because SI is too close to the inner workings of the game and not far enough removed that players are concentrating on the effect rather than the numbers.

The only reason I'd rather not implement the 5-speeds idea is because I do hold the OG as a standard to aim for rather than deviate from

It feels odd that you should use that as an argument against the "5 speeds" idea. Sure, L1 uses a wide range of different release rates, but "Flow Control" is the only level where changing the RR is part of the solution, and in "Flow Control", the intended solution just switches between the level's original release rate (50) and 99, while the "disable the traps" solution leaves the release rate at 50 throughout. A few levels require setting the release rate to 99 so as to finish within the time limit. But fine-tuning the release rate is almost entirely the domain of challenges (especially with the sliding glitch) rather than intended solutions.

I tallied up the number of times each release rate is used in L1:

Spoiler

1: 18
10: 5
15: 1
20: 11
30: 3
40: 5
50: 37
55: 3
60: 4
66: 1
70: 6
75: 1
76: 1
80: 6
85: 2
88: 2
90: 2
99: 12

So, a large number of different RRs are represented, but one can't help noticing that most of them are very rare, and the designers seem to have been pretty content with just 1, 20, 50, a cluster around the 75 area, and 99. It's even more stark when one looks at ONML. There, the only values used more than once are 1, 5, 10, 20, 50 and 99. (It's interesting that 5 appears on the list, after being unused in L1 -- it's so close to 1 that you would not notice any difference in play.)

Since ONML was designed second, this really looks as though the designers themselves realised that the game didn't need so many gradations in release rate....

[Proxima]

One possible system would be to have a single-digit release rate, with the following values:

1 = SI 100 (round number, and close to NL's slowest possible SI, 102)
2 = 80
3 = 60
4 = 50 (close to RR 1 = SI 53)
5 = 40 (close to RR 25 = SI 41)
6 = 28 (RR 50)
7 = 16 (RR 75)
8 = 10 (RR 87 -- a key value because of the builder turnaround trick)
9 = 4

[Simon]

current codebase only supports up to 32 options.

That sounds odd, I'd recommend to investigate. A small and hard limit that is also nontrivial to raise?

I'm genuinely interested to hear what people have to say

I checked "Yes, accustomed" and "Yes, reason not mentioned (please reply)".

During play, the displayed initial spawn interval is for eyeballing, and I have feelings for it. E.g., spawn interval 60 gets the second lix stuck in first lix's digger pit, but 50 is too quick. I also have feelings for L1's RR 1, RR 50, and RR 99. With NL's RR, I have only a feeling for NL's RR 99, and for nothing else. When I see other people play and they have set NL to RR, I'll ignore it, or convert it in mind to L1 RR or spawn interval.

I don't like levels with precision RR fidgeting. I'll solve those by trial-and-error, not by exact math, and they're annyoing. It helps a little if I have a feeling for what the numbers mean. But this little isn't strong enough to make me check "know precisely what to expect when changing this value in-game". Thus, if WillLem wishes me to avoid exact math, then forcing RR over SI will not progress towards that goal. I don't do it in the first place, and if it's inevitable, I'll do it regardless of SI/RR and would then merely get annoyed from RR.

(Reminder that I don't foresee playing SuperLemmix much, given how I haven't played NL much outside contests.)

Here's an aspect from level design, not from play.

When I design a level, I want the initial spread of lix to look natural and unsystematic. That comes in two variations:

• Walking lix shall show different sprite frames.
  
• In a holding pit, lix shall spread, they shall not stack perfectly.
  

Therefore, I like to choose, during level design, an odd spawn interval (because the walker's animation cycle has 8 frames) that's away from nice divisors of the holding pit's length. In reality, I'll eyeball the rough interval, pick a nearby prime number at random, and test a few times to see how it looks.

With L1 RR or NL RR, it's not immediately obvious which numbers will make odd intervals, and they obscure entirely which numbers make prime intervals.

If Proxima's round values were the only ones allowed, I'd design odd-length holding pits instead.

-- Simon

[WillLem]

It feels odd that you should use that as an argument against the "5 speeds" idea.
---
Since ONML was designed second, this really looks as though the designers themselves realised that the game didn't need so many gradations in release rate....

Thanks for tallying these up, it's interesting to see the spread in L1.

The list is quite large with many values accounted for, and I imagine that those less-frequently-used ones were used for a reason in those levels; same goes even more so for ONML, in which the levels were even more tightly designed.

So, allowing more variation allows for the creation of levels which might need a more finely-tuned RR as its base. Sure, there might be more frequently used ones, but narrowing the choices down to just those feels unnecessarily exclusive, particularly from a design POV.

Having said that, I like your "9 options" list; it's an attractive prospect from a player POV, for sure. Simon's idea of revising it to allow "natural" timing of the Walker animations would be a good revision as well. Were it not for the fact that the Editor allows you to type the values you want, it would definitely be something to consider for the Editor to make level creation easier.

During play, the displayed initial spawn interval is for eyeballing, and I have feelings for it. E.g., spawn interval 60 gets the second lix stuck in first lix's digger pit, but 50 is too quick.

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

I don't like levels with precision RR fidgeting. I'll solve those by trial-and-error, not by exact math, and they're annyoing.

Agreed, fair comment. Perhaps this is an argument for not allowing more RR/SI values, but it's possible to make fidgety levels no matter which value is displayed, and as long as the player has some gauge in mind for what value equates to what result in-game, RR and SI are equal here, too.

It helps a little if I have a feeling for what the numbers mean
---
Thus, if WillLem wishes me to avoid exact math, then forcing RR over SI will not progress towards that goal.

OK, so I guess SI wins out a little bit here. If you're having to do mental arithmetic because RR is displayed instead of SI, then yes I'd prefer to avoid that.

Still, the ideal situation is that a player would be changing the value and then noticing how it affects things in-game, eventually learning to equate meaning to them by intuition. It's only because you know exactly what SI means that you favour it, and RR now looks more arbitrary. Conversely, a player who knows nothing about SI instead learns to equate meaning to the RR values...

Thinking about it, and with "OG preservation" aside, a scale using colours rather than numbers is probably what I'd personally prefer... (although, that would be very awkward to try and implement in a button-oriented panel; such a thing would probably need a sliding scale).

I like to choose, during level design, an odd spawn interval (because the walker's animation cycle has 8 frames)
---
With L1 RR or NL RR, it's not immediately obvious which numbers will make odd intervals, and they obscure entirely which numbers make prime intervals.

Ultimately, though, it's necessary to learn which values are useful for either RR or SI. You've learned SI, hence your preference. Someone who'd learned RR would feel the same way.

But OK - I don't want to exclude people who've taken the time to learn either value, so if I was to re-implement the option it would be for that reason.

How would people feel about bringing the option back, but having it show RR when in Classic Mode?

[Dullstar]

One advantage of Spawn Interval is that the direct correlation of the values to the result makes quick estimation of the amount to change it easy. If I want to double the release rate, that's halving the time between spawns, thus I want to cut the spawn interval in half. When you think about it that way, you can take a lot of the trial and error out of reaching the number you're looking for. And if you really want to do frame perfect SI/RR twiddling... well, it's not exactly hard to do that with RR either, as you can just figure out, "Yep, that's one frame off, gotta go up/down one... two frames off, so adjust by two..." because of the way modern NL RRs map to spawn intervals (and in the traditional scale, it just becomes an adjustment of 2, 4, 6... instead of 1, 2, 3...). So blocking spawn interval doesn't actually discourage these frame perfect RR/SI shenanigans at all and in fact makes quick estimations (the kind of RR/SI adjustments you might actually want to encourage) harder:

What is double RR 50? I don't know. It might be 75. I think? Could be wrong. IIRC the formula for NL SI to RR is 103 - SI = RR, and thus SI = 103 - RR so 103 - 50 = 53. 52 / 2 = 26 SI. 103 - 26 SI = 77 RR. So we got close, but... not quite (in practice it should be close enough in most cases). It looks like there's a bit of a pattern there, although I haven't proven it holds true for arbitrary values, where we want to increase the RR by half the remaining distance to 99 to double the release rate, but that's a bit harder to mentally calculate than simply dividing a number by 2. Quick, make spawns twice as fast with SI 28: that's 14, easy. Make spawns twice as fast with RR 75!... uh... that's gonna be, like 80 something I think? (it's 89) (these calculations assume the current NL scale, though I suspect they'd still work for the traditional scale, albeit with the SI equivalents being different, but I didn't actually check for the traditional scale).

And, of course, as mentioned, the NL RR scale almost completely different from the original game RR scale, matching only at RR 99.

Since SL doesn't seem too concerned about existing NL content breakage, there may be an argument for reverting to the traditional RR scale.
But: doing that would cut off a lot of the available range, and then you may end up with demand for a 3rd option to use the current NL RR scale (which would need to range from 50 to 99 instead of 1 to 99 because the traditional scale can't represent these values... unless you want negative release rates to be a thing).
Interestingly, reverting to the classic RR scale would actually fix a minor cosmetic issue in the SI display option, which is that SI >= 100 looks like garbage, but it usually isn't a problem because seriously who uses SI >= 100, that's like 6 seconds at the rate of physics updates. That is, like, EXCESSIVELY slow, and if I remember correctly, these SIs were enabled not because there was actually demand for them, but because they wanted to remove the redundant values in the traditional scale so that changing the RR value would always change SI, so SI from 53 to 102 were created as a result of the scale suddenly having space for 50 extra values. But I'm not aware of any serious complaints that traditional RR 1 was too fast.

Although annoyingly, if you for some reason want a stacker to let no lemmings past it, you need 54 SI which is *exactly* one SI out of the traditional range.

I see no compelling reason not to offer SI as an option even in classic mode (particularly if you don't revert to the traditional RR scale as neither current option is really classic...)

[WillLem]

One advantage of Spawn Interval is that the direct correlation of the values to the result makes quick estimation of the amount to change it easy. If I want to double the release rate, that's halving the time between spawns, thus I want to cut the spawn interval in half. When you think about it that way, you can take a lot of the trial and error out of reaching the number you're looking for.

Some trial and error is a good thing; it's directly interacting with and responding to the game as it's happening, which adds to the atmosphere. I'm aiming to put a little bit back in with SuperLemmix, so if SI helps to remove trial and error then it makes it a prime target for omission.

With that said, the aim is not to make the engine completely trial and error, because the QOL features are great for challenge play and/or quick testing of levels. This is why Classic Mode is optional and will remain so. It's also what prompted the idea to put the SI option back in, but limit Classic Mode to only using RR.

And if you really want to do frame perfect SI/RR twiddling...

I don't; quite the opposite, in fact.

The more I think about it, the ideal implementation of RR would be a sliding scale with only colours or a "slider" graphic as a visual reference. I'd rather the player be watching the lems than the numbers:


(Something like this, for example)

Since SL doesn't seem too concerned about existing NL content breakage, there may be an argument for reverting to the traditional RR scale.

Unlikely to happen tbh; increased range is a good thing, this particular improvement will stay. Furthermore, there are equivalents to the OG scale on the NL scale which allow content preservation anyway.

I see no compelling reason not to offer SI as an option even in classic mode (particularly if you don't revert to the traditional RR scale as neither current option is really classic...)

At this point, more voices seem to be saying "bring the option back", so it most likely will happen.

However, it probably would be on the condition that Classic Mode presents the RR scale. Sure, NL's version might not represent the same numeric values as the OG, but I'm less interested in that than I am in the presentation of the "hatch speed" feature itself; since RR is an arbitrary scale, the actual output itself becomes more important as a "what's happening here?" reference, rather than "I already know what should happen here because I know exactly what these numbers mean." Therefore, RR is more in the spirit of what Classic Mode is trying to do (only slightly more so, I admit, but enough).