ウディタの中級者上級者向けの小ネタ第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

ウディタコンテストに向けて

ツイッターではけっこうウディタコンテストに向けて作ってる
ゲームの話を頻繁にしてますが
何気にブログの方ではほとんどふれていなかったので
その辺のことについて書きたいと思います


ジャンルはスクロールアクションゲームです
正確にはたぶん多方向スクロールアクションシューティングゲーム？
になるのかな？

スクリーンショット↓






まあ完成度的には20%ぐらいですね
ちなみにタイトル名は決まっていません

実はタイトルを決めずにここまでゲーム作ったのは
今回が初めてです（笑）

いつもは先にタイトル名決めて、タイトル画面を作ってから
システム作ってました。

なんかタイトルとタイトル画面を先に作ると　
作らざるおえない感じがするんですよね

まあそれは置いといて
とりあえず
今回こそはウディコンに間に合わせたいです

去年はEnergy Gateを作ってましたが
結局間に合いませんでしたからね、今回こそ間に合わせて見せます
………
ただ問題なのは、今年は高校3年で受験があるってことなんですよね
ゲームなんか作ってる場合じゃない気がするんですが
両立してみせますよ、はい
とりあえずこのゲームだけでも全身全霊で！

まあがんばれば確実に間に合うとは思います
実際Energy Gateは開発開始したのが7月17日でしたからね
それでウディコンの締め切り当日の23時には全システムは完成していました
ステージの用意とチュートリアルが間に合わなかっただけでした
（まあゲーム性が微妙でしたが（笑））

で今作ってるのは2月28日から作ってますから
本気出せばなんとかなりそうな予感です

まあコンテストに向けてはそんな感じですね



たぶん今年は受験とかで勉強しなければなので
このゲーム開発以外の作業はほとんどできない気がしますが
完成して無事にコンテストに間に合えば
次の開発作業は
ウディタツールの作成やゲーム開発補助ツールの作成になると思います
たぶん！ですが

あるいはARPGの開発になるかも？
まあとりあえず受験がどうにかなるまでは
あまり手を付けられなさそうです


ま、精一杯頑張ります！

Chord Assistor公開！&現状報告

作曲補助ソフトChord Assistor公開しました！
※β版(Ver0.95)です

DL↓
http://ux.getuploader.com/k_shin07/download/5/ChordAssistor_%CE%B2%E7%89%88.zip



開発時間があまりとれないので一旦公開します
一応最低限の機能はついているので使えるとは思います

Ver1.00公開時に追加・修正される予定の機能は
・編集対象の切り替え簡略化
・MIDI出力機能
・インフォメーションウィンドウ
・ヘルプ

です

ただしMIDI出力はどうなるかは不明です
MIDIの解析作業から始めないとなので

ちなみにこのソフトは
コード進行を作成を補助する目的として作りました

将来的には
転回に対応したりして高機能化したいところですけど
時間的問題と知識的問題等で
どうなるかは不明です

4月入るまでにVer1.00公開を目標としたいですけど
たぶん過ぎます
なのであまり期待はしないでください

それとMajとかminとかのコードの種類の説明が表示されますが
説明がないのがほとんどですので

説明できる方がいたら是非情報提供を！

=====================================================
ここからは現状報告です

ウディフェスはテスト期間なため諦めました
ついでにそのゲームプロジェクトも中止
いつか再開するかもしれないし、再開されないかもしれない

そのかわりにウディコン参加を目指して
横スクロールACTゲームを作ろうと思っています！

時間的には体験版になるかもしれないですけどね
まあその辺は努力します

それと
ひそかにARPGの開発プロジェクトが進んでいたり進んでいなかったり
まあ企画段階ですが
本格的に作る予定なので軽く1年はかかると思います
一応報告
完成するかは不明ですけど

まあ今のところこんな感じですかな

新年明けましておめでとうございます

新年あけましておめでとうございます！

最近はあまり作業をしていなかったので
特に書くことがないんですけど

まあChord Assistorとかその辺の開発情報というか
そんなのを書きたいと思います

■Chord Assistorについて
現段階の完成度はおよそ90%ですね
これからの作業内容は

・iniへの設定入出力処理
・操作の簡略化（左クリックでプレビュー再生、右クリックで編集対象へ）
・補助ウィンドウ
・MIDI出力機能
・メニューバーの搭載
・ヘルプ作成

だいたいの作業内容はこんな感じ

MIDI出力機能とメニューバー搭載はもしかしたら
一旦公開したあとになるかもしれません

というかメニューバーは確実に公開後
になります(いろいろとめんどうなので)

一応Chord Assistorって何って方のために
簡単な説明をしておきます

作曲の基盤となるコード進行を作るときの
補助プログラムという感じです

現段階のスクリーンショット↓























■Energy Gateについて
これについてはもしかすると
開発中止ということになることもありえるかも
時間的にあまり余裕もないですし、ゲーム性も微妙ですからね

まあもし開発を続ける場合の作業予定内容は

・起動時の演出を強化
・背景の本格化
・ショップ処理の高機能化
・エフェクトの大幅強化
・コンボボーナスの獲得率の補正機能
・シグナル固定時に固定されたシグナルに変化を見せる
・アイテム効果表現の工夫
・制限時間制の廃止
・ゲート破壊実装
・ゲームオーバー仕様の変更（全ゲート破壊）
・ゲートエネルギーゲージ、フィールドエネルギーゲージの搭載
・速度・頻度レベルアップ時の消費対象をスコアからエネルギーへ
・頻度レベルの効果の調整
・崖システム(案)
・その他いろいろ

さすがに全部書くとすごい量になるので
細かいところは省きましたが
まあこんな感じです

■これからについて
まずはChord Assistorを完成させたいと思います
予定としては1月10日までに公開したいですが
微妙なところです
でもまあ1月中には公開してみせます

それともしEnergy Gateの開発を続ける場合で
間に合いそうでしたら
ウディフェスに出すかもしれません
出さないかもしれないですが
まあどちらにしろ開発を続ける場合かつ完成したらの話ですが

あとは
新しいゲームを作るかもです
ジャンルはARPG
まだいろいろと考えてる途中ですけどね
でも
システムとグラフィック的に大変そうなので
開発期間はとても長くなりそう
それに
今年からは高校3年なので
受験に忙しくなりそうですから
今年はあまり作業できないかもしれない
という
悲しい現実(>_<)

まあそんな状況ですが
今年もがんばりたいと思います！