Dynamic Mood in Games Using Parametric Input

(1)

Dynamic Mood in Games Using Parametric Input

Philip Stenmark

Computer Game Programming, bachelor's level

2020

(2)

Abstract

In the context of video games, a portrayed mood can bring forward emotion and make a scene more alive. With the use of dynamic mood, the look and feel of the game may change provided dynamic events, as dictated by player inputs and various sets of conditions. This thesis aims to describe and present a range of techniques that are subject of affecting the in-game mood, as implemented into an original development project. By using select design patterns, carefully authored parameters and intuitive areas of implementation, the mood and atmosphere of the game experience can be altered dynamically in meaningful ways.

Sammanfattning

Ur ett datorspelsperpektiv så kan en viss stämning väcka känslor och få en miljö att kännas mer levande. Med dynamisk stämning så menas att spelets utseende och känsla kan förändras med hjälp av dynamiska händelser, formade efter in- data från spelaren och olika uppsättningar av villkor. Detta dokument har för avsikt att presentera en rad tekniker som kan användas för att påverka ett spels stämning på ett dynamiskt och betydelsefullt sätt. Genom att välja rätt designmönster, noggrant formulera parametrar samt utforska intuitiva utveck- lingsområden så demonstreras detta inför ett verkligt spelprojekt.

(3)

1. Introduction

The concept of mood and atmosphere may be considered an important element in the context of video game making. A certain mood can make scenes more alive, invoke profound player reactions and conduct the basis for an emotional experience [4]. Through the combination of imagery and sound, video games can induce emotional immersion in a way that is very applicable to the gaming experience. The lack of mood may however result in the player becoming inat- tentive to the experience and letting their mind stay at higher level thoughts, thus getting less immersed.

With the use of dynamic mood in a game, the mood may change depending on external factors, custom conditions or in-game events. This may let the player feel even more immersed due to the mood reflecting on their own actions and conscious choices.

This thesis aims to describe and suggest some of the ways dynamic mood may be implemented into an original development project. Through a central mood system, various aspects of the game can respond and react to dictated mood changes. By focusing on providing a set of tools that allow straightforward customization and application of in-game effects, the development team can easily integrate the implementation into the gameplay flow.

1.1 Mindforce Game Lab

Mindforce Game Lab is a company that has set out to create meaningful games which nudge people with medical conditions into healthier habits [3]. This as an effect to the evidence of the past years where the use of games has increasingly been proven to be useful to improve health [6]. In their first project Rim Rift, Mindforce Game Lab seeks an experience for players who need help to inscribe the aspects of their daily routine, e.g. medication adherence, sleep routine and meals. Through various daily in-game activities, the player finds reason to return to the game, which further ensures a routine and creates a habit loop.

(5)

(a) Home level and progression screen fea-

turing various routine stations. (b) Medication scan completion screen fea- turing the playable character Fig.

Figure 1.1: Rim Rift work-in-progress screen captures.

1.2 Rim Rift

Rim Rift¹presents a magical mobile world in which the player is given 100 days of content to assist their journey towards healthier habits. The player gets to interact and control the creative and caring character known as Fig. The player is set to build a home that contains various routine stations based on real- world habits. Each day, the player can perform an augmented reality scan on a sticker placed their physical medication container. This gains access to a new daily puzzle which lets Fig collect more resources for expanding the home base.

While adventuring together, the player gets to build an emotional relationship with Fig through interactions, story and dialogue. As a team, the player may find a way to withhold a daily routine to assist their medical condition.

1The Rim Rift name is not final and is subject to change.

(6)

1.3 Goal

In order to better meet and motivate their users on their journey, Mindforce Game Lab would like to explore the changing of mood in the Rim Rift game experience through various in-game effects. A set list of goals is proposed to fulfill this vision:

• Implement a central system that is able to listen for mood changes, as dictated by in-game events, player inputs or other external sources. This is the main entry point for interactions with various gameplay components.

• Explore and implement techniques on a week-by-week basis that are considered subject of affecting the in-game mood. The techniques used may involve multimedia effects, psychological principles and experimental elements based on affective science. In-game weather visuals, atmospheric colors, subconscious motifs and soundscapes may all be subject of affecting the in-game mood.

• Design everything with usability in mind. Every implementation is viewed as a tool for the Mindforce Game Lab design and art team to use. As such, an adequate parameterization of the mood-altering techniques is favored to allow discreet interfacing with other gameplay systems and artistic user controls.

1.4 Tool Design

A tool used for assisting game creation should be easy to use. A game designer, artist or any non-programmer should find the tool comprehensible, without re- quiring any additional knowledge. As such, the parameterization and interfacing should be designed with ease of use in mind. One should not overexpose nor underexpose the tool user with too many nor too few parameters respectively.

By accepting feedback and acquiring the tool users’ needs, a tool with the right set of controls can be created.

1.5 Project Structure

This section presents the general project structure used in the Rim Rift project.

Some key concepts are used in order to enable high-level game design and flow to be conveniently configured. The game is built using the Unity cross-platform game engine [9].

1.5.1 Modules

All major building blocks of Rim Rift are based around a concept of modules.

Modules are placed in the root scene’s top level for every game scene. A few

(7)

different module categories are available, each inheriting from the Module base class. The use of module concepts allows for explicit ordered control over creation, execution and destruction of objects.

1. Main is the top level entry point of the application.

2. Managers are the second level of the application (e.g. menu manager, level manager).

3. Controllers are the third level of the application. For example, the level manager may inherit a character controller and an enemy controller.

4. Factories are globally available singletons that produces a copy of an object by request (e.g. explosion factory).

5. Systems are globally available singletons that handles a certain confined aspect of the application (e.g. music system, save system).

1.5.2 Gameplay Node Graph

A node graph is used to script high-level gameplay elements into the game. The node graph used is based on xNode [7]. The gameplay node graph may dictate text dialogs, character navigation and level interactions. A game designer may construct a graph that can handle outcomes of any action made in a select level.

The graph allows to configure and set various properties within modules through exposed controls. As such, no implicit gameplay flow control is expected to exist within systems, controllers or managers.

(8)

2. Design and Implementation

The following sections present the approach used in the project. Due to the nature of the project, many different areas are considered in terms of implementation detail. Note that the areas described may not necessarily be related directly to each other, however, they are all considered a subject of affecting the in-game mood.

2.1 Mood System

The central hub used to enable dynamic mood is the mood system – a system module that accepts inputs and exposes hooks for other modules to connect to.

One may consider the mood system to be the core of project since it controls all other subsequent features. The system receives inputs from the the gameplay node graph (as described in section 1.5.2) through a simple interface. This means that the game designer and other gameplay authors are fully in charge of what actions may lead to changes in mood. Note that the exposed gameplay graph controls can be arbitrarily advanced, thus making the prerequisites to change mood feature depth and complexity.

In order to simplify the ranges of mood available, three distinct categories are constituted; positive, neutral and negative. Each category will result in different look and feel of the game upon selection. The reason not to use a wider range of selections is the strive to expose a set of controls that can be easily operated (see 1.4).

2.1.1 Changing Mood

Once setting the mood type in the node graph, a callback function OnMood- Changed(MoodType) is triggered. Any other module listening to this event is notified and may then respond accordingly. Note that the function is only triggered when the new mood set was not the same as the previous.

2.1.2 Player Emotions

Apart from the defined set of distinct moods, a selection of player emotions are also exposed through the mood system module. The intention of player

(9)

emotions is to directly map them to Fig’s face animations. This enables a larger range of expressions that offer finer detail control compared to the pragmatic mood type enumeration.

Example: the player manages to complete a difficult level, thus receiving a large reward. When returning to the home stage, Fig’s mood is very positive.

Just as the home stage is revealed, the skies turns sunny and Fig employs a cheerful walking pose – all in a synergistic manner.

2.2 Music

The Rim Rift game experience features music playback in all levels. Since the home level is the most frequently visited location in the game, some dynamic mood events are proposed to embellish this fact. As such, the home level is given unique music clips for each mood type (see section 2.1). By listening to a mood change event from the mood system, the music system is able to fade in and out a track. In combination with other techniques, this may yield a meaningful impression when mood is changed. The home level music also incorporates the ability to set custom music clips for each mood type that exclusively play during night time.

2.2.1 Time of Day

The level scenes features a scrolling timeline in which the player can scrub and change the time of day (this is considered a major puzzle solving feature in Rim Rift). A different music theme is played during the night to ensure a particular mood. This is done by using a 120 seconds long audio clip that maps using a 1:1 ratio with the non-real timeline of the same length. As such, day time starts at 0:00 and night time starts at 1:00 (one minute). When time is being scrubbed, a seek operation is committed to find a new time in the audio clip which to continue from. It is ensured that the audio clip is muted while seeking an offset due to undesirable audio artifacts that may be audible otherwise.

2.2.2 Sound Events

Shorter sound tracks may occur throughout the game to emphasize on a specific event (e.g. achievement gain, level completion). To account for these in the music system, the main music loop is faded out for a short amount of time. The temporary music clip is played until completion or until there is an interruption from an external action (e.g. scene change).

(10)

2.3 Sky Colors

The game features a colorful background in all scenes. This background also changes depending on the time of day (both real-time and through the scrollable timeline), as seen in Figure 2.1. The sky may be considered an important medium in which the mood of the scene may be set. As such, some customiz- ability for the positive and negative mood types are proposed. When the mood changes to either, the sky system responds and begin to transition into a new look.

Figure 2.1: Day-night cycle (from left to right; morning, day and night).

2.3.1 Mood Color Profiles

A select mood type can be mapped to a mood color profile, which is a small collection of parameters that can alter the final image in various ways. To allow for an interface with ease of use, these parameters are condensed and named thoughtfully. Most of these are color-making attributes which contribute to a HSV (hue, saturation, value) model [1] that alters the sky colors as a post- processing effect. The elements considered are; hue, intensity, cloudiness and fog.

2.3.2 Application

The sky color effect is applied as a post-processing effect during run-time. All color operations are performed in the HSV color space to allow access to the

(11)

relevant attributes. Each parameter in a mood color profile affects the final image in various way. These are:

• Hue is direct color grading of the final image ∈ [−1, 1].

• Intensity represents the saturation factor ∈ [0, 1]. The intensity is also implicitly modified by the cloudiness factor.

• Cloudiness is the brightness of the image ∈ [0, 1], simulating how much light passes through the cloud layer. This effect also makes the sun appear smaller, as a result of less light passing through.

• Fog controls the amount of fog present in the scene. Fog is by integrated a part of the sky shader, which makes it easy to configure.

2.3.3 Blending

The blending between the mood color profiles takes place in a fixed amount of time. By using linear interpolation [2] on all fields of the color profile, a smooth transition is ensured. Note that at most one color profile can be active at any time. Consequently, transitioning from the negative to the positive profile first require a transition to the neutral state. The neutral mood profile is simply the default color setting with no additional effects applied.

Example: the game recognize inputs that the player has not yet eaten dinner nor taken their medicine at the time of playing. For this reason, the skies begin to darken, Fig accepts a distressed facial expression and the sound track downgrades its harmonies. A notification shows and question the player on their routine.

2.4 Animation Layers

The main character Fig features a wide range of expressive animations that correspond to different activities. Since the main character works as a great medium for outlining the current mood, the animation system also hooks into the central mood system (as shown in section 2.1).

This is done by using animation layers [8] in the animation state machine. By enabling synced animation layers, one is able to re-use the same state machine base layer multiple times. This allows overriding targeted animations within the state machine (e.g. run, walk, eat).

A new layer for the positive and negative mood type is created respectively.

An artist or game designer may then later replace parts of any layer to be used with the associated mood. Since any animation layer is weighted by a variable amount w ∈ [0, 1], the transition to the override will be smooth.

(12)

3. Result

The final result present a centralized mood system that accept inputs from the gameplay node graph (see 1.5.2). The mood system can propagate mood changes to any connected system. The implemented connected systems are;

music playback, sky colors and character animation. When working together, the systems form a proper impression of mood change and is able to subjectively change the feel of the game experience.

Be aware that the perception of mood in the game may be considered heavily subjective. Due to this, the evaluation of the results are limited. A large scale user test would be required to properly study the effects of the implemented techniques. However, the Rim Rift game experience contains many aspects that are in greater need of testing compared to the proposed implementations. As such, no explicit user tests were initiated to evaluate the results. You may view this paragraph as a way to discredit the potential extrapolations made in the following sections.

3.1 Usability

Each mood-altering technique provides an easy-to-use interface to configure the respective usage. Through a carefully authored selection of exposed parameters, the user of the systems should find them easy to operate. Each system handles their own internal state and is individually responsible to ensure a smooth mood transition when a change was requested. As such, all systems internally author a blend weight ∈ [0, 1] which is modified using any transition speed of choice.

3.2 Music

In the final implementation, the music system was restored and updated to be more functional than before. By introducing a uniform interface to play, pause and fade between music tracks, more features than intended could be implemented. This also included a minor feature to play shorter one-time sound events (e.g. achievement music jingle). Furthermore, the chosen data structures allowed for easy mapping of music clips to mood type and time of day, as exposed to the user and internally.

(13)

3.3 Sky

The sky system was retrofitted with a mood change listener that is able to change the hue, intensity, cloudiness and amount of fog in the scene through a configurable set of mood color profiles. This may be considered a major effect in terms of affecting the in-game mood due to the large visual impact. The color modifications were applied as a post-processing effect, thus leaving the initial sky color settings unchanged.

3.4 Animation

The changes made to the animation system were simple but also considered to give substantial effect to the in-game mood. With the use of weighted animation layers, the transition to any animation layer is smooth and unobtrusive. In the final version, no changes were applied to the face animations implicitly (see section 2.1.2).

(14)

4. Discussion

The implementation was first imagined to be covered on a week-by-week basis, however, due to bugs and complications, some of the techniques implemented were revisited and took more time than expected. This was however considered acceptable, since some adequate solutions were successfully built anyway.

Most notably, the music system had inherent implementation difficulty due to the apparent low-level nature of the sound API provided with the game engine [9]. The seek operation provided – used to scrub to a new time point in a sound clip – did not behave as expected and caused unwanted sound artifacts and glitches. Furthermore, unresolved issues in the time system interfered with the continuous and scrollable music playback in level scenes. This led to a minor rework of the time system as a separate bug fixing pass.

The proposed player emotion feature (see section 2.1.2), as visualized by facial animations, was discarded due to complications with the underlying controllers. The player face animation controller already had capabilities for setting and updating the facial animations, however, it could be set from multiple lo- cations in different contexts. This led to unwanted complexity and thus the implementation of player emotion control by mood change was discontinued.

Fortunately, this made the mood system more lightweight.

Overall, most of the implementations required little to no additional nor prior research. All code written was using the C# language under the Mono software platform and framework [5]. Furthermore, the code style guide and agreements were easy to follow during the project, as well as the proposed version control workflow.

4.1 Limitations

Due to the structure of the project and the proposed implementation detail, the techniques can only be controlled and triggered through the mood system exclusively. This means that there is no explicit control over any singular system.

One may choose to modify each system in the editor, however, they are not exposed to be individually controlled by the gameplay node graph. At the time of development, the Mindforce Game Lab team did not express the need to obtain explicit control over individual techniques, which proved this limitation to be minor.

(15)

4.2 Social and Ethical Aspects

The mood system and its connected parts can change the look and feel of the game (section 3). As a result, both the mood and behavior of the player is subject to change depending on the mood portrayed in the game. More notably, the Rim Rift game experience is aimed for people that have a medical condition, including depression and bipolar disorder. Due to this, the players’ mood may change more drastically and potentially infer long term negative effects. It is however noted that the in-game mood changes are exclusively triggered by the gameplay node graph (see section 1.5.2), which is authored by the Mindforce Game Lab team.

In the context of Rim Rift, the respective usage of the implemented systems are strongly suggested to be configured in close communication with individuals who are proficient in the targeted treatments areas. Any failure to do so may result in the target user experiencing unwanted side effects that have not yet been systematically investigated nor documented. By this, the author hereby trusts the Mindforce Game Lab team to carefully consider the authoritative usage of the proposed implementations. Any misconduct of this trust may, in the worst case, result in a detrimental effect to the Rim Rift product and subsequently the reputation of Mindforce Game Lab as a company.

4.3 Future Work

Future work may include exploring additional techniques that are subject of affecting the in-game mood and that may connect to the mood system interface.

Additionally, it would be possible to expose more parameters to the gameplay node graph. This would expand the control surface the Mindforce Game Lab team has across the different implemented components.

(16)

5. Conclusion

This thesis has been able to describe and present three different dynamic game effects that are subject of changing the in-game mood. Based on a centralized system and a set of carefully authored parameters, the implementation is able to portray a change in mood in the Rim Rift game experience. All aspects are designed with usability in mind in order to sustain a low friction workflow for the Mindforce Game Lab team. With the use of variable mood transition weights, any mood change event can unfold without being too noticeable.

(17)

Bibliography

[1] HSL and HSV. https://en.wikipedia.org/wiki/HSL_and_HSV.

[2] Linear interpolation. https://en.wikipedia.org/wiki/Linear_

interpolation.

[3] Mindforce Game Lab AB. https://www.mindforcegamelab.com/.

[4] Justyna Fryczak. Developing empathy through single-player video games.

Master’s thesis, Umeå University, 2013.

[5] .NET Foundation and Xamarin. Mono. https://www.mono-project.com/.

[6] J. Leighton Read and Stephen M. Shortell. Interactive games to promote behavior change in prevention and treatment. 2011.

[7] Thor Brigsted. xNode. https://github.com/Siccity/xNode.

[8] Unity Technologies. Unity Animation Layers. https://docs.unity3d.com/

Manual/AnimationLayers.html.

[9] Unity Technologies. Unity Real-Time Development Platform. http://

unity.com/.

Dynamic Mood in Games Using Parametric Input