今まで触れていなかったデバッグ文について述べておくと、我はこれに助けられたといってもit is no exaggerationだと思う。(我はこの単語をExあっげラテと覚える)
参考に、テストプレイで必要とするデバッグをつめこんだ部分の一部を紹介。
24番で… -->[ｺﾓﾝ156/567行]
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
2 0 0 0 0 0 0 0
4 0 0 0 0 0 0 0
6 0 0 0 0 0 0 4
12 6 0 0 2 0 2 6 -->[ｺﾓﾝ156/568行]
3列目列掘り -->[ｺﾓﾝ157/59行]
4列目列掘り -->[ｺﾓﾝ157/78行]
6列目列掘り -->[ｺﾓﾝ157/116行]
25番で… -->[ｺﾓﾝ156/567行]
0 0 0 0 0 0 0 0
0 0 0 0 2 5 0 0
4 0 0 0 3 1 0 0
2 0 0 0 2 3 0 0
4 0 0 4 1 4 0 1
5 1 3 2 4 1 0 3
13 5 4 1 3 5 1 4
6 3 5 4 2 4 2 15
12 15 2 3 4 1 3 6
5 6 5 2 11 2 4 13 -->[ｺﾓﾝ156/568行]
これらは、我が実際にリーチ機能がうまく動作するかどうかを確かめるために、わざわざ\cself(\の文字はあちらでは円マーク)の文字を80回もうった。
これによって、各マスの詰み状況が把握でき、これと照会して実際の挙動と一致するかどうかを確かめる。もちろんこれの再現でも何度もエラーが発生したと思われ、たとえば消しだまの判定の10部分の見落としなど。これらのデバッグ文があれば、実際との違いにより、どの部分でおかしなことが起きているのかだいたい見当がつく。
採掘ボーナス(配当の宝石(上では6と記されているもの))の判定は、左上から初めて0か6、以外のもののマスを探して行き、それに1をひいて8でわったものに1をたしたものがそのマスの段数になるので、その段数のはじめのマスマイナス1までのマスに配当があれば、それらはのちに採掘ボーナスとして入手できるものである、との判断に基づきリーチ処理を進めた…が、最後の段に関する判定で見落としがあり、すべて種別0か6の場合に誤った判断を下しているという事態に。これもデバッグ文で見つけられた。変数の内部値(F9で確認可能)はＯＫ。そしてデバッグ文でも正しい挙動。ならば採掘リーチの条件で間違えている、というふうに見当がつく。
こういったエラー特定を無数に繰り返してできたのが、せいぜい演出が少ないあれである。
変数呼び出し値の導入により、圧倒的に楽に大量の変数代入、呼び出し処理ができるようになり、こういう大量にピクチャを扱うゲームが作成可能となった。
参考までに我がメモしたピクチャの使用状況は、
基本的に100までが背景などの基盤となるピクチャ、20000までがキャンディドロップ(はじめちょっといろいろあってピクチャをむだづかいしすぎた)、25000までがビンゴボンバー、30000までがトレージャーシーザー(仮)、30001からがＢＥＴタイムなどの枠。ワンダーチャンス的なものを導入すればもちろん35000以上からとなる予定。
しかしこのゲーム、すでに言ったとおり動画録画を併用するとかくかくになるので、実際もう少しなめらかに動くところをみせられずまことに残念である。
さて、ちょっとここでこれまでとったスクリーンショットをはりつけていく。
日々進化する過程がわかって面白い。
