2026
こんにちは、しぇらです
ウディタには基本システムという、ゲームを作るための詰め合わせデータセットがあります
これを使って好みで設定してしまえば、大体の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周年ですから、それに向けた作品です
頑張ろうね
ウディタには基本システムという、ゲームを作るための詰め合わせデータセットがあります
これを使って好みで設定してしまえば、大体の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周年ですから、それに向けた作品です
頑張ろうね
PR
2026
5月2日よりPC 専用フリーゲーム「夢魅の窓」を公開しました!
ダウンロードはこちらからどうぞ
■Download■
Windows 専用ゲームです
無料なので気軽に遊んでみてね
「幸福の定義」以来なので、5年ぶり?とかですかね…
ウディタの環境も随分と変わり、Ver3.5 になった恩恵を浴びつつ作成しました
今回は基本システムにメスを入れ、ウディタっぽさをなくすことを目標に進めてきました
チップもコモンも、何ならBGM まで作ってだいぶ時間をかけて作成してきました
いやはや人の執念とは恐ろしいものですねぇ…
この作品は過去作品とは切り離して作成したものです
まだまだデモ版ですが、今まで作成したものと長さがほぼ同等になってしまっているのが今回の作品の長さを物語っているかと思います
実際、かなり長くなる予定です
大体の導線の話をしておきますと、大マップが4つぐらい増えます
その中で大体どのマップも1時間ぐらいのお話が積まれる…と思っていただけたら
こんな長編を作るのが初めてですので、どうなるかはまだまだ未知数です
現在はBOOTH のみで配布していますが、配布先をもう少し増やしていく予定です
ふりーむは現在審査中ですが、審査自体がかなり厳しくなった影響で本当に通るかさっぱりでして…(主にルカ周りの表現がきついかも)
というか今回無事回避できても、本編になった場合にはもうちょっときつい表現が入ると思うので、今後ふりーむで登録する場合はかなりマイルドな表現になるかと思います
今回は割とマイルドな表現にしているし、実行しないことを口頭でちゃんと言ってるけどそれすらダメですって言われたら、僕はもうふりーむに投稿すらできなくなる
あとはCi-en と夢現が有力候補です
出せそうなところには出していけるようにしていこうと思います
これからもまだまだ制作を続けていきます
それでは夢と「悪夢」を楽しんでくださね!
ダウンロードはこちらからどうぞ
■Download■
Windows 専用ゲームです
無料なので気軽に遊んでみてね
「幸福の定義」以来なので、5年ぶり?とかですかね…
ウディタの環境も随分と変わり、Ver3.5 になった恩恵を浴びつつ作成しました
今回は基本システムにメスを入れ、ウディタっぽさをなくすことを目標に進めてきました
チップもコモンも、何ならBGM まで作ってだいぶ時間をかけて作成してきました
いやはや人の執念とは恐ろしいものですねぇ…
この作品は過去作品とは切り離して作成したものです
まだまだデモ版ですが、今まで作成したものと長さがほぼ同等になってしまっているのが今回の作品の長さを物語っているかと思います
実際、かなり長くなる予定です
大体の導線の話をしておきますと、大マップが4つぐらい増えます
その中で大体どのマップも1時間ぐらいのお話が積まれる…と思っていただけたら
こんな長編を作るのが初めてですので、どうなるかはまだまだ未知数です
現在はBOOTH のみで配布していますが、配布先をもう少し増やしていく予定です
ふりーむは現在審査中ですが、審査自体がかなり厳しくなった影響で本当に通るかさっぱりでして…(主にルカ周りの表現がきついかも)
というか今回無事回避できても、本編になった場合にはもうちょっときつい表現が入ると思うので、今後ふりーむで登録する場合はかなりマイルドな表現になるかと思います
今回は割とマイルドな表現にしているし、実行しないことを口頭でちゃんと言ってるけどそれすらダメですって言われたら、僕はもうふりーむに投稿すらできなくなる
あとはCi-en と夢現が有力候補です
出せそうなところには出していけるようにしていこうと思います
これからもまだまだ制作を続けていきます
それでは夢と「悪夢」を楽しんでくださね!
2026
こんにちは、しぇらです
前の記事で立ち絵とメッセージを同時に出すコモンを作成しました
で、立ち絵今回使う分をすべて描いて、実際に導入してみたのですがまぁーーーーー重い!!!!
色々探ってみたのですが、やっぱり大きな画像は読み込み時に重くなるっぽいなぁと
ウディタにはデバック時、実際の処理速度をリアルタイムで確認することができます
それを見ると、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のときループを中断処理し、指定した画像を削除する
みたいなね
というわけで改造編でした
場合によって使い分けてくださいね
それでは~
前の記事で立ち絵とメッセージを同時に出すコモンを作成しました
で、立ち絵今回使う分をすべて描いて、実際に導入してみたのですがまぁーーーーー重い!!!!
色々探ってみたのですが、やっぱり大きな画像は読み込み時に重くなるっぽいなぁと
ウディタにはデバック時、実際の処理速度をリアルタイムで確認することができます
それを見ると、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のときループを中断処理し、指定した画像を削除する
みたいなね
というわけで改造編でした
場合によって使い分けてくださいね
それでは~
2025
こんにちは、しぇらです
ウディタで動画を流せるようになりましたね、ずいぶん前に
ウディタ公式では、.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:入力プラグイン
③設定&出力
何かしら編集などをして出力をします
出力→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
ウディタで動画を流せるようになりましたね、ずいぶん前に
ウディタ公式では、.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.)を導入できるようになる
- 上記のL-SMASH Works と一緒に入れると動作が軽くなる
- ⚠️AviUtl2 に入れても意味がないです、多分バグります
- 入れておくと主要な動画ファイル(.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
2025
こんにちは、しぇらです
【Reinkarnation】は今年で5周年を迎えたので、嘘吐きオオカミと後輩と同様に実況をしていました
短編でしたので、結構早めに終われましたね
今回も完結まで駆け抜けたので、動画の話とか諸々の話をしようと思います
というわけで表人格かつ本来の小屋主さん
立ち絵は今後ちょっと直しましょう…
性格はかなり鬱屈としていますし、色々と諦めてしまっています
物語を書き、物語を保管し、物語を見届ける
そんなことを今は生業としています
本編ではぼかしてはいますが、しいさんは自分の生まれた世界ではずっと前に、すでに死んだことになっています
そして、うさぎちゃんもといファブラが生まれた地に手違いで落ちてしまい、それ故に『規則』と出会ってしまいます
本当の意味で死ぬか、海に呪われるか…
彼女は海に呪われることを選択し、試練を受け半分人間、半分海の怪物になりました
海に呪われることを選択したのは「そっちの方が生きていたころより上手く生きれる気がしたから」です
そしたら『規則』からめちゃくちゃ仕事を投げられるようにはなりましたが、しえやクラリオン、ファブラに囲まれて、海の外で生きていたころより楽しく生きていそうです
鎖骨にある模様は試練に通過した印であり、通行証でもあります
表情が変わりにくいしあまり笑わないのはデフォルトです、そのうち話します
見た目はほぼしいさんを受け継ぎ、性格はほぼ真反対です
よく笑い、ころころ感情を変え、ちょっぴり邪悪
…邪悪なのはしいさんの性格も多少は引き継いでいるからです
しえはしいさんから記憶と性格をある程度引き継いでいますが、ほぼ別個体です
ある程度なのは、しいさんがしえに渡した記憶が不完全だからです
だからこそしえはしいさんがあそこまで鬱屈とした子になった理由を知りません
「知りたいけど知らなくてもいいや!しいが元気ならそれでいい!いつか知れたらいいな」
ぐらいのスタンスです
ファブラのことを「うさぎちゃん」と呼んでいるのは名前を教えてもらっていないし、契約者ではない自分が教えてもらっていいのかわからないからです
しいさんは別に教えてもいいと思っていますが、自分から教えた方がいいだろと思っているので彼女からは教えないと思います
今後も基本的に表に出るのはしえではあるのですが、年1ぐらいでしいさんも出していこうかなと思ってます
ツンデレさんです
うさぎ妖精自体、人間があまり好きではないのですが、時折人間に興味を持ち、人間と契約する子が現れます
その一匹がファブラです
ファブラが人間に興味を持つ理由
簡単です
「文明を生み、物語を残す『人間』ってどんな物語を残す種族なのだろう?」
そんな好奇心からです
【嘘吐きオオカミと後輩。】で出てくるフレアも似たような感じです
自らの住処や還る場所を離れ、契約者となった人間の近くで暮らします
しいさんの場合は海で暮らしているので、ファブラが暮らしていた場所とさして変わりません
ファブラの特異的な能力として、海以外の異世界の物語を記録した「追憶」や「記憶」を物体として出現させることができます
今後この能力を使っていろいろとしいさんに探索させようと思います
ちなみにクラリオンとは利益の一致で情報交換をする仲になりました
最初彼女を出す予定全くなかったんですよ
そもそも彼女の構成ができたのここ最近です
しいさんたち3人よりだいぶ後です
ではなぜクラリオンを出すことにしたのか
もちろん世界観を強固にする理由もあるのですが、純粋にしいさんとしえの間をつなぐ橋がファブラじゃ適任じゃないなと感じまして
ファブラはしいさんのこともしえのことも知っています
ただ突っ込み役でツンデレさんだし、しいさんの役割側の人が全然おらんなぁ…となって
じゃあどっちかというと『規則』側の子を出そう!『規則』側にメイドさんいるし、その子に属してる子を作ろう!となって誕生したのがクラリオンです
性格もクラリオンの先生とよく似て、従者として従順で優しい子でありながら猫なので非常に気まぐれです
これは今後の話ですが、クラリオンの先生もしいさんが従属している『規則』の人も出てきます
そのうちです
お楽しみに~
今思ったけど、ここ生物学上のヒトっていないな?
本編の作業時間の中で一番長いかもしれない
VHS風にしたり、セル画風にしたりさぁ…
今回の進化点としてはしゃべっているときも口がパクパクするようになりました
アニメなんかを参考にして、4.5枚ぐらい描きました
ちょっとしたことですがいい感じになったかも
あとはカメラ制御を真面目に使うようになりました
今までは手振れ効果ぐらいしか使ってなかったのですが、表現したいことをやってみるにはカメラ制御が必須っぽかったのでねぇ
普段はAviUtl で編集作業をしているのですが、未だに機能を使いきれていない気がします
AviUtl2 が出たのは流石に衝撃すごかったな!!!
AviUtl2 は今後の進化が非常に楽しみです
ちょっとずつ触っていますが、AviUtl の時に感じてた不便さがだいぶ解消されてるのがいいです
ショートアニメについては分けて投稿しているのですが、謎に伸びる…
なぜ?
本編に関しては、あのほの暗くそれでも何かつかめるかもしれない、そんな雰囲気を作りたくて作った動画です
Reinkarnation 自体、「最後、前に進むための物語」ですので
しえではなくしいさんが動画に出た理由もここです
あの雰囲気にしえは出せん
ああいった仄暗く停滞した、確かに存在している日々を作るの、やっぱり好きだなって改めて思いました
精神削られますけどね
「日常」っていうのが重要で
非日常でも楽しいですが、やっぱり人の本質が見えるのって普通の日常で、変わり続ける日々だと思うのです
人の信念、あらゆる事象、物事、概念への思想、考え、感性…
それこそすべてが一致する人など存在しない
だからこそ様々な見方があって、思考があって、物語があって
それを書けるの、楽しいですよね
仄暗い必要性はまぁ別にないのですが、そこは僕の好みなので…
いつも気づいたらこうなってるんだ、なんでだろうね
そういえば、今回初めてCOEIROINK を使ったのですが、難しくないか!?
一つ一つの音の調整が出力前にできないの結構しんどいなと思いまして…
Audacity で無理矢理調整とかしました
もっと練習せんとですね
なぜならしゃべりたいので
無邪気で見た目よりも人の心を大切にし、本質を見つめる子供のような青年
【Reinkarnation】のキャラクターはみな花がモチーフなのですが、イリスのモチーフは「コスモス」と「アヤメ」です
彼にはもう一つモチーフがあって、それが「虹の女神:イーリス」です
善良な性格でありながら、神々に罰を下す神
イリスは他者に対して偏見を一切持たず真心で接します
花が咲いたのちは大切に思っていた人すらも手にかけ、凶悪性を増し冷徹に槍を振り下ろす
ね、そっくりでしょ
多分動画内でも言いましたが、あの世界ではオッドアイは異端でした
だからこそ一切の偏見を持たず、心で接してくれたイリスや義両親のことが大好きでした
リシアンのモチーフは「リシアンサス」いわゆる「トルコキキョウ」です
ゲーム内謎解きはリシアンサスの花言葉や誕生花となっています
ピンクや白のリシアンサスが全体的なモチーフとなっています
ゲーム内ではイリスの記憶にしか出てきませんが、イリスのことをとても大切に、大切に思っていました
彼の槍に貫かれても、笑ってお別れしたい
永遠にイリスを思う心はどれだけ時を過ごしても変わらないのでしょう
すごく面倒な性格してます
話し方は回りくどいし、現状話せることはほとんどないよ
1つ言えるのは、たくさんのものを見つめ、目的のために永い時を待つ待ち人だということです
「アンモビウム」が彼の一応のモチーフです
「たそがれりんかね」のED曲は自作曲でした
これね、7,8年ぐらい前に彼らをイメージして作ったものでして
最近ちゃんとStudio One を買いまして、編曲しなおしたものを今回のEDとして使用しました
いっぱい素材がある!
流石に素材不足を感じていたから買ってよかった!やったね!
で、以前作ったはいいものの公開するタイミングを完全に失い、箪笥の肥やしになっていました
今回せっかくだし使うか!となって、多少編曲を加えマスタリングをして使用しました
曲自体は割と好きです
かつての回想と心の中の激情をやりたくて作っていました
DTMの使い方いまだにわからん…
箪笥の肥やしになっている曲、何個かあります
かなしい
今回はこんな感じ!
【Reinkarnation】はイリスたちのための回顧録でもあり、『彼』のための物語でもあります
もう1人の追憶に巻き込まれた少女、アーデの回顧録が漫画の主軸でもあります
もうバージョン更新できないからな!そのままだぞ!
本体のバージョン更新できないから動画で出たバグは一生あのままです
作り直しは多分やんないです
自主制作ゲームの動画投稿は来年までお休みです
来年の【幸福の定義】までは自由に動画投稿します
【Reinkarnation】は今年で5周年を迎えたので、嘘吐きオオカミと後輩と同様に実況をしていました
短編でしたので、結構早めに終われましたね
今回も完結まで駆け抜けたので、動画の話とか諸々の話をしようと思います
小屋主さんたち
今回で大体の人物を出せたので大まかにお話しますしいな
誰だ貴様!というわけで表人格かつ本来の小屋主さん
立ち絵は今後ちょっと直しましょう…
性格はかなり鬱屈としていますし、色々と諦めてしまっています
物語を書き、物語を保管し、物語を見届ける
そんなことを今は生業としています
本編ではぼかしてはいますが、しいさんは自分の生まれた世界ではずっと前に、すでに死んだことになっています
そして、うさぎちゃんもといファブラが生まれた地に手違いで落ちてしまい、それ故に『規則』と出会ってしまいます
本当の意味で死ぬか、海に呪われるか…
彼女は海に呪われることを選択し、試練を受け半分人間、半分海の怪物になりました
海に呪われることを選択したのは「そっちの方が生きていたころより上手く生きれる気がしたから」です
そしたら『規則』からめちゃくちゃ仕事を投げられるようにはなりましたが、しえやクラリオン、ファブラに囲まれて、海の外で生きていたころより楽しく生きていそうです
鎖骨にある模様は試練に通過した印であり、通行証でもあります
表情が変わりにくいしあまり笑わないのはデフォルトです、そのうち話します
しえ
試練に通過した結果、海の残骸から誕生した人造人間見た目はほぼしいさんを受け継ぎ、性格はほぼ真反対です
よく笑い、ころころ感情を変え、ちょっぴり邪悪
…邪悪なのはしいさんの性格も多少は引き継いでいるからです
しえはしいさんから記憶と性格をある程度引き継いでいますが、ほぼ別個体です
ある程度なのは、しいさんがしえに渡した記憶が不完全だからです
だからこそしえはしいさんがあそこまで鬱屈とした子になった理由を知りません
「知りたいけど知らなくてもいいや!しいが元気ならそれでいい!いつか知れたらいいな」
ぐらいのスタンスです
ファブラのことを「うさぎちゃん」と呼んでいるのは名前を教えてもらっていないし、契約者ではない自分が教えてもらっていいのかわからないからです
しいさんは別に教えてもいいと思っていますが、自分から教えた方がいいだろと思っているので彼女からは教えないと思います
今後も基本的に表に出るのはしえではあるのですが、年1ぐらいでしいさんも出していこうかなと思ってます
ファブラ
『物語』の名を冠し、海や種族たちの記録をし続けるうさぎ妖精ツンデレさんです
うさぎ妖精自体、人間があまり好きではないのですが、時折人間に興味を持ち、人間と契約する子が現れます
その一匹がファブラです
ファブラが人間に興味を持つ理由
簡単です
「文明を生み、物語を残す『人間』ってどんな物語を残す種族なのだろう?」
そんな好奇心からです
【嘘吐きオオカミと後輩。】で出てくるフレアも似たような感じです
自らの住処や還る場所を離れ、契約者となった人間の近くで暮らします
しいさんの場合は海で暮らしているので、ファブラが暮らしていた場所とさして変わりません
ファブラの特異的な能力として、海以外の異世界の物語を記録した「追憶」や「記憶」を物体として出現させることができます
今後この能力を使っていろいろとしいさんに探索させようと思います
ちなみにクラリオンとは利益の一致で情報交換をする仲になりました
クラリオン
突然現れ、消えていく魔法生物猫さん最初彼女を出す予定全くなかったんですよ
そもそも彼女の構成ができたのここ最近です
しいさんたち3人よりだいぶ後です
ではなぜクラリオンを出すことにしたのか
もちろん世界観を強固にする理由もあるのですが、純粋にしいさんとしえの間をつなぐ橋がファブラじゃ適任じゃないなと感じまして
ファブラはしいさんのこともしえのことも知っています
ただ突っ込み役でツンデレさんだし、しいさんの役割側の人が全然おらんなぁ…となって
じゃあどっちかというと『規則』側の子を出そう!『規則』側にメイドさんいるし、その子に属してる子を作ろう!となって誕生したのがクラリオンです
性格もクラリオンの先生とよく似て、従者として従順で優しい子でありながら猫なので非常に気まぐれです
これは今後の話ですが、クラリオンの先生もしいさんが従属している『規則』の人も出てきます
そのうちです
お楽しみに~
今思ったけど、ここ生物学上のヒトっていないな?
動画制作のお話
後編のショートアニメがバチクソ大変でした!!!!!!!本編の作業時間の中で一番長いかもしれない
VHS風にしたり、セル画風にしたりさぁ…
今回の進化点としてはしゃべっているときも口がパクパクするようになりました
アニメなんかを参考にして、4.5枚ぐらい描きました
ちょっとしたことですがいい感じになったかも
あとはカメラ制御を真面目に使うようになりました
今までは手振れ効果ぐらいしか使ってなかったのですが、表現したいことをやってみるにはカメラ制御が必須っぽかったのでねぇ
普段はAviUtl で編集作業をしているのですが、未だに機能を使いきれていない気がします
AviUtl2 が出たのは流石に衝撃すごかったな!!!
AviUtl2 は今後の進化が非常に楽しみです
ちょっとずつ触っていますが、AviUtl の時に感じてた不便さがだいぶ解消されてるのがいいです
ショートアニメについては分けて投稿しているのですが、謎に伸びる…
なぜ?
本編に関しては、あのほの暗くそれでも何かつかめるかもしれない、そんな雰囲気を作りたくて作った動画です
Reinkarnation 自体、「最後、前に進むための物語」ですので
しえではなくしいさんが動画に出た理由もここです
あの雰囲気にしえは出せん
ああいった仄暗く停滞した、確かに存在している日々を作るの、やっぱり好きだなって改めて思いました
精神削られますけどね
「日常」っていうのが重要で
非日常でも楽しいですが、やっぱり人の本質が見えるのって普通の日常で、変わり続ける日々だと思うのです
人の信念、あらゆる事象、物事、概念への思想、考え、感性…
それこそすべてが一致する人など存在しない
だからこそ様々な見方があって、思考があって、物語があって
それを書けるの、楽しいですよね
仄暗い必要性はまぁ別にないのですが、そこは僕の好みなので…
いつも気づいたらこうなってるんだ、なんでだろうね
そういえば、今回初めてCOEIROINK を使ったのですが、難しくないか!?
一つ一つの音の調整が出力前にできないの結構しんどいなと思いまして…
Audacity で無理矢理調整とかしました
もっと練習せんとですね
【Reinkarnation】登場人物たち
しゃべれることが少ないですが、しゃべりますなぜならしゃべりたいので
イリス
【Reinkarnation】だけでなく「はねうさぎのこや。」世界でも相当な聖人枠無邪気で見た目よりも人の心を大切にし、本質を見つめる子供のような青年
【Reinkarnation】のキャラクターはみな花がモチーフなのですが、イリスのモチーフは「コスモス」と「アヤメ」です
彼にはもう一つモチーフがあって、それが「虹の女神:イーリス」です
善良な性格でありながら、神々に罰を下す神
イリスは他者に対して偏見を一切持たず真心で接します
花が咲いたのちは大切に思っていた人すらも手にかけ、凶悪性を増し冷徹に槍を振り下ろす
ね、そっくりでしょ
リシアン
かつての追憶に巻き込まれ、人ならざる力を持っていた少女多分動画内でも言いましたが、あの世界ではオッドアイは異端でした
だからこそ一切の偏見を持たず、心で接してくれたイリスや義両親のことが大好きでした
リシアンのモチーフは「リシアンサス」いわゆる「トルコキキョウ」です
ゲーム内謎解きはリシアンサスの花言葉や誕生花となっています
ピンクや白のリシアンサスが全体的なモチーフとなっています
ゲーム内ではイリスの記憶にしか出てきませんが、イリスのことをとても大切に、大切に思っていました
彼の槍に貫かれても、笑ってお別れしたい
永遠にイリスを思う心はどれだけ時を過ごしても変わらないのでしょう
『彼』又は『規則』
【Reinkarnation】どころか「はねうさぎのこや。」世界全体に関わる人すごく面倒な性格してます
話し方は回りくどいし、現状話せることはほとんどないよ
1つ言えるのは、たくさんのものを見つめ、目的のために永い時を待つ待ち人だということです
「アンモビウム」が彼の一応のモチーフです
黄昏還る箱庭にて
「たそがれりんかね」のED曲は自作曲でした
これね、7,8年ぐらい前に彼らをイメージして作ったものでして
最近ちゃんとStudio One を買いまして、編曲しなおしたものを今回のEDとして使用しました
いっぱい素材がある!
流石に素材不足を感じていたから買ってよかった!やったね!
で、以前作ったはいいものの公開するタイミングを完全に失い、箪笥の肥やしになっていました
今回せっかくだし使うか!となって、多少編曲を加えマスタリングをして使用しました
曲自体は割と好きです
かつての回想と心の中の激情をやりたくて作っていました
DTMの使い方いまだにわからん…
箪笥の肥やしになっている曲、何個かあります
かなしい
今回はこんな感じ!
【Reinkarnation】はイリスたちのための回顧録でもあり、『彼』のための物語でもあります
もう1人の追憶に巻き込まれた少女、アーデの回顧録が漫画の主軸でもあります
もうバージョン更新できないからな!そのままだぞ!
本体のバージョン更新できないから動画で出たバグは一生あのままです
作り直しは多分やんないです
自主制作ゲームの動画投稿は来年までお休みです
来年の【幸福の定義】までは自由に動画投稿します
次のページ
>>
プロフィール
HN:
しぇら
性別:
非公開
自己紹介:
一次創作同人サークル「はねうさぎのこや。」の管理人。
絵をかいたり、ゲーム作りや曲作りなんかを楽しんでいる。
絵をかいたり、ゲーム作りや曲作りなんかを楽しんでいる。
最新記事
(05/26)
(05/08)
(03/01)
(12/14)
(11/09)
P R