open source project to tackle the problem of long development cycles required to produce software to conduct multi-participant and real-time human experiments online.
The "Player" tab in the admin page (configuration tab) would include Authorization rules like:
Unique participants? (true/false) Exclude those who have already played the experiment.
Connection properties: reject incoming connections based on properties such as IP, browser type, PING (delay of communicating with the server), mobile devices (yes/no?), etc.
Whitelisting participant: in case the experimenter wants to add a list of the participants who are allowed to play the game (i.e., whitelisting emails; MTurk IDs, etc.). In this feature, the experiment designer can upload additional information about the participants (i.e., their previous scores, gender, etc.).
Dealing with disconnections:
Pausing the experiment and displaying a notice to all connected clients with a countdown to give a chance the player to come back.
If the countdown reaches ends, the experimenter can configure the game to:
Continue with fewer players
Letting smaller groups continue ensures that real people generate all the information that participants respond to
Connect a bot player
Potentially compromises the internal validity of the data from groups affected by a dropout
Also raises issues of deception if such computer-generated information is not disclosed
or cancel the game, and redirect participants to the exit survey.
This will damage the reputation of the experimenter as participants will be unable to earn as much as they had anticipated.
The participant can come back, or otherwise fallback with a default behavior
I.e., that participant will give ‘null’ answers, and it is up to the experimenter to deal with the disconnection, i.e., player.get("status") will be offline and they can show a disconnection avatar or something). This will require implementing player.get("status") which can return: online, offline, idle, notLooking etc.
Note about disconnections:
If the disconnection happens exogenous to the experiment (e.g., due to network issues, screen freezes, a random real-life event that prevent the player from continuing the experiment), then it is ok and unlikely to affect the overall results of the experiment (just an expensive annoyance)
If a disconnection happens endogenously to the experiment (i.e., participants disconnect because of something that happened in the game--losing points, getting bored in one of the conditions, etc.) then this will jeopardize the internal validity of the results. This is so bad for the experimenter! They have to be careful.
The "Player" tab in the admin page (configuration tab) would include Authorization rules like:
player.get("status")will beofflineand they can show a disconnection avatar or something). This will require implementingplayer.get("status")which can return:online, offline, idle, notLookingetc.