Rocket launch updates

[K-Meech]

Decided to split these small fixes into a separate PR, rather than rolling them in with the save data for #20 . Mostly small fixes that make testing the rocket launch game easier, or make it simpler to access values that change between games to add to the save data.

• reduced gazeTolerance setting from 300 to 2 in the unity editor (otherwise the entire game field of view is within the gaze target range)

• when useMouseForTracker is checked, I added a line to make sure the mouse world position is used (rather than raw coordinates). This means that when the checkbox is ticked, and the game is played in the editor, mousing over the launch code box advances the numbers, while holding the mouse towards the edges doesn't (so it's matching what the real gaze point would do)

• For the save data, I wanted to capture all values that vary between games. Due to shakeSpeedReduction this includes the minimum required head speed (different for pitch vs yaw games). To make this easier to capture in the save data, I split this into two variables minimumSpeedPitch / minimumSpeedYaw which get chosen between at the start of the game to populate minimumSpeed. Potentially this is also easier to read at a glance, then having to multiply minimumSpeed by shakeSpeedReduction.

• I also wanted to capture the final gazeTolerance for each game. This was challenging for the current setup as:

  • In the call to gazeBuffer.gazeSteady, the gazeTolerance is passed as gazeTolerance * gazeTol.magnitude (with gazeTol.magnitude being based on a measure of the size of the target object). This means the actual gaze tolerance used for the calculation isn't equal to gazeTolerance.
  • The size of the target object (the launch code box) doesn't always match the gaze tolerance. E.g. when the gazeTolerance was set to 300 (covering the full screen), the box was still much smaller.

To get around this, I added some code to scale the target object (and launch progress ring) to match the input gazeTolerance. This should mean the size always matches, so if you look just outside the launch code box the numbers won't advance, while just inside they will. This means gazeTolerance can get passed directly to gazeBuffer.gazeSteady also, meaning this saved value will accurately reflect the tolerance used.

Happy to change / discuss any of these points - thanks!

[mmcleod89]

The code looks good, I'll be able to double check how it works in play when I get home and have access to my eye tracker!

[mmcleod89]

This all works for me. I think scaling the image of the number / progress bar to represent the tolerance of the gaze is sensible, but one thing to consider during play testing is that you may want the actual tolerated zone to be slightly larger than the appearance on the screen, especially if the gaze crosshair is not going to be visible, as the tracking isn't always perfectly stable or accurate.

[thompson318]

This does a nice job of tidying up the existing code. Separating pitch and yaw speed is a good idea as is transforming mouse coordinates to world. Nice to see the progress ring properly scales too.
Couple of things that could be added (or a separate PR):

• Setting the launch time and adaptive difficulty correctly. Currently set at 5 seconds * adaptive difficulty (1.7) = 8.5s. Launch time should start at 30s (it's currently set short to make testing quicker). I'm also not clear yet on how it should scale with adaptive difficulty. Should it increase continuously or in steps. What is the maximum value?

• Remove (or hide) the gaze crosshair.

[mmcleod89]

I have to admit I find the crosshair very helpful when testing it to have the feedback that my gaze is actually registering in the right place, especially since the progress bar won't start until both things start happening and usually with a little delay. We might want to consider having some other feedback, such as one of the box-style crosshairs that doesn't obscure the text or having the number highlight when your gaze is one it so that you can have confidence that the game is recognising what you are doing.

[K-Meech]

Thanks for the comments both! I've created a new issue: #81 to keep track of these suggestions - do add anything I may have missed.

I'll keep this PR as-is for now, so that I can finish off the save data with these changes. Happy to implement any of these features though once we've discussed with David.