Tagged as: blog,
Group: C
This article describes all aspects concerning the design of the study prototype.
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:
Thus, we chose to change the game concept by multiple aspects:
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
Also, the following aspects should be kept in mind while developing:
The game prototype for the main study should contain the following aspects:
* 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:
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:
The findings of our approaches pointed out, that we had left only two approaches:
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.