search

phetsims / quadrilateral

"Quadrilateral" is an educational simulation in HTML5, by PhET Interactive Simulations.
GNU General Public License v3.0
1 stars 3 forks source link

Context responses for blocked movement #270

Closed terracoda closed 1 year ago

terracoda commented 1 year ago

We need responses for when further shape transformation or movement is blocked by

  1. the shape itself
  2. the bounds of the Play Area
terracoda commented 1 year ago

Ideas

Corners may or not be totally blocked when they hit an edge, so maybe it's best to call out the edge they have just hit, upon hitting it.

Corner movement can get more restricted if it is blocked by part of the shape.

Sides, especially long ones can get blocked more easily:

terracoda commented 1 year ago

We could also say the shape changes are blocked rather than a side or corner is blocked.

terracoda commented 1 year ago

@BLFiedler, what do you think?

brettfiedler commented 1 year ago

@jessegreenberg, can we call out which edge is blocking corner and/or side drag?

Fine with your last suggestion, too. Should also be accompanied by a sound to assist.

jessegreenberg commented 1 year ago

The model currently does not have that information, it is a single "am I within these rectangular bounds" check, not an edge collision check. It could be added as a new feature with some additional time.

brettfiedler commented 1 year ago

We aren't going to implement Voicing targeted to specific edges (e.g., top, bottom), but we will want Voicing and the boundary sound to fire when encounter a new edge (like when sliding along an edge you just encountered into a corner/new edge).

We talked about using the user input/vertex direction rather than the edge position to trigger the "shape blocked by edge" context response or boundary sound.

Assigning to @jessegreenberg, to spend some time on implementing this.

jessegreenberg commented 1 year ago

The basic context responses are in place but I couldn't get to the second (more challenging) part today.

jessegreenberg commented 1 year ago

OK, I think this is working as requested!

@BLFiedler can you please review the sound after this change?

@terracoda can you please review the Voicing? On thing I noticed is that the collision context responses are getting cancelled by the medium and high priority Utterances from context responses from other shape changes. Is there anything you would like to do about this?

brettfiedler commented 1 year ago

This sounds great from the sound side. Tested both side drag and vertex. Bounced between and along sides and heard the bonks every time I expected to.

If the Voicing sounds good, feel free to close @terracoda

brettfiedler commented 1 year ago

Oops - I did notice one issue.

Keyboard - Side Drag

Move a side into the the boundary - you (correctly) hear the "bonk" sound. Now press the same direction again. Now you hear the inner boundary sound "eh eh".

Does not happen with vertex drag.

terracoda commented 1 year ago

Questioning some Keyboard Examples:

  1. Heard "Blocked by edge" response when I hit the edge at the corner with the down arrow, but after that I hit the right arrow, and I heard "right", and no movement occurred. I expected to hear "Blocked by edge" or nothing since I was already at the two edges.

    image

  2. Turned on values in case that's helpful. In this case, I heard the edge sound upon hitting the edge, and on the next key press I got the blocked response. I think this happens from time to time. And sometimes I don't hear the response. Is it possible that if the response is a little late, it gets interrupted by a key press?

    image

  3. In this case - moving side BC down... When Corner C hit the bottom, I heard, "Blocked by inner shape." I wasn't sure if that was the correct response? I expected to hear, "Blocked by edge."

    image

still testing...

terracoda commented 1 year ago

  1. I hear both responses in this case. I hit edge and hear "Blocked by edge" response and sound, and then I hit the up arrow again and I hear the "Blocked by inner shape" response and the other blocking sound (inner shape). Should the inner shape audio (sound and speech) fire after hitting the edge? This only happens when a side hits the edge.

    image

  2. Some inconsistency when a corner hits and edge. If it just so happens that the movement/step hits the edge and triggers one of the longer shape-property or shape-maintenance context responses, I think the "Blocked by edge" gets lost. Sometimes the response will fire on the next key press and sometimes it does NOT - possibly because I have already pressed the arrow key more than once. Actually, I think this inconsistency is just some delayed responses. I played a a lot with Corner C in the scenario below and I think I heard everything I correctly, but sometimes it was a little out of synch, so it felt weird or I missed something - especially if I did multiple key presses at the edge.

    image

So far, my main concern is hearing the "Blocked by inner shape" audio (sound and response) when a side or the corner of a side hits the edge. @jessegreenberg is this a bug or is there a model reason for it?

terracoda commented 1 year ago

The sounds work quite nicely :-)

jessegreenberg commented 1 year ago

OK, reviewed the list and responding to each:

1) I haven't been able to reproduce yet, will keep trying. 2) Yes, this is happening because the other context responses are higher priority than the collision context responses. 3) I am not sure why this is happening, Ill take a look. 4) I am guessing this is caused by the same issue as 3 and as the issue @BLFiedler mentioned in https://github.com/phetsims/quadrilateral/issues/270#issuecomment-1375557197. 5) Yes, I think this is the same as 2. Context responses from shape changes are higher priority than these context responses. Would you like to try making these collision responses the same or higher priority?

Currently changes are prioritized like this (by value):

terracoda commented 1 year ago

@jessegreenberg and @terracoda discussed the priority of each response.

We'll try upping the priority of Blocked by edge/shape to 2, so that it has the same priority as shape maintenance, and @terracoda will see how that goes.

jessegreenberg commented 1 year ago

OK, coming back to this issue after a siesta. The remaining work is

For the collision bug...

One of the requirements for a valid shape is that all Vertices are in bounds. So when a vertex touches the bounds edge, it triggers the boundary sound. Then when an attempt is made to go out of bounds, it counts as an invalid shape and triggers the related sound.

We need a check for valid shape that only looks for crossed/overlapping components for this sound/voicing feature. We can break up isQuadrilateralShapeAllowed into a bounds check and an overlap/cross check. Sound would use this while vertex positioning would use both.

EDIT: This is working well for sides. Id like to understand why this problem ISN"T happening for vertices, that doesn't make sense to me.

EDIT: This is not a problem for Vertices because bounds.closestPointTo the vertex input listeners, so we never attempt to move a vertex out of bounds. That is not true for sides, there happens to be more complex logic when moving both vertices at once. I think it is OK to apply this fix to sides without using the same logic for vertices.

jessegreenberg commented 1 year ago

Alright, these were fixed in the above commit.

brettfiedler commented 1 year ago

I noticed if you "meet" both conditions for hitting an edge and the next move being an invalid shape, you still hear both sounds with sequential keypresses in the same direction (you would probably get this with vertex too?).

https://user-images.githubusercontent.com/47331395/228294539-7d8d2345-7da6-4364-b84e-7f1c1f4833d8.mp4 (video showing moving side CD to the right, then to the right again).

This is because the boundary checks for arrival at, while the invalid shape checks for the next movement causing an invalid shape.

Ideally ,we'd probably have both of these fire once you reach the boundary, but it's also at odds with how we wanted the invalid shape sound and context response to fire (only when you try to make the invalid shape, not when you have made a valid shape).

So, this is fine. While it seems like the same bug as before, it's more informative and not a bug at all! I think we're good here, but I'll wait for @terracoda to review. Feel free to close after if no other issues.

jessegreenberg commented 1 year ago

We discussed today that @terracoda will review but this doesn't need to block the next test.

terracoda commented 1 year ago

Hmm, I feel like these responses are working well together.

I do still get a shape maintenance response sometimes when hitting the edge, rather than an edge response. I think this happens when the threshold for a shape maintenance/shape area change triggers right at the edge.

Wiggling around mixes things up, so I feel like a person can get themselves out of a restricted spot.

I am willing to leave things as-is. I think we already changed the priority of the edge response, to be greater than the shape-maintenance response, so I feel edge responses are happening more than before, and the occasional shape-maintenance response that happens at the edge can be tolerated in a useful way since the response does provide information about the actual shape.