Improvements

[DominiqueMakowski]

• [x] Consider "skip intro" button (or when people press escape, or when people hold the space bar)
• [x] Add delay after the instructions (~2 seconds) before the stimulus appears
• [x] Add sounds for the states (happy bark)
• [x] Add little jump for doggo on every key press
  • [x] Higher jump as a function of score? This way, ppt's response time is feedbacked using 1) the scorebar, 2) the sound and 3) the jump
• [x] Add sprite aimations (e.g., going red or blinking) when "too fast" and "slow response"
  • [x] ~Add "green" blinking for fast trials (?)~
  • [x] Add throw sound at the end of trial when no response has been made (to mark the onset of a new trial)
• [x] Add a bit of variation in location (left/right), orientation, and size (a bit) of the stimulus (bone)
• [x] Do not make the bone disappear after threshold time: otherwise it's weird to require people to press nonetheless when the stimulus disappears. Instead:
  • [x] Keep bone visible until key press. But when RT > threshold, make it disappear in the background
  • [x] Shrink bone when it dissappears
  • [x] If RT < threshold, bone slides towards doggo (as if he got it). The threshold limit becomes implicit (no visual cue as to when the threshold is crossed, only different outcome)
• [x] Explain stimulus disapearance
  • [x] Replace whining sound by surprise sound for slow trials
  • [x] Add in the instructions that "Catch the bone before it gets stolen" and then we reveal who steals it
  • [x] An animation to the bone when as it disappears: it shrinks very quickly into oblivion (as in in someone was grabbing it into the background)

[DominiqueMakowski]

• [x] Make doggo a bit smaller
• [x] Maybe we can remvoe the "enter your name", I think we can straight up have the button "Start the game" and save the ppt ID as a random 10 character string à-la-jspsych (unless it is passed as a URL variable in the future)
• [x] Be able to set the game settings through URL variables. URL Variables include:
  • [x] p = participant name. Stored in the data. Useful for test-retest.
  • [ ] Default to random string. Or empty?
  • If this drives the file name, how to make sure we don't override data on OSF?
    • [x] Decouple OSF file name from participant name?
  • [x] s = study name. Default to nothing (empty). Stored in the data
  • [x] l1n = level 1 total number of trials (N_trials)
  • [x] osf = OSF component code to send the data to (via datapipe)
  • [x] By default, we send a copy of the data to DoggoNogoData, that will track usage
• Scoring and data
  • [ ] Make sure the value of "ISI" corresponds to the time between last key press and next stimulus (i.e., adjust it for animation buffer if needs be)

[DominiqueMakowski]

(I'm tagging @BenjaminTribe so that he follows the development)

Further polishing touches:

Landing screen

• [x] Add maybe this image as a background
• [x] Change landing text to:

Doggo/Nogo: The Game This game was designed by psychologists to accurately assess your cognitive reflexes. At the end of the level, you will receive information about your score. [in slightly smaller]By playing, you agree that your data will be anonymously collected for scientific research. You can find more information by clicking here [maybe a URL to the README page for now as we don't have anything better]

Introduction

• [x] Reposition the "skip" progress bar to be slightly lower. Replace text to just mentioned "Hold spacebar" (i.e., remove the escape option from the text)

Instruction screen

• [x] Do not skip it automatically, it says on until the key press
• [x] Key symbols:

Can we have like instead of the down arrow written as text, having like a down arrow key "logo"? Something like that

• [x] Doggo has a slight change of scale when game proper starts. Should be the same

Game

• [x] Remove text ("getting a new bone")
• [x] Optional: Maybe to consider for first trial(s) to indeed write "Press Down key" if people don't - as it could indicate that people don't know what to do
• [ ] Mechanism problem: if one starts to have slow trials, then the slow trials are succeeding super fast, leading to a cycle of losing. Maybe Probably we want to increase the upper threshold if response is > upper limit (e.g., by +100ms)

[DominiqueMakowski]

Burnin period

The game seems quite hard, so it might we worth to it to introduce a burn-in period where it's easy at the beginning and gets progressively harder

How about:

The threshold (and also the upper limit) get adjusted by the following:

• Threshold = Threshold + Threshold*(1-n_trial/10)

What that means is that for the first trial (aka n_trial=0): threshold = threshold + threshold*1 (so basically it gets doubled) Then this benefit progressively lowers as n_trial increases until it becomes 0 after 10 trials

[Max-Lovell]

Firstly, some implementation notes to consider:

• medianRT is initialised to maxRT/2
• maxRT = 2*medianRT, but has minimum of minRT*2
• Early presses and misses count are recorded as individual 'trials' - and so they affect anything which relies on the trial count. I could instead make some global counter which only increases on slow and fast trials....
• Quickly added a display of trial score next to total score - could maybe do with an animation
• See GetNewTargetScore function here: https://github.com/Sussex-Psychology-Software-Team/DoggoNogo/blob/main/Assets/Scripts/Simple%20RT/ScoreManager.cs
• Might also be of interest for some points below: https://github.com/Sussex-Psychology-Software-Team/DoggoNogo/blob/main/Assets/Scripts/Simple%20RT/TrialManager.cs

Some ideas:

• Save bone location and screen info
• Use spacebar for lefties
• Throw noise is annoying?
• URL Vars
  • Add Study name and participant name to file name
  • Need a URL var for forwarding address on 'continue'
  • Pass any included url vars onto forwarding address
  • option to turn off sending data to our OSF

Replies to above:

"Add "green" blinking"

Unsure about this?

Add throw sound at the end of trial when no response has been made (to mark the onset of a new trial)

I think this works as the feedback for a Missed trial - then each trial has a signal for it's end, after which a new trial begins when the feedback text is wiped.

Make sure the value of "ISI" corresponds to the time between last key press and next stimulus (i.e., adjust it for animation buffer if needs be)

So, l've purposefully written all animations to be based on a pre-specified duration for this. currently the longest one is the bone being thrown away on missed trials, which takes 1 second. There's also a 1 second delay between trials. A new trial is signified by the feedback text being removed - this is when the ISI timer starts. Our ISIs at the moment are at their least 1 second, which means if that was included in the animation time, there would be no trial. I think if we're signalling the end of a trial with animated feedback, that signals also a time for participants to have a break before they are in that readiness state waiting for the next stimulus. my 2¢ anyway.

Default to nothing (empty)

All URL variables default to 'query variable not found' if that is the case - empty strings are also indicative of an error so I've returned something specific for now.

l1n = level 1 total number of trials (N_trials)

we don't control the number of trials per level - levels are controlled by score, and there isn't anything specific about level 1. I've implemented this as an optional control for the nTrials variable, which is essentially an estimated total trials used by the function which is used in the calculation of the max score for the next stage. I think this var name should be changed?

Threshold = Threshold + Threshold*(1-n_trial/10)

done with min(0, (1-n_trial/10)) as this would end up with negative values

Mechanism problem: if one starts to have slow trials, then the slow trials are succeeding super fast, leading to a cycle of losing. Maybe Probably we want to increase the upper threshold if response is > upper limit (e.g., by +100ms)

So are you saying if rt > maxRT, maxRT += 100? Can we avoid saying 'threshold' if it's getting used to describe medianRT and maxRT?

[DominiqueMakowski]

Thanks for these precisions, very helpful.

1. medianRT is initialised to maxRT/2

But what happened on the first trial?

2. maxRT = 2medianRT, but has minimum of minRT2

My hunch is that the minimum safety fallback isn't necessary, I don't think it's mathematically possible to have 2median RT to be < to 2minRT

3. Early presses and misses count are recorded as individual 'trials'

Mmh indeed we might want to separate early presses from the rest because if I understand, when people do early presses it still lowers the amount of "real" trials right?

4. Save bone location and screen info

Yeah, that's a good idea!

5. Use spacebar for lefties

I think that lefties are also used to use the arrow keys? But that makes me think that @BenjaminTribe we should add a handedness question if the demographics of study 1

6. Throw noise is annoying?

Lol well you've been overexposed to the game to be fair. But yeah it kinda is haha

7. "Add "green" blinking"

Yeah, that's probably useless. However, I would like to add sparkles upon "evolution" (and potentially even a pause, like the doggo evolves, and then it's like "press down arrow to continue")

7. a time for participants to have a break before they are in that readiness state waiting for the next stimulus

Yeah, as long as that minimum time is 1s (in real time, i.e., including the animation) I'm happy

8. empty strings are also indicative of an error so I've returned something specific for now

👌

9. as this would end up with negative values

👌

10. Can we avoid saying 'threshold' if it's getting used to describe medianRT and maxRT?

Okay yes fair that's confusing. In my mind there's the "threshold" for fast/slow answers (both are valid), which is currently operationalized as medianRT (but could be something else, that's why I used to say threshold to be more general but yes), and the "MaxRT", which is the maximum time for the window in which people can make valid answers. But yes let's be more specific.

So are you saying if rt > maxRT, maxRT += 100?

Yes, what do you think?

[DominiqueMakowski]

Just tested, it feels quite good now I'd say!

Two graphic things:

• As mentioned above, after each phase add sparkles coming off doggo once he evolves? and maybe like a break with a manual restart. Also currently the score "carries over" to the next bar, but should we maybe kind of "reset" it - i don't know how to explain, but currently if they are near completion of the first phase and you do a really good score you have parts of the next bar filled, but I feel like it would make sense that it just "completes" the current active bar and then restart from 0 for the next. Not sure if that's clear

• For the end image
  • Can we make a smoother transition where the end score screen kind of fades in from a black screen? So that it's a bit more "climactic"
  • change "The experiment is over" for "You complete the game, congratulations!"
  • Add an animation of doggo that jumps happily on the side (maybe while the "result bar" is loading?)
  • Change text to "Your reflexes were faster and more accurate than XX% of people. Well done!" And then, in smaller: "But can you do better? Click Restart to try again"

In general, the text doesn't look super sharp (it looks a bit like text on an image that was stretched), I'm not sure if it is because of the outline, or the arbitrary scaling etc - not sure we can do anything about that though

[DominiqueMakowski]

Using Median(RT) (i.e., the 50th percentile) as a threshold makes it quite challenging and punitive (well, not as much as Dark Souls), perhaps in the future an offshoot study could test the effect of a gentler threshold (e.g., 75th percentile) on fun and engagement :) (maybe the percentile level could be a URL var for easy changes - in a future version).

[DominiqueMakowski]

I managed to nicely download & open the data from Python, amazing stuff @Max-Lovell !

• There's probably an issue with userAgentString
• Rename trial_n for trial_number or trialNumber (to keep consistency with the other keys)
• Can we save the current "threshold" value? (i.e., the median)
• rename trialType asz responseType maybe? (because it's a function of the response not of the trial per se)

[Max-Lovell]

Nice, thanks for the feedback, I'm off next week but some notes for me when I get back:

RT task

• [ ] 3rd evolution dog image positioning is off
• [x] Remove maxRT minimum bound
• [x] Sparkles on level change
• [x] Down to resume on level change
• [x] Start healthbars at minimum
• [x] Handle total score separately for each level.
• [x] Add in separate 'trial count' variable to record only slow and fast (and missed?) trials
• [x] Stop Early presses rt from being included in median

Data

• [x] Export data with: trialNumber, threshold, and responseType vars
• [x] Save bone location and screen info

End screen

• [x] smoother transition where the end screen kind fades in from a black screen?
• [x] change "The experiment is over" for "You complete the game, congratulations!"
• [x] animation of doggo that jumps happily on the side (maybe while the "result bar" is loading?)
• [x] Change text to "Your reflexes were faster and more accurate than XX% of people. Well done!" And then, in smaller: "But can you do better? Click Restart to try again"
• [x] Fix text blur issue

Programming generally

• [ ] Need separate feedback, RT, and level manager classes
• [x] Need to handle missing trials better
• [x] Look into handling early presses in trial manager?

But what happened on the first trial?

Didn't know what to do with it so just kinda arbitratily halved the maxRT. Actually just changed it to the midpoint between min and max.

My hunch is that the minimum safety fallback isn't necessary, I don't think it's mathematically possible to have 2median RT to be < to 2minRT

Can't remember what happened to make me put that in tbh - I guess I got some error. I'll take out and we can see how it goes.

Mmh indeed we might want to separate early presses from the rest because if I understand, when people do early presses it still lowers the amount of "real" trials right?

Yeah they increase the trial number and lower the score.

I think that lefties are also used to use the arrow keys?

Son of a bitch you're right. But also spacebar is just a lot more comfortable to use with your lefthand, spacebar is big and in the middle so generally easier. Up2u

Yes, what do you think?

Mmm if someone stepped away from the computer it'd screw up the system a bit - is there a more objective way to put an upper limit on reaction times?

There's probably an issue with userAgentString

looks fine but you'll need a special parser to get the data out, unless you tried that? It's a super annoying format, no idea how we ended up with this system tbh, but it's the only info we'll get automatically.

[DominiqueMakowski]

Add in separate 'trial count' variable to record only slow and fast (and missed?) trials

Maybe to simplify this we could just add a field trialValid: true that would be false for early presses and all computations based on the number of trials would only take into account where trialValid is True (but I'm fairly happy with how the data is formatted now because it's straightforward to put all trials into a dataframe (since they have consistent fields) and then filter out and keep only the valid ones