Gorilla
Support Home Binding Guide

Binding Guide (Task Builder 2 & Game Builder)

  • Overview
  • Binding To The Spreadsheet
  • Binding To Manipulations
  • Binding To The Store
  • Binding To The Network Store

Overview


When building tasks, many configuration settings can be set directly. Whether it's the text of an instructions screen or the time limit for a screen, you can simply set the value you want in the tools:

Screenshot of the Screen tab with a Time Limit component set directly to 5000ms

In the case above, the screen will always have a time limit of five seconds. But this isn't always what we want - we might want different trials to have different time limits. Or we might want to have two experimental conditions with different time limits. Or we might have a task where the time limit changes dynamically depending on the participant's performance. We know we want a time limit, but we want to specify it somewhere else.

Instead of entering a value directly, we can instead dynamically link this field to another source of data - for example, a column in the spreadsheet, or an experimental manipulation. In Gorilla, we call this binding - we bind the field to a data source that allows it to be defined elsewhere. You can bind any configuration setting that has the little link icon ( ).


Info

Looking for Task Builder 1?

These documents refer to the new generation of Gorilla tools (Task Builder 2 and Game Builder).

For guidance on how to source the content of Zones in the original tools, see our Task Builder 1 How-To Guide: What is Zone Source?

Spreadsheet


The most common use case for binding is using the spreadsheet. In both Task Builder 2 and Game Builder, the spreadsheet defines which displays or scenes the participant will see, and in what order - it effectively defines the protocol for the task. For each row in your spreadsheet, the task will perform the display or scene defined for that row:

Schematic of the Display column in the spreadsheet, with arrows pointing from each row to the corresponding named display

A lot of the time, you'll want to have lots of trials, but have the stimulus be different for each one. You achieve this by binding your stimulus field to the spreadsheet, so that on each trial, it takes its value from a particular spreadsheet column:

Schematic of the spreadsheet's Stimulus column with arrows from each row to the Stimulus screen on the corresponding trial

To do this, click the binding icon next to the setting you want to bind, and either choose an existing spreadsheet column or create a new one:

You can now upload your stimuli and add them to your spreadsheet. If you go back to your trial and open the Debug tab, you can select a spreadsheet row to preview so that you can check that your bindings are working:

Info

Looking for Task Builder 1?

These documents refer to the new generation of Gorilla tools (Task Builder 2 and Game Builder).

For guidance on how to use the spreadsheet in the original tools, see our Task Builder 1 How-To Guide: How Does the Spreadsheet Work?

Manipulations


Manipulations are settings that you can control at the experimental level. Rather than have settings that change trial-by-trial, this allows you to have settings which you can configure differently for different experimental conditions. To give a simple example for a memory task, you might want to have all your participants do the same task, but have half of them do the task with a longer recall time and half with a shorter recall time:

Schematic showing a between-participants recall time condition implemented as a Manipulation in the Experiment Tree

To do this, click the binding icon next to the setting you want to bind, and either choose an existing manipulation or create a new one. When you preview your task, you can now set the value for that manipulation to help you test it:

When you add your task to an experiment, you can now configure manipulations separately for each instance of the task:

Info

Looking for Task Builder 1?

These documents refer to the new generation of Gorilla tools (Task Builder 2 and Game Builder).

For guidance on how to use manipulations in the original tools, see our Task Builder 1 How-To Guide: Manipulations.

Store


Each participant has their own unique Store - data that belongs to them and stays with them for the duration of the experiment. You can think of it as a little backpack or suitcase that each participant carries with them, and you can put values in there and then retrieve them again later. In the first generation of tools, this was referred to as Embedded Data - we've changed the name to Store because we think it's a better term, but it fulfils the same function.

The simplest use-case for the Store is when you want to save a participant's response and then use it later in the task. Note that this is separate from recording responses for your actual experimental data that you download once your participants have finished - participant responses are always recorded in your downloaded data; the Store is purely when you also want to be able to use a particular response later in the task.

For example, imagine a memory task where the participant is asked to specify an animal at the start of the task, and then recall it at the end. We want to check if the participant's recalled response at the end of the task matches their initial response at the start - i.e., whether they recall their response accurately. You would save their initial response to the Store at the start, perform the rest of the task, ask them to enter the animal again at the end, and compare their response to the one from the Store to establish whether they were correct:

Schematic of a task setup where the participant's recall is compared to their earlier stored response

To do this, you first need to tag your response, and then use the Save Response screen component to save the response to the Store. On the recall screen, you can now bind the Correct Answer field of your Scorer component to the same field in the Store:

Data in the Store is global by default, and so any values that your task writes to the Store will also be available in future tasks, as well as in the experiment tree. The most common use-case of this is to record a response in a task, and then use that response to branch the participant in the experiment tree.

For example, imagine an experiment which first asks participants whether they prefer dogs or cats as a pet, and then directs them to a different task depending on their response - so dog people get one task and cat people get another. In Gorilla, we start with a questionnaire which asks the initial dog or cat question, and we then save this to the Store under the key pet. By the end of the questionnaire, all participants should have one value called pet in their Store, which will either be cat or dog. The next node is a branch node, which looks up the value of pet in the participant's Store, and directs them down the appropriate branch:

Schematic of an experiment branching participants to a Dog Task or Cat Task depending on their pet value saved in the Store
Info

Looking for Task Builder 1?

These documents refer to the new generation of Gorilla tools (Task Builder 2 and Game Builder).

For guidance on how to use embedded data in the original tools, see our Task Builder 1 Embedded Data Walkthrough.

Network Store


The The Network Store is only used in Multiplayer tasks. It is similar to the Store, except that instead of each player having their own unique Store, the Network Store is a single store that is shared and synchronised between all players. If Player A writes a value to the Network Store, then it will also be updated for Player B.

This is useful for sharing state between players. For example, if you wanted to capture a response from Player A and display it to Player B, you would have Player A write the response to the Network Store, and then bind the text display for Player B to the same field:

/network store

For more about multiplayer, read the overview guide for an introduction, and then go through our step-by-step guide to build a multiplayer task for yourself.

Info

Looking for Task Builder 1?

These documents refer to the new generation of Gorilla tools (Task Builder 2 and Game Builder).

For guidance on how to use embedded data in the original tools, see our Task Builder 1 Embedded Data Walkthrough.