A End-User Programming System For Creating Adventure Games

(1)

A End-User Programming System For Creating Adventure Games

CHRISTOFFER EKEROTH

Master’s Thesis at CSC Supervisor: Anders Hedman Examiner: Cristian M Bogdan

TRITA xxx yyyy-nnn

(2)

(3)

Abstract

In today’s always online, always connected world we consume more digital media than ever before. As part of this development, social media has blurred the line between producer and consumer, giving anyone with an Internet connection the opportunity to reach out to millions of users.

While platforms such as Twitter, Facebook and Tumblr allow anyone to be the editor of their own news channel, some forms of expression are still out of reach for the everyday user. One such medium is computer games, which have always required—and still do—a high level of programming skill to create. As such, games is a channel that has traditionally been out of reach for the casual content creator.

The goal of this thesis is to address this issue by making the creation of text-based adventure game accessible to non-programmers, as part of an initiative from Paradox Interactive. More specifically, Para- dox Interactive had the goal of empowering their writing staff to create adventure games without requiring the assistance of programmers.

Through interviews and workshops with writers and other stakeholders at Paradox Interactive a set of requirements were elicited, which were complemented by analyzing the works of Joe Dever, author of the influential Lone Wolf series of gamebooks. From these requirements a series of low-fidelity prototypes were developed, which were tested and iterated upon in collaboration with users of the system.

After several iterations on the prototype a final design specification was developed, which was turned into a high-fidelity software prototype.

Building upon the high-fidelity prototype, a working adventure game creation software was developed.

Ett programmeringssystem för slutanvändare ämnat för äventyrsspel

I dagens ständigt uppkopplade värld konsumerar vi digitala medier som aldrig tidigare. Som en del av den här utvecklingen har sociala medier löst upp gränsen mellan producent och konsument, vilket gjort det möjligt för vem som helst med en Internetuppkoppling att nå ut till miljontals andra användare.

Medan plattformar som Twitter, Facebook och Tumblr har gjort det möjligt för vem som helst att bli redaktör för sin egen nyhetskanal finns det vissa uttrycksformer som fortfarande håller vanliga användare utestängda. Ett exempel är datorspel, vilka ställer stora krav på förkun- skaper inom programmering för att man ska kunna skapa dem. På grund av detta har skapandet av datorspel traditionellt sätt varit utom räckhåll för vardagsanvändaren.

Målet med detta exjobb är att, på initiativ av företaget Paradox Interactive, råda bot på detta genom att göra skapandet av textbaserade äventyrspel tillgängligt för icke-programmerare. Mer specifikt har man

(4)

på Paradox Interactive velat skapa ett verktyg som skulle låta deras författare skapa äventyrsspel utan att behöva hjälp från programmerare.

En kravspecifikation för verktyget togs fram genom intervjuer och workshops med författare och andra inblandade på Paradox Interactive, vilken kompletterades med en analys av Joe Devers Ensamma Vargen- böcker. Från kravspecifikationen togs sedan ett antal prototyper fram, vilka testades och utvecklades i samarbete med systemets användare.

Efter ett flertal iterationer av prototoypen togs en slutgilitg speci- fikation fram, vilken låg till grund för en digital prototyp. Utifrån den digitala prototypen utvecklades sedan en slutgiltig version av mjuk- varan.

(5)

Introduction

1.1 Background

1.1.1 Gamebooks

Gamebooks (also colloquially known as “Choose Your Own Adventure Books”, from the series of the same name, or “Solo Adventures”) are works of interactive fiction where the reader is invited to make choices that shape the narrative of the book [4].

This is accomplished by prompting the reader to turn to different pages in the book depending on what path she chooses for the protagonist.

Gamebooks bear many similarities to early text-based computer games, such as Colossal Cave Adventure , which let players navigate through a branching story [11, p. 186]. However, the concept of books containing branching story lines dates even further back: Jorge Luis Borges’ Examen de la obra de Herbert Quain[1] features a fictional author whose work branches out into several paths, leading to a total of nine different endings.

Behavioral psychologist B.F. Skinner also experimented with branching-path books for automated learning; at each branch the student would be presented with a question and a choice of answers, each leading to a different place in the book. A correct answer would direct the reader to a page with more information about the subject and further questions. Answering incorrectly would yield a page explaining why the answer was wrong, and an instruction to turn back to the original page [4].

To better illustrate how a gamebook reads, here is an excerpt from the gamebook Flight from the Dark by Joe Dever [5]:

The path is wide and leads straight into thick undergrowth. The trees are tall here and unusually quiet. You walk for over a mile when suddenly you hear the beating of large wings directly above you. Looking up, you are shocked to see the sinister black outline of a Kraan diving to attack you.

If you draw your weapon and prepare to fight, turn to 229.

(8)

CHAPTER 1. INTRODUCTION

If you evade the attack by running south, deeper into the forest, turn to 99.

If the reader thinks she can dispatch the beast, she will turn to section 229 of the book and see how the story unfolds from there. On the other hand, the tall trees would provide protection from the flying Kraan, so turning to section 99 might be the safer option. . . if she can make it in time, that is.

The ambition of the stakeholders at Paradox Interactive AB, where the thesis work was carried out, is to bring the gamebook experience into the digital realm by creating text-based adventure games for smartphones and tablet devices, such as the Apple iPhone, the Apple iPad or devices powered by the Android operating system.

Paradox Interactive employs a staff of several writers and game designers whom they would like to task with creating these adventure games.

1.1.2 Lone Wolf

Lone Wolf is a series of fantasy gamebooks written by Joe Dever, in which the player takes on the role of a knight named Lone Wolf, who has sworn to defend the land of Sommerlund against the evil Darklords.

The Lone Wolf series has been an important source of inspiration for the stake- holders at Paradox Interactive, and has served as a benchmark for what they wish to accomplish with their adventure games. As such, the book Flight from the Dark [5]—the first in the Lone Wolf series of gamebooks—will be referenced throughout the thesis.

If the reader wishes to find out more about Lone Wolf, a community effort is underway to make the Lone Wolf series of books freely available online, sanctioned by Joe Dever. They can be found at http://www.projectaon.org.

1.2 Problem definition

The goal of Paradox Interactive is to allow for their writers, who may have little or no programming experience, to create adventure games. However, writing software from scratch for iPhone or Android devices is a very complex and time-consuming task, even for people who are programmers by trade.

Is it possible then to simplify the task of creating software? David Canfield Smith notes in KidSim: Programming Agents Without a Programming Language [29]:

This problem—the “end-user programming problem”—is an unsolved

one in computer science. In spite of many previous attempts to develop

languages for end users, today only a small percentage of people are able

to program.

(9)

1.3. GOALS AND DELIMITATIONS

As such, there is as of yet no one formula or approach that allows for end-users to easily create software. However, there have been a number of successful attempts to address smaller parts of the end-user programming problem:

Even though one may be hesitant to call Microsoft Excel a programming lan- guage, nonetheless it endows the end-user programmer with many powerful pro- gramming facilities. It also manages to do so in such a way that the user never has to reflect over the fact that she is actually programming.

In A User-Centered Approach to Functions in Excel [9] Simon Peyton Jones notes:

It may seem odd to describe a spreadsheet as a programming lan- guage Indeed, one of the great merits of spreadsheets is that users need not think of themselves as doing “programming”, let alone functional programming—-rather, they simply “write formulae” or “build a model”.

1.3 Goals and Delimitations

1.3.1 Goals

Following requirements established together with stakeholders at Paradox Interac- tive, the following goals were set up:

• To design and develop a programming environment that supports the creation of text-based adventure games.

• Users of the programming environment should not need previous programming experience or experience with any other programming environment.

• It should be possible to recreate the adventure game book Flight from the Dark (referenced in section 1.1.2) in its entirety using only the programming environment.

• It should be possible to export finished adventures to a file. It should be possible to play the adventure files in a “game player” client in the form of a desktop or mobile application.

• The programming environment should be flexible enough to allow the creation of adventure games set in a diverse variety of worlds and time periods, and should not be limited to one specific setting (i.e. “Tolkienesque fantasy” or

“Cyberpunk”).

1.3.2 Delimitations

To contain the scope of the project, some delimitations were also selected:

• The programming environment should be domain-specific and need not sup-

port general programming tasks.

(10)

CHAPTER 1. INTRODUCTION

• Certain elements of the adventure game experience, such as combat and in- ventory management, would not need to be handled explicitly in the editor but could be seen as “black boxes” handled by the adventure game client.

1.4 Structure of the Thesis

This thesis consists of five primary sections, organized by topic:

• The Previous Work section details previous research in the field of usable pro- gramming languages and environments and related areas of usability research.

• The Method section contains descriptions of the methods used in the thesis and how the thesis research was carried out at Paradox Interactive.

• The Results section presents the results obtained during the thesis work, most of them sourced from interviews and usability sessions.

• The Conclusions section presents a design specification for an adventure game creation tool based on the results in the Results section.

• The Discussion section ends the thesis with some concluding discussions of the results obtained and how they relate to previous research in the field.

While the thesis work also included the implementation and testing of the ad-

venture game creation software, I chose to focus on results obtained during user

research.

(11)

Chapter 2

Previous work

A lot of research effort has gone into making software creation tools more usable, for novices and experienced programmers alike. Kelleher, et al. have compiled a taxonomy of existing programming tools designed to make programming more accessible, and the research behind them [10]. In the following section I will present some common approaches increasing the usability of programming languages.

2.1 Reducing language complexity

One of the early approaches to making programming easier was to make the lan- guages less complex. One of the first known realizations of this idea was the LOGO language, one of the first attempts at bringing programming to a wider audience. In- vented by Daniel G. Bobrow, Wally Feurzeig, Seymour Papert and Cynthia Solomon in 1967, it emphasized simplicity and was intended for constructivist teaching of programming. [23]

One of LOGOs central ideas was “turtle graphics”, the ability for the user to draw lines programmatically by manipulating an on-screen cursor (the “turtle”).

This allowed users to experiment their way towards correct implementations of graphics drawing algorithms.

Below is some example LOGO code that makes the “turtle” draw a spiral, using recursion:

to spiral :size

if :size > 30 [stop] ; an exit condition fd :size rt 15 ; many lines of action

spiral :size *1.02 ; the tailend recursive call end

The approach used in LOGO to reduce complexity was to keep the syntax simple and to minimize the number of language primitives available to the programmer.

Another method of simplifying programming had been attempted a few years earlier

(12)

CHAPTER 2. PREVIOUS WORK

when J.G. Kemeny and T. Kurtz developed the programming language BASIC [10, p. 6].

BASIC (Beginners All-purpose Symbolic Instruction Code) was developed at Dartmouth College, as a less intimidating alternative to FORTRAN and ALGOL. In contrast to the terser syntax used by LOGO, BASIC employed a more conversational style of programming that was designed to be reminiscent of natural language [10, p. 7].

Below is a simple BASIC program that sums the numbers 1 to 10:

100 FOR I = 1 TO 10 110 LET S = S + I 120 NEXT I

2.2 Visual programming languages

Even if programming languages can be simplified, several studies suggest that there may be usability problems intrinsic to textual programming that makes it difficult to comprehend and learn [18] [26] [12].

For example, even the simplest programming language syntax requires strict adherence, and so the user has to remember and understand it before she can create or manipulate programs.

An alternative approach to programming is to let the user manipulate graphical objects instead of text. These objects can then be made to only combine in mean- ingful ways, allowing the environment to help the user construct syntactically and semantically correct programs. This eliminates a large body of user errors that can otherwise become major stumbling blocks for beginners [8].

One of the more recent visual programming languages that follows this paradigm is Scratch, developed by Resnick et al. [16] at the MIT Media Lab. Scratch rep- resents its language primitives as graphical blocks that can be “snapped” together like puzzle pieces. Just like a puzzle, the Scratch blocks have connectors of different shapes, which indicate which blocks fit together.

This paradigm has proven hugely successful; since its launch in 2007, users have uploaded thousands of projects to the Scratch web site (http://scratch.mit.edu), with the core audience consisting of children between 8 and 16 years old. [24] The prevalence of teens and pre-teens in the Scratch community attest to the success of the MIT team’s effort to create an accessible programming language.

The Scratch programming language has been a great inspiration throughout this thesis, both in the methodology used to develop the language and the findings presented by Resnick et al.

2.3 Programming by demonstration

Another way of making programming more accessible is to completely revise the

approach to writing programs. In the classical programming paradigm, the user

(13)

2.4. DOMAIN-SPECIFIC LANGUAGES

feeds the computer a program text, which gets translated to instructions that the computer can execute. In other words, the programmer has an idea for how she wishes the program to behave, then attempts to devise the instructions necessary to achieve the desired behavior.

Programming by demonstration turns this approach on its head; given some precondition, the user demonstrates the desired behavior to the program, and the program tries to infer the appropriate instructions to accomplish it. KidSim, de- veloped by Allen Cypher and David Canfield Smith, is an example of such an envi- ronment. [29] KidSim uses graphical rewrite rules, which lets the user demonstrate program behavior by specifying a “before” condition and a resulting “after” state using the graphical objects in the environment.

For example, the user might instruct a train to move along a track by putting a train and some railroad in the “before” box, then moving the train further along the track in the “after” box. The program then tries to infer a general rule from the user’s demonstration, which will (hopefully) produce the desired result, even in situations slightly different from the one demonstrated.

2.4 Domain-specific languages

Studies have shown that the usability of a programming environment can further be improved by making it domain-specific [7]. This means using language constructs that are closer to the problem domain may make a programming language easier to use compared to general-purpose programming languages.

An example of such a language is SQL (initially known as SEQUEL) a domain- specific language for working with relational databases[2]. Its developers, Donald Chamberlin and Raymond Boyce, describes it as “a data base sublanguage for both the professional programmer and the more infrequent data base user”. As such, it is strictly concerned with operations on databases, which makes SQL easier to learn:

The simple block-structured English keyword syntax and simple op- erations on tables enable users to interact with the SEQUEL system with less training and sophistication than would be required in either a calculus-oriented system or a traditional procedural programming lan- guage.

Below is an example SQL query that retrieves the name and salary for every employee in the “TOY” department who is managed by “ANDERSON”:

SELECT NAME, SAL FROM EMP

WHERE DEPT = ’TOY’ AND MGR = ’ANDERSON’

(14)

CHAPTER 2. PREVIOUS WORK

2.5 Designing usable programming languages

As a result of the work that has gone into designing more usable programming languages and environments there has also evolved a body of work around best practices and frameworks for usable programming language design.

One paper that greatly influenced my work on this thesis was Some Reflections on Designing Construction Kits for Kids [25], in which Mitchel Resnick and Brian Silverman reflect on their 20 years of experience designing technologies for kids. Of particular note was the concept of “Low floor and wide walls”, an analogy which describes the property of being easy to learn (“low floor”) while at the same time allowing for a wide range of different solutions to be built (“wide walls”).

Several compilations of best practices in programming language design have been published, such as Usability Issues in the Design of Novice Programming Sys- tems [21] which compiles a large body of research and organizes it according to Jakob Nielsens heuristic usability principles. [19]

Another entry on best practices, grounded in personal expertise, is Seven Deadly Sins of Introductory Programming Language Design by Damian Conway and Linda McIver, wherein attributes of programming languages are evaluated for their roles in aiding or hindering learnability [17].

The learnings presented in these “best practices” papers have been a great help for approaching the language design problem in an informed way.

2.6 Human-Computer Interaction

Though creating a programming language environment has its unique set of chal- lenges it is still software intended to be used by people. As such, general principles of human-computer interaction and software usability are still applicable.

In particular, Interaction Design: Beyond Human Computer Interaction has been very useful to me in its comprehensible presentation of prototyping at various stages in software development [27, p. 529]. The workflow used in the thesis work—

requirements gathering, design, prototyping, evaluation—also follow the suggested

interaction design process laid out by Preece et al. [27, p. 413]

(15)

Chapter 3

Method

3.1 A user-centered approach

The thesis work was carried out using a user-centered approach as described by Preece et al. in Interaction Design [27, p. 425]. The main tenets of this approach are:

1. Early focus on users and tasks 2. Empirical measurement 3. Iterative design

The details of these principles and how they were implemented in the thesis work are described below.

Early focus on users and tasks

As the name suggests, a user-centered approach involves frequent interaction with the users of the product. As such, I had been allowed access to both junior and senior designers and writers at Paradox Interactive. I had also been assigned a designer intern who would use the software in parallel with it being developed.

An early focus on users and tasks meant querying the designers who would use the system about their current game creation process. How do they currently go about creating adventure games? Do they already use computers in their workflow, or is their toolset completely analog? What are the biggest cognitive challenges in their work and how do they cope with these?

In the user-centered approach the users are also actively involved in the design process. This allows for drawing upon their experience in the adventure game field when coming up with solutions to design problems.

The primary means of involving the users in the early stages of the project were a

series of interviews and workshop sessions (see section 3.3.1). To better understand

the domain of adventure games and gamebooks requirements were also gathered by

(16)

CHAPTER 3. METHOD

analyzing game books and conducting interviews. The results of these inquiries are presented in section 4.3.

Empirical measurement

In the user-centered design philosophy, empirical measurement means measuring reactions and performance of intended users as they interact with various design artifacts. This also means setting up concrete goals for the user experience.

Together with the stakeholders at Paradox Interactive, a set of usability goals were set up (see section 1.3.1) which design alternatives were continuously measured against.

User reactions to designs were also recorded through usability testing at various stages of development (see below).

Iterative design

Iterative design means to continuously test, evaluate and iterate the design during the development process. In the thesis work this was accomplished by developing prototypes at various levels of fidelity.

Usability tests (see above) were conducted with the prototypes with the following artifacts:

1. Paper prototype (see section 3.4.1) 2. High-fidelity prototype (see section 3.4.2) 3. Working versions of the tool (see section 4.8)

The feedback from the test sessions was then integrated into subsequent itera- tions of each artifact.

3.2 Finding an appropriate paradigm

After reviewing existing work (see section 2) on programming environments for novices I reviewed some of the most common approaches and evaluated how well they would fit the task.

Having reviewed different approaches I concluded that a visual programming environment similar to Scratch would be the most suitable. Since this finding in- fluenced the rest of my work on this project it is presented here briefly; for a more elaborate review of the results obtained, see section 4.1.

3.3 Requirements gathering

Before the design work began in earnest I gathered requirements to find out what

tasks needed to be supported by an adventure game creation tool. The requirements

(17)

3.4. PROTOTYPING

gathering process followed the guidelines described by Preece et al. in Interaction Design [27, p. 473].

Two methods were used in gathering requirements:

1. Analysis of the mechanics employed in the gamebook Flight from the Dark.

2. Interviews and workshop sessions with the designers involved in the project.

Another important source for both requirements and approaches to adventure game creation was Joe Dever’s how-to guide Writing Solo Adventures [6], which documents the process he used when writing the Lone Wolf series of gamebooks.

3.3.1 Workshops and interviews

Several interviews and workshop sessions were held with designers and other stake- holders at Paradox Interactive. The primary focus of the interviews were to find out how designers currently create adventure games. Areas of inquiry included:

• What activities are performed when designing adventure games.

• Tools designers use to support these activities.

• Problems with designers’ current tool sets and workflows.

• Common cognitive challenges encountered when designing adventure games.

Though none of the designers at Paradox had designed game books before, they did have experience designing role-playing game systems and adventures, such as the Coriolis series of role-playing games [15].

3.4 Prototyping

There are several problems in software design which have known, workable solutions.

Photo manipulation, word processing and spreadsheet applications have existed for a long time and as such there are several common patterns and best practices that a designer can use.

Adventure game creation tools, on the other hand, are far less common and as such it is less of a given how the user will interact with the tool. For this reason, I started out by developing a series of prototypes of increasing fidelity, which allowed for quick exploration of design ideas [27, pp. 531-535].

3.4.1 Paper Prototype

For investigating how users might perform a set of tasks, Preece et al. recommend

paper prototyping [27, pp. 531-535]. A paper prototype is quick to develop, and is

(18)

CHAPTER 3. METHOD

easy to throw away if it doesn’t work. Also, because of its low fidelity, it keeps both designers and subjects focused on the interaction part of the design.

The first version of the paper prototype was based on ideas and suggestions generated in the workshops and Joe Dever’s Writing Solo Adventures [6] article. I used an A3 sheet of paper to represent the user’s workspace, and Post-it notes to represent the interactive elements of the interface. (See figure 3.1)

The prototype was tested in several session with subjects recruited both from inside and outside Paradox Interactive. Some of the subjects had previously partici- pated in workshops and interviews as role-playing design experts (see section 3.3.1), others had no prior experience with the project or adventure game design.

Each test session was modeled after the guidelines for usability tests in Steve Krug’s book Don’t Make Me think [13, pp. 130-159]:

1. Prior to starting the session, a video camera is set up to record the participant interacting with the system. This allows the designer to review the material later and share the results with other stakeholders.

2. The session starts. The system under test is explained to the participant, and well as why I need their help. I also explain that the session will be recorded, and ask for permission to show the recorded footage to other stakeholders in the project. Krug recommends stressing that the objective is to test the usability of the system, and not the performance of the participant.

3. The participant is given a series of tasks to complete. In this case, the list of tasks was a set of scenarios compiled from the Flight From the Dark gamebook.

The scenarios were chosen as to test as large a number of different interactions as possible.

• Give the player two paths to choose from, one of which is only available if the player has the Vordak Gem item.

• Give the player two paths to choose from, one of which is only available if the player has ten or more gold pieces.

• Continuing from the previous assignment, subtract ten gold from the player’s inventory if she chose the path that requires gold.

• Reduce the player’s combat ability by two points if she does not have a torch in her inventory, then trigger combat with a Burrow Crawler.

• Have the player combat a Marsh Viper. If the player has fewer hit points after fighting the viper than she had before combat, end the game.

• Give the player the choice to take a safe or a riskier path. The conse- quence of choosing the risky path should depend on the outcome of a dice roll.

The subject is encouraged to think aloud as she completes each task. The de-

signer should not prompt the subject, but simply tries to observe the subject,

occasionally asking question about the subject’s thought process.

(19)

3.4. PROTOTYPING

4. After the subject has completed all the tasks the designer may ask some follow- up questions to further clarify the subject’s thought processes. After this, the designer thanks the subject for their time and takes note of any interesting findings from the session.

Following Steve Krug’s advice, I tried to test each version in a small number of sessions as opposed to testing one version many times over. The idea underlying this approach is that every test session yields diminishing returns in the number of usability errors discovered; testing with five users is usually enough to find most problems, and testing with three users generally yields the best return on time invested [20].

Due to time constraints I could not always test each iteration of the prototype with three users, but sometimes had to make do with two tests before creating the next version. In some cases I also made exceptions in the case of glaring usability errors, which I usually addressed after just one test. In total, four iterations of the paper prototype were created.

3.4.2 High-fidelity prototype

The next step in the design process was to create a high-fidelity prototype. A high-fidelity prototype mimics the look and feel of the finished product, but several essential features may be missing. The purpose of the high fidelity prototype was to assert that the interactions designed for the paper prototype could be translated to a computer environment.

I chose to develop the prototype using HTML and JavaScript, so that the pro- totype could be used in a web browser. The reasons for choosing HTML was that it allowed for high portability (all popular operating systems ship with JavaScript- enabled web browsers) and high development speed. A screenshot of the prototype can be seen in figure 3.2.

In order to quickly recreate the functionality of the paper prototype the open- source WireIt library was used. This allowed creating and connecting boxes to each other in a way that closely resembled how users interacted with the paper prototype.

As with the paper prototype, the high-fidelity prototype was tested and iterated upon several times. However, due to time constraints I only had time to conduct two usability tests.

3.4.3 Version One

Using the previous findings, I created an initial working version of the tool. In parallel with developing the tool, I helped an intern at Paradox Interactive use the tool to create a “proof-of-concept” adventure game.

The feedback gathered from using the tool was continuously fed back into the

tool’s development.

(20)

CHAPTER 3. METHOD

Figure 3.1. A work-in-progress prototype

Figure 3.2. The high-fidelity prototype

(21)

Chapter 4

Results

4.1 Finding an appropriate paradigm

Several paradigms from previous work on novice programming environments were evaluated in the initial phases of the project (see section 2). An early hypothesis was that a domain-specific textual programming language would be a good fit for creating adventure games. (See section 2.4)

Inspired by the work of Pane et. al [22] I asked users to describe events in Lone Wolf in a formal manner, i.e. in a way that a computer might understand. The idea was that the proposed solutions would then be used to inform the design of a domain-specific programming language, making it as natural to use as possible.

However, several difficulties were encountered early in the design process:

• Even though the syntax was designed to resemble real-world language, pro- grams were still required to conform to a strict syntax. This required the user to learn and memorize the syntax and semantics of the language in order to use it.

• When asked to give formal descriptions of scenarios in a game book, partici- pants gave very different answers. This indicated that while the semantics of the language could be made to sound natural to some users, this effect would not be universal.

Due to these discouraging early results, I decided to abandon the textual pro- gramming idea and consider other paradigms.

Though programming by demonstration is an interesting concept I deemed it ill-suited for working with adventure games because of the combinatorial complex- ity it would incur: Every game rule would have to be demonstrated by the user, and additional examples might be required for rules that interact in a non-obvious manners. (See Making Programming Easier for Children by Cypher, Canfield and Smith [28][p. 8])

The most promising approach seemed to be designing a tool similar to Scratch,

modified to better suit the adventure game domain. First and foremost, the building-

(22)

CHAPTER 4. RESULTS

block approach employed by Scratch would offer a good balance between expressive power and ease of use. As put by the designers of Scratch:

The Scratch programming environment and language work together to create a system that is exceptionally quick to learn—users can be pro- gramming within fifteen minutes—yet with enough depth and variety to keep users engaged for years.

[16] This would provide the “low floor and wide walls” necessary for making it easy to get started while at the same time allowing for a wide variety of adventure games to be built, as stated in the requirements (see 1.3.1).

Taking these factors into account, I decided to use the visual programming paradigm for the tool.

4.2 Requirements analysis

As mentioned in section 3.3, I had gathered requirements in order to inform the design of the tool. The first part of the requirements gathering process was to analyze the gamebook Flight from the Dark to elucidate the rules used to drive the game forward. Four basic building blocks were identified—entries, side effects, branches and preconditions—which will be presented below:

4.2.1 Entries

The basic building block of a game book is the page, or “entry” as Joe Dever calls it [6]. Each page contains a textual description which advances the story, and usually concludes by presenting the player with a choice of what to do next.

4.2.2 Branches

The alternatives presented to the player—which I will henceforth refer to as branches—

consist of a short description of the choice and an instruction to turn to a specific page. To select which branch to follow, the player simply turns to the appropriate page and continues reading from there.

4.2.3 Side effects

An important element of Flight from the Dark is that the choices the player makes may have consequences that resonate through the entire adventure; as the story un- folds, the protagonist may collect items, learn new skills, make friends and enemies, and so on. In order to remember what has happened to the character, the player records this information on a character sheet which is included in the gamebook.

The effects recorded on the character sheet are important since they affect the

course of events in the gamebook. For example, if the character triggers a trap she

(23)

4.3. WORKSHOPS AND INTERVIEWS

may lose health points. If the number of health points is reduced to zero, the game is over. To prevent the protagonist from dying, the player may consume a health potion that she has found earlier during the adventure. She would then remove one health potion from her inventory and restore the appropriate amount of health on her character sheet.

I will hereafter refer to instructions that affect the state of the game world as side effects .

4.2.4 Preconditions

The information on the character sheet can also influence the choices available to the player. For example, if the player helps out a member of the mages guild she might receive a special amulet. Later in the game, she may need to gain the favor of another mage; if the player has the amulet, she can choose to show it to the mage.

The way gamebooks implement this mechanic is to prefix certain branches with a precondition, e.g. “If you possess the Amulet of Xendor, you may present it to the mage. Should you choose to do so, turn to page 123.”

4.3 Workshops and Interviews

Some of the most valuable findings in the thesis work were discovered during infor- mal brainstorming workshops.

One of my initial hypotheses were that letting the users create their own ab- stractions, just as in regular programming languages, would be a very useful feature.

I presented the idea in an early brainstorming session, but the participants seemed confused as to why this was necessary

¹

.

Asking the group why they thought this way, one of the senior designers de- scribed the process he used to outline his adventures: He would first build a flowchart of the adventure, using Post-It notes to represent each node in the flowchart.

As he explained his process he drew a tree structures of boxes on the conference whiteboard (see figure 4.1). The boxes, which would be Post-It notes in his ordinary workflow, could be one of four different types:

• Story - a segment of exposition in which the player learns what is happening.

• Dilemma - a juncture where the player is asked to make a choice that will direct the course of the adventure.

• Combat - an adversary which the player must defeat to proceed, using the game’s combat rules to determine if the player succeeds.

• Puzzle - an obstacle which the player must use her wits to overcome.

1Presenting my idea to the user group was a mistake—it’s usually a bad idea for the designer to try to impose her ideas on users.

(24)

CHAPTER 4. RESULTS

He explained that these four basic building blocks were usually all he needed to construct adventures, which is why he didn’t see the need for creating further abstractions.

This finding, together with other insights detailed in section 4.4, greatly informed the design of the adventure game creation tool.

In summary, letting the user create her own abstractions, encapsulating recur- ring or complex patterns, was not seen as an important (or even desirable) feature.

Being an essential activity when writing general computer programs, I had taken for granted that this would be a must-have for the adventure creation tool.

Similar results were found by Resnick et al. during the development of Scratch:

Early versions of Scratch had a mechanism for creating procedures. In early field tests, however, many users were confused by procedures since they seemed very similar to broadcasts—both involved associating a name with a collection of commands. [Note: A broadcast in Scratch is a set of commands to be executed when an actor receives a message.]

In the interest of simplicity and minimalism, procedures were removed from the language before Scratch was officially released, and Scratch has gotten along surprisingly well without them.

4.4 Flowcharting

While researching tools of gamebook authors I found that Joe Dever, much like the designers at Paradox Interactive, had used flowcharts to outline his adventures. In Writing Solo Adventures [6] Dever writes:

Flowcharting is the guts of a solo gamebook. It enables you to visualize and summarize exactly what will happen in each entry. It also helps you to balance the game-play (scoring, items found etc.) and make sure that technically the entries link together correctly.

In both Dever’s and the Paradox designers’ methods, each node in the flowchart represents one entry (see 4.2.1) with one or more branches (see 4.2.2) connecting it to subsequent entries. The designer might also keep notes at each branching point about any preconditions (see 4.2.4) that must be met for the player to be able to progress along the given branch[6].

Using flowcharts in this manner helps the designer construct an overview of the adventure. Once this overview is complete, the designer then fleshes out the adventure with more detailed information about what happens to the player at each entry.

Preece et al recommend using metaphors that users are familiar with in order to

help them learn use a new system [27][p.543]. Since the designers at Paradox and

Joe Dever had both chosen to use flowcharts when designing adventures, it seemed

like a flowchart would be a good interface metaphor to use for an adventure game

creation tool.

(25)

4.5. INITIAL DESIGN

4.5 Initial Design

From my requirements gathering (see sections 4.2 and 4.4) I had identified four basic elements that could be used to construct adventure games: Entries, branches, side effects and preconditions. These were then translated into corresponding interface elements in the prototype:

• Entries (see 4.2.1) were represented by a post-it note on which the user could write down a short summary of how the entry would advance the story.

• Branches (see 4.2.2) branches were represented by lines drawn in pen, con- necting entries with each other.

• Side effects (see 4.2.3) were represented as post-it notes attached to an entry.

More than one side effect could be attached to the same entry. Although it was never stated explicitly, the prototype used variables to store side effects.

• Preconditions (see 4.2.4) were represented as post-it notes attached to a branch.

If several preconditions were attached to a branch it meant all of the precon- ditions had to be true for the branch to be available.

While entries and branches were very free-form in how they were implemented in the prototype, side effects and preconditions were more formalized. Based on the results from the requirements analysis (see section 4.2) I created several template Post-it notes for expressing side effects and preconditions where the user could fill in their own values.

I will not include the full initial list of operations here, but I will include some examples for the purpose of illustration.

Some sample operations for use in preconditions:

• Comparisons (lesser than, equal to, etc.) which could be used to compare two values to each other.

• Player has ..., which tested if a player possessed a certain item or skill.

Some sample operations for use in side-effects:

• Set ...to ..., used to set a variable to a specific value.

• Roll dice, which would produce a number between one and six.

4.6 Low-fidelity prototype

4.6.1 Expressing side effects

The first version of the prototype contained several template arithmetic operations,

such as Add ...to ..., which could be supplied as input to the Set ...to ...

(26)

CHAPTER 4. RESULTS

operation. The intent was to give the users several options for how the value of a variable should be expressed: As a constant, as a reference to a different variable or as a function of one or more variables.

For example, to increase the player’s gold by ten the user was first supposed to construct the expression Add 10 to Gold and then use that as the right-hand value of the Set ...to ... operation, resulting in the compound expression Set Gold to (Add 10 to Gold) . (By itself, Add 10 to Gold would not change any variables since it only produced a new value.)

However, participants in the initial test group found this highly unintuitive. To them, an expression like Add 10 to Gold looked like it would change the value of the Gold variable. When asked what operations he would use to increase the Gold variable by ten one participant responded: “Intuitively, I would want to use Add ...to ... . But I guess it could just be an issue about how it’s phrased.”

When the intended use of Set ...to ... was explained to participants, they did neither see the use for this construct, nor how it was different from just using the addition operation: “Is the idea that I should be able to put different things into variables? What other things would you enter using number plus number?”

In the second iteration of the prototype, the generic arithmetic operations were changed to better conform to users’ expectations. For example, the Add ...to ... operation would now let the user increment a variable simply by specifying a variable name and a value. New participants who used this version of the prototype consistently chose the correct operations without any guidance.

4.6.2 Rolling dice

In the Lone Wolf gamebooks, the protagonist’s fate is sometimes left at the mercy of fortune; in these situations the player is required to roll a die, and turn to different pages depending on the result of the roll.

For these types of scenarios the prototype included a special Roll dice oper- ation, which produced a random number between one and six. The user was then expected to use this operation together with the Set variable to ... operation to save the result of the die roll, and then use this variable in a precondition (see section 4.2.4) to decide what branches would be available to the player.

However, this design introduced many usability problems; like variable assign- ment, it had to be explained in every test session. Once again, reducing the gener- ality of the operation proved to be an effective solution: Instead of having the user store the result of the die roll, a special variable—Dice result—was introduced.

Whenever the Roll dice operation was used, the result was automatically stored in Dice result, making it instantly available to use in preconditions for branches.

As was the case with the assignment operations, specializing the Roll dice

operation yielded positive results; with the addition of the Dice result variable

all of the participants used the Roll dice operation correctly without needing any

further instruction.

(27)

4.6. LOW-FIDELITY PROTOTYPE

4.6.3 Negative numbers

Having separate operations for addition and subtraction was another redundancy in- troduced to increase usability; technically, the same effect could have been attained by providing either positive or negative numbers to the Add ...to ... operation.

However, an earlier result indicated that this redundancy would probably be a good thing:

In my early low-fidelity prototypes there was a Boost combat value by ...

operation, which would increase the player’s combat proficiency with a certain amount.

One of the tasks in the prototyping sessions required the participants to reduce the combat value of the player. The “correct” way to do this was to provide a negative number to Boost combat value by ..., which would result in a decrease of the player’s combat value. While this was consistent with the rules of arithmetic, the design of the operation did not suggest that it could be used in this manner.

“It’s not intuitive that Boost combat value can also be used to decrease it. I would change the name or add another operation for reducing the combat value” was one feedback point I received.

While the case of Boost combat value could simply have been a result of un- fortunate naming, it would probably also qualify as an instance of what Conway et al. refer to as “Excessive cleverness” [17]:

Instances of “excessive” cleverness can be difficult to spot, precisely be- cause the “excess” exists only relative to the knowledge level of the novice. Frequently the only way to detect excessive cleverness is to see a novice programmer’s complete misunderstanding of an “obvious” con- cept.

4.6.4 Marsh Vipers and random numbers

The most difficult assignments to solve proved to be the combat with the Marsh Viper (see section 3.4.1, 3) and having the outcome of a player’s choice be dependent on chance (see section 3.4.1, 3).

The difficulty of the Marsh Viper assignment arose from the user having to record the player’s hit points before the combat by saving it to another variable and then comparing it to the player’s hit points after combat.

All participants had some difficulty solving the Mash Viper problem. Even if they realized that they should use variables in some way, it was not obvious how.

When asked to think aloud, one participant said: “I suppose you could check if your hit points have decreased at all. But then you have to establish how many hit points you have before combat has started. . . you would have to have some calculation before combat that saves the value. . . ”

However, once they realized that they could store the player’s hit points before

combat in a separate value, all participants managed to solve the assignment. One

participant who had more experience with video game design remarked: “It takes

(28)

CHAPTER 4. RESULTS

a bit of thinking, but if you have previous experience with [game creation tools] I think you’ll get it. I’ve used Multimedia Fusion so I know how to use variables and so on.”

Having the outcome of a choice depend on chance presented other difficulties which I was never able to solve in a satisfactory manner. Random outcomes were constructed in the following way:

1. Create a Roll dice operation at the current entry.

2. From the current entry, create several branches with identical descriptions.

3. Make each of the branches lead to a different outcome, i.e. a different entry.

4. Attach preconditions depending on the dice result to each branch so that only one of them are ever shown given a certain dice result.

This means that the outcome of the choice has already been decided when the player reaches the entry; what the player sees is simply a branch that has already been singled out from several alternatives. However, since the descriptions of all of the branches are identical, there is no way for the player to tell the difference.

While this design has no impact on how the adventure is played, it was a gross violation of the users’ mental models. In the test sessions it was made clear that the users had the expectation that the dice roll should dictate where the player ended up as she made the choice, not before.

Having two branches which were identical in every fashion except that they led to different sections was also unintuitive. One participant commented: “I don’t know if I’ve missed some sort of presentation function. It is not obvious to me, as a designer, whether these two [branches] are visible or not.”

Introducing a special operation to cover the random outcome of choices could have been a solution to this problem, but I did not have time to try it out.

4.6.5 Evaluation

Apart from the difficulties mentioned above, the participants did not need any additional instruction to complete their assignments. Even though the participants did not participate in a complete reconstruction of Flight from the Dark, I believe with some certainty that they would be able to if the test sessions had continued.

Reviewing Flight from the Dark I managed to reconstruct all scenarios using the operations in the final version of the prototype, given that I would not need to reconstruct the combat rules of the game.

One exception, however, was the combat with the Marsh Viper: In the original

adventure the description says the player is to die if she is damaged by the viper

during combat, while in my version the player dies if she has less health points after

combating the viper. These are not exactly equivalent since the combat rules allows

the player to restore health points during combat, allowing her to take damage and

(29)

4.7. HIGH-FIDELITY PROTOTYPE

still have the same amount of health points (or more) as before. However, I judged that this was within the limits of what could be considered a faithful recreation of the game.

4.7 High-fidelity prototype

As discussed in section 3.4.2, the high-fidelity prototype was basically a translation of the paper prototype into a computer environment.

While this proved useful for validating that the conclusions drawn from the low- fidelity prototype were still valid in a graphical user interface, it provided little in the form of additional design insight. Once the participants had been introduced to the graphical environment, they completed their given assignments without any major difficulties.

4.8 Version One

Once development of a working version had begun no major changes to the design were made.

Given a completed tool, the intern at Paradox interactive managed to create a fully-functional adventure in a matter of two weeks, requiring only intermittent assistance.

A screenshot of the final version of the working tool can be seen in figure 4.2.

(30)

CHAPTER 4. RESULTS

Figure 4.1. A reproduction of the senior designer’s flowchart.

Figure 4.2. The final version of the tool

(31)

Chapter 5

Conclusions

5.1 An Adventure Game Creation Tool

From my findings and results in the test sessions I created a design for a general adventure game creation tool, the specification of which is presented here.

As described in section 4.2, the adventure game creation tool is built upon four basic concepts: Entries, branches, side effects and preconditions.

Each entry is associated with a descriptive text, and is linked to several other entries via branches. The user creates branches by connecting entries together in a graphical user interface; see sections 4.2.1 and 4.2.2 for more details on entries and branches.

To describe the state of the game world, the tool uses variables. Variables serve the same purpose as the character sheet in a gamebook (see section 4.2.3) and consist of a name and value. All variables used in the adventure are visible in the user interface.

There are several implications of using variables, such as typing, declaration, etc.

However, the tool tries to keep this complexity removed from the user: Variables are created automatically as they are used and are dynamically typed.

When a user creates a new adventure, some variables are already defined. Some of the predefined variables have a special meaning as pertains to the rule of the game, while others mainly serve to provide a template for the user as she creates the adventure. The predefined variables are described below:

• Health Points - represents the general well-being of the player. If the Health Points variable is decreased below one, the game is over.

• Combat Bonus - a temporary increase in the player’s combat prowess. After each combat, this number is reset to zero.

• Combat Penalty - a temporary decrease in the player’s combat prowess (see above).

• Gold - the number of gold pieces the player has in her inventory.

(32)

CHAPTER 5. CONCLUSIONS

• Dice result - the result of the Roll Dice operation is stored here (see be- low).

For each entry, the user can add side effects, which affect the state of the ad- venture in some way. The operations that can be used as side effects are described below:

• Add ...to ... - adds a value to a variable.

• Subtract ...from ... - same as above, but using subtraction instead of addition.

• Multiply ...by ... - multiplies a variable by a value.

• Divide ...by ... - same as above, but using division instead of multiplica- tion.

• Set ...to ... - sets a variable to a value.

• Roll dice - rolls a six-sided dice and saves the result to the Dice result variable.

Note that for any operation that requires a value, a variable can be used instead.

For example, one might express the player purchasing a ferry trip with the expression Subtract Ferry Price from Gold , given that there is a Ferry Price variable.

For each branch, the player can attach one or more preconditions which must be true in order for that branch to be available. The available preconditions are:

• ...is greater than ... - tests whether a value is larger than another value.

• ...is lesser than ... - tests whether a value is lesser than another value.

• ...equal to ... - tests whether one value is equal to another value.

• ...not equal to ... - tests whether one value is not equal to another value.

For reasons concerned with implementation details

¹

, the player’s inventory and set of skills had to be implemented as lists, i.e. collections of values instead of single values. The reason I mention these separately is that I do not believe they are strictly necessary for building adventures, but for the sake of completeness they are included here anyway.

The following operations were used to handle the player’s inventory:

• Give ...to player - adds a value to the player’s inventory list.

1A requirement of the game player client was that it should have an interface for managing inventory items (see section 1.3.2). For this to work in the integration between player client and the adventure creation tool items and skills had to be put into specially designated lists.

(33)

5.2. EVALUATION

• Take ...from player - removes a value from the player’s inventory list.

• ...in inventory - checks whether a given value is in the player’s inventory list.

• ...not in inventory - checks whether a given value is not in the player’s inventory list.

Each of the operations above also had an equivalent for managing the protago- nist’s skills (see also section 4.2.3 for more details regarding items and skills in Lone Wolf ).

5.2 Evaluation

Having arrived at a finished specification, did the adventure game creation tool fulfil the stated requirements? Paraphrasing the goals section (1.3.1), the goals of the system were to:

• Provide a tool usable by non-programmers to create adventure games.

• Be flexible and powerful enough to allow for the recreation of the Lone Wolf adventure Flight from the Dark.

As indicated by the results in section 4.6, the system does not require previous programming experience to use and appears to be easy for beginners to learn and use. As mentioned in section 4.6.5, it was possible to recreate Flight From the Dark using the operations available in the final version of the prototype.

The design of the adventure game tool was also successfully translated to a fully-

functioning computer version, as detailed in section 4.8. The computer version of

the tool was used to construct an adventure that could later be used by Paradox

Interactive.

(34)

(35)

Chapter 6

Discussion

In this section I will discuss the methods used, the results achieved and the con- clusions that can be drawn from them. I will also attempt to relate my findings to other research in the field of programming language usability. Finally, I will present some recommendations for further work that could be done in the field of usable game creation tools.

6.1 Methods used

6.1.1 A user-centered approach

First of all, I believe that using a user-centered approach from the onset of the project was of great benefit to the development of the tool. Every test or workshop session that I held with users yielded actionable insights, and allowed me to iterate and course-correct the design of the tool along the way.

I believe that if interactions with users had been less frequent or deferred to the end of the project I might have taken the design in the wrong direction for too long to bring it back on the right track. Also, there would have been the risk that I, having invested a lot of time and effort into a bad design, would subconsciously dismiss any indications that it did not work.

6.1.2 Low-fidelity Prototyping

Another method that I think greatly benefited my work was the use of low-fidelity prototypes. Even though they were the simplest prototypes imaginable, consisting of just paper and Post-It notes, they still generated good feedback.

The “low tech” nature of the prototype also seemed to foster a spirit of creativity and collaboration: I believe that the users felt empowered to make changes to the prototype in a way they would not have with a high-fidelity version, probably because they could make the changes themselves, right there in the test session.

Using low-fidelity prototypes also allowed for an iteration speed that would

not have been possible otherwise. This quote from Some Reflections on Designing

(36)

CHAPTER 6. DISCUSSION

Construction Kits for Kids [25] rings especially true after my experience with low- fidelity prototyping:

Just as we want kids to iterate their designs, we apply the same principle to ourselves. In developing new technologies, we have found that we never get things quite right on the first try. We are constantly critiquing, adjusting, modifying, revising. The ability to develop rapid prototypes is critically important in this process. We find that storyboards are not enough; we want functioning prototypes. Initial prototypes don’t need to work perfectly, just well enough for us (and our users) to play with, to experiment with, to talk about.

6.1.3 Significance of Results

All of the work presented in this thesis has to be viewed in light of the fact that it was conducted with a relatively small group of people; all in all, about a dozen users from inside and outside of Paradox Interactive were engaged in my research and testing work. Thus, the results are by their nature very qualitative.

That is not to say that they are not significant however; as mentioned in sec- tion 3.4.1, testing with five users is usually enough to uncover most usability errors.

However, it would have been interesting to test the prototype with people of more diverse backgrounds, for example fiction authors with no connection to the game industry.

6.2 Low floor, wide walls

Simplicity, composability and elegance are often lauded as ideals of programming, while coupling, specialization and redundancy are often considered anathema. The ideal programmer’s toolbox is small, but very powerful in its potential for creating abstractions. From this toolbox the programmer is then free to compose and weave new constructs, uniquely tailored to almost any domain or problem.

However, this “less is more” approach can have a detrimental effect on the learnability of the programming environment. In Seven Deadly Sins of Introductory Programming Languages [17], Linda McIver and Damian Conway write:

Learning to program is difficult. We believe that a substantial part of this difficulty arises from the structure, syntax and semantics of the pro- gramming languages which are commonly used to teach programming.

A End-User Programming System For Creating Adventure Games