【ウディタ】初心者向けコモン作成例集②

概要

ウディタでコモンを作るときに
応用が利きそうな内容をピックアップした
粗雑なコモン作成例集その2です。


留意事項

この記事はウディタVer3.270時点らへんの内容になります。
記事内容のミス指摘があれば修正しますが
内容に対する質問には基本的に答えませんので悪しからず。

<最終セーブ時の設定を起動時に自動ロード>

内容:

①ゲーム起動直後、初期設定を読み込むために
 自動起動するイベントかコモンを作り、後述のメイン処理内容を作る
②システムファイル名を決めておく(下記では¥s[10]に代入している)
③文字列操作で<ファイル内容読込>で特殊コマンドでファイルがあるかチェック
  (下記では <<GET_FILE_EXIST>>¥s[10] としている)
④文字列の条件分岐で、③でチェックした結果0or1で処理内容を分ける
 0:デフォルトの設定値を入れて、とりあえずシステムファイルを作成
 1:システムファイルからロード→⑤に続く
⑤システムファイルから「セーブデータの内容読込」を使って
 必要な設定値をロードして、同じ設定値に代入する。
⑥ゲーム中、セーブを実行したらシステムファイルにも上書き保存して
 設定内容を保管・維持する。

■文字列操作:S10[システムファイル名] = "Save/system.sav"
■文字列操作:CSelf6[ファイルチェック] =<ファイル内容読込> [UTF-8] "<<GET_FILE_EXIST>>\s[10]"
■条件分岐(文字):  【1】 CSelf6[ファイルチェック]が "1" と同じ
-◇分岐: 【1】 [ CSelf6[ファイルチェック] "1" と同じ ]の場合↓
 |■デバッグ文:システムファイルからロード
 |■セーブデータの内容読込: CSelf20[ロードした値] = セーブデータ[S10[システムファイル名]]の Sys100:BGM音量補正[%]
 |■変数操作: Sys100:BGM音量補正[%] = CSelf20[ロードした値] + 0 
 |■セーブデータの内容読込: CSelf20[ロードした値] = セーブデータ[S10[システムファイル名]]の Sys101:BGS音量補正[%]
 |■変数操作: Sys101:BGS音量補正[%] = CSelf20[ロードした値] + 0 
 |■セーブデータの内容読込: CSelf20[ロードした値] = セーブデータ[S10[システムファイル名]]の Sys102:SE音量補正[%]
 |■変数操作: Sys102:SE音量補正[%] = CSelf20[ロードした値] + 0 
 |■
-◇上記以外
 |■デバッグ文:コンフィグを設定後、システムファイルを保存
 |■変数操作: Sys100:BGM音量補正[%]~Sys102:SE音量補正[%] = 50 + 0 
 |■データのセーブ: S10[システムファイル名]
 |■
◇分岐終了◇
例:BGM音量の値をセーブデータから内容読込

他用途:
UDBで管理すると、コンフィグ画面にも応用が効いて便利です。
最後にセーブしたデータ番号は何か?などの設定値なども
応用して保管/利用に使えます。

説明:

BGM音量やキー配置などの設定を、最終セーブ時点と同じものを
自動ロードしてプレイヤーに不快感を与えないないようにできます。
セーブからの読み込みでシステム変数や通常変数を指定したい場合
9000100や2000000という特殊な数値指定が必要な点と
一部読み込めないものもある点に注意してください。

タイトル画面の爆音で最初にやられて設定したのに、
次回起動時にまた爆音を食らったらたまったもんじゃないですよね。

上記処理では、システムファイルを雑にまるごと保存してますが、
個別に保存して最小サイズにする方法も多分ある……はず。
(セーブデータが肥大化しそうな場合は別途検証してください)

<複数条件を評価してフラグ処理>

内容:

それぞれの条件を満たしたら2進数的IDを加算し
最後にDB参照して結果として返す、複雑なフラグ処理。
2進数的なIDを加算値に扱うことで重複しない複雑なフラグ管理ができる。
使う加算値:1,2,4,8,16,32,…(以下略)

例えば、心/技/体のような集計項目があった場合
心=1 / 技=2 / 体=4 のようにして条件に合えば加算する。
・平均より技(2)だけが高ければデータ2番を参照
・平均より心(1)と体(4)が高ければデータ5番を参照
・どれも平均以上ならデータ7番を参照
・逆にどれも平均未満ならデータ0番を参照

下記は、実際に作ったコモンでの作例です(若干、見苦しいですが)

コモン例

このコモン例では、フラグ初期値(一時変数B)=0にして
3項目を見て、平均以上だった値を条件達成としています。
V1-6カオス達成時…+1 V1-7バトル達成時…+2 V1-8ロマンス達成時…+4

フラグ処理DB例

フラグ値別でDBデータ番号0~7で8種類を用意しており
複数のフラグに合った個別内容を返します。

他用途:
一時的なフラグ値を使い回したい時の応用。
例:毎章ごとに毎回話す相手と話してから先に進む場合
王様と話した:V0+1 / 大臣と話した:V0+2 / 姫様と話した:V0+4
V0>=7になれば先へ進み、同時にV0=0にリセットして次章へ。
次章ではまたフラグを集めて……の繰り返し

説明:

2進数の各桁の数値、1,2,4,8,16….を組み合わせて足すと
重複した数値にならないことを利用します。
上述の平均値とはあくまで基準値(ボーダーライン)なので、
別で基準値を用意するなど、ゲームに合わせて評価してください。

<プラスとマイナス表記の一括置換>

内容:

+と- (あるいは±0も)の正負の数値表記を混在表示したいとき。
数値の条件によって表現を変える方法でも良いが
とりあえず+\cself[10]のような文字と値を入れておき
あとで下記2種の置換をすれば一括でやれて手間を減らせる。
①「+-」→「-」に置換
②「+0」→「±0」に置換

説明:

装備ステータスなどで、プラス性能だけでなく
マイナス性能も混在してる場合に楽できる。

<一覧表示専用のDBを作る>

内容:

制作者側がパラメーターを打ち込む元となるDBを裏DB
プレイヤー側に見せる表示用DBを表DBとここでは呼びますが
表DBを作ることにより、裏DBが汚いままでも
プレイヤー側にはキレイに見せることができます。

表示用DBのイメージ
DB導入前の未整理な感じ
DB導入後の整理したイメージ

他用途:
・可変DBだと流動的なソート/フィルタ機能にも転用できる
 (バージョンアップによる内容変更時は処理の考慮が必要)
例:表示前にソート/フィルタ内容で表示用DBを生成し、表示に使う

・UDBだと固定的なカテゴリソート/フィルタ機能にも転用できる
例:データ1は通常表示、2は武器だけ、3は防具……など

・100件超のアイテムになる場合は、データ番号でページを分ける
例:データ0番は表示優先度0番~100番。1番は101番~200番…以下略
  として1ページ最大50件表示に達するまで所持数を確認する。

説明:

いくつか利用目的を挙げます。
・アップデートで装備や敵が増える可能性があるときに
 元DB側をいじらず一覧表示順がキレイに整理できる
 (アイテムごとのIDや所持数やフラグを移動させずに済む)
・元となるDB側にデータ欄の余裕(隙間や空欄、分類)を置きたいが
 表示時に変な条件分岐や隙間を作りたくない、表示させたくない
・表示用のコモンさえ完成すれば元DBのメンテナンス負担が減らせる
 ※ただし、表示用DBのメンテナンスは必要になる

その他:
必要と思った背景として
装備品やモンスターなどのデータベースは、
思いついた内容を後から追加することがわりとあるので。
それをそのまま所持品や図鑑でそのデータ順に表示すると
プレイヤーは「整理整頓されてない」と困惑し、配慮不足となります。
また、ある程度作りこんでいた場合、
宝箱から入手できるアイテムがズレたり出現するモンスターがズレるため、紐づいたデータを安易に整理整頓できなくなります。
そんな状況になる前に、想定して用意しておくと便利かもしれません。
(毎回、あとから思い出して苦労する……)

<変数操作で複数項目のフラグチェック>

内容:

「0以下 or 1以上」でフラグを確認する場合に
条件分岐のコードを減らして数式で簡略化することができます。

下記例では、魚が釣れてない=0、釣れている=1として
釣魚をコンプリートしているかチェックしています。
最初にself0に(=1)を条件として代入しておき参照先の値を上限として代入。
計算結果は、釣れてない魚があった場合は0、全部釣れている場合は1となり
最終的にself0 = 「0 or 1」として最後の条件分岐1つのみで処理する。

他用途:
データが多い場合、ループ処理と併用して
条件分岐の使用回数を減らすことも可能。
1万個のデータを総チェックする場合のパターンとして
 A:1万のデータを1つずつ見て、0が出たら0,でなかったら1を返す
 B:100個のデータを見て、0が出たら0、
 でなかったら次の100個を見る…を100回やる
 C:すべてのデータで0がないか取り合えず計算する

説明:

DB昇順などの総当たり(ループ&条件分岐)でも良いと思いますが
条件分岐を減らして数式での処理を増やすことで
処理時間やコード視認性がよくなる可能性があります。
あくまで、こんな方法もあるよ的な内容となるので
最適解かどうかはケースバイケースです。

<イラストから2D歩行マップを作る>

内容:

①マップにしたいイラストを用意する
②該当マップへ入った時に、ピクチャ番号-1~-99999で表示する
 ※スクロールする場合は、『スクロールとリンク』の
  オプションに必ずチェックを入れる
③エディタでマップチップの〇×を置いて調整する

例:飛行場で滑走路と地続きっぽい部分だけ歩けるようにしたい
例:実際のチップ配置状況と並列実行での表示処理例

他用途:
・キャラチップを指さしポインタなどに置き換えて、
 部屋の写真などを背景に調べ物をするADV的な使い方も可能。
・飛び出すイラストのような表示開始でその世界を歩ける演出。

説明:

画像が重たいほど処理負荷はかかりますが
マップチップをアレコレ考えて置くよりも
ザックリだけど綺麗に仕上がります。
ただ、2D歩行可能場所と違和感なく一致させるためには
トリミングなどの加工技術が必要になるケースがありそうです。

<マップイベントにタグIDを付ける>

内容:

マップEvの処理の優先順位が高いページに下記を仕込む
(ページが大きいほど処理の優先順位は高い)
条件:並列処理
条件:self* が0と同じ (*は0~9。使うセルフ変数は固定にすると GOOD)
変数操作で self* = タグID のコードを仕込む(IDは 0 以外にする)

例:self9にタグID:3を入れておく

他の方法:

イベント画像にタグIDを仕込んで抽出する
※少し回りくどい方法なので一斉の並行処理が嫌な人向け

①キャラチップ画像のファイル名にタグIDを仕込んでおく。
②変数操作で9100009 + EvID * 10 を入れておく。
③文字列変数で上記変数をX番呼出
④タグIDより前にある文字列を消去する
 例:CharaChip/Enemy10.png からCharaChip/Enemyを消去置換
A-⑤変数操作で上記の文字列を代入、タグIDになる。
 例:¥cself10 = 1600005 +0 ⇒ ¥cself10 = 10(.pngは自動的に無視される)

説明:

そのマップEvが敵なのか味方なのか、あるいは宝箱なのか等々
種類や処理内容が定まっているイベントを管理する場合は
タグIDのようなものでカテゴリ分けしておくと、
汎用的な処理やDBでのイベント管理などに活用できるかもしれません。

<チップの裏側へ移動させる演出>

内容:

マップチップのタイル設定を瞬間的に★にして
裏側に移動(落ちたり隠れたり)したように見せかける。

コード上だとタイル設定の「★」は「主人公の上」になっています。

他用途:
空中に浮かんでいる敵を倒したときに、裏側に落としたり
水平な建物の絵を使ってキャラを建物の中や裏(奥)に移動させたり

説明:

正面側に落下させれば処理的には楽ですが
裏側に落下させることで、逃走したり敗北したりするような
演出効果の強調が見込めるかもしれません。
ちなみに演出が終わった後は、チップ処理の全初期化をすれば
変更したチップ設定を一括で元に戻すことができます。

<一部の設定値は16の倍数で考える>

内容:

透明度やRGBなどは255が最大値であることが多いので
増やしたり減らしたりする場合に16の倍数で覚えて考えると
すこし楽……かもしれない。

他用途:
PC関連でよく使われる16進数に強くなる(かもしれない)

説明:

ちょっと眉唾なノウハウかもしれませんが。
0,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240,256
更に16x16=256になり、これが16進数でよく使われる範囲です。
で、語弊はありますが255≒256として扱っちゃいましょう。
んで、255の半分や1/4の透明度っていくつでしょうか?
って時に素早くパパっと128や64という数値が出るのが楽なのと
値の調整でも16の差し引きで考えれば少し楽っていうだけの話です。


この記事が気に入ったらサポートをしてみませんか?