Operation-level Feedback for Whack-A-Mole

[bastianilso]

In the action feedback issue #238 we proposed improved action-level feedback. This issue concerns itself with the real-time feedback users receive when they move the cursor on the wall (operation-level feedback).

The current feedback involves a blue target, which continuously updates its position based on the physical position of the user's controller. We can however enhance this feedback in a number of ways to incentivize/reward behavior.

• real-time help: for example we could indicate if users move the blue cursor in the right direction. This might need to be optional and become part of future "player assistance" efforts.
• real-time feedback: for example we could give indications of to what extent users follow the "ideal trajectory". The closer they follow the path, the better feedback they receive.

We don't know yet whether such behavior is ideal for therapy, so for now the work on this feedback will be exploratory. I suggest as a starting point that we focus on the real-time feedback case. We could for example provide a trail after the cursor which become longer, the closer the cursor is to the ideal trajectory (red line in the image above).

[bastianilso]

so lucas has worked on the "ideal trajectory feedback" and so far we have a visible line going from one mole to another. we will try to make this work by going from the cursor to the "currentMoleToHit" mole (the next mole). Right now whack-a-mole dont have logic to really handle "several" valid next moles. So either we update the CurrentMoleToHit code to handle that, or we just assume there is one "ideal" mole for now and will upgrade the code later.

Here is some updated examples of types of feedback we can consider in this space.

[lucasmnt]

Here is an update on what we have been discussing: I now have a system that can create a static line between the player's cursor and an activated mole, and that disappears when the mole is deactivated/the player pops it.

To achieve this, I created two scripts:

• LineToDraw.cs, which contains the LineToDraw class. Its purpose is to construct the drawn line with the correct given parameters : cursor and mole position, mole ID that will also become the line ID, and finally a gameObject that will hold the LineRenderer:

The class itself takes 4 parameters : a LineRenderer to draw the line, two Vector3 that hold the start and end positions of the line, and an ID to distinguish between multiple lines drawn simultaneously.

• TargetAssist.cs, which for now contains the UpdateLines() and ResetLines() functions, both called by events in DiskMole.cs.

In the UpdateLines() function you can see an enum PointToDraw which has two values: Add or Remove. I could have done it with a boolean, but it speaks better to someone who will read this code.

This script also contains a Dictionnary<int,GameObject> called currentLines that stores all the lines that are currently drawn. The various manipulations of this dictionnary are done in the UpdateLines() and ResetLines() functions.

TargetAssist.cs is attached to the Target game object in the main scene and has a direct reference to the same object via a [SerialisedField].

This is what it looks like in the game at the moment:

You can see lines being drawn between the cursor and the moles, and in the hierarchy on the left, at the bottom, you can see gameObjects called "Line [moleID]" being created and destroyed.

Finally, to solve the problem of the "ideal mole", we could perhaps, when a correct mole is activated, measure the distance between the different activated moles and say that the closest is better, with an if statement that asks if the furthest mole is about to be deactivated via its timer. If so, make the ideal trajectory for that mole.

Another idea is to say that all moles are "ideal" to hit and have the cursor react from the closest drawn line, it might be easier, and depending on how the feedback looks, it might work well.