Motorspace indication: indicate on wall instead of motorspace

[bastianilso]

People keep track of the cursor on the wall when playing, rather than their hand. For this reason, weep the signifier arrow graphics on the wall . So we could e.g. just have an arrow pointing on the wall itself.

A signifier should be on the wall, because that is what they are tracking.

related issue: #167

[bastianilso]

Could be e.g.

[bastianilso]

Alternative: tile wall. So cursor can never exceed boundaries. Going left means cursor appears right.

[lucasmnt]

I've been working on this issue, and right know I have two version of the work, one with only one arrow, and the other with three arrows. I also managed to make the arrows appear when we are going out of vertical boundaries (not only horizontal one).

See with only one arrow :

See with three arrows :

In any cases, these arrows are 2D sprites, and they can appear simultaneously if you are out of vertical and horizontal boundaries at the same time. Theses "arrow boundaries" are triggered by the fact that the player cursor is going too far from the left, right, top, or bottom of the wall.

[lucasmnt]

I want to add that right now, all the code that manages the appearing of the different arrows is situated inside the WallManager.cs script, since it's the only place (that I found) where we have access to the wall dimensions, and positions. Is it ok to leave it here or should I try to get the logic somewhere else ?

[bastianilso]

• Rather than scaling them as a group, you could scale them individually.

• Prefab that's "BoundaryArrow" and then have an automatic animation. And then you can instantiate it X number of times.

• Make the arrows slightly smaller.

• We discussed a new proposed behavior:

  1. Show a single arrow per side of the wall. If the cursor moves outside the wall, show an arrow, with orientation towards the cursor by using the Transform.LookAt() function.

• Move logic to Target GameObject and make it subscribe to events from WallManager, thus keeping WallManager clean of the code.

[lucasmnt]

I was wondering if, in the same fashion as the mole prefab, we should move the logic to the BoundaryArrow prefab and not to the target (there is also the fact that there are two Targets, one for left and one for right controller). Wall Manager will stay clean, and the only "problem" would be getting cursors positions.

Right now i'm putting the logic to the Target, but we will still need to create like a BoundaryArrow.cs am I right ?

[bastianilso]

@lucasmnt maybe we should take a look at what you have here later in the afternoon today, let me know.

[bastianilso]

Some ways to handle the infinite cursor challenge when going beyond the wall:

• create a 2D plan behind the wall with no visibility but with a collider, so the cursor doesn't go to infinity.
• detects when cursor positions beyond the wall (using X or Y max positions) and use this detection to determine the visibility of the arrows.

As for attaching the arrows to the person's field of view, our normal approach is to attach it to an invisible game object placed on the head. However, please make it possible to switch between using FOV arrows and having them attached to the wall, since we don't quiet know what is the appropriate choice yet.

[bastianilso]

current WIP branch holds the latest work in this area: https://github.com/med-material/Whack_A_Mole_VR/tree/wip/arrow-boundaries

[bastianilso]

Further ideas:

• not making the cursor dissapear. two ideas: 1) making it stuck at the edges of the board, 2) "slow-mode" where the cursor moves but only slowly, until it is back within the boundaries.
• highlight the edge, pulsate,.. special state that you need to recover from.. sound feedback too.
• can have stuck cursor + cursor indicating actual position of your cursor off the board, perhaps with line drawn in-between to indicate how to get back.

[bastianilso]

Implemented with commit d3b2482c5ecc3395c64f8eb654babfea7ff2d85b