Support Home Multiplayer How To: Multiplayer

How To: Multiplayer

  • Overview
  • Creating Multiplayer Tasks
  • Allocating Roles to Players
  • Taking Turns
  • Controlling Flow
  • Player Positions
  • Previewing Multiplayer Tasks
  • Running Multiplayer Experiments
  • Matching Players
  • Rematching Players
  • Step-by-step guide
  • Player Control - Worked Example

Overview


The Multiplayer tool allows you to easily create online multiplayer experiments and studies. In a multiplayer task, several participants take part in a task together, in real time. A multiplayer task can either be more 'turn-based', where one participant takes an action and then another participant responds, or 'real-time', where participants perform actions simultaneously.

Schematics of a sequential turn-based task and a simultaneous real-time task

Creating Multiplayer Tasks


Note: Multiplayer is an add-on to the Task Builder 2 tool. You can create tasks using Multiplayer for free, but you will need to purchase the Multiplayer add-on in order to collect data from participants in a multiplayer experiment.


Setting up

The first thing to do is to create a new Task Builder 2 task, and enable multiplayer. Go to the Multiplayer tab and click "Enable Multiplayer". You also need to specify how many players are needed for your task - Gorilla supports tasks with up to 8 players. You will usually want to keep player numbers small (think 2-4) as tasks with larger player numbers are inherently more susceptible to participants dropping out (and therefore leaving the others without enough people to continue).

Screenshot of the Multiplayer tab in Task Builder 2. The Enable Multiplayer box is checked. Number of players is entered as 2

You will notice that your spreadsheet automatically gains some new columns, one for each player (Player A, Player B and so on):

Screenshot of the spreadsheet with new columns PlayerA and PlayerB

These columns correspond to roles allocated to players during a multiplayer task. This is further covered in the Allocating Roles to Players part of this guide.


Creating Tasks

You create multiplayer tasks just as you would a standard, single-player task in Task Builder 2 - you can use all the same components to build your task. In addition, you gain access to the Multiplayer component, which simply controls which player an object is enabled for. This allows you to only enable certain objects (e.g. response buttons) for a specific player.

For example, consider a task where Player A has to think of an animal, and Player B guesses which animal Player A chose. Player A then says whether Player B was correct or not:

Storyboard showing a 2-player task with Player A's view on top and Player B's view below

There are objects that are always visible, and some that should only be available to a specific player. The Multiplayer component allows you to control this and assign certain roles to specific players:

Storyboard with items visible only to Player A circled in red and items visible only to Player B circled in blue

Read more about roles in the Allocating Roles to Players part of this guide.


Allocating Roles to Players


Creating Roles

Different players can have different roles in the multiplayer game. For example, in a monetary negotiation game, such as the Ultimatum Game , one player is an offer-maker who makes an offer to other player(s).

Roles can be created within the multiplayer task, using the Multiplayer component. Adding the Multiplayer component to an object in the task allows you to specify which player gets to see/interact with that object.

For example, when you add a Multiplayer component to an object with a Single Number Entry component, and select Player A in the Multiplayer component, this would make the Single Number Entry component only available to Player A and not other players. In the example of a monetary negotiation game, this can be used to allow Player A to play the role of the offer-maker who types in the amount they wish to offer to other players.

Task Builder 2 Object with a Single Number Entry component and a Multiplayer component with Player set to Player A

Allocating Roles

When taking part in a mulitiplayer study, participants play in different player positions. For example, in a two-player game, someone will play as Player 1 and someone else as Player 2. You will learn more about player position assignment from the Player Positions section of this guide.

You must let Gorilla know which players (Player 1, Player 2 etc.) should have what roles (Player A, Player B etc.) at each point in the multiplayer task using the 'Player' columns in the Spreadsheet. The 'Player' columns appear in the Spreadsheet automatically when the multiplayer setting is switched on, and the number of columns reflect the number of players that the game is configured for:

Screenshot of the spreadsheet with new columns PlayerA and PlayerB

For example, if you create a 2-player game, two columns - one for 'Player A' and one for 'Player B' - will appear in the Spreadsheet. These columns will then need to be filled with the numbers corresponding to the player positions, e.g. entering 1s in the Player A column and 2s in the Player B columns means that Player 1 in the room will play the role of Player A, and Player 2 in the room will play the role of Player B:

Screenshot of the spreadsheet showing PlayerA column filled with 1s and PlayerB column filled with 2s

In the example above, where all the rows in the Player A column are filled with the same number '1' and all the rows in the Player B column are filled with the same number '2', the role allocation will stay consistent throughout the task. This means that Player 1 in the room will play the role of Player A and Player 2 will play the role of Player B through the whole task.

If you wish to configure turn-taking in your task, you can reshuffle roles for your players by switching the numbers in the Player columns. Learn more about turn taking in the Taking Turns section of this guide.


Taking Turns


In some multiplayer paradigms, players should take turns performing different roles. For example, in a monetary negotiation game, such as the Ultimatum Game , Player 1 can be an offer-maker first and make an offer to Player 2. In the second round, Player 2 can make an offer and Player 1 can be the offer-receiver. They can swap roles again in the next trial, making Player 1 the offer-maker again and Player 2 the offer-receiver, and so on. This turn-taking can be configured in the Spreadsheet tab, using the player columns.


Configuring turn-taking

When designing your task, you use the Multiplayer component to control whether a particular object is only enabled for Player A, Player B, Player C, etc.

In your task's spreadsheet, you must enter values corresponding to player numbers into the Player columns to assign which player in the room gets to play which role in each trial. In Gorilla, each row in the spreadsheet indicates a single trial in the task. Therefore, you can use the 'Player' columns to configure turn-taking and change the roles of your players throughout the task.

For example, entering a '1' in the Player A spreadsheet column and a '2' in the Player B spreadsheet column in the first row means that, in the first trial, Player 1 in the room will play the role of Player A and Player 2 in the room will play the role of Player B.

If you then reverse the player numbers in the second row (so Player A column has a '2' and Player B column has a '1'), then Player 2 in the room gets to play the role of Player A and Player 1 in the room gets to play the role of Player B in the second trial. This allows you to use the spreadsheet to define turn-taking, and ensure that all participants have been able to perform each role.

Schematic showing how Player 1 and 2 swap roles between Player A and B on each trial Screenshot of PlayerA and PlayerB columns in the spreadsheet containing numbers 1 and 2 in first row, swapping in second row

You can see turn-taking in practice in our Ultimatum Game multiplayer sample.


If you wish to keep the role allocation consistent throughout the trials, fill in the same number for all rows within a given Player column in the spreadsheet. For example, entering 1s in all the rows of the Player A column assigns Player 1 to the Player A role througout the whole task. Read more about role allocations in the Allocating Roles section of this guide.


Controlling Flow


Multiplayer tasks can progress in various ways, depending on your paradigm. There are three modes you can choose from:

1. Advance the screen when all players are ready

This is the default option, and is suitable when you want your players to progress through the screen(s) at the same pace. For example, you might want to ensure every player reads the instruction screen before they progress onto the task trials - you can set this up in two ways:

  • Add one way to progress the screen, shared across everyone. For example, add a Continue button and don't add a Multiplayer component to it - this will make it available to all players as a default. Players will have to wait until everyone presses the Continue button before the screen moves on.
  • Add a way to progress the screen for every individual participant. For example, add a separate Continue button with a Multiplayer component for Player A, and a separate Continue button with a Multiplayer component for Player B, etc. Then, add the Advance - Multiplayer component to the Screen tab and set the Required Players setting to 'All'. This way, the screen will only progress after all players have clicked their individual Continue button. It is crucial to make sure that all players have some way of advancing the screen, otherwise the players could get stuck waiting for others to progress.
Image showing a screen component Advance Multiplayer with a Required Players setting set to All.

2. Advance the screen when the first response is received

By adding the Advance - Multiplayer component to the Screen tab, you can control whether the screen should progress after all players complete it, or when just the first response is received. This is suitable for screens where it is a single player's turn, and once they have completed their action, the screen should advance.

Image showing a screen component Advance Multiplayer with a Required Players setting set to First.

3. Advance the screen when a specific player responds

If you want to allow only a specific player to control the advancement of the screen, without waiting for responses from other players, add the Advance - Multiplayer Player component to the Screen tab and specify which player should progress the screen. Gorilla will then progress the screen only after receiving a response from the designated player.

Image showing a screen component Advance Multiplayer Player with a player setting set to Player A.

Read on to learn more about player positions.


Player Positions


When taking part in a multiplayer study, participants play in different player positions. In a two-player game, someone will play as Player 1 and someone else as Player 2.

Imagine you have 6 participants in your experiment: let's call them p101, p102, p103, p104, p105 and p106, and you want them to take part in a two-player task. When participants are matched together in your experiment, they are assigned to the same room. A room is simply a collection of participants who have been matched together.

Within this room, the players have a fixed, canonical order: e.g. in a two-player room, one participant will play in a Player 1 position and the other in a Player 2 position. (In a 4-player room, there would be four player positions: Player 1, Player 2, Player 3 and Player 4.)

When paired up into rooms of two players each, the player rooms would look something like this:

Schematic of three multiplayer rooms each containing a Player 1 and a Player 2

In the rooms, your participants will be matched and assigned to Player 1 and Player 2 positions.

As a default, the order in which your participants are assigned to the player positions is arbitrary (we actually apply some randomisation to ensure that participants aren't simply matched in the order that they arrive). However, you can manually assign players if you want specific participants to play on specific positions - learn more in the Matching Players section of the guide.


Positions and Roles

Players playing in positions of Player 1, Player 2, Player 3 etc. must be allocated roles of Player A, Player B, Player C etc. within the multiplayer task. Read more about role allocation in the Allocating Roles to Players part of the guide.


Previewing Multiplayer Tasks


Simulating Players

In order to simulate real participants, you should open as many previews of your task as you have players, so that you can see each player's view of the task at the same time.

You must preview your multiplayer task using separate browsers or devices. You cannot be logged in as two different participants in the same web browser, even if you open separate tabs or windows. Therefore, the easiest way to preview your multiplayer task is to log in to your Gorilla account in two separate browsers (or however many you need), and create separate previews, one preview in each browser.

Schematic of a preview of a 2-person multiplayer task. One player's view is being previewed in Chrome, the other in Firefox

Note: If your multiplayer task uses subsystems, such as audio and/or video recording, you will need to preview the task for each player using separate devices, as opposed to just separate browsers on the same device. This is because a subsystem used on one device can only be used for one player at a time. You can use the same type of browser on each of the devices.

Warning

Do not run multiplayer in incognito/private browsing mode. Incognito mode does not allow loading and storing of task data in the same way as a normal browser mode does. This can affect data sent from one player to another, and subsequently prevent multiplayer tasks from previewing/running properly.

Participants should also not take part in your multiplayer study in incognito or private browsing mode. There is no way to prevent participants from using incognito mode, but we recommend advising them not to use it. You can include this information in a study description, on the instruction screen, or in an email to your participants.


Simulating Multiplayer Rooms

When you click the 'Preview' button in your multiplayer task, you will be asked if you want to create a room or join a room. In order to join players in the same room, click on 'Create a room' as one player, and click on 'Join a room' as another player. Then, copy and paste the room ID from the created room into the other player's preview. This will pair the preview participants so that they are playing together. See the video below for reference.

Pro Tip

The player who creates a room in preview mode will be assigned to the Player 1 position, while the player who joins the room using the room ID will be assigned to the Player 2 position. See more information about position assignment in the Player Positions section of this guide.

Note: creating and joining a room is a preview feature to allow you to simulate the multiplayer experience. In real, live experiments, multiplayer rooms will be created automatically. See the Running Multiplayer Experiments section of this guide for further information on real-life experiments.


Running Multiplayer Experiments


Note: Multiplayer is an add-on to the Task Builder 2 tool. You can create tasks using Multiplayer for free, but you will need to purchase the Multiplayer add-on in order to collect data from participants.


Warning

Do not run multiplayer in incognito/private browsing mode. Incognito mode does not allow loading and storing of task data in the same way as a normal browser mode does. This can affect data sent from one player to another, and subsequently prevent multiplayer tasks from previewing/running properly.

Participants should also not take part in your multiplayer study in incognito or private browsing mode. There is no way to prevent participants from using incognito mode, but we recommend advising them not to use it. You can include this information in a study description, on the instruction screen, or in an email to your participants.

Setting up

To create a multiplayer experiment, you need to add a Lobby node to your experiment tree. The Lobby node groups together participants who are going to play together. Participants who are grouped together for multiplayer experiments are put into the same room - everyone starts off in the lobby and then gets assigned to a room with the other players they are going to play with. The size of the room depends on how many players the task is for. For a two-player task, we want two participants in each room, for a four-player task, we want four in each room, etc. See an image example below:

Schematic of 7 participants in a Lobby being assigned in pairs to Rooms

You can add a Lobby node to your experiment in the same way you would add other nodes. Go to the Experiment Builder, click Edit, and click on the '+Add New Node' button in the Design tab. Then select Lobby from the list of experiment nodes:

Image showing experiment nodes menu with a Lobby node highlighted in red
Warning

The Lobby node is only available for users who have purchased a multiplayer license. If you would like to buy access to our multiplayer tools, please go to our pricing page . Access to multiplayer experiment nodes is granted automatically to users with a multiplayer license. If you have any multiplayer-related questions, please contact our friendly support team .


Configuring the Lobby node

When we previewed a multiplayer task, we created a player room manually (see the Previewing Multiplayer Tasks section for more details). Now in the experiment, we use a Lobby node to create player rooms for us.

To configure the Lobby node, click on the node to open up its configuration settings. The minimum required setting for the Lobby node is the number of Players that should be assigned to each player room. This needs to be the same number that you specified earlier in your multiplayer task:

Screenshots of the Lobby node with 2 players specified in the settings and a multiplayer task with Number of players set to 2 Image showing the configuration settings for the lobby node, with a players setting set to 2.

Additional Settings

Apart from the Player number setting, the Lobby node has multiple other settings that allow you to customise your multiplayer study. See a full list of Lobby node settings with example settings filled in below:

Image showing the configuration settings for the lobby node with example settings filled in

One setting of the Lobby node needs to be explained in more detail: the Mode setting, that determines how participants form player groups. Participants can be matched with other players automatically, either randomly or according to specific rules, or manually by researchers. Learn more in the Matching Players section of the guide.


Multiplayer Experiments Best Practice

Below are some tips for a smooth run of your multiplayer experiment:

Prevent stuck participants - use Time Limit on Lobby Nodes

The Time Limit setting in the Lobby node is a very handy setting that can improve participant experience and save you time and tokens! When this setting is used, participants can move onto another node in the experiment via a Time Out branch, instead of being 'stuck' in the Lobby node indefinitely until they withdraw their participation. You can branch them to a relevant experiment node, such as a Questionnaire node where you can show them some information on their time out ('Sorry we couldn't match you with other players at this time!'), or a Reject node where their participation will be withdrawn automatically and tokens that they have reserved will be returned to your account for future use.

Control participants flow - use Live Gate Nodes

When running your experiment, participants will be coming into your study at various rates. This is a challenge for multiplayer paradigms where participants need to gather at a similar time to form a group of players, and progress through the study at a steady pace. As a consequence, your participants might experience delays while waiting for other players to join, or progress through the experiment, which decreases their satisfaction and risks them withdrawing. To mitigate this issue, we've created a Live Gate node that lets you dynamically control the progress of participants within the experiment.

For example, if you run a multiplayer task for four players, you can wait to have four participants in your Live Gate node before you manually let them start the multiplayer task together. You can monitor how many participants are waiting in the Live Gate node, and control the release of participants via a special url that is provided within the node (it's a good idea to refresh the Live Gate node frequently to see the most recent updates). You can use Live Gate anywhere in the experiment tree, but it is especially useful to place it just before the Lobby node to control the flow of participants into the lobby where they are matched. Read more about matching participants in the Matching Players section of this guide.

The Live Gate nodes are also invaluable in multiplayer experiments that involve rematching players midway through the study. You can wait for several groups of players to progress throughout the first part of the experiment and let them wait in the Live Gate node until you have a desired number of groups to rematch the players. For this purpose, use one Live Gate node before each of the Lobby nodes that you use for rematching players. You will find more information in the Rematching Players section of this guide.

Maximise recruitment - check the requirements of your chosen Recruitment Policy

There are multiple recruitment policies you can use to collect data for your study - see a full list in our Recruitment Policies guide. If you are using a Third Party recruitment service, such as Prolific, Sona, MTurk etc., you might face some restrictions from the services that could affect the running of your multiplayer study.

For instance, Prolific uses a 'rate limiter' to even up access to studies between participants, so that studies aren't taken only by the most active participants on their platform. Having the rate limiter in place can be tricky when recruiting for a multiplayer study, because it slows down recruitment and could prolong player group formation. This can lead to delays and even attrition from those who do not wish to wait for others to start a study. You might want to consider contacting Prolific Support and asking for the rate limiter to be temporarily disabled on your Prolific account. We also recommend asking your participants to patiently wait for others to join before they can begin the study.


Matching Players


This section explains room assignment modes, and covers how to apply advanced matchmaking rules so that participants are matched according to specific criteria.

Participants entering the Lobby node during a live experiment can be matched with other players either automatically or manually. You can select how you wish your participants to be matched using the Mode setting in the Lobby node.

Pro Tip

When running your experiment, participants will be coming into your study at various rates. This is a challenge for multiplayer paradigms where participants need to gather at similar time to form a group of players, and progress through the study at a steady pace. As a consequence, your participants might experience delays while waiting for other players to join, or progress through the experiment, which decreases their satisfaction and risks them withdrawing. To mitigate this issue, we've created a Live Gate node that lets you dynamically control the progress of participants within the experiment. You can use Live Gate node anywhere in the experiment tree, but it is especially useful to place it just before the Lobby node to control the flow of participants into the lobby where they are matched.


Automatic Mode

Automatic mode is the default mode of the Lobby node. There are two ways your participants can be matched in automatic mode:

1) Random automatic mode: As a default, the order in which your participants are assigned to the player positions and rooms is arbitrary (we actually apply some randomisation to ensure that participants aren't simply assigned to rooms in the order that they arrive).

Image showing the Mode setting in the lobby node with Automatic mode selected.

2) Automatic mode with preset criteria: If you wish to define rules for how participants are assigned to rooms, you can use the Matchmaking setting - this is a setting of the Automatic mode that ensures that Players are matched with other players according to specific criteria. For instance, you might want to create groups where a male participant is paired with a female participant, a conservative participant is matched with a liberal participant, or any other combination you wish to examine in your study.

In order to apply the matchmaking rules, select Automatic matchmaking mode in the Lobby node and tick the 'Enable Matchmaking' setting.

Image showing the Automatic Mode setting in the lobby node with the Enable Matchmaking checkbox selected

When you enable matchmaking, two new settings will appear: a Fixed Order setting and a Player Criteria setting. We'll explain the Player Criteria setting first.

The Player Criteria setting allows you to set up automatic matchmaking rules based on selected criteria. Participants who meet the criteria will join the same group of players and proceed to the multiplayer task together. The criteria operate by checking values saved in each participant's Store. During tasks or questionnaires, you can save information about participants to Fields in their individual Stores. You can then extract this information to use it later in the task, e.g. in the Player criteria settings. You can read more about using Store in our Store Guide.

As an example, you might wish to match players based on their political views. In your Experiment Tree, you can precede the multiplayer task with a questionnaire asking whether participants support a 'conservative' or 'liberal' party. You can save their answers to a Store Field called party. Then, in the Lobby node's matchmaking setting, you would add criteria for Player 1 to have the value 'conservative' in their Field 'party' and Player 2 to have the value 'liberal' in their Field 'party'. This way, the Lobby node will automatically match conservative and liberal players into one group and will repeat that matching for each group of players.

Screenshot of setting Player Criteria using the Store Field 'party' to pair conservative and liberal participants into rooms

The Fixed Order setting, when turned on, ensures that participants are always ordered according to the rules defined in the Player Criteria. In the example above, if Fixed Order was turned on, then Player 1 would always be conservative and Player 2 would always be liberal. If Fixed Order was turned off, then each room would always have one conservative player and one liberal player, but it would be random which one was Player 1 or Player 2.


Manual Mode

You can choose to match players into rooms manually. This might be handy when, for example, you want to run a multiplayer study with a moderator who should play in a specific player position within the room.

You can matchmake players manually by selecting the Manual matchmaking mode in the Lobby node. In this case, when participants enter the Lobby node they will wait for you, the researcher, to match them with other players and form rooms which will then progress onto the rest of the experiment.

Manual assignment happens in the matchmaking room which can be accessed using the URL provided in the Lobby node:

Screenshot of Lobby node settings. Manual mode is highlighted, and the matchmaking room URL at the top is circled in red
Warning

You can only test Manual assignment mode when you have participants in the Lobby. You therefore need to run the experiment, as opposed to previewing it, to see the manual Lobby node mode in action. During the preview, the URL leading to a matchmaking room will not appear.

Following the URL from the Lobby node, you will enter a matchmaking room, where you will see IDs of the players who are waiting in the Lobby. You can add the players to the current room by clicking on the 'Add' buttons next to their IDs. In the Manual assignment mode, player assignment happens in numerical order. This means that the first player manually added to the room will be assigned to the Player 1 position, the second - Player 2, the third - Player 3 etc.

Screenshot of the matchmaking room with an Add button next to each player in the Lobby and a Create button to create a room

Once you are happy with your matching, confirm it by clicking a 'Create' button. The player room you just created will automatically move onto the next node of your experiment. Repeat the process with other players until you form all the rooms.

Pro Tip

When running your experiment, you can open the experiment tree and click on the Lobby node - this will show you a URL on the top of the node which you can click on and follow to bring up the matchmaking room.

See a step-by-step example of manually assigning players to specific player positions in the Player Control - Worked Example section of the guide.


Rematching Players


When participants reach a Lobby node, they will wait there until they have been matched with enough other participants to create a complete room. Once they have been matched, they will all advance to the next node in the tree. Usually, this will be your multiplayer task, to ensure they all start it at the same time and don't need to wait for one another.

Participants enter the lobby individually and leave when assigned to a room with the right number of players

If you have only one Lobby node in your experiment tree, participant matching stays consistent, This means that participants remain in the same player rooms for any multiplayer tasks they encounter in the experiment.

However, if you wish to reshuffle your participants during the experiment, simply add another Lobby node(s) to your experiment tree - every time participants reach the Lobby node they will be removed from their existing player rooms, gathered all together, and then re-matched to the new player groups.

Pro Tip

Live Gate nodes are invaluable in experiments that involve rematching players midway through the study. Live Gate nodes let you dynamically control the progress of participants within the experiment, so you could wait for several groups of players to progress throughout the first part of the experiment and let them wait in the Live Gate node until you have a desired number of groups to rematch the players. For this purpose, use one Live Gate node before each of the Lobby nodes that you use for rematching players.


Step-by-step guide


To get started with the Multiplayer tools, follow our Step-By-Step Guide to build the Ultimatum Game, a classic multiplayer behavioural study.

You can find multiplayer task and experiment examples on our Multiplayer Samples page .


Player Control - Worked Example


Let's work through a scenario where you, the researcher, want to be one of the players in your 2-player Multiplayer experiment, and where you want to ensure that you are in control of the screen progression. Follow the steps below to set this up.


Step 1 - Enable Multiplayer

Firstly, create a new Task Builder 2 task, enter edit mode by clicking the Edit button in the top right corner, and go to the Settings tab. In the Settings, select the Multiplayer tab and tick the Enable Multiplayer box. Specify the number of players this task is designed for - in our example we are creating a 2-player game.

Image showing the Multiplayer tab in Task Builder 2. Enable Multiplayer is ticked and the number of players is set to 2

Step 2 - Create and allocate roles to players

In our example, we want to create a role that progresses the screen and then allocate this role to one player. To do that, create a new display with a new screen. On the screen, add an object with a screen advancing component, such as a Continue Button, and add a Multiplayer component to it. Set the Player setting on the Multiplayer Component to Player A.

Image showing a Continue Button with a Multiplayer component. In the Player setting, Player A is selected

Then, add the Advance - Multiplayer Player component to the Screen tab and, again, set the Player on this component to Player A. Read more about the Advance - Multiplayer Player component in the Controlling Flow part of the guide.

Image showing a screen component Advance Multiplayer Player with a player setting set to Player A.

Step 3 - Assign players to specific roles

Now, we want to make sure you are Player A who has the role of controlling the continue button.

In the Spreadsheet tab, you will notice columns for Player A and Player B. The number of columns depends on the number of Players you specify in the Multiplayer tab in your Settings. We are creating a 2-player task, therefore two columns will appear in our spreadsheet: one for Player A and one for Player B. We need to fill these columns with numbers that correspond to player positions, that is '1' for Player 1 and '2' for Player 2.

Let's put 1s in the Player A column - this means that the person who is playing in a Player 1 position will be allocated a role of Player A, who is in control of screen progression. Now we will need to make sure you will play in a Player 1 position.

Screenshot of the spreadsheet with Player A and Player B columns. Rows in the Player A column are filled with 1

Step 4 - Assign participants to specific player positions

Now we will assign you to the Player 1 position.

Player assignment happens in the Lobby node in the Experiment tree. As a default, in Automatic mode, when participants enter the room, the Lobby node randomly allocates them to be Player 1, Player 2, Player 3 etc. To ensure that you are Player 1 and not a random player, use Manual mode instead.

A URL will appear on the top of the Lobby node settings window. Click on the URL to go to the matchmaking room.

Screenshot of Lobby node settings. Manual mode is highlighted, and the matchmaking room URL at the top is circled in red

In Manual mode, player assignment happens in numerical order, therefore add yourself first - this will make you Player 1. Add the other player second - this will make them Player 2. Assign all the players to positions according to your protocol. Once you are happy with your player assignment, confirm it by clicking a 'Create' button.

Screenshot of the matchmaking room with an Add button next to each player in the Lobby and a Create button to create a room

Now when you run the study, Gorilla will recognise you as Player 1 and match this information with the '1' you have put in the Player A column of the multiplayer task spreadsheet. This way you will be playing a role of Player A who is in control of screen advancement. Gorilla will find '2' in the spreadsheet column for Player B, and will allocate a Player B role to Player 2.