Chapter 6
/
New Game
"[Play is] a critical activity necessary to achieve a healthy adulthood."
(Miller, 2014, p.163)
This chapter discusses the development of the rehabilitation game from its first realisation as an MVP through to the final iterations that were used for user testing. During this process we consulted with clinicians several times, which resulted in large changes to the gameplay and features (often marked by a version increment: v1.# - v2.0). This chapter concludes with testing the alpha version of the game with potential users to make final assessments on the effectiveness its design.
6.1 MVP (Minimum Viable Product)
Figure 6.1a - Tiddlywinks
Figure 6.1b - Tiddlywinks
Tiddlywinks v1.0
Tiddlywinks is a digitized version of block dominoes that allows players to use rehabilitative exercises to execute specific in-game actions. Gameplay was modelled loosely after Tiddly-Wink (see Appendix D, p. 221) due to its rigid ruleset.
Version 1.0 of the rehabilitation game was chosen to be a digital tabletop game for several reasons; the first of which was that it enabled high levels of connectivity and adaptability at the cost of meaningful interactions. No concept held all three criteria in equal portions, yet this one had the highest potential for satisfying two of the three.
The rules of Tiddly-Wink helped establish the MVP requirements for a playable domino game.
Another strength of this concept is its innate familiarity with the target audience. To be effective as a rehabilitation game, potential users must first be willing to give it a try. The digitization of a classic tabletop game caters to a broad audience. This is supported by the low learning threshold of dominoes.
The specific choice to use dominoes comes from the simplicity of the core interaction. Cards typically use four suits for every numeric value (and the inclusion of jokers in some games), whereas dominoes only requires the player to focus on one number at a time. Simplicity was integral for all elements of the game. Increasing the complexity of the game came down to tweaking the base rules: how many dominoes does each player start with? How many players are there? How big is the deck? Do you draw on a pass etc.
Domino games are social by nature. A patient may not always have access to people to play with therefore computer substitutes were necessary. Complicated artificial intelligence for non-human players was out of scope for this research. A computer player’s turn is broken down into a few simple steps.
Figure 6.2 - Decision Tree
6.1.1 Inclusion of Strength for Task Training (STT)
The first phase of Dr. Signal’s STT (2014, p. 47) involves priming: high exertion exercises that promote neural plasticity and prepare the patient for repetitive exercises. The relationship between priming and base repetitions is a physiotherapeutic equivalent of shuffling a set of dominoes before playing a game with them. Mapping these rehabilitative processes to their in-game equivalents may help maintain immersion.
A common concept in strength training is “fifteen reps to failure” (N. Signal, personal communication, 16 March 2016). This involves performing fifteen repetitions of a set exercise with an attached weight, ideally one that the patient would be unable to lift a sixteenth time. This weight is indicative of roughly 50-60% of the maximum a person can lift with that muscle group. For the user to experience proper strength training, they require external components such as weights or therabands. Thus, part of the training is out of the game’s control and there is an element of trust introduced that relies on user’s to be truthful in their input. Additional sensors could be included to prevent this, however such an addition was beyond the scope of this research.
Signal stated that there are approximately nine parameters clinicians can use to tweak exercises to enhance certain aspects (N. Signal, personal communication, 16 March 2016). Of these nine, she recommended we focus on excursion (distance), speed and accuracy, as they best match our proposed system of movement to gameplay.
Although the digital game was developed to use STT as its mode of rehabilitation, it was designed in such a way to enable response from a variety of input methods. This was to maximize the game’s versatility, rather than restrict its application to a singular style of physiotherapy. The following section discusses significant changes that happened to the game and the reasoning behind them.
Figure 6.3 - Calibration Concepts
Figure 6.4 - Representation of Exercise
6.2 Alpha
6.2.1 Tiddlywinks to 12-12 v1.0
The gradual increase of functionality moved the game away from Tiddlywinks to a general platform for block dominoes. Several important additions were made to account for users who are not familiar with dominoes or simply forget how to use the interface. The first was a help button that was always visible from the in-game UI. Clicking it toggled reminder text for what the player sees on-screen.
An integral addition was a prompt system that calculated all the legal moves a player can perform on their turn and highlighted them after a predetermined time. This functioned as a failsafe for players who did not understand the generic help text or needed assistance planning their turn. The significance of the timer was to keep help text off-screen until it became necessary, aligning with Gregor et al.’s point that the oversaturation of information can make it less digestible (2002, p. 154)
Additionally, upon loading the game for the first time (or later times if the option is reset), the player was asked if they wished to receive a tutorial on how to play. Selecting “Yes” prompted specific UI elements that told the player how to navigate the menus and start a game. Pressing “Play” loaded a tutorial level that dealt a predetermined hand to both the player and their computer opponent. During this level, the player was prompted to select tiles in a specific order which granted them the experience of beginning play, playing matching tiles, how to pass, and how to end a round. Showing the players all the typical manoeuvres of a game meant they might recognise them in future sessions. The development of this tutorial was in accordance with Ma et al.’s claim that users need to familiarise themselves with a system before it becomes too difficult (2007, p. 688).
In constructing the tutorial it became apparent that the ‘options’ menu was too dense and risked overwhelming new users with too many choices. To counter this, only the functionality required to play a basic game against computer opponents was kept. It was this version of the game that was used for preliminary user testing.
FIgure 6.5 - Main Menu Concepts
Figure 6.6 - Options Concepts
Figure 6.7 - UI Layout Concepts
Figure 6.8 - Tutorial Plan
Figure 6.9 - Wireframe
6.2.2 Preliminary Testing
To maximise the effectiveness of user testing with survivors of stroke, preliminary user tests were conducted with colleagues who had not experienced the game before. Inclusion criteria was kept simple. The user testers must:
· Not have experienced a stroke before.
· Not have any significant cognitive deficit.
· Not have experienced the game before in any way.
The purpose of these tests was to ensure that the basic gameplay was functional and easy to understand, which was reflected by the inclusion criteria. Without stroke-related impairments, the testers were able to provide feedback based on the raw gameplay experience.
Six user testers were asked to load the application, play through the tutorial, and play a basic round of the game. To keep responses simple and to the point, a questionnaire using a five-point Likert scale and short written answers was provided (for the full questionnaire and a more detailed summary of the written results, see Appendix C, p. 209).
The strengths of the game that were made apparent were:
· The game was easy to learn.
· The interface was easy to understand.
· It was clear when players could and could not play.
· The use of language was relatable.
· Animations were smooth and enjoyable.
· Player icons were popular.
Of these strengths, the interface’s ease of use and the players’ ability to learn the game is highly subjective and would need to be properly tested with survivors of stroke. “Relatable” language is also subjective, however this prompted the use of less clinical terminology. More animations and icons were developed in response to their popularity.
Elements that needed work were as follows:
· The win/loss conditions were unclear.
· The scoring was unclear.
· The sense of competition was not as evident as it could be.
· Main menu scene was too sparse and the ‘options’ menu too cluttered.
· The tutorial information was overwhelming.
· Pacing was too slow.
The users reported that the tutorial felt overwhelming, yet some elements were still unexplained. This highlighted that the problem was not a matter of the quantity of information being presented, but how and when it was being presented. The primary purpose of the player is to play a game, therefore any instruction referring to elements of the main menu, other than the ‘play’ button, were removed. The tutorial was extended to include the score screen to explain scoring mechanics once the player had already learned how to play a round.
6.2.3 12-12 v2.0 to v3.0
A return visit from Dr. Signal prompted an overhaul of the game in both code and aesthetic. One of the core ideas behind the developments of this version was to embed the criteria for success into as many elements as possible in subtle but meaningful ways.
Adaptability: The ‘options’ menu needed robust error handling. The game needed to be playable regardless of the settings the player adjusted e.g. trying to start a game with zero opponents and defaulting to one computer opponent. The amount of user icons was expanded to allow more personalisation.
Connectivity: Time constraints meant we were unable to explore the effect of including online networking or player profiles, leaving these aspects of connectivity unexplored. To counter this, local multiplayer was ensured to be fully functional. Adding in features like concealing player hands until the ‘ready’ button is pressed and clear variation in the profile pictures allowed the game to be played by up to four separate people, all using the same device.
Meaningful Interactions: Embedding meaning into the interactions of the menu was more difficult than the other criteria. Our inability to test on users at this point in the research meant we could not test the proposed methods of interaction.
Menu navigation via device input was removed as it preceded gameplay (therefore calibration) and would pose a significant barrier to those who are not used to the connection between the device and the game, namely first time users. Instead, focus was placed on making the behaviour of the menu as logical as possible; e.g. rather than the hand size being depicted by a number, the player can see three to six tiles in a row that reflect how many remain in their hand.
6.2.4 Integrating the Device
The use of a special sensor had to be accounted for in the gameplay. If the sensor was not available, a ‘simulate’ button became active. Whilst not an ideal substitute, this does act as a failsafe, albeit one that relies on the player’s honesty.
Initially we tried to use Inertial Measurement Units (IMUs) to directly replicate the motion in-game but interpreting the devices’ data proved more difficult than anticipated and the results were unfavourable. The calibration scene was implemented in an attempt to counter this, which integrated naturally into the priming phase of the exercises.
An alternative solution was to use gesture recognition and teach the device which exercises to be looking for. This would allow each clinician to build a library of movements that set the standard for what their patients should be aiming to meet. Such a method removes the need for repeated calibration, allowing players to get to the primary gameplay faster. Tying the device’s calibration to the tutorial is an organic way of getting the user to set everything up before they dive into the core experience.
Figure 6.10 - Menu and Target Development
Figure 6.11 - Options Development
Figure 6.12 - Tabletop Development
Figure 6.13 - Button and Tile Development
Figure 6.14 - Scoring Development
6.3 User Testing
This section discusses the testing of the complete system (William Duncan’s hardware and the digital game), the discoveries made and their subsequent iterations.
Prof. Taylor explained that within a therapeutic context it is expected to take roughly three months of training to make any noticeable difference to the patient’s condition. This meant we could not prove that our solution would be able to make any effective change to a user’s mobility or physical health. Instead, we focused on the usability of the system.
Recruitment began with contacting local stroke clubs and presenting our research. From these presentations we acquired the contact details of potential participants. These participants were contacted via telephone and those who met our inclusion criteria were given an over-the-phone interview. According to Dr. Signal, neural plasticity can happen months after an incident, meaning we were not restricted to survivors of recent strokes.
Inclusion Criteria:
· Aged > 18.
· Had experienced a disabling stroke.
· Has or has experienced hemiplegia or hemiparesis following stroke.
· Can walk 10m without standby assistance.
Exclusion Criteria:
· Significant cognitive deficit.
· Unable to follow a 1 step verbal command.
· Unable to give informed consent.
· Medically unsuitable in the opinion of the screening physiotherapist, G.P or medical specialist.
· Experiencing excessive joint pain.
· Suffering other conditions that could impact results (eg. substance abuse, significant mental illness such as major depression).
(For our phone interview questions, see Appendix document C2)
The purpose of the inclusion and exclusion criteria, aside from establishing the participants’ experiences with stroke, was to ensure they would be capable of safely interacting with our system without the need for clinical supervision. Our system was designed for home-based rehabilitation, therefore is unable to depend on clinical aid to function. These criteria also ensured our participants would have enough communicative ability to articulate their thoughts regarding the system clearly.
Our recruitment process resulted in several participants donating their time to our study. Participants were given aliases to protect their identities.
6.3.1 The Players
‘Alex’ survived a cerebellar stroke that affected the right side of her body. She was originally wheelchair-bound but recovered her ability to walk through rehabilitation. Her balance remains affected and she occasionally requires a walking stick. Alex lives independently and is an active member in the local stroke club.
‘Bernie’s stroke afflicted him with left hemiplegia and affected cognitive capabilities. Bernie’s communicative abilities were limited and he had a caregiver who occasionally spoke on his behalf. Despite retaining his ability to walk (with the aid of a quad cane), Bernie’s hemiplegia severely limits his gait and he experiences falls regularly. This necessitated his test to be conducted from a seated position.
(Bernie was not part of the original recruitment process. For more information regarding Bernie as a user tester, see Appendix C)
‘Charlie’ was the most physically able of our participants. Despite experiencing two strokes in the past decade, Charlie only has minor right hemiparesis and is fully capable of living independently. She has the fastest gait of our participants with only minor balance and coordination issues. However, Charlie’s short-term memory was affected and she can be very forgetful at times. Charlie often finds technology hard to use because she forgets how it works.
‘Dannie’ had multiple sclerosis prior to his stroke, which worsened its effects. At the beginning of his recovery process he was completely bed-ridden. Dannie suffered left hemiplegia which locked up the left side of his body but over time he was able to recover some of the lost functionality. He lives with his partner who cares for him. Dannie is capable of moving about independently, albeit with a walking aid. He has no fine motor control over his left foot and arm.
6.3.2 Testing Protocol
With permission from our participants, we visited them in their homes to conduct the tests in a safe environment. Tests began with the observation of usability heuristics. Media-specific elements included the readability and articulation of text-based information, the players’ comprehension of the visuals and the players’ comprehension of the game’s rules. The use of think aloud protocol helped us assess these heuristics. During this process we took handwritten notes and non-identifying video of our participants for revision purposes.
The lack of functioning sensors in the device was addressed through the implementation of Kelley’s ‘OZ paradigm’ (1984). This method gives experimental participants the impression that they are interacting with the system as it is desired to function, thus giving genuine reactions. In actuality, the researcher is surreptitiously intercepting communication between the participant and system, providing appropriate responses (ibid., p. 27). For our tests we used an application on a cell phone to wirelessly transmit to the tablet each time the player performed a correct exercise.
The exercise requirements of our participants were fifteen leg raises (hip abduction) for the priming phase. The tutorial phase involved playing six dominoes, each requiring the player to perform five side-steps. Participants were then required to play a standard game, running through a further fifteen leg raises and twenty to thirty leg raises over the course of the following round. As this round was against a randomised computer opponent, the amount of playable dominoes fluctuated from four to six between participants. Each player completed these steps at different rates, taking between twenty-five and thirty-five minutes.
We conducted a semi-structured interview with our participants after the observation session. The purpose of these interviews was to give them the opportunity to comment on anything they had missed with think aloud protocol. Questions were kept simple to avoid leading our users’ responses. The interview was recorded using a simple microphone to avoid participants becoming camera shy. Our participants were free to speak in as much detail as they chose. The interview was designed to take fifteen minutes to complete, but some participants spoke for as long as thirty-five minutes.
(For interview questions, see Appendix document C3)
Figure 6.15 - User Testing Setup Diagram
6.3.3 Test 1
Testing was conducted according to the protocol above. Each test involved the participant putting on William Duncan’s smart shoe, completing the tutorial of 12-12 and then playing through a standard game.
6.3.4 Feedback 1
It became apparent very quickly that no participant was confident enough to play while holding the tablet. This meant the tablet had to be placed on a table and any exercise that required stepping needed to be repeated back and forth. Despite being a minor issue, this demanded very clear setup instructions for the beginning phase of the game.
Alex stressed the importance of the affordability of the system. She explained with an example from her stroke club where members were offered discounted gym memberships but had to discontinue their membership once the promotion expired because they could not afford the standard rate.
Both Alex and Charlie expressed excitement about interacting with the system. They liked the “you can do it” mentality of the game and how it encouraged them to move out of their comfort zone. A large contributor of their enthusiasm came from the attention the system granted them. “We need to be pushed to get the brain to do these things,” stated Charlie, “this makes you feel like a normal person.”
The main difficulty that was experienced by all users was what to do in each phase of play. Every participant needed to be reminded which exercise to perform and when. For the majority of play, each user displayed uncertainty on what to do next until the prompt text informed them. Despite this prompting, it was common for the participants to request clarification on how to perform the exercises correctly.
Elements of the UI were unclear as well. Most participants did not recognise the buttons to be interactive right away and had to be prompted to press them. This problem occurred several times during play, indicating the style of the buttons was too subtle. Similarly, several participants did not realise the dominoes were interactive via tapping and needed to be shown.
Both Alex and Dannie suggested a less intense version of the game for less able players. Shorter game sessions with less dialogue would make the game more accessible for people with less motor and cognitive functionality. This wouldn’t need to resemble a complete block dominoes game proposed Alex, “even if [players] don’t remember everything, it’s the novelty of pressing a button and seeing something happen.” The game’s complexity could gradually be built up, mapped to each player’s physical and cognitive development.
6.3.5 Test 2
Our second tests were conducted in an identical manner to the first ones with a few exceptions. Bernie was excluded from this round because the changes made to the game’s build were not significant enough to account for their cognitive deficit. Participants were encouraged to raise the tablet to a more appropriate height by using books as a makeshift stand. Lastly, the interview questions were reduced to avoid redundant information. These reduced interviews took between ten to twenty minutes to complete, depending on the participant.
(For the second test interview questions, see Appendix document C4)
6.3.6 Feedback 2
Elevating the tablet to an appropriate height using books removed the need for participants to lean over the tablet. We received no reports of pain or discomfort after the session was completed.
All participants requested a simple breakdown of how to perform each exercise properly as part of the introductory gameplay. This would remind users who do not have access to clinicians how to correctly perform their exercises. It also coincided well with Alex and Dannie’s suggestion that a reduced version of the game be available for people whose stroke is more recent.
The more each participant played, the greater understanding they exhibited of how the game worked. During the post-tutorial game, the participants would wait until the prompt came up before they would make a move. Before the end of the game, each participant had figured out the gameplay well enough to make decisions before the prompt was activated. When asked about the difficulties of learning the game, Alex responded that it was not disheartening to make the wrong decisions initially and “once you get the hang of it, it could grip you.”
Both Alex and Charlie emphasised the significance of keeping the pacing of the game slow. It wasn’t enough just to let the player move at their own pace, it had to be acknowledged by the game that they were able to do so. This was particularly important for reading instructions; “you’ve got to take your time to read it. You can’t rush it.”
All participants became confused as to which exercise to perform at least once. It is possible an introductory panel that explains the change in exercises at the end of the priming phase would remedy this. Alternatively, the addition of animated visual prompts when a player selects a tile could suffice.
Time constraints on testing meant we were unable to test the multiplayer capabilities of the game, however, each participant expressed interest in being able to play the game with others. Dannie made the point that for competitive play to be enjoyable, their opponents would have to be of a similar skillset to them. Being a beginner, they would need to play with other beginners or they might become frustrated. Charlie also enjoyed that she did not need people around to play, claiming “I can do it for me,” as it allowed her to test their personal capabilities.
6.4 Results Analysis
The findings of these testing sessions suggest that 12-12 provides a stimulating, yet demanding experience for older adults recovering from stroke. The enthusiasm our participants displayed supports the claims of Gerling et al. (2010, p. 69) (2011), Ijsselsteijn et al. (2007, p. 18) and Jung et al. (2009) that older adults can be positively receptive of new technology. Even Dannie, who was initially sceptical, became more engaged as his understanding of the system grew. He reported the game to be both cognitively and physically stimulating, commenting how he was “starting to break out a sweat” by the end of his second game.
Conducting user testing in the homes of our participants proved how minimal the requirements were to set up the system. Each participant was able to find a comfortable surface to play from and used simple objects like books to raise the tablet to the appropriate height. The portability of the tablet enabled this type of setup, reinforcing the accessibility of the system within a home environment. The only object specifically designed for rehabilitation was the shoe-based controller.
A large portion of user feedback was directed at the system’s usability. To reach the deeper qualities of a system, such as adaptability or connectivity, one must understand it at a surface level. It did not matter if 12-12 promoted local multiplayer with friends and family if players did not understand how to start a game. Ijsselsteijn et al. (2007, p.18) and Nap et al. (2009, p. 248) made it clear that the system would need to be simple in order to be usable, but even these basic tests showed our implementation of a ‘simple’ game system was in need of further development.
Participant responses also made it clear that system feedback needed to be more than just encouragement. The game had to let users know that if they required a break, they would not be disappointing anyone or “failing” at the game. Two of our participants claimed such reassurance would boost their confidence. This is reflective of the work of Lee et al. (2012, p.445) and Mathwick and Rigdon (2004, p. 325), who proposed that greater perceived control over a system (in this case, pacing) tends to make users react more positively to it.
Each participant’s proposition of an adapted system for less able survivors of stroke verified adaptability as a criterion for success. Feedback suggested that system adaptability would be the strongest contributor towards accessibility. Although each participant acknowledged the connective potential for constructive competitive play, it was comparatively less important. Similarly, meaningful interactions were initially less important based on participants’ comments that it didn’t matter how they were achieving it; there was a simple novelty in seeing the game’s response to their movement.
In every test our intervention became necessary during the early phases of play, generally to explain a specific aspect of interaction. It is possible to make the UI more explicit by using multiple avenues of information (such as text, animated imagery and sound effects), yet our participants seemed more comfortable with asking us questions directly. The more they played with the game, the less help they needed. This behaviour is indicative of how the system is to be used in conjunction with clinical rehabilitation. Clinician input is still necessary for the initial setup of the system (prescription of exercises, sole weight, repetitions etc.) and its maintenance (adjustment of exercises, weight and repetitions). As the user learns the system, the clinician is needed less and less. This knowledge means a clinician-specific interface is necessary for the system’s integration into a clinical environment.
Lastly, the aesthetic of the game yielded no complaints from participants. They reported it to be vibrant and the text was easy to read. This aligned with the works of Gerling et al. (2011), Gregor et al. (2002, p. 151), Ijsselsteijn et al. (2007, p. 18), Kopacz (2004, p. 212) and Martin et al. (2014, p. 104), which informed most of the design decisions regarding the game’s interface.
FIgure 6.16 - Clinical Interface (Speculative)