1月 2016 | おばちゃんのスカイリムガイド

2016/01/11

SM様が見てる~ストーリーマネージャーの「神の目」

私がスカイリムを初めてプレイしたのは、もう四年も前のことになりますが、その時の興奮と衝撃は今でも昨日のことのように覚えています。
まるで映画を見てるみたいだったド迫力のアルドゥインの襲撃シーン、蝶やトンボやサケが採り放題の夢みたいな美しい自然……私が感激したものを挙げたらきりが無いのですが、その中でも一番「このゲーム凄い!面白い!」と衝撃的だったのは、NPCの心無い一言でした。
一番最初に辿りついた村~リバーウッドで、ふと目についた道端の樽を漁ったら、「あの女を見てごらん、ゴミを漁ってるよ」って、これみよがしに言う声が聞こえてきたんですよね(笑)
「あの女って、もしかして私のこと?」と思って顔を上げたら、近くの家の縁側にいたおばあさん(スヴェン母のヒルデさん)が不審者を見るみたいな目でこっちを見てて。

ええ~!まさか私がアイテム漁ってるとこ見てそんなこと言ったの!?
…ってか、この樽ってゴミ箱だったんだ……!!(私が拾ったキャベツは生ゴミか)

前作オブリビオンでも、お店の人が万引きを警戒してプレイヤーの後をついて来る事はあったけれど、まさかNPCにイヤミまで言われるなんて……本当に驚きました。
凄い、このゲームはNPCがこっちの行動を見て生身の人間みたいに反応するんだ……オブリビオンからもっともっとNPCのAIが進化したんだ、って感動しましたね。
とりわけ私はどんなゴミみたいなアイテムでも残さず拾ってしまう、TES初心者あるある…みたいなタイプでしたから、ヒルデさんのイヤミは心にぐさっときて、以後のプレイではヒルデさんの前では絶対に樽を漁らないように気をつけました。

でもあの時、私のがめつい行動を見ていたのは、本当はヒルデさんではなかったのです。
私の一挙一足をストーカーのようにチェックしていたのは、「ストーリーマネージャー」というスカイリムの因果を司る神。

このゴミ漁りの一件の他にも、私がスカイリムで面白いと思った事件の多くは、この神の何でも見通す目が少なからず関与していました。
今日はそんなストーリーマネージャーこと、SM様のことについて、書きたいと思います。

この手紙……私はフォントを可愛い書体に変えていたせいで、最初はファンレターかと思いました。


さて、まずは「ストーリーマネージャー」とは何ぞや…ということなんですが。

スカイリムの発売十ヶ月前(2011/1/17)に書かれた、開発中のスカイリムを紹介する「gameinfomer」の記事(The Technology Behind The Elder Scrolls V: Skyrim)によると、ストーリーマネージャー、もとい「Radiant Story」というシステムはベセスダ様入魂の目玉の新機能のひとつであったことが窺えます。
ちなみに上記の「gameinfomer」の記事は英語なんですが、この記事を翻訳して紹介している「doope!」というゲームサイト様の特集記事があります。
↓こちらがその記事のリンクです。よろしければこちらをご覧ください。
「The Elder Scrolls V: Skyrim」の新エンジンは”Creation Engine”、その概要が遂に明らかに


上記の記事後半にある「Skyrimの物語は”Radiant Story”システムにより拡張される」…のくだりが、「ストーリーマネージャー」によって、どんな進化がゲームにもたらされるのかを紹介している部分です。
これをざっくり読めば、どういった類のイベントがストーリーマネージャーによって引き起こされたものなのか、スカイリムを既にある程度プレイされている方であれば、「ああ、あの時のアレか…」と思い当たるフシが少しはあるのではないかと思います。

プレイヤーが未探索の場所や調査して欲しい場所へと自然に案内できる様」にと作られたこのシステムおかげで、未上陸のソルスセイムのダンジョンをいきなりクエストの目的地に指定されて「どこ?」と探しまくったり、スイートロールを落としただけで殺し合いの喧嘩が始まるNPC達の「より複雑で現実的な反応」を拝ませてもらったりしたわけですね(笑)
なんだかこう皮肉いっぱいに書くと、このシステムは「微妙」な機能だった感じがしなくもないのですが、しかしこの新システムは実際のところ、使い方によっては結構あなどれない性能をもっていまして、ベセスダ様がドヤ顔するのもさもありなん…という感じなのでありました。


ストーリーマネージャーというのは、ざっくり簡単に言ってしまうと、プレイヤーの挙動によって動く、クエストの着火装置……みたいなもんです。
プレイヤーが誰かを攻撃したり、魔法を使ったり、アイテムを拾ったり、レベルUPしたり、誰かと仲良くなったり、罪を犯したり……プレイヤーが何かするたびどこかに行くたびにチェックが走って、条件に合うものがあればクエストを発動させます。

たとえばヒルデさんが「ゴミを漁っている!」とイヤミを言ってきたのは、「WIAddItem02(ごみあさり)」というクエストが発動したからなんですが、このクエストが発動したのはストーリーマネージャーのPlayer Add ItemというSMイベントで「プレイヤーがゴミを漁っている!」と判定されたのが原因です。
「Player Add Item」というSMイベントは、文字通り、プレイヤーが何かアイテムを取得したのを察知して起こるイベントでして、プレイヤーが何かしらのアイテム…たとえ矢一本でも…を取得するたびにイベントが走ります。
しかもこのイベントでSM(ストーリーマネージャー)様が察知するのは、プレイヤーが単に何かアイテムをゲットした、という情報だけではないんです。
そのアイテムは元々どこにあったものだったのか、誰の所有物だったか、どこでプレイヤーが手に入れたか、そのアイテムは盗んだのか、買ったのか、スリとったのか…などなど、入手経路についてもSM様は全部チェックしているんです。
このSM様の何でも見通す「神の目」だけは、たとえ隠密100、スリ100のドヴァキンさんでも、絶対にごまかすことはできません。誰にも目撃されなかった筈の盗みなのに、あとで「雇いの悪漢」が送られてくるのも、買い物して店を出た瞬間に、カルセルモの手紙を持った配達人が駆け寄ってくるのも全部、このSM様が見ていたから、なんですね。

ごみあさりクエストを走らせるかどうかを決める、SMイベントのノードの条件設定

上記の画像は、プレイヤーがアイテムを取得したことを察知したSM様が「WIAddItem02(ごみあさり)」クエストにGOサインを出す場合の条件設定です。
まず一つ目……AquireTypeが「5」という条件がありますが、これはコンテナタイプの収納からアイテムを入手したかどうかをチェックしています。
条件二つ目の 「WIAddite02RubbishContainerList」というのは「Rubbish(がらくた)」という名前の通り、
たいした物の入っていない樽や袋といったコンテナが登録されているフォームリストです。
そして三つ目は、プレイヤーが室内(インテリア)にはいないことをチェックするもの。
つまり、野外で樽や袋のような基本リスポンする保管に向かない収納庫からアイテムを入手すると、SM様は「プレイヤーはゴミを漁った!」と判定するわけなんですね。
そして「WIAddItem02(ごみあさり)」クエストに通知がいき、クエストの配役が決まると、NPCがプレイヤーにイヤミを言ったり嘲笑したりという場面が発生するのです。
だからヒルデさんのAIが進化して、プレイヤーの行動に超反応したわけじゃあないんです。
ヒルデさんはたまたま、私が樽を漁った時にすぐ近くに居ただけ。
私がゴミ箱同然の道端の樽から何かを入手したのを察知したSM様が、「今プレイヤーがゴミを漁ったよ!」と「WIAddItem02(ごみあさり)」クエストにチクって、そしてそのごみあさりクエストの配役(エイリアス)に条件の範囲内にいたヒルデさんが選ばれただけだったんです。
このように登場人物や舞台を、その場にいるものの中から見繕ってクエストを臨機応変に組み立てて実行させるからこそ、SM様は「ストーリーマネージャー」と呼ばれるわけなんですね。
スカイリムで「へえ、こんなイベントあったんだ…」と思う場面の多くは、ただそこにいたから、という理由でSM様に選ばれて参加したNPC達の一期一会のシーンであることが多いです。


たとえば……女性NPCが集まって談笑してるところに、「やあ、ご婦人方!この素晴らしい日に、大きくて強い男がお手伝いできることはありますかな?」と、男NPCが意味深なセリフでナンパしてくるという変なシーンを見たことがあるでしょうか。
これもSM様から通知を受け取って始まるクエスト(DialogueGenericScene04)のシーンで、スカイリム本体で用意されている汎用の会話シーンの一つなんですが、バニラの状態だとお目にかかるのはちょっと珍しいかもしれません。
ちなみにこのナンパシーンを拝むには、まず、サーディアちゃんタイプのお色気担当の女性ボイスタイプ(FemaleSulty)のNPCがいることが必須条件です。
それから「FemaleCommoner」「FemaleEvenToned」「FemaleNord」のいずれかのボイスタイプの女性NPCがサーディアちゃんのボイスタイプのキャラと会話できる範囲内にいること。
この女性キャラ陣が揃い、かつサーディアちゃんタイプの半径500以内に「MaleNord」の男性がいると、この会話シーンのクエストが発動する条件が揃います。
つまり年頃のイケてるおねーちゃん達が集まってキャッキャしてるところを見て、ノルド男がスケベ心(?)を出して声をかけてくる、という筋書きなんですね。
ちなみにこのテの汎用クエストは、メインクエストなど主要なクエストに登場する予定の予約済みのNPCは基本的には参加しません。(サーディアちゃんなども予約済みNPCの一人です)
なので他のクエストに登場する予定がないModで追加されたフォロワーなどの方が、このシーンの出演者に選ばれる可能性が高いかもしれないですね。
このナンパシーンのやりとりはちょっとイミフっぽい感じではあるのですが、配役がハマると結構面白いので、まだ見たことがないという方はぜひ一度ご覧になってみてください。


それから、しばらく前に「今頃になってこんな没クエストが見つかるなんて!」と話題になってたようなんですけども、死んだNPCが幽霊となって配偶者や子供、兄弟といった家族の側をうろつくというクエスト(WiKill02)…なんてのもSM様経由で始まる汎用クエストのひとつです。
スカイリムにはNPCが死んだ時の演出として用意されているクエストが結構ありますね。
以前、消えない死体について調べていた時に悩まされたWIKill05(関係者が死んだNPCに駆け寄り、家に引きこもるクエスト)だとか、誰かを殺した後に、そのNPCと仲の悪かったキャラからお礼を貰うクエスト(WiKill04)など……死が身近なスカイリムだからこそ、いろんな演出が用意されているんでしょうか。
ただ、上記の幽霊クエストがずっとゲーム中では発生せず、誰にも知られず埋もれていたことからもわかるように、SM様によるクエスト関係者抽出のしくみは実際のところ、セリフが用意されているボイスタイプであるかどうかという大きな壁に阻まれて、100%稼動しているとは言えません。
ボイスタイプの問題をクリアし、さらに他の主要クエストで予約されておらず、しかも故人の家族や恋人であるという関係性をもっているNPCの組み合わせなんて……狙って用意しないと難しいです。
CKでQuestの「Event」のところをソートすると、SMイベント経由で稼動するクエストが一目瞭然です。

「ごみあさり」とか「うっかり落としてしまいました」とか「何かいい物でも見つけたんですか?」とか
クエスト名の日本語訳って、なんかいい味出してるなあと思います。


さてそれでは、CKとか弄らない方にとってはクソ眠い話になるでしょうけども、せっかくなんで、このストーリーマネージャーの機能がどんな風に搭載されているのかを見てみたいと思います。
ストーリーマネージャーのイベントの詳細は、CKのオブジェクトウィンドウの「Character」カテゴリの中にある「SM Event Node」という項目で見ることができます。
SMイベントは前述した「Player Add Item」のように、プレイヤーの行動や周囲の状況に対応したさまざまな種類のものがあります。
たとえば「Craft Item」というのは、プレイヤーが錬金台や鍛冶屋の鋳造器具などでアイテムを制作した時に起こるイベントです。チュートリアルで武器や防具を作った時にすかさず鍛冶屋さんが「悪くない」とか褒めてくれますよね。ああいうNPCのリアクションの出所になっているのがこの「Craft Item」です。
「Kill Actor Event」とか、「Increase Level」とか、大抵は名前のまんま、という感じのイベントなんですが、中にはゲーム中では一度も使用されておらず、具体的にどういう場面で発生するのか、私にはよくわからないイベントもあります。

ちなみに上の画像は、スカイリム本体+DLC3種を読み込んだ時のもので、Usersの一番多いもの(つまりゲーム中で一番よく使われているもの)から順に並んでおります。
これを見ると、一番ゲーム中で多く使われているのは「Script Event」ですね。
この「Script Event」というのは、ちょっと特殊なタイプのイベントでして、これはプレイヤーの直接行動からではなく、スクリプトからキーワード経由で発動します。
こちらはプレイヤーの動作と関係なく任意のタイミングで手動で発動させることができるのが便利で、だからこそゲーム内で一番多く使われていると思うんですが、スクリプトを知らない方には説明がちょっと難しいので割愛させていただきますね。

「Change Location Event」のSM Event Node 編集画面
各SMイベントの項目をダブルクリックすると、上画像のような「SM Event Node」の画面が開きます。
ここにそれぞれのSMイベントから通知を受けたいクエストを登録するわけです。
クエストを登録する場所は、SMイベントノード(節)と言うようにツリー構造になっていて、第一層のノードには大抵ざっくりとした条件が設定されています。(何も条件がないのもあります)
たとえば「DungeonNode」というブランチでしたら、移動先のロケーションのキーワードが「LocTypeDungeon」になっているかどうか、つまりダンジョンかどうか……という条件です。
それでその条件をパスしたら、その配下のクエストノードのチェックが始まって、そこでもっと細かい条件判定をし、条件が合えばクエスト開始のGOサインが出る、というしくみです。
実行されるクエストは一回のイベントにつき一個、と決まっているわけでなくて、イベントをシェアしてクエストを同時多発的に実行したり、配下のノードからランダムで実行されるものを選んだり、実行されるクエスト数に制限を設けたりなどできます。


上の画像の「Change Location Event」というSMイベントは、ゲーム中では二番目によく使われているイベントで、文字通り、プレイヤーがロケーションを移動した時に起こるイベントです。
「Change Location Event」によって発動するクエストは沢山あって、例をあげるとキリがないのですが、個人的に苦笑を禁じえないのはDA09、デイドラ・メリディア様の「夜明け」関連のクエストです。
上画像で赤線を引いた部分……「Stacked Branch Node: QuestNode」の下に「DA09ChangeLocation」というクエストが登録されているんですが、このクエストは何をしているのかというと、プレイヤーが移動した先のダンジョンの宝箱に例のアノ珠を仕込んでおくという裏工作を行っているんですね。
SM様はプレイヤーが訪れた場所の詳細……ボスキャラやボス用宝箱の所在、ロケーションの中心地といった「Location Ref」の情報もしっかり押さえてますので、それを毎回教えてもらって、例の珠をポスティングしているというわけです。
だからあの珠は節操無く、どこにでも入っていたんですね(笑)


使用頻度が三番目に多い「Actor Dialogue Event」というイベントは、さきほどご紹介したナンパシーンのようなNPC同士の会話イベントの着火によく使われるSMイベントです。
もっともボイスタイプさえ合えば誰でも会話シーンが始まるというような汎用会話のクエストはスカイリムではほとんど無くて、登録されているのは固定のNPC同士による会話シーンばかりです。
ちなみに私が以前試しに作ってみたNPC同士の汎用会話シーンModも、この「Actor Dialogue Event」のSMイベントを利用して作ったものでした。
このイベントはロードされている範囲内にいる、会話が可能なシチュエーションにいるNPCを察知すると発生するのですが、前提としてNPCのAIパッケージに「Random Conversations」のチェックが入っていないと会話可能とは見なされないようです。
また会話の起こる頻度や距離感などはゲームセッティングの値で決まっているようでして、詳しくはCK Wikiのこのあたりに詳細が書かれています。
自分でModを作ってみて思ったんですが、このイベントで検出するNPCの範囲というのは予想以上に広くて、しかも会話が始まる前に自動で相手に近寄ってきてくれたりはしないので、軽く通りすがりに挨拶する程度なら、「Actor Hello Event」の方がより自然な感じになるのではないかと思いました。


ところで話はちょっと脱線してしまうのですが、このNPCの汎用会話Modを作った2014年の初め頃から私は「Papyrus.0.log」などのログを見るのに、SnakeTailというログ監視ツールを使っております。
私にとっては「Mod Organizer」「Sublime Text2」とならぶ、スカイリムで遊ぶためになくてはならない三種の神器のツールのひとつで、このストーリーマネージャーの機能をよく知るためにも欠かせないものでしたので、ここでちょろっとご紹介させていただきます。
これは汎用会話Modを作ってた頃のSSなんですが……右端の赤枠の部分が「SnakeTail」です。

このツールの何がそんなに便利なのかと言いますと、これを使うとなんと、スカイリムのゲームをプレイしながら「Papyrus.0.log」などのログの進行をリアルタイムで見ることができるのです。
つまり横目でログが流れていくのを確認しながらゲームを操作するという感じでして……いちいちゲームを終了させずともログがチェックできるというだけでなく、プレイ中のどのタイミングで、どういったスクリプト処理が走っているのか、ということをその場で即チェックできるんですね。
もちろんこのツールを使う前に、動作を確認したいと思ってるスクリプトにデバッグ用のコメントを仕込んでおかないと意味がないですけれども……しかし準備さえすれば、その効果は抜群です。
少なくとも私にとっては、今までパンくずを撒きながら手探り状態で歩いていた暗いスクリプトの闇の中を、カーナビ付きの車で走り回れるようになった、と感じるくらい役に立った神ツールでした。


んで、この「SnakeTail」を使って、ストーリーマネージャーのログをプレイ中に観測すると、どのようなタイミングでイベントが起こり、どんなクエストが着火したか…というのが一目瞭然で面白いんです。
ちなみにストーリーマネージャーのログというのは、「StoryManager.0.log」というPapyrusスクリプトのログにも似たSM様の挙動が記録されるログのことです。
このログを出力するためには、Papyrusのログと同じようにiniファイルを編集する必要があります。
[General]
iStoryManagerLoggingEvent=-1
bEnableStoryManagerLogging=0 → bEnableStoryManagerLogging=1 に変更
セーブデータが保存される方のSkyrimフォルダの「skyrimprefs.ini」、この中の[General]にある「bEnableStoryManagerLogging」の設定を「1」に変更してやると、Papyrusのログが出力される「Logs」フォルダの中に「StoryManager」というフォルダが出来て、そこに「StoryManager.0.log」という名前でログが保存されるようになります。

また、同じ[General]の中の「iStoryManagerLoggingEvent」という項目は、このストーリーマネージャーのログ出力のオプション設定になってるようです。
ちなみにデフォルトの「-1」ですと、すべてのSMイベントがログに出力されます。
このオプションについてはCK Wikiを見ても説明がどこにも書いていないようなのですが、おばちゃんが自前でテストして調べてみたところ、こんな感じでログが切り替わるようになっておりました。
「0」……「Kill Actor Event」
「1」……「Assualt Actor Event」
「2」……「Change Location Event」
「3」……「Script Event」
「4」……「Actor Dialogue Event」
「5」……「Actor Hello Event」
「7」……「Player Add Item」
「8」……「Player Remove Item」
「9」……「Craft Item」
SMイベントのログは場所によっては物凄い量になりますから、自作Modの動作確認でログを見る場合などには、トレースするイベントの種類を限定できるこのオプションは非常に有用です。
もっとも私が確認できたのはこの9種だけで、他のイベントについてはわからなかったんですが。
他のイベントについて、何かご存知の方がいらっしゃいましたらぜひとも教えてください。


とまあ、そんなわけで、話がかなり専門的(?)になってきて読む気が失せたでしょうけども、もうこんな話をする機会も二度と無いでしょうから、もうちょっとだけご紹介させてください。

まずは「StoryManager.0.log」とはどんな感じのものなのか、一部ですがスクリーンショットを撮りましたので参考までにご覧ください。
ちなみに下の画像は、前述の「SnakeTail」でログを開いたところなので、文字色が変わったりなどしていますが、「StoryManager.0.log」自体は単なるテキストファイルです。
(クリックすると別ウィンドウで拡大します)
ストーリーマネージャーのログは、SMイベントが起きるたびに詳細情報が記録され、そのイベントに登録されたノードの判定がどうなったか、という結果が出力されます。
上の画像のログですと、まず一番最初に発生したのは「Player Add Item」イベントです。
二行目の「Started processing event 000014FE: Player Add Item ...」というところを見ると、プレイヤーがその時入手したアイテムの所有者は特に無く(OwnerRef: NULL)、またコンテナタイプの収納庫から入手(AquireType: 5)したことがわかります。
続けて三~五行目の記述は、その後、配下のノードの判定がどうなったかという結果を示す部分です。
まず「Player Add Item」のSMイベントノードの基点のノードを通って、それから二つ、「Node '' failed conditions」と出てますんで、直下にあったノードが二つとも条件外ということで、そこでチェックは終わり、その下層にあるノードのチェックはスルーされたことがわかります。
「Player Add Item」のSMイベントノード
「Player Add Item」のSMイベントノードには、第一層に二つのノードがあるだけですので、これでチェックはすべて完了となり、六行目で「Finished process event.」(イベントプロセス終了)となったわけです。
ざっとですが、ストーリーマネージャーのログの見方はこんな感じです。
まあ、これはチェックするノードが少ない時の例なので非常にわかりやすいんですが、いろんなイベントが立て込んできてタイムアウトが発生したりするようになると、ログの順番もめちゃめちゃになってきて、どれがどれなのかわけわかんなくなってきます。
ですが、条件をパスしてクエストの着火までたどり着いたものは名前がわかりますし、さらにそのクエストの必須項目が揃わなくてクエストが不発に終わっても、その結果がわかるようになっています。



長々と書きましたが、私がストーリーマネージャーについて書けることは以上です。
スカイリムにはいろんな仕掛けがいたるところに散りばめられているのに、目に見えるのはほんの一部です。ストーリーマネージャーのログを見ながらプレイしていると、特にそう感じます。
たわいもないNPCの一言の後ろに、こんな途方も無いしくみが隠されていたということが驚きで、そして知れば知るほど面白くて、それをずっと書きたいと思っていたんですが、うまくまとめられず、結局こんなとりとめもない内容になってしまいました。
更新するのをためらう出来ですが、少しでもスカイリムって凄いな、こんなしくみがあったんだ…と思っていただけたら嬉しいです。