Quest System for Massive Multiplayer Online Role-Playing

Quest System for Massive
Multiplayer Online Role-Playing Games
WILLIAM SAAR
Master’s Degree Project
Stockholm, Sweden 2004
TRITA-NA-E04085
Numerisk analys och datalogi
KTH
100 44 Stockholm
Department of Numerical Analysis
and Computer Science
Royal Institute of Technology
SE-100 44 Stockholm, Sweden
Quest System for Massive
Multiplayer Online Role-Playing Games
WILLIAM SAAR
TRITA-NA-E04085
Master’s Thesis in Computer Science (20 credits)
at the School of Computer Science and Engineering,
Royal Institute of Technology year 2004
Supervisor at Nada was Björn Thuresson
Examiner was Yngve Sundblad
Quest system for massive
multiplayer online role-playing
games
Abstract
Quest systems drive the storytelling of computer role-playing games by
confronting the player with different events in the game. Massive multiplayer
online role-playing games are games where hundreds or thousands of players
play together at the same time in the same game world. This thesis documents
the project to develop a quest system for It’s Alive Mobile Games’s massive
multiplayer online game platform.
The project started with the special challenges involved in designing a quest
system for a game world with hundreds or thousands of players and an
examination of existing solutions and their problems. The examination also
included traditional storytelling techniques, academic research on procedural
authorship, and aspects of social studies and artificial intelligence that relate to
computer-based generation and expression of stories.
A design process with a requirement’s elicitation phase, a system design phase,
and an implementation phase followed the examination. The process resulted in a
prototype of a quest system that featured a web-based quest-authoring tool for
non-programmers and a quest execution component for a test version of It’s
Alive’s game platform.
Uppdragssystem för massiva
online-rollspel
Sammanfattning
Uppdragssystem driver berättandet i datorrollspel genom att presentera spelaren
för olika händelser under spelets gång. Massiva online-rollspel är datorrollspel där
hundra- eller tusentals spelare spelar tillsammans samtidigt i samma spelvärld.
Den här rapporten dokumenterar utvecklingsprojektet för ett uppdragssystem för
It’s Alive Mobile Games massiva online-spelplattform.
Projektet utgick från de utmaningar som det innebär att skapa ett uppdragssystem för en spelvärld med hundra- eller tusentals spelare och började med en
undersökning av existerande lösningar och deras problem. Undersökningen omfattade även traditionella berättartekniker, akademisk forskning om procedurellt
författande samt aspekter av sociologi och artificiell intelligens som relaterar till
datorbaserat skapande och uttryck av berättelser.
En designprocess med en kravinsamlingsfas, en systemdesignfas och en implementationsfas följde undersökningen. Processen resulterade i en prototyp av ett
uppdragssystem med ett webbaserat verktyg som låter författare skapa uppdrag
utan att programmera och en komponent för exekvering av uppdrag i en
testversion av It’s Alive’s spelplattform.
Table of contents
1 Introduction ................................1
1.1 Purpose ....................................................................................1
1.1.1 Overview.............................................................................1
1.1.2 About It’s Alive.....................................................................1
1.1.3 Desirable properties of a quest system .....................................1
1.2 Background...............................................................................2
1.2.1 Defining computer role-playing games and quests......................2
1.2.2 From single-player to massive multiplayer ................................2
1.2.3 Trend towards emergence......................................................3
2 Methods......................................4
2.1 Overview...................................................................................4
2.1.1 Structure of story-based role-playing games .............................4
2.2 Storytelling ...............................................................................4
2.2.1 Storytelling in non-interactive media ........................................4
2.2.2 Computer-generated stories ...................................................5
2.2.3 Storytelling problems with interactivity.....................................5
2.2.4 Levels of conflict...................................................................6
2.3 Scripted quests by human authors .............................................6
2.3.1 Strengths and weaknesses .....................................................6
2.3.2 Case study: Everquest ...........................................................7
2.4 Computer generated quests .......................................................8
2.4.1 Case study: Anarchy Online ....................................................8
2.5 Quests that support different kinds of players ............................9
2.5.1 Player and play style classifications..........................................9
2.5.2 Systems that support different kinds of players ........................ 10
2.5.3 Case study: Morrowind ........................................................ 11
2.6 Quests that affect the game world ........................................... 13
2.6.1 Problems with physical changes to MMORPG game worlds .......... 13
2.6.2 Case studies: Everquest, Meridian 59, Star Wars Galaxies,
Asheron’s Call ............................................................................ 14
3 Execution..................................15
3.1 Requirements elicitation .......................................................... 15
3.1.1 Initial assumptions.............................................................. 15
3.1.2 Requirements from It’s Alive................................................. 15
3.2 It’s Alive’s platform ................................................................. 15
3.2.1 World representation ........................................................... 15
3.2.2 Client-server communication ................................................ 16
3.3 Scenarios and use cases .......................................................... 16
3.3.1 Introduction....................................................................... 16
3.3.2 Definitions ......................................................................... 16
3.3.3 Scenario: Defeat Enemy For Money Mission ............................. 17
3.3.4 Scenario: Create Quest........................................................ 18
3.3.5 Identifying use cases........................................................... 18
3.4 System design......................................................................... 19
3.4.1 It’s Alive’s game platform..................................................... 19
3.4.2 Quest system design ........................................................... 20
3.4.3 Quest structure .................................................................. 20
3.4.4 Quest builder..................................................................... 21
3.4.5 Quest runtime .................................................................... 23
3.4.6 Quest bean........................................................................ 24
3.5 Implementation process .......................................................... 25
3.5.1 Technologies, development environment, and platform ............. 25
3.5.2 Methodology ...................................................................... 26
3.5.3 Differences from the system design ....................................... 26
3.6 Test ........................................................................................ 27
3.6.1 Testing the implementation .................................................. 27
3.6.2 Testing the documentation ................................................... 28
4 Results .....................................29
4.1 Implementation description..................................................... 29
4.1.1 Deliverables and installation ................................................. 29
4.1.2 Database model ................................................................. 29
4.1.3 Quest builder implementation ............................................... 30
4.1.4 Quest runtime implementation .............................................. 33
4.1.5 Suggested improvements..................................................... 34
4.2 Quest system user guide.......................................................... 35
4.2.1 Overview........................................................................... 35
4.2.2 Roles ................................................................................ 35
4.2.3 Quests and quest events...................................................... 35
4.2.4 Authoring quests ................................................................ 36
4.2.5 Implementing a quest event ................................................. 38
4.2.6 Running a quest ................................................................. 38
5 Conclusions...............................40
5.1 The selected method................................................................ 40
5.2 Comments from It’s Alive ........................................................ 40
6 References ................................41
7 Appendices ...............................43
7.1 Appendix A: Use cases ............................................................. 43
7.1.1 Use case: Perform Quest...................................................... 43
7.1.2 Use case: Execute Quest Event ............................................. 43
7.1.3 Use case: Execute Action ..................................................... 44
7.1.4 Use case: Customise Quest Data ........................................... 44
7.1.5 Use case: Notify Quest System ............................................. 45
7.1.6 Use case: Access Quest Data................................................ 45
7.1.7 Use case: Manage Quests..................................................... 45
7.1.8 Use case: Edit Quest........................................................... 45
7.1.9 Use case: Create Quest Event............................................... 46
7.1.10 Use case: Visualize Quest Status. ........................................ 46
7.2 Appendix B: Javadoc................................................................ 47
7.2.1 QuestEventExec ................................................................. 47
7.2.2 QuestEventConfig ............................................................... 49
7.2.3 QuestContext ..................................................................... 51
7.3 Appendix C: Database tables .................................................... 53
1 Introduction
1.1 Purpose
1.1.1 Overview
This thesis includes an examination of quest systems in computer role-playing
games. It also documents the design and implementation of a quest system for
It’s Alive Mobile Games’s upcoming title BotFighters 2 and other games that use
It’s Alive’s massive multiplayer online game platform.
My original vision for this project was to develop a computer-controlled quest
author and I examined the existing quest system with this goal in mind. When
starting the design and implementation of a quest system for It’s Alive’s game
platform, the focus of the project shifted towards building a tool that would allow
human authors to create quests.
The shift in focus brought a change in my intended target user group for the
system. A computer-controlled authoring system would try to satisfy players
directly while an authoring tool targets authors and must enable them to create
quests that satisfy the players.
1.1.2 About It’s Alive
It’s Alive is a games development studio focusing on pervasive games: massively
multiplayer games with the real world as game arena. The games are played on
multiple devices and involve the player 24 hours a day, everywhere.
Launching the world’s first location-based game BotFighters™ in 2000, It’s Alive
is now working with mobile operators, media companies and games publishers in
creating games that will redefine gaming in the 21st century.
The vision is to become the provider of pervasive games and create game
experiences that merge with the real world - redefining reality. It’s Alive was
founded in early 2000, is based in Stockholm, Sweden and is owned by the
founders and the venture capital company Ledstiernan.
It’s Alive develops and manages two pervasive game titles of its own: the action
game BotFighters™ and the “virtual soap” game Supafly™. Additionally, the
company produces custom games for customers like Channel 4 UK, Endemol, and
3.
1.1.3 Desirable properties of a quest system
This project started with a number of questions that relate to quest systems. The
questions deal both with issues of storytelling in games that I had observed and
wanted to examine further as well as issues brought up by It’s Alive:
•
•
•
How can the system create variation in the quests and prevent players
from replaying any quest the same way?
How can the system generate quests that appeal to different player types
and different play styles?
How can the system generate quests that relate to the current situation in
the game world?
1
•
•
•
•
How can the system allow the player to affect the game world through
quests?
How can the system make the quests interesting enough for the players to
want to spend their time on doing quests?
How can the system generate quests that strengthen the players’ relation
to the game world and each other?
How can a system allow players to generate quests for each other?
1.2 Background
1.2.1 Defining computer role-playing games and quests
The central characteristic found in most definitions of computer role-playing
games (RPGs) is character development (Bates 2001, Spector 1999, Hallford
2001). Role-playing games often feature both stories and fighting, but they are
generally separated from story games and action games because of the way the
character develops through the game.
A massive multiplayer online role-playing game (MMORPG) is a role-playing game
where several hundreds or thousands of players each control one or more
characters in a common game world. The term multi-user dungeon (MUD) is
often used about older MMORPGs without graphical user interfaces.
For the purpose of this thesis, a quest constitutes a series of events that can
affect a player’s character. Participation in quests is not always voluntary, but the
narrative drive in most quests derives from the players’ curiosity and will to
improve his character.
I use the term quest rather than story because the story of a RPG is sometimes
considered to be the total experience of the game (Klug 2002), including all the
quests that the player is exposed to and all the events that take place between
the quests and between the events of each quest.
1.2.2 From single-player to massive multiplayer
Most role-playing games (RPGs) use quests to immerse the players in the game
world and give them a reason to act. The quest systems used in most RPGs
depend on human authors to manually write each quest. The massive multiplayer
aspect of MMORPGs brings new demands that make it desirable to automate the
generation of quests.
Designers of MMORPGs want to create worlds that can change and want to
empower players by letting them influence the worlds (Kosak 2002). MMORPG
designers often also try to make each player feel unique, often by offering ways
for players’ to customize their characters.
The multiplayer aspect of MMORPGs makes it more important to provide quests
for both single players and groups of players. It also makes it necessary to
prevent cheating since cheats can affect the balance between different players in
the world.
Creating unique quests for every player or group of players prevents players from
cheating by telling each other about the solutions to specific quests. However, it
also means that a much larger number of unique quests will need to be created
than for single-player RPGs.
2
A system that generates quests on demand can adapt the quests to the players
and increase each player’s feeling of uniqueness. If such a system is aware of the
situation in the game world it can also offer the player opportunities to influence
the game world.
1.2.3 Trend towards emergence
There is a trend in games to move away from rule-based systems towards
emergent systems. Rule-based systems force designers to explicitly specify
everything that happens in a game while emergent systems are based on
specifying a number of simple general principles whose interaction can cause
complex events that even the game designer can not predict.
Sherry Turkle (1995) sees this development as a greater trend in society that has
come to change people's perception of artificial intelligence and even the way we
perceive the operation of the human brain.
In game design the trend is expressed by the advice to create “problems not
puzzles” (Spector 2000). The idea is that the game should present the player with
problems that can be solved by manipulating general principles that control the
game. The principles should be consistent throughout the game even if it leads to
players achieving their goals in the game in ways that the game designer did not
predict.
The alternative, which is very common in older games, is that the game presents
the player with puzzles that can only be solved in ways that the game designer
has explicitly defined. The solutions sometimes require the player to wrap his
thinking around the internal logic of the game designer and the puzzles are often
implemented using specific rules that do not apply elsewhere in the game.
3
2 Methods
2.1 Overview
This chapter documents different approaches to quest systems and examines
aspects of both traditional non-interactive authorship as well as computergenerated narratives that relate to the desirable properties of a quest system
listed in the introduction. The material comes from studying computer roleplaying games (RPGs), multi-user dungeons (MUDs), massive multiplayer roleplaying games (MMORPGs), and computer-generated fiction.
2.1.1 Structure of story-based role-playing games
Mirjam Eladhari (2002) presented a model of story-based games that divide
games into three levels: the code level, the story level, and the discourse level.
While her model was not specifically targeted at MMORPGs or even RPGs, its
terminology is useful for discussing the narrative aspects of such games. This
chapter and other parts of this thesis will refer to the model when discussing
different elements of games. Eladhari provides the following description of the
different levels:
“1. Code level, containing engines, framework and game programming. These
together manifest the geographic structure as well as the conditions for the deep
structure of the narrative and overall story.
2. Story level, which consists of the ov erall story (if there is one), the deep structure
and the individual story-carrying objects, who in their turn can manifest the overall
story and possible side-stories (side-quests) as well as separate independent stories.
3. Discourse level, which consists of the states of the individual elements in the now
of the playing, and the sequential order created between the different parts of the
narrative simultaneously with the movements of the player through the game. It is in
this layer that the surface struc ture of the narrative is visible.”
2.2 Storytelling
2.2.1 Storytelling in non-interactive media
Robert McKee (1997) defines a story as a series of scenes, actions through
conflict that lead to changes to value-charged conditions. Writers group scenes
into sequences and acts, and sometimes give them names that signify their
dramatic function and tension, such as inciting event, sequence climax, act
climax, or story climax.
The dramaturgy is the order of the scenes in a story. Many different
dramaturgical models that order the scenes based on their function and degree of
dramatic tension exist. It is often considered important that the events in the
story result from actions motivated by the characters’ inner motives.
Literature on writing that dates all the way back to Aristotle’s On Poetics identify
two kinds of writing methods, character-based writing and plot-based writing.
Extreme character-based writing starts with a number of characters and builds
the story by documenting the result of role-playing each character’s actions. This
approach ensures that all the events of the story follow from the characters’ inner
motives, but may not result in very interesting scenes or stories.
4
Extreme plot-based writing starts with a number of characters, a number of
interesting events, and a dramaturgical model and builds the story by making the
characters perform actions that lead up to the events in an order decided by the
dramaturgical model. This ensures that many spectacular things happen but may
result in a shallow story that seems stiff and not very believable with respect to
the characters.
McKee recommends a mix between these two extremes. The characters’
personalities and motives should drive the actions of the story but the writer
needs to exercise enough control over the story to ensure that it does not lose its
focus and that its events are interesting and structured enough to avoid bad
artefacts, such as anti-climaxes. The writer should also focus on the interesting
parts of the story and leave out the boring parts of the characters’ lives.
2.2.2 Computer-generated stories
Janet Murray (1997) makes a connection between computer-generated stories
and the formulaic storytelling principles found in Alfred Lord’s description of
composition and performance processes used by Yugoslavian bards and Vladimir
Propp’s analysis of Russian folks tales. According to Murray, Propp analysed 450
tales and concluded that they were all variations of a single core tale consisting of
25 basic plot functions (actually, Murray gets the numbers wrong, Propp (1968)
examined 100 tales and identified 31 functions). Propp also established rules for
the composition of the functions into tales.
Murray notes that the earliest techniques for computer-generated narratives just
substituted words and parts of sentences in a paragraph provided by a human
writer. Though this system may be simple, it provided the foundation for building
stories from “primitives” and Anarchy Online (2001) used a similar technique to
generate and express quests.
Murray also mentions several attempts to build stories from patterns, both
specified by humans and discovered by computers, in story structure. She claims
that the problem with these techniques was that they were only designed to build
non-interactive stories and that the stories that they generated did not tend to
have clear endings.
2.2.3 Storytelling problems with interactivity
Interactivity introduces a number of problems for the storytelling methods used
in non-interactive media (Adams 1999). The storyteller does not control the
motives or the choices of the player. The player usually does not have the kind of
knowledge about the world, nor the relation to other characters in the world that
the writer can embed in his own characters.
Interactivity also changes the way that people experience a work, from the
passive experience based on observation that all non-interactive works offer to an
active experience where the player has to participate in the work by making
choices. The importance of the user’s choice in interactive media means that
there are different ways to achieve satisfaction from interactive works than from
non-interactive works (Hallford 2001, Murray 1997). This raises questions about
the usefulness of dramaturgical structures developed for non-interactive me dia in
interactive works.
Similarities to the character-based and plot-based writing methods can also be
found in the design of interactive works. Simulation games, like The Sims, where
the player watches computer-controlled characters act according to their
programmed personalities use the character-based method to build a story. The
5
Sims also solved the problem of skipping over the boring parts of the story by
allowing the player to control the pace of the time in the game.
Similarity to plot-based writing techniques can be found in action games in which
the players fight their ways through different levels and where the story is only
an excuse to show spectacular effects and video-sequences at the end of each
level.
2.2.4 Levels of conflict
With the definition of stories as series of conflicts one can also analyse a story
based on the nature of its conflicts. McKee (1997) divides the conflicts of noninteractive stories into three levels: extra-personal conflicts, personal conflicts
and inner conflicts.
McKee uses the action/adventure genre as the primary example of stories that
build mostly on extra-personal conflicts, soap operas as a genre based on
personal conflicts, and stream of consciousness as a genre based on inner
conflicts. McKee advocates building stories where conflict occurs at all three levels
at once.
One can also classify the player’s experience of games into the three different
levels of conflicts. Action games where the player defeats hordes of mindless
monsters and navigates through difficult environments cause extra-personal
conflicts for the player. Adventure games with branching story lines where the
player experiences the dilemma of choosing which path to take have the potential
to cause inner conflicts for the player.
Personal conflicts are rare in games but I do think they manifest in MMORPGs and
MUDs as fights among player-controlled characters, or disputes among players
over valuable resources in the game.
I do not consider the fighting between the characters in most multiplayer action
games to occur at a personal level, mainly because players tend to lack
attachment to their characters in such games and because the games do not tend
to focus on social aspects. Even the conflict in multiplayer action games can heat
up on a personal level though when someone raises suspicions of cheating or
when the players build relations that last beyond the game session.
2.3 Scripted quests by human
authors
2.3.1 Strengths and weaknesses
Many games use script engines to bridge the gap between the story level and the
code level. The aim of the script engine is to create an abstraction of the code
level that allows the quest authors to work primarily in the story level without
having to bother with the details of the code level.
Quest authors usually imp lement each quest manually and the scripted quests
have the benefit that the authors can customise the dramaturgy, dialogue,
setting, reward, and even the rules of the game world to each particular quest.
6
Scripted quests suffer from a number of problems. A MMORPG in which players
spend a significant part of their time on quests and where every quest has to be
unique requires a very large amount of quests. Most MMORPGs with scripted
quests do not bother with uniqueness and this has consequences on both the
players’ immersion in the game’s fiction and the game’s difficulty.
It is not uncommon for players who complete quests in Star Wars Galaxies
(2003) or Everquest (1999) to observe other players completing the same quests
and being promised the same important role in the game’s universe. I find this
problematic as one of the benefits of human authors is that they can generally
inject more meaning into stories compared to computer-controlled authors. The
publishing of detailed guides to the quests on game sites also affects the difficulty
of the game (see 2.3.2).
Other problems arise from the separation of the story level and the code level.
Quest authors must try to ensure that all of the story-level quest scripts work
correctly with all the changes to the game state that are caused by code-level
systems and the players’ interactions with those systems. Failure to do so may
result in anything from minor annoyances to the fiction of the game to a complete
breakdown of the game (examples of both are presented in the case studies in
2.3.2 and 2.5.3).
Brenda Laurel (1993) describes these conflicts between the story level and the
code level of a game as conflicts between the “language” and the “thought” of the
game. I view it as a conflict between rule-based systems and emergent systems.
While the systems that simulate the world are now often based on general
consistent principles, the scripted quest systems still often depend on human
authors to explicitly define everything that must happen for the quest to work.
Games can reduce conflicts between scripted quests and changes to the game
state caused by code-level systems by keeping the game world as static as
possible. Scripts tend to work better if emergent behaviour and other changes to
the world are eliminated, except of course those changes that have been
explicitly scripted by the quest authors.
Another way to reduce such conflicts is to make the quests less dependent on the
current state of the game world. This is also a consequence of keeping the game
world static. It allows quest authors to customise quests for the initial state of the
world and depend on the static nature of the world to keep the initial state
forever current.
Keeping the game world mostly static actually seems necessary for the quest
authors to fully be able to customise their quests to the game world. Writing a
hundred quests customised to the characters and locations in a city may be a
wasted effort if the code-level systems allow the players to demolish the city and
scare away all the city’s inhabitants.
Other reasons why static game worlds are more desirable for scripted quests are
that they simplify testing and prediction. The specific nature of rule-based quests
require that testers play through each one of the quests and try to take all
possible and important changes to the game state into account.
2.3.2 Case study: Everquest
Everquest (1999) is a fantasy MMORPG that uses quests scripted by human
authors. The quests usually reward the player with items and money and often
7
change the way the different factions in the world regard the player. The quests
do not seem to have other effects on the world.
Since different players can play each quest in Everquest, a player can even replay
many quests, fan sites (Allakhazam’s Magical Realm 1999) have posted detailed
descriptions and solutions to most quests in the game. My personal experience
with the game is that most players spend much of their game time killing
monsters to gain experience and to find rare items and comparatively little time
on quest-related events.
One conflict between the story level and the code level in Everquest occurred in
the quest for the Journeyman’s boots (Journeyman’s Boots 2000). In the quest,
the player has to find and stop a character called Hasten Bootstrutter that
occasionally appears in an area called Rathe Mountains and runs along a scripted
path.
Hasten is one of several characters that can appear in that area. The others are
referred to as Hasten’s placeholders and only Hasten or one of the placeholders
can exist in the world at any time. When a placeholder appears it needs to
complete its script or die before Hasten or another placeholder can appear.
The Journeyman’s Boots quest broke because of a conflict between the script of
such a placeholder, a very powerful monk character called Brother Zephyl, and
the terrain navigation system at the code level. When Brother Zephyl was
executing his scripted movement, the terrain navigation system caused him to
get stuck in the terrain. No player at the power level that the Journeyman’s Boots
quest was aimed at could ever hope killing Brother Zephyl and, since Brother
Zephyl was unable to complete his script, he would not disappear on his own.
If Brother Zephyl appeared no one without very powerful friends who could defeat
him would be able to finish the quest for Journeyman’s boots until support
personnel reset the server or manually moved Brother Zephyl, allowing Hasten or
another placeholder to appear (Wrinn 2001).
2.4 Computer generated quests
Several MMORPGs have started using partially computer-generated quests. The
descriptions of the quests generally consist of some elements written by human
authors combined with some elements that are dynamically generated by the
game.
Star Wars Galaxies (Star Wars Gala xies 2003) uses both scripted and computergenerated quests. The computer-generated quests come in the form of missions
provided by mission terminals and seem to exist mainly to introduce money into
the game world’s economy.
2.4.1 Case study: Anarchy Online
Anarchy Online (2001) is a futuristic MMORPG that features mission terminals
that allow the player, or groups of players, to generate random missions based
on a number of parameters. The mission terminal generates mission objectives
from a number of mission templates, a location for the mission and a reward for
completing the mission that is proportional to the difficulty of the mission and the
size of the player’s group.
If a player accepts a mission, the mission terminal gives the player a key to an
entrance in a building or a dungeon. The game generates a layout for the mission
8
area behind the entrance and populates the area with enemies and items. The
world outside the mission areas is static and each mission entrance can lead to
different mission areas depending on which mission key that the player who
passes through the entrance possesses.
The missions seem related to the geography of the world and most players seem
to spend most of their game time on doing missions. However, the generated
missions do not have any other effect on the world or its politics other than that
they provide the players with rewards and experience.
The static structure of the mission templates and mission terminal interface has
also lead to the creation of third-party programs that let the players specify what
they want from missions and that accesses the mission terminal repeatedly until
a mission that fulfils the specifications is generated (ClickSaver 2003).
These programs increased the load on the game
servers and the game designers eventually
changed the way the terminals worked to only let
each player generate new missions every two
seconds. This solution did not stop the use of the
third-party tools, but it alleviated the technical
problems that those tools caused for the game.
(Build Notes v14.4.2. 2002). Figure 2.1 shows
the ClickSaver application accessing a mission
terminal.
2.1 The ClickSaver program accesses a mission terminal repeatedly until the mission terminal generates a mission
that fits the player’s specification.
2.5 Quests that support different
kinds of players
2.5.1 Player and play style classifications
Many classifications of players of RPGs exist. Richard Bartle (Bartle 1996)
identified four different motivations to participate in MUDs (Multi-User Dungeons)
and divided player’s into four different categories depending on their main
motivation: achievers, explorers, socialisers, and killers.
Bartle claims that achievers focus on achieving game -related goals and consider
MUDs similar to games like chess, tennis or Advanced Dungeons and Dragons.
Explorers want to learn as much as they can about the virtual world and consider
9
MUDs to be pastimes like reading, cooking or gardening. Socialisers mainly use
the game as a context to converse and interact with other people. They consider
MUDs to be similar to nightclubs, TV, and concerts. Killers want to impose
themselves on other people and consider MUDs to be sports.
Hallford (2001) identifies six different player motivations and approaches to
RPGs: the fragmaster, the problem solver, the treasure hound, the story chaser,
the navel gazer and the tourist.
The fragmaster focuses on combat. The problem solver looks for creative
solutions to problems in the game and wants flexible game objectives. The
treasure hound focuses on collecting treasures and looks for the rewards that
each problem presents. The story chaser mainly takes interest in the dramatic
content in the game. Navel gazers focus on achievement and character
development. The tourist wants to explore the world and enjoys detailed
environments.
In their study on social responses to media (Reeves 1996), Byron Reeves and
Clifford Nass used a psychological personality classification model called “the Big
Five” to classify both users and computers. The Big Five got its name from the
way it ranks personalities on five different scales: dominance, friendliness,
conscientiousness, emotional stability and openness. Reeves and Nass suggest
that dominance and friendliness are the two most critical scales.
2.5.2 Systems that support different kinds of players
Byron Reeves (1996) and Clifford Nass studied the results of adapting a computer
to different personality types by changing the name of the computer and the text
in the computer’s interface to be either dominant or submissive. They concluded
that users liked working with the computer better when the computer had a
similar personality type to the user.
Reeves and Nass also observed that people could temporarily change their
personalities to become more similar to their company and that the bestappreciated personality was a similar personality accomplished through such
change. Their experiments also confirmed that users liked working with the
computer best when the computer first had an opposite personality type to the
user but changed its personality during the work towards the personality of the
user. Users even liked a computer that changed from the user’s personality type
to the opposite personality type more than a computer that had the opposite
personality all the time.
Warren Spector (2000) describes how the ambition for Ion Storm’s role-playing
game Deus Ex was to use emergence through a complex simulation of the game
world to support different play styles:
“It’s all about how you interact with a relatively complex environment in ways that you
find interesting (rather than in ways the developers think are interesting), and in ways
that move you closer to accomplishing your goals (not the developers' goals).
…
Every game system is designed to differentiate one player-character from another,
and to allow players to make decisions that reflect their own biases and express
character differences in obvious ways in the game world.”
Raph Koster (2000) and his team used Bartle’s player classifications in their
design process for Star Wars Galaxies (2003) to make the game work for a varied
audience.
10
The Star Wars Galaxies design even ended up sacrificing the narrative qualities of
its static quests, making them end in what I classify as anti-climaxes, at the
expense of supporting different play styles. The quests often reward players with
items but the developers chose to make most of the item rewards worthless so
they would not devalue the player professions that craft items in the game
(O’Hara 2003).
2.5.3 Case study: Morrowind
Morrowind (2002) is a single-player RPG that uses quests written by human
authors. Quests drive the storytelling in Morrowind and the game demonstrates
how quests can make a game work for different kinds of play styles.
Morrowind uses different factions and characters in the game to give the player
different kinds of quests. Players that want a violent experience might join the
Fighter’s Guild where they will have to clean out rat infestations and kill bandits.
Players that want a more peaceful experience might join the Mage’s Guild that
will send them out to collect herbs in an area of the world where they encounter a
character that needs help with her love life and asks the player to go on a
romantic quest to deliver a message to a lover.
In both the Fighter’s Guild and the Mage’s Guild there are characters that try to
give the player missions that may disagree with the motivation that made the
player join the guild in the first place. One guild master in the Mage’s Guild wants
to send the player on a violent mission and a guild master in the Fighter’s Guild
tries to involve the player in organised crime.
However, in both cases other guild members, whose opinions the player have
found reason to trust, warn the player of the two guild masters and recommend
other directions for the player to take.
Morrowind seems to cater to three categories of players: combat-oriented
players, non-violent players, and sneakers. The combat-oriented players like to
take their enemies head-on and can be warriors or combat oriented mages. The
non-violent players can become healers, peaceful mages or temple servants. The
sneakers can use stealth, theft, and assassination to make their way through the
game and can join the Thieves’ Guild.
Morrowind also demonstrates both trivial and serious problems that can occur
because of conflicts between the code level and story level of the game. The
trivial problem occurs in the text -based dialogue system that Morrowind uses to
allow players to communicate with comp uter-controlled characters, often called
non-player characters (NPCs).
The dialogue system sorts dialogue that NPCs in the game can talk about into
different topics. A code-level mechanism creates hyperlinks from words in
dialogue text to other sections of dialogue whose topics correspond to the words
in the dialogue texts.
The trivial problem occurs when an NPC’s dialogue includes a word that is also a
topic for a section of dialogue. For instance, an NPC called Tuvene Arethan uses
the word “rules” while talking about the traditions of barbarian tribes, Ashlanders,
but also has a dialogue section about the laws of the invading empire in the world
stored under the topic “rules”. When the player clicks on the hyperlink “rules” and
expects to get more information about the rules of the Ashlanders, the NPC
11
instead changes subjects and starts talking about the rules of the invading empire
(figure 2.2).
I think this provides a great example for Brenda Laurel’s description of the
conflict between the story level and code level as a conflict between the thought
and the language of the production (see 2.3.1).
2.2 Tuvene Arethan talks about the rules of the Ashlander society, but when the player selects the automatically
generated hyperlink for the word “rules” the NPC changes subjects and talks about the Imperial laws instead.
The more serious problem occurs during a quest where a NPC called Hlormar
Wine-Sot asks the player to help him retrieve his magical axe, Cloudweaver. A
female mage NPC holds Cloudweaver and the player can either side with the
mage or help kill the mage and retrieve the axe. If the player kills the mage and
picks up the axe, Hlormar asks the player for the axe and everything works fine.
However, if the player knocks down the mage and steals the axe while the mage
is unconscious, Hlormar will repeatedly ask the player for the axe but provide the
player with no option to either give Hlormar the axe or refuse (figure 2.3). Each
popup window with Hlormar’s request only allows the player to close the window
by saying goodbye to Hlormar, something that results in that the window closes
and that another identical window opens, effectively trapping the player in a loop.
12
2.3 Hlormar Wine-Sot asks to get his axe Cloudweaver back, but the game provides no option to give the axe back to
him because the NPC that had stolen the axe is unconscious instead of dead. Pressing Goodbye results in that he
popup closes but immediately opens again, trapping the player in a loop.
2.6 Quests that affect the game
world
2.6.1 Problems with physical changes to MMORPG game
worlds
While text -based MUDs sometimes allow players to reprogram the physical layout
of the game world and its objects (Turkle 1995), these kinds of changes are still
rare in MMORPGs that feature 3D-worlds. One reason for this is that the
calculations used to generate realistic lighting data for the game world’s
geometry are too demanding to allow real-time re-computation.
Another reason is that most games use pre-calculated structures to allow
computer-controlled characters to navigate in the world (Tozour 2002). It would
be inefficient to have characters navigate just by following the world geometry in
real-time so game developers use algorithms to generate path-finding data.
Other reasons why physical changes to the world are difficult include the
rendering constraints of the players’ graphics cards and the distribution of
information about the changes to all affected players. Rendering constraints
include polygon count and texture memory. Failure to stay within the rendering
constraints can cause a drop in the number of frames that can be rendered every
second. Players sometimes refer to the symptom as “slide show”.
Game world designers often adjust the number of polygons for each location in
the world to allow it to render at an acceptable frame rate for all players. This is
already quite difficult in MMORPGs with static worlds because players can create
crowds, drop many objects on the ground, or die in large numbers and leave
many corpses that all charge the polygon budget.
The memory of the graphics cards limits the amount of texture data that can be
stored on the cards. When scenes include more textures than can be stored in the
13
graphics card’s memory, textures need to be transferred from the comp uter’s
main memory to the graphics card’s memory every frame, affecting the frame
rate of the game.
World designers need to ensure that the amount of texture data that is visible at
every location in the world and that the amount of texture data needed to show
all objects that every player avatar can possible display (such as clothes,
weapons, or bags) is smaller than the amount of memory allocated for textures
on the graphics card. This is one of the reasons why no major MMORPG today
allows players to submit images for use as guild emblems on clothes, shields etc.
Distributing information about all the changes to the world is also difficult
because of limitations on the bandwidth of the players’ connections and on the
game servers’ performance.
Some recent MMORPGs (Shadowbane 2003, Star Wars Galaxies 2003) are
starting to allow players to change physical aspects of the game world in limited
ways by giving them the ability to build and destroy houses.
2.6.2 Case studies: Everquest, Meridian 59, Star Wars
Galaxies, Asheron’s Call
Everquest allows players to do quests that change the way different political
factions in the world view the player, but few MMORPGs have used quests to
allow players to make permanent changes to the world, changes that would affect
other players.
Meridian 59 (Meridian 1996) featured a dynamic political system where players
had to retrieve tokens belonging to council- member characters whose support
gave players certain bonuses in the game (Gilroy’s m59 Reference 2003).
Retrieving a token for the council member increased his support for the player’s
political faction and weakened the council member’s support for opposing
factions.
Star Wars Galaxies (2003) uses a similar system where players belonging to the
two sides, the empire or the rebellion, compete at performing a certain quest
related to a monthly episodic story. The side that performs the quest most times
gets a bonus for the following month.
Asheron’s Call featured an editorial board that updated the game world on a
monthly basis. They sometimes added books to the game world that referred to
the actions of players in the world and it is likely that the quests that players
completed could influence the directions of the editorial board’s updates to the
game world. Since the editorial board manually created the changes to the world
off-line before inserting them into the game, they were able to make changes to
the game world that would require too much performance or be too difficult to
automate.
14
3 Execution
3.1 Requirements elicitation
3.1.1 Initial assumptions
My initial plan was to build some form of automated storyteller that would use
principles from interactive writing and a set of quest events to generate
interesting quests for the players. The quest events would be customised to
current data from the game world and be combined according to dramaturgical
principles.
According to that plan, the target user of my system would be the player of the
game and I started my work by examining how quest systems and storytelling in
other interactive productions appealed to players.
3.1.2 Requirements from It’s Alive
It’s Alive initially wanted me to create a requirements specification, a system
design, and possibly a prototype for a quest system. During the analysis of a
brainstorming session at It’s Alive, it also became clear that they needed the
system to allow human quest authors to create the quests. The quest system was
technically similar to a system that It’s Alive had designed to stage events in the
game, and my system would provide both event and quest functionality if it
allowed human authoring.
These requirements greatly affected my initial plan as both my target user group
changed and some of my original objectives became entirely dependent on the
abilities of the quest author. With my new goal to create a tool for humanauthored quests, my target user now became the quest author rather than the
game player. The quest author would either be a game developer, community
manager, or player, so It’s Alive wanted the system to allow non-programmers to
create quests.
My objective to build a system that would create quests that were interesting for
the player would now have to be fulfilled by the quest author. The change also
put me closer to my system’s users, something that allowed me to gain feedback
on the design without having to go outside the company to locate testers.
3.2 It’s Alive’s platform
3.2.1 World representation
It’s Alive’s games take place both in the real world and in a two dimensional
virtual world. The screen of the players’ mobile phones shows the virtual world
and all items and characters in the game. Mobile positioning in the real world is
used to navigate in the virtual world so the virtual world does not contain any
terrain or other obstacles to navigation.
15
3.2.2 Client-server communication
Players communicate with the game server through commands that are
represented as text messages when sent over SMS, but may be represented by
other data structures when sent from mobile phones that support J2ME. Players
communicate with computer-controlled characters and other players in the game
world through commands that include text messages.
3.3 Scenarios and use cases
3.3.1 Introduction
The requirements specification process began by creating scenarios that provided
specific examples of how the system was meant to work. The scenarios
demonstrated functionality that could be isolated and generalised into use cases
that would act as a basis for a system design.
The specification process began with two basic scenarios, the Defeat Enemy For
Money Mission scenario that describes the execution of a typical quest and the
Create Quest scenario that describes an example of how a quest could be
created. The goal at the beginning of the process was to isolate the basic
functionality and leave refinements to later iterations of the development process.
3.3.2 Definitions
3.3.2.1 Definition of terms
This section describes some of the terms that occur in the scenario and use case
specification.
An Action is associated with a quest event and executed by the quest system to
affect other systems of the game.
A Boss NPC (Non-Player Character) is a computer-controlled character that has
some sort of authority in the game world that allows it to send players on
missions.
The Event Graph is a data structure that describes the way quest events are
connected to each other in a quest. The graph is directed and can contain cycles.
Figure 3.1 depicts a typical quest graph.
Start
Find Treasure
Meet Poor Man
Give Money
<< Branch event >>
Don’t Give Money
Gain Poor Man Faction
Gain Greedy Points
End
Figure 3.1. A graphical representation of an event graph.
16
Game Entity is a common term for several kinds of objects that make up the
game world, including characters, items, and locations.
The Game Platform is made up of all the system used to run the live game
except the quest system.
A Game Programmer or Game Developer is a programmer skilled in Java and
It’s Alive’s game architecture.
A Property is a data field associated with a game entity. Such fields include the
amount of money that a character game entity possesses or whether it is alive or
dead.
A Quest is a narrative structure built from several interconnected quest events.
Every quest has a start and an end and the connections between its quest events
make up the event graph of the quest.
A Quest Author is the person that writes a quest by adding, configuring, and
connecting quest events to each other. This person should not have to be skilled
in programming and could be a community manager or even a trusted player of
the game.
A Quest Event is an event that can occur in a quest. It consists of actions that
should be taken in the event, conditions that determine if the quest event has
completed, and connections to other quest events.
The Quest System is the system that handles quest in the game, the system
described in this document.
3.3.2.2 A note about the figures
UML-diagrams use non-standard symbols to represent actors and inheritance.
This was necessary because the tool that was used to create the figures,
Microsoft Powerpoint, does not support the UML’s symbol for actors or the type of
arrowheads it uses to signify inheritance.
3.3.3 Scenario: Defeat Enemy For Money Mission
Actors: Boss NPC, Quest System, Player.
Description: Based on specifications in the quest events of a quest, the quest
system commands the Boss NPC to advertise a mission to players belonging to
the same group as the Boss NPC. The quest system registers an observer that
notifies the quest system when a player that belongs to the same group as the
Boss NPC requests the mission from the Boss NPC.
The player initiates a conversation with the Boss NPC. The Boss NPC detects that
the player belongs to the same group as the Boss NPC and informs the player
that a mission is available. The player asks the Boss NPC about the mission and
the quest system is notified about the request.
The quest system inspects the player’s toughness and searches the game’s
database for a character type that belongs to an enemy group and is of similar
toughness to the player. The quest system spawns a character of that type into
the world and also generates an appropriate reward for the mission in the form of
money. The quest system commands the Boss NPC to describe the mission
objective, to defeat the enemy character, and the reward for completing the
mission, the money.
17
The quest system registers an observer that notifies the quest system when the
enemy is defeated. The quest system commands the Boss NPC to include the
option to give feedback on the mission on its list of subjects to talk about with the
player. The quest system also registers an observer that notifies the quest
system when the player asks the Boss NPC about feedback on the mission.
The player defeats the enemy and the quest system gets notified about the
defeat. The player contacts the Boss NPC and requests feedback. The quest
system commands the Boss NPC to give the player the reward and positive
feedback on the mission.
3.3.4 Scenario: Create Quest
Name: Create Quest.
Actors: Quest Author, Game Programmer.
Description: The game programmer implements quest events that quest authors
can use when constructing quests. The game programmer chooses the type of
the quest event, implements functionality for actions that should occur in the
event, and specifies conditions for determining that the event has completed. The
game programmer also specifies the connectivity of the event, partially
determined by the event type, and implements a way to configure the event.
The quest author creates a new quest and names the quest. The quest author
adds quest events from the available quest events that the game programmer
has created. The quest author then configures each quest event and connects
them to each other to form a flow. The quest author then saves the quest and
deploys it in the game.
3.3.5 Identifying use cases
I identified a number of use cases in the two scenarios. The use cases were
divided into two groups where one group had to do with the execution of quests
in the live game platform while the other group mainly covered the authoring of
quests. The use cases are depicted in the figures 3.2 and 3.3 and detailed
descriptions of the use cases can be found in appendix A.
GamePlatform
NotifyQuestSystem
ExecuteAction
ExecuteQuestEvent
CustomiseQuestData
QuestSystem
PerformQuest
Figure 3.2. Use cases that model the functionality to execute quests in the live game.
18
AccessQuestData
ManageQuest
QuestAuthor
EditQuest
CreateQuestEvent
GameProgrammer
Figure 3.3. Use cases that model the functionality needed to author quests.
3.3.5.1 Overview of use cases related to execution of quests
The perform quest and customise quest data use cases both deal with the
execution of quests, while the execute action and the execute quest event use
cases deal with execution of quest events.
The notify quest system use case specifies functionality that lets the game
platform notify the quest system of events in the game platform, such as the
execution of certain game commands. The access quest data use case specifies
how the quest system interacts with the persistent storage component.
3.3.5.2 Overview of use cases related to quest authoring
The manage quest, edit quest, and create quest event all deal with the authoring,
rather than the execution, of quests. The manage quest use case describes
functionality for managing different quests. The edit quest use case deals with the
editing of single quests, mainly adding, configuring, and connecting quest events.
The create quest event describes how the game programmer implements quest
events for use in the authoring of quests.
3.4 System design
3.4.1 It’s Alive’s game platform
It’s Alive’s game server platform is based on two components: the MRE and the
MCS. The MRE handles real-time game functionality and the MCS handles
persistent storage and other game features that benefit from enterprise
application server functionality. A web-based component called APEX allows
administrators to configure systems in the MRE and MCS (figure 3.4).
19
3.4.2 Quest system design
The design of the quest system follows the design of It’s Alive’s game platform
and consists of three components: the quest builder, the quest runtime, and the
quest bean. The quest builder is a web-based tool that the quest author uses to
create quests. The quest builder is integrated into the APEX administration tool of
It’s Alive’s game platform.
The quest runtime manages the quests’ interaction with the rest of the game,
keeps track of when conditions specified in quest events have been fulfilled, and
executes actions defined by quest events that affect other parts of the game. The
quest runtime is integrated in the MRE of It’s Alive’s game platform.
The quest bean stores the quests and keeps track of the quest event states in the
game, providing persistent storage and transaction integrity. The quest bean also
performs computations that can be isolated from the rest of the game and require
scalability. The quest bean is integrated as an Enterprise Java Bean in the MCS of
It’s Alive’s game platform.
WebFramework
MRE
MCS
CommandExecutor
Game Repository
Command
AttackGC
APEX
SayGC
QuestRuntime
QuestBuilder
QuestBean
Figure 3.4. The quest system is integrated into three different parts of the game. The arrows show which component
that initiates communication. The quest builder runtime receives notifications from commands but never initiates
communications with any existing command. However, the quest runtime does initiate communication with the
command executor component in the game when it needs to create and execute commands of its own.
3.4.3 Quest structure
A quest consists of a set of quest events and a directed graph structure, the
event graph, which determines the connections between the events. The event
graph can contain cycles but begins with a start event and ends with an end
event. All quest events, except the start and end events, are connected to quest
events that precede them and quest events that follow them. The start event has
no event that precedes it and the end event has no event that follows it.
20
Figure 3.5 shows the inheritance hierarchy of the quest events that are not start
or end events. Some events are connected to several preceding events and are
called link events. Others are connected to several following events and are called
split events. No event is connected to both several preceding and several
following events.
Some split events call for the quest system to execute their followers in parallel.
These events are called fork events. Other split events call for the quest system
to execute only one of several followers. These events are called branch events.
Some link events execute when all the preceding events that they are connected
to have completed. These events are called join events. Other link events execute
when one of the preceding events that they are connected to have completed.
These are called merge events.
QuestEvent
AbstractQuestEvent
void addChild(QuestEvent e)
void setChild(int i, QuestEvent e)
void removeChild(int i)
QuestEvent getChild(int i)
int getChildNum()
void addparent(QuestEvent e)
void setparent(int i, QuestEvent e)
void removeparent(int i)
QuestEvent getparent(int i)
int getparentNum()
StartEvent
SplitEvent
ForkEvent
EndEvent
LinkEvent
BranchEvent
MergeEvent
JoinEvent
Figure 3.5. The inheritance hierarchy of all the different quest event types.
3.4.4 Quest builder
The quest builder component lets quest authors manage and edit quests using a
web-based interface.
The user interface consists of a HTML document, the quest form, which the quest
author uses to manage quests and edit quests. The quest form contains a
graphical component, the event graph editor, which displays and lets the quest
author manipulate the quest structure. The user interface also includes a form
that allows the user to configure the quest events added to the quest. The quest
builder customises the configuration form for every quest event type.
The quest author uses the event graph editor to add quest events, remove quest
events, and connect quest events to each other. The event graph editor
communicates with the quest form, which in turn sends requests to a Java
21
servlet, a Java component running on the web server. The servlet processes the
requests and generates responses in the form of JSP documents (Java Server
Page). The web server transforms the JSP document into HTML document that it
sends to the web browser. Figures 3.6 and 3.7 describe the quest builder.
Web Browser
Web Server
HTML-document
QuestForm
JSP Engine
EventConfigForm
Java Servlet
Event Graph Editor
QuestBean
Quest
QuestEvent
JSP Configuration
Form
Figure 3.6. The web-based quest builder that the quest author uses to edit quests communicates with a Java servlet
on a web server that generates new JSP documents as the quest author reconfigures the quest.
QuestForm
EventConfigForm
QuestServlet
QuestBean
QuestAuthor
load()
getQuests()
getQuestEvents()
displayInitializedForm()
createQuest()
nameQuest()
addEvents()
moveEvents()
configureEvent()
submitQuestStructure()
getEventConfiguration()
displayConfigurationForm()
configure()
saveConfiguration()
saveConfiguration()
displayQuestForm()
connectEvents()
saveQuest()
submitQuestStructure()
deployQuest()
deployQuestName()
Figure 3.7. The sequence of a typical quest editing session. .
22
saveQuest()
deployQuestt()
3.4.5 Quest runtime
The quest runtime performs the actions defined in the quest events and handles
all interactions with the game platform.
Much of the functionality in the quest system requires that systems in the game
platform notify the quest system when certain game events occur. All
notifications from such external game systems are sent to the quest runtime
component of the quest system.
The classes in the quest runtime can be divided into a control and a data
partition. Figure 3.8 shows this division where the control partition is called the
quest manager and the data partition is called the quest entity.
Game Platform
Quest Entity
CommandExecutor
Action
Command
Quest
Quest Runtime
EventGraph
Quest Manager
QuestData
QuestEvent
QuestControl
Condition
NotificationFilter
CompletionCondition
StartCondition
Figure 3.8. The classes of the quest runtime and the division of the classes into a control partition, the quest
manager, and a data partition, the quest entity.
3.4.5.1 Interaction with external systems
The parts of the quest runtime that interact with game platform are the quest
control and the actions stored in quest events.
The actions actively commands the game platform to perform tasks, such as
changing properties or having computer-controlled characters take certain
actions, while the quest control passively listens for notifications of events that
occur in the game platform. The action class is located in the data partition of the
quest runtime because actions do not exercise control over the quest system and
because the implementations of the actions are custom-written for each game
that uses the quest system rather than a general part of the quest system.
The quest events register observers in the quest control when they are waiting
for certain conditions in the game platform to be fulfilled in order for the quest
23
events to complete. When programmers implement the quest events they also
add the functionality to notify the quest runtime when events occur in the game
platform that make the quest events complete. The quest control uses the
notifications it gets from the game platform to evaluate the conditions that the
quest events have registered in the game platform.
3.4.5.2 Internal operation
The quest control component iterates through all deployed quest and evaluates
whether their start conditions have been fulfilled. If a start condition has been
fulfilled a quest is prepared (instantiated) and customised to the current situation
in the game world.
The quest control then starts executing the quest events from the start of the
prepared quest’s event graph and continues until it reaches a quest event that
requires a notification in order to complete, this should happen fairly quickly in
most cases. When that happens, the quest control continues to iterate through
the deployed quests. If the quest system receives a notification that completes a
quest event, the quest control resumes execution of that quest.
Figure 3.9 describes the sequence that the quest c ontrol performs.
QuestControl
QuestBean
Quest
EventGraph
QuestEvent
Action
* getQuest()
retrieve()
canStart : = testStartCondition()
[canStart] prepare()
customise()
setNextQuestEvent()
[canStart] perform()
[noNextQuestEvent] :=
isNextEventSet()
[noNextQuestEvent] return
[noNextQuestEvent == false]
getNextQuestEvent()
retrieve()
customise()
executeAction()
execute()
notifyToComplete :=
testCompleteCondition()
[notifyToComplete] registerNotifier()
[notifyToComplete == false]
setNextQuestEvent()
Figure 3.9.The sequence that the quest control goes through to perform quests.
3.4.6 Quest bean
The quest bean component runs in an enterprise application server environment
that provides persistent storage, transaction integrity, and scalability. The quest
bean uses Enterprise Java Beans, code components meant to run on application
servers. The quest builder saves and deploys its quests to the quest bean, using
it as a storage device.
24
The quest runtime uses the quest bean to access the quest structure when
performing quests and to perform those actions that benefit from being executed
in an enterprise application server environment. The quest runtime also uses the
quest bean to keep track of quest data, such as customisation data and state
changes to quest events. Figure 3.10 shows the architecture of the quest bean
and its use of different Enterprise Java Bean types.
QuestBean
QuestRuntime
SessionBean
EntityBean
QuestBean
QuestDataBean
Figure 3.10. The quest runtime communicates with a session bean in the quest bean component. The session bean
uses an entity bean as persistent data storage for the quest.
3.5 Implementation process
3.5.1 Technologies, development environment, and
platform
The quest system was implemented using Java, JSP (Java Server Pages),
Macromedia Flash, and JavaScript. Java is a programming language from Sun
Microsystems that I used to create the quest runtime component and the serverside parts of the quest builder component. It’s Alive’s game platform is also
written in Java.
I used Tomcat from the Apache Foundation as my servlet container to serve JSP
pages to the user’s web browser in the quest builder. A Java servlet is a program
that implements an interface that allows it to be called by servlet containers to
generate web pages.
JSP is a technology that lets web authors mix Java code and HTML in a web page.
The JSP page is deployed to a servlet container that compiles the JSP page into a
servlet and executes the servlet when the user accesses the JSP page from his
web browser. The output from the servlet is transmitted to the users web
browser.
Macromedia Flash and JavaScript run in the web browser and add functionality to
web pages. Flash comes as a plug-in that needs to be installed in the web
browser, while JavaScript is currently included in most web browsers. Flash
movies are relatively self-contained objects that allow better handling of graphics
and multimedia on web pages while JavaScript allows better control of the web
browser. I used both JavaScript and Flash to create the quest builder client
component.
25
I used the NetBeans development environment from Sun to develop the Java and
JSP code. I considered both Borland JBuilder, which was the standard at It’s
Alive, and Eclipse, which I felt provided the best general code editing
functionality, but decided on NetBeans because it, comb ined with the RefactorIT
plug-in, offered the most attractive combination of support for JSP/Servlet
development and general code editing functionality.
I used the Tomcat servlet container included with NetBeans to run the quest
builder component and the Xerces XML-module from the Apache foundation to
handle XML with Java.
The available options for implementing the quest runtime were to make it totally
independent from It’s Alive’s game platform, to implement it in the full game
platform used to run existing games, or to implement it in a simpler test version
of the game platform supplied by It’s Alive.
I chose to implement the quest system in the simpler test version of the platform.
The test version’s system architecture was similar to the full game platform and
could execute game commands in a similar way to how it is done in the full game
platform, yet it did not use the full game platform’s complex enterprise computing
mechanisms.
I used the MySQL database to store quest data for both the quest builder and
quest runtime component.
3.5.2 Methodology
The goals for my project were to implement a system that would support the
Defeat Enemy For Money Mission scenario from the requirements specification
and to identify the programming interfaces needed by the game platform and
quest-specific functionality to interact with the quest system.
I used a process inspired by Extreme Programming where I first wrote a very
specific non-extensible system that supported just the functionality needed for a
simple quest scenario. I then refactored the implementation to make it more
general and to create interfaces between the core quest system and questspecific functionality. After each refactoring I tested the system with a simple
quest.
I repeated the specific implementation, refactoring, and testing steps with
increasingly complex versions of the system until I had an extensible system that
supported the scenario from the requirements specification.
Traces of the process are still found in the documentation for the QuestEventExec
class in appendix B. The class uses another class called QuestEventDesc that is
part of the quest system’s internal representation of quests. This class should and
can be refactored out of the QuestEventExec so the game developer who
implements quest events does not have to know about it.
3.5.3 Differences from the system design
Because I implemented the project on a test version of It’s Alive’s game platform,
I did not have to bother with Enterprise Java Beans. The persistent storage
functionality of the quest bean component is instead implemented using the
MySQL database while the scalability functionality and transaction integrity
functionality remain unimplemented.
26
I leave the division between quest runtime and quest bean in the design
specification because it may be useful for integrating the system in It’s Alive full
game platform.
My process of going from specific to more general implementations until I had a
system that fulfilled certain goals resulted in that the classes in the system design
that were not needed for my test scenario remain unimplemented. The whole
quest event class hierarchy from figure 3.5 and condition classes from figure 3.8
are not implemented.
I have chosen to leave them in the design too, because I think that building
general tool classes would be a great boost to productivity when implementing
quest events. Their inclusion in the design also guided the final refactoring steps
of the implementation when I generalised the system, as they became examples
of extensions that my system would have to support.
3.6 Test
3.6.1 Testing the implementation
In order to test the system I implemented the quest events needed to realise the
Defeat Enemy For Money Mission scenario from the requirements specification
and constructed the scenario in the quest builder (shown in figure 4.2).
The scenario contains five different quest event types where the simplest are the
start and end events that do nothing. The talk event makes a character talk to
the player and then immediately completes. It is used to advertise the quest to
the player, to instruct the player on what to do, and to reward the player with a
compliment. The question event waits until the player tells a character one of
several specified words and proceeds along one of two possible connections
depending on the word. The question events in this quest both wait for the player
to tell a character called GigaBot either “yes” or “no”. The quest also features a
kill event that waits for someone to attack and kill a specified character, in this
quest a character called MegaBot, before it proceeds.
It’s Alive’s test platform that ran the quest system allowed me to specify game
commands to be executed in the platform as command line parameters when the
platform was started. I specified the following command line parameters:
“SAY GigaBot yes”
“SCAN”
“SAY GigaBot yes”
“KILL MegaBot”
The SAY command makes the player’s character, called PlayerBot, talk to a
character called GigaBot and tell him “yes” twice, the first time to agree to being
told about the quest and the second time to agree to the mission. The KILL
command causes the PlayerBot to kill another character called MegaBot.
The SCAN command is included as a delay to get better looking output by
compensating for the test platform’s multi-threaded execution. That the test
platform uses multi-threading, causes the output sequence to differ from the
sequence in which commands are actually executed in the platform.
This is not a problem in the actual game since the narration of the quest enforces
serial execution. The player will usually not answer “yes” the second time before
27
he has actually been asked about whether he wants to perform the quest or not,
and the only consequence of doing so is that the comments are swapped (unless
the higher latency of the mobile phone networks allows all threads to finish
processing before the command arrives and corrects the sequence). Since this
was not an issue specific to the quest system, I chose to work around it by
inserting a scan command rather than to change the test platform.
The execution of the quest produced the following output:
OUTPUT: GigaBot -> PlayerBot: Got a quest for you mate,
interested?
OUTPUT: PlayerBot -> GigaBot: SAY GigaBot yes
OUTPUT: n/a -> PlayerBot: Scan Results
OUTPUT: GigaBot -> PlayerBot: MegaBot is feeling a big grumpy. Put
him out of his misery for me, will ya?
OUTPUT: PlayerBot -> GigaBot: SAY GigaBot yes
OUTPUT: n/a -> PlayerBot: Character “PlayerBot” kills Character
“MegaBot”
OUTPUT: GigaBot -> PlayerBot: Jolly good job, mate.
I also tested answering “no” instead of “yes” to GigaBot’s first question and got
the following output:
OUTPUT: GigaBot -> PlayerBot: Got a quest for you mate,
interested?
OUTPUT: PlayerBot -> GigaBot: SAY GigaBot no
OUTPUT: n/a -> PlayerBot: Scan Results
OUTPUT: GigaBot -> PlayerBot: So be it, coward!
OUTPUT: PlayerBot -> GigaBot: SAY GigaBot yes
OUTPUT: n/a -> PlayerBot: Character “PlayerBot” kills Character
“MegaBot”
Here, the negative answer to the question causes the quest to proceed to a talk
event where the player is insulted before the quest ends. The quest system
correctly ignores the player’s remaining commands, but the game platform still
performs them.
3.6.2 Testing the documentation
In order to test the documentation, a producer at It’s Alive used the
documentation to produce the slides that described the activities of the quest
system for my internal company presentation of the system.
The creation of the slides went fine, but caused me to append notes to the
Javadoc documentation of the QuestEventExec class to clarify that the
QuestEventDesc class is internal to the quest system and should be refactored
out of the classes exposed to quest event implementers.
28
4 Results
4.1 Implementation description
4.1.1 Deliverables and installation
The quest system implementation consists of two parts, a web module and a Java
archive. The web module is mainly used to run the quest builder and contains JSP
pages, a Flash movie, and Java classes. The Java archive contains the Java
classes that constitute the quest runtime and depend on some of the classes of
the web module.
The web module must be installed in the servlet container. The Java archive must
be included in the class path of the game platform, along with those classes from
the web module that the classes in the Java archive depend on. Both the web
module and the Java archive need access to the MySQL database.
4.1.2 Database model
The database model consists of the three tables shown in figure 4.1. The quest
table stores each quest’s name as a string, whether it is deployed or not in the
game, and its event graph data as XML. The name field is the primary key of the
quest table.
event_configurations
quest_name VARCHAR(100)
event_name VARCHAR(100)
event_type VARCHAR(100)
configuration_data TEXT
quests
event_types
name VARCHAR(100)
deployed TINYINT(1)
xml_data TEXT
name VARCHAR(100)
addable TINYINT(1)
configuration_class VARCHAR(100)
Figure 4.1. Shows the database tables used in the quest system. The underlined fields are the primary keys of the
tables.
The event_types table stores the name of each quest event type, whether the
quest author should be able to add the quest event to a quest or not, and the
name of the quest event type’s configuration class. The quest builder lists the
names of all addable event types when the quest author adds an event to the
quest.
The addable column exists to allow quest events to be disabled and to keep the
start and end events out of the list of events that the quest author can add. Each
quest only has one start and end event and they are added automatically when
the quest is created. The name column of the event type is the primary key of
the event_types table.
29
The event_configurations table stores the names of all the quest events that
have been added to every quest and associates them with their respective event
types and configurations. The primary key for the event_configurations table is
the union of the quest_name and event_name columns. The quest_name
column is a foreign key of the quests table’s name column. The event_name
column is a foreign key of the event_types table’s name column.
4.1.3 Quest builder implementation
The client of the quest builder component uses JSP, JavaScript, and Flash. JSP
generates all the web pages in the interface while JavaScript controls the web
browser and handles tasks like opening pop-up windows and passing
configuration data from one frame to another and to the server.
The event graph editor component is implemented in Flash and displays the
structure of a quest (figure 4.2) but also interacts with JavaScript methods when
the user configures one of the quest events, adds a quest event to the event
graph, or saves the quest.
4.2 The quest builder interface displaying the structure of the Defeat Enemy For Money scenario from the
requirements specification.
30
4.1.3.1 Pop-up windows
The quest builder uses a common JavaScript method to open pop-up windows
when the user creates a new quest, opens a quest, adds a quest event to a quest,
or configures a quest event. The method creates a pop-up window with two
frames where the top frame loads a document that depends on the functionality
of the pop-up while the bottom frame loads a document common to all pop-up
windows that contains the buttons “OK” and “Cancel”. Figure 4.3 shows a pop-up
window used to configure a quest event.
4.3 A pop-up window that shows the configuration of a quest event.
If the user presses the “Cancel” button on the bottom frame of the pop-up
window, the pop-up simply closes. If the user presses the “OK” button, a
JavaScript method calls the getSettingData method on the top frame to retrieve a
string that represents the data that the user entered in the pop-up. It then sends
the name of the JSP page loaded in the top frame and the retrieved string to the
server in the same operation as it reloads the event graph editor’s web page.
The server uses the top frame’s JSP page name to look up the appropriate Java
method on the server to handle the data from the getSettingData. The server
then passes the string returned by the top frame's getSettingData method to the
Java method. All pages meant to be loaded into the top frame of the pop-up
window must implement the getSettingData JavaScript method.
For instance, the JSP page “newquestframe.jsp” has a JavaScript method called
getSettingData that returns a user-specified quest name. On the server, the page
name “newquestframe.jsp” is associated with a Java method that accepts the
name of a quest as a string and creates a new quest with the name.
The documents loaded into the pop-up windows for creating quests, opening
quests, or adding quest events are all parts of the quest builder. When the user
31
configures a quest event, the server retrieves the document loaded in the top
frame from the specific quest event’s configuration class, which is created by the
game developer that implements the quest event and not a standard part of the
quest builder.
The JavaScript method that opens a pop-up window for configuring a quest event
sends the name of the quest event as an URL parameter in its call to load the top
frame of the pop-up window. This allows the server to look up the appropriate
configuration class for the quest event and to store the name of the quest event
in the user’s JSP session. The server retrieves the name of the currently
configured quest event from the JSP session when the user presses “OK” to save
the configuration data. Figure 4.4 describes the sequence of the quest builder.
The use of a JSP session relieves the user from the responsibility of passing the
quest event name both when opening the configuration window and when saving
the configuration data. However, it also has the consequence that the user must
only configure one quest event at a time.
WebBrowser
BottomFrame
TopFrame
Server
User
create new quest
open pop-up window
load into popup
load
load into popup
load
configure
press OK
getSettingData()
close pop-up window
reload event graph editor and send top frame URL
and setting data as GET parameters
lookup method
by top frame
URL
call method with
setting data
return event graph editor page with new settings
4.4 The sequence occurs when the user opens a pop-up window, in this case to create a new quest.
4.1.3.2 Interaction between Flash and JavaScript
Flash can call JavaScript methods by accessing URLs that use javascript as its
protocol component rather than the traditional http or ftp protocols. Instead of
accessing an URL like “http://www.abc.xyz”, Flash calls the JavaScript method
myMethod on the web page containing the Flash object by accessing the address
“javascript:myMethod();”.
Accessing Flash methods from JavaScript is more complicated since JavaScript
can only call certain predefined methods on Flash movies. Interaction from
32
JavaScript to Flash was needed to allow the save command on the web page
outside the Flash component to save the data in the Flash component.
Flash uses a movie metaphor with a timeline consisting of a number of frames to
control dynamic behaviours. Two methods that JavaScript can access on a Flash
movie are TCallFrame and TPlay. TCallFrame sets the movie’s position to a
specified frame in the movie’s timeline. TPlay plays the movie from the frame
where it is currently positioned, executing the behaviours defined on the following
frame.
In order to implement the save command I created a special Flash movie that lies
hidden in the event graph editor movie and saves the data in the event graph
when it plays a certain frame. The save command on the web page calls the
TCallFrame and TPlay methods on the hidden movie to make it play the frame.
4.1.3.3 Quest data flow
When the user opens or creates a quest, an XML representation of the quest is
stored in a JSP session. When the event graph editor is loaded it reads the XML
data from the JSP session and builds its own internal representation of the quest.
The graphical interface allows the user to edit the event graph editor’s internal
representation of the quest data.
When the user saves the quest or adds, configures, or removes quest events, the
event graph editor builds an XML representation of its internal representation of
the quest. It sends the XML representation to the server via JavaScript methods
on the web page where the event graph editor’s Flash component is embedded.
The event graph editor also sends along any changes it wants done to the quest,
such as adding or removing a quest event.
At the server, a Java class called EventGraphProcessor parses the XML data into a
data structure consisting of Java objects. The EventGraphProcessor performs the
event graph editor’s requested changes to the structure and translates the
structure back to XML. It then stores the XML in the database and the JSP session
from which the event graph editor reads the XML when its web page is reloaded.
The JavaScript method that submits the quest data and change requests from the
event graph editor submits it as URL parameters in the same call that reloads the
event graph editor.
The quest runtime also uses the EventGraphProcessor class to parse the XML
representations of the quests. The class also performs validation on the quests to
ensure that all the quest events are connected.
4.1.4 Quest runtime implementation
The sequence performed by the implementation of the quest runtime is very
similar to the design shown in figure 3.9. The main differences are that the data
about the quest is retrieved from a relational database rather than a quest bean
and that the event graph object is included in the quest object.
The current implementation of the quest runtime keeps one quest event, rather
than a queue of quest events, as the next quest events to be executed by the
quest engine. This is sufficient to run the scenario from the requirements
specification and any other quest that does not depend on parallel traversal of the
quest graph. A queue is necessary to implement fork functionality, where paths in
the quest graphs execute in parallel, but that would also raise the issue of how to
33
handle the multiple initialisations and executions of quest events that may occur
when parallel-executing paths merge or join.
One alternative is to specify that every quest event must be able to handle
multiple initia lisations and executions. The other alternative is to demand that a
special event, designed to handle multiple initialisations and executions, must be
used to merge or join parallel-executing paths. Such an event would allow the
rest of the events to expect to be initialised and executed only once. Validation
code could be added to the EventGraphProcessor class to enforce such a demand.
Developers can also get around the problem of parallel traversal by writing quest
events that handle several parallel tasks in each quest event. This may hinder reuse of quest events, but allowing a quest event to execute other quest events (or
a whole quest) could solve this problem.
The current implementation of the quest system neither demands nor limits any
of the alternatives, but the quest events that have been implemented to support
the test scenario were not written to support multiple initialisations.
4.1.5 Suggested improvements
4.1.5.1 General improvements
•
•
Add a mechanism to propagate data through a quest.
Add generalised game entity syntax.
The current implementation does not contain any standard mechanism to
propagate data between quest events in a quest. Such a mechanism can be
created, but might benefit from adding a method to QuestContext (appendix B)
that allows quest events to retrieve either the name, or even a data storage
structure, of the quest they are part of.
The quest events that were written to test this implementation of the quest
system allowed the quest author only to specify the names of specific characters
to be included in the quest. Future quest events could be written to allow the
author to specify more generalised descriptions of the characters, items,
locations, and other game entities.
Quest authors could specify an SQL query that locates appropriate game entities
in a database. The specific entities, chosen at runtime by the SQL query, could be
communicated through the quest using the data-propagation mechanism
specified above. This improvement would allow quests to be reused and adapted
to different player styles.
4.1.5.2 Improvements to the quest builder
•
•
•
•
Decide on a policy for the operation used to save a quest.
Improve interface constraints.
Add feedback on invalid user data.
Add a mechanism to deploy quests.
Currently the quest builder saves quests whenever the user adds, removes, or
configures quest events. The save button in the quest interface is only necessary
to save the quest after the user has connected several quest events with each
other.
The save button should either be removed or be made the only way to save the
quest. Removing the save button could easily be implemented by making the
34
event graph editor call its save functionality after the user connects quest events.
Making the save button the only way to save the quest would require the creation
of session-based storage that allows unfinished quests to persist among multiple
calls to the web interface.
Improving interface constraints would be to make the quest builder enforce
constraints such as only allowing one open pop-up window at a time and not
allowing the user to remove non-addable quest events from the event graph
when this breaks the quest (specifically, the start and end events).
The current implementation handles invalid data by silently discarding it, at best.
It would be better to provide feedback to the user.
The current implementation forces the user to edit a database table in order to
deploy a quest to the game. This should be integrated into the quest builder,
possibly with access restrictions that only allow authorised personnel to deploy
the quests.
4.1.5.3 Improvements for the quest runtime
•
•
Refactor the QuestEventDesc class out of the QuestEventExec interface.
Enable parallel execution of quest events.
The QuestExec interface described in appendix B uses a class called
QuestEventDesc. This class should be kept internal to the quest system and the
QuestEventExec interface should only have to return the indexes of the links that
the quest should proceed along when the quest event has completed.
The current implementation does not allow quest events to execute in parallel.
Several solutions are discussed in 4.1.4.
4.2 Quest system user guide
4.2.1 Overview
This guide contains information about using the system. It is intended for authors
that create quests and game developers that need to implement quest events.
4.2.2 Roles
The roles that interact with the quest system are players, authors, game
developers, and the game platform.
Players are the end-customers who play the game that uses the quest system.
Authors use the quest builder, the graphical tool for building quests, to create
quests by adding, configuring, and connecting quest events. Authors do not have
to be programmers. Game developers are programmers who implement the quest
events that the authors can add to their quests. The game platform is the rest of
the game outside the quest system.
4.2.3 Quests and quest events
A quest is a data structure that has a name that identifies the quest and an event
graph that arranges a set of quest events and their connections in a directed
graph structure. Authors create quests by first specifying a unique name for the
quest and then adding, configuring, and connecting quest events in the event
graph.
35
Game developers implement quest events that consist of an executable
component and a configuration. This separation allows quest events to be reused
several times in a quest, different quests, or even different games that use the
quest system.
While the quest has information about the names of the different quest events
and the way they are connected, it views the quest events as “black boxes” and
has no information about what each quest event does. A quest event, on the
other hand, only controls its own executable code and configuration, including
how many connections to other quest events it has, but knows nothing about the
other quest events in the event graph.
When authors add quest events to the event graph, the quest system names the
quest events to identify them. The names have to be unique for the quest and the
event graph, rather than each quest event’s configuration, stores the names of
the quest event. A database table links the names of the quest events in every
quest to their quest event types and configurations.
While quests store the connections between the quest events, the quest events’
configurations specify how many connections each quest event has to other quest
events. This allows the configuration to, during authoring of the quest, change
the number of connections for each quest event.
4.2.4 Authoring quests
Quest authoring starts by installing and running the quest builder. The quest
builder consists of a web module and a database. Appendix C specifies the SQLstatements that need to be executed during installation to create the database
tables. The web module is installed in a servlet container and the author accesses
the quest builder’s user interface by opening the JSP page “questbuilder.jsp” in a
web browser.
4.2.4.1 User interface
The quest builder web interface, as shown in figure 4.5, is divided into two
frames. The lower frame shows web links that allow the author to create quests,
open stored quests, and save quests. The upper frame loads the event graph
editor component when the author opens or creates a quest.
36
4.5. The user interface of the quest builder showing the pop-up menu that appears when the author holds down the
left mouse key over the blue square next to a quest event.
The author adds quest events to a quest by selecting the “Add Event” option from
a pop-up menu that appears when the holds down the left mouse button in the
event graph editor. The event graph editor gives each new quest event a unique
name in the quest. The event graph editor shows each quest event as a square
followed by the name of the quest event.
The author configures or removes quest events by selecting the appropriate
option from a pop-up menu that appears when the author holds down the left
mouse button over the square of the quest event.
4.2.4.2 How quests are saved
The user interface contains a save button, but adding or removing a quest event
or saving a quest event’s configuration also currently saves the quest. The save
button in the user interface need only be used when the author wants to save the
quest after connecting quest events.
37
4.2.5 Implementing a quest event
A quest event consists of two parts that need to be implemented by a game
developer: an executable and a configuration. The executable part of the quest
event is used by the quest runtime to execute the quest event in the live game
based on the parameters specified in the configuration.
The configuration is responsible for reporting the number of connections that the
quest event has to other quest event. It is also responsible for generating a
configuration web page to be shown in the quest builder and for translating the
configuration data returned by the web page into a format that can be used by
the executable part of the quest event.
The configuration web page must contain a JavaScript method called
getSettingData that returns a string with the configuration data. This string is
what the configurable part of the quest event needs to translate to the
executable.
Game developers implement the executable by implementing a Java interface
called QuestEventExec and implement a configuration by implementing a Java
interface called QuestEventConfig. Appendix B describes the interfaces.
4.2.5.1 Interacting with the quest system
When implementing the executable part of a quest event, the game developer
sometimes has to notify the quest system that a quest event has completed, or
send notifications from other parts of the game platform to the executable part of
the quest event. The game developer uses a class called QuestEventContext to
handle these two cases. Documentation for QuestEventContext is included in
Appendix B.
4.2.5.2 Deploying a quest event to the quest builder
In order to deploy a quest event to the quest builder, the game developer needs
to add an entry to the database table event_types containing the quest event’s
name and the name of its configuration class. The database entry must also
specify that the quest event should be addable, by setting the addable column to
1. The quest event’s configuration class must also be included in the class path of
the quest builder’s server-side component.
4.2.6 Running a quest
4.2.6.1 Deploying a quest
When the quest builder saves a quest it stores the name of the quest and its
event graph, represented as XML, in the database table quests. The table also
contains the deployed column that specifies whether the quest should be
deployed to the game or not (defaults to 0, or false). In order to run the quest in
the quest runtime on the test platform, the author must set the deployed
column of the quest to 1 (true). The deployed column allows the quest author to
keep unfinished quests in the database while still running the ones that are
finished.
4.2.6.2 Running a quest
In order to run a quest, the game platform must create an instance of the
QuestEngine class and call the startQuest method on the instance to specify
which quest to run. The game platform must also regularly call the questLoop
method on the QuestEngine instance to make it perform the quest.
38
The way quests are started will be specific to each game and the way the game
platform constructs the QuestEngine instance will be highly affected by the
integration of the quest system into the full game platform with its enterprise
application server functionality.
39
5 Conclusions
5.1 The selected method
While this thesis describes several problems with quest systems where human
authors, rather than a computer-controlled author, create quests, I think an
authoring tool was appropriate for It’s Alive’s game platform and the scope of the
project.
The use of a graphical authoring environment based on a simple graph structure
could hopefully help the quest authors and programmers predict unwanted
behaviours, such as some of the conflicts between story-level and code-level
systems detailed in chapter 2. Advanced behaviours will need to be programmed
as special quest events by game programmers who hopefully know more about
the workings of other affected code-level systems in the game than the typical
quest author.
While my original questions about how to support different player types and how
to add variation to the quests will have to be answered by the quest authors that
use the system, I also had use for the questions when designing the system. The
improvements I have suggested in section 4.1.5 discuss what the quest authors
and game developers could do to get re-usable quests that adapt to different
player types. The whole division between the quest builder and quest runtime
would even make it possible to replace the quest builder component with a
computer-controlled author.
There are many problems with computer-controlled quest authors though,
especially ones that hope to comp ete with human quest authors and will exist in
environments where clever players will try to exploit them to improve their
characters in the game.
Such a computer-controlled quest author would demand good artificial
intelligence both in applying its authoring principles and probably also from the
computer-controlled characters in the game world to achieve or portray character
motivations in the quests. It would also be difficult to test such a system in an
environment with hundreds or thousands of players.
These demands would have drastically increased the difficulty of (and reduced the
chance of) integration of the quest system with the It’s Alive’s full game platform.
I am satisfied with how my system has minimal requirements on the game
platform since game developers implement most of the interactions with the
game platform as they implement quest events.
5.2 Comments from It’s Alive
During the internal presentation at It’s Alive the programmers remarked that they
found the context-based architecture of the implementation of quest events to be
easily understood because it is also used by many other Java libraries.
The game producer who participated in the test of the documentation (see 3.6.2),
remarked that the work needed to integrate the quest system with the full game
platform was mainly of analytical, rather than implementation-intensive, nature.
40
6 References
Adams, E. (1999). Three Problems for Interactive Storytellers. Gamasutra. [www]
http://www.gamasutra.com/features/designers_notebook/19991229.htm
Last verified 2003-07-04
Allakhazam’s Magical Realm. (1999). [www]. Allakhazam.com, LLC.
http://everquest.allakhazam.com/ Last verified 2003-06-26
Anarchy Online. (2001). Funcom. [cd-rom] http://www.anarchy-online.com/
Last verified 2003-06-26
Bartle, R. (1996). Players who suit MUDs. Brandeis University [www]
http://www.brandeis.edu/pubs/jove/HTML/v1/bartle.html
Bates, B. (2001). Game Design: The Art & Business of Creating Games. Prima
Tech.
Build Notes v14.4.2. (2002). Funcom. [www]
http://www.anarchy-online.com/content/game/inproduction/live/old/14_4_2.html
Last verified 2003-06-26
ClickSaver. (2003). [www] http://a.chavasse.free.fr/ClickSaver/
Last verified 2003-06-26
Eladhari, M. (2002). Object Oriented Story Construction in Story Driven Computer
Games. [www] http://zerogame.interactiveinstitute.se/pdfs/OOSC-Eladharithesis.pdf
Last verified 2003-07-01
Evans, R. Barnet, T. (2002). GDC 2002: Social Activities: Implementing
Wittgenstein. [www]
http://www.gamasutra.com/features/20020424/evans_01.htm
Last verified 2003-06-25
Everquest. (1999). Sony Online Entertainment. [cd-rom]
http://everquest.station.sony.com/
Last verified 2003-06-26
Gilroy’s m59 Reference (2003). Gilcon. [www]
http://www.gilcon.net/meridian/faqs-get.asp?ID=77
Last verified 2003-07-03
Hallford, N. Hallford, L. (2001). Swords & Circuitry: A Designer’s Guide to
Computer Role-Playing Games. Prima Tech.
Fowler, M. (2000). UML Distilled. Addison-Wesley. Second Edition.
Journeyman’s Boots (2003). Allakhazam.com. [www]
http://everquest.allakhazam.com/db/quest.html?quest=28
Last verified 2003-07-01
Laurel, B (1993). Computers as Theatre. Addison-Wesley Publishing Company.
Klug, C. (2002). Implementing Stories in Massively Multiplayer Games. [www]
41
http://www.gamasutra.com/resource_guide/20020916/klug_01.htm
Last verified 2003-06-26
Kosak, D. (2002). Game Developers Conference 2002 Coverage: What’s This
World Coming To? The Future of Massively Multiplayer Games. Gamespy.
[www] http://www.gamespy.com/gdc2002/mmog/
Last verified 2003-07-07
Koster, R. (2000), Star Wars Galaxies Design Process. [www]
http://www.legendmud.org/raph/gaming/designprocess.html
Last verified 2003-07-09
McKee, R. (1997) Story. Methuen Publishing Limited.
Meridian 59. (1996) Near Death Studios. [cd-rom]
http://meridian59.neardeathstudios.com
Last verified 2003-07-03
Morrowind. (2002). Bethesda Softworks LLC. [cd-rom]
http://www.elderscrolls.com/index.php
Murray, J. (1997), Hamlet on the Holodeck. The MIT press.
O’Hara, K. (2003), Desired Rewards. [www]
http://forums.station.sony.com/swg/board/message?board.id=Developers&mess
age.id=1784&view=by_date_ascending&page=1
Last verified 2003-10-29
Propp, V. (1968), Morphology of the Folktale, University of Texas Press.
Reeves, B. Nass, C. (1996). The Media Equation. CLSI Publications.
Shadowbane. (2003), Ubisoft. [cd-rom] http://www.shadowbane.com/
Last verified 2003-07-03
Spector, W. (2000). Postmortem: Ion Storm’s Deus Ex. [www]
http://www.gamasutra.com/features/20001206/spector_01.htm
Last verified 2003-07-09
Spector, W. (1999). Remodeling RPGs for the New Millennium. [www]
http://www.gamasutra.com/features/19990115/spector_01.htm
Last verified 2003-06-27
Star Wars Galaxies (2003), SOE. [cd-rom] http://www.starwarsgalaxies.com/
Last verified 2003-10-20
Tozour, P. (2002). First-Person Shooter AI Architecture. AI Game Programming
Wisdom. Charles River Media.
Turkle, S. (1995). Life on the Screen. Touchstone.
Wrinn, G. I want my booties. (2001). Caster’s Realm. [www]
http://eq.crgaming.com/viewarticle.asp?Article=1015
Last verified 2003-07-01
42
7 Appendices
7.1 Appendix A: Use cases
7.1.1 Use case: Perform Quest
Actors: Quest System.
Description: The steps involved to perform a quest in the live game.
Entry condition:
1. The quest system detects that the entry conditions for a quest have been
fulfilled.
Flow of events:
2. The quest system customises the quest using the Customise Quest Data
use case.
3. The quest system traverses the quest’s event graph to its first quest
event.
4. The quest system executes the quest event using the Execute Quest Event
use case.
5. When the quest event has completed the quest system stores the stat e of
the quest in persistent storage using the Access Quest Data use case.
6. The quest system continues traversing the quest’s event graph according
to the connections between the quest events in the event graph and the
specifications of the current quest event. The quest system can traverse
the event graph in three different ways:
Linear. The quest event is only connected to one other quest event
and the traversal continues to that quest event.
Fork. The quest event is connected to several other quest events
and the traversal continues to all the other quest events in parallel.
Branch. The quest event is connected to several other quest events
and the traversal continues to one of the connected quest events,
the choice is based on conditions specified in the quest event.
7. The quest system detects whether the quest event is the final quest event
or returns to 4 if it is not.
Exit condition:
8. The quest system stores that the quest has completed in persistent
storage using the Access Quest Data use case.
7.1.2 Use case: Execute Quest Event
Actors: Quest System, Game Platform.
Description: The steps involved when performing an event of a quest in the live
game.
Entry condition:
1. The quest system arrives at the quest event while traversing a quest’s
event graph and detects that the conditions for executing the quest events
have been fulfilled. Three basic kinds of conditions exist:
Join. The current quest event will be ready to execute when all
previous quest events connected to the current quest event in the
event graph have completed.
43
-
-
Merge. The current quest event will be ready to execute when one
of several previous quest events in the event graph connected to
the current quest event have completed.
Linear. The quest event is ready to execute when the previous
quest event has completed.
Flow of events:
2. The quest system customises the action of the quest event using the
Customise Quest Data use case.
3. The quest system performs the actions of the quest event using the
Execute Action use case and observes the conditions that must be fulfilled
for completing the quest event.
Exit condition:
4. The game platform notifies the quest system using the Notify Quest
System use case when the conditions for completing the quest event have
been fulfilled. An alternative is that the quest system itself detects that the
conditions for completing the event has been fulfilled.
7.1.3 Use case: Execute Action
Actors: Quest System, Game Platform.
Description: The kind of actions that can be performed by quest events.
Flow of events:
1. The actions that a quest event can perform include:
The quest system commands a game entity in the game platform
to perform an action.
The quest system creates new game entities in the game platform.
The quest system changes the properties of a game entity in the
quest platform.
The quest system removes a game entity from the game.
7.1.4 Use case: Customise Quest Data
Actors: Quest System, Game Platform.
Description: What happens when the quest system customises quest data to the
current situation in the game world.
Entry condition:
1. The quest system retrieves any customisation data for the quest that
already exists in persistent storage using the Access Quest Data use case.
Flow of events:
2. The quest system customises the quest data based on the retrieved
customisation data and data from the game platform. Customisations that
the quest system can perform:
Turn a general description of a game entity into a specific game
entity that exists in the game platform.
Turn a general description of a change to a property into a specific
change to a property.
Turn a general description of a composite set of game entities and
properties into a specific set of game entities or properties or both.
Exit condition:
3. The quest system registers the customisation data in persistent storage
for the quest using the Access Quest Data use case.
44
7.1.5 Use case: Notify Quest System
Actors: Game Platform, Quest System.
Description: What happens when the game platform notifies the quest system of
the occurrence of a game event.
Entry condition:
1. The game platform notifies the quest system that a game event has
occurred.
Flow of events:
2. The quest system retrieves information about the game event from the
game platform and the notification. The quest system then determines
whether the notification matters to any of its quests. Game events that
the game platform should notify the quest system about include:
That a character game entity has been defeated.
That a character game entity has retrieved an item game entity.
That a character game entity talks to a c omputer-controlled
character game entity about a certain subject.
7.1.6 Use case: Access Quest Data
Actors: Quest System.
Description: The steps involved to access persistent data related to a quest.
Flow of events:
3. The quest system specifies a quest whose data should be accessed.
4. The quest system specifies which part of the quest data that should be
accessed.
5. The quest system either retrieves or stores the data.
7.1.7 Use case: Manage Quests.
Actors: Quest Author.
Description: The things that can happen when a quest author manages quests.
Flow of events:
1. The quest author can perform the following operations on quests:
Create quest.
Name quest.
Rename quest.
Open quest for editing.
Delete quest.
Save quest.
Deploy quest to game.
7.1.8 Use case: Edit Quest.
Actors: Quest Author.
Description: The things that can happen when a quest author edits quests.
Flow of events:
1. The quest author builds the event graph of the quest by performing the
following operations on the quest:
Add quest event.
Remove quest events.
Move quest events.
Connect quest events according to the connectivity of the quest
event types specified in the Perform Quest and Execute Quest
Event use cases. The quest event types correspond to the different
behaviour types from UML’s activity diagrams (Fowler 2000) and
consist of: activities, forks, branches, joins, and merges.
45
2. The quest author configures the individual quest events. The properties of
quest events that the quest author can configure include:
The name of the quest event.
The connectivity of branch, fork, merge, and join event types. That
is, how many branches that a branch event has etc.
Descriptions of game entities and other customisations for the
event’s game actions.
The conditions that must be fulfilled for a quest event to be
completed.
7.1.9 Use case: Create Quest Event.
Actors: Game Programmer.
Description: The things that happen when a game programmer implements a
quest event that the quest author can use.
Entry condition:
1. The game programmer creates a new quest event class of a specific type
and names the class.
Flow of events:
2. The game programmer implements actions that should be executed by the
quest event and implements a way for the quest system to customise the
quest event.
3. The game programmer implements a mechanism that allows the quest
author to configure the quest event.
4. The game programmer implements conditions for completing the quest
event and mechanisms for detecting when the quest event has completed.
Exit condition:
5. The game programmer stores the quest event in a way that allows it to be
added to quests by the quest author using the Edit Quest use case.
7.1.10 Use case: Visualize Quest Status.
Actors: Game Platform, Quest System.
Description: This use case is a specialisation of the Execute Action use case and
displays the quest status to the player.
Flow of events:
1. The quest system sets properties in the game platform that store
information about the quest progress in a way that can be accessed by the
game.
46
7.2 Appendix B: Javadoc
7.2.1 QuestEventExec
Package Class Tree Deprecated Index Help
PREV CLASS
NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
com.itsalive.matrix.quests
Interface QuestEventExec
All Known Implementing Classes:
LinearEventExec, QuestionExec
public interface QuestEventExec
Method Summary
void execute()
Called when the QuestEventExec should execute the actions related
to the quest event.
quests.QuestEventDesc[] getNextQuestEvents()
Called after this object has signaled that it has completed.
boolean hasCompleted()
This method will only be called once, directly after the execute
method has finished.
void initialize(QuestContext context,
quests.QuestEventDesc desc,
quests.QuestEventConfig config)
Called before the QuestEventExec instance is executed and sets basic
parameters that the QuestEventExec needs to interact with the quest
system.
void notify(java.lang.Object notificationKey,
java.lang.Object data)
This method allows the quest system to notify the quest event when
something has happened in the game platform.
Method Detail
initialize
public void initialize(QuestContext context,
quests.QuestEventDesc desc,
quests.QuestEventConfig config)
Called before the QuestEventExec instance is executed and sets basic parameters that the
QuestEventExec needs to interact with the quest system.
47
execute
public void execute()
Called when the QuestEventExec should execute the actions related to the quest event.
hasCompleted
public boolean hasCompleted()
This method will only be called once, directly after the execute method has finished. If this method
returns false at that time, it is the responsibility of this QuestEventExec to notify the quest system when
it has completed by calling the questEventHasCompleted method on its associated QuestContex object.
getNextQuestEvents
public quests.QuestEventDesc[] getNextQuestEvents()
Called after this object has signaled that it has completed. Should return the quest events that should be
executed.
notify
public void notify(java.lang.Object notificationKey,
java.lang.Object data)
This method allows the quest system to notify the quest event when something has happened in the
game platform. The quest event can register that it wants to observe notifications associated with
specific keys by calling the registerObserver method on the associated QuestContext.
Package Class Tree Deprecated Index Help
PREV CLASS
FRAMES
NEXT CLASS
SUMMARY: NESTED | FIELD | CONSTR | METHOD
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
48
7.2.2 QuestEventConfig
Package Class Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
quests
Interface QuestEventConfig
All Known Implementing Classes:
DefaultConfig, KillConfig, QuestionConfig, TalkEventConfig, UnconfigurableEventConfig
public interface QuestEventConfig
A class that holds the configuration for a quest event. The configuration may only change
when the setConfigurationData method is called.
Method Summary
java.lang.String getExecClassName ()
Gets the name of the class that provides runtime functionality for this quest event and
implements com.itsalive.matrix.quests.QuestEventExec.
int getLinkCount()
Returns the number of links that this quest event can have to other following quest
events in the event graph.
void setConfigurationData (java.lang.String dataString)
Sets the configuration data, as retrieved when the web interface calls the
getSettingData JavaScript-method on the configuration form written by the
writeConfigurationForm.
void writeConfigurationForm (javax.servlet.http.HttpServlet servlet,
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
Called when the user chooses to configure a quest event of the type related to this
QuestEventConfig.
Method Detail
writeConfigurationForm
public void writeConfigurationForm(javax.servlet.http.HttpServlet servlet,
javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws javax.servlet.ServletException,
java.io.IOException
Called when the user chooses to configure a quest event of the type related to this QuestEventConfig.
Throws:
javax.servlet.ServletException
java.io.IOException
setConfigurationData
49
public void setConfigurationData(java.lang.String dataString)
Sets the configuration data, as retrieved when the web interface calls the getSettingData JavaScriptmethod on the configuration form written by the writeConfigurationForm.
getLinkCount
public int getLinkCount()
Returns the number of links that this quest event can have to other following quest events in the event
graph.
getExecClassName
public java.lang.String getExecClassName()
Gets the name of the class that provides runtime functionality for this quest event and implements
com.itsalive.matrix.quests.QuestEventExec.
Package Class Tree Deprecated Index Help
PREV CLASS
NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
50
7.2.3 QuestContext
Package Class Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
NO FRAMES
All Classes
DETAIL: FIELD | CONSTR | METHOD
com.itsalive.matrix.quests
Class QuestContext
java.lang.Object
com.itsalive.matrix.quests.QuestContext
public class QuestContext
extends java.lang.Object
Constructor Summary
protected QuestContext(QuestEvent event, QuestEventExec exec)
Creates a new instance of QuestContext
Method Summary
static void notifyQuestSystem (java.lang.Object notificationId,
java.lang.Object data)
Called by parts of the game platform that wants to notify the quest system that an event
has occured.
void questEventHasCompleted()
Called by the QuestEventExec instance when the quest event has completed.
void registerObserver(java.lang.Object notificationId)
Called by the QuestEventExec instance to register an observer for a certain kind of
notification to the QuestEngine.
void removeObserver(java.lang.Object notificationId)
Called by the QuestEventExec instance to remove an observer that listens for a certain
kind of notifications to the QuestEngine.
protected setQuestEngine(QuestEngine engine)
static void
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString,
wait, wait, wait
Constructor Detail
QuestContext
protected QuestContext(QuestEvent event,
QuestEventExec exec)
Creates a new instance of QuestContext
51
Method Detail
setQuestEngine
protected static void setQuestEngine(QuestEngine engine)
notifyQuestSystem
public static void notifyQuestSystem(java.lang.Object notificationId,
java.lang.Object data)
Called by parts of the game platform that wants to notify the quest system that an event has occured.
questEventHasCompleted
public void questEventHasCompleted()
Called by the QuestEventExec instance when the quest event has completed.
registerObserver
public void registerObserver(java.lang.Object notificationId)
Called by the QuestEventExec instance to register an observer for a certain kind of notification to the
QuestEngine.
removeObserver
public void removeObserver(java.lang.Object notificationId)
Called by the QuestEventExec instance to remove an observer that listens for a certain kind of
notifications to the QuestEngine.
Package Class Tree Deprecated Index Help
PREV CLASS NEXT CLASS
FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD
DETAIL: FIELD | CONSTR | METHOD
52
NO FRAMES
All Classes
7.3 Appendix C: Database tables
# Host: localhost
# Database: quest_db
# Table: 'event_configurations'
#
CREATE TABLE `event_configurations` (
`quest_name` varchar(100) NOT NULL default '',
`event_name` varchar(100) NOT NULL default '',
`event_type` varchar(100) NOT NULL default '',
`configuration_data` text NOT NULL,
PRIMARY KEY (`quest_name`,`event_name`)
) TYPE=MyISAM;
# Host: localhost
# Database: quest_db
# Table: 'event_types'
#
CREATE TABLE `event_types` (
`name` varchar(100) NOT NULL default '',
`addable` tinyint(1) NOT NULL default '0',
`configuration_class` varchar(100) NOT NULL default '',
PRIMARY KEY (`name`)
) TYPE=MyISAM;
# Host: localhost
# Database: quest_db
# Table: 'quests'
#
CREATE TABLE `quests` (
`name` varchar(100) NOT NULL default '',
`deployed` tinyint(1) NOT NULL default '0',
`xml_data` text NOT NULL,
PRIMARY KEY (`name`)
) TYPE=MyISAM;
53