[SUGGESTION] [PLAYER] [REJECTED] Changing RR affects next interval

[Simon]

Status: I have decided against implementing this change.

[Simon]

Have lemmings come out of the hatch. Change the release rate. This does not affect the next lem to be spawned. It will only affect the interval between that next lem and the 2nd-next.

Why is this irritating? If we change the interval, it should affect the interval as soon as possible. By affecting the current interval (we're always on an interval between lems), it would have that immediate effect. This is a basic principle of UI design: Give immediate feedback and put the change in effect ASAP.

More opinions on this please.

-- Simon

[IchoTolot]

I can see logic behing both methods:

- ASAP change is logical in the sense that RR change is imminent, but.....

- Change with the next spawning Lemming is also logical: The RR count counts not for the current spawning Lemming, but for the next spawning Lemming ----> changing it will change the rate with the the next spawning Lemming.

Also the handling of Lemming bunches is a lot better to handle this way....
EXAMPLE:
Say that you want an exactly 1RR gap and then change immidiatly to 99RR for compression....with the change with the next spawning Lemming there is zero problem to do this exactly.
With immidiate change little unpricise stituations can accour more easily....you must wait until the second Lemming spawns or you won't have an exact 1RR size gap...then turning it to 99RR will likely have a little gap (a few frames) between Lem 2 and 3, because you change it after Lem 2 and not in advance.
Also to do this as good as it gets, there is the precise moment for turning it up RIGHT AFTER the 2nd Lem, where the Change with the next spawning Lemming method leaves the whole 1RR gap to react.
-----> less precision for levels with sharp RR change timings and this is always good

So as I went from Lemmini to NL together with the change of the imminent RR change to the Change with the next spawning Lemming method, I was also a bit sceptical at first, but now as I have played lots of NL now... I see the advantage of the NL RR change!


Also: Now all replays have been made with this method and maybe this change would affect them (I have no motivation of checking+redoing quite a lot of replays ). Furthermore every player have gotten used to it by now

To end my statement: I prefer the current implementation of the RR, because of the lesser precision needed + getting more precision out of it.

[Simon]

Interesting use case for the delayed RR-change.

My gut feeling is that your case will occur far less often than this: We want to spawn exactly n lems very quickly, then make it slow immediately. This is the typical situation where I produce 1 lem too much with the NL method. But I am not well-versed in level design to judge how often these would occur.

If the NL regulars prefer the delayed RR change, I don't care too strongly to push the idea further. It's also easier for namida not to write any code to convert replays.

-- Simon

[IchoTolot]

Interesting use case for the delayed RR-change.

My gut feeling is that your case will occur far less often than this: We want to spawn exactly n lems very quickly, then make it slow immediately. This is the typical situation where I produce 1 lem too much with the NL method. But I am not well-versed in level design to judge how often these would occur.

If the NL regulars prefer the delayed RR change, I don't care too strongly to push the idea further. It's also easier for namida not to write any code to convert replays.

-- Simon

Yes this case, requires the thinking...turn it down 1 Lem before your goal.   
But in this case both methodes require (the same) precision (right after Lem X/Y turn it down), it's just the thinking that is diffrenent (and this can be adopted by the player): The next spawn will be slow / it's right now slow again.

(lil chat out of IRC here )
<IchoTolot> I see the advantages of both, your method prob a bit easier to understand for beginners    the other one offers a benefit in handling tight timings for advanced players
<SimonMath>hmm
<IchoTolot>but as this is not a very complicated mechanic (and prob obvious how it works after a few uses) I must give the point to the better handling

Any way to ease the precision in some points is valuable! And the more common scenario just requires adapting a thought with no precision disadvantages.

[Nepster]

My opinion: Big change for minor improvement.

My gut feeling is that your case will occur far less often than this: We want to spawn exactly n lems very quickly, then make it slow immediately.

But here you only have to go back a few frames or move a few frames ahead, which can be easily done (once am improved version of the negative timeskip is implemented in NeoLemmix). In IchoTolot's situation on the other hand, you have to guess when about 3 seconds have passed since the previous lemming, which makes for a much larger error margin.

If we change the interval, it should affect the interval as soon as possible. By affecting the current interval (we're always on an interval between lems), it would have that immediate effect.

I wouldn't use "immediate effect" here: If you change the RR from 1 to 30 directly after a lemming spawned, you still have to wait about 2 second until you see any change, instead of 5 seconds. This is better, but still not optimal, i.e. you propose an improvement regarding immediate player-feedback, but not a complete solution (which likely doesn't exist).

[ccexplore]

Sounds like I'm late to this party so I'm guessing most of what needs to be said is already said.  Anyway, yeah, I think almost everyone will find the current behavior unintuitive for the exact reason Simon mentioned, though with sufficient practice I expect most people can internalize this oddness and stop getting tripped up.

The advantage IchoTolot mentioned is the first positive that came to mind, but I suspect that advantage might be somewhat overstated, given that you can still change the RR while paused.  I might've overlooked something, but seems to me that for each case where Simon's more intuitive RR handling would lead to a precision move (ie. a small window to pause and change RR before you can no longer achieve the exact desired distance between the most recent lemming out and the next one), there is a corresponding case as well with the current less intuitive RR handling (ie. the current RR gives a small window to pause before the next lemming ["n+1"] is out, and you need to set the distance between n+1 and n+2 via a precise RR change).  It is of course still possible that in practice, the former might happen more often than the latter.

Replay conversion may be the strongest reason to avoid changing the current behavior--even if we make the change alongside other physics-breaking changes, changing how the RR works will most likely affect a lot of existing replays without some sort of conversion to compensate, compare to most physics-breaking changes that tend to be more scoped to specific skills in specific setups.

[namida]

Handling existing replays would not be a major issue. All that would need to be done is, for older replays, queue the RR change and apply it when the next lemming has spawned, rather than applying it instantly.

The problem more comes down to:
1. How problematic would this change be for existing users?
2. Does changing the behaviour give a significant improvement to new users?

[namida]

If it isn't too much work to do so, I might put together a test version later on that implements the changed behaviour in some form. Note that for the purposes of a test version, I wouldn't make the effort yet to have replay compatibility - if it's decided to go ahead with the feature, that's when I'd put the replay compatibility in.

This way, people can try it out and see how they find it in practice, rather than relying on theoretical arguments.

[Nepster]

Just to save you some work: This new RR is already implemented in Lix, so people can try it there.

[namida]

This doesn't nessecerially guarantee the implementation would be exactly the same; but this is a good starting point.

For those who'd prefer a more Lemmings-like setup to test it in; IIRC the Master System version of Lemmings works this way.

[IchoTolot]

Handling existing replays would not be a major issue. All that would need to be done is, for older replays, queue the RR change and apply it when the next lemming has spawned, rather than applying it instantly.

The problem more comes down to:
1. How problematic would this change be for existing users?
2. Does changing the behaviour give a significant improvement to new users?

I really think point 2 doesn't apply here. The improvement for new players would be VERY little and it throws off the current system.
As I already said I think this is right now a better to handle RR for advanced players + The energy this requires could better be used somewhere else.

[namida]

So, we've got posts going both ways on this one, although it does seem to be leaning more towards "keep it as is". I think this calls for a poll.

[mobius]

I voted for change. But I'm not real concerned with it.

Old Lemmini worked this way [instant change] and I used to use that a lot and never had any problems with it. I liked it a little better.

As you may know of me by know; if I'm playing a level of the example cases Icho and Simon talked about I would probably quit, frustrated, whether the RR was more or less helpful.

[namida]

Between the arguments in the discussion and the poll results, I'd say it's not worthwhile making this change. Still, it probably was something that needed to at least be discussed sooner or later; it has been now.