0_0_56

 obake   specification   version 

リビジョンを 0_0_56 へアップ。６月で製作は一時停止していたが、その間は Shader 関連の技術点検。

Shader は最終的に GLSL ES: Shader 48 という別サイトを作って一段落。今後 Shader 48 は追加更新を行うが、しばらくゲーム本体の製作を優先、新規 Shader の製作／公開はプライオリティ下げる。

shader 関連の記事はアーカイブとして残したが、トップに表示されない。カテゴリ Shader からアクセス。今後 Shader というカテゴリには本ブログで記事追加は無し。（ Shader は専門ページとして Shader 48 を用意した ）

製作再開とドキュメントなどの点検

製作中断はあらかじめ予定の内、中断／再開してすぐ作業に取り掛かれるよう、仕様をまとめたドキュメント類はこのブログ風製作日記も含めてきちんと残しておいた。

変数や関数のメモは詳細なものがあり、ソースコード見てももはや誰が書いたこれ？状態だけど、説明書見ながらだったらなんとかなるはず。というわけで、再開と同時に新機能追加、及びシェーダの組み込みとシェーダを使った描画処理の効率化・点検作業など。

シェーダは通常描画でも処理速度的なメリット

いわゆる Pass-Through でも GPU へ描画処理をまわすのは速度的恩恵がありそうとのこと。一般的には GPU のせいでむしろ遅くなったというケースは無いらしい。

今回は途中からシェーダを組み込んでいるため、そのせいで新しく不具合が発生しないかそちらには懸念がある。現在までの所、新しい問題は確認されていない。HTML5 での動作も含めて全て問題なし。

新機能の実装

６月で中途半端になったのは、コンボが途切れた後の処理となる。

コンボが途切れたら、空いたゲームボードのスペースに新しいお化けを上から落として隙間を埋める処理が必要。いわゆる落ち物パズルとしてのゲームエンジンはこれで一応完成目処が付く。

コンボおよびコンボ連鎖中の判定は二つの変数が絡む。

TryCombTimer

ComboCounter

TryCombTimer はコンボチャレンジをタイマー管理するための変数。

ComboCounter はコンボが何回連続したかをカウントする。

この二つの変数状態を監視すれば、コンボが途切れた瞬間は条件として抽出できる。

コンボを決めると、盤面上のオブジェクトは消えていく。盤面上のオブジェクトを消すことでボーナスを得るが、盤面上のオブジェクト数が少なければ少ないほど、ボーナス獲得は高い点数を貰える。コンボが完全に途切れた時、盤面上にオブジェクトスペースがある場合はお化けを補充する。

以上を新規お化け補充のための仕様とする。まずコンボが完全に判定終了していること。そして動いている（ 落下中 ） オブジェクトが無いこと。

すると

    MvBricksPaiRFlag = false;

    MvTargetCT = 0;

上記２つの変数状態を判定する必要も出てくる。

さらに、重力が機能中でないことを確認するためのフラグとして、落下中は true なので

Phy_Falling = false;

これも追加。

つまり？

お化け補充のため、条件は複数あってタイミング制御が重要。まだ難しく考え過ぎだが、要するにコンボが途切れたらすかさずお化けを補充すれば良い。しかしコンボ判定が途切れるまでにタイムマージンを設けてあるので、そのわずかな時間でタイルスワップ操作は可能になる。つまりコンボ判定が終了しても、アクティブタイルスワップを無意味に繰り返せば、スワップ中はお化けが補充されない。

    !Phy_Falling 重力が機能していない

    TryCombTimer == 0;

    !MvBricksPaiRFlag 
if (!MvBricksPaiRFlag and !Phy_Falling and TryCombTimer == 0;){
};

最低三つで条件を作れば安全。

お化け補充は上から落下パターンと唐突に現れるテレポート型、二種類が考えられる。

実装が楽なのはテレポート型。（ 落下型は落下位置の計算・再計算処理がある ）

コンボが終了したらという条件は今後ゲームイベントを拡張する上で利用する機会がありそう。

コンボ終了のタイミング

QF_ComboChallenge ユーザ定義関数が扱う。

この関数によると、コンボが終了してもその時点でまだ落下中のオブジェクトがある可能性を示唆している。同時に落下オブジェクトが無い場合の条件も判定しているので、この関数が実行されるタイミングでイベント定義を作成すれば良さそう。この関数自体を拡張するのはまずくて、新しくユーザ定義関数を作成し、独自にタイミング制御用の関数として利用する。

となると、新しく作成するユーザ定義関数の実行タイミングは毎 step 、Check_TypeOne関数の実行されるタイミングということになる。

新しいユーザ定義関数と、新しい判定用フラグのために instace 変数を用意する。とりあえず QF_Dororon という関数を作成した。そして条件判定用の専用変数を用意する。>> しかし既存の変数リストを眺めたらすでにそれ用の変数だけは確保されていた。まだ未使用。これを使う。

CtCaptuN

PiTCount と同じタイミングでカウントを行うが、PiTCount はゲーム中に値が増加し続け 0 にリセットされることはない。対する CtCaptuN はコンボ判定中は PitCount と同じタイミングで増加するが、コンボが終了した時点で値が 0 にリセットされる。この違いがある。

TryCombTimer の値が 0 の時に ユーザ定義関数 TS_CK_3MatchIsTrue で判定用フラグ変数 DororoFlag = true となる。

こうしてタイミングは作成できた。ユーザ定義関数 QF_Dororon にまとまっている。これからイベントを作る。




次へ

前へ