数年ぶりにSkyrimを始めて一番感じたことは、
アニメーション関連技術が劇的に進化している
ことですね。これはほんとビックリ。
modderの皆様には感謝してもしきれませぬ。ありがとうございます。
反面、modderの技術力向上に対し、user(勿論僕も含めて)がどれだけ追従してMODを理解してるか？というと・・・かなり怪しいですぬ。動きが見えづらい、framework色の強いMODが増えた為と思われます。
そこで、自分の環境は自分で面倒を見るDIY精神に則り、2023年末におけるアニメーション関連のframework系MODの構造把握をしておこうと思います。
どのMODが何をしてるのか？の概要を把握してるだけでも、環境整備には役に立つでしょう。
詳細はまた別記事作る予定でいますが(僕の理解度次第…)、とりあえず概要だけでも。
個人的な解釈からの理解なので、間違いがあるかもしれません。各MODの概要説明という面では大丈夫だと思いますが、詳細に関しては嘘あるかもです。その前提でお願いします！
ちょっと長いですが、前提知識を貯めつつ読み進められる並びになってます。だんだん繋がりが理解できる想定！
- Project New Reign - Nemesis Unlimited Behavior Engine
- Payload Interpreter
- Animation Motion Revolution
- Open Animation Replacer
- Behavior Data Injector
- Paired Animation Improvements
Project New Reign - Nemesis Unlimited Behavior Engine
FNISの後継ポジション的なMODで、FNIS同様にバニラに存在しない新規アニメーションの追加が可能です。互換性は高めで、クリーチャ系エロMOD以外なら、FNIS対応MODがそのまま動きます。
NEMESISとFNISの違い
userの使い勝手としては、おおよそ同じかと(つまりFNISで難儀した人はNEMESISでも躓く)。
ただしローカル環境のbehaviorファイル(後述)の生成方法が大きく異なります。イメージ的には、バニラbehaviorはなるべく触らず、外に追加のbehaviorを「接続」していくのがFNIS。対してバニラbehaviorそのものを自由に改変し、パッチで「復元」していくのがNEMESIS。パッチが複数あればまとめて整頓し(多分これがUpdate Engine)、改造合体behaviorに復元します。
直接変更したbehaviorファイルをMOD化できる為、基本的に制約が無さそうです。イベントシーン的なアニメーション追加は勿論、戦闘系等の直接操作対象になるアニメーションも拡張可能です(例えばコンボ攻撃の状態遷移を作れるとか)。
反面、適当にいじったbehaviorからパッチを作ると、危険度の高い物が出来てしまうかも。いいもわるいもリモコン次第。FNISでは起きないと思います。
桃鉄に例えると、「Whiterun駅」とか勝手に作ってみても、入れる余地がありません。
・・・ならどうするか？
FNISやNEMESISで線路を分岐＆延伸して、作った「Whiterun駅」をどこかにしれっと置くのです( ; ﾟДﾟ)
NEMESISは「Whiterun駅」作者の想定位置に無理矢理にでも置くでしょう。きっと儲かります。でも無茶しすぎるとケガの元。
FNISは予め調べた安全ポイントに支線を引いて置くでしょう。ちょっと儲けが少ないかも。でもきっと安泰。
NEMESIS対応MODはどう作る？
behaviorファイルの直接editが必須な筈で、FNISよりは大分ハードル上がります。ポーズMOD系なら、LISTファイル書いて”FNIS for Modders”でbehavior生成した方が楽だと思います。
基本、”Skyrim Behavior Editor”もしくはテキストエディタ(NEMESISの”Behavior Template”が参考になるかも？)でbehaviorファイルを作り、”HKX Extractor”で差分抽出して、MOD化するんだと思います(多分・・・)。ちなみに32bit版hkxしか扱えません。また、Skyrim Behavior Editorはバグが多く、「禁じ手」手順でセーブすると全てのbehaviorファイルを破壊する等、注意が必要です。別の方によるbugfix版もありますので、そっちの方がいいかも。
あまりwebに情報が無いので、Shikyo Kira氏(作者さん)のDiscordがお勧めです。Skyrim Behavior Editor(Zartar's Behavior Tool ZBTと呼称されることも)の使い方pdf、その他How To資料、MOD化した32bit版behaviorファイルと、これらをセットでパックした物が見つかります。
NEMESIS及び関連ツールのリンク
NEMESIS
www.nexusmods.com
HKX Extractor
behaviorファイルからの差分生成ツール
github.com
hkxcmd
hkxとxmlの相互変換(HKX Extractorにも同梱)
www.nexusmods.com
Skyrim Behavior Editor
GUIのbehaviorエディタ
github.com
別作者さんのbugfix版
github.com
前述の資料はDiscord有志の方々で作成したようなので、直接リンクは張らないでおきます。必要な人はDiscordで探してみてください。
Payload Interpreter
アニメーションファイルには、アニメーションデータそのもの以外に、”annotation"と”payload”という、2つのデータが括られてます。この２つ、今回の最重要ワード！
annotationとpayloadとは？
例えば攻撃時(多分素手殴り)のアニメーションファイル。
0.333 preHitFrame再生開始時を起点とした時刻(多分)、オレンジ色が
0.433 SoundPlay.WPNSwingUnarmed
0.433 weaponSwing
0.533 HitFrame
annotation、赤いのがpayloadです。攻撃ボタンを押して殴りアニメーションが出る所を想像してください。予備動作から始まり、パンチが出て、ひっこめます。
さてこれ、アニメーションごとに教えて貰わないと、何処でエフェクト音出すの？とか、どこら辺が当たり判定フレームだ？とか分からんですよね。多分このタイミングをゲームに教えるのがannotationで、それっぽい感じの名前してます。behavior graphで登録されたAnimation Eventをトリガするようです。
payloadはannotationに付随しており、この場合は再生するエフェクト音です。具体的にはskyrim.esm内のSound DescriptorのEditor ID。まさにannotation(注釈)とpayload(積荷)と言った所ですかね？
Payload Interpreterによるpayload拡張
Payload Interpreterは、このpayloadの記述内容を大幅に拡張します。例えばこんなpayload。作者様のGitから一部拝借。
0.333 preHitFrameこれは、パンチと同時にFireboltをぶっ放せ！というpayloadになります。俺の拳が真っ赤に燃える(ﾉ´∀｀*)。後ろの数字は消費マジカ等の設定。他にもSETGOHSTで無敵フレーム時間を入れる、新規アニメーション変数を操作してのstate遷移(多分AMCOがコンボでやってる)等、アニメーション起点で大活躍。かなり強力な縁の下の力持ちMOD。
0.433 SoundPlay.WPNSwingUnarmed
0.433 weaponSwing.@CAST|0x12FD0|Skyrim.esm|1|1|0|0|0|0|0|20|20
0.533 HitFrame
Payload Interpreterと関連リンク
Payload Interpreter
www.nexusmods.com
書式はこちら
github.com
hkanno64
アニメーションファイルからのannotation(payload含む)抽出及び埋め込みツール。
要Havok Content Tools(x64)
www.nexusmods.com
Animation Motion Revolution
Skyrimはアニメーションによる移動量とゲーム制御下の移動量が同期してないようで、特に戦闘中だとムーンウォークやらスケート状態になってましたね( ; ﾟДﾟ)。
このMODはannotationを拡張して、これを根本的に解決してくれます。
Animation Motion Revolutionの仕組み
下の4行です。ちょっと値は適当ですが、こんな感じ。
0.333 preHitFrame時刻に対応したxyz移動量及び回転量(モーションデータ。日本語ローカルの「モーション」と意味が違うので注意)を、annotationから読み取ることで、実際の移動量との整合を取ります。
0.433 SoundPlay.WPNSwingUnarmed
0.433 weaponSwing.@CAST|0x12FD0|Skyrim.esm|1|1|0|0|0|0|0|20|20
0.533 HitFrame
0.250000 animmotion 0 0 0
0.500000 animmotion 0 60 0
0.750000 animmotion 0 60 0
1.330000 animmotion 0 120 0
AMR対応アニメーションに必要なこと
AMR対応するには、モーションデータをannotationとして記述する必要があります。これが無いと、アニメーション毎の移動量が分からないので、どうにもなりませぬ。このキッチリと整合性のとれたアニメーションこそが、アクション性を大きく向上させた現在のSkyrimの心臓部に思えます。凝った戦闘系環境を作るなら、AMR対応は何よりまず必須でしょう。
Payload Interpreter等と記述が混ぜこぜになっても、ゲームエンジン含めてそれぞれ解釈不可能なものは無視するようなので、併用しても問題無いです。SCARとかCPRも独自のinterpreter持ってそうですが、大丈夫みたい。時刻に関しても、必ず時系列に書かないといけない、ってことでも無いようです。
www.nexusmods.com
Descriptionにannotationの書式が書いてあります。
中休みでござる(〃▽〃)
後半しゅっぱーつ！
Open Animation Replacer
アニメーションを動的に差し替えます。気に入ったアニメーションファイルだけ抜き出して、手作業で所定のフォルダに「上書き」変更したこと無いですかね？。これをゲーム内で一時的に実行するイメージ。同じ機能を持つ「Dynamic Animation Repracer」の後方互換で、DARに無い機能もある為、userは現在のところ、こっち(OAR)を入れておけば良いと思います。
Open Animation Replacerの仕組み
フォルダ単位で設定された差し替え条件に従って、再生するアニメーションファイルを逐次差し替えます。差し替え条件が「プレイヤキャラ」のアニメーションなら、PCEAと同じ効果になる訳です。また、フォルダ毎にpriority設定をするので、差し替え条件が複数被った際は、高priorityフォルダが優先されます。差し替え元のアニメーションファイルはbehaviorから探すので、FNISやNEMESISで追加した新規アニメーションも差し替え対象になります。
これの凄いところは、behaviorファイルを更新せずに実現してる所ですかね。FNISもNEMESISも不要です。behavior的にはどのキャラも同じアニメーションを再生してるのに、実際はOARが差し替えまくる訳です。
behaviorをだまくらかすOAR( ﾟДﾟ)
さらに凄いことに。差し替えに伴い、annotationやpayloadもしっかり差し替わります。OARでアニメーションファイルを差し替えつつ、それぞれに違うannotationを入れこむことも。これもコンボ実現の1要素ですね。様々なMODの効果により実現されてることが分かります。
設定ファイルはjson形式で、ゲーム内のGUIから作成できます。実際に試しながら条件を作りこめるのが大きな魅力ですね。指定したキャラクタ(プレイヤ含む)の使用アニメーションをリアルタイムに表示する「Animation Log」機能もあり、テストにデバッグに、非常に強力です。
Open Animation Replacerでできること
「短剣装備時」とか「片手剣装備時」とか、はたまた「Dawnbreaker装備時」みたいな状態別条件も、「リディアさん専用」とかでも大丈夫。武器種毎に差別化したアニメーション、武器専用アニメーション、リディアさんに野生味を持たせるなんてのも可能です。IEDと併用すれば、「短剣を腰背面に納刀」「盾を背中に背負う」といった状態に合わせた、それぞれの抜刀アニメーションの自動切換えなんてことも。
priority設定には注意が必要で、例えば
priority1000000 mt_idle.hkx プレイヤ女性用
priority900 mt_idle.hkx Nord男性用
priority100 mt_idle.hkx プレイヤ男性用
みたいな構成にしてしまうと、プレイヤがNord男性の時は専用待機アニメーションが不発します。適用範囲が狭いほどにpriority上げると良いかも。
Smooth MovesetがまさにアイディアMODの1つで、感知されてない時に抜刀すると、「武器を抜いてるけども構えない」という、待機と構えの中間状態を作ります。感知されると構えます。これ結構個人的には目から鱗でした。この方のMODはどれも素晴らしい(〃▽〃)
Open Animation ReplacerとDynamic Animation Replacerの違い
使う分にはOARだけ入れておけば現状困らないのですが、moddingやファイル管理になると、それぞれの特徴が出てきます。正直どちらも捨てがたい。
OARはゲーム内でテストしつつ設定ファイル(json)を作れる反面、テキストエディタで大量の設定ファイルを作るには煩雑になります。一方DARはゲーム内での設定はできないものの、設定ファイルの書式が極めてシンプルで、テキストエディタで楽に作れます。
また、MOD毎のフォルダの中でpriority管理するOARは、同一アニメーションの差し替え以外であればpriority競合が許容されます。動作的にはお互い何もカチ合わないので。一方DARは、priorityフォルダ単位で全てのファイル(導入した差し替えMOD全部)を一括で条件管理する為、「MODごとに」という概念を持ちません。したがって複数のMOD間で同じpriority番号のフォルダが存在すると、即不具合になります(設定ファイルが確実に上書きされる)。全体像はDARの方が見やすいのですが、圧倒的に競合しやすいのもDARですね。全く無関係のアニメーション間でも、priority競合が許容されない為。
Behavior Data Injector
FNISやNEMESISでのbehaviorファイル更新無しで、jsonファイルからbehavior graghに新規のAnimation Eventsやアニメーション変数を追加できます。色々なMODの前提条件になっています。
Behavior Data Injectorは何ができるMOD？
新規追加したAnimation Eventを、用意したアニメーションファイルからannotationでトリガして、スクリプトやSKSEプラグインで使う等。behaviorのnodeを増やしたり、nodeの設定を書き換えたりはできないです。つまり新規アニメーションをこれだけで増やすことは不可能。
専業userであれば、前提MODで指定される為、とりあえず入れておくだけで問題無いです。特に設定することもありません。
対応MODによる使い方実例(Dynamic Sprint)
Dynamic Sprintを例に。スプリントの差し替えですが、初動に助走が発生した後にダッシュする独特なMOD(要OAR、Dynamic Animation Casting)です。これもSmooth氏作。
- Behavior Data Injectorで、新規Animation Eventを登録
- 上記を助走アニメーション(OAR高priority)のannotationでトリガ
- DACのspell起動、助走アニメーション維持条件のeffect付与(約1秒)
- 1秒後にeffect効果切れ、助走アニメーションの維持条件が失効
- 通常ダッシュ(低priority)にOARが差し替え
といった流れです。アイディア次第で用途が多そうですね！
Paired Animation Improvements
※20231205項目追記。書き忘れてましたぬ。
paired animation(ここではキルムーブ含む)における、バニラのannotation問題を修正します。
Skyrimの仕様で、paired animation(2キャラが同期するアニメーション)の時は、annotationからトリガできるAnimation Events名に制限があるようです。このMODの作者さんであるErsh氏が検証したところ、”NPC”もしくは”2_”のprefixが付いたannotation以外は無視されてしまうとの事。
annotation名が制限されると何が困る？
バニラのAnimation Eventsが大半使えないだけで十分問題ですが、具体例ついでに寄り道( ﾟДﾟ)
”Payload Interpreter”では、パンチのタイミングでfireboltを撃つ例を出しました。
0.433 weaponSwing.@CAST|0x12FD0|Skyrim.esm|1|1|0|0|0|0|0|20|20
0.533 HitFrame
さて、このタイミングを少しずらしたい、0.500で発動したい！と思ったらどうしましょう？
何のeventもないタイミングですが、「payloadはannotationに載せて使う」という絶対のルールがあります。とはいえ他のAnimation Eventを適当に使ったら、えらいことになるのは明白で。
payloadを積むだけの、何も起きない、誰も使わないAnimation Eventがあると良さそうですね！
そこでPayload Interpreterには、ダミーのAnimation EventであるPIEが用意されてます。ただ登録されてるだけなので、何も起きませんし、バニラや他のMODが使うこともありません。
0.433 weaponSwing
0.500 PIE.@CAST|0x12FD0|Skyrim.esm|1|1|0|0|0|0|0|20|20
0.533 HitFrame
こんな感じで書いておけばOKです。これなら殴りから少しdelayのついた、時刻0.5でfireboltがブッパされます(その筈…確認してないですが！)。
使い勝手の良いPIE、当然paired animationでも、使えれば色々な拡張が期待できますが・・・。
はい、prefix問題により使えないのです('_')…このままでは困りますね。
これだけなら、まだPayload Interpreter側に対応版をお願いする手もありそうですが、バニラのAnimation Eventsは名前変える訳にもいきませぬ。
これを解決してくれるのが、"Paired Animation Improvements"という訳です。prefixの制限を解除して、paired animationでも自由にannotationが使えるようになります。
PIEをAnimation Eventとして登録する為だけに、NEMESISを使います。アニメーションの追加や、behaviorのnodeを変更してる訳ではないです。つまりこれは”Behavior Data Injector”で代替可能な処理であり、Behavior Data Injectorのオプションに「Nemesis Less Patch」があります。アニメーションスロットの使用数削減効果
ちょっと僕の理解が怪しく、嘘ついてるかもですが。詳細は作者さんのdescriptionに書いてありますので、そちらで読んでください。
paired animationは、同期前の各キャラそれぞれのアニメーション(というかclip)をまずロードして、その後で2キャラを同期、結合した完成版アニメーションをゲーム内で作成してるようです。
この作業は該当behavior graphが読み込まれたタイミング(つまりゲーム起動時とかロード時でしょう)で実行される為、それだけアニメーション数の上限を圧迫する筈で。
"Paired Animation Improvements"は、この事前作業を中止させて、必要に応じて結合してるようです。その為、アニメーション数の登録数の大幅削減に繋がるとの事。
これ、もともとバニラで実装されてる機能らしいのですが、何故か未使用らしい？
ロード時に表示されるアニメーション数は変化無さそうですが、これは取り込んでる分だけ勘定してるんでしょうね。実際はそこから内製で更に増えてる、といった所でしょうか。もしキルムーブのタイミングでCTD起きるとかであれば、関係あるかも？
Paired Animation Improvements
www.nexusmods.com
自分用に書き溜めたメモをまとめて手直しした感じですが、結構量が増えてしまった・・・
最後までおつかれさまでした！
