Validating Puzzle Game Level Design Using Artificial Intelligence - Aaltodoc

Page created by Joel Simmons

IT & Technique

English

Like
Share
Embed
Fullscreen
Slides
Download HTML
Download PDF
Abuse

←

→

Page content transcription

If your browser does not render page correctly, please read the page content below

Validating Puzzle Game Level Design Using Artificial Intelligence - Aaltodoc

Aalto University
School of Science
Master’s Programme in Computer, Communication
and Information Sciences

Essi Jukkala

Validating Puzzle Game Level Design
Using Artificial Intelligence

Master’s Thesis
Espoo, April 27, 2020

Supervisor:      Professor Perttu Hämäläinen
Advisor:         M.Sc. (Tech) Juuso Toikka

Aalto University
School of Science
Master’s Programme in Computer, Communication                       ABSTRACT OF
and Information Sciences                                          MASTER’S THESIS
 Author:             Essi Jukkala
 Title:
 Validating Puzzle Game Level Design Using Artificial Intelligence
 Date:               April 27, 2020                             Pages: vii + 65
 Major:              Game Design and Production                 Code: SCI3046
 Supervisor:         Professor Perttu Hämäläinen
 Advisor:            M.Sc. (Tech) Juuso Toikka
 In this thesis, a case study of developing an artificial intelligence tool for com-
 puter game design is presented. The game used, Ketsu, is a single-player puzzle
 game with novel mechanics of mirroring and combining. The levels for the game
 were handmade by a level designer, using an iterative cycle of adjustments and
 evaluation to achieve design goals. Such an iterative process is common in the
 game industry, but, as was the case with Ketsu, the process can be tedious and
 time-consuming.
 Artificial intelligence has been successfully used to replace manual work in game
 development. In particular, artificial intelligence can emulate player behaviours,
 and can be used to validate game content. In this thesis, we explore the possibili-
 ties of AI to validate a level designer’s intent in the game Ketsu. We demonstrate
 how AI can be used to provide more immediate feedback than testing with human
 players, by implementing a tool for visualising and validating level solutions.
 Our results indicate the tool is useful: It approximately halved the time needed
 for each level design iteration, allowing the designer to estimate the solvability,
 playability and difficulty of a level without conducting costly user testing with
 real players.
 The success of the tool highlights the importance of developing intelligent tools to
 empower level designers. By reducing the need to perform tedious tasks, mixed-
 initiative tools such as ours can help designers better focus on the creative aspects
 of creating levels. Additionally, as such tools help minimise the time and human
 resources needed in creating levels, they can lead to significant savings in the
 content generation pipeline. In a time of active research in developing artificial
 intelligence to aid in content generation, our work highlights the potential of
 mixed-initiative tools for level design.

 Keywords:           artificial intelligence, level design, game design, tools
 Language:           English

                                          ii

Aalto-yliopisto
Perustieteiden korkeakoulu
Master’s Programme in Computer, Communication                                DIPLOMITYÖN
and Information Sciences                                                      TIIVISTELMÄ
 Tekijä:             Essi Jukkala
 Työn nimi:
 Pelin kenttäsuunnittelun validointi tekoälyavusteisesti
 Päiväys:           27. huhtikuuta 2020                  Sivumäärä: vii + 65
 Pääaine:           Game Design and Production           Koodi:          SCI3046
 Valvoja:             Professori Perttu Hämäläinen
 Ohjaaja:             DI Juuso Toikka
 Tässä diplomityössä esitetään tapaustutkimus, jossa kehitettiin tekoälyä
 hyödyntävä työkalu tietokonepelien suunnittelun avuksi. Ketsu-peli, jota varten
 työkalu kehitettiin, on yhden pelaajan pulmapeli, joka hyödyntää uudella tavalla
 peilaus- ja yhdistysmekaniikkoja. Pelin kenttien suunnittelija suunnitteli kentät
 käsin. Suunnittelussa hyödynnettiin iteratiivista prosessia, jossa muutokset ja
 niiden arviointi vuorottelevat, ja tämän prosessin avulla saavutettiin suunnitte-
 lun tavoitteet. Vastaavaa prosessia käytetään yleisesti peliteollisuudessa, mutta
 kuten myös tämän pelin kohdalla, on prosessi usein yleisestikin hieman työläs,
 hidastempoinen ja aikaavievä.
 Tekoälyä on menestyksekkäästi käytetty korvaamaan käsin tehtyä työtä pelikehi-
 tyksessä. Tekoäly voi emuloida pelaajien käyttäytymistä, ja sitä voidaan käyttää
 validoimaan pelin sisältöjä. Tässä diplomityössä tutkitaan tekoälyn mahdolli-
 suuksia validoida Ketsu-pelin kenttäsuunnittelijan aikomuksia kenttiä suunnitel-
 lessa. Näytämme, miten tekoäly voi tuottaa palautetta nopeammin kuin ihmis-
 pelaajilla testaaminen. Tämä tehdään toteuttamalla kenttäsuunnittelua avustava
 työkalu, joka visualisoi ja validoi kentän ratkaisut.
 Työn tulokset osoittivat työkalun olevan hyödyllinen: Työkalu vähensi kentän
 suunnitteluun vaaditun ajan noin puoleen jokaisen iteraation kohdalla, sillä pelin
 suunnittelijan ei tarvinnut tehdä testausta käyttäjätestausta oikeilla pelaajilla
 arvioidakseen kentän ratkaistavuutta, pelattavuutta ja vaikeustasoa.
 Työkalun toimivuus tuo esiin älykkäiden työkalujen kehittämisen painoarvon, jot-
 ta kenttäsuunnittelijat saavat lisää tapoja tehdä työtänsä. Vähentämällä työläitä
 ja aikaavieviä tehtäviä, työkalut, joissa aloite uuden luomiseen voi tulla joko tie-
 tokoneelta tai ihmiseltä, antavat kenttäsuunnittelijoille mahdollisuuden keskittyä
 luoviin tehtäviin kenttien suunnittelussa. Lisäksi kyseiset työkalut vähentävät
 tarvittavaa aikaa ja ihmisresursseja, ja voivat siten tuottaa merkittäviä säästöjä
 sisällönluomisprosessissa. Tämä työ auttaa nostamaan esiin tällaisten työkalujen
 mahdollisuudet kenttäsuunnittelulle tänä aktiivisen tutkimuksen aikana, kun
 uusia tapoja käyttää tekoälyä sisällöntuotannossa vielä tutkitaan.
 Asiasanat:           tekoäly, kenttäsuunnittelu, pelisuunnittelu, työkalut
 Kieli:               englanti
                                              iii

Acknowledgements

I am happy to say that my thesis is finally done, and now it time to express
my gratitude for all the people who made this possible. First, I would like to
thank my thesis supervisor Prof. Perttu Hämäläinen for all the encourage-
ment and guidance, my advisor M.Sc. (Tech) Juuso Toikka for all the advice
and kind words, and my mentor Matt for pushing me to finalise this thesis.
    I would like to thank my parents for all the support, and for always
believing in me. Thank you Joutomiehet, my other family, for all the crazy
adventures and amazing people. I am glad I nowadays have more than one
place to call home.
    My journey to explore the student life started with the Guild of Electrical
Engineering, thank you for making me feel welcome. Thank you all my
beloved HTMK peeps for all the long days and even longer nights. My life
would not be the same without you. I would also like to thank everyone else
who I have volunteered with in the student organisations and in the student
union, it has been a pleasure.
    This journey brought me countless new friends and acquaintances. Thank
you everyone with whom I have had a nice time! Especially I would like to
thank Jutta, Tuuli and Kata, for always being there for me. This is just the
beginning.
    Last but not least, thank you Aleksi, you are awesome. I cannot wait to
see where life takes us next.

Helsinki, April 27, 2020

Essi Jukkala

                                      iv

Abbreviations and Acronyms

AI      artificial intelligence
3D      three-dimensional
2D      two-dimensional

                         v

Contents

Abbreviations and Acronyms                                                                   v

1 Introduction                                                                               1

2 The Level Design Process                                                                    4
  2.1 Iterative Game Design Process . . . . . . . . .    .   .   .   .   .   .   .   .   .    6
      2.1.1 Conceptualisation: Refining the Ideas .      .   .   .   .   .   .   .   .   .    6
      2.1.2 Prototyping: Making the Idea Playable        .   .   .   .   .   .   .   .   .    8
      2.1.3 Playtesting: Getting Feedback . . . . .      .   .   .   .   .   .   .   .   .   13
      2.1.4 Evaluating: Deciding What Next . . .         .   .   .   .   .   .   .   .   .   16
  2.2 Iterative Level Design Process . . . . . . . . .   .   .   .   .   .   .   .   .   .   18

3 Artificial Intelligence and Game Design                                                    20
  3.1 Artificial Intelligence Playing Games . . . . . .      .   .   .   .   .   .   .   .   21
  3.2 Artificial Intelligence’s role in Game Design . .      .   .   .   .   .   .   .   .   22
       3.2.1 Game Characteristics . . . . . . . . . . .      .   .   .   .   .   .   .   .   23
       3.2.2 Playtesting, Simulating and Balancing .         .   .   .   .   .   .   .   .   24
  3.3 Procedural Content Generation . . . . . . . . .        .   .   .   .   .   .   .   .   25
       3.3.1 Evaluating Generated Content . . . . . .        .   .   .   .   .   .   .   .   26
       3.3.2 Generating Content . . . . . . . . . . . .      .   .   .   .   .   .   .   .   26
  3.4 Artificial Intelligence Assisting Game Design . .      .   .   .   .   .   .   .   .   29
  3.5 Designer Modelling with Mixed-Initiative Tools         .   .   .   .   .   .   .   .   32

4 The Ketsu Game                                                            34
  4.1 Level Design in Ketsu     . . . . . . . . . . . . . . . . . . . . . . 35

5 Features for Level Design Helper Tool                                                      38
  5.1 Discovering the Needs of the Level Designer . .        .   .   .   .   .   .   .   .   38
      5.1.1 Validating Level Solutions . . . . . . . .       .   .   .   .   .   .   .   .   39
      5.1.2 Improving Playability . . . . . . . . . . .      .   .   .   .   .   .   .   .   40
      5.1.3 Rating Difficulty and Player Performance         .   .   .   .   .   .   .   .   40

                                    vi

5.2   Proposed Tool Features . . . . . . . . . . . . . . . . . . . . . . 41
   5.3   Evaluation Criteria for Tool Features . . . . . . . . . . . . . . 41

6 Implementation of the Helper Tool                                                   43
  6.1 Solving the Levels . . . . . . . . . . .   . . . . . . . . . . . . . .          43
  6.2 The Algorithm for Solving the Levels       . . . . . . . . . . . . . .          44
      6.2.1 A* Algorithm for Levels Using        the Combining Mechanic               45
      6.2.2 Mirroring the Moves . . . . .        . . . . . . . . . . . . . .          45
      6.2.3 Characters Combining . . . .         . . . . . . . . . . . . . .          46
      6.2.4 Collecting Items . . . . . . . .     . . . . . . . . . . . . . .          47
  6.3 Example Level Solution . . . . . . . .     . . . . . . . . . . . . . .          48
  6.4 Testing the implementation . . . . .       . . . . . . . . . . . . . .          50

7 Evaluation of the Tool                                                              51
  7.1 Interview with the designer . . . . . .     . . . . . . . . .   .   .   .   .   51
      7.1.1 Using the Tool During the Level       Design Process      .   .   .   .   52
      7.1.2 The Value of the Tool . . . . .       . . . . . . . . .   .   .   .   .   53
  7.2 Improvement Possibilities . . . . . . .     . . . . . . . . .   .   .   .   .   53

8 Discussion                                                                          55

9 Conclusions                                                                         57

A The Level Design Helper Tool Data Structures                                        64

                                     vii

Chapter 1

Introduction

This thesis describes the development and evaluation of an artificial intelli-
gence (AI) tool to help computer game level design. Level design is a sub-
category of game design. To define game design, first we need to define what
games are. There are many definitions, but as a simple definition games can
be defined as a form of play with goals and structure [23]. A more in depth
definition lists six features that apply to games [15]: Games are rule-based
systems, that have variable, quantifiable outcomes, and different outcomes
have different values, either positive or negative. Games are challenging and
players exert effort to influence the outcome, to which the players also feel
attached to. Games can be played with or without any real-life consequences.
    Video games are not just software, but have something unique in them:
the gameplay. The gameplay differentiates video games from other software
as they work differently. When using software, the user has a concrete goal
they want to achieve, but with the games the goal is more vague: to have
fun while playing [3].
    To understand the experiences games give to players, it is useful to look
at the motivations for playing. One framework defines three motivation com-
ponents: achievement, social and immersion [49]. The achievement compo-
nent includes the interest in the rules and systems of a game, as well as the
advancement and competition in a game. The social component is about
connecting with other players, helping each other and being part of a group.
The immersion component relates to the feeling of escaping the real world
and customising your character to whatever you want without any limitations
from the real world. The immersion component of motivation is especially
powerful as nowadays games include realistic visual experiences that can cre-
ate endless virtual worlds for the players to explore and play in.
    As games can be defined as a form of play with goals and structure,
game design can be defined as the design of these goals and structures. The

                                      1

CHAPTER 1. INTRODUCTION                                                        2

structure of a game includes, for example, the rules that the game is based
on, the environment where the game is played and the objects the players
use to reach the goals [22]. The different environments where the player
interacts with the game world are termed “levels”, and the process of creating
them is known as level design. The environments can be, for example, maps
that the player traverses through, or open worlds made for exploration [36].
Traditionally these environments are designed by hand, which can be a time-
consuming process.
    The iterative game design process consist of four phases: conceptualisa-
tion, prototyping, playtesting and evaluating [22]. The iterative game design
process also forms the base for the iterative level design process, which is
the main focus of this thesis. Artificial intelligence can help with creating
and validating content for games. For the content creation, mixed-initiative
tools, where the computer and the designer work together to create content
are especially interesting [18]. Artificial intelligence can also be used to test
games and provide feedback. To explore the possibilities of artificial intel-
ligence assisting game design, this thesis presents a case study of the game
Ketsu, demonstrating how a level design helper tool can speed up the level
design process.
    Ketsu is a puzzle game with mirroring and combining mechanics, where
the two characters are trying to reach specified goals in a grid-based level.
The levels were handmade by the level designer and manually tested. To
speed up this process, a helper tool was designed, based on an interview with
the game’s original level designer, Athina Giokarini. The focus in evaluating
the tool was simple: can it speed up the iterative design process?
    Based on a qualitative study, with supporting quantitative results, the
tool developed in this thesis speeds up the level design process in multiple
ways. In the conceptualisation phase, the tool enables the designer to quickly
test for any flaws in the initial configuration of the level. While the prototyp-
ing phase originally required a lot of trial and error to validate and discover
solutions, the tool could automatically show a solution or state if a level
is not solvable. With a small team and limited resources, playtesting was
initially done manually by the designer and the team. As the tool provides
solutions, it alleviates the burden of using human players to test the levels
for solutions and errors. The evaluation phase also benefited from the tool
as it provided information about the level in a clear format that could be
compared across different iterations.
    Notably, our quantitative results revealed that the tool halved the time
required to create levels for the Ketsu game. The biggest time savings were in
tasks where the designer would need to manually test the levels for errors and
calculate necessary moves to complete the levels. Our research highlighted

CHAPTER 1. INTRODUCTION                                                     3

other areas where similar improvements could be expected from other tools,
highlighting the potential of artificial intelligence in speeding up the level
design process.
    The remainder of the thesis is structured as follows: Chapters 2 and 3
first describe how games and game levels are designed, and what kinds of AI
approaches have been utilised to help designers. This lays the foundation for
describing and understanding the specifics of the Ketsu game (Chapter 4),
and the design, implementation, and evaluation of the level design tool that
constitutes the empirical contribution of this thesis (Chapters 5, 6 and 7).

Chapter 2

The Level Design Process

Games are complex systems that create an experience for the players. The
process of designing and creating a game takes many phases of development
to reach the final product. Even though the game design process always starts
with an idea, and the idea might be simple in the beginning, the game built
based on it is a complex system. For example, the initial idea might be of a
match three game in which the player matches three pieces of the same colour
to remove them from the board. The final product based on this idea could
then be anything from “Candy Crush Saga”[17], a candy-swapping puzzle-
game where the match-three is the core gameplay, to “Gardenscapes”[29],
a home decoration game with match-three as the mechanic to unlock new
items for the players to decorate their virtual home with.
    Because of all the different options for the design, it is extremely difficult
to imagine all the aspects of the game when designing it the first time. This
is where an iterative process helps. The typical design process is as follows:
the initial idea is conceptualised, prototyped, playtested and evaluated. This
cycle, depicted in Figure 2.1, forms the base of the iterative game design
process and is repeated multiple times during the game development process.
The iterative process allows errors in the initial design and leaves open the
possibility of new ideas developing during the process [22].
    The phases of iterative design are based on design processes formulated
halfway through the twentieth century. One process is the “Plan–Do–Act–
Study” cycle, which is a modification of the scientific process and was pro-
posed by Walter Shewhart in “Statistical method from the viewpoint of qual-
ity control”[38]. The iterative process steps he outlines are as follows:

                                        4

CHAPTER 2. THE LEVEL DESIGN PROCESS                                           5

                                Conceptualise

              Evaluate                                 Prototype

                                   Playtest

              Figure 2.1: The phases of iterative game design.

   • Plan: Determine the problem.

   • Do: Create a solution.

   • Study: Analyse the success or failure of the designed solution with
     statistical tools developed for the analysis.

   • Act: If there are problems with the solution, repeat the cycle.

The “Think–Sketch–Show–Evaluate” process created by Henry Dreyfuss and
described in “Designing for people” [8], modifies Shewhart’s process to also
consider the user in addition to the object being designed. It has the following
steps for the iterative process:

   • Think: Examine the cause of the problem and consider solutions by
     using brainstorming techniques.

   • Sketch: Design the simplest and most efficient ways of trying out the
     most promising solutions.

   • Show: Share the design sketches created with potential users, clients
     and other stakeholders.

   • Evaluate: Consider the feedback and evaluate the effectiveness of the
     solution.

CHAPTER 2. THE LEVEL DESIGN PROCESS                                           6

    These cycles both consist of the phases where the problem is identified, so-
lutions are designed and then evaluated. Both of these have the phases similar
to the more recent process used in software development: “Requirements–
Prototype–Review–Revise” [22]. In this process, requirements for the soft-
ware are laid out, a functional prototype is created based on the requirements
and then the prototype is tested and feedback gathered. With the feedback,
the requirements and the initial plan are then revised. As the processes
described are designed for product development, they cannot be applied di-
rectly to game design. Rather, the game design process needs to also take into
account the player experience in addition to the game designer’s intentions.

2.1      Iterative Game Design Process
Player experience is a wider concept than traditional user experience. Tradi-
tional user experience consists of the usability of the software and the func-
tionality. Games include the functionality too, but they consist of events
that the player experiences and that makes them different from tools or
functional products [22]. The player experience is all about the experience
that the game is providing for the player, and playability is used to evaluate
that in addition to usability [12]. Game designer need to take the player
experience into account when designing a game in addition to the game de-
sign itself, which create the requirement for game designers’ intentions to
include more than a traditional product designer’s intentions. The iterative
game design process helps by making the player experience a part the game
design process. As mentioned before, the process consists of conceptualising,
prototyping, playtesting and evaluating.

2.1.1     Conceptualisation: Refining the Ideas
Conceptualisation is the first phase of the iterative game design process.
The initial game idea is refined to provide a core concept for the game. In
this phase the idea turns into the game’s design. During conceptualisation,
designers develop different aspects of the game’s design, taking into account
the mechanics, story, aesthetics and technology for the game [35]. These
aspects together are essential to form a complete game [35]. To create game
designs from the initial idea, different techniques of brainstorming are used to
flesh out the idea. Alex Osborn first described a technique for brainstorming
in “Applied Imagination: Principles and Procedures of Creative Problem-
solving”[27], where he outlines some rules for brainstorming:

CHAPTER 2. THE LEVEL DESIGN PROCESS                                         7

   • Prefer quantity over quality to create as many different ideas as possi-
     ble.

   • Accept all ideas and do not judge any of them.

   • Build on other’s ideas to add more depth to them.

   • Have no limitations on your ideas, let them be as crazy as they come.

   • Visualise the ideas with pictures and not just words.

   • Mix and combine to create unique combinations of ideas.

    Many different game designs emerge during brainstorming that branch
from the original idea. After the designs have gotten more structured with
brainstorming, it is time to select a design to go forward with. To do that,
the game designs need to be evaluated. One way to evaluate them is to check
if they passes through these tests proposed by Jesse Schell in “The Art of
Game Design”[35]:

   • Trust your gut feeling: Does the game feel right?

   • Check the audience: Who would play this and would they enjoy this
     enough?

   • The game is an experience: Is the game well-designed?

   • Novelty makes the game interesting: Is there something new about the
     game?

   • Games are products: Can the game make money and be profitable?

   • Technology has its limits: Can this game be made with the technologies
     that exist?

   • Social gameplay should be designed: Is the game social and if not, is
     that alright?

When going through these tests, the game designs might need some changes
to pass the tests. For example, even if the game idea passes all the other
tests, when looking at the technology, it can deemed non-viable to do with
the current tools available. After such realisation, the game design will need
changes to accommodate the restrictions from the technology.
    The conceptualisation can be done in different ways, either as a group,
or each designer individually at first. Conceptualising together expands the

CHAPTER 2. THE LEVEL DESIGN PROCESS                                           8

ideas quickly when the brainstorming creates a lot of content, but doing the
initial conceptualisation separately usually results in more variation [22]. For
example, the conceptualisation could be done in the following way. Firstly,
the initial requirements are decided to be: “create a mobile game that uses
the real world data and is a multiplayer game”. Secondly, when the initial
requirements have been decided, the designers create the first designs indi-
vidually. Thirdly, after individual ideation designers present their designs
to the group. Fourthly, the presentations the designs are evaluated with the
tests presented above and expanded further in a group. Lastly, after a design
is deemed to be good enough, the process moves onto the next phase of the
process, which is prototyping the design.

2.1.2     Prototyping: Making the Idea Playable
When a new version of the game design is ready, it is time to validate and
evaluate it with prototyping. In most cases the full scope of a games’s design
is complex and it would take months to create a working prototype that has
all the different mechanics, aesthetics, story and technology put together.
That is why, before the prototyping starts, it is important to set out the
goals for the prototype. The goal can be formed into a question that the
prototype is supposed to answer, and it can be anything from trying to find
out the correct aesthetics to trying out the core mechanics and evaluating
them and if they are fun.
    Different kinds of prototypes answer different questions. When trying
out the mechanics, a playable prototype is needed, whereas when explor-
ing ideas in the aesthetics prototype, it can consist only of reference pic-
tures. In “Games, Design and Play: A Detailed Approach to Iterative Game
Design”[22] Colleen Macklin and John Sharp categorise prototypes to the fol-
lowing categories: paper, physical, playable, art and sound, interface, code
and technology, core game and complete game.
    Paper prototypes are quick to make but the are fairly abstract and will
not enable the game to be really playable. They can still provide interesting
insights of the basic interactions in the game and can make the developers
think of the various elements that the game consist of. With paper proto-
types simple game mechanics can also be tried out, especially in puzzle games
where it is easy to explain the interactions without actually playing the game.
This way the basic layout and game perspective can be tested without pro-
gramming anything and iterations are faster [11]. For example, for the Ketsu
game, introduced in more detail in chapter 4, paper prototyping was used in
the beginning to show how a level would be played before anything digital
was developed. Figure 2.2 shows a level as a paper prototype.

CHAPTER 2. THE LEVEL DESIGN PROCESS                                       9

     Figure 2.2: An early paper prototype version of the Ketsu game.

    Interface prototypes are related to paper prototypes as they both think
about the interactions. Interface prototypes only focus on the interactions
and transitions between different screens in the game and can be easily made
in an image editing software [22]. They also serve as a basis for the user
interface (UI) and art development later on in the development phase. The
first version can be drawn on paper and next versions can be implemented
digitally. Examples of these two interface prototype styles, for the Ketsu
game, are shown in Figure 2.3.
    Art and sound prototypes and code and technology prototypes are typ-
ically separate from the actual gameplay. Both of them can be developed
side-by-side with the other prototypes to gather references and information
for the next phases of development. Art prototypes focus on the aesthetics
of the game, so they begin from collecting different reference images and
other references. Based on the references concept art and animated mock-
ups of the game can be created to give an idea about the visual style in the

CHAPTER 2. THE LEVEL DESIGN PROCESS                                       10

                   (a) Paper prototype of the main screen UI.

                   (b) Digital prototype of the main screen UI.

Figure 2.3: Paper version (2.3a) and digital version (2.3b) of an interface
prototype for the Ketsu game.

game [11]. For example, in the Ketsu game project the characters were first
sketched before implementing them in a 3D modelling software. The concept
art and the final models based on the concept art are depicted in Figure 2.4.
Audio prototypes bring life to the animated mock-ups and give an idea of
the soundscapes for the game [11].
    Code and technology prototypes work similarly in the technical side. The
prototyping starts with gathering references of the possible technologies to
be used when developing the game. Technology choices include everything
from the input devices to the game engine and different frameworks [22].
When relevant references have been gathered, the next phase of prototyping
is putting them all together in a working prototype. After that it is easy to
evaluate which features can be implemented and which need to be redesigned

CHAPTER 2. THE LEVEL DESIGN PROCESS                                               11

         (a) Characters concept art.      (b) Characters made in a 3D software.

Figure 2.4: Concept art (2.4a) and the final version (2.4b) of characters for
the Ketsu game.

in order to be viable from the technical perspective.
    A playable prototype is often the most important prototype as it provides
the first version of the game. The prototype implements the key mechanics
and the core actions which already give the first feeling of what the game is
like to play. It is beneficial to use a game engine that allows fast prototyping,
for example Unity, to avoid the overhead of doing things yourself [1]. A
playable prototype tells whether the game is fun to play and that is the
most important bit to figure out when making games. If the core actions are
implemented well enough, and the game still is not fun to play, adding more
content and features will not make it better [22]. Of course some mechanics
might be very complex and only make sense when they are fully implemented,
but in most cases the small playable parts should be fun on their own. If
the playable prototype seems fun enough, it is further developed into the
core game prototype, which includes the core of the game experience. Initial
art designs are implemented into the game in this prototype which usually

CHAPTER 2. THE LEVEL DESIGN PROCESS                                           12

leads to the first fully playable version of the game [22]. An example of a
core game prototype for the Ketsu game can be seen in Figure 2.5. The core
game prototype depicted has the first version of the graphics, and basic user
interactions for moving the characters are available as well as a level selection
possibility.

           Figure 2.5: A core game prototype of the Ketsu game.

    The core game prototype then evolves to the complete game prototype,
which also includes all the user interface elements, tutorial and the full story
of the game. The complete game prototype is the final phase of prototyping
and after that the game usually moves into the production phase where the
first version of the game can be published and the development continues
based on that.[22]
    The complete game prototype should not be developed in the first itera-
tions of the iterative design loop, but only after several iterations. The key
rule to follow in the prototyping phase is the loop rule defined by Jesse Schell,
which states

      The more times you test and improve your design, the better your
      game will be.

Iterative game design process relies on improving the design by testing, so af-
ter each prototyping phase the implementation should be tested. The difficult

CHAPTER 2. THE LEVEL DESIGN PROCESS                                             13

part is to know, when the prototype is ready to be tested. The prototyping
phase should not take too long because if the prototype is not tested early
enough, time is wasted on developing it further, but the prototype should
also be complete enough that it answers the questions it should [35]. The
biggest questions in the game design should thus drive the prototyping phase
so that as many of them can be answered as possible. For that, the questions
need to be prioritised. That usually leads to the agile ways of working, where
the goals are set for smaller tasks at a time and the features being developed
are prioritised so everyone knows what things are important during the next
phase of the iterative process.
    To create prototypes as efficiently as possible, the initial question is a good
starting point. In addition to that, there are two important tips keep in mind
that help keeping the prototyping productive. The first one is not to think
about the quality of prototype too much, and the second one is accepting the
fact that the prototype probably will be discarded after testing [35]. That is
why the first playable prototype should not have the beautiful art integrated
and it should not have the perfect data structures planned. Using a game
engine with some ready-made assets can speed up the prototype development
a lot.

2.1.3     Playtesting: Getting Feedback
The third phase of the iterative game design process is playtesting. Playtest-
ing is all about getting feedback from players to evaluate the game design. As
described previously, the prototype should try to answer a question regard-
ing the game design. Playtesting the prototype actually provides the answers
when the developers see if the players understand the game the same way as
the developers. In many cases, the answers the playtesting gives might not
be what the developers expect as it provides a completely different look at
the design [22].
    When entering the playtesting phase, it is important to define the kind
of playtest the developers want to run. The audience chosen for the playtest
affects the results and will give different kinds of answer. The least effort
for a playtest is an internal playtest where the team of developers test the
game. An internal playtest is easy to setup, but might not give the best
answers as the developers of a game tend to think of the game in the same
way [35]. Internal playtesting is of course valuable as a first step to check that
everything works the way you intended before giving the game to any external
testers. Internal playtesting is also an ongoing process, and for example
continuous builds of even the earliest prototypes is a working practice to get
everyone on the team playing. This way bugs and other problems in the

CHAPTER 2. THE LEVEL DESIGN PROCESS                                           14

implementation come to light easily and can be fixed to work according to
the design.
    After the internal playtesting, the next group for testing usually is friends
and family. The good thing about friends and family as a playtesting group
is that they are easily available and they are easy to communicate with [35].
There are negative side effects to using family and friends as testers too. This
group of testers is biased as they usually want to give just positive feedback
not to hurt your feelings and they will try to like the game even if they
wouldn’t in the real world [35]. For example, your friends might be mostly
games played on a computer and they would not play or even like mobile
games, but still they will give positive feedback as they like you and not the
game actually. Or they might be very harsh as they are used to being honest
with you [11]. Family and friends also might already have an idea of the
game as you might have told them what you’re working on when socialising
with them on your free time.
    When the developers want to get the first impressions of the game, it
is important to use players who have never played the game before. These
kinds of tests give valuable information about the initial feeling of the game
and if the players immediately like or dislike the game. The difficulty with
new players is that they only play for a short amount of time and can’t
comment on the long term progress of the game [35]. Also after the playtest
they cannot be used as new players again as they are already familiar with
the game. Online services, like PlaytestCloud1 , help with this problem as
from there you can get new testers all the time. With online services you can
run also other types of tests, for example target audience testing with new
players and give them even specific testing instructions.
    Other game developers can be also used for testing. They can give feed-
back in more detail about the design as they are familiar with the design
process and can imagine what the game will look and feel like when it is
developed further [22]. The downside of this is that they might not focus
enough on the prototype in their hands and instead concentrate too much on
the ideas they get from the prototype. Other developers can be useful when
testing certain mechanics, as they have expertise to evaluate if a mechanics
works in the context of the game.
    The target audience or the expert players are players who play similar
games to the one being developed. They are able to compare your game to
the other games already out there and give detailed feedback based on their
experiences. Unfortunately these kinds of players also are often biased and
have a favourite game from the genre your game is trying to enter, which leads
  1
      https://www.playtestcloud.com/

CHAPTER 2. THE LEVEL DESIGN PROCESS                                          15

them to compare your game to their favourite too much and not concentrate
on what they like about your game [35]. If the developers listen too much of
the expert player’s opinions, they might end up pleasing just a small group of
people instead of creating a successful game with a broader audience. This is
especially problematic if a community is formed around the early testers, for
example in Discord, where the players then tend to discuss a lot and request
certain features that they would like to see.
    After the audience for testing the prototype has been chosen, it is time
to run the playtest. The playtest can be run live in your studio, in some
public place or online. With live playtests the environment might affect the
playtest and how comfortable the testers feel [35]. In a public place it might
be difficult to record the playtest and if it is done in your studio the testers
might feel like they are under too much pressure and might not act naturally.
Online playtests provide the testers some peace for doing the playtest but it
will be difficult to interact with those kinds of testers. When the location
has been chosen, it is important to think beforehand what things you want
to know.
    The Ketsu game, was playtested multiple times. For example, a paper
prototype, shown in Figure 2.6, was used to test the mechanics without a
digital implementation and a core game prototype was used to compare if
the mechanics worked for the players similarly in a digital version.

   Figure 2.6: Paper elements used for a playtest with the Ketsu game.

   Even if the prototype has been made to answer a certain question, it is

CHAPTER 2. THE LEVEL DESIGN PROCESS                                           16

helpful to write down the questions you will evaluate the playtest results
with. Too broad questions like “Is the game fun?” will not provide enough
answers, so the questions will need to be more detailed than that [35]. The
evaluation can concentrate on anything ranging from a high-level approach
about the feeling and first impression to a really technical approach that tries
to find out bugs and performance issues. A good playtest provides answers
to the specific questions laid out before the test, but it will also give you
a lot of unexpected information [35]. It might turn out that the players
concentrate on features that the developers did not think were important
or it might be that the target audience players do not like the game at all.
The important part of the iterative game design process is evaluating the
answers and problems that came up during the playtest. Also realising that
the game just does not resonate with the players the way you would expect
is an important observation which can then lead to redesign or abandoning
the idea or mechanic completely.
    When starting to evaluate the results from a playtest, it is important to
distinguish between feedback and input from the players. Feedback from the
players is important, but might not lead into any direct actions or changes
to the plan. When asking for input instead, it usually affects the design as
the designers values the players and wants to make the game likeable for
them.[22]

2.1.4     Evaluating: Deciding What Next
Evaluating is the final phase of the iterative game design loop. In this phase
the initial game design is evaluated against the results of the playtest results.
During the evaluation phase the team first gathers all the possible feedback
for the game design from the previous phases of the loop, most of the feedback
coming from the playtesting phase. The evaluation starts from the questions
made for the prototype and for the playtesting and should focus on those
elements.
    The results of the playtesting are broken into small details that can be
acted upon if needed. If the prototype was made to evaluate the core game-
play, the details should provide detailed information about the core: what
actions were used by the players, which parts of the game the players did
not understand and did they like playing the core game. After the details
have been laid out, it is important to explain the causes for them [22]. If
the players did not use a certain action, it is important to figure out was the
reason that they did not know about it, that they did not understand it or
was it just too complex and they did not like it. This evaluation is especially
useful when testing new mechanics to see if it makes sense to developed them

CHAPTER 2. THE LEVEL DESIGN PROCESS                                          17

further or concentrate on other things instead. For example, a novel idea of
a action puzzle game might turn into a more traditional puzzle game after
analysing the playtest results, which happened with the Ketsu game, that
this thesis concentrates on in chapter 4.
    When the results have been analysed, the next step is to decide what to do
next. Based on the details and the reasons behind them it is possible to make
decisions to change the game design in applicable parts. To help identify the
correct parts of the game design, in “Games, Design and Play: A Detailed
Approach to Iterative Game Design”[22] Macklin and Sharpin have created
categories to classify the results with: actions, goals, challenge, information,
feedback, decisions, perceptions, context, takeaways and emotions.
    The categories contain the following information:

   • Actions describe what the players can and cannot do and relate also to
     the controls of the game.

   • Goals are the objectives of the game and it is important to evaluate if
     the players understand them or create their own objectives instead.

   • Challenge is the difficulty of the game and when balanced correctly, it
     keeps the players engaged.

   • Information given during the game should make sense for the player
     and be given in right amounts or otherwise the player might get lost
     or feel overwhelmed.

   • Feedback inside the game gives player the response from the game when
     performing the different actions to understand their outcomes.

   • Decisions are important to create the players a sense of skill when they
     make the decisions and based on them advance towards the goals.

   • Perceptions tell if the game corresponds to the experience it was de-
     signed to provide for the players.

   • Context is the environment outside of the game which still affects the
     gameplay: if the game is played indoor or outdoors, when on the move
     or at home.

   • Takeaways are everything the player gets from the game: the experience
     and the message the developers want to tell.

   • Emotions are the feelings the player feels when playing and it is impor-
     tant to evaluate if they are as intended.

CHAPTER 2. THE LEVEL DESIGN PROCESS                                         18

    The results can be positive or negative, and based on those it is time to
make the changes to the game design. When the parts of the game design
that need to revised have been decided upon, it is time to return to the first
phase of the iterative game design loop, conceptualising. Again it will start
with coming up with new ideas for the parts of the game design and then
refining them.
    This section described the iterative game design process in general. The
phases can be applied to level design but with different kinds of emphasis.
Level design also begins with an idea, which can be the initial mechanic
the whole game is built upon or a new addition to existing elements. The
next chapter highlights the main points that need to be remembered when
applying the iterative process to level design.

2.2     Iterative Level Design Process
Level design is a part of game design where the designer creates the envi-
ronment the game is played in. For puzzle games the environment is the
one level that the player plays. In the level there are the elements that the
level consist of and the mechanics used to solve the level. In puzzle games
there are usually multiple mechanics in play at the same time. For example,
in match-three games, the first mechanic is the matching, but in addition
there can be an element that blows away pieces without matching, which is
a different mechanic. Matt Rix tells in a presentation for the Game Devel-
opers Conference, “Trainyard: A level design post-mortem”[31], that for the
player to learn the new mechanics, it is important to introduce them one
at a time. New objects, new mechanics or new ways of using the current
objects are all elements that should be considered as new things to teach.
Also combinations of elements should be considered as new elements, too.
The granularity, according to Rix, helps the more casual players to take in
the new mechanics and the flow will be smoother that way.
    Creating levels to teach the mechanics benefits from the iterative process.
With it the new mechanic can be tested and evaluated in the context of the
game. During the process the mechanic, the instructions for the player and
the order that the mechanics are introduced in can all be iterated upon to
create the best possible experience. The levels are the most pleasant to the
player when they are balanced and everything is intentional. For example,
placing all the pieces to serve a certain meaning and not forcing the player
to do things in a certain way makes the level feel thought out and balanced
[31].
    The conceptualisation phase begins with brainstorming the different pos-

CHAPTER 2. THE LEVEL DESIGN PROCESS                                          19

sibilities to implement the mechanic for the level. This includes everything
from the look and feel to the technical choices as with the general process.
When the ideas have been gathered, they will be refined and after that they
can enter the prototyping phase. For the Ketsu game, the levels were first
concepted on paper. An example of a level sketched on paper was introduced
earlier in Figure 2.2.
    When creating a prototype for a level’s design, the overall game design
guides the process. The core actions are defined in the game design and they
need to remain the same throughout the levels to keep the game together.
The prototype for a level can consist just of the core idea and be playable
without much art in it for example, or it can be close to the complete level
prototype, where the new mechanic is connected to existing art, technology
and design choices. In the Ketsu game, the framework was created in a way
that the level design, when created in a digital form, used the existing art
assets. An example of an early level prototype was shown in Figure 2.5.
    Playtesting levels is tedious as just a simple mistake in the level design
might make the level completely unplayable and the designer would need to
iterate on design a lot before it can be tested again. For example, in the
Ketsu game, calculating the moves incorrectly in a grid where the player
moves breaks the whole level and testing it will not provide any meaningful
results. With the more complex levels this might be hard to notice when
testing manually, and thus using artificial intelligence can be helpful for this
phase as it can point out mistakes immediately, generate level content based
on existing mechanics, or help the designer to automate some tasks. The next
chapter introduces different uses for artificial intelligence in game design in
more detail.

Chapter 3

Artificial Intelligence and Game
Design

Games and artificial intelligence (AI) have been developed in close proximity
to one another since the dawn of AI research. In fact, already in the 1950s,
an AI learned to play the game Checkers [34]. As board games are simple to
model, but hard to master, they have proven to be an interesting problem for
artificial intelligences to solve, leading to crossover development between the
two fields. Later on, in the 1980s, the introduction of digital games brought
forth another new platforms and problems for AI research [48].
    In general, games present complex and fascinating problems, some of
which can be solved with artificial intelligence. For example, classic chess
is a game in which artificial intelligence has been able to beat humans in
since 1997 [48]. Many games have an explicit ending and can be completed
or played through. Other games have puzzle elements that require careful
thinking from humans to solve. Some games, such as “Minesweeper”, can
be solved or played through by an AI with the proof by exhaustion method,
where all the possible combinations can be tried through, but not all game
are like that [16].
    In many cases the number of possible actions is extremely large and
the complexity makes it impossible to try all actions one after another. In
terms of computational complexity, it means that many games are NP-hard
[48]. For example, Nintendo classics like “Super Mario Bros” and “Leg-
end of Zelda” are NP-hard. This was proven by proving that these games
are essentially versions of a boolean satisfiability problem, 3-SAT, which is
known to be NP-complete [2]. To prove the NP-hardness, it is enough to
piece the games to variables that affect the solution. Using these pieces, it is
possible to answer the question “”Given the starting position, is it possible
reach the goal?” The process uses the pieces to reduce the 3-SAT problem

                                      20

CHAPTER 3. ARTIFICIAL INTELLIGENCE AND GAME DESIGN 21

to correspond the games and thus proving that they are NP-hard. [2]
    Throughout history games have been a popular pastime. Nowadays video
games make a total of over $100 billion in revenue, and the number is growing
[48]. For research purposes, the popularity of games is a positive thing,
as more games means more content for research. On the other hand, the
popularity also creates requirements for games: they need to have a lot of
content. Utilising artificial intelligence can help a lot with this as AI can be
used for testing new features, simulating game progress or even creating new
content for games. All of these require novel AI solutions in the future to
keep up with the gaming industry.
    Artificial intelligence can be used in both simulating player behaviour
and analysing it from a live game. Simulating players and analysing data is
already a standard in the gaming industry, for example for “Candy Crush
Saga”, for which the process is introduced in more detail in section 3.2.2.
Still, new games will require new ways of simulating players. For example,
simulating location-based games is difficult when compared to a game with
only certain maps to play through. In the future, artificial intelligence can
also be utilised to help game designers. Georgios Yannakakis predicts that
in the future AI will help designers in the process of creation by learning
the designers preferences, so AI can be used not only as a passive tool to
simulate player behaviour and create feedback about the game, but also to
learn about the ways designers create content [47].

3.1      Artificial Intelligence Playing Games
When talking about using artificial intelligence in the gaming industry and
research, people often think about AI playing games like chess against hu-
mans. The second usage of AI in games that typically comes to mind is an AI
controlling non-player characters. More modern uses of AI in games include,
for example [48]:

   • Playtesting, where artificial intelligence is used to play the game as a
     human player would, to provide insight into the game interactions that
     emerge in a game.

   • Simulating games, where AI plays through a game with certain param-
     eters to provide information about the difficulty of the gameplay.

   • Procedural content generation, where AI creates content for the game.

   The first two use cases rely heavily on the fact that AI can play games.

CHAPTER 3. ARTIFICIAL INTELLIGENCE AND GAME DESIGN 22

In this chapter artificial intelligence playing games is first introduced, and
after that the chapter concentrates in content generation.
    Different algorithms and simulators need knowledge of the game rules
and mechanics to be able to play. Artificial intelligence can play a game in
the role of a human player or as a non-player character, and either to win
or for experience. Depending on the situation, a suitable role and way of
playing needs to be chosen. For the purpose of this thesis, AI playing as a
human player is more relevant, so the focus will be directed to that aspect
of artificial intelligence playing games.
    When artificial intelligence is used to play games in the role of a human
player, it is mainly used either to play through the game, i.e. to win, or to
play the game like a human player would, to simulate player behaviours [48].
The first approach is largely used in academia to benchmark AI performance.
It is also used in the game industry, for example to verify if a level can be
solved, or if there are any exploits. The second approach, artificial intelligence
playing for experience to act as a human player, is used in the game industry
to see if levels are playable [48]. In addition to checking that a level is solvable,
developers usually want to gather other data. This data can, for example,
show how hard the level is to complete, how many moves are required and
what mechanics the player might use to get through a level.
    Combining both of these methods provides interesting insights for game
developers: an AI developed to play as a human player can evaluate different
levels generated either manually by a level designer or automatically with
procedural content generation. The next section focuses in the different way
artificial intelligence can aid game design.

3.2      Artificial Intelligence’s role in Game De-
         sign
Artificial intelligence can be used in various ways to aid game design in
addition to playing games. In this part of the chapter we will first introduce
some characteristics that need to be considered when developing an artificial
intelligence to help with game design. After that, we will go through popular
ways in which AI can be used to help with game design and creating game
content. The chapter ends with introducing mixed-initiative game design
tools, where either the computer or the human designer can take initiative
to decide what to do next.

CHAPTER 3. ARTIFICIAL INTELLIGENCE AND GAME DESIGN 23

3.2.1     Game Characteristics
This section will introduce some game characteristics that affect game design
as a whole, as well as the ones relevant for the design of an AI for a puzzle
game. Game characteristics are groups of features giving a description of the
game, for example, the amount of players, the average playtime and the luck
involved in playing.
    The first characteristic to consider is the number of players in the game.
Games can have just a single player, two players or more than two players.
The first category can be further up divided into purely single-player games,
like “Tetris”[42], and to one-and-a-half-player games, like “Civilization”[41],
the latter category having non-player characters as a half of a player in addi-
tion to the actual human [9]. The distinction between the two is fuzzy, but
the latter is mainly used to refer to games, where the non-player characters
are advanced enough to have an impact on the human player’s game and are
not just additions to the story. The non-player characters usually play as
the enemies, and many single-player games belong to this category, rather
than being purely single-playered. For example, playing “Civilization”[41]
against the AI would be categorised as an one-and-a-half-player game, as the
decisions of the non-player characters heavily affect the choices of the human
player [9].
    Puzzle games are usually designed to be single-player experiences, as usu-
ally they do not feature any enemies or other non-player-characters that
would affect the game. For designing an AI to play puzzle games, single
player games present an easier challenge than multiplayer games, but they
have other characteristics that affect the development.
    Two player games might be divided into games that are played with two
players or with two teams, usually against each other. Most of the classic
two-player board games are a good example of the former, such as chess, and
many of the popular team shooter games, for example “Counter-Strike”[45],
count as the latter. Multiplayer games have a lot of variation too. They
can either be games where players play purely against each other, like many
board games, or games where players play against only a subset of all the
players in the game, such as “World of Warcraft”[4] [9].
    In addition to the number of players, two important characteristics of
a game are stochasticity and observability. Stochasticity describes the pre-
dictability of the game, so all game mechanics that generate any kind of
randomness increase the stochasticity of the game, such as a dice roll.[48]
In many puzzle games there is very little randomness as the gameplay is
built on logic and player choices rather than changes coming from inside
the game. For example, in “Minesweeper”[24] the field is generated when

CHAPTER 3. ARTIFICIAL INTELLIGENCE AND GAME DESIGN 24

the game starts and no randomness is introduced afterwards. In other cases
some randomness might exist, depending on the mechanics, such as pieces
falling to the board in match-three games or the pieces falling from the top
in “Tetris”.
    A characteristic related to stochasticity is observability. Observability
determines the amount of information available to the players during the
game. All of the information might be available for all the players, or some
of it might be hidden, or given only partially. [48] For example, in many card
games, hidden information is the other player’s hand. In puzzle games hidden
information is rarely used, but it can be, for example, when the whole map
is not visible immediately, but is shown when the player progresses through
it.
    One more important characteristic that affects AI design for puzzle games
is branching factor, which informs about the number of choices players can
make at any decision point of the game [48]. At its simplest, the branching
factor can be just two, to do an action or not to do it, or the branching factor
can be very large. The branching factor is large, for example, in match-three
games, when a player can match any of the pieces to many directions on every
turn. In puzzle games, the branching factor greatly affects the effectiveness
of AI algorithms. For a game with a large branching factor, it might not be
possible to use exhaustive methods such as tree search algorithms, and other
techniques might also struggle when trying to calculate the possible actions
more than a few moves ahead [48]. The Ketsu game has a branching factor
of four, as the main character can move in four directions each turn: up,
down, left or right.

3.2.2     Playtesting, Simulating and Balancing
As described in section 3.1, artificial intelligence can be used to play games in
different ways. From the game design point of view, the ways where AI plays
in the role of a human player are the most interesting as it provides valuable
feedback about the game and how it works. Artificial intelligence can be used
in playtesting, for example, when balancing a game using different kinds of
simulations.
    Playtesting is used when game developers want to gather information
about the player experiences in the game. The information gathered can,
for example, be about crashes and bugs that occur during the gameplay, or
different metrics describing the difficulty and balance of levels in the game.
Traditionally playtesting is done with real human players, but the disadvan-
tage of that approach is the time it takes. When using an artificial intelli-
gence trained to play like a human player would, the results and feedback

You can also read