Ultimatum Game

Technical Manual

Script Author: Katja Borchert, Ph.D. (katjab@millisecond.com), Millisecond

Created: January 30, 2012

Last Modified: January 26, 2023 by K. Borchert (katjab@millisecond.com), Millisecond

Script Copyright © Millisecond Software, LLC

Background

This script implements a sequence of socio-economic decision games called the 'Ultimatum Game' about the allocation of monetary resources. In Ultimatum Games one party proposes a split of resources that a second party either has to accept or reject. If rejected, neither party receives anything.

The implemented procedure is based on:

Harle, K.M, & Sanfey, A.G. (2010). Effects of approach and withdrawal motivation on interactive economic decisions, Cognition & Emotion, 24:8, 1456-1465.

Duration

7 minutes

Description

Two players play a game in which a sum of money (default: $10) has to be split. One player acts as proposer and proposes a split; the other player acts as responder and either accepts or rejects the offer. If the responder accepts the offer, the money is split as proposed. If the responder rejects the offer, neither one will get any money. In this script, the participant plays with the computer.

Harle & Sanfey (2010) had their participants play the game only as responders.

Procedure

By default 2x8 games/trials are run by block.UG_Responder
To change, go to
a) section Editable Parameters
b) section BLOCKS -> and follow further instructions
!!! list.ResponderGain contains 16 proposal items from Harle & Sanfey (2010). Harle & Sanfey (2010)
divided the 16 games randomly into 2 blocks.

Trial Sequency:
a) Responder Game: modelled after Harle & Sanfey (2010)
- The Responder Game Sequence starts out with an instruction page that informs participants of their role.
- After pressing the Space Bar the picture of the current Proposer is presented for 2s (default)
- Afterwards an (optional) waiting screen is presented (not from Harle & Sanfey, 2010)
(to get rid off the waiting screen: set parameters.waitforproposaltime = 0 under
VALUES-> EDITABLE PARAMETERS)
- After the waiting screen, the proposal is presented. The participant has 10s (default) to decide to
accept the offer (press button 'Accept') or reject it (press button 'Reject'). The script is programmed in such a way
that no response during the 10s period is counted as a rejection.
- the last screen presents the outcome (Accepted/Rejected) of the proposal and updates the participant's
total
b) Proposer Game:
- The Proposer Game starts out with an instruction page that informs participants of their role.
- After pressing the continue button the picture of the current Responder is presented for 4s (default)
- Afterwards a screen comes up that asks the Proposer to fill in the sum for the proposer (self)
and responder (partner). By default, there are 10s given for this task. The participant is informed
that an incorrect split as well as no response at this point results in the proposal to give
all the money to the responder.
To change from a timeout set-up to one where the trial waits for a specific response from the participant
go to TRIALS -> PROPOSER GAME -> openended.MakeProposal and delete /timeout
- After the proposal screen, a waiting screen is presented for a default of 10s
- the last screen presents the outcome (Accepted/Rejected) of the proposal and updates the participant's
total

Stimuli

By default the script only provides a single picture of a responder/proposer. Harle & Sanfey (2010)
used 16 randomly sampled pictures.
To edit the default picture selection go to section Editable Stimuli -> item.partnerpictures

Instructions

The instructions are not originals and can be easily edited under section Editable Instructions.
Furthermore, to change the wording for several text stimuli used in the script,
go to Editable Stimuli.

Summary Data

File Name: ultimatumuame_summary*.iqdat

Data Fields

NameDescription
inquisit.version Inquisit version number
computer.platform Device platform: win | mac |ios | android
startDate Date the session was run
startTime Time the session was run
subjectId Participant ID
groupId Group number
sessionId Session number
elapsedTime Session duration in ms
completed 0 = Test was not completed
1 = Test was completed
roletoplay 1 = participant plays the responder (default)
2 = participant plays the proposer
3 = the script plays a customized order of responder-proposer trials
!!!Go to LISTS-> CUSTOM ORDER and follow instruction to customize the order of list.roleorder
and list.ResponderGain_Custom
sum The total sum of money that gets divided (default: $10)
computerdecisionrule 1 = computer accepts all offers
2 = computer accepts no offers
3 = computer accepts all offers that >= (parameter) minacceptoffer
4 = computer accepts all offers that are at least 0.5* (parameter) sum ("the fair proposal") and rejects all
offers that are lower than (parameter) minacceptoffer (if (parameter) minacceptoffer < 0.5* (parameter) sum).
For (parameter) minacceptoffer <= offers < 0.5 * (parameter) sum, the computer decides on a random basis (default)
list.randomchoice controls the random behavior (default: p=2/3 accepts offer; p = 1/3 rejects offer)
minacceptoffer Is the minimum value at which an offer may be accepted by the computer (if (parameter) computerdecisionrule > 2) (default = 3)
proposalpresentationtime The time the proposal is presented on screen in ms (default: 10000ms)
makeproposaltime The time to make the proposal in ms (default: 10000ms)
seepartnerpic The time the picture of the current partner is presented in ms (default: 4000ms)
waitforproposaltime The time the participant has to wait until "partner" aka computer makes the proposal in ms (default: 10000ms)
!!!if set to 0, the proposal will immediately follow the presentation of the picture
!!! set to (example) = rand(2000, 10000) to achieve a less predictable waiting period
seeoutcome The time the outcome of the game is presented in ms (default: 4000ms)
participantTotal Contains the total of money the participant has won
computerTotal Contains the total of money the computer has won

Raw Data

File Name: ultimatumgame_raw*.iqdat

Data Fields

NameDescription
build Inquisit version number
computer.platform Device platform: win | mac |ios | android
date Date the session was run
time Time the session was run
subject Participant ID
group Group number
session Session number
blockCode Name of the current block
blockNum Number of the current block
trialCode Name of the current trial
trialNum Number of the current trial
role 1 = Player is Responder; 2 = Player is Proposer
proposerGain Contains the currently proposed split for the Proposer
responderGain Contains the currently proposed split for the Responder
sum The total sum of money that gets divided (default: $10)
response The participant's response
outcome Will be set to either "ACCEPTED" or "REJECTED"
latency The response latency in ms; measured from onset of proposal
participantTotal Contains the total of money the participant has won
computerTotal Contains the total of money the computer has won

Parameters

The procedure can be adjusted by setting the following parameters.

NameDescriptionDefault
roletoPlay 1 = participant plays the responder (default)
2 = participant plays the proposer
3 = the script plays a customized order of responder-proposer trials
!!!Go to LISTS-> CUSTOM ORDER and follow instruction to customize the order of list.roleorder and list.ResponderGain_Custom
sum The total sum of money that gets divided $10
computerDecisionrule 1 = computer accepts all offers
2 = computer accepts no offers
3 = computer accepts all offers that >= parameters.minacceptoffer
4 = computer accepts all offers that are at least 0.5* parameters.sum ("the fair proposal") and rejects all
offers that are lower than parameters.minacceptoffer (if parameters.minacceptoffer < 0.5* parameters.sum).
For parameters.minacceptoffer <= offers < 0.5 * parameters.sum, the computer decides on a random basis (default)
list.randomchoice controls the random behavior (default: p=2/3 accepts offer; p = 1/3 rejects offer)
minAcceptoffer Is the minimum value at which an offer may be accepted by the computer (if parameters.computerdecisionrule > 2)
(default = 3)
numberofResponderBlocks Sets how often a block of responder games should run.
By default, 2 responder blocks (each with 8 games, see Harle & Sanfey, 2010) are run
reset Dictates after how many blocks the items in list.ResponderGain are recyled. By default it will reset after 2 blocks
!!!list.ResponderGain contains 16 items => enough items to run 2 blocks of responder games
(these numbers are taken from Harle & Sanfey who ran 2 blocks of 8 trials and sampled randomly
from 16 offers)
numberofProposerBlocks Sets how often a block of proposer games should run.
By default, 1 proposer block with 8 games is played.
Trial Presentation Times
proposalPresentationTime The time the proposal is presented on screen in ms 10000ms
makeProposalTime The time to make the proposal in ms 10000ms
seepartnerpic The time the picture of the current partner is presented in ms
if duration is set to 0 no partner pic will be presented. The instructions
will automatically adapt.
2000ms
waitforProposalTime The time the participant has to wait until "partner" aka computer makes the proposal in ms
!!!if set to 0, the proposal will immediately follow the presentation of the picture
!!! set to (example) = rand(2000, 10000) to achieve a less predictable waiting period
10000ms
seeOutcome The time the outcome of the game is presented in ms
DEFAULT (COMPUTER) PROPOSALS
The default computer proposals are governed by list.ResponderGain (and list.ResponderGain_Custom if an
experimenter wishes to present a custom sequence of responder-proposer trials)
Go to section Editable Lists->list.ResponderGain and edit the default selection
4000ms