A Software Engineering Framework for Reusable Design of Personalized Serious Games for Health: Development Study

Abstract

Background: The use of serious games in health care is on the rise, as these games motivate treatment adherence, reduce treatment costs, and educate patients and families. However, current serious games fail to offer personalized interventions, ignoring the need to abandon the one-size-fits-all approach. Moreover, these games, with a primary objective other than pure entertainment, are costly and complex to develop and require the constant involvement of a multidisciplinary team. No standardized approach exists on how serious games can be personalized, as existing literature focuses on specific use cases and scenarios. The serious game development domain fails to consider any transfer of domain knowledge, which means this labor-intensive process must be repeated for each serious game.

Objective: We proposed a software engineering framework that aims to streamline the multidisciplinary design process of personalized serious games in health care and facilitates the reuse of domain knowledge and personalization algorithms. By focusing on the transfer of knowledge to new serious games by reusing components and personalization algorithms, the comparison and evaluation of different personalization strategies can be simplified and expedited. In doing so, the first steps are taken in advancing the state of the art of knowledge regarding personalized serious games in health care.

Methods: The proposed framework aimed to answer 3 questions that need to be asked when designing personalized serious games: Why is the game personalized? What parameters can be used for personalization? and How is the personalization achieved? The 3 involved stakeholders, namely, the domain expert, the (game) developer, and the software engineer, were each assigned a question and then assigned responsibilities regarding the design of the personalized serious game. The (game) developer was responsible for all the game-related components; the domain expert was in charge of the modeling of the domain knowledge using simple or complex concepts (eg, ontologies); and the software engineer managed the personalization algorithms or models integrated into the system. The framework acted as an intermediate step between game conceptualization and implementation; it was illustrated by developing and evaluating a proof of concept.

Results: The proof of concept, a serious game for shoulder rehabilitation, was evaluated using simulations of heart rate and game scores to assess how personalization was achieved and whether the framework responded as expected. The simulations indicated the value of both real-time and offline personalization. The proof of concept illustrated how the interaction between different components worked and how the framework was used to simplify the design process.

Conclusions: The proposed framework for personalized serious games in health care identifies the responsibilities of the involved stakeholders in the design process, using 3 key questions for personalization. The framework focuses on the transferability of knowledge and reusability of personalization algorithms to simplify the design process of personalized serious games.

Keywords: cocreation; domain knowledge; eHealth; framework; health care; personalization; serious game.

Figure 1

The Flow Model states that to enter the flow channel, that is, a state of total immersion and maximized focus and performance, the goal and related challenge should match the skill level of the user [46].

Figure 2

(A) A conceptual schematic visualization of the currently complex and redundant dependencies between stakeholders during the development of multiple personalized serious games. (B) Schematic visualization of decoupling these dependencies by implementing reusable components that can be used for multiple serious games, thereby removing the tedious and repetitive effort of the stakeholders.

Figure 3

The generic framework consists of 3 types of modules. The Knowledge Base module formalizes the knowledge of the domain expert. The game-specific modules are the responsibility of the (game) developer and contain the personalized parameters. The final module, the Independent Personalizer, is the responsibility of the software engineer, who implements the algorithms for personalization.

Figure 4

Using the Intel RealSense Camera and the Cubemos skeleton tracking (left), the arm movements of the user are tracked to control the game character (right).

Figure 5

The implementation of the proof of concept using the proposed framework indicates that 2 features have been identified, namely, heart rate and game score. The Knowledge Base contains the necessary expert knowledge and respective context parameters that are necessary to interpret these features. After the Interpreter has interpreted this information, using the Context Locator to fetch the context values, the Personalization Engine is responsible for the adaptation, using the implemented models. Finally, this is again translated to an action of the game, namely, speed.

Figure 6

An overview of the responsibilities of the involved stakeholders.

Figure 7

The first 10 games show a diverging score (top), which responds to a near-constant difficulty (bottom). The score of the user drops as of game 10, to which the system responds with a drop in difficulty. After game 14, the user achieves, on average, a constant score, which is, as expected, responded to by the system with a slow increase in difficulty.

Figure 8

The score of the user is, on average, constant during the first 13 games (above), to which the system responds with a slight increase in difficulty (below). After a brief drop in scores, the user’s score indicates an upward trend as of game 16. The system responds by significantly increasing the difficulty of the game as long as this upward scoring trend continues.

Figure 9

In the first 15 games, the user reaches, on average, a constant score (above), to which the system again responds by slowly increasing the difficulty (below). As of game 16, the score keeps dropping, showing a downward trend, to which the system responds by significantly lowering the difficulty.

Figure 10

For an, on average, constant score (above) and a constantly increasing heart rate (middle), the system responds differently for real-time personalization compared with offline personalization (below). If the system is updated after the game (offline personalization), the maximum threshold heart rate of 180 bpm is exceeded in game 27, of which the average heart rate is 182 bpm. The system thus starts decreasing the difficulty as of game 28. When the system is updated during the game (real-time personalization), the system already decreases the difficulty as of game 26, therefore achieving a much lower speed much faster. bpm: beats per minute.

Figure 11

This detailed overview of the heart rate of the user starting from game 26 (top) indicates that the system can reduce the difficulty of the game (bottom) much faster in the case of real-time adaptation as the maximum threshold of 180 is already exceeded in game 26. Because the average heart rate of a gaming session only exceeds 180 in game 27, a delay is introduced in the version using offline adaptation. Real-time adaptation, therefore, allows the system to respond much faster to critical values than when offline personalization is used.