Acenumber Technical Issues

今流行りのAI、即ち人工知能とタイトルすれば甚だ釣り気味ですが、 ゲーム作成に於いてはコンピュータにプレイヤーの相手をさせる場合、 大にしろ小にしろ孰れ其の為のアルゴリズムを用意しなければなりません。 其れは手元の開発iPhone専用ゲームアプリ バルーンズオキュパイ でも一般です。

略してバルオキュでは プレイヤーが画面上に風船を膨らませて自陣を拡張しているのに対し 此のゲームでは敵キャラクターとなる うさ犬 兄弟の弟、 はなまる が画面上を所狭しとジャンプしまくりプレイヤーが膨張させつつある風船を割って回る、 と言うゲーム内容になっています。 此の際、はなまるはプレイヤー陣地の確定した部分は避けて飛ぶ必要があります。 また膨張中の風船にはなまるが飛び込めば其の風船は割れてプレイヤーの負けが確定しなければなりません。 此の両者の解決を同時に図る上手い方法はないものかと模索して、 どうやら共に衝突判定が使えるだろうと思い付きました。 ゲームAIに衝突事件を組み込んで実装すればはなまるは確定風船を避けつつ時には膨張中の風船を割りに掛かるだろうと言う目論見です。

衝突判定の実装は一般に難しいと言われる処ですが アップル社がXcodeに用意する2Dゲーム開発フレームワークである SpriteKit には最初から其の機能が用意されているので其れを用いることにします。

陣取りゲームとして目論む処のゲーム主画面に於いては 陣地の遣り取りの判定のために画面全体を区切る必要があります。 区切った画面各々にプレイヤーの陣地か如何かの判定フラグを持たせ 更には他にも様々に応用して用いる使い勝手の良い 配列 として扱う腹積もりです。 この際ゲーム画面の幅に合わせて区切りを柔軟に保たせるために 可変配列を用いることにします。

可変配列オブジェクト NSMutableArray の概要については iPhoneアプリ開発の虎の巻 のページ NSMutableArray などが参考になるかも知れません。

キャラクターが空を飛んでいるのを表現するのに iPhoneの画面を超えて縦横無尽に飛び回る状況を作り出したい為に上方に上限を設けぬ実装を鑑み Spritekitに於ける座標系を考察したのが以下列挙する本ブログの両記事です。

• Spritekitに於ける座標系（2016年7月9日）
• Spritekitに於ける座標系補遺（2016年7月11日）

処が此処に問題の内在が発覚しました。 時折デバッグの為に変数を出力して検討するのは誰もが実行する処でしょう。 2017年5月5日記事 SpriteKitに於ける時間軸に基づく背景グラデーションの独自実装 に記したようにゲームに於いてキャラクターが上空に飛翔すればするほど 宇宙空間に近いた表現で空色を濃く染め上げるのに背景色を変化させたのですが 此の時必要なのはキャラクターの縦軸の位置変数であるのは言う迄もありません。 其の変数とした honmaruPosYRatio の算出法は以下コードとなります。

アップル社がiPhoneアプリ開発に提供する2Dゲーム用フレームワーク SpriteKit を開発アプリに適用すればゲーム画面内に物理空間を生じせしめ 内部でオブジェクト同士の衝突の検出を可能にします。

Getting Started with SpriteKit

処でアップル社が提供する統合開発環境、 IDE（Integrated Development Environment） 足るXcodeでは補完機能が随分重宝します。 特にスティーブ・ジョブズに依って齎された NEXTSTEP を継承するアップル社の開発環境では長くなり勝ちなメソッド名や変数名などを扱うには 補完機能がないとなると実に不便に感じるものです。

さてSpritekitを利用して開発するゲームに於けるコーディングでは 利用するクラスファイルのヘッダファイル冒頭に以下記述が必要になるのは周知でしょう。 先ずはSpritekitをインポートしなければならないのは言わずもがなです。

下の図は手持ちのiPad Pro 9.7インチ版のApp Storeで Swift Playgrounds で検索した結果表示です。 どの環境でも此の如く先ず真っ先にアップル社が提供するiPad専用アプリ Swift Playgrounds が表示されるでしょう。

アップル社から提供されるアプリで尚且つ無料でもあり躊躇うことなく入手インストールします。 なお Swift Playgrounds の詳細説明画面を開けば下図のように 何やら楽しげな内容を垣間見せるものとなっています。 レートが 4+ 、即ち制限なく年少者にも問題なく見せられる設定となっており アップル社としては積極的に次代を担う子供達に使用を促すものとして提供されている様子が伺えるでしょう。

プログラムをしていれば思わぬ結果に右往左往するのも多くあります。 其れはiPhoneアプリ開発に於いても例外ではありません。 以前では其の開発言語は Objective-C の一択であり自らもアプリを幾つか当該言語で以て記述してリリースしました。 今は多くアップル社から提供された新開発言語 Swift で書かれるアプリも多くなってきました。

Swiftは型に厳格な言語で更には思わぬバグを防ぐために 何の値をも持たない nil （null）を許す際には当該事項も型として用意されるものです。 optional （オプショナル）型と称すものですが なかなか理解が難しく正直自身も恥ずかしながら正確な部分迄把握は出来ておらず 都度都度対処療法を施している様な状況です。

さて今回落とし穴に陥ったのは変数の文字列化に於いてでした。 既にリリースのなっているアプリをバージョンアップしようと機能追加するに於いては 変数の宣言も形や場所を変えざるを得なくなります。 従来は変数の宣言を3次元配列から一義に代入していました。 以下の如くです。