α-Stella[R]_ブログ

ウディタ機能拡張ツール Wodistant Ver1.0.0 正式リリース！

ウディタ機能拡張ツール『Wodistant』の正式版Ver1.0.0を公開します！

DOWNLOAD(ダウンロード)

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

本アプリケーションは『.NET Framework 4.5.2』が使用されています。

起動できない場合は以下をインストールしてみてください。

https://www.microsoft.com/ja-JP/download/details.aspx?id=42643

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

本ツールはウディタに対して外部から機能を拡張するツールです。
利便性を大きく向上させて開発作業の効率が上がります！

β版公開時に搭載されていた機能についての詳細は下記ページをご覧ください。
http://alphastella07ks.blog.shinobi.jp/wodistant_info/wodistant_beta

< 正式版で追加された新機能/修正内容 >

コモンイベント比較機能

コモンイベントエディタ上でCtrl+Shift+Dを入力することで
２つのコモンイベント比較するためのウィンドウが起動します。

比較したいコモンイベントを選択して『コモンイベントの比較開始』を押すと
その２つのコモンの差が可視化されます。
緑背景部分：追加されたイベントコマンド
赤背景部分：削除されたイベントコマンド

その他修正/追加機能(一部)

・ウディタ接続時のツール側のウィンドウがアクティブにならないことがある不具合修正

・接続実行時に起動中ウディタが1個だけであればウディタ選択画面をスキップして自動的に接続するように改良

< コメント文挿入 >

・たまにコメント文挿入に失敗(イベントコードの貼り付け失敗)することがある不具合を修正

< CEv Navigator >

・履歴リストのコモンをダブルクリックでも開くように変更

・コモン履歴一覧で履歴を全削除/個別削除する機能追加

・起動時に履歴リスト側が初回フォーカスにならないことがある不具合の修正

・起動後『Ctrl』キーを押し続けたまま『Q』キーを押すと検索フィルターへフォーカスが移動するように改良

上記以外の細かい修正は Readme.txt ファイルをご覧ください。

───────────────

新機能/修正内容は以上です。
本ツールで開発効率をあげ、ゲーム完成までの時間を短縮しましょう！

DOWNLOAD(ダウンロード)

ウディタ機能拡張ツール Wodistant β版公開！

※本ページはβ版です。正式版は下記で公開されています
http://alphastella07ks.blog.shinobi.jp/wodistant_info/wodistant_v100
---------------------------------------------------------------------------------------------

ウディタ機能拡張ツール『Wodistant』を公開します！

DOWNLOAD(ダウンロード)

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

本アプリケーションは『.NET Framework 4.5.2』が使用されています。

起動できない場合は以下をインストールしてみてください。

https://www.microsoft.com/ja-JP/download/details.aspx?id=42643

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

ウディタに対して外部から機能を拡張するツールです。
利便性を大きく向上させて開発作業の効率が上がります！

< 追加される機能 >

1.前回開いた複数のコモンに素早くアクセス

コモンイベントエディタ上でCtrl+Tabを入力することで
コモンイベントに素早くアクセスするためのウィンドウが起動します。

そこでコモンイベントを開くと
前回のイベントコマンドのスクロール位置を復帰して開き直すこと可能です。

※VisualStudioに搭載されているCtrl+Tabのアレです

2. コモンイベント一覧にフィルタリング

同じくCtrl+Tabで起動するウィンドウから
コモンイベント一覧に対してフィルタリングすることが可能です。

フィルタリングされた一覧から開きたいコモンをダブルクリックすることで
ウディタ側で開くことができます。

3. コメント文を素早く挿入

イベントコマンドリスト上で『F2』キーを入力することで
コメント文入力用のウィンドウが立ち上がります。

そのまま続けて入力することでコメントが打て、
Ctrl+Enterでコメント文の挿入が完了します。

4. 定義ジャンプ

『イベントの挿入』を選択し『F12』キーを入力することで
該当のコモンイベントを開きます。

『Ctrl+Tab』と連携することによって呼び出しているコモンイベントを『F12』で確認してから

『Ctrl+Tab』で素早く呼び出し元のコモンイベントを開き直すといった操作が可能になります。

───────────────

解説は以上になります。
本ツールで開発効率をあげ、ゲーム完成までの時間を短縮しましょう！

DOWNLOAD(ダウンロード)

ウディタ専用統合開発環境『Woditoride』公開！！

──────────────────────────────────────
2018/04/02 追記 : ※本記事はエイプリルフール企画です。
　　　　　　　　　(開発機能は無く、閲覧機能のみを持ったツールとなります)
──────────────────────────────────────
ウディタ専用の統合開発環境『Woditoride』を公開します！

DOWNLOAD(ダウンロード)
-------------------------------------------------------------------

本アプリケーションは『.NET Framework 4.5.2』が使用されています。

起動できない場合は以下をインストールしてみてください。

https://www.microsoft.com/ja-JP/download/details.aspx?id=42643

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

ウディタでのゲーム開発をより効率的に行うことができます。
現状ではマップやマップイベントの開発環境がまだ実装されていませんが
コモンイベントの実装がこれまでより格段に効率化可能です。

Woditoride スクリーンショット

< 注目すべき機能 >

1. コモンイベントを複数同時編集可能

WOLF RPG エディターではコモンイベントの編集を同時に行うことができません。
Woditoride では2つ、5つ、10個でも同時編集が可能です。
コモンイベント2つ水平に並べたり、縦に並べたり、
1つ1つウィンドウを分離することも可能です。

以下のGifアニメーションでは実際に水平や垂直に並べたり、
ウィンドウを分離/再度結合させたりしています。

2. イベントコマンドを折りたたむ

ループ内や条件分岐など
インデントがずれるイベントコマンドを折りたたむことができます。
今は見る必要の無い、行数の多いループなどを折りたたむことで
コモンイベントの可読性が向上します。

3. コモンイベント最適化を標準搭載
公開している WoditorOptimizer の最適化機能を搭載して
テストプレイ実行時に自動で最適化することが可能です。
実行時だけ最適化されるため、開発中にも最適化の恩恵を受けることが可能になりました。

※デフォルトではこの機能がオフになっています。
※自動で最適化されるため、安全を考慮して扱いに注意が必要な最適化機能は
　OFFになっています。使用する場合は最適化カスタム画面から有効化してください。

WoditorOptimizer については下記をご覧ください。
WoditorOptimizer 2.0.0 公開
 WoditorOptimizer 1.0.0 公開

4. コモンイベントの絞り込み機能

コモンイベント一覧にフィルターをかけることができます。
コモンイベントの数がかなり多い場合などに
この機能を活用することですぐに目当てのコモンイベントを検索することが
可能になりました。

他にも効率化のために改良が施されています。
イベントコマンドの表示も一部改善されており、
UDB書き込みイベントコマンド用の表記なども追加されています。
(※UDB書き込みはイベントコードを弄らないと作れない
　ウディタで公式にサポートされていないイベントコマンドです)

本ツールを使用してウディタによる
ゲーム開発がより速く、より楽になれば幸いです。

DOWNLOAD(ダウンロード)

WoditorOptimizer Ver2.0.0公開

CommonEvent.datを最適化して処理の高速化を図る
WoditorOptimizerを大幅アップデートしたVer2.0.0を公開しました！

DOWNLOAD(ダウンロード)

-------------------------------------------------------------------
本アプリケーションは『.NET Framework 4.5.2』が使用されています。
起動できない場合は以下をインストールしてみてください。
http://go.microsoft.com/fwlink/?LinkId=397708
-------------------------------------------------------------------

< 主な変更点 >

・開発環境をC++/CLIからC#に移植
　　各処理を全て一新しています。

・UIの一新
　

・最適化項目追加
　　・ラベル地点を含まない『回数付きループ[0]回』削除

　　・『回数付きループ[1]回』を削除してループ内の処理を取り出す

　　・変数操作の『データを呼ばない』を最適化

　　・DB書き込みを最適化

　　・CSelfX～CSelfYの変数操作分解

　　・コモンセルフ名を削除

　　・コモンイベント名を隠蔽

　　・コモンイベントのメモを削除

　　・数値入力/文字列入力の各引数名を削除

　　・返り値名を削除

　　・コモンイベント色をランダムに変更する

　　・定数回ループの展開

・既存の最適化項目改善

　　・『コモンEv名で呼出』を番号呼出に変換する

　　　　→指定された名前が見つからなかった場合は変換しないように変更。

　　　　　従来まではコモンイベント0番が呼び出しに変換されてしまっていた。

　　・ラベル名の最適化

　　　　→特殊文字が使用されている場合はそのコモンイベント内では

　　　　　最適化されないように変更。

・データの取り扱いにWodiKsライブラリを使用
　　データの扱いをWodiKsライブラリに一任しています。
　　WodiKsライブラリを使用すればここまでできるという指標を示す意図もあります。

　　※本ツールで使用しているWodiKsは未公開の最新バージョンです。
　　　試用してみたい方はフォルダ内のWodiKs.dllを使用していただいてかまいませんが
　　　マニュアルなどは一切ありませんのでご注意ください。
　　　(まだテスト中/未テストの機能もあるため新機能はバグまみれの恐れがあります)

・最適化後に各最適化項目に該当したものがどれだけあったか確認できる機能
　

・最適化の実行順序を示す『実行フロー』ウィンドウ
　　内部でどの順番で最適化が実行されるかを可視化します。
　　将来的に実装されるかもしれないプラグイン機能に向けた機能の１つです。
　

・その他
　　上記以外にいくつか細かい修正が施されています。

DOWNLOAD(ダウンロード)

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

前回の第1弾に引き続き
ウディタ中級者上級者向けの小ネタ第2弾です！

<< 目次 >>

・ラベル名に特殊文字を使用してリアルタイムでジャンプ先を変更する

・『1』か『0』かのフラグは1つの変数に最大で32個管理できる

・コモンイベントの返り値の格納先にCDB等を指定する方法

・ゲーム中に指定した名前のコモンイベントを起動する。

・ゲーム中にDBのタイプ数を調べる方法
・ファイルが存在するか確認する方法※扱い方注意
・先頭ビットのみ『1』をセットする方法
・通常変数や予備変数の各変数にメモを記述する
・ループ中断の処理負荷
・ループ開始へ戻るの処理負荷

ラベル名に特殊文字を使用してリアルタイムでジャンプ先を変更する

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

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

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

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

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

『1』か『0』かのフラグは1つの変数に最大で32個管理できる

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

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

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

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

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

コモンイベントの返り値の格納先にCDB等を指定する方法

以下はコモンイベント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の値を書き換えることも可能。

ゲーム中に指定した名前のコモンイベントを起動する

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

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

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

ゲーム中にDBのタイプ数を調べる方法

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

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

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

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

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

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

ファイルが存在するか確認する方法※扱い方注意

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

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

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

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

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

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

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

先頭ビットのみ『1』をセットする方法

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

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

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

通常変数や予備変数の各変数にメモを記述する

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

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

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

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

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

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

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

活用方法もある）

ループ中断の処理負荷

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

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

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

よって

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

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

つまり

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

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

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

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

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

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

ループ開始へ戻るの処理負荷

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

回数付きループの場合

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

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

実行される。

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

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

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

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

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

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

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

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

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

ウディタの中級者上級者向け小ネタ集第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』のようにイベントコードに対しての削除はできませんが
　将来的にはオマケとしてイベントコードに対しても実行できるモードを
　用意するかもしれません。

α-Stella[R]_ブログ

ウディタ機能拡張ツール Wodistant Ver1.0.0 正式リリース！

ウディタ機能拡張ツール Wodistant β版公開！

ウディタ専用 統合開発環境 『Woditoride』公開！！

WoditorOptimizer Ver2.0.0公開

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

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

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

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

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

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

ウディタ専用統合開発環境『Woditoride』公開！！