XPとVX系のタイルの違い その３
一番重要なタイルIDについて。
まずはXPとVX系すべてで共通するオートタイルの中身。
オートタイルは周囲のタイルで自動に形が変わるタイルですが、
これはエディタ側の機能であってゲーム側には自動で形を変える機能はありません。
ゲーム側にあるのはオートタイルを以下のような４８パターンのタイルに変更し、
その中からIDで指定されたタイルを標示しているだけです。
とりあえず覚えておきたいのは、ひとつのオートタイルにつき４８のIDが使われていると言うことです。
次に全体のID割り当てについて。
XPの場合、0～47番は何もないタイルとして設定されています。
48番から48区切りでオートタイルのIDになっています。
48～95、96～143、・・・最後が336～383。
通常のタイルセットのIDがこの続きとなり、左上から右に384～となります。
こちらはひとつのタイルにつき、IDはひとつです。
VXAceの場合、タイルIDの順番がちょっとややこしいです。
まずタイルセットＢが0～となっており、Ｂ以降のタイルセット一つにつき256のIDが使われています。
セットＢが0～、セットＣが256～、セットＤが512～、セットＥが768～。
そして1024～1535までは不明です。たぶん使われていません。
1536～1663がセットＡのパーツ５になります。
オートタイルではないので、タイルごとに１つのIDです。
さらに2047までも不明です。これもたぶん使われていません。
2048からがオートタイルとなります。
パーツ１が2048～、パーツ２が2816～、パーツ３が4352～、パーツ４が5888～。
で、最後にXPからVXAceにIDを変換するときの目安。
まず通常のタイルセットはXPが384～、VXAceが0～となっているので
単純に-384すればいいように思えますが、
XPの素材ではID384が何もないタイルではないので空けなければなりません。
ID384が何もないタイルに出来るのであれば384を引き、
出来なければ128引いてセットＣからを使うということも出来ます。
ちなみにアクイトアイでは後者を使っています。
オートタイルについてはXPが48～、VXAceが2048～となっているので+2000ですが、
前回の記事に書いたとおりアニメーションを使うタイルによって値が変わります。
アニメーションしないタイルはパーツ２の2816～なので、
それとの差分を加算する必要があります。
IDの大まかな説明は以上です。
改めて思うのは、やっぱり素材化は無理ですね・・・
まずはXPとVX系すべてで共通するオートタイルの中身。
オートタイルは周囲のタイルで自動に形が変わるタイルですが、
これはエディタ側の機能であってゲーム側には自動で形を変える機能はありません。
ゲーム側にあるのはオートタイルを以下のような４８パターンのタイルに変更し、
その中からIDで指定されたタイルを標示しているだけです。
とりあえず覚えておきたいのは、ひとつのオートタイルにつき４８のIDが使われていると言うことです。
次に全体のID割り当てについて。
XPの場合、0～47番は何もないタイルとして設定されています。
48番から48区切りでオートタイルのIDになっています。
48～95、96～143、・・・最後が336～383。
通常のタイルセットのIDがこの続きとなり、左上から右に384～となります。
こちらはひとつのタイルにつき、IDはひとつです。
VXAceの場合、タイルIDの順番がちょっとややこしいです。
まずタイルセットＢが0～となっており、Ｂ以降のタイルセット一つにつき256のIDが使われています。
セットＢが0～、セットＣが256～、セットＤが512～、セットＥが768～。
そして1024～1535までは不明です。たぶん使われていません。
1536～1663がセットＡのパーツ５になります。
オートタイルではないので、タイルごとに１つのIDです。
さらに2047までも不明です。これもたぶん使われていません。
2048からがオートタイルとなります。
パーツ１が2048～、パーツ２が2816～、パーツ３が4352～、パーツ４が5888～。
で、最後にXPからVXAceにIDを変換するときの目安。
まず通常のタイルセットはXPが384～、VXAceが0～となっているので
単純に-384すればいいように思えますが、
XPの素材ではID384が何もないタイルではないので空けなければなりません。
ID384が何もないタイルに出来るのであれば384を引き、
出来なければ128引いてセットＣからを使うということも出来ます。
ちなみにアクイトアイでは後者を使っています。
オートタイルについてはXPが48～、VXAceが2048～となっているので+2000ですが、
前回の記事に書いたとおりアニメーションを使うタイルによって値が変わります。
アニメーションしないタイルはパーツ２の2816～なので、
それとの差分を加算する必要があります。
IDの大まかな説明は以上です。
改めて思うのは、やっぱり素材化は無理ですね・・・
スポンサーサイト
XPとVX系のタイルの違い その２
下記のスクリプトを更新しました。
選択肢拡張
遅くなってしまいましたが、報告のあった不具合を修正しました。
「選択肢のカーソル位置記憶」という機能を使用した状態だと選択肢の内容が更新されないため、
半透明にする描写が正常に機能しない場合があるという不具合でした。
報告ありがとうございました。
前回の続き
オートタイルの違い。
まず用意する画像の規格が違うのは、ヘルプを見ると分かると思います。
規格の変換については、たぶん検索するとツールが見つかるのでそちらを使用してください。
XPとVX系では、サイズが違うだけでなく扱い方も違います。
XPは好きなオートタイルを７つまで選べるようになってます。
VX系はタイルセットＡの規格に合わせて、まとめる必要があります。
で、問題はアニメーションさせるタイルの扱い。
XPではオートタイルを横に複数並べればアニメーションするのに対し、
VX系ではタイルセットＡのうちパーツ１しかアニメーションしません。
つまり、XPの７つまで設定できるオートタイルのうち、
どれをパーツ１に変換し、どれをパーツ２以降にするかを先に決めなくてはなりません。
VX系ではかなりの種類のオートタイルが用意されていますが、
XPからの変換を使うと７種類しか使用できないだけでなく、
アニメーションするタイルとしないタイルの比率まで制限されます。
これも考えてマップで使用するオートタイルを選ばないと変換できないです。
マップ作りで気をつけるのはこれくらい。
次回は細かな仕様について。
選択肢拡張
遅くなってしまいましたが、報告のあった不具合を修正しました。
「選択肢のカーソル位置記憶」という機能を使用した状態だと選択肢の内容が更新されないため、
半透明にする描写が正常に機能しない場合があるという不具合でした。
報告ありがとうございました。
前回の続き
オートタイルの違い。
まず用意する画像の規格が違うのは、ヘルプを見ると分かると思います。
規格の変換については、たぶん検索するとツールが見つかるのでそちらを使用してください。
XPとVX系では、サイズが違うだけでなく扱い方も違います。
XPは好きなオートタイルを７つまで選べるようになってます。
VX系はタイルセットＡの規格に合わせて、まとめる必要があります。
で、問題はアニメーションさせるタイルの扱い。
XPではオートタイルを横に複数並べればアニメーションするのに対し、
VX系ではタイルセットＡのうちパーツ１しかアニメーションしません。
つまり、XPの７つまで設定できるオートタイルのうち、
どれをパーツ１に変換し、どれをパーツ２以降にするかを先に決めなくてはなりません。
VX系ではかなりの種類のオートタイルが用意されていますが、
XPからの変換を使うと７種類しか使用できないだけでなく、
アニメーションするタイルとしないタイルの比率まで制限されます。
これも考えてマップで使用するオートタイルを選ばないと変換できないです。
マップ作りで気をつけるのはこれくらい。
次回は細かな仕様について。
XPとVX系のタイルの違い その１
「アクイ ト アイ」の製作では、XPのエディタでマップを作ってVXAceで読み込むと言う
ちょっと強引なことやって複雑なマップを作ったりしてました。
なぜこんな面倒なことやってたかというと、XPではタイルを３層自由に配置できるため、
立体的なマップを作るのに適していたからです。
とはいっても、ただ拡張子を変えるだけでは読み込むことは出来ません。
結構中身が違うので、VXAceの規格に合わせてXPのデータを変える必要があります。
で、それぞれの中身についていろいろと調べたわけですが、
そろそろどっかにメモしとかないと忘れちゃいそうなので
今日はそれについて書いておこうと思ったわけです。
別にメモ帳に書いて保存しておいてもいいのだけれど、
せっかくブログあるんだしブログに書きます。
メモ書きみたいな内容なので、分からない人にはさっぱり分からないし
どうでもいい人にはどうでもいい内容です。
ちなみに、XPマップをVXAceで読み込むスクリプトは素材化する予定はありません。
というのもXPのマップがそのまま使えるわけではなく、色々と制限がつくので
その制限を意識してマップを作らないと読み込めないため、めんどくさいのです。
● プライオリティの違い
画面にマップを表示するクラスをTilemapクラスといいます。
それに使用するタイルセットの画像やマップデータを設定することで、
エディタで作ったマップが画面に標示されます。
XPもVXAceも、タイルマップの層の数は基本的に同じ３層です。
なら簡単に読み込めるんじゃないかと思うかもしれませんが、
結構細かな違いがあるわけです。
その違いの一つが、プライオリティの扱いです。
プライオリティというのはXPで使われていた名称で、
VXからは「通常キャラの上に表示」されるタイルとなっています。
プライオリティの方が書きやすいので、ここはプライオリティと書きます。
まずVXAceのプライオリティについて。
VXAceでは単純にプライオリティを設定したタイルがキャラの上に標示されます。
分かりやすい構造になってます。
が、プライオリティが設定されたタイルが全てキャラの上に表示されるかといったらそうではありません。
正確には、
「３層目に設置されたタイルでプライオリティが設定されているものがキャラの上に表示される」
です。
こうなっているのはエディタを見るとわかるのですが、
プライオリティが設定できるのはタイルセットのB～Eまでです。
そしてこのタイルセットB～Eは、３層目にしか配置できないようになっています。
これがXPでは、プライオリティが設定されているタイルを１層目や２層目にも配置でき、
ちゃんとキャラの上に標示されます。
つまり、XPのエディタで自由に配置できるといっても、
VXAceでは３層目にプライオリティ設定したタイルを設置しないとキャラの上に表示されないわけです。
ここがマップ作りで気をつけなければならなかった点です。
ですが、裏を返せばプライオリティが設定してあっても、１層目や２層目に配置すれば
キャラの下に標示されるということでもあります。
これを利用すれば、同じタイルでもキャラの下に標示したり上に表示したりできます。
（ただし、通行判定もいじる必要あり）
とりあえずプライオリティについては以上です。
他についてはまた近いうちに書く予定。
ちょっと強引なことやって複雑なマップを作ったりしてました。
なぜこんな面倒なことやってたかというと、XPではタイルを３層自由に配置できるため、
立体的なマップを作るのに適していたからです。
とはいっても、ただ拡張子を変えるだけでは読み込むことは出来ません。
結構中身が違うので、VXAceの規格に合わせてXPのデータを変える必要があります。
で、それぞれの中身についていろいろと調べたわけですが、
そろそろどっかにメモしとかないと忘れちゃいそうなので
今日はそれについて書いておこうと思ったわけです。
別にメモ帳に書いて保存しておいてもいいのだけれど、
せっかくブログあるんだしブログに書きます。
メモ書きみたいな内容なので、分からない人にはさっぱり分からないし
どうでもいい人にはどうでもいい内容です。
ちなみに、XPマップをVXAceで読み込むスクリプトは素材化する予定はありません。
というのもXPのマップがそのまま使えるわけではなく、色々と制限がつくので
その制限を意識してマップを作らないと読み込めないため、めんどくさいのです。
● プライオリティの違い
画面にマップを表示するクラスをTilemapクラスといいます。
それに使用するタイルセットの画像やマップデータを設定することで、
エディタで作ったマップが画面に標示されます。
XPもVXAceも、タイルマップの層の数は基本的に同じ３層です。
なら簡単に読み込めるんじゃないかと思うかもしれませんが、
結構細かな違いがあるわけです。
その違いの一つが、プライオリティの扱いです。
プライオリティというのはXPで使われていた名称で、
VXからは「通常キャラの上に表示」されるタイルとなっています。
プライオリティの方が書きやすいので、ここはプライオリティと書きます。
まずVXAceのプライオリティについて。
VXAceでは単純にプライオリティを設定したタイルがキャラの上に標示されます。
分かりやすい構造になってます。
が、プライオリティが設定されたタイルが全てキャラの上に表示されるかといったらそうではありません。
正確には、
「３層目に設置されたタイルでプライオリティが設定されているものがキャラの上に表示される」
です。
こうなっているのはエディタを見るとわかるのですが、
プライオリティが設定できるのはタイルセットのB～Eまでです。
そしてこのタイルセットB～Eは、３層目にしか配置できないようになっています。
これがXPでは、プライオリティが設定されているタイルを１層目や２層目にも配置でき、
ちゃんとキャラの上に標示されます。
つまり、XPのエディタで自由に配置できるといっても、
VXAceでは３層目にプライオリティ設定したタイルを設置しないとキャラの上に表示されないわけです。
ここがマップ作りで気をつけなければならなかった点です。
ですが、裏を返せばプライオリティが設定してあっても、１層目や２層目に配置すれば
キャラの下に標示されるということでもあります。
これを利用すれば、同じタイルでもキャラの下に標示したり上に表示したりできます。
（ただし、通行判定もいじる必要あり）
とりあえずプライオリティについては以上です。
他についてはまた近いうちに書く予定。
軽量化スクリプトの解説 その２
今回はメニュー画面の軽量化解説です。
「ぼくらの大革命！」はバージョン1.3で、メニューを開く時間も大幅短縮されました。
ここで使った軽量化のいくつかは、既に「レスポンス向上」スクリプトに入れてあったりします。
ですが、一番効果のあった軽量化はちょっと特殊なので入れてません。
それについて解説したいと思います。
通常メニュー画面を開くと、キャラクターのステータスが右側に表示されます。
このステータスの描写は全員分行われるので、
９９９人ともなればフリーズしたかのように重いです。
これを何とかせねばと、描写の高速化をいろいろ図ったのですが、やはり限界がありました。
そこでふと思いついたのが、画面に映っているキャラのステータスだけ描写すればいいのでは？
というものでした。
この画像で言えば、一番上の"騎士C"から"見習い戦士P"までを描写して
残りは描写しないと言うことです。
画面をスクロールさせたら、まだ描写していないキャラをそのとき描写すれば、
見た目的には従来と変わりません。
これがうまくいき、人数が多くても少なくてもメニューを開く時間が変わらなくなりました。
ホント、こういうのって後から思えば当たり前だけど、それに気づけるかどうかですね。
で、この軽量化ですがスクリプト素材として配布できるんじゃないかなと考えています。
というのも、このやり方で軽量化できるのは、キャラのステータス描写だけではなく
アイテムの描写なんかでも使えます。
アイテムが何百と言う数を所持するゲームだと、カテゴリを切り替えるたびに一瞬止まったり
してしまいますが、これを軽減することが出来る・・・はずです。
最近、スクリプトも更新してなかったので、いろいろと修正済んだのと一緒に
公開したいなあとは思ってます。
以下、コメントお返事です。
「ぼくらの大革命！」はバージョン1.3で、メニューを開く時間も大幅短縮されました。
ここで使った軽量化のいくつかは、既に「レスポンス向上」スクリプトに入れてあったりします。
ですが、一番効果のあった軽量化はちょっと特殊なので入れてません。
それについて解説したいと思います。
通常メニュー画面を開くと、キャラクターのステータスが右側に表示されます。
このステータスの描写は全員分行われるので、
９９９人ともなればフリーズしたかのように重いです。
これを何とかせねばと、描写の高速化をいろいろ図ったのですが、やはり限界がありました。
そこでふと思いついたのが、画面に映っているキャラのステータスだけ描写すればいいのでは？
というものでした。
この画像で言えば、一番上の"騎士C"から"見習い戦士P"までを描写して
残りは描写しないと言うことです。
画面をスクロールさせたら、まだ描写していないキャラをそのとき描写すれば、
見た目的には従来と変わりません。
これがうまくいき、人数が多くても少なくてもメニューを開く時間が変わらなくなりました。
ホント、こういうのって後から思えば当たり前だけど、それに気づけるかどうかですね。
で、この軽量化ですがスクリプト素材として配布できるんじゃないかなと考えています。
というのも、このやり方で軽量化できるのは、キャラのステータス描写だけではなく
アイテムの描写なんかでも使えます。
アイテムが何百と言う数を所持するゲームだと、カテゴリを切り替えるたびに一瞬止まったり
してしまいますが、これを軽減することが出来る・・・はずです。
最近、スクリプトも更新してなかったので、いろいろと修正済んだのと一緒に
公開したいなあとは思ってます。
以下、コメントお返事です。
軽量化スクリプトの解説 その１
自分が作ったスクリプトの解説とか前から書いてみたかったので、
「ぼくらの大革命！」で使用した軽量化スクリプトの解説なんかしてみようと思います。
「ぼくらの大革命！」はバージョン1.3の更新で、大幅に軽量化しました。
人数が９９９人でも、処理落ちとかしなくなったと思います。
（ＰＣのスペックにもよりますが・・・）
あの更新での一番の軽量化は、画面に映っていない仲間の移動処理を行わないようにしたことです。
とはいっても、それではいざ画面に映ったとき、
おかしな位置に仲間が立ち止まっていた状態になってしまいます。
そうならないように、プレイヤーが１歩移動するごとにすべての仲間が
移動後の位置へと瞬時に移動するような処理も加えてます。
つまりは画面に映っていないキャラは、マス目とマス目の間をワープしながら移動してたりします。
正直、この軽量化は大して効果がないと思っていました。
なぜなら、マス目とマス目の間を移動する処理と言うのは、それほど複雑なものではないからです。
たとえば、X座標の１から２へと移動する場合、
座標が入ってる変数に１以下の数値を足しているだけです。
0.1ずつ足せば、10フレームで１から２になります。
（実際はもうちょっと複雑です。
通常は上限を超えないように配列を作成したりしますが、
そこは元から改良してあって配列を作成しないようにしてあります。）
なので、この軽量化を行った後のラグ解消には、私自身驚きました。
なぜ、こんなにも効果があったのか。
私が衝突判定のほうが重いと思っていたからでしょう。
衝突判定はもっと複雑です。
マップチップの移動可能判定から全てのイベントと衝突しないかの判定まで行うので、
イベントが多くなるほど処理が重くなります。
後ろをついてくるだけのキャラにこれは必要ないので、
この処理がなければ良いと思っていました。
ですが考えてみれば、衝突判定が行われるのは移動開始の１フレームだけです。
マス目とマス目の移動は数フレームの間処理が行われます。
さらにそれが９９９人でずっと移動し続けてるとなれば、とても重くなるわけです。
とまあ、解説したところでこんな知識が役立つゲームなんて他にないでしょうけど・・・
ですが、軽量化には１フレームしか行われない複雑な処理より、
毎フレーム行われてるちょっとした処理を見直したほうが良いということですね。
そういう意味では、またひとつ賢くなれたと気がします。
「ぼくらの大革命！」で使用した軽量化スクリプトの解説なんかしてみようと思います。
「ぼくらの大革命！」はバージョン1.3の更新で、大幅に軽量化しました。
人数が９９９人でも、処理落ちとかしなくなったと思います。
（ＰＣのスペックにもよりますが・・・）
あの更新での一番の軽量化は、画面に映っていない仲間の移動処理を行わないようにしたことです。
とはいっても、それではいざ画面に映ったとき、
おかしな位置に仲間が立ち止まっていた状態になってしまいます。
そうならないように、プレイヤーが１歩移動するごとにすべての仲間が
移動後の位置へと瞬時に移動するような処理も加えてます。
つまりは画面に映っていないキャラは、マス目とマス目の間をワープしながら移動してたりします。
正直、この軽量化は大して効果がないと思っていました。
なぜなら、マス目とマス目の間を移動する処理と言うのは、それほど複雑なものではないからです。
たとえば、X座標の１から２へと移動する場合、
座標が入ってる変数に１以下の数値を足しているだけです。
0.1ずつ足せば、10フレームで１から２になります。
（実際はもうちょっと複雑です。
通常は上限を超えないように配列を作成したりしますが、
そこは元から改良してあって配列を作成しないようにしてあります。）
なので、この軽量化を行った後のラグ解消には、私自身驚きました。
なぜ、こんなにも効果があったのか。
私が衝突判定のほうが重いと思っていたからでしょう。
衝突判定はもっと複雑です。
マップチップの移動可能判定から全てのイベントと衝突しないかの判定まで行うので、
イベントが多くなるほど処理が重くなります。
後ろをついてくるだけのキャラにこれは必要ないので、
この処理がなければ良いと思っていました。
ですが考えてみれば、衝突判定が行われるのは移動開始の１フレームだけです。
マス目とマス目の移動は数フレームの間処理が行われます。
さらにそれが９９９人でずっと移動し続けてるとなれば、とても重くなるわけです。
とまあ、解説したところでこんな知識が役立つゲームなんて他にないでしょうけど・・・
ですが、軽量化には１フレームしか行われない複雑な処理より、
毎フレーム行われてるちょっとした処理を見直したほうが良いということですね。
そういう意味では、またひとつ賢くなれたと気がします。
