I have created a monetary incentive delay task and a social variant of the classic incentive paradigm. In each trial the participant must respond (click on the white square) in enough time to be able to win (see a rewarding image), or else they lose (see a punishing image). I have attached the experiemental files here.
They are designed to be used for ERP analysis later on hence the need for a substantial number of trials.
The current issue is that the task is too easy and participant will just click continuously when the fixation cross appears until the white square appears subsequently. I’m looking for advice on how I could make this task harder?
Currently there is a staircase structure to the trials loop so that the response duration is adjusted each time depending on how they performed on the previous trial. However this doesn’t seem to be working as intended as particiapnt simply click continuously when the fixation cross appears.
I have considered adding a more substantial jitter to the presentation of the fixation cross, and adding in an additional delay of a blank screen between the fixation cross disappearing and white square appearing to reduce pre-emptive clicking? Any thoughts much appreciated.
Thank you for all the very useful suggestions, your second of jittering the onset of the target is along the lines of what I was also thinking of - so to increase the delay between the fixation cross and target, but importantly jitter this period of time more obviously to reduce the predictability of the stimulus.
Though I understand your point about the task, it is intended to be easy, however I think my structure as it stands is not allowing (or allowing for very few) loss trials to be recorded.
And the staircase structure is set within a code component that adjusts for each new trial based on the participant performance saved from the last routine (or trial).
However, now the white square doesn’t appear at all nor is the jitter working. Whenever I try to adjust the start time of target_stim (the image component) or target_mouse (the mouse component) linked with it either the white square doesn’t appear or the delayed start time is ignored - do you know why this might be?
I am aiming to try and make it so that participant’s will be receive a loss as feedback for making a click before the white square appears (in addition to clicking too late as its set up now) but due to the above problems I can’t see how to do that within the same routine currently.
Thank for the suggestions, I’ve attached a zip folder of my experimental folder which should allow you to run as it will contain everything you need. I’ve created a reduced version so I can just focus on getting this work within a set of trials for now.
Unfortunately still no white square (also this is an image rather than a polygon as I am trying to keep all stimuli as images to try and standardise any trigger delays with stimulus presentation), I added the changes in you outlined as you’ll see in the zip folder.
I think I may be due to a line of code in the every frame tab in my code component (see below), I think t refers to time since the start of the routine so maybe that is intefering with the other start times? This is set up currently to monitor whether the mouse pressed during the target presentation but I suppose this is redundant now. However I don’t know currently how to add code for a start time for each of the target_stim and target_mouse components in the Coder.
#check correct response
if t < 0.2:
correct = 1
continueRoutine = False
correct = 0
continueRoutine = False
Are you sure you clicked fast enough? 200 ms is extremely short, even for a simple RT-task. Your routine ends after randOnset + resp_duration (plus transparent rectangle), regardless of when you responded. One way to check if timing is an issue here is to increase your RT-window and see if you still get only losses. Another way to check the if-else construction is to include some print statements. Simply print the values of correct and tooearly to the console in your feedback-routine.
I substantially increased the duration of each of the variables above and the same thing occurs. It seems that I’m always getting feedback that is always a win or always a loss - is there another way of coding to present loss feedback to an early mouse click than the method I have taken?
So, getting closer. Yes you’ve understood the conditions I essentially end up with under the Incentive trial types. Adding in the elif statements you recommended I can no achieve 2 out of 3 of those things.
Specifically, if no click is made (i.e. they don’t click early but don’t click the white square in time) then you get a loss, and if you click early (but haven’t clicked the white square) you get a loss.
The problem is if you don’t click early and have clicked the white square it is still coming up as a loss, when the first if statement should mean this is now a win, which leads me to think I am always getting a loss.
I have included more print statements but due to low memory I can’t monitor the Runner whilst the task is running, the statements also don’t appear quickly enough for me to compare (again due to computer constraints on memory).
I’ll keep playing around with the elif statements, my only guess is that all the conditions aren’t being fully captured?