thesis2004-feb.dvi

全文

(1)平成年度. 卒業論文. インタラクティブドラマシステムにおける拡張 ÀÌÆ プランニング. 氏. 名：. 田中啓介. 学籍番号：. . 指導教員：.

(2)

(3) 助教授. 提出日：. 年月日. 立命館大学理工学部情報学科.

(4) 要旨. 我々は，次世代の双方向デジタルコンテンツであるインタラクティブドラマをコメディに着目して開発している．ストーリー性のあるプランを生成するために

(5) . をキャラクターエージェントのプランニング手法として取り入れた．さらに我々は，意図的なキャラクターエージェントの失敗を引き起こすための機能，視聴者とのインタラクション性の向上，ストーリーの多様性の増加といった課題を達成するために従来のを拡張した．本論文では，これらの拡張について述べ，拡張による効果をプランニングの実行例を検証して評価する．キーワードインタラクティブドラマング. 自律エージェントストーリー生成プランニ.

(6) 目次第章序論研究背景研究の目的論文の構成. . 第章研究の位置付け研究の必要性従来の研究解決すべき諸問題本研究の位置付け. . 第章提案手法従来の拡張 . . #.

(7)

(8) !"

(9) オペレータの複数候補. 第章評価従来のタスク分解と拡張におけるタスク分解の比較拡張によるプランニングの実行例考察. . 第章システムの実装に関して開発環境システムの構成. . 第章結論と今後の課題. . 第章謝辞. . $. .

(10) 図目次 . 従来のにおけるタスク分解の例従来のによるオペレータの例拡張によるオペレータの例拡張におけるタスク分解の例. $ $ % &. . 従来のにおいてオペレータの選択肢を増やしたタスク分解の例拡張においてオペレータの選択肢を複数の候補とした場合のタスク分解の例実行例のシーン実行例のシーン実行例のシーン実行例のシーン実行例のシーン実行例のシーン $ 実行例のシーンプランニングの全体的な流れ意図的に失敗させるために選んだオペレータ. . $ % # & . . $ % # & .

(11) 第章 . 序論. 研究背景. 次世代の新たな双方向デジタルコンテンツとして，インタラクティブドラマがある．インタラクティブドラマとは，視聴者とのインタラクションによって物語が動的に変化していくシステムである．このシステムではコンピュータによって仮想空間が構築され，その中では自律エージェントが役者となって物語が進められる．視聴者はドラマのキャラクターとして参加するか，三人称の視点から物語を視聴することが出来る．我々は独自のシステムを開発する上で，コメディとしてのインタラクティブドラマに着目した．そのためには，ユーモラスなエージェントのための新たなプランニング手法が必要となる．本研究はこのような要求を満たすために，インタラクティブドラマシステムのためのプランニング手法を提案するものである．. . 研究の目的. 我々は，ユーモラスなエージェントのためのプランニング手法を考案するにあたって，既存のシステムで使用されたり，あるいは他の研究において紹介されたプランニング手法に関するいくつかの問題点を明らかにした．つには，プランニングではストーリーのバリエーションを多くすることが困難であるということ．もう一つは，既存のシステムにおけるユーモアの創出が偶然性に頼ったものであるということである．本研究では，これらの問題点に対する解決法として，. ¯.

(12)

(13) !"

(14) . ¯ オペレータの複数候補を導入したプランニング手法である拡張. . を提案し，それに基づいてシステムを開発する．. 論文の構成. 本論文では，提案するプランニング手法に関する説明に加え，プランニングは未実装ではあるが開発の初期段階にあるインタラクティブドラマシステムについて説明する．本論文の構成を次に示す．. .

(15) 第章研究の位置付け解決すべき問題点を明らかにし，本研究の目的や有用性について述べる．第章. 提案手法に対して具体的にどのような拡張を行ったかを述べ，プランが生成される手順について説明する．. 第章評価既存のと拡張. を比較し，提案手法の有用性を検証する．. 第章システムの実装に関して本研究に関連するこことして，我々が開発しているシステムの実装に関して述べる．第章結論と今後の課題まとめとして結論を述べ，システムの開発を含めた研究の今後の課題について述べる．. .

(16) 第章 . 研究の位置付け. 研究の必要性. 我々はインタラクティブドラマシステムを，単なるドラマではなく '( のような台詞がなくても楽しめるようなビジュアルコメディとして開発することにした．そこで重要となるのは，役者となる自律エージェントがいかにユーモラスな行動を行えるか，という点である．したがって，視聴者の笑いを誘うような行動を取らせることができるようなプランニング手法が必要となる．. . 従来の研究. 従来行われてきたインタラクティブドラマの研究としては，)" *+ や ,

(17)

(18) - .

(19) /

(20) *+ 等があるが，これらはコメディに焦点を当てたものではない．笑いに着目した研究としては，視聴者とエージェントがユーモラスな会話漫才を行うシステム *+ があるが，これはその場の会話を楽しむものであり，ストーリー性のあるコメディではない．また，キャラクターエージェントの単純な失敗からユーモラスな場面を生み出すシステム *+ があるが，このシステムではキャラクターエージェントが失敗し得る行動を実行するということを許しているだけであり，意図的に失敗を生み出して笑いを誘うというものではない．このように，「ストーリー性がある」ということと「意図的に視聴者の笑いを誘おうとする」という点を兼ね備えたシステムは現時点ではまだないと言える．. . 解決すべき諸問題. ユーモラスなエージェントのためのプランニング手法を研究するにあたって，我々は *+ や .0 *$+ といったプランニング手法について調査をおこない，本研究ではストーリー性を保つことが容易だという特徴をもつをベースとしたプランニング手法について研究することにした．しかし，従来のをそのままインタラクティブドラマに適用するにあたっては問題もある．それは，前もって作成されたツリーを探索することでプランを生成するというの特性上，プランの多様性が乏しくなるということである．また我々は視聴者の笑いを誘発する方法として，前節で紹介した「失敗による笑い」を導入することにしたが，この方法ではユーモラスな場面の創出は偶然性に頼ったものになって. .

(21) しまうという問題がある．これらつが我々が開発するインタラクティブドラマシステムのエージェントに必要となるプランニング手法における解決すべき問題点である．. . 本研究の位置付け. 本研究では，前節で挙げた問題点の解決法として，従来の行う．. ¯. に対して次に示す拡張を.

(22)

(23) !"

(24) の導入. ¯ オペレータの複数候補の導入これらの拡張を導入したプランニング手法として「拡張. . 」を提案する．.

(25) 第章 . 提案手法. 従来の . 我々が提案するに対する拡張について述べる前に，従来のプランニングについて簡単に説明する．とは

(26) の略であり，その名のとおり階層化されたタスクのツリーを用いてプランニングを行うものである．具体的には，あるタスク，例えば 1 を手に入れるという処理を表したというタスクを「交換する」や「買う

(27) 」といった複数のより細かいサブタスクに分解していく．これらのサブタスクは，いずれかの子ノードが実行されれば解決される「23 ノード」や，順番に全て実行されれば解決される「4 5 ノード」のどちらかのタイプの子ノードとして分解される．このような分解を繰り返し，直接実行可能なプリミティブタスクとなるまで分解していく．その結果，前述した例の場合を根とした木ツリーが出来上がる．つまり，プリミティブタスクは木構造における葉ノードあるいは終端ノードとなっており，各プリミティブタスクはオペレータと一対一で対応している．なお，プリミティブタスク以外の中間ノードをメソッドと呼ぶ．ツリーの例を図に示す．なお，インタラクティブドラマにおいてはこのツリーはプランニングに際して前もって作成される．実際のプランニングはこのツリーを探索することで行われ，探索の過程で到達した葉ノードつまりオペレータの系列が最終的なプランとなる．各オペレータは前提条件，追加リスト，削除リスト 5

(28) 6

(29) から成り，図のように記述される．探索の過程であるオペレータが実行可能かどうかは前提条件をチェックすることで判定されるが，前提条件が満たされなかった場合，バックトラックすることで別のノードが探索されるリプランニング．実行不可と判定されたノードが 23 ノードの子であれば共通の親ノードを持つ別の子ノードが探索される．4 5 ノードであった場合は，共通の親を持つ一連のノードは失敗と見なされるので，一つ上の階層において同様の探索が行われる．このをインタラクティブドラマエージェントのプランニング手法として用いれば，ストーリーの流れを前もって決められるため視聴者が見ても違和感のないようにストーリー性を保つことが容易である．我々はこの利点に注目し，キャラクターエージェントのプランニングにを用いることにした．. .

(30) get(X). exchange steal. from a shop owner. from a kid pick(X). meet(owner). exchange(car, X). catch(kid). get_out_of_the_shop(). exchange(toy, X) buy. get money. move(ATM). 図. stand_in_the_line(). trade. withdraw(cost(X)）. pick(X). 7 従来のにおけるタスク分解の例. Operator: pick(X) Preconditions: available(X) Delete List: available(X) Add List: in_hand(X). 図. Operator: pay(X) Preconditions: in_hand(X) money(cost(X)) Delete List: money(cost(X)) Add List: own(X). 7 従来のによるオペレータの例. $. pay(X).

(31) . 拡張 . に対して行った拡張は以下の点である．

(32)

(33) !"

(34) の導入. 我々が従来の. ¯. ¯ オペレータの複数候補の導入.

(35)

(36) !"

(37) は，.3,0. タイプのオペレータに見られる前提条件 0"/

(38) のようなもので，オペレータの実行時にその成功8失敗を判定するための条件である．この拡張によって，結果的に失敗となるようなオペレータの実行を可能にし，失敗によって生じるユーモラスな場面を得られることが期待できる．また，視聴者が環境に対して操作を行うことでオペレータの失敗を誘うといったことができるようになる．オペレータの複数候補は，同じ条件下で実行され，かつ同じ実行結果となる複数の異なるオペレータをひとまとめにするというものである．この拡張により，あるプリミティブタスクにおける行動のバリエーションを増やすことができる．. .

(39) . 我々は，キャラクターエージェントがユーモラスな場面を作るための手段として，そのエージェントにある行動を失敗させるという方法をとることにした．本来，プランニングというのはあるゴール状態を達成するための解となるオペレータの系列を求めて，より効率良く作業を「成功」させるための手法である．しかし，本研究におけるエージェントは必ずしもゴールを達成しなくても良い上に，わざと失敗をさせてリプランニングさせるという「非効率的」なプランの生成を行う．プランニングというものの性質上，ゴール状態は設定され，それに基づいてプランニングが行われるが，より効率的なプランではなく実行の過程でよりユーモラスな場面を作り出すようなプランを生成するようにプランニングが行われる．そこで，意図的に失敗をするようなプランを生成するために必要となるような拡張が /

(40)

(41) !"

(42) である．

(43)

(44) !"

(45) は，オペレータの実行時に成功8失敗を判定するための条件である．すでに .0

(46) . 0 のオペレータにおいて適用されているが *+，本研究ではこれをにおいて用いている．， .0 は両者とも .3,0. スタイルのオペレータを用いており，つのオペレータは前提条件 0"

(47) ，追加リスト 4""

(48) ，削除リスト 5

(49)

(50) からなる．我々のに対する拡張では，これらに加えて

(51)

(52) !"

(53) が加えられる．その性質上，前提条件と

(54)

(55) !"

(56) は混同され易いが実際には異なるものである．

(57)

(58) !"

(59) を追加したオペレータを図に示す． .3,0. スタイルのオペレータにおける前提条件は，複数あるオペレータの中から条件に合うオペレータを選ぶために用いられる．そのため，前提条件が満たされなければ実行さえされないが，一旦実行されれば必ず追加リストや削除リストの内容が適用される．言い換えれば，前提条件さえ満たせば必ず成功するという仮定の下で実行されるということである．. .

(60) Operator: pick(X) Preconditions: available(X) Executability Conditions:. Operator: pay(X) Preconditions: in_hand(X) money(cost(X)) Executability Conditions:. Delete List: available(X) Add List: in_hand(X). Delete List: money(cost(X)) Add List: own(X). Operator: pick_secretly(X) Preconditions: available(X) Executability Conditions: not someone_aware_of(X) Delete List: available(X) Add List: in_hand(X). 図. Operator: pay_in_a_hurry(X) Preconditions: in_hand(X) money(cost(X)) Executability Conditions: exist(clerk) not in_line Delete List: money(cost(X)) Add List: own(X). 7 拡張によるオペレータの例. %.

(61) 一方

(62)

(63) !"

(64) は，前提条件がチェックされてオペレータに対応する行動が実際に実行された時に初めてチェックされる．条件が満たされれば実行が成功したと見なされ，追加リスト 4""

(65) と削除リスト 5

(66)

(67) の内容が適用される．条件が満たされなければ実行失敗と見なされ，追加リストと削除リストは適用されない．つまり結果が成功か失敗かに関わらず，前提条件さえ満たされれば実行が「試みられる」ということである．オペレータがこの

(68)

(69) !"

(70) を持つことによって，プランナーは，予測されない割り込みがない場合にそのオペレータが失敗するかどうかということをを事前に知ることができる．つまり，環境モデル仮想空間の状態と

(71)

(72) !"

(73) を照合して相違があれば，実行までに環境が変化しない限りそのオペレータは実行時に失敗すると見なすことができるわけである．この機能によって，失敗する行動を意図的にエージェントに実行させることでユーモラスな場面を作り出すことができる．また，視聴者とのインタラクションという観点から見ても，

(74)

(75) !"

(76) は有用である．前述したように，視聴者はドラマが展開する仮想空間内のオブジェクトなどを操作することが出来る．したがって，たとえ成功させるために選択されたオペレータであっても，視聴者とのインタラクションによって失敗させることもできる．これによって，ユーモラスな場面を作り出すために視聴者がキャラクターの邪魔をして失敗を誘うといったことも可能となるわけである．. . オペレータの複数候補. オペレータの複数候補とは，つのプリミティブタスクすなわちツリーの終端ノードにおいて複数のオペレータを候補として持たせるというものである．インタラクティブドラマの特徴として毎回見るたびに別のストーリーが見られるというものがあるが，を用いた場合ストーリーの大まかな流れはツリーによって決まってしまうため，前回と同じようにツリーが探索されれば全く同じオペレータ系列が得られてしまうということもあり得る．言い換えれば，インタラクティブドラマにおいては例え同じ結果となる行動でもいくつかの多様な行動を選択肢として持ちたい場合があるわけである．特にコメディに焦点を当てた場合，ある場面で以外な行動をとることができるかどうかが，笑いにつながる要素として重要となる．で述べたように，をインタラクティブドラマに用いる利点は，一貫性のあるストーリーとなるように前もってその流れを決められるということにある．この特徴を残したままストーリーの多様性を向上するための拡張が，の終端ノードの階層において行動オペレータの選択肢を増やすことのできる「オペレータの複数候補」である．従来の. ではつのプリミティブタスクにはつのオペレータが対応していた．オペ #.

(77) レータの複数候補による拡張では，つのプリミティブタスクつまり終端ノードには複数のオペレータが存在する．これらのオペレータは単純にどのようなものでも良いというわけではなく，同じプリミティブタスク内にある各オペレータは，同じ条件下で実行されかつ同じ実行結果となるオペレータでなければならないと規定した．具体的には，前提条件 0"

(78) と追加リスト 4""

(79) ・削除リスト 5

(80)

(81) が他の候補オペレータと同一でなければならない．その代わり，

(82)

(83) !"

(84) とオペレータに対応する具体的な行動方法は同一でなくても良い．複数の候補オペレータを持ったプリミティブタスクを含む拡張のツリーは図のようになる．. get(X). exchange. from a shop owner. •meet(owner) •call(owner) •call_loudly(owner). steal. from a kid. •exchange(old_teddy, X) •exchange(car, X) •exchange(a_few_money, X). •catch(kid) •catch_by_force(kid) •call(kid) •call_loudly(kid). •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). •exchange(old_teddy, X) •exchange(car, X) •exchange(a_few_money, X). •get_out_of_the_shop() •get_out_of_the_shop_quickly(). buy. trade. get money. •move(ATM) •move_in_a_hurry(ATM) •move_slowly(ATM) •move_secretly(ATM). 図. •stand_in_the_line_and_wait() •pass_a_person_and_wait() •get_ahead_of_the_line(). •withdraw(cost(X)) •withdraw_in_a_hurry(cost(X)) •withdraw_slowly(cost(X)). •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). •pay(X) •pay_in_a_hurry(X) •pay_slowly(X) •pay_roughly(X). 7 拡張におけるタスク分解の例. プランニングにおいて探索がプリミティブタスクに達した時，まず前提条件がチェックされる．条件が満たされれば，いずれも前提条件・実行結果が同じであるため，そのプリミティブタスクにある全ての候補オペレータが平等に選択可能となる．プランニングの際は事前に

(85)

(86) !"

(87) が参照され，失敗する行動かどうか等の情報に基づいていずれかのオペレータが選択される．実行時に

(88)

(89) !"

(90) が満たされないといった原因でオペレータの実行が失敗した場合リプランニングが行われるが，単純に従来のにおけるバックトラックは行われない．そのプリミティブタスクに他の候補オペレータがある場合，いずれかのオペレータが代わりに選択される．言い換えれば，別の方法を試みようとする．同じプリミティブタス. &.

(91) ク内でも

(92)

(93) !"

(94) が異なるので同じ原因によって失敗することはない．したがって，異なる

(95)

(96) !"

(97) のおかげで成功するかもしれないし，別の原因でまた失敗するかもしれない．なお，すべての候補が失敗したり，失敗の回数が設定された閾値に達すると従来のと同様のバックトラックが行われる．. .

(98) 第章 . 評価. 従来のタスク分解と拡張におけるタスク分解の比較. 従来のスクは，. において，例えばお金を得るという行動を意味する.

(99) というサブタ. 4' に移動する待ち行列に並ぶお金を引き出すといったプロセスに分解できる．これらをそのままプリミティブタスクとしてオペレータを対応させることもできるが，拡張との比較のためにこれらの各プロセスにおいて複数の選択肢を用意することを考える．従来ので複数の選択肢を用意するには 23 ノードが用いられる．具体的には図のようになる．4 5 ノードである

(100) を，，，というサブタスクメソッドに分解し，これらを 23 ノードとする．つの各ノードについて選択肢となる複数のプリミティブタスクへの分解を行う．こうすることで，，，それぞれについて複数の選択肢となるプリミティブタスクを用意することが出来るが，図を見て分かるように選択肢となる各ノードは独立したノードとなっているため，つのオペレータを選択するために全ての選択肢の前提条件，追加リスト，削除リストを参照しなければならない．このため処理の上でも非効率的であるし，ツリーの管理が煩雑になってしまう．一方，同じタスクを拡張において分解すると図のようになる．

(101) は直接つのプリミティブタスクへと分解され，各プリミティブタスクには候補となる複数のオペレータがひとまとまりとなって用意される．図を見るだけでも簡潔な記述だということが容易に分かるが，実際にプランニングの際も，同じプリミティブタスク内のオペレータであれば区別せずに扱えるため，管理が容易である．. .

(102) get money. withdraw. wait withdraw(cost(X)). withdraw_in_a_hurry(cost(X)). withdraw_slowly(cost(X)). move stand_in_the_line_and_wait(). move(ATM). move_in_a_hurry(ATM). 図. move_slowly(ATM). pass_a_person_and_wait(). get_ahead_of_the_line(). move_secretly(ATM). 7 従来のにおいてオペレータの選択肢を増やしたタスク分解の例. get money. •move(ATM) •move_in_a_hurry(ATM) •move_slowly(ATM) •move_secretly(ATM). 図. •stand_in_the_line_and_wait() •pass_a_person_and_wait() •get_ahead_of_the_line(). •withdraw(cost(X)) •withdraw_in_a_hurry(cost(X)) •withdraw_slowly(cost(X)). 7 拡張においてオペレータの選択肢を複数の候補とした場合のタスク分解の例. .

(103) . 拡張によるプランニングの実行例. 以下に我々が拡張したプランナーが生成するプランとその実行による典型的な結果を示す．この簡単なストーリーはイギリスのテレビシリーズ '( のようなスタイルを再現するものである．シーンは主人公が店でクマのぬいぐるみ

(104) を見つけたところから始まる．エージェントのゴールはこのクマのぬいぐるみを手に入れることである．使用するタスクは先に示した図ので，今回の例ではオブジェクト

(105) を入手するのが目的である．つまり，

(106) を解決することがエージェントの具体的な目的である．プランニングは以下のように行われた．なお，各シーンは図 ∼図 # として，以下の手順の後にまとめて示し，加えて全体的な流れを図 & に示した．. . まず

(107) メソッドが選ばれ，その下層にある

(108) が選ばれる．図探索が

(109) メソッドの最初に実行されるプリミティブタスクに到達し，候補の中から

(110) が選択される．これにより主人公は急いで 4' に向かう．. 4' に到着すると，次のプリミティブタスクへと移る．ここでプランナーは環境の状態. を参照して，失敗するオペレータとして候補の中からを選び，主人公は列の先頭を取ろうとする．具体的な処理としては，

(111) がであるのに対して環境内ではという状態が存在し，この時点で条件が満たされないことを確認する．オペレータの詳細を図に示す．. . 既に 4' に並んでいる人がおり，

(112) にあるという条件が満たされないため，先頭を確保するという試みが失敗する．図 . . 再試行のためにというほかの候補が選ばれた．これにより主人公は列の前に並んでいる人を無理やり抜かして自分の順番が来るのを待つ．図. . $. 次のプリミティブタスクへと移り，

(113)

(114) が選ばれ，主人公は急いで現金を引き落とした．この時点で必要な現金を手に入れることに成功し，

(115) メソッドが終了する．図 $. . メソッドへと移り， !

(116)

(117) が実行され，主人公は急い. %. でクマのぬいぐるみを手にとる．図 . この時点で，ユーザは仮想空間に対してインタラクションを行うことにした．具体的には，現金を手に入れることで追加された状態

(118)

(119) を取り除くことで，主人公から現金をとりあげてみた．. .

(120) #. 主人公は次の行動として

(121)

(122)

(123) を実行しようとするが，である

(124)

(125) が満たされず，失敗してしまう．つまり，主人公はお金がないのに気づき，クマのぬいぐるみを買えなくなってしまう．この時点でメソッドおよび

(126) メソッドは失敗に終わってしまう．図 %. &. 上記の失敗により，バックトラックが行われ，メソッドに移る．ここで今度は !

(127)

(128) が実行され，主人公はこっそりクマのぬいぐるみを手に取る．. . 次のプリミティブタスクに移り， " !

(129) が実行され，主人公は店員に捕まらないように素早く店を出る．図 #. 拡張. ツリーでのプランニングおよび実行の全体的な流れは図 & のようになる．. get(X). exchange. steal buy. 図. 7 実行例のシーン .

(130) buy. get money. •move(ATM) •move_in_a_hurry(ATM) •move_slowly(ATM) •move_secretly(ATM). •stand_in_the_line_and_wait() •pass_a_person_and_wait() •get_ahead_of_the_line(). •withdraw(cost(X)) •withdraw_in_a_hurry(cost(X)) •withdraw_slowly(cost(X)). failure 図. 7 実行例のシーン . $.

(131) get money. •move(ATM) •move_in_a_hurry(ATM) •move_slowly(ATM) •move_secretly(ATM). •stand_in_the_line_and_wait() •pass_a_person_and_wait() •get_ahead_of_the_line(). •withdraw(cost(X)) •withdraw_in_a_hurry(cost(X)) •withdraw_slowly(cost(X)). 別の候補図. 7 実行例のシーン . .

(132) get money. •move(ATM) •move_in_a_hurry(ATM) •move_slowly(ATM) •move_secretly(ATM). •stand_in_the_line_and_wait() •pass_a_person_and_wait() •get_ahead_of_the_line(). 図. •withdraw(cost(X)) •withdraw_in_a_hurry(cost(X)) •withdraw_slowly(cost(X)). $7 実行例のシーン . %.

(133) buy. get money. trade. •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). 図. 7 実行例のシーン . #. •pay(X) •pay_in_a_hurry(X) •pay_slowly(X) •pay_roughly(X).

(134) buy. get money. trade. failure •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). 図. %7 実行例のシーン $. &. •pay(X) •pay_in_a_hurry(X) •pay_slowly(X) •pay_roughly(X).

(135) get(X). exchange. steal. buy. •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). 図. #7 実行例のシーン . . •get_out_of_the_shop() •get_out_of_the_shop_quickly().

(136) get(X). exchange. from a shop owner. steal. from a kid. •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). •get_out_of_the_shop() •get_out_of_the_shop_quickly(). buy. Failure trade. get money. •move(ATM) •move_in_a_hurry(ATM) •move_slowly(ATM) •move_secretly(ATM). •stand_in_the_line_and_wait() •pass_a_person_and_wait() •get_ahead_of_the_line(). •withdraw(cost(X)) •withdraw_in_a_hurry(cost(X)) •withdraw_slowly(cost(X)). Failure 図. &7 プランニングの全体的な流れ. . •pick(X) •pick_in_a_hurry(X) •pick_slowly(X) •pick_secretly(X). •pay(X) •pay_in_a_hurry(X) •pay_slowly(X) •pay_roughly(X).

(137) Operator: get_ahead_of_the_line() Preconditions: be_at(ATM) Executability Conditions: not line_formed Delete List: waiting_for_my_turn Add List: ready_to_withdraw 図. . 7 意図的に失敗させるために選んだオペレータ. 考察. ここではで述べた問題が解決されたかどうかについて検証する．まず，プランストーリーの多様性が乏しくなるという問題点だが，これは主にオペレータの複数候補によって解決を試みた．実行例として示したプランはつだけであるが，全体の流れを見てわかるように，選択されるオペレータ系列はこの例以外にも多数の組み合わせが可能だということがわかる．この拡張によってストーリーの選択肢の幅が広がるのは，ツリーにおける終端のノードにおいてのみである．もちろん，ある程度ストーリーを決めることができるというの特質上，簡潔にツリーの上位の階層で選択肢を増やすということが難しいためであるが，これではプランの大幅な変更が行われにくい．つまり，多くのリプランニングがプリミティブタスク内で生じるので，まったく異なる手段を試みるということは稀になってしまうわけである．しかしながら，全体的なストーリーの流れをしっかりと決めておきたいような場合や，例えば童話や寓話等をベースにしたコメディでを使用したい場合，従来のでは依然としてストーリー選択肢の幅が狭いため，オペレータの複数候補による拡張は有用であるといえる．次に，ユーモラスな場面の創出を偶然性に頼ってしまっているという問題点だが，これは

(138)

(139) !"

(140) によって解決を試みた．実行例では，主人公が 4' に並ぶ列の先頭をとろうとして失敗するというシーンが

(141)

(142) !"

(143) を活用したシーンである．このシーンから分かるように，拡張における

(144)

(145) !"

(146) を利用すれば，意図的に失敗するオペレータを選択することができる．実際，このシーンではわざわざ. .

(147) 失敗するを選ばずに直接を選べばその場の目的は達成できるが，ここではユーモラスな場面を作るために意図的に前者を選択したわけである．このように，実際に作られた場面が笑いを誘うようなものであるかはまた別の課題となるが，この拡張によってキャラクターエージェントが失敗する場面を意図的に作ることは可能となった．. .

(148) 第章. システムの実装に関して. ここでは関連する研究として，我々が開発しているインタラクティブドラマシステムについて述べる．このシステムは現在開発の初期段階であり機能的にまだ未熟であるが，これまでの開発におけるシステムの構成や開発の方法等について概要を説明する．. . 開発環境. 開発は以下のような環境で行われる．.

(149)

(150) での開発. ¯ ¯ . ¯ . 9.

(151) 用のエディタである :2 を用いてコーディング 9 に付属している # でコンパイルでの開発. によるコーディング. モデルの作成. ¯ ¯ ¯ ¯. 0 でキャラクターのアニメーションを編集 ' によるキャラクターやオブジェクトのモデリング ' プラグインである (" .

(152) " で 0 ファイルを ' で読み込み ' プラグインである 4

(153) 1 で ' ファイルを 9 用のデータに変換. ¯. 9"

(154) を用いてアニメーション，オブジェクトをコードから呼び出し可能にする. . 次元仮想空間の作成. ¯. 9"

(155) を用いてマップ仮想の環境を作成. その他. ¯ ゲームエンジンの実行等に !. を用いて作業 .

(156) . システムの構成. インタラクティブドラマは仮想空間内でストーリーが展開するため，5 表示のインターフェースであることが望ましい．また，キャラクターエージェントが空間内で行動を行うことができるようなものでなければならない．このようなプログラムをから作ることは非常に労力を必要とするため，我々は 9;

(157) && という一人称視点シューティングゲームで用いられている 9 *&+ というゲームエンジンを用いて開発を行うことにした．このゲームエンジンはグラフィックの表示やネットワークの機能が 40, として提供されており，これを用いれば 9.

(158) という独自のプログラミング言語を用いてゲーム等を開発することができるようになっている．また，キャラクターエージェントを空間内で動作させるために，(

(159) と呼ばれる 4, キャラクターを外部からネットワークを通じてプログラムによって操作するためのインターフェースである <;(

(160) *+ という 9 用の拡張コード '25 を用いることにした． <;(

(161) を通じて 9 の (

(162) を動かすには，=- で <;(

(163) 用のエージェントプログラムを開発するための 40, である =-(

(164) *+ を用いた．この 40, を用いてエージェントの行動を司る =- のプログラムを作成している．インタラクティブドラマを開発するためには，エージェントを =- で記述するだけでなく，仮想空間内でのエージェントの動作の追加や改良，サーバと =-(

(165) クライアント間のプロトコルで新たに必要となるコマンドの拡張といった作業を行う必要がある．これらの実装はゲームエンジン側のコードと =-(

(166) 側のコードの両方において行われる．. $.

(167) 第章. 結論と今後の課題. 本論文では，従来のインタラクティブドラマシステムとの適用における問題点を指摘し，その解決法としてつの新たな手法を導入した拡張を提案した．一つは

(168)

(169) !"

(170) で，これによって意図的な失敗を作り出すことができた．もう一つはオペレータの複数候補の導入で，大幅なリプランニングが難しいという問題点はあるものの，ツリーの管理の容易さを損なわずにストーリーの多様性を増すことができた．今後の課題としては，ユーモア度の定量的評価ということが挙げられる．例えば，本論分における実行例が面白いかどうかは主観的な判断によってしまうため，検証することは難しいといえる．ユーモア度を定量化することができれば，笑いを誘う場面を作り出すにはどのようにプランニングを行えば良いのかということを評価するヒューリスティックスを導き出し，ユーモラスなエージェントの開発に適用できるだろう．また，基本となるシステムを完成させることも今後の課題である．. .

(171) 第章. 謝辞. 本研究を行うにあたり，御指導，御助言を頂きました 3 ; 助教授に深く感謝致します．また，本研究プロジェクトのメンバー，特に八朔宏樹氏の協力に感謝致します．本研究に関して貴重な御意見を頂きました知能エンターテインメント研究室の院生，回生，回生諸氏に感謝致します．. %.

(172) 参考文献 *+ '

(173) ' " .

(174) 47 4 (- 6 > .

(175) /( " (- 4

(176) , ,

(177)

(178) .

(179) ; #/ = /4

(180) && *+ ! ) !-?? ' " '" .=7 <

(181) 5 ; .

(182) !

(183) ’,

(184)

(185) ,

(186)

(187) = ,

(188)

(189) <; " .;

(190) - / ' && *+ "

(191) 37 ,

(192)

(193) - !;" 7 6

(194)

(195)

(196) ,

(197) .

(198) ; 0 ,

(199)

(200) 4

(201) > . " > 5-;

(202) 7 4

(203) Æ " !;

(204)

(205) ,

(206) &/& .

(207) ; && *+ !-?? ' ! ) " '" .=7 <

(208) > ; .

(209)

(210) !

(211)

(212) 0/ " );

(213) ! ,/&& : 7 ; '"

(214) ,

(215) > 4 && *+ 5. .;

(216) .== " @7 !

(217) .

(218)

(219) 07 - 0

(220) 444,/#%8,44,/#% 0" / ##% *$+ (

(221) ( " <A 7 0

(222) . 4

(223) Æ ,

(224) 7 . ,

(225) . - # / && *+ ! ) 6? ' '" .= ( B 4) " !-?? '7 0 ); ; " 4

(226) ,

(227)

(228) - .

(229)

(230) 0 >

(231) )

(232) ,

(233)

(234) !> > ,

(235)

(236) - 5

(237) .

(238)

(239) "

(240)

(241) ;

(242) 5;

(243) "

(244) <; /$ ' && *%+ 6? ' '" .= !-?? ' " ! )7 ./ " 07 4 '

(245) " > !

(246) (- <;2 && 6" 9@ *#+ .; C " @; '7 4

(247) ;

(248) .

(249) .

(250) <

(251) ( " 4

(252) ; 4

(253) 03,'4 && 6 4, /$ && *&+ 9 5-

(254) 7 $%% # #% *+ <;

(255) ;7 $%% # % &% #.

(256) *+ =-(

(257) ;7 . $%% # # %. &.

(258)