Machine Learning

A learning module would much facilitate the authoring process, since explicitly modeling of behaviors would interrupt, complicate, and endanger the creative process. Optimization over a set of parameters, e.g. over a set of personality traits to create the emotions defined in the endorsed story set, is a very promising ap-proach, but limited to cases were such parameters are available and the model sufficiently covers the desired behaviors (e.g., the author might want a combina-tion of emocombina-tional reaccombina-tions that cannot be defined by the personality parameters).

Situation Description

Parameter 1 Parameter 2 .

. .

Parameter N GUI

Activate IF Parameter 2

Activate IF Parameter 5

Developing a learning module is a feasible task. Certainly, only knowledge-rich methods can be employed, since any statistical method requires a too large data-base of endorsed stories. The ideal authoring method would be achieved if the author only defines a limited set of typical stories, actions and reactions, and the system employs these typical cases as guidelines for controlling behavior during further interactions.

Figure 74 – The CBR-cycle applied to designing behaviors for virtual characters.

The most suited technology for behavior teaching of virtual characters is probably Case-Based Reasoning. Some storytelling systems have already started experi-ments on CBR, with adaptation of the story structure being in focus (cf. [Fair-cloughCunningham], [Swartjes]). In my view, CBR is promising in the storytelling domain because of the notion of “analogy”, which translates easily into “typicality”.

CBR is the technology that relies on the storage of concrete cases and of reusing them, with the help of adaptation algorithms and a similarity function, to find the

RETRIEVE

REUSE

REVISE RETAIN

Here, the designer can interactively design the behaviour

of the virtual character

The retained behaviour „solutions“

form the „repertoire“

of the virtual character Personality Model

The authoring system actively supports

those steps

most appropriate case out of the data base of cases. Cf. Figure 74 for a diagram of the CBR-cycle, adapted to virtual characters in IN. It is known for its appro-priateness to domains where the problem is badly describable and structured, as in IN (cf. [AamodtPlaza]).

Ideally, the author of a virtual character in IN would do nothing but define exem-plary cases, possibly assisting the system with some metadata that explain why he is choosing a particular behavior, employing GUI-based dialogues for this explana-tion. All of the knowledge of domain experts and of ad-hoc algorithms remains hidden in the similarity, adaptation, and storage functions.

The advantage of employing analogy over direct modeling lies (i) in the possibility of reusing structures that are not modeled, but that contribute to the desired effect, and to (ii) approximate the envisaged solution by increasing the data base of cas-es. In fact, the “set of endorsed stories” mentioned about maps directly into a set of successful cases, though it is not necessarily identical with the cases of the data base, which may for example also contain failure cases, i.e. cases that did not please the content creators.

Figure 75 exemplifies the advantage of reusing structures that are not modeled.

The content creator wants here Joel (cf. the application sketch of Section 7.2) to react angrily, when the player first speaks about a certain story person. The sys-tem reuses the peculiar facial expression that the author wants the syssys-tem to dis-play, in a similar situation, where the only difference is that player and Joel have become friends. But, according to the system’s adaptation rules, an angry expres-sion is not appropriate between friends, and thus removes the angry component of the face, but does not destroy the peculiarity of the intended expression.

Figure 75 – The left image depicts the face of Joel, as defined by the content creator. Joel shall show this expression in a situation where it is asked first about Idabel and the player has not yet acquired Joel’s friendship. The right side shows how the system can adapt the face by simply removing the “angriness” of the brows, employing generic adaptation rules.

The peculiarity of the facial expression remains visible, without explicit modeling of expres-sions like “astonishment” or “doubt”.

If natural language interaction is employed, integration with the CBR is a difficult task. The most promising approach consists in a combination of CBR and mod-eled solutions; the stored cases being the important exceptions to the regular be-havior that is modeled. Figure 77 shows this structure. Following McKee’s analy-sis, a story is composed of sequences of “beats”, i.e. of important events that de-scribe some change in story value; what is not important does not belong directly to the story.

Endorsed case in Case Data-Case: Joel displays a very particular facial expression that the content creator defines as being a form of

“anger”

Adapted case for a situation where anger is not appropriate: The brows were adapted, the wide opened eyes and irregular mouth were kept

Figure 76 – The production of a typical story involves correcting and enhancing the system, until it produces the desired story without violating stories that are already in the data base of endorsed sto-ries.

For example, chatting with the virtual character about the weather is normally not important for the story. Therefore, generic natural language and emotion modules can be employed. But speaking with it about his relationship to another important story person is important, and it may be essential to have the character (e.g. Joel, cf. above) react angrily when the theme comes to this person (e.g. Idabel). Thus, a set of important behavior patterns can overlay the base system of modeled beha-viors. The important cases can be added iteratively, until a sufficient approximation of the desired behavior is achieved. A specific feature of an approach that employs typical interactions as basis is then, apart from the adaptation of the cases, the faculty of “bringing the interaction back” to the typical course and to the important beats; e.g., a virtual character should bring a conversation on the weather back to the more important relationship to other story characters.

Figure 77 – The dramaturgically important interactions build normally only a thin surface, comparing to the whole body of possible interactions. The large part of the body can be generated by generic modules and algorithms, while the important surface requires, to a large extent, authoring efforts. The virtual actors must be able to bring a generic interaction back to the important dramatic layer. The surface layer can be approximated by adding CBR-cases to the system.

There is no need to restrict a CBR-case to a single instance of a story fragment.

Departing from the experiences acquired with Cyranus on the usefulness of em-ploying directed graphs to have control over precise reactions, it is sensible to al-low for the use of this formalism also in Creactor. Thus, a content creator should be able to define a case also in terms of bifurcations. Then, this specific CBR-case would function like a composite state of the Cyranus-framework, the main differ-ence being the possibility of adaptation, while the CBR-module represents a “Se-quencing Engine” of the framework.

Predicted and scripted, dramaturgically appropriate and seemingly deep

behavior

Generic, generated behavior patterns User behavior drives

system into less elaborated behavior

patterns

System tries to lead interaction back to elaborated surface

The way back to the surface is guided by improvisational

behaviors

Figure 78 – The major cycle of the adapting the framework includes the minor cycle of the content creator approximating the desired behavior of the virtual actors, without changing the framework it-self.

Figure 78 shows the resulting creation cycle of the approach, which involves com-puter scientists together with domain experts and content creators making deeper changes to the system in order to meet demands that emerged during the work of the content creator, and the minor cycle of the content creator who, through teach-ing, correctteach-ing, explaining and fine tunteach-ing, approximates the behavior that he has in mind, until it is sufficiently close to the intended result, or until the system is no longer capable of approximating the target, and entering into the major cycle be-comes necessary. The work represented within the square labeled with “Pro-gramming Task” is not clearly a cycle, but implies rather a constant dialogue be-tween the parties involved, and also joint work. An example of the production cycle of the content creator is depicted in Figure 76.