『ラベル設置』及び『指定ラベルに飛ぶ』コマンドはラベル名に特殊文字を使用できる。

これを利用してゲーム中にラベル名の変更やジャンプ先指定ラベル名を変更できる。

プログラミング言語のswitch文の再現とかも可能。

※あまり多用しすぎるとスパゲッティコードになるので注意

※ラベル文と特殊文字の連携なので重い

ウディタのコモンセルフや通常変数、予備変数等の全ての数値変数は
4バイトで管理されている。

1バイトは8ビットで構成されるので4バイトの場合32ビットで構成されている。

各ビットにフラグを設定すれば最大で32個のフラグを管理できる。

※ビット等の詳しい説明をすると長い文章になるので

　ここでは割愛。分からない方は検索してね

以下はコモンイベント3を起動し返り値の受け取り先として

『CSelf0(1600010)』を指定した場合のイベントコード

WoditorEvCOMMAND_START

[210][3,0]<0>(500003,16777216,1600010)()

WoditorEvCOMMAND_END

上記イベントコードを改造して

受け取り先を『CDB[0:0:4](1100000004)』に

変更したイベントコード

WoditorEvCOMMAND_START

[210][3,0]<0>(500003,16777216,1100000004)()

WoditorEvCOMMAND_END

UDBを受け取り先として指定すると

UDBの値を書き換えることも可能。

コモンイベントを名前指定で起動する際、

名前入力欄に文字列変数を特殊文字で指定すると

その文字列変数で指定された名前のコモンイベントを起動できる。

データ数や項目数の取得はウディタに実装されているが、

タイプ数の取得は実装されていない。

しかし、求める方法は存在する。

タイプ名を取得した際、存在しないタイプIDの場合は

『×NoData』が返ってくるので

タイプIDを0から順に判定していけばタイプ数を求めることが可能。

文字列操作のファイル内容読込機能を使ってファイルが存在するか

どうかを調べることができる。

この機能を使ってファイルを読み込んだ際

ファイルが存在しなかったら『<NoFile>』が返ってくるので

それを判定してファイルの有無を確認可能

※ただし、ファイルが存在する場合は問答無用で読み込まれるので

　データの大きいものを読み込んだ際は重くなる。
　単純に有無だけ確認したい場合は扱いに注意しよう。

変数操作:Cself[0] = 1073741824 + 0

変数操作:Cself[0] *= 2 + 0

※ウディタでは2000000000以上の値を直接代入できないため

通常変数等はシステムデータベースで管理されているが

それぞれデータベースの項目は使用していない。

ウディタがバージョンアップし通常変数等の

新機能実装が入らない限り

ここの項目は追加しても問題がないので

自分用に変数の説明項目等を追加すると利便性が上がるかも。

（同様にBGMリストに著作権記入の項目を追加しておくとかの

活用方法もある）

『ループ中断』コマンドが実行されると

『ループ中断』コマンドの位置から下方向に

『ループここまで』コマンドを探索する。

よって

『ループ中断』～『ループここまで』間にある

処理行数に応じて負荷が変化する。

つまり

ループ先頭付近でループ中断を行うより

ループ末尾付近でループ中断を行う方が

ループ中断実行の処理負荷は軽い。

※ループ内の処理内容によって適切な中断位置は変わるため

　絶対に末尾付近の方が軽いとは言い切れないので注意。

　中断実行の瞬間の負荷が末尾の方が軽いというだけの話

『ループ開始』地点へ戻る際の処理負荷は一定だが

回数付きループの場合

『ループ開始へ戻る』により回数分のループが終了した際は

『ループ開始へ戻る』コマンドの位置から『ループ中断』が

実行される。

『ループ中断』コマンドは

『ループ中断』～『ループここまで』までの

行数が多ければ多いほど重くなるため

『ループ開始へ戻る』コマンドがループ末尾に近いほど

処理負荷は軽くなりやすい。

※ループ内の処理内容によって適切な

　『ループ開始へ戻る』コマンドの位置は変わるため

　絶対に末尾付近の方が軽いとは言い切れないので注意。

　中断実行の瞬間の負荷が末尾の方が軽いというだけの話

コメント文2.2個につき『変数操作:Cself[0]=0+0』１個分

チェックポイントも同様

コモンイベントの最終行やループ内の最終行に自動的に挿入される

空のコマンドにも処理負荷が存在する。

処理負荷はコメント文とほぼ同等だが、極わずかに軽い。

ラベル名の文字列が長ければ長いほど処理負荷が高くなる。

番号指定のコモンイベント起動に対して名前指定のコモンイベント起動は1.5倍の処理負荷がかかる。

特定の処理を実行させたくない場合等に[0]回ループで処理を括っても、
[0]回ループ実行時の処理負荷はループ内の処理行数に応じて増える。

コメント文に処理負荷があるので、多数行のコメント文の処理負荷を削りたい。
そう思って[0]回ループで括っている人もいるかもしれないが

これは逆効果である。

[0]回ループで括るとかなり高負荷になるので注意。

ちなみにこれは[0]回ループの実行負荷がかかる分重くなるということではなくて、
[0]回ループ内の行数に応じた負荷がコメント文の負荷より重いということである。

つまり

『多数行のコメント文を含んだ[0]回ループの負荷』

より

『何も中に入れていない[0]回ループの負荷+多数行のコメント文の負荷』

の方が軽いということ。（※コメント文の行数は同じ）

以下の３つのピクチャがある場合（※全て同じ画像）

1. Picture/test01.png

2. p.png

3. P0000000000000000000000000000.png

Dataフォルダ直下にあり、ファイル名の最も短い『p.png』のピクチャの方が描画時に速く描画できる。

『p.png』と『P0000000000000000000000000000.png』

の1回の描画の処理負荷の違いは

『変数操作:CSelf0 = 0 + 0』コマンド9個分の違いがある。

処理負荷に違いがあるのは

ピクチャ表示コマンド時のみでピクチャ移動コマンドの場合は影響が無いと思われる。

DB操作にて以下のようにアクセス方法によって処理負荷が違う

<速い>

CDB[0:0:0],CDB[0:CSelf0:0]

<遅い>

CDB[CSelf0:0:0],CDB[0:0:CSelf0]

上記の違いが発生する原因は

タイプID及び項目IDに変数を指定すると

X番の変数呼出にて処理が実行されてしまうためと思われる。

変数指定をデータIDにのみ行うことで高速に処理できる。

処理負荷的には約3倍の違いがある。

※名前指定と数値指定は同じものとして考えて問題ない

ピクチャ表示とピクチャ移動では移動の方が処理負荷が軽い。

既に表示しているピクチャに関してはピクチャ移動で処理してあげることによって描画負荷を軽くできる。

通常コモンイベントに引数を渡す場合はウディタのコモンイベントエディタで設定を行うが、設定が行われていなくても引数渡しは可能である。

この仕様を使い、5つ目の引数を渡すことができる。

ウディタはエディタ上では引数を4つまでしか扱えないが、

内部的には5つまで対応している。

5つ目の引数を渡す場合はコモンイベント起動コマンドのイベントコードを改造する。

< 例 >

コモンイベント３に数値入力を５つ渡す（0,1,2,3,4）

WoditorEvCOMMAND_START

[210][7,0]<0>(500003,5,0,1,2,3,4)()

WoditorEvCOMMAND_END

コモンイベント３に文字列入力を５つ渡す（CSelf5,CSelf5,CSelf5,CSelf5,CSelf5）

WoditorEvCOMMAND_START

[210][7,0]<0>(500003,80,1600005,1600005,1600005,1600005,1600005)()

WoditorEvCOMMAND_END

コモンイベントの『イベントの挿入』を使いコモンイベントを起動する際、コモンイベントの指定に『このコモンSelfXX』を使用すると変数で指定したコモンイベントを起動できるが、引数が渡せない。

引数を渡すようにするためにはイベントコードを改造する

以下は『このコモンSelf0』のコモンイベントを起動するイベントコードである。

WoditorEvCOMMAND_START

[210][2,0]<0>(1600000,0)()

WoditorEvCOMMAND_END

これに引数を渡すようにしたい場合は以下のように改造する。

（引数を３つ使い、CSelf1,CSelf2,CSelf3を渡す場合）

WoditorEvCOMMAND_START

[210][5,0]<0>(1600000,3,1600001,1600002,1600003)()

WoditorEvCOMMAND_END

▽解説

[2,0]の2に使用したい引数の個数分足しこむ

今回は３つ使用するので[5,0]

(1600000,0)の0のところに引数の数を入れる

今回は３つ使用するので(1600000,3,

(1600000,3,

に続き、渡したい変数や数値を引数分だけ記述する

基本UDBのデータはゲーム中に書き換えることはできないが

書き換える方法が存在する。

UDBにアクセスする際に可変データベースのタイプIDでアクセスを行う。

例えばUDB[1:0:0]にデータを格納したい場合は

『DB操作』ではなく『変数操作』の『可変DB』を使用して

以下のように処理する

変数操作:CSelf0 = 1 - 100

変数操作:可変DB[CSelf0:0:0] = 0 + 0

これでUDB[1:0:0]のデータを書き換えれる。

▽アクセス先タイプIDから100を引くとなぜ書き換えれるの？

X番の変数呼出の番号を意識すると答えが見えてくる。

CDB[1:0:0]の呼出値は『1101000000』

UDB[1:0:0]の呼出値は『1001000000』

差は『100000000』

変数操作の可変DB操作はX番の変数呼出を使用してアクセスが行われる。

つまり変数操作でCDB[1:2:3]としての場合

呼出値は以下のように求められる。

CDBアクセスの基準呼出値 [1100000000]

　+

タイプID [1 * 1000000]

　+

データID [2 * 100]

　+

項目ID [3 * 1]

= 1101000203 → CDB[1:2:3]

上記の呼出値となる。

ここでタイプIDに-100を与えてみた場合

CDBアクセスの基準呼出値 [1100000000]

　+

タイプID [-99 * 1000000]

　+

データID [2 * 100]

　+

項目ID [3 * 1]

= 1001000203 → UDB[1:2:3]

となる。

これによってUDBにアクセスすることが可能になる。

UDBはCDBと違ってセーブデータの容量を食わないので

一時変数的な使い方をするならUDBに書き込む方が容量が増えなくて済むメリットがある。

[※使用は自己責任、試すならバックアップは取っておこうね※]

X番の変数呼出を使用しないアクセス方法に限りデータID10000以上へのアクセスが可能。ただし必ずデータIDは使用する範囲分確保しておく必要がある。

10000以上のデータIDを確保する方法にはCSV読み込みを使用する。

CDBのタイプ0のデータ数を10001個以上にする場合

まずはデータ数10000個分を『データ数の設定』ボタンを使用して確保する。その後10000個分データをCSVで吐き出す。

データID9999を選択した状態でCSV読み込みを行い先ほど吐き出したCSVを読み込ませる。するとデータIDが0～19998まで確保できる。

この手順を使い任意のサイズまで拡張できる。

ただし、DB設定画面でそのタイプを選択する毎に重い読み込みが走ってしまうので、あまりにもたくさんのデータを用意するのは避けたほうが良い。

X番の変数呼出を使用しないアクセス方法については

DB操作のDB[数値:変数:数値]で使用するとよい。

（タイプID,項目IDに変数を使用するとX番の変数呼出になってしまうのでデータID10000以上にアクセスできない）

ピクチャ表示ではDataフォルダ内のフォルダから画像ファイルを選択するが、『Data/Picture/UI/hp_bar.png』のようにPictureフォルダの中にUIフォルダがあるような場合でも使用可能である。

ウディタ上で選択することはできないが、ピクチャ表示のパス入力欄に直接パスを入力することで表示が可能。

上記例の場合は以下のようにパスを入力すれば表示される

Picture/UI/hp_bar.png

ピクチャ表示時のパスはDataフォルダからのパスを指定する必要があるが、

これは相対パスで処理されているので1つ上のフォルダに戻る『../』を使用すれば、Dataフォルダ外のピクチャを表示可能である
< 例 >
../Save/Test.png