ウディタの中級者上級者向け小ネタ集第1弾

というわけでウディタを使用するにあたっての
小ネタ集的なものを書こうと思います。
主に中級者上級者向けを対象としているので悪しからず。
（第1弾とか書いてるけど第2弾があるとは言っていない……）
※前半は処理負荷に関することが多めです。

<< 目次 >>

・コメント文やチェックポイントの処理負荷

・空コマンドの処理負荷

・ラベル処理の負荷

・コモンイベントの起動方法の違いによる処理負荷

・[0]回ループで処理を括ってもループ内の処理行数に応じて負荷がかかる

・使用するピクチャのパスが短ければ短いほど描画処理が軽くなる

・DBのアクセス方法により処理負荷が変わる

・ピクチャ表示とピクチャ移動の処理負荷
・コモンイベント起動時に渡す引数は最大で５つまで渡せる(数値入力、文字列入力)
・変数で指定した引数有りコモンイベントを起動する方法

・ゲーム中にUDBに値を格納する
・実はDBは１タイプにつき10000データID以上使用できる（自己責任）

・2階層下のフォルダにあるピクチャを表示する
・Dataフォルダ外のピクチャを表示する

コメント文やチェックポイントの処理負荷

コメント文2.2個につき『変数操作:Cself[0]=0+0』１個分 チェックポイントも同様

空コマンドの処理負荷

コモンイベントの最終行やループ内の最終行に自動的に挿入される 空のコマンドにも処理負荷が存在する。 処理負荷はコメント文とほぼ同等だが、極わずかに軽い。

ラベル処理の負荷

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

コモンイベントの起動方法の違いによる処理負荷

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

[0]回ループで処理を括ってもループ内の処理行数に応じて負荷がかかる

特定の処理を実行させたくない場合等に[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のアクセス方法により処理負荷が変わる

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のデータはゲーム中に書き換えることはできないが 書き換える方法が存在する。 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に書き込む方が容量が増えなくて済むメリットがある。

実はDBは１タイプにつき10000データID以上使用できる（自己責任）

[※使用は自己責任、試すならバックアップは取っておこうね※] 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以上にアクセスできない）

2階層下のピクチャを表示する

ピクチャ表示ではDataフォルダ内のフォルダから画像ファイルを選択するが、『Data/Picture/UI/hp_bar.png』のようにPictureフォルダの中にUIフォルダがあるような場合でも使用可能である。 ウディタ上で選択することはできないが、ピクチャ表示のパス入力欄に直接パスを入力することで表示が可能。 上記例の場合は以下のようにパスを入力すれば表示される Picture/UI/hp_bar.png

Dataフォルダ外のピクチャを表示する

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

ウディタツール開発用ライブラリ WodiKs α版公開！

ウディタツール開発用ライブラリ『WodiKs』のα版を公開します！
（Ver0.40）

WodiKs-Ver0.40[α版] ダウンロード



<< WodiKs とは >>
WodiKs はウディタツールの開発を手軽に行えることを
目的としたツール開発用ライブラリです。(C#で作られています)


◇ 現在実装されている主な機能 ◇
・ウディタが管理している各種ファイルの読み込み/書き込み
　　├ CommonEvent.dat
　　├ DataBase.dat / DataBase.project
　　├ CDataBase.dat / CDataBase.project
　　└ SysDataBase.dat / SysDataBase.project

・各種データの取り扱い
　　├ コモンイベント
　　├ イベントコマンド
　　└ データベース

以下のような物が手軽に作れるようになります。
（サンプルプロジェクトとして同梱しているものです。）

  ▲原寸大で開く

ライブラリの導入方法や使用方法等の詳細は
同梱されているマニュアルファイル『WodiKsGuide.chm』をご覧ください。

WodiKs-Ver0.40[α版] ダウンロード

【ウディタ】ループの処理負荷について

今日調べてたループに関する処理負荷をまとめておこうと思います。

<< ループ内の行数 >>
ループ処理を抜ける場合は
『ループここまで』コマンドまでの行数に応じて
処理負荷が変化します。

ループを抜けると言いましたが、ループを実行しない場合にも
行数が影響します。
-- ▼処理負荷比較 --
     

上記画像の結果のようにループ内の行数が多いほど
処理負荷がかかるみたいです。

行数が多いほど負荷が上がる原因は
ループを終了するときに『ループここまで』コマンドを
探索しているためだと思われます。


<< ループ中断 >>
『ループ中断』コマンドが実行されると
『ループ中断』コマンドの位置から下方向に
『ループここまで』コマンドを探索します。

ループを抜けるときにループ内の行数に応じて
負荷が変わったように
『ループ中断』～『ループここまで』間にある
処理行数に応じて負荷が変わります。

-- ▼処理負荷比較 --




<< ループ開始へ戻る >>
『ループ開始へ戻る』コマンドが実行されると
『ループ開始』地点へ戻ります。
このとき『ループ開始』地点は予め記録されており
『ループ開始』地点へ戻るときの処理負荷は一定だと
思われます。
(※複数のパターンで実験してみての印象ですので
　『ループ開始』地点が記録されていると断定はできません)

ただし、『回数付ループ』の場合は
『ループ開始へ戻る』コマンドが実行されたあとに
指定回数ループしたかどうかの判定が実行されます。
もしループが完了していた場合は
『ループ開始へ戻る』コマンドの位置から
『ループ中断』コマンドが実行されます。

よって『ループ開始へ戻る』～『ループここまで』間の
処理行数が多いほど、ループを抜けるときに処理負荷が
高まってしまいます。

-- ▼処理負荷比較 --




[ 余談（興味ない人はスルーでOK） ]
『ループ中断』コマンドが実行されると
現在のループ処理に対応する『ループここまで』コマンドを
探索します。
ここで言う対応する『ループここまで』コマンドというのは
『ループ開始』コマンドのインデントと
同じインデントに存在する『ループここまで』コマンドです。
インデントというのは以下のイベントコードで言う
<0>や<1>の数値のところです。
▼イベントコード

WoditorEvCOMMAND_START

[170][0,0]<0>()()

[0][0,0]<1>()()

[498][0,0]<0>()()

WoditorEvCOMMAND_END

この場合
[170][0,0]<0>()()　が　『ループ開始』コマンド
[498][0,0]<0>()()　が　『ループここまで』コマンド
インデントの部分を見ると同じ 0 がセットされています。
ここが一致する『ループここまで』を探索します。
つまりイベントコードを弄って本来は違うインデントのところで
対応した『ループここまで』コマンドを置くと
そこをループ終了地点と誤認させることができます。

ウディタでのゲーム開発再開

ゲーム開発両立の厳しさから
長い間ウディタでのゲーム開発は停止していましたが
とうとう再開しました。

というわけで2日ほど前から新しくゲームを作っています。
最後のウディフェス参加を目標にゲームの企画をし始めましたが
規模が1週間じゃまず作れないほどのものになってしまったので
もうウディコン用かな……

ちなみに
タイトル画面（ロゴのみ）はこんな感じです。


ちまちま作ってたウディタ用のフレームワークシステムと
1週間ぐらい前辺りに作ってた
ウディタでクラスを定義して、それを元にインスタンスを生成する
システム(オブジェクト指向)の実験作でもあります。

ちょっと特殊なゲームシステムになりそうなので
完成まで無事に漕ぎ着けれるかは心配ですが
まぁ頑張っていこうと思います。

ウディタ用ツール『WoditorOptimizer』Ver1.00公開！

※本ページのツールは古いバージョンです。新しいバージョンは下記で公開されています

http://alphastella07ks.blog.shinobi.jp/woditoroptimizer_info/woditoroptimizer_ver2.0.0

---------------------------------------------------------------------------------------------

ウディタの『CommonEvent.dat』を解析して各コモンイベントを
最適化するツール『WoditorOptimizer』Ver1.00 を公開しました！

↓こちらからダウンロードできます。
http://ux.getuploader.com/k_shin07/download/26/WoditorOptimizer_Ver1.00.zip

◆追記◆=================================================
『MSVCP110』がありませんというようなエラーが出て起動できない方は
以下のURLから『VSU4\vcredist_x86.exe』をダウンロードして
インストールしてください。
https://www.microsoft.com/ja-jp/download/details.aspx?id=30679
========================================================

↓画面UI（クリックすると原寸大で開きます）



◆ 最適化とは？
最適化といっても一体何ができるのかよくわからないと思うので、そのあたりの解説をします。

まず結論から
ウディタの処理を高速化します！

当然、「どうやって高速化するねん」ってなりますよね。
「高速なアルゴリズムにでも書き換えるのか？」
そんなのは無理です！じゃあどうするのか、解説していきます。

ウディタで開発をするときによく使うのがコモンイベントですよね。
ほとんど処理はそこにイベントコマンドとして記述されます。
ですが、その中にはゲームの実行には無関係な
『コメント文』や『チェックポイント』『デバッグ文』などがあります。
 
読みやすくするためや、パッと見で処理の内容を分かりやすくするために
たくさん挿入したりしますよね？

今では知っている人も多くなっているとは思いますが
これらのイベントコマンドにも処理負荷が存在するんです。

システム変数108番「[読]現ﾌﾚｰﾑのｺﾏﾝﾄﾞ処理数」などで確認すれば
しっかりとカウントされていますので、負荷が存在するのも納得することでしょう。

それらの負荷はとても軽いので、特に影響を受けることが無い場合がほとんどですが
もし、1000回とか2000回とか回る多重ループ内にたくさん記述されていた場合はどうでしょう？
そういった感じで場合によっては知らぬ間に顕著に
負荷影響を受けているかもしれません。

だからと言って、『コメント文』等を挿入しないなどの選択を取るわけにはいきませんよね？
そんなことをすれば何をやっている処理か分からなくなります。

そこで、この『WoditorOptimizer』の出番です。
このツールでは、各コモンイベントを管理している『CommonEvent.dat』を解析して
それらの不要なイベントコマンドを一括で削除して処理を最適化することができます。
（『CommonEvent.dat』は『Data』フォルダ内の『BasicData』フォルダに格納されています）

開発中に削除できないなら、配布時にだけ削除すればいいというわけです。



コマンド削除以外による最適化機能も実装されています。
現在実装されている項目は以下の画像の通りです。(画面スクリーンショットから抜粋)

『コメント文をデバッグ文に変換する』『デバッグ文をコメント文に変換する』
についてはオマケで実装しただけで、最適化とは関係無い項目にあたります。

上記の各項目についての詳細は配布データ内の『機能詳細.txt』をご覧ください。


また、『CommonEvent.dat』を解析にすることによってデータの集計も可能になっているので
以下のような機能も実装しています。(画面スクリーンショットから抜粋)

総イベントコマンド数では、全てのコモンイベント内のイベントコマンド数の合計が
表示されています。
大規模なゲームになると10万超えたりもするでしょうから、自分の作っているゲームの
コマンド数の総計を調べたりして楽しむのもありでしょう。

また『イベントコマンド数グラフ比較』では
以下のように各コモンイベントのイベントコマンド数を比較することができます。


以上でこのツールの解説を終わりたいと思います。

もしバグやこんな機能がほしいとか要望があれば
報告して頂けると幸いです。
ツイッターのハッシュタグ『#WoditorOptimizer』が付けられているツイートについては
できるだけ閲覧するようにするのでそちらに要望等あれば呟いていただいても結構です。
（全て回収できるとは限りませんが）


※このウディタ用ツール『WoditorOptimizer』は
　以前公開していた『WECDeletor』の後継ソフトにあたります。
　現状 『WECDeletor』のようにイベントコードに対しての削除はできませんが
　将来的にはオマケとしてイベントコードに対しても実行できるモードを
　用意するかもしれません。