0_0_64B

 obake   specification   version 

0_0_64 をベースにバグチェックしながら、細かい機能実装。

0_0_64 以降、セーブデータは項目が複数追加されている。主にプレイヤーの環境情報の取得で、デバッグ用。HTML5 では機能しない。Windows PC 及び Android などモバイル機器では動作する。

os_get_info(); 関数は HTML5 での動作を

Save Data の Section 名一覧

  1. “play”
  2. “init”
  3. “InitGUI”
  4. “settings”
  5. “SYSTEM_INFO”
  6. “DebugRestart”

全 6 種類の Section Name が登録されている。

0_0_64A でセーブデータに “SYSTEM_INFO” の Section を追加。起動時にシステム全般のデータを取得して保存。基本的には使わないデータだが毎回取得して保存しているので無駄に感じている。現在はデバッグで必要な時があるかもしれないので念の為保存しているだけだが、将来的にはオプションを有効にしない限り保存しない設定とする。

Room 追加

0_0_64A で start を game_menu と分割して独立した ROOM とする。

start の役割は新設されたオブジェクト .init_screen から create Event を実行すること。ここではグローバル変数の定義や Shaders の初期化、セーブデータの読み込みと書き込み、スクリーンサイズの取得、プラットフォームの判定、スクリーンサイズからウィンドウサイズの変更、など。アプリケーションのシステム要件を満たしているかなど、動作環境をチェックするための動作が多く仕込まれている。スクリーンサイズよりもゲームアプリケーションのウィンドウサイズが大きい場合にはウィンドウサイズを小さくする。

game_menu は従来からあった .st の動作を引き継ぐ。ただし、初期化処理部分は start へ引き渡したので、こちらは純粋にメニューを表示する機能へ専念させる。

メモリ解放処理の追加

各ルームに配置されたイベント管理用オブジェクトには ROOM 終了時 データ構造に利用していたメモリ領域を確実に解放する処理を追加。

例えば Game Engine では .ev というオブジェクトが管理用だが、ROOM END のタイミングで利用していた全てのデータ構造を破棄する処理を追加した。

EV_DS_CLEAR 関数に .ev で利用される全てのデータ構造がリストアップされている。

このリスト以外にも .ev では局所変数にデータ構造を利用したケースがあり、これについては利用したその場で念の為に解放処理を実行している。

しかし runner.exe 上で room_restart を意図的に繰り返し実行することでメモリの使用量がどうなるかを監視したが、最終的に 77 回程度リスタートかけると out of memory になってアプリが落ちる現象は解消されなかった。

これについては Android 実機も room_restart を繰り返すと最終的にアプリが落ちる現象として再現性があったので、共通して言えることとしては、room_restart は意図的に何度も繰り返し実行すべきではない。あるいはそのような仕様のゲームを作るべきではない。

Windows Build に関しては YYC（ YoYoComplier ） で再現性をチェックしたが、やはり 77 回でアプリは強制的に落ちた。

データ構造で利用した変数を明示的に開放してもしなくても room_restart の多用はアプリをクラッシュさせる。

内蔵の Grid Editor を少しだけ機能拡張。

Grid Editor

最低限の機能しか付けていない。開発者用、一般ユーザには見せない部分。グリッドを作成する機能。レベルエディタ。

二種類の Grid を ini に保存できる。ただしデータ構造は一つしか扱っていないので、保存する際には同じデータ構造を名前だけ変えて保存している。

保存する対象を内部的に切り替えていることを示すため、画面下部にボタンを設置。ターゲットを切り替えた場合、背景色を別のものへ変える処理を追加。編集対象を切り替えたことを見た目でわかりやすくした。

ROOM の追加

Game Settings の実装

Save Data が拡張されたので、先にゲーム設定画面の作成に着手。

room.game_menu に直接実装することも考えたが、一応手間をかけて Room を分割することにした。

room.game_setting として実装を開始。

Room transition の実装

Room を切り替える際、演出として遷移効果を付けることにした。専用の room.transition として実装を開始。

Room 名は各モード毎に異なるため、.transition という Room は存在しない。

（ Transition はゲームの基本操作を学ぶミニチュートリアルを兼ねるようなものにしたい ）

実装された ROOM の一覧

  1. start - - - ● 実装済み
  2. game_menu - - - ■ 実装中
  3. Story_Mode- - - ▲ 実装開始
  4. Time_Attck- - - ▲ 実装開始
  5. omake_mode - - - ✕ 未実装
  6. game_setting - - - ▲ 実装開始
  7. game_engine - - - ■ 実装中
  8. Grid_Editor - - - ● 開発者用：実装済み
  9. stage_A - - - ✕ 未実装

Room の階層構造

  • start
    • game_menu
      1. Story_Mode - - - Intro ／ Stages
      2. Time_Attck - - - Play ／ HighScore
      3. omake_mode - - - 未実装
      4. game_setting - - - Set ／ ?
      5. EXIT - - - 未実装（存在しない）

バグ

新規お化け補充後の 3-Match 判定にチェック漏れが出ている件。

新しいバグではなく従来から確認されているバグ。0_0_59Aで実装された部分に問題があるのだと思われる。

総当り方式のチェックが必要か否かの選択で、一旦重力操作したタイルにだけ対象を絞って 3-Match 判定していたが、これがダメっぽい。結局総当り方式に近い規模のチェックが必要みたいだ。

しかし再現性の証明がメンドイ…

なので、バグはそのまま放置して先にステージとかレベルのロード機能などを実装、デバッグをしやすい環境を作ってからデバッグ作業へ移りたい。

総当り方式は TS_CK_Solver で実装済みなので、用途は違うがロジックは転用できる。

補充後の判定処理は QF_3Match で行っている。OBKSummon == 0 がトリガー。OBKQue が利用しているデータ構造。.rebirth オブジェクトの Alarm 0 で ds_queue_enqueue(OBKQue, d); として利用される。これには新しく作成されたインスタンスのID、つまり新しく補充された「お化け」のIDが入っている。




次へ

前へ