[?][SUG][PL] Improve same-frame assignment behaviour in Replay Insert mode

[WillLem]

Then put absolute overwrite prevention into the next release.

It should already be in the RC...? (Can't check right now, on mobile).

The problem with your hotkey remains that it overwrites different lemming, which nobody wants.

It doesn't have to. If we figure out SameFrameSamLem, that could be the hotkey behaviour for sure.

I'll help you until it's done.

That's good, I appreciate that. You help temper some of my more haphazard coding habits and it's always nice to have your company

[Simon]

absolute overwrite prevention into the next release.

It should already be in the RC...?

Ah, yes, RC1 prevents all overwrites. It behaves as follows. Situation:

• Replay contains old assignment for the next tick.
  
• Activate insert mode.
  
• Point to a lemming that would normally (= if nothing were in the replay) eligible to be assigned.
  
• Click.
  

The game then does:

• You hear an assign sound.
  
• The replay stays as before the click. You didn't cut, you didn't insert.
  
• Physics advance once.
  
• The old assignment replays.
  

This UX is problematic. You hear the expected assignment sound exactly as after a successful click, and the physics advance, too. But the click didn't produce what we wanted. It feels like a bug.

It's outright misleading when we assign permanents that will do nothing on the immediate next frame. The potential assignee does exactly what he would do if the click's assignment went through: Walk forward once.

-- Simon

[WillLem]

This UX is problematic. You hear the expected assignment sound exactly as after a successful click ... It feels like a bug.

The assignment sound happens because of the original assignment, this we know. You should also hear the assign fail sound as well; can you confirm this?

But yes, it's clearly not ideal.

My suggested solution to this if we keep "no overwrite" behaviour would be to only trigger the assign fail sound for this particular situation (i.e. attempted assignment fails due to existing assignment). The slight inconsistency with the fact that the assignment sound is heard wherever else there is assignment during replay mode is acceptable; here, the assignment failure feedback is more important.

[Simon]

Yes, I hear both the successful old assignment and the short click for the failed assignment. I didn't notice that yesterday.

I agree that you shouldn't play a successful sound here.

On a click that will not assign, don't advance physics in the first place? Play only the failed assignment. Then you won't have to introduce inconsistencies. On air clicks, you probably want to advance physics, but air clicks are safe, can't mistake air clicks for a wanted assignment.

Wondering if you want to tell people before the click that the assignment will not go through.

-- Simon

[WillLem]

I agree that you shouldn't play a successful sound here.

OK, I'll implement this for the 1.0 release version. EDIT - This is now implemented ready for release.

On a click that will not assign, don't advance physics in the first place? Play only the failed assignment. Then you won't have to introduce inconsistencies.

Unless I'm misunderstanding what you mean, not advancing physics on a mouse click would be inconsistent. At every other time, clicking advances physics; I see no reason to change this.

Also, the player needs to see the reason their assignment has failed: because there is an existing assignment, which will be activated on clicking and advancing physics.

(Again, I might have misunderstood what you meant).

Wondering if you want to tell people before the click that the assignment will not go through.

We'd need a way to detect future assignments to the selected lemming, which we currently don't have (but would likely need to be implemented to allow same-frame-same-lem assignments anyway).

What sort of feedback do you imagine? Some ideas: the lemming could simply not be selectable on the frame prior to the assignment, or the selection rectangle could have a big "X" through it. A "this lem cannot be assigned" message in the panel would also be OK.

This could look like a bug, though. I still think the failed assignment itself is enough feedback: let the user know why it's failed, rather than that it can't happen (but without providing a reason).

Consider: the user cannot assign on the next frame anyway, so physics might as well advance, the fail sound plays, the original assignment is seen, and the player can see the reason why they can't assign on that frame. They then simply step to another frame to assign the new skill or use the Replay Editor to remove the original assignment if it absolutely must be on that frame.

[Simon]

inconsistent
might have misunderstood

I meant: In NL 12.14, all replayed assignments sound the same (all play the regular assignment sound effect). In your RC2, only some replayed assignments will sound like that. Those replayed after a failed click will produce no sound. This will be less consistent.

But it's decent. It's better than (advance physics + play sound for successful assignment).

Next week, I will playtest in Lix: Replayed assignments sound different than freshly clicked assignments.

not advancing physics on a mouse click would be inconsistent.

The intuition here was: If you can't give the player what he wants the most (assignment), give nothing. Don't give 30 %. Fail as clearly as you can.

The alternative to make all click failures not advance physics. E.g., player clicks to assign basher to basher, physics shouldn't advance. Then that not-advancing will be consistent with the not-advancing on failures that come from old assignments in the replay. You'll also preserve the sound consistency; all replayed assignments produce the same sound.

user cannot assign on the next frame anyway, so physics might as well advance

Hmm.

He can change the release rate, but that would be a feeble argument.

He can delete the old same-lemming assignment, then assign. If you advance, he'll have to rewind, then delete, then assign. I'll sleep over this.

let the user know why it's failed
physics might as well advance
original assignment is seen

The original assignment can be elsewhere in the level, for an unrelated lemming.

This will remain a design problem even if you eventually allow same-lemming overwrite as an option. I have no good answer for this.

What sort of feedback do you imagine?

No idea yet. This design problem is entirely new. I was curios how satisfied you were with the RC's feedback on failed clicks. Yes, assume that we solve all technical problems, e.g., how to fetch this information from the replay.

I agree that we shouldn't make things look like bugs. Generic crossed-out cursors or no-signs won't clarify the reason behind the click that is going fail. Some leeway you have, it's a corner case in an expert feature.

If you're happy with what you have, release CE 1.0 with what you have. It's better than NL 12.14 because it prevents accidental different-lemming overwrites. We can solve the hard design problems in March. And user options for same-lemming overwriting (really: cut future of that lemming, then assign) can also wait.

I don't mind going 5 times in circles with this. You're the first to shred the Lix design choices. I wonder if I want to make it a user option in Lix whether air clicks in insert mode cut the replay.

-- Simon

[WillLem]

In NL 12.14, all replayed assignments sound the same (all play the regular assignment sound effect). In your RC2, only some replayed assignments will sound like that. Those replayed after a failed click will produce no sound. This will be less consistent.

Yes, having implemented this and tested it a few times, it does feel somewhat odd, even if it is technically "better UX"...

The intuition here was: If you can't give the player what he wants the most (assignment), give nothing. Don't give 30 %. Fail as clearly as you can.
...
Then that not-advancing will be consistent with the not-advancing on failures that come from old assignments in the replay. You'll also preserve the sound consistency; all replayed assignments produce the same sound.

I see. In that case, this is definitely worth a try. For RC2 For the 1.0 release*, all assignments that fail due to an existing assignment at the same frame don't advance physics (and, trigger the Assign Fail sound as feedback).

*RC1 feedback has been slow, let's just go ahead with the release version. We can always tweak this again in later updates.

[Simon]

assignments that fail due to an existing assignment at the same frame don't advance physics

... but all other failures to assign still advance physics: You select basher, you click on a basher, and physics advance from this failed assignment.

I agree that this combination a good choice to try in public. I'm not sure if it's absolutely best and I'd like to see feedback.

Reason: I've experimented with non-advancing failed assignment in Lix singleplayer streams. It wasn't fun to block all failed assignments from advancing physics. When an ascender/hoister is still ascending, but we know that he'll be assignable within 1-3 physics updates, I'll select builder and click on him several times. This ensures that he builds ASAP. I didn't know that I used this pattern until I removed it experimentally, and I'm putting it back in.

-- Simon

[WillLem]

When an ascender/hoister is still ascending, but we know that he'll be assignable within 1-3 physics updates, I'll select builder and click on him several times. This ensures that he builds ASAP. I didn't know that I used this pattern until I removed it experimentally, and I'm putting it back in.

Yeah, exactly. This is one of the reasons I wasn't sure about preventing physics advancements. I'm still not 100% sure it's best either.

It works well to offset confusion caused by either "we heard the assign skill sound but this is not the skill we tried to assign" or "we heard the assign fail sound and yet the lemming has begun an action", but also causes the player to have to click more times to get to a frame they can assign upon. If we advance physics and allow the sound clashes, we get to assign in fewer clicks.

There is probably no 100% correct answer to this one. Happy to consider any ideas that anybody might have.