A Methodology for Requirements Analysis

of AI Architecture Authoring Tools

April Grow
1
, Swen Gaudl
2
, Paulo Gomes
1
, Michael Mateas
1
, Noah Wardrip-Fruin
1
1
Center for Games and Playable Media
University of California, Santa Cruz
Santa Cruz, CA, 95064
{agrow, pfontain, michaelm, nwf}
@soe.ucsc.edu
2
Department of Computer Science
University of Bath
BA2 7AY, Bath, UK
s.e.gaudl @bath.ac.uk
ABSTRACT
Authoring embodied, highly interactive virtual agents (IVAs) for
robust experiences is an extremely difficult task. Current
architectures for creating those agents are so complex that it takes
enormous amounts of effort to craft even short experiences, ith
lengthier, polished experiences (e.g., !acade, Ada and "race) often
re#uiring person$years of effort by expert authors. %oever, each
architecture is challenging in vastly different ays& it is impossible
to propose a universal authoring solution ithout being too general
to provide significant leverage. Instead, e present our analysis of
the System-Specific Step (''') in the IVA authoring process,
encapsulated in the case studies of three different architectures
tackling a simple scenario. (he case studies revealed distinctly
different behaviors by each team in their ''', resulting in the need
for different authoring solutions. )e iteratively proposed and
discussed each team*s ''' Components and potential authoring
support strategies to identify actionable softare improvements.
+ur expectation is that other teams can perform similar analyses of
their on systems* ''' and make authoring improvements here
they are most needed. !urther, our case$study approach provides a
methodology for detailed comparison of the authoring affordances
of different IVA architectures, providing a lens for understanding
the similarities, differences and tradeoffs beteen architectures.
Categories and Subject Descriptors
I.,.-- .Artificial Intelligence/0 1istributed Artificial Intelligence 2
intelligent agents, multiagent systems& 1.,.- .Software
Engineering/0 3e#uirements4'pecifications 2 elicitation methods,
methodologies.
General Terms
1esign, 'tandardi5ation.
Kewords
1esign, Agent Authoring, Interactive Virtual Agents, (ool$1riven
1evelopment, 6ehavior$+riented 1esign, A67
!" I#TR$D%CTI$#
Interactive Virtual Agents (IVAs) are embodied human characters
that richly respond to user interaction, combining ork in AI,
interfaces, sensing technology, and graphics, as ell as
interdisciplinary knoledge from fields as diverse as psychology
and theater. )e have begun to see the uses of IVAs manifest across
many fields, including medicine &8/, human care$giving .-,/,
education .-9/, interactive drama .-:/, and video games .-;, -</.
(here seem to be as many approaches to creating virtual embodied
agents as there are humans creating them, but the ma=ority of
approaches have one thing in common0 authoring.
+ur particular use of the overloaded term authoring encompasses
any asset creation and modification necessary to produce the
desired functionality of IVAs0 animation, audio, ritten dialogue,
as ell as behaviors, goals, and other more speciali5ed decision$
making constructs belonging to a custom decision$making
mechanism (1>>). Authoring for the 1>> adds another
dimension of complexity to the authorial burden of IVAs beyond
scripted scenes. (he combinatoric interaction possibilities,
including large internal (to the agent) and external state spaces,
makes it difficult for an author to reason about and modify a
1>>.
Authoring tools are often proposed as a means to help the author
manage this complexity. %oever, authoring tools, especially for
IVAs exhibiting complex behavior, are a research area of their
on. (o be of any practical use, authoring tools must be domain$
specific, system$specific, or customi5able enough to be tailored to
the authoring challenges of a specific 1>>& this fact is illustrated
by the lack of any cross$architecture tools for IVAs. (he choice to
invest time and energy in an authoring tool is a difficult one,
because it is challenging to determine if the cost of
creating4customi5ing a tool and training authors ould be less than
brute$forcing the authoring challenge ithout the tool.
(o better understand IVA authoring, e surveyed -- IVA authors
across : institutions and ? different pro=ects. )e then returned to
three teams for iterative intervies, here e discovered a similar
pattern of difficulty, hich e have decided to call the System-
Specific Step ('''). In the ''' lies the 1>>$dependent tangled
eb of architectural affordance and constraint in hich the author
painfully translates their high$level vision for the character into a
decision policy expressed in a specific architecture. )e returned to
the three teams ith our interpretation of their system*s ''',
confirming the re#uirements it places on any authoring tool
approach, together ith authoring tool proposals based on the
challenges discovered in the ''' to gauge their reactions.
(his paper proposes the ''' re#uirements analysis methodology as
a means by hich programmer$authors may better understand their
specific system*s authoring burden and potential features of
authoring tools hich ould alleviate this burden. !urther, our
approach to re#uirements analysis provides a methodology for
comparing multiple IVA architectures to better understand the
relative strengths and tradeoffs of different architectures, as ell as
the different authoring metaphors and behavioral idioms supported
by different architectures. )e report three case studies of IVA
architectures having different design philosophies, teams, and
levels of complexity as rigorous example test cases of our
methodology. +ur goal is to inform the creation of authoring tools
in similar architectures to enable the authoring of more robust
IVAs, to potentially identify common patterns of authoring
difficulty across architectures, and to provide a methodology for
more rigorous comparison of the strengths, eaknesses and
tradeoffs beteen different IVA architectures.
!"! Related 'or(
(he authors* are not aare of any other ork that documents and
analy5es the processes of different IVA authoring approaches over
a common scenario. In .--/, !ati>A and A67, to target
architectures of our case studies described belo, ere compared
regarding their expressiveness for modeling conflict beteen
characters. )hile related, this ork focused on the output of the
to architectures, rather than their authoring processes. Even
though the content matter of the tools as different, Felson and
>ateas* iterative case studies regarding video game design support
tools provided a compelling example for our IVA architecture
authoring analysis .-B/. )e ere able to build up a methodology
and test it ith our sub=ects through tight collaboration, hich e
feel as key to our success.
)e have implicitly narroed our definition of authors to
programmer$authors in this paper& the designers ith an authorial
vision ho have enough technical knoledge to build or use
complicated or technical authoring tools. )e ould like to support
less tech$savvy authors in the future, for hich the list of authoring
issues identified by 'pierling and '5ilas .,-/ also provides a useful
starting point. (he process of defining the ''' and tools
supporting it involved iterative discussions ith our intended
authors in order to Gmake tools that better match the concepts and
practices of .our/ media designers and content creatorsH .,-/.
+ne of the clearest cases of authoring tool effectiveness as
demonstrated by Farratoria, a tool suite that enables non$technical
experts familiar ith digital media to create interactive narratives
.,9/. Farratoria is comprised primarily of three separate tools0
story graph, script, and timeline editors all linked ith collective
underlying data structures. )hile the interaction ith the created
agents as minimal, the addition of the Farratoria tool suite to the
agent authoring process reduced the time spent authoring beteen
to similar pro=ects by half. Farratoria*s divide-and-conuer
approach to authoring tool design, creating each sub$tool ith
familiar vocabulary and tropes of its specific genre to better
support speciali5ed authors, informed our conceptuali5ation of the
'''.
AI@aint, a behavior tree authoring tool, gains its authoring poer
by limiting the behavioral domain to spatial reasoning .-/. In our
case studies, e focused on the authoring of social behavior, as
such behavior is characteristic of many IVA applications. 1ifferent
metaphors and conventions ill need to be supported for social
behavior than for the spatial behavior supported by AI@aint.
!inally, as AI research progresses, commercial AI systems in
games also evolve using techni#ues from research to empoer their
systems. !or example, as the needed complexity of game agents
exceeded that hich can be readily authored by finite state machine
approaches, behavior trees .A/ arose as one of the dominant
commercial approaches to structuring and controlling intelligent
agents in games. (o of the architectures examined in our case
studies make use of reactive planning, hich is closely related to
behavior trees.
)" T*E S+STE,-S.ECI/IC STE.
)e acknoledge as a first$class authoring challenge that each IVA
architecture comes ith its on design philosophy, coding style,
and data structures. )hile e can all share the idea of an authoring
burden, ho this burden manifests in each system can be entirely
uni#ue. In order to begin alleviating the authoring burden for each
system, e need to identify the peculiarities of the authoring
burden in specific instances.
(he 'ystem$'pecific 'tep is our term for the parts of the authoring
process here broad discussion ends and, as the name suggests,
system$specific design constructs are used instead. Any aspect of
authoring that is driven by the commitments of a specific
architecture, including design constructs and design philosophy, is
part of the ''' of that system. Examples of hat an author may
need to do as part of the ''' include0 imagining ho an agent ill
traverse the behavior representation so as to iteratively author
interesting decision points, constructing hierarchical goals so that
an agent can plan its ay from the beginning to end of the scenario,
and figuring out ho an agent can express frustration if its body is
busy doing other actions. Figure 1 shos a graphical
representation of the boundaries of the '''s using this paperI three
case studies as examples, including a fe of each systemIs uni#ue
primitives and tasks.
)"! T0e SSS Conception
)e conducted a series of informal intervies ith : institutions
across the globe to help understand ho different institutions
making use of different architectures approached their personal
IVA authoring challenges. In addition to the six local A67 authors
and the authors of this paper, e surveyed members of "AI@'
.-?/, CA1IA .,8/, and C(A( .,,/ to explore different approaches
and purposes for authoring, anecdotes of successes and failures of
particular authoring tools, and techni#ues for visuali5ation. +ur
findings helped us propose the idea of the 'ystem$'pecific 'tep to
capture the architecture$specific phases of the authoring process,
and led us to the methodology of using in$depth case studies to
inform the design of authoring tools.
/igure !" Illustrates t0e boundaries of an arc0itecture1s SSS
)") T0e SSS ,et0odolog
In order to find a specific system*s point of divergence from shared
authoring concepts, e needed to run the architecture through an
authoring exercise. !or this paper, e designed a simple scenario,
described belo, for intermediate$expert authors to transform into
descriptive pseudocode for their on system, one step removed
from actually programming the scenario. (hese intermediate$expert
authors ere accompanied by an analyst ho as not an expert in
the architecture, hich forced the intermediate$expert to elaborate
and make explicit every step of their authoring process.
(he authoring team then translated their ork into a rigorous
process map, here the analyst rote the map (confirming their
understanding) and the intermediate$expert validated and expanded
it as necessary. @rocess mapping involves creating a visual
representation of a procedure similar to a flo chart, making
explicit Gthe means by hich ork gets doneH .-8/. 1etails of each
step (and possible sub$steps) in the process ere recorded, such as
the duration of each step, other people involved, and possible
authoring bottlenecks. (he goal of this process map is to make as
much of the authoring process as explicit as possible for analysis.
In the folloing case studies, conclusions dran from the process
maps of each team are enumerated as SSS !omponents.
)e found this process not only helpful, but necessary to discover
actionable means by hich to improve the authoring experience for
the re#uirements analysis (as the Authoring 'upport 'trategies
sections of the case studies ill elaborate). It is important to note
that it may take multiple of these sessions ith the same author
(and possibly multiple process maps) to obtain the full authoring
process ith sufficient detail for analysis. !or example, one early
process map made ith an A67 author as very high$level,
focusing on the interconnection ith other teams and the bottleneck
this caused. (he analyst had to return to the A67 author for
another session aimed at creating a ne process map through the
expansion of a single node in the first process map.
2" T*E SCE#ARI$
(he scenario e chose is a simplified version of the G7ost
InterpreterH scenario recently completed and demoed by the
I>>E3'E group in A67 .,;/. It involves the player as an armed
soldier in an occupied territory searching for their lost interpreter
via a photograph in their possession. (he player must sho the
image to a cooperative local civilian, ho ill then recogni5e the
person in the photograph and point the player in the direction of the
interpreter. +nce the player knos the location, the scenario is
successfully completed. (he uncooperative civilian ill not
respond to the player*s pleas for help, and if the player is rude or
breaks social norms .?/, the F@Cs (Fon$@layer Characters) ill
leave and the scenario ill end unsuccessfully.
)e chose this scenario because it exercises a ide range of
capabilities of interactive characters0 player involvement, multiple
F@Cs ith different attitudes, a physical ob=ect, communication
beteen F@C and @C, and multiple outcomes. (he scenario as
also simple enough that each team as able to reach a pseudocode
state of completion in a reasonable amount of time (-$8 hours).
)hile the original I>>E3'E scenario re#uired non$verbal
communication via gesture recognition, e did not enforce that
modality on other systems. (he specifications of the scenario ere
designed to be loose enough to allo each system to encode the
scenario to their system*s advantages ithout demanding
extraneous features that all systems may not possess.
3" CASE ST%DIES
)e studied the folloing three programmer$author teams of one,
to, and five intervie participants respectively (although there are
more developers on each team). Each architecture made use of a
different design philosophy, hich ill become apparent in the
discussion of their individual '''. (he folloing case studies are
listed in order of increasing complexity of the architectures. Each
of the case studies provides a description of the authoring process
associated ith the architecture, a list of the ''' components
abstracted from the authoring description, and a description of
authoring support strategies that could reduce the authoring burden
of the particular '''.
3"! Case Stud !4 B$D using .$S*
6ryson et. al. ascribe to a particular behavior authoring
methodology entitled 6ehavior$+riented 1esign .:/, an approach
that combines +b=ect +riented 1esign and 6ehavior$6ased AI .9/.
6ryson et al. use 6+1 and their action selection mechanism, the
@+'% (@arallel$rooted, +rdered 'lip$stack %ierarchical) planner as
their architecture and development process because it focuses on
simplicity and iteration, offering a lo barrier to entry for novice
authors. (his case study encoded the 7ost Interpreter scenario in
the least amount of time.
After the scenario as defined, a programmer and designer orked
together to create a list of abstract behaviors that need to be
performed. It is important to note that the 6+1 designer (as
distinct from the programmer) ill never need to encounter
anything more complicated than graphical interfaces in their
authoring interactions, alloing the designer and programmer to be
the most independent of the three case studies (although they may
be the same person in some pro=ects). (he separation of these to
roles is part of the design philosophy of 6+1. In our case study the
abstract behavior list included seven actions0 a greeting4goodbye to
mark the beginning and end of the interaction, accepting,
examining, returning an item, ignoring the player (for the
uncooperative agent), and telling information. (he second step as
to build hat is ultimately a list of procedure signatures for the
programmer, determining hich of these behavior elements need to
be represented as actions and sensors, as ell as an idle state
should all else fail .</.
(he programmer then coded the actions and sensors as functions to
create the building blocks of the dynamic plan. In parallel, the
designer used the primitives (actions and sensors) created by the
programmer to design the behavior tree using A6+1EJ, a
graphical design tool for @+'% plans. Figure " shos the
6+14@+'% process map for the tasks of the designer and
programmer.
/igure )4 A 0ig0-le5el representation of B$D6.$S*1s process
map including some defined sample primiti5es
4.1.1 SSS !omponents
4.1.1.1 Start #inimally
Even though our scenario as relatively simple, it as important to
begin ith a minimal number of behaviors, actions, and sensors to
create a orking vertical slice. (he scenario began ith only four
primitives in the first version of the dynamic plan.
4.1.1." Decompose $teratively
A key feature of the 6+1 authoring methodology is its agility& not
only can programmers iteratively tackle the stubs created in the
previous Component, but the designer and programmers freely
move beteen phases of the design process to build up missing
primitives that ere not in the minimal first list. In our case study,
the programmer as creating idle and item$handling primitives
hile the designer reali5ed they had not accounted for the norm$
offense response.
4.1.1.% #inimi&e and 'ncapsulate
)hile not a part of this scenario, an experienced 6+14@+'%
designer knos that if more than three sensors are needed to trigger
a competence, the logic held ithin the tree is getting too complex.
(he designer should flag the programmer to offload the logic from
the tree onto a ne sensor, simplifying the logic (and thus
computational resources) controlled by the tree. Fot folloing this
rule of thumb is a common mistake most novice 6+14@+'%
authors make, resulting in a tangled mess of restricting sensors that
is difficult to debug and behavior libraries limited to a narro
subset of scenarios. (his last ''' Component is the most uni#ue,
as all behaviors (hich contain the ma=ority of the complexity) are
only triggered by the tree rather than contained ithin the tree.
4.1." Authoring Support Strategies
(he 6+14@+'% case study is uni#ue in that it is the only system
e studied ith an explicit authoring approach as ell as a
graphical design tool (A6+1EJ). (his makes it easy for novice
authors to create simple agents, but authoring and maintaining
complex agents creates challenges in need of more robust tools.
(hus, the focus of our authoring support strategies ill primarily
address ''' Component 9.-.-.8, as the first to are ell$
supported via the 6+1 methodology and the current architecture.
(here is no standardi5ed method for testing and debugging in
6+14@+'%, a problem that all the other architectures in this paper
also share. 'upport for syntax checking and live behavior
debugging ould shorten the programmer*s development cycle
considerably hile iterating on more challenging behaviors ('''
Component 9.-.-.,). >ost crucial, hoever, is a mechanism to
facilitate better behavior sharing and reuse beteen and ithin
pro=ects. (he larger a 6+14@+'% behavior library is, the more
likely that novice users tend to develop their on library instead of
reusing existing components. (he challenge ith three or more
sensors triggering a behavior, discussed above in ''' Component
9.-.-.8, is one example of an authoring lesson that needs to be
encoded in the graphical design tool to help authors build more
reusable behaviors. A ne module that manages past similar
encapsulated behavior libraries, and prompts users to submit their
ne simplified behaviors for future reuse, ould also increase the
reuse and poer of 6+1 and @+'% enormously.
3") Case Stud )4 /Ati,A
!Ati>A .B/ is a multiagent architecture in hich each agent has an
emotional state and plans future actions to achieve a specific goal.
"oals can be eighted according to their relative importance.
1ifferent characters can have separate personality files in hich
these eights are defined. Authoring in !Ati>A is done by editing
several separate K>7 files. )hen presented ith the re#uirements
of the the 7ost Interpreter scenario, !Ati>A authors started by
considering the motivations of the F@Cs. 'ince the behaviors of
agents in !Ati>A are goal driven, it as proposed that F@C*s in
this scenario must have the explicit goal of helping the player. A
possible example of such a goal is shon in !ode 1 ith the goal
(elp.
Additionally, there needed to be a motivation not to help, in order
to model the uncooperative F@CIs behavior. (he authors chose for
the uncooperative F@C to have the goal of avoiding harm from the
armed player (let it be called )rotectSelf). !or this second goal to
be useful, there must be an F@C action that is helpful to the player,
but at the same time might put it in harms ay. !or instance, the
F@C might consider the possibility of being harmed hen taking
the picture from the player. If the agent considers a plan involving
possibly being harmed, then it ill feel a !ear emotion. (he authors
then continued to define actions that the agents can take along the
path of reaching the help goal, such as actually taking the photo,
examining it, or speaking.
4.".1 SSS !omponents
)e ere lucky in this case study to consult ith a second !Ati>A
authoring team after iteratively discovering the ''' Components
ith the first team. (heir responses have been included in the
folloing sections alongside those of the first !Ati>A scenario
authoring team.
4.".1.1 Goals First
!Ati>A*s goal primitives must be defined first, ith the necessary
actions being derived from them. (his is driven by !Ati>A*s
dependence on goals for the cognitive appraisal emotion model to
ork. !or each branching strategy that the agent could take (e.g.
respond to re#uest or not respond), there needed to be a motivation,
hence a driving goal. (he second !Ati>A team orked ith goals
and actions simultaneously, hich as inconsistent ith the first
team. @art of the second team*s reasoning as that, ith the
appropriate set of actions, the agent should be able to deal ith a
ide range of situations, and thus goals. )e speculate this different
approach may be caused by the disparity beteen the author
experience and scenario complexity beteen the to teams (the
second team had more experience and a less demanding scenario).
4.".1." Find Decision )oints
)e noticed that the authors divided the scenario into sections
hose boundaries corresponded to moments in hich the civilians
had to make a decision. As every decision point must also be
motivated by a goal, it helped to author the previous '''
Component as ell. Authors also found that temporal ordering of
decisions could be enforced by creating goal preconditions that
referenced recent events. (he second !Ati>A team agreed ith
this analysis. (heir modeled scenarios ere re#uired to go through
se#uential phases, due to pedagogical ob=ectives. (hinking of the
decision point se#uences helped define their goals.
4.".1.% Goal *eighting and +uning
(he cooperative and uncooperative civilians in the scenario chose
to take different actions hen deciding to help by having different
numerical eights for the (elp and )rotectSelf goals. 6y giving
more importance to a particular goal in the character*s personality
file, the intervieed authors made sure each agent made the
appropriate decision at the decision points. It is these goal eights
that completely control ho different agents take different paths
throughout the performance, hich supports previous comments by
!Ati>A authors (including the second !Ati>A team) that eight
tuning is by far the most time$consuming process of complex
!Ati>A authoring .,/.
4.".1.4 $ntent Goals for Future !onseuences
)hile not part of this particular authoring scenario, e did
encounter a useful authoring anecdote that sparked discussion of
this additional !Ati>A '''. "oals have to types0 Active @ursuit
and Intent. !or Active @ursuit goals, the agent actually creates
plans to achieve them. Intent goals define constraints that the agent
should try to maintain as it pursues Active @ursuit goals. In the
process of researching .--/, "omes created to Active @ursuit
goals that an agent simultaneously tried to achieve. %oever,
"omes learned from an expert !Ati>A author that !Ati>A could
not handle more than one Active @ursuit goal at a time and had to
re$rite his entire goal structure. (he second !Ati>A team did not
agree that this as an important part of their process, as their
authors reported easily choosing beteen Active @ursuit and Intent
goals.
4."." Authoring Support Strategies
)e propose authoring support strategies for the to '''
Components that ere supported by both teams0 9.,.-., and
9.,.-.8. !or ''' Component 9.,.-.,, e proposed an interface
here authors could create example se#uences of events
schematically. Afterards, the tool ould prompt the user hen a
given agent as faced ith a decision. (he author ould then
create the corresponding goals (and possibly actions) that ould
motivate different strategies.
All three case studies have points in their authoring here #uick
iteration of different scenarios ould be incredibly helpful in
speeding up the authoring process. !Ati>A exhibits the most
obvious case, as all of its content ad=ustments can be narroed to
values in a fe specific files. (he authors speculated launching
multiple simultaneous configurations of a scenario ith !Ati>A
agents encoded ith different personality eights (possibly in real$
time), choosing the best version, and iteratively repeating to tune
the eights.
3"2 Case Stud 24 AB7
A67 as designed ith a focus on the creation of expressive IVAs
and provides a feature$full reactive planning language for
structuring and creating them ith a high degree of interactivity
.-A/. (he primary structure primitive in A67 is the behavior,
hich can subgoal other behaviors in se#uence or in parallel and
contains preconditions that gate hether or not it can currently be
executed. (he Active 6ehavior (ree (A6() encodes the current
intention structure of the agent, ith the leaves of the tree as
potential executable steps. )orking >emory Elements ()>Es)
hold information intended to be shared throughout the A6(, such
as hether an F@C is holding an item. It is important to note that
all the intervieed A67 sub=ects are involved ith the in$progress
I>>E3'E pro=ect& e ill take care to delineate A67 language$
specific and I>>E3'E pro=ect$specific constructions in this
section.
(he A67 authors approached the scenario by first creating a list of
abstract behaviors hich ere stubbed into the A6( in a rough
se#uential structure. At a high level, the authors each tackled a
specific behavior and orked iteratively ith each other to bring it
to completion. A67 authors thus also employ the ''' Components
9.-.-.- and 9.-.-., described above, and so they ill not be
restated. %oever, the details of the iterative steps for A67 hold
rich opportunities for further ''' Components.
Consider the example giveLob=ect() behavior for a character to
hand an ob=ect to another character0
(he behavior in !ode " illustrates the basic behavior structure that
authors of abstract behaviors must address0
+he conte,t of ho- the .ehavior -ill .e triggered0 in this
scenario, the author knos that giveLob=ect() ill be triggered in
response to a re#uestLob=ect() behavior or it ill be accepted
unconditionally. It contains no logic for having the offered ob=ect
re=ected. (his behavior also only handles removing the ob=ect from
the character*s hand, and assumes another behavior handles the
ob=ect*s fate.
/elevant signals and *#'s0 (he previous behavior as
authored assuming that the character@hysical)>E contains
locational information, that there is a social'ignal)>E ready to
handle socialInterpretationExtend%and, and that there are
constants such as the cExchange+b=ect1istance previously defined
and calibrated for the orld. If any of these are lacking, or the
author does not kno about them, the author must search the
existing code or create them.
',pected animations0 %ead tracking, eye ga5e, and holding out
the offered ob=ect are the animations used in this behavior. (he
logic behind procedurally animating them is handled elsehere, and
if it ere not, the author ould have to create it.
)ossi.le $nterruptions0 (he most challenging and crucial step
to making these behaviors robust is handling interruptions, hich
the above behavior fails to do. In the successLtest, if the F@C never
acknoledges the social'ignal or the player never comes in range,
the F@C ill hold their hand out forever. If a timeout as added to
holding out their hand, hat should the F@C do about the
unre#uited ob=ect offering, and ho should the lost
re#uestLob=ect() context be handledM (hese are all considerations
the author must address hen making behaviors robust.
4.%.1 SSS !omponents
4.%.1.1 Define !oding $dioms
Nnlike 6+14@+'% and !Ati>A, hich make strong architectural
commitments to specific agent authoring idioms, A67 is a more
general reactive planning language, ithin hich many different
idioms can be implemented. 6efore novice and intermediate
programmers can make progress, generally an expert A67
programmer must first define the coding idioms used to structure
the agent (see .,:/ for examples of A67 idioms). (hese idioms
define approaches for organi5ing clusters of behaviors to achieve
goals. !or the I>>E3'E pro=ect, an idiom called 'ocial
Interaction Nnits ('INs) has been developed to organi5e clusters of
behaviors around goals to achieve specific social interactions. (he
A67 authors intervieed all approached the G7ost InterpreterH task
using the 'IN idiom.
4.%.1." 0)! and )layer !onsiderations
Although e can see that the example behavior above, as ell as
the architecture, is separated from a particular implementation, the
code must intimately consider implementation details. (here is an
enormous amount of state information and A6( possibilities the
author must personally maintain regarding ho the behavior ill
be triggered in the performance, hether F@C or @C characters ill
be performing or responding to the behavior, and hat supportive
information must be stored in orking memory. 6+14@+'% and
!Ati>A offload much of this complexity into the actions
Table !4 A summar of SSS Components described t0roug0out t0e paper
'ection O Fame 'ummary 'ystems Authoring 'upport
9.-.-.- 'tart >inimally %aving a orking vertical slice early gives programmers
and designers a good overvie of the scenario structure
6+14
@+'%,
A67
Current A6+1EJ graphical design
tool is sufficient
9.-.-., 1ecompose
Iteratively
!illing in the stubs iteratively gives designers and
programmers freedom to ad=ust the structure ithout
getting in each otherIs ay
6+14
@+'%,
A67
Current A6+1EJ graphical design
tool is sufficient
9.-.-.8 >inimi5e and
Encapsulate
(he 6+14@+'% tree relies on simple logic to execute
#uickly, so complex sensory preconditions should be
offloaded to behaviors
6+14
@+'%
A module that manages encapsulated
behaviors, keeping them simple and
proposing them to ne authors
9.,.-.- "oals !irst (he agentIs actions are driven by goals, so there must
alays be a goal structure
!Ati>A Combined ith ''' Component
9.,.-.,
9.,.-., !ind 1ecision
@oints
Fecessary scenario$defined decision points make sub$
goals more apparent to author
!Ati>A 'cenario event se#uencing tool ith
prompts for goals and actions at
decision points
9.,.-.8 "oal )eighting
and (uning
AgentIs different behaviors are driven by different
eights, hich is a huge time sink to debug
!Ati>A @arallel execution and real$time
ad=ustment4comparison of values
9.,.-.9 Intent "oals for
!uture
Conse#uences
7anguage$specific limitations, such as only having one
active goal at a time, hinder novice$intermediate authors
!Ati>A 6etter documentation
9.8.-.- 1efine Coding
Idioms
As A67 is its on language, an author must have a
strong understanding of their chosen idioms
A67 (oo advanced for a tool to offer much
help
9.8.-., F@C and @layer
Considerations
An author must conceptuali5e roles, the contents of the
orking memory and A6(, and fine$grain performance
details hile building up their behaviors
A67 3evival of the A67 1ebugger through
modulari5ation0 offline code analysis
of behavior structures through idioms
9.8.-.8 Consider
Interruptions
Authors must try to robustify their behaviors against
interruptions and stalling, hich complicates the
previous ''' Element
A67 3evival of the A67 1ebugger through
modulari5ation0 offline code analysis
of behavior structures through idioms
implemented in the game engine, hile A67 keeps this complexity
ithin the decision$making process of the agent.
4.%.1.% !onsider $nterruptions
In the A67 scenario, if the system detects the player offering the
photo, it ill trigger the series of A67 behaviors by the
cooperative F@C0 takeLob=ect(photo), examineLob=ect(photo), and
pointLto(interpreter). If the system detects the player re#uesting the
photo back any time after examineLob=ect(photo), this ill trigger
the F@C to give back the photo regardless if it is in the middle of
another behavior such as pointing. !rom a designer*s perspective,
it is perfectly logical that someone may return the photo ith one
hand and point ith another. %oever, the author of pointLto()
must account for the fact that the behavior may have to multitask
ith other behaviors to dynamically decide hich hand to use. If
the synchroni5ation of those behaviors is not done properly, the
animation of the IVA ill contain artifacts hich are not appealing.
4.%." Authoring Support Strategies
)e discussed A67*s ''' ith novice, intermediate, and expert
authors of the A67 language, and their processes all shared the
same structure described in detail above. %oever, novices and
early intermediate authors needed to reference experts to
understand that the above considerations existed, and here to look
for them in the code or ho to create aspects of them if they ere
missing. +nce example behaviors have been created, authors
routinely copy$paste and adapt existing code. A67 meta$behaviors,
an advanced language feature, could help alleviate this process, but
they ere not utili5ed by any of our authors.
Fovice$intermediate A67 authors ork ithin previously
established idioms, such as I>>E3'E*s 'INs. >aking tools to
support the design of ne idioms in regard to ''' Component
9.8.-.- is not ithin the scope of this approach, as e have been
focusing primarily on novice$intermediate authoring tool support.
In contrast to the visual representation of 6+14@+'%*s dynamic
plan, the Active 6ehavior (ree (A6() in A67 is in a constant flux,
making it hard to visuali5e. Currently, A67 authors use debug log
print statements of the current system state and trial$and$error
experiments to understand A6( dynamics. 'upport for more
sophisticated debugging techni#ues does exist in the form of an
A67 debugger (a process that executes alongside an agent at
runtime), but none of the A67 authors choose to use it. (he current
A67 debugger contains too many usage barriers to ascertain if it is
technically useful in helping visuali5e ''' Components ix and x.
+ur current plan for overcoming these usage barriers include a
graphical A6( representation that allos for parallel vieing of
dis=oint parts of the tree, saving tree snapshots, and saving vieing
locations for repeated tests. )e also have plans to analy5e A67
code structure offline through an I1E plugin, and an A6( pattern
recognition algorithm to alert authors to missing behavior cases
(F@C vs. @C implementations), unused behaviors, and other
structural indicators e have yet to find.
8" DISC%SSI$#
(he ''' Components that arose from the simplest case study,
6+14@+'%, ere high$level authoring guidelines that apply to
multiple architectures. 'pecifically, all three of 6+14@+'%*s
Components apply to A67 as ell, as they are more characteristic
of a hierarchical planning structure than of 6+14@+'%
specifically. +ther ''' Components, such as !Ati>A*s Goals
First (iv), are guided by !Ati>A*s planning$oriented cognitive$
appraisal architecture that is driven by explicit goals. (he A67
case study provides a level of complexity above the other to&
A67 is a general reactive planning language here many authoring
idioms may be designed, as ell as the only architecture in the case
studies ith a behavior tree that dynamically changes during
runtime.
>any intervieees ere resistant to the idea of specifying
implementation time (in number of hours), as it varied greatly
beteen each task. )e also found that the particular shape or
contents of any single process map asn*t as relevant as the
process of elucidation and reflection. (he goal of the process
mapping techni#ue is to tease out hat is general and hat is
system$specific about a given architecture. (he system$specific
information forms the core of re#uirements analyses and the
actionable plans found therein. +a.le 1 shos a summary and
consolidation of each teamIs analystIs best attempt at discovering
system$specific patterns of frustration and proposing solutions to
alleviate the problems.
Although the ''' concept contains the phrase G'ystem$'pecificH
in its name, e found that certain ''' Components are shared
beteen different systems, revealing common architectural tropes.
%oever, e did find common medium$level authoring challenges
that may be of use to other teams by abstracting ''' Components
of the case studies0 the need for (better) mechanisms for behavior
(or other architecture construct) sharing and reuse, live debugging,
and template structures for architecture constructs. )e hope that
the ''' Components defined in this paper not only help other
architectures discover their on ''' Components, but that the
other architectures can reuse the ''' Components and the
corresponding authoring support strategies e have outlined.
9" C$#C7%SI$#S
(his paper has proposed the ''' re#uirements methodology as a
means by hich programmer$authors may better understand their
IVA architecture*s authoring burden and make progress toard
alleviating that burden. (he methodology as born of intervies
conducted ith many disparate and independent groups performing
IVA authoring research. )e then performed case studies of three
teams authoring a single simple scenario here e process$mapped
their authoring process, extracted and elaborated their ''' and its
Components, and proposed authoring strategies that might alleviate
their authoring burdens. (he three teams found the ''' to be a
valuable tool in analy5ing their system, and each group plans on
implementing support for their authoring strategies.
:" ACK#$'7EDGE,E#TS
In no particular order0 >artin van Velsen, C(A(, Claudio @edica,
CA1IA, 'amuel >ascarenhas, "AI@', Andre 'tern, 1an
'hapiro, the I>>E3'E team, the AmonI group, >egan @ycroft,
and Perry 6ruce
;" RE/ERE#CES
.-/ 6ecroft, 1., 6assett, Q., >e=Ra, A., 3ich, C., S 'idner, C. 7.
,;--. AI@aint0 A 'ketch$6ased 6ehavior (ree Authoring
(ool. In A$$D' 111.
.,/ 6ernardini, '., S @orayska$@omsta, P. (,;-8). @lanning$
6ased 'ocial @artners for Children ith Autism. In )roc. of
the +-enty +hird $nternational !onference on Automated
)lanning and Scheduling 2$!A)S-1%3.
.8/ 6ickmore, (., 6ukhari, 7., Vardoulakis, 7. @., @aasche$+rlo,
>., S 'hanahan, C. (,;-,). %ospital buddy0 A persistent
emotional support companion agent for hospital patients. In
$ntelligent 4irtual Agents (pp. 9?,$9?:). 'pringer 6erlin
%eidelberg.
.9/ 6rooks, 3. A. (-?B<). A robust layered control system for a
mobile robot. /o.otics and Automation, $''' 5ournal of,
"(-), -9$,8.
.:/ 6ryson, Q. Q. (,;;-). $ntelligence .y design6 principles of
modularity and coordination for engineering comple,
adaptive agents (1octoral dissertation, >assachusetts
Institute of (echnology).
.</ 6ryson, Q. Q., S 'tein, 7. A. (,;;-). >odularity and design in
reactive intelligence. In $nternational 5oint !onference on
Artificial $ntelligence (Vol. -A, Fo. -, pp. ---:$--,;).
>organ Paufmann.
.A/ Champandard, A. Q. (,;;8). A$ game development6 Synthetic
creatures -ith learning and reactive .ehaviors. Fe 3iders.
.B/ 1ias, Q., >ascarenhas, '., S @aiva, A. (,;--). !atima
modular0 (oards an agent architecture ith a generic
appraisal frameork. In )roceedings of the $nternational
*or7shop on Standards for 'motion #odeling.
.?/ Evans, 3ichard (forthcoming). Computer >odels of 'ocial
@ractices. In Vincent >uller (ed.), Synthese 8i.rary6
)hilosophy and +heory of Artificial $ntelligence. 'ynthese.
.-;/ "audl, '., 1avies, '. and 6ryson, Q. Q., ,;-8. 6ehaviour
oriented design for real$time$strategy games0 An approach on
iterative development for '(A3C3A!( AI. $n0 Foundations
of Digital Games !onference "91% 2FDG "91%3.
!oundations of 1igital "ames, pp. -?B$,;:.
.--/ "omes, @., S Qhala, A. (,;-8). AI Authoring for Virtual
Characters in Conflict. In 0inth Artificial $ntelligence and
$nteractive Digital 'ntertainment !onference.
.-,/ "ratch, Q., )ang, F., "erten, Q., !ast, E., S 1uffy, 3. (,;;A).
Creating rapport ith virtual agents. In $ntelligent 4irtual
Agents (pp. -,:$-8B). 'pringer 6erlin %eidelberg.
.-8/ >adison, 1. (,;;:). )rocess mapping, process
improvement, and process management6 a practical guide
for enhancing -or7 and information flo-. @aton
@rofessional.
.-9/ >ascarenhas, '. !., 'ilva, A., @aiva, A., Aylett, 3., Pistler, !.,
AndrT, E., ... S Pappas, A. (,;-8, >ay). (raveller0 an
intercultural training system ith intelligent agents. In
)roceedings of the "91% international conference on
Autonomous agents and multi-agent systems (pp. -8BA$
-8BB).
.-:/ >ateas, >. (-???). An :&-centric revie- of interactive
drama and .elieva.le agents (pp. ,?A$8,B). 'pringer 6erlin
%eidelberg.
.-</ >ateas, >. (,;;8). Expressive AI0 "ames and Artificial
Intelligence. In D$G/A !onf..
.-A/ >ateas, >., S 'tern, A. (,;;,). A behavior language for
story$based believable agents. $''' $ntelligent Systems,
1;(9), 8?$9A.
.-B/ Felson, >. Q., S >ateas, >. (,;;?, April). A re#uirements
analysis for videogame design support tools. In )roceedings
of the 4th $nternational !onference on Foundations of
Digital Games (pp. -8A$-99). AC>.
.-?/ A. @aiva. "AI@'0 Intelligent agents and synthetic characters,
,;-9. http044gaips.inesc$id.pt4gaips4
.,;/ 'hapiro, 1., >cCoy, Q., "ro, A., 'amuel, 6., 'tern, A.,
'anson, 3., ... S >ateas, >. (,;-8). Creating @layable
'ocial Experiences through )hole$6ody Interaction ith
Virtual Characters. In 0inth Artificial $ntelligence and
$nteractive Digital 'ntertainment !onference.
.,-/ 'pierling, N., S '5ilas, F. (,;;?). Authoring issues beyond
tools. In $nteractive Storytelling (pp. :;$<-). 'pringer 6erlin
%eidelberg.
.,,/ Carnegie >ellon Nniversity. C(A(0 Cognitive (utor
Authoring (ools, ,;-9. http044ctat.pact.cs.cmu.edu4
.,8/ 3eyk=avik Nniversity. CA1IA0 Center for Analysis and
1esign of Intelligent Agents, ,;-9. http044cadia.ru.is4
.,9/ Van Velsen, >. (,;;B). Farratoria, an Authoring 'uite for
1igital Interactive Farrative. In F8A$/S !onference (pp.
8?9$8?:).
.,:/ )eber, 6. "., >ahorter, @., >ateas, >., S Qhala, A. (,;-;).
3eactive planning idioms for multi$scale game AI. In
!omputational $ntelligence and Games 2!$G3, "919 $'''
Symposium on (pp. --:$-,,). IEEE.