カテゴリー: iPhoneアプリ作成

アニメーションがごく自然に盛り込まれるアップル社の代表的な製品 iPhone で更にゲームを拵えるとなればアニメーションは必要不可欠で加えて2Dゲームフレームワーク SpriteKit を採用すればぱらぱらアニメの実装が重要となってきますが、 2016年6月17日の記事で紹介したぱらぱらアニメの実装手法 、即ち UIImageView での実装では煩雑故に取り回しが良くなく塩梅悪い場面が多くなってきます。

ところでSpriteKitでは SKNode を単位としてゲーム画面中に取り込むと取り回しが良く楽にもなります。 従って当然の如くSKNode内にはぱらぱらアニメを取り込めるように設計されています。 此の機能、 テクスチャアトラス を用いたアニメーションの実装はゲーム開発には必須となるでしょう。

開発するiPhoneゲームアプリでは 耳で空を飛べる特殊能力を持つキャラクターの うさ犬 を何処まで遠く飛ばせるかを競うものにしたいと考えました。 ゲーム画面としてはうさ犬を中央に配置して 地面の側をスクロールして飛んでいるように見せる ゲームとしては定番の処理を施す目論見です。

然うとなると地面は無限にスクロールしなければなりません。 但し無限の横幅を持つ地面の画像を用意するのは不可能です。 其処で此れ又ゲームとしては定番の処理として 一定幅の地面の画像が右からスクロールして左に消えると同時にタイミング良く同じ画像インスタンスを生成し 繰り返しスクロールさせて恰も無限に地面が続くように見せる手法を用います。

Xcodeで色を使用するに於いて最も基本的な方法は標準的フレームワーク UIKit の UIColor クラスを使用します。 其の際、色を指定するのにRGB夫々に於いて値は0から1の間で示される小数である必要から 16進カラーを小数変換する （2016年5月21日）処理を施しました。

処で此の如く簡略化しても未だ煩わしく 更にコード記述を省力化出来る方法はないかと探しせば サイト成長の果実 の2011年12月3日の記事として以下リンク先に見える如き もっと手軽にWeb式RGB指定出来る方法が共有されていました。

iPhoneに限らずアップル社の製品ではアニメーションが多用され ユーザーインターフェースの一部となりユーザーの操作把握の大きな助けとなっています。 一般のアプリにおいてすら然るべくあれば況やゲームに於いてをや、 開発中のアプリはブロック崩しにて特別に大きなアニメーションは必要ありませんが タイトル画面ではプレイ画面でボール足るキャラクター ウパンダ のボールとして呼び出される前に呑気に居眠りしている様子を表現したく思いました。

而してウパンダのぱらぱらアニメを実装すべく目論んだのでしたが但し タイトル画面ではプレイ画面で利用しているアップル社純正の2Dゲーム用フレームワークの SpriteKit は読み込ませていませんから最も基本的な Cocoa Touch の UIKit フレームワークでぱらぱらアニメを実装しなければなりません。

人情として何時迄も同じハイスコアを表示しておきたくない場合もあるでしょうとて、 ハイスコア削除機能 を以て削除する機能を実践したのでしたが実は其の際画面遷移、 例えばハイスコアをクリアするボタンを実装した設定画面からメニュー画面に 遷移した後にクリアした筈のハイスコアが表示されてしまう問題が発生してしまいました。

原因としてはどうやらハイスコア削除及びハイスコア表示のメソッドの呼び出しのタイミングに有るようです。 タイミングとしては UIViewController のデリゲートメソッドを利用していますから 然るべきタイミングのメソッド内にてハイスコア削除若しくは表示メソッドを呼び出せば良い理屈です。

ゲームに必須の機能として先ず盛り込んだ ハイスコア機能 では取り敢えず保存と表示を実現しましたが、 理由は孰れにせよ保存されたハイスコアを削除したい機会も訪れるでしょう。 例えば何の気なしに貸し与えた友人が己の手の届かぬハイスコアを叩き出し 何時になっても己の追い着けぬ高得点を見せ付けられるのが堪えられないのも又人情です。

iPhoneアプリ開発では慣れていないと凡そ見当の付かないトラブルに 出会（でくわ）します。 開発中のゲームアプリでは 設定画面に表組みを利用しました が例えばHTMLでtableタグを用いるような極く常識的な感覚で実装していたら思わぬ陥穽に嵌まってしまいました。 何処にも繰り返しの命令など記述していないにも関わらず 実際にアプリを走らせてみると設定画面の表を縦に、上にスクロールして行くと 上で表示された筈の内容が再び下から現れるのでした。

最初は此の現象を前にして皆目意味が分かりませんでした。 ソースを試行錯誤して少しだけ変更するのを繰り返したりしましたが一向に改善は見られない処か 増す増す深みに嵌まってしまうのでか細い 縁（よすが） ですが iOSプログラミングでは表組みの実装に使うクラス UITableViewController をキーワードにするなどしてネットを繰って漸く見付けたのがサイト ”たゆたえども沈まず”で の2013年3月28日の記事でした。

参考記事に於いては以下引用の記述が目に止まります。

ゲームアプリに限らずiPhoneアプリに於いては アニメーションはユーザーに現在アプリがどのような状況にあるか知らせるために重要な役割を果たします。 其れは画面遷移時の動きに於いても一般です。

開発中のゲームアプリに於いては画面遷移は面クリアー時及びゲームオーバー時などに発生します。 ブロック崩しゲームの面クリアー時には 必ずボール足るキャラクターがブロック足る果物の最後の一つを食す筈です。 またゲームオーバー時にはボール足るキャラクターが地面に落下している筈です。 当然其れ等の処理はプログラム内に記述してあるのですが 全て処理は飛ばされて画面遷移が発生しているとしか思えない状態が発生してしまいました。 プレイヤーに取っては訳も分からず突然画面が切り替わるように感じられる由々しき事態です。

アプリの開発中はなるべくなら環境を変えたくはないものですが 長期に及べば然うも言ってはいられません。 開発環境がソフトウェアとしての不具合など修正されている場合も多ければ尚更です。 初めてのXcodeアップデート には此の如き不安も抱えての実施ではありました。

案の定問題の発生したのは AdMobメディエーション に於いてでした。 Xcode5から5.1へのアップデートに伴い開発中のゲームアプリが ビルド出来なくなってしまったのです。

初開発iPhoneゲームに ブロック崩し を選択し、 参考サイトに助けられながら も実装を進捗するに 徐々に己独自の要素を持ち込みたくなるもの、 また此れなくばアプリ開発の意味はありませんし アップル社に申請したとて審査通過の後 App Storeに陳列されなどしないでしょう。

盛り込みたく目論んだのはゲームの一方の主役たるブロックが 古（いにしえ） より連綿たる単なる四角では面白くもなく 此れを果物に変えんと欲し又プレイヤーが面クリアーする毎に 果物の種類を変えたく目論んだのでした。