Some kind of software is needed for conducting a prestudy with the button. To make it more fun for our participants, the decision was made to code a simple game. It needs to fulfill the following requirements:

• It needs to be compatible with our button
• Should be playable on Linux
• Easy to understand, fast to learn

For the game concept, the Chromium Dinosaur game (https://www.blog.google/products/chrome/chrome-dino/) was selected as suitable for conducting simple tasks. But since additional functionality is needed, the decision was made to recode the game.

Python was chosen for the programming language. To simplify the coding of the game, the library pygame (https://www.pygame.org/) was selected.

In contrast to the original game, which only fills up a tiny portion of the screen, the new version runs as a fullscreen application. The goal was to make it easier to play for the participants, as everything is visible much better.

Game Elements:

The game consists of the following game elements:

• The player: A dino sprite fixed on the x-axis on the screen. When the corresponding button is pressed and the dinosaur is currently standing on the ground, it plays a jumping animation.
• The ground: A texture scrolling from right to left that gets reset back to its starting position before it leaves the screen. This causes it to appear as an infinite plain.
• The obstacles: Game sprites that are spawned outside of the visible portion of the screen. They move from right to left at the same speed as the ground and get despawned when their x-coordinate is < 0. On each frame, a collision detection with the player sprite is made. If they overlap, it is a game over for the player.
• A status bar on top of the screen: Displaying the current score, the number of the current run and the permutation of latency and latency variance (see below).

Test Setup:

An additional class containing all constants for the game was written. Like that, making changes is easy. Two dictionaries were created, one for all possible values of latencies, and one for latency variances.

LATENCIES = {

      "NO_LATENCY": 0,   # ms
      "SMALL_LATENCY": 20,  # ms
      "MEDIUM_LATENCY": 50,  # ms
      "HIGH_LATENCY": 100  # ms
  }

VARIANCES = {

      "NO_VARIANCE": 0,  # ms
      "SMALL_VARIANCE": 20,  # ms
      "MEDIUM_VARIANCE": 50,  # ms
      "HIGH_VARIANCE": 100  # ms
  }

Out of these two dictionaries, each containing four entries, a new list with all 16 possible permutations is created. Each of these 16 corresponds to one task/run the test subject is confronted with.

To make them distinguishable for the test operators, each permutation got an unique ID (“AA”, “AB”, “AC”, “AD”, “BA”, …, ”DD”). The first letter of the ID stands for the set latency (A: No latency, …, D: High latency), the second letter for the set latency variance. Since the test subjects do not know what these IDs mean, the integrity of the experiment is not endangered.

Each permutation in the code also comes with an unique seed. The seed is handed to the random generator at the beginning of each run. When deciding where to spawn new obstacles, the random generator can always produce comprehensible new coordinates. This means that a player never experiences the same level twice, but each new player gets the same level setup for a specific permutation (e.g. test subject one and test subject two get the same level setup for permutation “BD”, but the level setup for the permutations “BD” and “BC” is different). This was made to make the same runs of different players easier to compare when looking at the data.

The results of each run of all test subjects were logged to csv files. The saved values and two example rows can be seen here:

The game was tested with real subjects for the first time during the pre-prestudy. This gave a lot of insight on what could be improved for the prestudy:

• The collision box of an obstacle was slightly shrunk to create a more realistic collision detection and prevent frustration for the players ”But I was sure I could make the jump…”
• Minimum and maximum distances between two obstacles were defined. This makes sure that jumps are possible, but also that there are no huge gaps between two obstacles.

Hardware:

• The game was played on the Acer Aspire V3- 771G laptop running the newest stable version of the Linux Mint operating system installed on a SSD.
• The laptop was used by the test operator. An additional monitor was connected to the laptop for the test subject.
• Before the prestudy, the performance of the game was measured and it was made sure that the laptop was able to run the game at a steady 60fps.