[SUG] Assign Fail Sound / Replay Insert Mode

[WillLem]

Don't worry, I'm not going to go mad with loads of new topics, I just think this particular feature needs a bit of discussion before I go any further with it.

Basically, the Assign Fail sound triggers any time an assignment is attempted, but fails for any reason. Reasons could be:

1) Assigning a destruction skill when the path would immediately hit steel.

2) Assigning the same skill to a lemming that is already performing that skill.

3) Disallowed assignments (e.g. assigning a Builder to a Blocker).

4) Assigning a skill on the same frame to a different lemming when in Replay Insert mode (this one is new for CE)

It's not just "adding noise" unnecessarily, it's arguably very useful to have this. Players might not be aware that they cannot assign a Builder to a Blocker (for example), and the auditory feedback is important for signalling to the player that the attempted assignment has been acknowledged.

And, if we're disallowing skill overwrite in Replay Insert (we should!*), it lets the player know "there is already an assignment on this frame"; vital!

And OK, spamming might trigger it a bunch of times, but this is acceptible given the benefits.

Possible drawbacks:

It might become annoying: for this, we can simply make it optional.

It doesn't play nicely with skill queueing: OK, this one is a problem. I've checked, and it turns out that every possible skill assignment gets added to the queue, so it's not as if we can say "this skill has been queued successfully, no need to play the Assign Fail sound". We'd have to simulate the lemming at the point of the attempted assignment to see if it would become possible in the next 15 frames, which seems like a potential source of bugs more than anything.

Besides, queued assignments are not necessarily useful to the player on the current frame, which is absolutely the necessary point of feedback. The sound remains useful to signal "no, it's not possible to assign that skill on this frame; the fact that the skill may be assigned in a few frames thanks to queueing doesn't necessarily help the player. So, the sound is still valid.

Current proposal, then: Implement the Assign Fail sound, make it optional, we accept that it doesn't couple up with the skill queue system quite as nicely as we'd like (but still remains useful as a point-of-assignment signifyer nonetheless).

Thoughts? Suggestions?

*We might as well discuss this one here as well, it doesn't need its own topic.

[Armani]

I don't mind adding "assign fail sound" as long as it's optional.

And, if we're disallowing skill overwrite in Replay Insert (we should!*)
*We might as well discuss this one here as well, it doesn't need its own topic.

It seems that you have a pretty strong opinion on disallowing skill overwrite replay in insert mode.

I'm aware of that behavior and I sometimes do overwrite skills with intention. The most recent example is; I was playing one of Strato's levels and I used a jumper to cancel a basher to make a little staircase. Later, I realized that I want to save that jumper for the last. So I overwrote the jumper assignment with a shimmier and luckily didn't have to do rest of the solution again.

These things happen rarely so I don't mind too much disallowing it if there's a good reason.

[WillLem]

It seems that you have a pretty strong opinion on disallowing skill overwrite replay in insert mode.

I'm aware of that behavior and I sometimes do overwrite skills with intention

Maybe we could use a modifier key (Ctrl, Alt, Shift) to overwrite assignments when in Replay Insert mode. Something to try for 1.0?

The point is that it should always be deliberate. The 10% of occasions where we want to overwrite shouldn't be paid for by the 90% of times we don't.

[Simon]

you have a pretty strong strong opinion on disallowing skill overwrite replay in insert mode.
I sometimes do overwrite skills with intention

Interesting that you want to overwrite. Thanks for bringing it up. Then it's not 100 % clear. See next post. I still believe that no accidental overwrite is better, but I've only read your post now, I haven't slept over it yet.

Older topics for reference:

2023 topic: Replay Insert Mode ("blue R") silently overwrites
2024 topic: Replay Insert Mode ("blue R") silently overwrites: Decision?

modifier key (Ctrl, Alt, Shift) to overwrite assignments

I've already bound fencer to Shift, and I've bound nuke to Ctrl.

-- Simon

[Simon]

The sounds are secondary. Some of this is fundamental input design and we must get it right.

The most recent example
used a jumper to cancel a basher
I overwrote the jumper assignment with a shimmier

This is a same-tick-same-lemming assignment. This overwriting will continue to be allowed. The design in the 2024 topic was:

• Prevent assignment on same tick to different lemming. Reason: This is the problematic accidental overwriting.
  
• Some feedback for the prevented different-lemming assignment will be nice. Sound is the easiest.
  
• Allow assignment on same tick to same lemming. This will first erase the old assignment, then write the new. I assume everybody wants this.
  
• Additionally, when we erase the old assignment, we should also erase all future assignments to the same lemming. (We keep the future of other lemmings.) Lix does this and it seems the best; reason: The future of that same lemming will desync otherwise anyway. namida/WillLem haven't outright said that this is the best, but I'll chalk that up to unfamiliarity with this detail in Lix. Happy to discuss this.
  

No need for hotkeys. Prevent only what is absolutely necessary: Same-tick-different-lemming.

-- Simon

[Armani]

Okay so disallowing overwrite only applies to same-tick-different-lemming assignment. That's desirable. It's hard to imagine overwriting an assignment to a different lemming being beneficial. Even if it does in some cases, probably it's not worth the risk of accidently canceling another assignment.

4. Additionally, when we erase the old assignment, we should also erase all future assignments to the same lemming. (We keep the future of other lemmings.)

  I'm 100% behind this

If disallowing overwrite is going to happen, this can be a good reason to introduce assign fail sound.
Not being able to assign skill with no indication whatsoever is a bit weird.

Slightly off-topic, but I've always thought lix's replay insert mode is superior to that of NeoLemmix. You can precisely manipulate each assignment, you can cancel each assignment with a single click and it's visually more intuitive in general. I think it's a good idea to discuss about possible changes to replay insert mode sometime in the future.

[WillLem]

Allowing assignment to the same lemming is not without its potential for problems, nor is erasing all future assignments for that lemming.

There are still cases where the player might not realise that there is an existing assignment to that same lemming. Those need to be accounted for as well, especially if the plan is to erase all future assignments.

If anything, we'd go from losing a single assignment - "oops, didn't mean to do that!" - to losing every assignment for that lemming. I'm not sure if Replay Insert mode should be that aggressive.

The Replay Editor is a much better candidate for fine tuning assignments; everything is visible at all times, we can add a button to erase all assignments for a particular lemming, etc. Replay Insert mode should be incidental only, and nothing invisible should happen (i.e. erasing future assignments). In fact, that sort of defeats the purpose of Replay Insert mode IMO.

EDIT: To be clear, I understand why future assignments should be deleted if the current one is changed, as they'll all go out of sync. My point is that I don't think overwriting assignments should be allowed at all in Replay Insert mode. Keep it simple and easy for players to understand. Direct them to the Replay Editor (NL equivalent of Lix's tweaker, which we can absolutely look at improving the functionality/visibility of) and let that sort of fine tuning happen there.

Keep it simple, keep it 100% deliberate.

[WillLem]

(Previous message has been edited.)

[namida]

Yeah, I'm also a bit iffy about the idea of erasing all future assignments for the same reasons. Additionally, it might be useful for the player to refer to the future assignments when correcting them - this could especially be the case if a user is attempting to repair a broken replay.

[Simon]

WillLem and namida, thanks for the replies.

I'll be too busy this weekend to write a full-fledged reply on this subject. I'll drill into this again in February. I'll distill the development insights and playtesting experience from 2022-2024.

lix's replay insert mode is superior
discuss about possible changes to replay insert mode sometime in the future.

Thanks, that means a lot to me!

The original inspiration was NL's replay editing window. Yes, there is more cross-pollination waiting to happen here, for both NL and Lix.

-- Simon

[WillLem]

I think it's important to distinguish between

Replay Insert Mode - this can be thought of as an invisible* cursor function that allows actions to be inserted into the replay without deleting any existing (including future) actions,

and

Replay Editor - NL's equivalent of Lix's Replay Tweaker (which Simon confirmed was inspired by NL's Replay Editor).

They are necessarily different things. I've spend some time updating SLX's Replay Editor, here are the results:



It's now possible to select multiple items. The originally-selected item in the screenshot above is the one at Frame 00152, to Lemming #1. It's possible to select all future actions for that lemming, and then delete them all at the same time. Or, we can delete just one or two of the actions (for instance, if one of the actions is assigning a permanent skill, we might not want to delete that).

It's also possible to jump (i.e. frameskip) to the frame of the selected event. If multiple are selected, we jump to the first event in the selection.

We can do even more to expand this; I'd rather the Replay Editor be the place where we fine-tune replays, let's make it more accessible by adding a panel button for it. Meanwhile, Replay Insert Mode should remain as simple as possible because it's invisible; it should only insert skill actions to fully empty frames, nothing more.


*The blue "R" lets the player know the mode is active, and there are plans to add a blue cursor as well, but the replay actions themselves are not visible in the same way that they are in the Replay Editor, so we shouldn't start deleting/editing them.

[Simon]

We agree that CE should not silently overwrite same-tick-different-lemming.

Now consider same-tick-same-lemming. How does it look in practice?

Lemming A becomes builder in tick 100. We want to assign basher to lemming A for tick 100.

We rewind to the result of tick 99. We select basher in the panel. We click lemming A, and expect lemming A to become basher. Under your proposal (never overwrite), lemming A becomes builder again. This will intuitively feel like a misclick, we failed to tell the computer that we want to assign basher. You can make the feedback more explicit (better sounds, better whatever), and then the program will look like it's telling the player: No, player, you cannot do what you want. I know that you want to bash here. There is builder in the replay, and I've clearly shown you the builder assignment during rewinding, therefore you'll certainly want to overwrite, but I still refuse to give you what you want.

You'll make the normal case rage-inducing!

the replay actions themselves are not visible

Actions of the same lemming were visible a second ago, during rewinding -- they were the sole reason for my rewinding. There is no accidental same-tick-same-lemming overwriting to prevent.

For same-tick-different-lemming, yes, we shouldn't silently overwrite.

The original feature request against NL was to avoid accidental overwriting to different lemming. namida originally thought: Let's not prevent overwriting because overwriting same-tick-same-lemming is so useful (source). It took some discussion to separate same-lemming from different-lemming; neither of us immediately saw the fundamental distinction. But, indeed, one is an accident, the other is useful.

-- Simon

[WillLem]

tl;dr

I agree that allowing deliberate same-frame-same-lemming overwrites is desirable, but I also believe that the potential for accidental overwrites is to high, even for same-frame-same-lemming.

So there is a list of proposed solutions at the bottom of this post.

Lemming A becomes builder in tick 100. We want to assign basher to lemming A for tick 100.

For this, I'd rather the player use the Replay Editor (Replay Tweaker).

My two main reasons are these:

1) The whole point of Replay Insert mode is that it preserves all existing replay actions. The fact that it ever allowed overwriting is an oversight bug, which we agree.

And yes, we're now wanting to make the distinction between "different" and "same" to decide whether we should allow overwriting, but even here I strongly think that overwriting should not be allowed in either case.

2) The Replay Editor provides actual visible feedback of what's happening, i.e. we're deleting the assignment at frame X so that it can be replaced. The Editor allows the player to jump to tha frame, delete the assignment, then return to the game to make the new assignment. More cumbersome, yes, but also definitely deliberate.

Allowing overwriting by simply assigning the new skill is not without its problems. You're referring in your example to the very specific case of zooming in on one lemming, which you know you want to change the assignment for, and then assigning the replacement skill action at the correct frame: I agree that this particular case is desirable and useful.

However, consider these cases where overwriting to the same lemming would be undesirable (and potentially rage-inducing):

* We rewind from frame Z to frame Y because we need to assign a Basher to Lemming A. There exists on that frame a necessary assignment to make Lemming A a Climber. We unknowingly overwrite the Climber assignment. We then skip forward to resume play from frame Z or thereabouts: oh no! all of our other assignments haven't played out correctly because the Climber assignment has been overwritten. And OK, the fix is simple (skip back to some point before frame Y and assign the Climber), but we've had to unnecessarily mess about.

* We rewind from frame Z to frame Y because we need to assign a Platformer to Lemming A instead of a Builder (we've realised we specifically need the Builder at frame Z). We assign the Platformer, but now all assignments following frame Y are out of sync: we forgot that there exist later assignments to Lemming A which aren't playing out correctly because the Platformer made the lemming turn around, whereas the Builder didn't. Or maybe the Lemming didn't turn around, but the Platformer has changed the relative position of the Lemming for the remainder of the Replay.

Both of these are solved by using the Replay Editor instead of relying on the proposed Replay Insert Mode same-frame-same-lemming edge case. Here's another example that unfortunately can't be directly solved by either:

* We rewind from frame Z to frame Y because we need to assign a Climber to Lemming A. We unfortunately rewind to a frame that has some other assignment, but the frameskip is large enough that the result of the assignment wasn't visible during skipping. Or perhaps it's another permaskill assignment, which are always invisible. We don't actually realise that we are overwriting an assignment in this case, it's purely by accident. This seems similar to the first example above, with an important distinction: the intention here is simply to add a permaskill property to the lemming to update its history rather than make a very specific assignment on a very specific frame; the potential for accidents is highest here, then.

However, the Replay Editor is more helpful here, too; the player can skip to the first action performed by that lemming, resume gameplay, and step back a few frames to make the Climber assignment, knowing that there cannot possibly be any other assignment to that lemming on that frame. And, the reliable and consistent "no overwrite" behaviour prevents overwriting some other Lemming's assignment.

We click lemming A, and expect lemming A to become basher. Under your proposal (never overwrite), lemming A becomes builder again. This will intuitively feel like a misclick

We display a panel message "Replay Insert mode doesn't allow overwriting existing assignments" (or maybe something more concise). That and the Assign Fail sound are more than enough feedback to let the player know why the assignment hasn't taken place.

then the program will look like it's telling the player: No, player, you cannot do what you want.

Yes, because the player is in Replay insert mode, which never allows overwriting: easy to understand, useful for many other things. It's not about disallowing the player to do what they want, it's about reinforcing the player's choice to be in Replay Insert mode and keeping the assignment behaviour consistent. I would be thinking "ah, OK, the game has prevented me from making a potential mistake".

I do have an idea regarding this though, please read on.

Actions of the same lemming were visible a second ago, during rewinding -- they were the sole reason for my rewinding. There is no accidental same-tick-same-lemming overwriting to prevent.

You're only thinking of one very specific case: the intentional overwrite. See the other potential accidental cases above for where we don't want to overwrite, even to the same lemming.


Proposed solution:

We can certainly reach a compromise here. I have some ideas, here they are in order of personal preference:

1) We use a definable hotkey to allow overwriting in Replay Insert mode. We accept that this will also allow overwriting to a different lemming, but since the use case is so specific (overwrite to same-frame same-lemming), it's unlikely ever to be an issue. This is by far my favourite solution to the problem, and would be very easy to implement.

2) Allow same-frame same-lemming overwriting, but make it optional. This means that players get to decide how they want Replay Insert mode to behave, and it's always an informed and intentional choice. However, it doesn't allow on-the-fly switching of the option should be player wish to momentarily opt for the other behaviour (this applies either way: "I definitely want to overwrite here" and "Hang on, I'm not sure if there's already an existing assignment on this frame"). It also means figuring out the how when it comes to implementing same-frame same-lemming overwrite, which (full disclosure) isn't trivial!

3) We introduce a third mode: Replay Overwrite mode, which behaves like Replay Insert in that it preserves everything it can, but does allow overwriting (so, essentially, the current NL 12.14 version of Replay Insert mode!). Again, the player accepts the potential for accidental overwrites (otherwise, if an assignment is ever not allowed in this mode, the player gets the same rage: "I thought this mode allowed overwriting, why can't I make this assignment on this frame??"). I prefer this solution much less, because Replay Insert mode it's already difficult enough for some users to get their head around (hence my strong desire to keep it as simple as possible).

4) We allow overwriting to same-frame same-lemming, but warn the player that they are about to overwrite an existing assignment. This is the worst solution of all, but it does satisfy both your desire to allow the intentional overwrite, and my desire to prevent the accidental overwrite.

[Simon]

Hmm, intentional same-tick-same-lemming assignment is more common than accidental same-tick-same-lemming assignment. But you have a point with how both such overwritings are still not common enough to spearhead the main design of the feature.

Regarding only a single lemming (disregarding same-tick-different-lemming worries), it's more common to kick a lemming's future from a wrong assignment onward, and then insert around that time.

I'll re-read the discussion with this insight and come back to your long post in a few days.

-- Simon