ツクール制作におけるシステム設計の話

こんにちは。
この辺でシステムのお話を一度まとめておこうと思います。
ここまででゲームの原案とおおまかなシナリオができました。
次はこれらに沿ってゲームを効率的に制作できるよう、システムの設計を考えていきます。
といっても今回は実は私が以前に作ったシステムがある前提で話が持ち上がっているため、これをベースにする、少なくとも大規模な変更はしない前提での設計やスケジューリングとなっています。

あらかじめ用意するもの

小規模なミニゲームであれば思いつくまま順番にイベントを作っていく（＝手続き型的な書き方）をしてもいいのですが、ある程度の規模のものを作るとなるとこの方法では後々問題が発生します。

処理が効率化されていないので同じような処理を何度も書くことになったり、１箇所変更しただけで何十個ものイベントを書き換えなければならなくなる、といった具合です。

そういった事態を避けるため、ゲーム制作では共通して使いまわせそうな処理をあらかじめひとまとめにしておきます（＝関数型的な書き方）。ツクールではコモンイベントとして用意しておくといいです。

また、ツクールではスイッチや変数を名前で呼び出すのではなく、IDで呼び出しています。そのため行き当たりばったりで作っていては、新しいイベントを作る度にどのスイッチが何番にあるのか探すだけで余計に時間がかかってしまいますし、見やすいように後からIDを変更しようものならそれを呼び出しているイベントすべてで、呼び出すIDを変更する必要が出てきます。

こちらもあらかじめ使いそうなスイッチや変数、コモンイベントなどを列挙し、用途や場面ごとにまとまったID番号にまとめておくことで後々の作業を効率化することができます。例えばメインシナリオの進行に使うスイッチは１番～２０番、Hステータスに関する変数は１５番～３５番、といった具合です。その際、多少スイッチや変数を余らせておくと、後から何か思いついた時に使えるので便利です。

あらかじめ考えておくべき具体的なものは以下。

スイッチ（用途ごとにどういうスイッチ郡に分けるか考えておく）
変数（同上）
コモンイベント（こちらもID順に並んでいるので同上）
ステート
スキル
例えば本作では次のような分け方が考えられます。

Hシーン開放用スイッチ

Hシーン1開放
Hシーン2開放
Hシーン3開放
…
Hシーン10開放

Hステータス関連の変数

淫乱度
口開発度
乳首開発度
クリ開発度
膣開発度
アナル開発度
絶頂回数

戦闘中のエロ関連のステート

拘束された（ヒロインのスキル追加/封印、ピクチャの出し分けに使用）
拘束した（敵キャラのスキルタイプ追加/封印に使用）
絶頂（次のターン行動不能）
発情（挿入攻撃のフラグ）

シナリオ進行用のスイッチ

-- メインシナリオ1
シナリオ1-1消化
シナリオ1-2消化
シナリオ1-3消化
…
シナリオ4-3消化

共通するもの、使い回すものを先に作る

どのマップでも共通して使う処理や、複数のイベントで使い回すことになるであろう処理を先に作ってしまいます。

こうすることで実際にマップ上でイベントを作る際は、その処理をコモンイベントから呼び出すだけでよくなりますし、変更しようと思ったときもコモンイベント１つ書き換えるだけで済みます。

もちろん複数のコモンイベントが絡み合った処理を書き換えるような大規模な変更はしんどいですが…

本作の戦闘エロフローチャート（簡易）

処理を作るときはまずフローチャートを作ると、どういう状態が存在して、どの状態からどの状態に移行する可能性があるのか、どの状態とどの状態が共存する可能性があるのかなどが視覚的にわかるので便利です。

ということで本作戦闘シーンのフロー図がこちら

よくあるシンプルな戦闘エロのフローを作ったつもりですが、これだけでも意外と複雑で頭がこんがらがりました；

敵に拘束されるとHな攻撃をされるようになり、Hな攻撃を受けるとヒロインの性感ゲージが上昇していきます。そして性感ゲージがMAXになると絶頂、さらに発情状態となり、この状態で敵に拘束されていると挿入攻撃を受ける危険があります。

敵側にも射精ゲージがあり、挿入攻撃をすることでゲージが上昇、MAXになると射精して力が抜け、拘束中のヒロインを放り出します。ちなみに挿入と挿入継続でステートを分けているのは、挿入開始時に演出を入れられるようにするためです。

また、本作はHPバーと衣服の耐久値を別で設定しており、拘束状態になると衣服をひん剥かれることもあります。

この図を元にスイッチや変数といった裏側の処理、状況に合わせたピクチャの変更といった目に見える処理を組んでいきます。

この中で敵モンスターのピクチャは敵ごとに個別に設定する必要がありますが、ヒロインのピクチャ変更の処理は体勢ごとに使いまわせそうです。

また、性感ゲージや射精ゲージの上昇量計算や加算処理も使いまわせそうです。例外的に上昇量の多い敵モンスターや敵の攻撃スキルを設定する場合はそのスキルだけ例外的に直書きすれば良さそうです。

ではではそんな感じで、引き続き制作を続けていきます。

シナリオの大筋を作る

さてさて、ゲームシナリオの方もそろそろ決めていく必要があります。
ということで今回はシナリオのお話。

ゲームの制作工程におけるシナリオ

「小夜（仮）」完成予定日とゲーム原案で、ゲームの全体像はざっくり決めたわけですが、次はシナリオの大筋を作っていきます。

というのも、「ゲーム」が一つの「物語」である以上、登場するキャラクターも必要なマップもキーアイテムも、全てはシナリオに沿って決まるわけです。

モノによっては世界観が先行して決まっていたり、先にキャラクター設定がはっきり決まっている場合もあるでしょうが、ここで一旦それらを一つのシナリオにまとめあげておく必要があります。

さて、現状では本作プロローグで起きる問題（小夜が妖怪に攫われて監禁される）とヒロインの目的（妖怪屋敷からの脱出）については決まっているわけですが、これは物語の起承転結でいう「起」が決まっているだけです。

これをもう少し掘り下げてみましょう。（といっても内容のすべてをここで語るわけにはいきませんし、「転」についてもネタバレを避けたいので書ける内容はかなり限られますが）

ゲームの進行役としてのメインシナリオ

ゲームにおけるシナリオには
「物語としてプレイヤーに楽しんでもらう」
だけでなく、
「ゲームの進行役」
としての役割があります。

「現在メインシナリオの進行度がここだから、行けるマップはこことここ、入れる建物はこれ、発生するイベントはこれとこれ」といった具合です。

この「進行役」としてのシナリオはいわばゲームのメインシナリオを何段階に分けるか、といった具合で機械的に決めていきます。

本作は

戦闘中のエロ
異種姦
をテーマにしている以上、敵モンスターとの戦闘が発生します。

予定している敵キャラクター10体を、プレイヤーに飽きさせずに楽しんでもらうために

どれくらいのペースで新しい敵キャラが登場すればいいか
どれくらいの敵モンスターとの戦闘を体験してもらったタイミングでシナリオを一区切りすればいいか
といったことを考えます。

このゲームはモンスターとの戦闘をメインに据えている以上、シナリオはそのシチュエーションを引き立たせるための演出でありスパイスです。

敵が出てきて倒すをずっと繰り返しているだけでは単調になってしまいますし、シナリオに力が入りすぎて敵が出てこなさすぎるようではコンセプトから外れてしまいます。

本作では敵キャラクター合計10体を予定しているので、それを次のように割り振ってみます。

通常モンスター6
ボス級モンスター3
ラスボス1
こうすると1ステージにつき

通常モンスター2種類
ボス級モンスター1種類
のセットが3つできて、ラスボスが余ります。

ということはこのバランスを基準に新しい敵モンスターを登場させたければ、シナリオの進行段階を4段階に分ける必要があることがわかります。
（ラスボスマップで新らしい敵を0にするのか、いくつかのマップで通常モンスターを1にしてバランスを取るのかなど調整余地はありますが）

新たな章に突入
新たな敵モンスターと戦える（襲われる）ようになる
章クリアフラグを立てる
新たな章に突入
を繰り返しながら物語の全貌が明かされ、エンディングに近づいていくわけです。

プロット（ストーリーの要約）を作る

物語の章数が決まったところで、もう少しだけ具体的になるようシナリオを掘り下げます。もちろん詳細なシナリオはゲームの制作を進めながら決めていってもいいのですが、中間地点くらいは予め決めておかないといつの間にかシナリオが横道に逸れていってしまいます。

例えば本作の始まりは
「歩き巫女として旅を続ける小夜が妖怪に攫われ、監禁される」ですが、これだけではいざゲームを作ろうとした時に

• 小夜が「旅する巫女」だとどうやってプレイヤーに伝えるのか
• どこにいて、どういう経緯で攫われるのか
• 妖怪はなぜ小夜を攫ったのか
• 監禁されている状態からどうやって行動可能な状態になるのか
  など、決まっていないことが多すぎてすぐに手が止まってしまいます。

これをもう少しだけ掘り下げます。

■プロローグ
小夜は歩き巫女として修行の旅の途中とある村に立ち寄っていた。
しかし村は大妖怪に襲われ、小夜は攫われてしまう。
牢に繋がれた小夜だが、欲情してIQ3になった看守をすんでのところで倒し、牢から脱出。
小夜は大妖怪の住む巨大な屋敷（魔王城的なもの）から脱出できるのか。
もちろん大妖怪は絶倫！捕まったら大変なことに…

• 最初の場面は村
• 小夜が巫女であることは服装と村人との会話でプレイヤーに伝える
• 村人との会話で小夜が巫女として旅をしていることをプレイヤーに伝えることができる
• 小夜が監禁状態を脱し、行動可能になるまでの経緯

ざっくりですが、これだけでもだいぶ見通しが良くなりました。

こうやってシナリオの大筋を決めて具体的なセリフや演出を作り始めれば、制作はスムーズに進みますし、大筋を決めている段階でシナリオがおかしなことになっていないか、きちんとゴールに向かってシナリオを進められているかどうかを確認することができるため、作者本人がシナリオの中で迷子になってしまうのを防ぐことができます。

ということで、今回はここまでです。
引き続き制作頑張ります！

戦闘エロをアニメーションにできるのか！？するのか！？

システムのお話が続いています。
前回の記事、Live2Dモデルをそのまま表示するのではなく、動画化することで、RPGツクールMZの戦闘シーンで立ち絵アニメーションを表示すること自体はできました。

ただこれで万事解決、というわけにはいかず。
というのもアニメーションできる代わりにいくつか制約が出てきて、それが元々の設計とうまく噛み合わない問題が発生しています。

今回やりたい戦闘エロ

詳細は別記事で書こうと思っているのですが、今回やりたい戦闘エロははっきりしていて、それを表現するためのシステムも既にある状態からスタートしています。
ただしこのシステムは画像の差分で表現する前提で作ったもので、20以上のレイヤーを使い分けることでやりたいことを実現しています。
これと今回発見できた戦闘アニメーションの実現方法がやはり噛み合いません。

複数レイヤー使った場合にモーションの同期が難しい問題

静止画と違いアニメーションは動いています。
こちらの記事でも触れましたが、表示した複数のレイヤーでモーションがズレていると、透過部分から後ろのレイヤーが見えてしまいます。

レイヤーのモーションを完全に同期させればズレは起こらないはずですが、それを実現するには、それぞれのピクチャに連動するスイッチを用意し、ピクチャが表示/非表示されるたびにそれらを操作、そして表示されているすべてのレイヤーのモーションを初期化する、という処理が必要になります。
（実装自体はできそう）

ただこの実装に（バグ修正やテスト含め）結構時間がかかりそうなのと、仮に実現できたとしても、要は動画を10個とか同時再生することになるわけで、プレイヤーが普通のPCを使っているとするときれいに同期できないのではないか、という懸念があります。

ということで他の作品を色々参考にさせて頂いていたのですが、やっぱり動画を複数レイヤー同時再生して差分表現してやろう、みたいな作り方は見当たりませんでした。（そりゃそうだ）

1レイヤーで全部条件分岐させる方法

となるとあらかじめ全パターンのアニメーションを動画で用意しておいて、関数を分けるなり条件分岐させまくって状況ごとに適切なアニメーションを1レイヤーだけ表示する、という脳筋戦法が思い当たります。
というか現実問題そうよね。

つまりこれまで
・小夜胴体立ち
・小夜表情恥じらい
・服破け具合1
みたいな感じで分けていたファイルを
・小夜胴体立ちの表情恥じらいの服の破け具合1のファイル
みたいな感じで全ファイル分けて作っておく必要があります。

今回けっこうしっかりパターンを作ろうと
体位3パターン
表情6パターン
衣服破損度4パターン
敵拘束3パターン※正確には未定
敵前戯3パターン×3箇所の計9パターン※正確には未定
敵挿入
みたいな感じで考えていたので、例えば↑の例でも1944の動画が必要になる計算です。
現実的ではありません。
※しかも今ざっと列挙しただけなのでまだ抜けてる可能性もある。

パターン数を削ってみる

ということでアニメーションをやるならパターン数を削る必要があるだろう、と。
体位を1つにすれば648動画。まだ多いですね。
衣服差分も削って162動画にしてようやく現実的なレベルでしょうか。
しかしここまで削るとなると

• 動くけどパターン数が少ない
• 静止画だけどパターン数が多い

のトレードオフとなり、悩ましいところです。

動画の差し替えには時間がかかる

さらに追い打ちをかける問題が。
なんとかパターン数を調整して実装しようとしていたのですが、同レイヤーへの動画の差し替えの際、読み込みに時間がかかり一瞬キャラが消えてしまう問題が。

※動作テスト用には他作品様の動画をお借りしたのでテスト動画はここに載せれません。文章だけの説明になってしまって申し訳ないです。

これは通常時→拘束時みたいなタイミングでは気にならないのですが、服を破かれた時にさえキャラ全体が一瞬消えてしまうのは気になりすぎます。
これではゲームへの没入感を削ぎ、現実に引き戻されてしまう。
これだとアニメーションできてもユーザー体験としてもむしろマイナスまであります。

動画の読み込みだけ先にやってしまって、差し替えを遅らせればどうかとか試しましたがどうも表示自体に時間がかかってしまうらしい。

一応対処法はあって、分類ごとにレイヤーを当てて、次の動画を画面手前のレイヤーに当ててから、奥のレイヤーを消すことで、シーンのシームレスな遷移は実現できます。
例えばレイヤー1が表示されている場合

• レイヤー2を表示
• ウェイト30フレーム
• レイヤー１を消去

※実際は表示したレイヤー以外をすべて消去（どの絵からどの絵に遷移するかランダムなため）

みたいな感じで実装するわけですね。

ただここで透過部分から後ろのレイヤーが見える問題が再発。
それなら透明部分をなくしてしまえばいいではないかと、動画自体に戦闘背景ウィンドウっぽいものを入れてしまう案を考えたり。

戦闘エロをアニメーションにできるのか！？するのか！？

そんな感じで色々試行錯誤していた1月でした。
この他にも小夜は動かなくていいのではないか、小夜の静止画の手前レイヤーで敵のエロ攻撃の方だけアニメーションにすればいいのでは、とかも考えましたが、そうこうしているうちに1月が終わりそうな勢いです；

結論としては、戦闘エロのアニメーションは「おそらくできる」のですが、「やらない」ことにしました。一番最初の計画通り、戦闘エロについては画像の差分で表現しようと思います。（その代わりパターン数はしっかりあるよ！）

• 発生する制約があらかじめ考えていたゲームの設計と合わないこと
• 今のところどうにかできそうな気配は見えているものの、また何かしら想定外で詰まりながら進めていった場合、開発に1年くらいかかりそうなこと
• 1作目ということもあり、そこまで時間をかけず、まずは作品のリリースを目指したいこと

など総合的に判断しました。
ただ敗北Hなど戦闘以外でのイベントにはLive2Dをそのまま使うこともできますし、どこかしらアニメーションは入れたいなーとも思っています。

そしてアニメーションをやるとしたらどんな感じになるのかはけっこうわかったので、次はこの前提で最初から設計してみたいですね。

ということで、長くなりましたが1月の総括も兼ねて、ということで。
引き続き制作頑張ります！

RPGツクールMZの戦闘シーンでアニメーション立ち絵を実装する方法

システムのお話。
前回の記事、Live2Dプラグインでは戦闘シーンでLive2Dモデルを動かせないと判明しました。
なので戦闘シーンをアニメーションにするための方法を色々模索してみました。

別のLive2Dプラグイン

前回とは別のプラグイン、PictureLive2D.js
を試してみたのですが、会話シーンでの表示から失敗しました。
何か設定をミスったのかもしれませんが、そろそろ時間がないので詰まった時点でこの案は却下。

Live2Dモデルではなく動画ファイルで戦闘アニメーションを表現する

他のサークルさんの作品データを覗いてみたところ、どうも戦闘シーンはLive2Dモデルをそのまま動かしているのではなく、動画化したものを動かしていました。
なのでこっちのプラグイン、MoviePicture.jsをテスト。

Live2Dモデルのモデルとモーションをあてた動画を出力。直接出力できるのはmov形式だったので、変換にはFFmpegというフリーソフトウェアを使っています。

んでプラグインの説明どおり、動画を準備→表示。

テスト

キターーーーーーーーーーーーーーーーーーーーーン☆

とりあえず戦闘シーンでアニメーション立ち絵を表示することができました！

【悲報】Live2Dモデル、戦闘画面で表示されないってよ（号泣）

困ったことが起こりました。
戦闘シーンでLive2Dが使えない可能性が出てきました。

何が起きたのか

前回の記事で小夜のLive2Dオリジナルモデルを動かしてみたわけですが、ふと思ったことがありました。

そういえばこのプラグイン「会話表示中にLive2d(cubism4.0)でキャラクターを表示させるプラグインです。」て書いてあったんだよなぁ、と。

ツクールの仕組み的にはオリジナルのスキルを作って、その効果にコモンイベントを指定することで、戦闘シーンでもプラグインコマンドやスクリプトの実行ができる。
はずなのですが、プラグインの説明にわざわざ会話表示中にと書いてあったのが引っかかっていました。

そして引っかかったことをド忘れしていました。
先にテストするべきだったよ。イラスト担当さんごめん。

一応、敵グループのバトルイベントに指定してみるとか、戦闘を発生させるマップイベントで指定してみるとか、そもそもコモンイベントではなくプラグインコマンドを直接記述してみるとかしてみたのですが、いずれも表示できませんでした。

少なくともこのプラグインでは戦闘シーンでLive2Dモデルを表示させることはできなさそう。
※調べてみたら、Live2D側がツクールの描画システムであるpixi.jsのサポートを切っている、とか色々ありましたが、その辺はここで書いてもややこしいだけなので割愛します。

代替案

ということで今考えている案はざっくり3つ。

別のLive2Dプラグインを使ってみる

実は上で挙げたものの他にもRPGツクールMZでLive2Dモデルを表示、動作させるためのプラグインは見つけています。

https://makonet.sakura.ne.jp/rpg_tkool/MVMZ/PictureLive2D/document.html

ただ、ざっと調べたところツクールとLive2D自体の相性があまり良くないようなので、同じことが起こる可能性があります。

正直望み薄。

Live2Dモデルではなく動画ファイルで戦闘アニメーションを表現する

戦闘エロアニメーションを実現している他のサークルさんの作品を覗いていたところ、戦闘シーンのアニメーションに関してはLive2Dではなく、mp4動画ファイルで実現しているものがありました。

こちらもプラグインがあり、動画のループ再生やポーズ、ウェイト、再生速度なども指定できるため、戦闘エロを表現することは十分可能。

今のところ可能性の高い選択肢の1つです。
（トリアコンタン様のプラグインなので動作はまず大丈夫）

戦闘シーンの描写は画像の差分を使って表現する

こちらは元々の案、画像とその差分を使って戦闘エロを表現する方法です。
実は今回の制作開始時点で私が過去に作ったコレ用のシステムが既にある状態だったため、この方法であれば確実に実現できます。

1作目でドン詰まって自然消滅…とかは一番嫌なので、某期日までに良い方法が見つからなければ、今回はこちらの方法を選択します。

その場合は敗北Hシーンだけでもアニメーションにできるよう挑戦してみるつもりです。

もう一つの懸念

実はLive2Dは戦闘シーンでの表示云々以前に、複数モデルで同時にモーションを再生し、その最中にモデルの表示/非表示（要は服の着脱や体勢の変更）をすると、各モデルのモーションがずれる、という問題も抱えています。

もちろん何かしらの変更が合った際に、表示されているすべてのモデルのモーションにリセットをかければこの問題への対処は可能なのですが、あまりにも条件分岐が複雑になり、バグの温床になる予感しかしません。

また、Live2Dモデルや動画を複数同時再生した場合、プレイヤーのPCが動作に耐えうるのか、という懸念もあります。
元の画像案ではレイヤーを10以上使っていたためさすがにそれは厳しいとしても、動画だと2つ3つ同時に再生するだけでも結構重そう…。

なのでこの点で大きく2つの方向を考えています。
戦闘エロのパターン数（体勢とか衣服破損度とか）は少なくなるけどアニメーション
戦闘エロのパターン数（体勢とか衣服破損度とか）は多いけど画像

なんにせよ、まずはLive2Dモデル、または動画を戦闘シーンに差し込めるかどうかですね。
引き続き頑張ります！