こんにちは、しぇらです

ウディタには基本システムという、ゲームを作るための詰め合わせデータセットがあります
これを使って好みで設定してしまえば、大体のRPG を作成することができるとっても楽なものです
ただ、ほしい機能がなかったり、追加したい機能があったり、好みの動作ではなかったり…と、どうしても不満は出てしまう
かといって、空データからゲームが作れるか、と言われても非常に難しいです
これに関しては僕もまだできない
ならば、基本システムを改造してしまえ！というのが今回のお話です

今回作成したゲーム「夢魅の窓」はがっつり基本システムを改造して作成したものです
ほしい機能に関しては、一から作ったものもありますが、改造するにあたって困ったなーとか、つまづいたなー、みたいな部分を抜粋して書いていこうと思います

①メニュー画面の改造
ウディタといえば、こんな感じの画面ですよね▼


で、「夢魅の窓」のメニュー画面はこんな感じ▼


見た目はだいぶ違いますが、基礎は完全に基本システムそのままです

メニュー画面は、2つのコモンでできています
「メニュー起動」と「メニュー描画」です
見た目にかかわるのが「メニュー描画」、実際のシステム周りが「メニュー起動」となっています
どちらにも変更は加えましたが、かなり変わったのが「メニュー描画」の方
コモンの中身を見れば大体わかりますが、背景、メニュー欄背景、メニュー項目、カーソルを描画しています
今回必要なものは、背景、メニュー項目、カーソル
メニュー欄背景やカーソルを点滅させる必要なかったので、コードを削除する必要があります
こういった表示しないものやエフェクトに関しては、デバック画面でf7を押すことで画像番号、どのコモンの何行目で最終表示、移動しているかが確認できます
この情報を基にかかわっているコードの追加、削除、改造・修正を行います
正直これの繰り返しです
カーソル移動に慣性をつけたり、ゲームの進行度によってメニューの項目が増えたりなど、コモンを読んで、改造して、挙動を確認して、違っていれば修正、確認…
これを繰り返してメニューの改造を進めました

メニューの備忘録は今後作ろうかなと思っています

②アイテム欄の挙動
アイテム効果に「イベント起動」というものがありますよね
UDB で「イベント起動」で登録すれば、コモンイベントなんかを呼び出せるのでちょっと変わったこととかができます
今回の場合、画像を見せてキャンセルキーなどを押せばメニュー画面に戻る、という挙動をしています
アイテムを押していちいちメニュー画面閉じていたら、普通にストレスですからね
（原神の初期塵歌壺）
が、デフォルトのままだと「イベント起動」をするとメニュー画面が閉じます
なんで……

アイテム効果の起動コモンは「アイテム使用効果処理」というコモンです
これを確認してみると、道具の消費処理後メニュー画面の消去フラグのDB書き込み処理が走っていることがわかります
これが走ることによって、「メニュー起動」側でメニュー画面が消える処理が走るのです
そのコードを消して、処理を変えてあげればメニュー画面の消去処理はなくなります

ちなみに、UDB で「イベント起動」を指定するとき、コモン番号+500000 で設定できるのを知ったのはこれを調べているときでした
コモン番号が変わったらここも変えないといけないのは正直忘れそう

③小数点以下の扱い
正直割と困った
というのも、ウディタは仕様として小数点以下は切り捨てられ、最終的には必ず整数になるようになっています
なので、動作側も小数点になるであろうものは×1,000 されていたり
三角関数とか、√とかね
三角関数も√もまぁわかるのですが、この「×1,000 をする」仕様が最初謎だった
というか、「小数点が必ず切り捨てられる」を知らないと、この仕様の意味も分かるはずがないという

高速処理のために、float ではなくint が使われてるんだろうなぁと
float を使うのが割と当たり前だったので、弾幕を作っているとき本当に悩んだ

弾幕に関しては、もう少しお勉強が必要だなぁと思っています
彼女だからかなり加減していますが、そうじゃない場合の方が普通なので…

ウディタだと弾幕の作り方を扱っているサイトが結構少ないなぁという印象でした
特に当たり判定
なので、こちらは配布コモンを確認しながら進めていました
一番の肝は角度
これをループ中に計算させ、角度を変更していくかというのが派手な弾幕を作り上げるために必要な工程であると認識しました
いやぁ…ウディタの三角関数難しくてあまりきれいな弾幕を作れなかったので、ウディタにおける三角関数をもう少し勉強する必要があるなぁ
本編ではもう少しきれいな弾幕に仕上げたいです

④ピクチャ番号の整理
まぁこれは基本システムを改造している途中にどんどんわからなくなっていった、という方が正しいかもしれません
例えばメニュー画面は、何枚も何枚もピクチャを表示していくわけですが、何番から始まっているんだ？というところから始まります
これはコモンを確認したり、デバッグ中にf7を押せばわかることではあるのですが、基本システムってコモン内の最初のピクチャ番号を決めたらどんどん加算していくんですよ
直接指定しているわけではないのです
ですから、「実際これ何番だ？」ということになっていくのがオチという

ということで整理しました


これはNotion の画面です
何でもいいのでまとめられると継ぎ足していくときに、ピクチャ番号かぶりを避けることができます
実際割と助かりました

⑤思考の整理
今回の制作に当たって、Notion には結構助けられました
紙に書くことも結構あるのですが、最終調整やNPC の会話のようなちょっとしたことから思いついたことや実装手順、実装した感想、どこまで実装したかなど全部まとめています
制作した音楽やフォントを上げたり、参考にした動画やネタになりそうなリンクを貼ってみたり…
別にNotion である必要性はないのですが、何かをまとめて蓄積できる場所はあったら便利だろうなぁと思いました

なんでこの人紙にも書くの？と思われたかもしれませんが、僕は紙の方が圧倒的に思考を整理できるからです
キャラや世界観の初期案や本編文章、それに付随する一枚絵、マップ、キャラチップの動作、システム設計、パターンのアイデアなど、実際に軽く計算したり、こういう動きは欲しい！とか
まぁいろいろ書いたりしてみると思考の整理ができるのです
普段は無印良品の5冊セットのノートに全部書いています

この辺りは人によって思考の整理の仕方が違うと思うので、一例として挙げておきます
思考の整理、非常に大事

⑥動画再生機能に翻弄される
これは基本システムではないですが、知らん間に公開されていた機能について
とはいっても、動画再生機能自体はVer.2.26 から追加されたもののようです
まぁその…離れていた時期なので、僕は知らなくて当たり前なのですが(最終更新がVer.2.24 だった人間)
出力に関しては記事を書いたのでそちらを見ていただくとして
まぁ記事が少ないことこの上ない！
一応言っておきますが、みなさんご存じの.mp4 でも十分かと思いますよ
公式が「ウディタ内部で唯一再生できる.ogv が一番いい」って書いてあったので対応しました
本当にそれだけなのに、出力方法がわからん！調べてもマイナーすぎて記事がない！
いやまだ僕にはFFmpeg の公式サイトがある(英語)！大体のコーデックに対応してるんだから記事ぐらいあるやろ！…と、実は割と文句を言いながら調べていました

最終的に行き着いたのはReddit ではあるのですが、ここから公式に飛んで設定について調べました
AviUtl で出力する→できない→Theora が必要→どれに入っているかわからない→.dll を全部突っ込んでAviUtl とFFmpeg を起動した状態を比較する
…といった感じで、あの記事の裏では結構面倒なことをしていました
FFmpeg での出力もあまり見かけなかったし、AviUtl で.ogv を出力する記事は本当に見かけなかった

ちなみに、AviUtl2 でffmpegOut が更新されるたびに.ogv が出力できなくなるので(多分ffmpegOut に入っているFFmpeg が必要最低限だから)、毎回FFmpeg の導入しなおしをしています
※無印では触ってないのでちょっとわからんが、こっちはFFmpeg を直接導入する必要があるので、あんまりそういうことは起きないはず…？
地味にめんどい

動画制作とかしない方、cmd に抵抗がある方はWeb サービスや変換ソフトをご利用くださいませ
一般の方はcmd やPowerShell の画面が怖いと聞きますし(慣れたら全く怖くないヨ)
僕が書いたのは、動画制作をして実際に導入するかつ面倒がりの究極体みたいなもんなので

それから、実際の導入に関して
動画の総再生時間を取得する単位は[ms] でした
総再生時間を確実に取得できるのは.ogv だけみたいなので、頑張った甲斐があります
プロパティでいちいち調べるの面倒だしね！
取得した総再生時間を/1000して*60をすることで、実総再生時間(60進数)を合わせ、1ウェイトの回数付きループをさせています

また、初回起動後は特定のキーを押すとスキップできる機能も追加しました
流石に初回は見てほしいのでスキップされると悲しくなりますが、それ以降はプレイヤー側も1分半拘束されるのは「いやこれ見たし」ってなりますし

ここもまた疑問で、スキップボタンって何が一番適切なんでしょうね…
調べた感じだと、左Ctrl が多いみたい…？なので、それに従っています

⑦セーブ・ロードの仕様
今回セーブ・ロード画面もゲームに合わせたものに変更していました
あれは基本システムのコモンから必要なコードだけ引っ張って作ったものです

セーブ画面▼

セーブ後画面▼

ロード画面▼

※ロード画面もうちょっと派手にしようかなぁ

問題となるのがセーブした時点でのすべてがそのままセーブされるということ
つまり画像表示をしたままセーブをすると、ロード後画像が表示されたままなんですよね
基本システムでは、これを回避するために16フレームをかけて一度全画像を非表示にする処理が行われています
ただ、ほとんどのゲームが実際そんな処理しているようには見えないし、メニューを表示したままセーブが走っている…
という考えの下、「夢魅の窓」は画像表示されたままセーブが走るようになっています
これは「実際にセーブ処理が走る瞬間だけ表示中のすべての画像の不透明度を0 にして、処理が終わり次第すぐに不透明度を元に戻す」という処理が走っています
だからぱっと見は画像が表示されたままセーブされているように見えるのです

ただ、この処理だけだとロード後にメニュー画面を開くと、メニューが開かれないのです
ですので、メニューを開く処理の前に「下地が表示されている場合は削除する」処理を追加しています
最初はメニューを閉じる瞬間にもう一度セーブ処理が走るようにしていたのですが、それだとセーブをした後にリセットされる状況に対応できません
こういっためんど処理とかしなくていいように基本システムは組まれているわけですが…
まぁ、何事も実際に触ってみて初めて分かることとかありますから
基本システムは本当にうまくできているもんだなと改めて思いました

ロードについてですが、これはロードする変数をミスると普通に読み込めない
また、ゲームデータとシステム面のフラグを保存するファイルを分けて読み込ませるようにしています
いわゆるSaveData.sav とSystem.sav です
System.sav 側にちょっと変わった処理をしているので、SaveData.sav より先に生成されます
…これの影響で片方が存在しているだけでデータを読み込みできるようになってしまいました
こうなるとゲームデータがないのに続きからが押せるというトンデモ挙動に
「そんなもん読み込めませんけど」みたいなログが出てきて落ちます
なので、こういった挙動を防ぐために「どちらのデータも読み込み成功した場合」を追加しました
まぁこれは基本システムだとちゃんと回避されていると思いますが、こういうのを気にしないといけないんだなぁと改めて認識
タイトルの処理がどんどん長くなる長くなる

⑧UTF-8 BOMとマスク機能
イーストゲートのちょっとしたイベント「掲示板書き込み」
キャラたちの日常的な会話が見れたり、他キャラの先行出しだったりの役割を果たしてもらっています

実際の画面▼


その中で実際に選択肢を選んで書き込みを疑似的にできる…というイベントがあるのですが、内容については.txt 読み込みを使っています
書き込み内容を可変DB に書き込みさせたり、書いた文章が長めだったりで多分実装しているイベントの中で一番重い
ウディタではUTF-8 BOM を推奨しているからそれを作るかー…
メモ帳使いづら

Windows に標準搭載されているメモ帳は保存するときに自動的にUTF-8 BOM になるらしいのですが、普通に書きづらくね？となり、ついにVSCode を導入する羽目に
普段使っているので入れたくなかったのですが、使いやすさは何よりも優先される
そういえば、以前はShift-JIS だったように記憶しているのですが、Ver.3 からUnicode に変更されたみたいです
Unicode の方がいろいろな面からみても圧倒的に使いやすいのでこれは本当にいいアップデート

文章は完成したものの、じゃあ実際の表示方法はどうしようか
ウディタはVer.3.5からマスク機能が使えるようになったそうです
じゃあせっかくだし使ってみるかー、ということでいろいろ挙動を調査
結果として、マスク対象にするピクチャID を設定→実際にマスクをかける という処理をして初めてマスク処理が使えることが分かる
うーん、わからん
ピクチャID の設定と実際にマスクをかける処理は一緒にしてほしかった感がある
個人的には「(画像)の非表示範囲(白)追加」の方が作りやすかった感じがします

---

完成されたものにメスを入れるのは非常に大変です
なにせそのメスを入れた部分が原因で壊れることだってあるし、うまく動かない理由がその後の処理とうまくかみ合ってなかったりとか…、原因を探るのがまず大変
原因がある程度わかっても、修正をどうすればいいのか？とか、何を変えればいい？など、結局最後に求められるのは己の忍耐です

①前後の動作の整合性がとれていない
②使用する変数の番号を間違えている
③正しく変数が渡されていない
④実はメスを入れた部分はかなり大事な処理だった！
⑤無限ループを気づかぬうちに作っている（終了箇所を設定していない）
⑥変更したピクチャは分割しなくていいのに変更前のままにしていた
⑦ピクチャの指定方法や表示位置を間違えている
⑧計算した結果0未満になってしまい、全部0変換されている
⑨削除したコモンと実はつながっていた

うまく動かない理由を経験則だけで列挙するならこんな感じですかね

これは基本システムの改造に限らず、コモン制作、果てにはゲーム制作すべてに言えることなのですが、最後には自分でどうにかして、自分で解決しないといけないのです
そして何よりも非常に地味です
でもそれが当たり前だと思っているし、だからこそ完成したときの達成感は一入です

頭が動かないときはゆっくり休んで、少し置いてみるのもいいと思います
後で見返して「ここ変じゃない？」を見つけやすくなります
僕はこれをよくやっていました
適度な休憩、大事

あとはどうにもできないときは、配布コモンに頼るのも大事
というか慣れないうちは配布コモンをガンガン頼っていいと思います
今回、僕は個人で追加したコモンは全て作成しましたが、ベースは配布コモンの中身を確認したり、有志の解説や開発日記を読んだりして、真似するところから始まっています
某やどかりさん、某とかげさん、いつもありがとうございます

僕の恩師も言っていました
先人の誰かやってるからそれを真似して自分のものにすればいい、と

とにかく読んで、手を動かす
理解も大事だけどまずは動くようにする、完璧を求めない、完成を優先する、バグ取りはそこからでもいい
僕がいつもゲーム制作に対して持っているマインドです
とはいっても一人で作業している性質上、どうしても作業スピードは遅いので、そこまで早くできるわけでもないのですが

基本システムの改造は大変ですが、できるようになればやれることの選択肢が増えます
やりたいことを増やす、やれることが増える、それだけで表現の幅が増えます

「夢魅の窓」のデモ版は無事公開できましたので、次はがっつり本編！…の前にどうしても作りたいものがあります
そこまで長くならない（つもり）けど、「はねうさぎのこや。」として重要な作品にするつもりです
来年で【嘘吐きオオカミと後輩。】シリーズ公開10周年ですから、それに向けた作品です
頑張ろうね