こんにちは、しぇらです

ウディタだと基本システムを使用している場合、何もしなくてもメニュー画面を出したりできます
とっても楽ですが慣れてくるとメニュー画面を改造してみたくなったりするかもしれない
背景を変えるぐらいなら非常に簡単なのですが、何かしらカスタマイズしたりイベントが一定まで進んだらコマンド数が増えたりなど、基本システムのみではできないことが多々あります
今回は実際にメニュー画面を改造してきた記録を残してみようと思います

①そもそも基本システムの中身はどうなっているか

基本システムにおいて、メニュー画面を出すコモンは大雑把に2つに分かれていて、「X[移]メニュー描画」と「X[移]メニュー起動」です
前者が実際の描画群、後者がメニュー実行中の実処理を担っています
その他、キャラクター欄や装備欄などは別途で用意されています(コモンイベント91~124あたりが該当)
また、コマンド数の実際の計算は「X┗[移]メニューコマンド算出」で行われています
ですので、改造を施す場合は

・描画処理→「X[移]メニュー描画」
・コマンド数や一定フラグでのコマンド数増減→「X┗[移]メニューコマンド算出」
・メニューから各コマンド起動→「X[移]メニュー起動」

といった感じになります
見た目を気にするなら「X[移]メニュー描画」、各コマンドに特殊処理を入れたい場合は「X┗[移]メニューコマンド算出」、「X[移]メニュー起動」といった具合でしょうか
UDB 17：システム基本設定にてコモンを使った呼び出しはできるのですが、そもそもアイテム表示を作った！とかであれば「X[移]メニュー起動」にて適切なコモンを選択すればそのコモンを使用することができます
個人的には「X[移]メニュー描画」が最も改造が入って、「X┗[移]メニューコマンド算出」は一定箇所まで進むとコマンドを解放する処理を入れる、「X[移]メニュー起動」ではメニュー起動禁止処理を入れたり自作コモンに入れ替えたりしたぐらいでした

基本システムってセーブ許可禁止設定はあっても、意外とメニュー起動そのものを禁止する処理がないのよね
まぁここは非常に簡単ですので、実際に改造した個所でお話ししましょう

②必要ないものは全部取っ払え

RPG だとキャラクターのパラメータ表示だったり装備欄、お金の表示が必要だったりしますが、そうではない場合は結構邪魔ですよね
ということで取っ払います

・キャラクター描画：X[移]キャラクター欄描画
・装備：X[移]装備画面描画
・セーブ・ロード画面：X[移]セーブ・ロード画面描画
・システム設定：X[移]システム画面描画
・お金：X[移]メニュー描画 - おまけ欄（所持金）を表示(218~)

ざっくり分けるとこんな感じです
もちろん、実計算や内部処理は別のコモンで行われているものもありますが、とにかく表示しないを目指します
なぜなら、実処理を先に消すと面倒なことになる場合があるからです
例えば別コモンから呼び出されていたりね…
それでエラーを吐くことはしばしばです
基本コモンなので、間違えて消した！とか確認のために見たい場合なんかはすっぴんの基本データを作成したData を作成しておけば元に戻せます
ウディタは複数を同時起動できるので何かあればね、すっぴんのウディタを起動してコモンを引っ張ってくればいいんです

③実際に改造しよう～メニュー描画編～

では、メニュー描画の改造を進めます
まずはメニュー描画がどのようになっているかの確認をしてみます

・10000：背景
・10001：メニュー欄背景
・10002：カーソル
・10003~10008：コマンド名
・10011：おまけ欄 - 背景枠
・10012：おまけ欄 - 文字列

なにも追加しなければ10008までですが、UDB では8つまでコマンド欄が追加できるので実際は10010まで表示できます
これをもとに必要な箇所を改造していきます
「夢魅の窓」では背景、カーソル、コマンド名のみ使用していましたので、まずは必要のない箇所を削りました

これはデバック画面にてF7 を押すと、使用中の画像がどの行で表示されて、更新（移動）して、エフェクトはどの行でかかっているか、が確認できます
その情報を基に該当箇所を削っていきます
そのたびに動作確認は行ってください
場合によってはカーソルを動かしたらコマンド名の位置が動いた、とかカーソルが画面外に行った…みたいなことがありますので

あと、それに連なっている計算処理はむやみに消さない方がいいです
計算結果を辿ってみると、消してしまった計算処理とつながっている、ということが往々にしてあります
割と変数が使いまわされています
消すならピクチャ表示とかピクチャエフェクトの命令を消した方がいいです

ではコマンド名の表示も改造していきます
基本システムでコマンド名の表示は文字列を表示していますが、別画像に差し替えたいみたいな場合もあるでしょう

こんにちは、しぇらです

ウディタには基本システムという、ゲームを作るための詰め合わせデータセットがあります
これを使って好みで設定してしまえば、大体の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周年ですから、それに向けた作品です
頑張ろうね

こんにちは、しぇらです

前の記事で立ち絵とメッセージを同時に出すコモンを作成しました
で、立ち絵今回使う分をすべて描いて、実際に導入してみたのですがまぁーーーーー重い！！！！

色々探ってみたのですが、やっぱり大きな画像は読み込み時に重くなるっぽいなぁと
ウディタにはデバック時、実際の処理速度をリアルタイムで確認することができます
それを見ると、1500 とかに到達するわけです

なめているのかと
重すぎです
たいていの場合、60fps で作成する場合が多いかと思いますのでまぁ大体16~17 ms を超えると処理落ちします(1000(ms)/60(f)=16.66...)
処理とかをしていない場合、大体0.1~0.3 ms に収まるのですが、画像表示をするとそれが1500 ms になるわけです
まともにデバックできない

では、事前表示をして軽くすればいいのでは？とも考えましたが、それをやっても重たいのです

仕方がない、コモンを修正するか
ということで改修結果はこんな感じ▼


じゃあ何が変わったの？という点について
①立ち絵1つ＝1枚ずつで処理
今までは、立ち絵すべて＝1枚にしていて重くなっていたわけです
もう単純です
それをやめればいいのです
正直10*12(1つ約250*600) ですらだめなのか…となっていたのですが、どう考えても縦7000 px は大きいのです
そして今回はデモ版きっかりですから、それ以降で立ち絵が増えます
なんなら描いたうえでゲーム画面上で表示して、表情足りないな？となったらその場で新規追加しています
毎回毎回画像編集するの大変なんだぞ！
それだったら1枚ずつになった方が楽だね

②個別フォルダに対応
上記で話した通り、困ったぐらいファイル枚数が多いわけです
ウディタは基本システムを使用する場合、データ生成時にデフォルトでPicture フォルダがありますが、これだけで管理できるわけないだろ
ということでPicture フォルダ以下に個別フォルダを追加しました
これで各キャラごとに管理・表示をするわけです
立ち絵の枚数やキャラ数が少なければ、こういうことをする必要はないのですが今回はそこそこ人数いるので…

こんな感じです
多分枚数が少ない、とかであれば前の記事のコモンの方がいいし枚数がめっちゃ多い、みたいなときは今回のコモンの方がいいと思います

んでこれ、多少改造は必要ですが画像を連番にしてループさせることで、疑似的に動いているように見せることができると思います
いわゆるLive2D 風です
例えば、

1.表示、非表示用の変数を用意
2.表示=1 のとき指定した連番画像をループさせる
3.非表示=1のときループを中断処理し、指定した画像を削除する

みたいなね

というわけで改造編でした
場合によって使い分けてくださいね
それでは～

こんにちは、しぇらです

ウディタで動画を流せるようになりましたね、ずいぶん前に
ウディタ公式では、.ogv を推奨しています
…聞いたことねぇファイル形式だな？

軽く調べてみると、動画フォーマットの一つで .ogg で保存されているそうです
なるほど、.ogg なのか
ウディタでの音声推奨フォーマットは .ogg なので、割と納得いきます

僕は普段AviUtl で動画制作もしているので、環境は揃っています
「ほな、AviUtl で直接 .ogv を出力すれば楽じゃん」となったので、備忘録兼ねて書いていきます

※基本はAviUtl で書いていきますが、AviUtl2 でも動作することを確認しています

①AviUtl(2) のダウンロード
下記サイトからダウンロードしてください▼
AviUtlのお部屋

AviUtl の場合
aviutl110.zip とexedit92.zipをダウンロード→解凍
exedit92.zipで解凍されたファイルは同じくaviutl110.zip に解凍されたファイルに入れてください

AviUtl2 の場合
最新の.exe をダウンロード→起動
これで完了です
頻繁に更新がされているので、明確にこの.exe というのは現状ありません
必ず最新のファイルをダウンロードしてください

AviUtl とAviUtl2 の違い
どっち入れればいいの？の結論は簡単にいうと
・簡単な編集だけでいい→AviUtl2
・編集も凝ったものをしたい→AviUtl
かと現状は思います

理由は簡単で、AviUtl の後継版がAviUtl2 なのですが、まだまだベータ版だからです
僕はどっちも触っているのですが、機能の充実という点ではやっぱりAviUtl の方が圧倒的にプラグインが多いのです
AviUtl2 は更新も活発だし、そのうち移行できるといいなぁ

ちなみに、「黄昏還る箱庭にて」はAviUtl2 の基本機能のみで作成しています(出力にはプラグインを使用しています)
あれぐらい簡単な編集であれば、AviUtl2 で全く問題ないと思います


②ffmpegOut のダウンロード
そもそもFFmpeg ってなんぞや？という話ですが、オープンソースのメディアエンコーダです
大体のメディアを読み込み、変換、出力、果てには簡単な編集までできてしまう非常に優秀なソフトウェアです
で、これをAviUtl で使用できるプラグインがあるんですね
それがffmpegOut です

下記Github からダウンロードしてください▼
GitHub - rigaya/ffmpegOut: Aviutlのffmpegを使用した出力プラグイン

ダウンロードはReleases をクリックしてLatest ラベルがついているものをダウンロードしてください
AviUtl とAviUtl2でダウンロードファイルが違うので気をつけてください
導入方法については、Github に詳しく書かれているのでそれに沿って導入してください

ついでに、これも入れておくといいよっていうプラグインも書いておきます
導入方法は各プラグインの導入方法に従ってください
●L-SMASH Works：入力プラグイン

• 入れておくと大体の主要なファイル(.mp4, .mov ...etc.)を導入できるようになる

●InputPipePlugin：AviUtl 用の入力プラグイン

• 上記のL-SMASH Works と一緒に入れると動作が軽くなる
• ⚠️AviUtl2 に入れても意味がないです、多分バグります

●x264guiEx：出力プラグイン

• 入れておくと主要な動画ファイル(.mp4 など)で出力できるようになる
• これと同様のx265guiEx という出力プラグインもある
• 違いはエンコーダの種類
• x265 の方が優れてはいるが、youtube などのストリーミングサイトに上げるならx264 のままで十分

③設定&出力
何かしら編集などをして出力をします
出力→ffmpegOut を選択します
設定を押して、下記のようなコマンドを入力します

-codec:v libtheora -qscale:v 10 -codec:a libvorbis -qscale:a 9

ものすごく簡単に解説しておきます
-codec:v libtheora ：動画コーデックでTheora を使用
-qscale:v [num]：ビデオの品質[0~10]
-codec:a libvorbis：音声コーデックでVorbis を使用
-qscale:a [num]：音声の品質[0~10]

実際の設定画面はこんな感じ▼

※画像はAviUtl のものですが、AviUtl2 も同様の設定で問題ありません 

これで出力すると、.ogv の動画が完成します！
お疲れさまでした！

ちなみに、今後もこの設定で出力する場合は保存をしておくと、わざわざ書き直したりする必要がなくなりますよ
左上の歯車ボタンをクリック→新規保存 でテンプレートの保存ができます

もし、エラーが出力された場合エラー文を読んでください
たとえば「○○が見つかりません」みたいなエラー文は、大体ライブラリが足りない場合に出てきます
ダウンロードしてきたFFmpeg ファイル下のbin を見てみると、.dll というものがあります
これをAviUtl のexe_file フォルダにコピペしてください
これを導入すると、大体の場合は出力が開始します

そもそも.dll って何よって話ですよね
Dynamic Link Library と呼ばれていて、単語の頭文字をとってdll です
簡単に言うとプログラムの一部品のようなものです
必要な部品が欠けているから出力できないよ、みたいな感じです

一応、コマンドを入力しなくても出力はできるのですが、画質が微妙になります
あとは、コマンドを入れない場合でエラーが出るときもあったので、コマンドを入力しておいた方が確実だと思います

FFmpeg で出力する場合、多少の知識とコマンドを理解しておく必要があるのですが、ffmpegOut を使用すれば、そういったものをスルーすることができます
また、元々サンプルが用意されているので、それを選択するだけで出力するための設定が完了します
もちろん、今回のような特殊な設定をしようとする場合は調べたりする必要が出てきますが…

FFmpeg を導入すれば、別にAviUtl でなくてもcmd でコマンドを叩いて変換できるのですが、編集したものを出力するなら1回でできたほうが楽ですよね
意外と「ウディタで.ogv を導入しよう」とか「AviUtl で.ogv を出力しよう」みたいな記事が見当たらなかったので、気合いで作りました
(.mp4 の記事ならたくさんあるのですがね〜…)

今回はこんな感じで
それでは〜

---

参考URL
"TheoraVorbisEncodingGuide",  FFmpeg, 2019(Retrived on November 25, 2025)
https://trac.ffmpeg.org/wiki/TheoraVorbisEncodingGuide

こんにちは、しぇらです
現在次回作のデモ版を出すにあたり、着々と作業を進めている次第です
なんか元々マップ関連を曲を作る予定なかったのに作っているので、気づくと作業量が増えています
おかしい…

前回、メッセージウィンドウを好きにやったついでに自動改行とかできたら楽じゃね？と思い、いろいろ調べていました
なんとVer.3.5以降なら隠しコマンドを使用することで改行できるようになったみたいです
なんて便利だ…

じゃあ、もうあれだし文章と立ち絵を同時に出すコモンを作ったらそれはもう無敵だ（作業がだいぶ楽になるため）となったので、今回進めていきます

使用バージョン：Ver.3.633
※Ver.3.5以降必須です

先に立ち絵コモンを作成しましょう
今回は、画像を縦横分割して表示する方法を取ります

まずユーザーDB に新しいタイプを追加します
項目は「ファイル」「縦」「横」を追加します
ファイルは「▼特」をクリックして、ファイル読み込み（文字列）を選択します
初期フォルダは立ち絵を置いているフォルダを選択していると、後々の作業が楽になります
縦横は「数値」を選択します
ユーザーDBの設定は以上です
表示したいキャラを置いておきましょう



次にコモンです
セルフ変数は以下の通り設定しておきます
CSelf35, 38はなくても別にいいです、調整用に使用しますが僕は使いませんでした
CSelf20は使うかなと思って設定しましたが、使いませんでした
なくても問題ないです


入力内容を設定します
項目は「表示」「表情番号」「画像」「立ち位置」「顔グラ番号」「文章」です
「表示」は「選択肢を手動選択」を選択して、「表示」「非表示」好みに応じて「半透明」とか準備します
「画像」は「データベース参照」を選択して、先ほど追加したものを選択します
「立ち位置」は「右」「左」があればいいかな、中央は好み
「顔グラ番号」は前回作成したコモンに合わせて、名前表示をするためのものです
文章と違い"@[num]"を使用して表示することはできません
そのため、表示のために専用で準備しておきます
「データベース参照」を選択して、「システムDB」の「顔グラフィック名」を選択します
「文章」は表示したい文章をそのまま入れます
自動改行処理を入れたコモンへ渡します
人によっては「反転」とかも追加するのかな
その場合は必要ない箇所を削ってください


コモンの中身はこんな感じ
  


そういえば、文字列のCSelfが1つ残ったので、中央表示を削れば画面へ最大4人表示させることができそうですね
僕の場合はそもそも最大2人しか写さないので必要性をあまり感じなかったかな

画面を4分割して1, 3本目の線の上に立ち絵が来るように調整しています

条件分岐にCSelf5[文章]が""以外の場合、つまり何かしら入力されていれば文章を表示できます
これをやっている理由は、立ち絵を2つ表示させているときに、片方の表示方法を変化させるときに例えば【透明になる→文章表示→別の画像を出現する→文章表示】のような動作を回避するためです

名前表示（CSelf4[顔グラ番号]）を-1にすると、前に表示した名前をそのまま表示できます
いちいち更新させるの、なんだかなぁと思っただけなので、この動作がなくても問題ないかと思います

上記で示した通り、CSelfを通す場合は文章で使用するような"@[num]"は使用できません
文章表示特有の機能だからです
ですので、ここで直接Sys0を操作しています

文章改行コモンは以下の通りです


ものすごく簡素になりました
文字列操作の隠しコマンド「指定幅で自動改行する」を使用しています
全角は2でカウントされるので、割り切れる数値を採用しいい感じに調整します
ここに関してはフォントや文字サイズとの兼ね合いもあるので、本当に自分で調整して好みを見つけるしかありません
文章だけを表示させるときはこれ単体でも使用できます

最終的にこんな感じになります
▼使用

▼左右同時

▼中央



※まだ立ち絵を描いていないので、例としてフリーペンシルさんを使用させてもらっています
ゆるっとしててかわいくていいですよね

僕は立ち絵の切り替えを頻繁にするし、文章を結構書くので全部まとめてやった方が早いなとなっているのでこんな全部を入れたコモンを作りましたが、分離させても問題ないです

こんな感じで、重たかった部分を解消することができました
あとメニューやセーブ・ロードも独自の物にするつもりなのでこっちの改造を進めていく予定なのですが…

だんだん形になってきてるのでいい感じです
このままデモ版は今年中に配信できるように進めていきたいですね

それでは～