Bargaining Game

[Karl Schuhmacher]

Lucas, 

I am trying to set up a bargaining game which can potentially include multiple iterations (i.e., a loop over multiple stages) within a given period. My question is related to Ankita's questions. 

The basic structure of the game is as follows:

Stage X: Participant is randomly selected to make proposal (with Wait for others)

Stage Y: Other participants can vote on that proposal (with Wait for others)

Stage Z: if accepted continue; if rejected, go back to Stage X

In Stage X, a participant is randomly chosen to make a proposal (and others need to wait for the proposal). In Stage Y, the proposal is subject to vote (and everyone needs to wait until all votes are in). In Stage Z, the outcome of the vote is determined. If the proposal is rejected, participants go back to Stage X of the "bargaining loop," such that the process is repeated. The process continues until a proposal is accepted. 

One of the remaining issues is that the "Wait for others" functionality no longer works, once participants have gone through one iteration of the bargaining game. My guess is that there is a background variable indicating that participants have already completed a given stage once (in the first iteration), such that they simply move on to the next stage without having to wait for the new proposal / votes.

My question: How can I re-enable the "Wait for others" functionality (on a given stage) for the second, third, etc. iteration of the bargaining game? Is there a specific variable I can set back to its initial value at the end of a given iteration of the game?

Your help is much appreciated!

Best, 

Karl

[in...@lioness-lab.org]

Hi Karl,

 

You are right about the background variable. In this case it might work to say in the parameters that the experiment has multiple periods (e.g., put that at a very high number), and start a new stage after stage Z. From period 2 onwards, you can check in stage X if in the previous period the proposal was accepted or rejected. If accepted, you can show a button that pushes participants to stage outside of the loop (i.e. they are done bargaining). If rejected, you show a button that leads them to stage Y (i.e. they have to bargain again). This way you do not have to mess with the “wait for others” functionality.

 

Does this make sense?

 

Cheers, Lucas

--
You received this message because you are subscribed to the Google Groups "LIONESS Lab help and discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lioness-lab...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/lioness-lab/66a027df-8c50-48e3-9f25-edb79e816523n%40googlegroups.com.

[in...@lioness-lab.org]

* that should read “start a new *period*  after stage Z” so that stage X is the beginning of the loop, and stage Z is the end of the loop.

 

From: in...@lioness-lab.org <in...@lioness-lab.org>
Sent: dinsdag 4 maart 2025 22:25
To: 'Karl Schuhmacher' <ksch...@gmail.com>; 'LIONESS Lab help and discussion' <lione...@googlegroups.com>
Subject: RE: Bargaining Game

 

Hi Karl,

 

You are right about the background variable. In this case it might work to say in the parameters that the experiment has multiple periods (e.g., put that at a very high number), and start a new stage after stage Z. From period 2 onwards, you can check in stage X if in the previous period the proposal was accepted or rejected. If accepted, you can show a button that pushes participants to stage outside of the loop (i.e. they are done bargaining). If rejected, you show a button that leads them to stage Y (i.e. they have to bargain again). This way you do not have to mess with the “wait for others” functionality.

 

Does this make sense?

 

Cheers, Lucas

 

From: lione...@googlegroups.com <lione...@googlegroups.com> On Behalf Of Karl Schuhmacher
Sent: dinsdag 4 maart 2025 21:51
To: LIONESS Lab help and discussion <lione...@googlegroups.com>
Subject: Bargaining Game

 

Lucas, 

--

[Karl Schuhmacher]

Lucas, 

Thanks for the prompt response. [It is possible that you see this message several times. Since I can no longer see my response to your response, I am reposting it. I apologize if you see this message several times.]

I think I understand your suggestion. Essentially, the idea is to use the "built-in" loop via periods and set periods to a very high number (in the hope participants never get to that number), such that each "period" represents one iteration within a single bargaining game. While I see how this could work for a single bargaining game, I would like to conduct a repeated game, such that in each "period" a new bargaining game begins, where each bargaining game can have multiple iterations (i.e., proposals). 

In other words, I was planning to (i) use the "built-in" loop via periods to create a repeated game and (ii) play, within each period, a new bargaining game. In a sense, I have an inside loop (i.e., the bargaining game) within the built-in loop via periods (to create a repeated game environment). Therefore, it would be great to know the name of the variable indicating whether a given stage has already been completed, allowing me to set it back to its original value, when a proposal is rejected (to enable the "wait for others" functionality). Unfortunately, I do not know how the name of that variable (and I could not find it in the documentation).

I hope this makes sense and again my apologies if you see this message several times. 

Best

Karl

[in...@lioness-lab.org]

Hi Karl,

 

Thanks for clarifying. These variables are not in the documentation as it’s easy to derail the experiment if they are used the wrong way.

 

I believe that in your case you could try manually setting the internal variable (which is indeed not visible in the control panel or in the documentation).

 

At the beginning of each stage within your loop, you can use the JS command:

 

setValue("core", "playerNr="+playerNr, "wait_XXXXXXready", 0)

 

where the XXXXXX after “wait_” corresponds to the internal identifier of the current stage. You can find this number for each stage by hovering over the stage tab on top of the screen. It’s usually a 6-digit number. So the JS line could read something like:

 

setValue("core", "playerNr="+playerNr, "wait_439888ready", 0)

 

I did not test this for your specific setup, but hopefully this points you in the right direction. Should this not solve your issue, please share your experiment ID with me and I can have a look for your specific case.

To view this discussion, visit https://groups.google.com/d/msgid/lioness-lab/4ffe1488-5314-440f-89e0-53c48a8daa2fn%40googlegroups.com.

[Karl Schuhmacher]

Lucas, 

Thank you for your response. 

For some reason, it did not work when I included the code on the actual stage. However, it did work when I included it on the stage that starts the bargaining game I set up. This is the code I implemented:

let waitScreens = [xxxxxx,yyyyyy,zzzzzz];
for (const wait of waitScreens){
  setValue("core", "playerNr="+playerNr, `wait_${wait}ready`, 0);
}

Thank you again for your help. 

Best, 

Karl

[Karl Schuhmacher]

Lucas, 

I have a much better understanding now of your statement that "it’s easy to derail the experiment if they [i.e., the variables for the "Wait for others" functionality] are used the wrong way." I am mainly posting this note, so others, who may rely on the information you have provided, can avoid some issues that I had. 

Let's say a self-designed "loop" for a bargaining game consists of four stages. In this case, it will not be possible to use the "Wait for others" functionality on the fourth stage, which sends groups back to the first stage, if they need to be looped back. Let's assume we incorporate the "Wait for others" functionality on the first three stages of the loop. In this case, it is critical that the first stage of the loop does not set to zero the "wait" variable for the third stage. What can happen is that participants are in "Wait" on the third stage and, one by one, they get moved to stage four of the loop. If those participants who got moved forward first are quick to click "Continue" on the fourth stage (to return to the first stage) OR the browser of those participants who are still in "Wait" is slow (or there is some other type of delay), it is possible that on the first stage, the "wait" variable for the third stage is set to zero for some participants, while other participants are still in "Wait" on the third page. In this case, they will be held in "Wait" forever, because their record indicates that others have not passed this stage, yet. 

I am not sure if this makes sense to others, but I had to learn it the hard way and I wanted to save others the issues I had. 

Best, 

Karl