IT database for myself
此れからのアップル社のiPhoneの画面解像度に関する方針としては launchimage.xib ファイルでローンチ画像を設定の上、 相対的な数値で全体を構成するべく予想されれば 此れに反する本ブログに2016年9月25日に公開した記事 ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法 に於いて記す手法を採れば孰れアプリ申請拒否の憂き目に遭わぬとも限らず と懸念した処で当該記事は筆を擱きました。 さて、どちらの手法を採用するか躊躇う所考えているばかりでは埒も明かず 取り敢えずは25日の記事とは異なる手法の採用を鑑みた検証も実施しておくに如かず、 とてものする記事になります。
先ず画面サイズを簡単に一覧にすれば上のようになるでしょう。 画像は既存の前二者の2サイズに加え新しく後二者に対応させる必要がありますから 都合4サイズへの対応となるのでした。 しかし巷間用意する画像に関する情報に於いては 等倍、2倍、3倍の3種類で宜しいとの流布が喧しく其れが真実がどうかも併せ検証したく思います。 検証用に用意したのは以下の3サイズの replay-test ボタン画像です。
開発対象機種がiPhoneであればこそ様々なフラグメントに悩まされもせず 安心して開発に専心出来るのが良点でもあったのですが 時代の趨勢はいつ迄も其れを許す訳もなく 愈々アップル社も旗艦iPhoneの画面サイズを多種類擁するようになりました。 以前、此のブログにiPhoneアプリ開発を扱うようになってからは iPhone4s及びiPhone5、5sの2サイズの解像度に対応すれば良かったのですが iPhone6以降ではPlusが加わり4サイズに対応する必要が生じたのです。
以下にシミュレータで上記コードを実行して取得した、 即ち画面横幅の各デバイスのサイズを記し置きましょう。
此の状況に於いて以前のように2サイズ対応の処理で済ます方法はないのか、 検証してみたのが本記事の趣旨となりますが、 その際サイト ぐーたら書房 の2014年9月10日の以下記事が役立ってくれました。
2Dゲーム開発に於いては座標の把握を難儀に思う処です。 2Dゲームフレームワークの SpriteKit を用いれば Scene 中の座標はその親 View たる UIKit の支配下にあるものとはY軸が逆転しますから尚更です。 Viewの入れ子はキャラクターの行動制限や把握などに便利なので利用したいのですが 入れ子にすればする程多重化した座標系は複雑化しますから トレードオフの関係となりジレンマで歯痒さを感じる処です。
iPhoneアプリ開発に於いて画面構成の基本となるのは UIView クラスです。 此のクラスは bounds プロパティと frame プロパティを持ち両者は CGRect を型としています。 開発を進めていけば両者の使い分けに混乱を来して来るのを感じた向きも多いのではないでしょうか。 どうやら入れ子になる座標系の把握については 先立って此れ等UIViewのプロパティを確り把握する必要があるようです。
ついてはサイト Sun Limited Mt. の2010年4月3日の以下の記事が大変参考になりました。
アイフォーンアプリ開発に於いてSDゲーム用フレームワークの SpriteKit を用いてアニメーションを実現するにあたり テクスチャアトラスを用いたアニメーションの実装方法 でテスト的に歩くウパンダをアニメーションさせてみたりしました。 この時コードとしては2016年7月21日の記事（ ゲームオーバー画面で表示されるアニメが重複描画される問題 ）に見られるように NSMutableArray を利用していましたが配列に簡単に収める必要性から連番画像を用意していました。
此処で画像を使い回す、即ち同じ画像を複数回使うのはセルアニメでは効率化の主要なテクニックですが 同じ画像は番号を振れば同じ番号となり連番とはなりません。 同じ画像に異なる番号を振れば実現は出来ますが無駄に容量を喰ってしまいます。 従って配列に収めるにあたり効率的に for 文で addobject する訳にも行かなくなります。 其の様な場合の難しく考えずごく簡単に一枚一枚の画像に対して 其々インスタンスを用意する記述をする実装法であれば 言って見れば生の実装法にも近く勉強の意味も予て実装してみることにしました。
手元の開発iPhoneゲームではプロジェクトにバージョン管理ツールとして git を導入 していました。 個人の開発ではチーム開発のように分担してブランチしたりマージしたりと言うような使い方は余りしませんが 試行錯誤を重ねる内に二進も三進も行かなくなったプロジェクトを 自身確定を認識している時点まで巻き戻すに実に有用だと考えます。
参考になったのはサイト Exception Code. の2013年9月1日の以下の記事です。
iPhoneアプリ開発に於いてアニメーションの実装方法には
UIKitフレームワークを利用したぱらぱらアニメ
だったり
SpriteKitで地面を無限スクロールする
煩わしいライブラリ間の依存の管理は CocoaPods に頼るべしとて流通する情報に任せ手元の開発アプリに導入したのが PhysicsDebugger でした。 SpriteKitフレームワークの物理エンジンで生成される物理体を可視化して 状態の把握を容易にしようと企んでの措置です。 此れは未だ慣れぬ中情報の不足した状況に於いてでしたが Xcode開発環境もフレームワークの SpriteKit も日々有難いことに開発が重ねられ状況も変じていきます。 SpriteKit 標準で物理体の可視化が可能になりました。
必然的に PhysicsDebugger は必要なくなりますので此れを外そうとした処が 此処に問題が発生した顛末が今回の記事となります。
アクションゲームの開発画面において衝突判定を可視化する要求に沿ってXcodeのライブラリ PhysicsDebugger を使うべく RubyGems のお膳立てをし Cocoapods もどうやらインストールのなるまで進捗しましたが 肝心の可視化が機能してくれない迄を綴ったのが2016年7月24日の 前編 にて本記事は其の続編、解決編になります。
解決の
開発ゲームアプリの開発画面に於いて 衝突判定を可視化したいために PhysicsDebugger なるライブラリを用いんと更にライブラリ管理のために Cocoapods を又此れをインストール足らしめるため RubyGems をアップデートしたものの尚守備良くは運ばなかった顛末を記したのが2016年7月24日の記事 Cocoapodsに依ってライブラリPhysicsDebuggerを使う（前編） でした。 此の問題を解決するためにネットを繰って目にしたのが アイエンターのアプリ開発ブログ の2014年4月4日の記事です。
【iOS】CocoaPodsを使ったライブラリ管理此の情報に Command Line Developer Tools のインストールが必要とあり 孰れにせよ此れは開発者用Macにはインストールが必須であるとの情報も散見しては 今回の記事をものする次第
SpriteKitフレームワークの物理エンジンで生成される物理体は ゲーム上のキャラクターなどを単純な形で包括して衝突判定などに活かされます。 ゲーム画面で見えてはならない此の物理体もゲーム開発中には想定通りの状態を保持しているか 把握のために可視化したくあります。 此の状況に有用なライブラリとして PhysicsDebugger が紹介されていましたので利用を目論むのでしたが さてライブラリを導入するとなると依存関係が気になります。 其の様な煩わしいライブラリ間の依存の管理は CocoaPods に頼るべしとて多くの情報が流通していましたので流れに身を任せた次第。
先ずCocoapodsのインストールですが 然うは問屋が卸さずとばかりにターミナルを用いた処理は途中で停止して一向に進みません。 Qiitaに2013年10月13日に配信される CocoaPodsがインストール出来ない時 などに依れば RubyGems をアップデートすべしとありますので従って後無事再インストールの首尾良く運んだのでしたが どうにも先が思いやられる感も有ったりしつつ＠ITの2014年3月10日の記事 生産性ガチアゲなオープンソースiOSライブラリ（終）：iOSライブラリ管理の神ツール「CocoaPods」のインストールと使い方 (1/2) を参考にターミナルから ~/.cocoapods ディレクトリを作成、場所の確認などもして先に進みます。
