Creating and adapting the game concept

As already described during the conceptualization of the main study, the prototype should contain a challenging and engaging game, while also allowing comparability to external studies in the field of latency research.

Our initial approach has been tending towards game concepts similar to classical Fitt’s Law Style tasks on moving targets, for example ‘Moorhuhn’ (https://www.moorhuhn.de/, l.a. 15.2.19), in which the player needs to click as many randomly spawned moving targets as possible within a given time. Classical ‘Moorhuhn’ targets come in three different sizes, which also represent associated difficulty boni to the score on hit.

Discussions showed, that directly duplicating this approach for the main study would lead to several problems:

• Moorhuhn targets strictly move along a horizontal axis. This would reduce external validity, since many games (like First-Person-Shooters) offer full freedom of movement.

• It would be really hard to replicate comparable conditions for randomly spawned targets of randomly chosen sizes, even when using seed and spawning based on a fixed timer

• The varying distribution of different target sizes also would make it very hard to calculate a comparable score throughout multiple play-throughs

Thus, we chose to change the game concept by multiple aspects:

• Game targets should be able to move along arbitrary directions

• There should be a fixed size distribution and order of the target objects

Both requirements perfectly fit on concepts of the video game classic “Asteroids” (e,g. http://www.freeasteroids.org/welcome/, l.a. 15.2.19), in which targets move freely over the screen and separate into smaller targets, when hit, until they vanish.

In the final concept, each round, the player would be provided the same amount of equally sized moving targets, which split into two smaller pieces on hit.

While conducting our prestudy, we came across some restrictions, which needed to be taken care while developing the main study prototype

• The participants seemed to “adapt” to a certain latency characteristics, which caused them to instantly fail on strongly differing latency levels

• Small stutters of the game engine PyGame affected the user experience most, also the evaluation through video was way too much effort

Also, the following aspects should be kept in mind while developing:

• In order to prevent “button mashing” (https://en.wiktionary.org/wiki/button_mashing, l.a. 15.2.19) and encourage aimed movements, we’ve decided to add a cooldown timer (visible through a progress bar below the mouse pointer)

The game prototype for the main study should contain the following aspects:

• Game Manager, including the following features:
• Controlling the experiment flow (e.g. training rounds, parametrization of different matches e.g.)
• Logging of mouse clicks, delayed mouse clicks, highscores and game stats
• Control the Game instance
• Game, including the following features
• Implementation of the behavior described above,
• Display for
  

  * Nickname Entry
  * Tutorial Screen
  * Training Game Round with no latency and no logging
  * Highscore Screen
  * SAM Screens
  * Fully customizable Study Game Round with customizable latency characteristics and no logging

  * EventQueue, LatencyGenerator and Random Number Generator based on Box Muller (Box, 1958)

Trying to prevent a repetition of the stuttering phenomena experienced using PyGame, we had a look at several lower-level Python-based application frameworks. We chose PyQt5 (https://wiki.python.org/moin/PyQt, l.a. 25.4.19), the python binding of the C++ based Qt-framework (https://www.qt.io/, l.a. 25.4.19), offering high efficiency and cross-platform capability.

As described in the conceptualization chapter, the setup should run smoothly on a Raspberry Pi3 with a fresh Raspbian Installation and PyQt 5 installed, connected to a consumer-level FullHD screen.

While developing the prototype, several problems have occcurred. The following paragraphs will elaborate on those problems and how we attempted to solve them.

After implementing a first test version of the Game Instance and running it on a Raspberry Pi 3 test setup, we experienced noticeable animation stutter, which has not been visible on our OSX and Windows based development machines. We have tried multiple approaches to diminish this stutter, e.g. rounding coordinate values on render, reducing screen resolution, testing different GL settings and testing the app in windowed mode. The best effect has been achieved by:

• Switching the Raspberry Pi OpenGL Settings to experimental True OpenGL Mode
• Increasing the GPU Memory Split to 256 MB
• and decreasing the overall screen resolution to 1280×720

This setting has allowed a smooth visual experience without noticeable stutter.

We have decided to test the system latency in a medium stage of development, in order to have enough time for adaptations. The test was conducted using a high speed camera, a prepared mouse, which lights up a LED on a physical contact close and a slightly modified game script changing the screen color.

It became evident, that the game prototype on raspberry pi comes with a comparatively high base system latency of around 142ms.

Trying to triangulate the source of the delay, we’ve followed multiple approaches:

• Searched for delays through time logs throughout the game script

• Verifying the reliability of the camera through an Arduino microcontroller triggering a LED in sync to the 240FPS-rate of the camera, which showed expected results and proved the reliability of our camera

• Measured latency of game script on several machines:
• Mid Level Windows Laptop: around 140 ms
• MacBook Air 13”, Early 2015: around 120 ms
• Created comparable sketches:
• Glut: around 80ms
• Qt: around 90ms
• Tried to trace the processing of the input event through a parallel GPIO Output to a LED on certain breakpoints in the code
• On Mouse Pressed
• On Delayed Event Triggered
• On Render Finished

The findings of our approaches pointed out, that we had left only two approaches:

• Reimplement the whole project in C/C++
• Try to adapt the system parametrization to system latency

Since the search for the latency source has taken a considerable amount of time and no team members are experienced with coding in C, the first approach has been considered unattainable, since the implementation would have required to be very quick and thus highly prone to errors.

• George EP Box. 1958. A note on the generation of random normal deviates. Ann. Math. Stat. 29 (1958), 610–611.