投稿者: iPhoneアプリ作者

Make a game like Flappy Bird with Swift 3: Learn iOS game programming with SpriteKit and Swift (English Edition)

iPhoneアプリに限らずとも開発場面に於いては座標の把握は大切でしょう。 Xcode の2Dゲームフレームワーク SpriteKit に於いても例外ではなく先祖ノードの当たるシーンに配置する 各子孫ノードには其々、座標原点、即ち基準位置があり標準では上下左右ともセンターに規定されています。

さて但し原点を左上に取るSpriteKit座標系では座標を考える上で 各ノードの左上に基準点があった方が具合が良い場合も多いでしょう。 此の中央に標準設定される基準点を変更せしめるプロパティは SKSpriteNode には anchorPoint として用意されています。

以上の如く記述すればノードの左上に基準点が設定されるのは屡々用いる所でもあります。 ところで文字を画面に表示せしむる SKLabelNode も同じで良いかと言うと此れは anchorPoint プロパティは持ちませんのでどうすれば良いかを調べ、検証します。

既に Xcode のバージョンは8を数える2016年秋現在、 バージョン5から画像管理用に特別な機能が導入されていました。 Asset Catalog です。 アイコンやローンチ画像管理に於いては所与のものとして用いていた .xcassets 拡張子の付与されるフォルダの外見を有したこの機能ですが 本来画像管理用の機能であれば此れを用いて画像を管理したいところです。 調べてみると此の機能を利用するだけでアプリ容量の低減にも有用だという記事もあります。

ブログ shobylogy の2016年3月16日の記事ですが Asset Catalogを利用すると Slicing が有効になりデバイスごとに必要な画像のみが配布されるバイナリに含まれるためであるとの言及があります。 また併せてXcode6からはベクターデータが使えるようになったとの旨情報も有り あわよくば画像の作成をベクターデータで一つで済ませたい目論見もあり 本記事で其の為の検証をするものです

此れからのアップル社のiPhoneの画面解像度に関する方針としては launchimage.xib ファイルでローンチ画像を設定の上、 相対的な数値で全体を構成するべく予想されれば 此れに反する本ブログに2016年9月25日に公開した記事 ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法 に於いて記す手法を採れば孰れアプリ申請拒否の憂き目に遭わぬとも限らず と懸念した処で当該記事は筆を擱きました。 さて、どちらの手法を採用するか躊躇う所考えているばかりでは埒も明かず 取り敢えずは25日の記事とは異なる手法の採用を鑑みた検証も実施しておくに如かず、 とてものする記事になります。

au版 iPhone 6s 16GB ゴールド白ロム 4.7インチ MKQL2J/A

• 3.5インチ（iPhone4s）
• 4インチ（iPhone5, 5s）
• 4.7インチ（iPhone6, 6s, 7）
• 5.5インチ（iPhone6 Puls, 6s Plus, 7 Plus）

先ず画面サイズを簡単に一覧にすれば上のようになるでしょう。 画像は既存の前二者の2サイズに加え新しく後二者に対応させる必要がありますから 都合4サイズへの対応となるのでした。 しかし巷間用意する画像に関する情報に於いては 等倍、2倍、3倍の3種類で宜しいとの流布が喧しく其れが真実がどうかも併せ検証したく思います。 検証用に用意したのは以下の3サイズの replay-test ボタン画像です。

開発対象機種がiPhoneであればこそ様々なフラグメントに悩まされもせず 安心して開発に専心出来るのが良点でもあったのですが 時代の趨勢はいつ迄も其れを許す訳もなく 愈々アップル社も旗艦iPhoneの画面サイズを多種類擁するようになりました。 以前、此のブログにiPhoneアプリ開発を扱うようになってからは iPhone4s及びiPhone5、5sの2サイズの解像度に対応すれば良かったのですが iPhone6以降ではPlusが加わり4サイズに対応する必要が生じたのです。

au版 Apple iPhone SE 64GB ローズゴールド MLXQ2J/A 白ロム

以下にシミュレータで上記コードを実行して取得した、 即ち画面横幅の各デバイスのサイズを記し置きましょう。

• iPad2:320
• iPad Pro:375
• iPhone4s:320
• iPhone5s:320
• iPhone6:375
• iPhone6 Plus:414

此の状況に於いて以前のように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で地面を無限スクロールする 類（たぐい）のものだったり SpriteKitでテクスチャアトラスを用いたアニメーション だったり updateメソッドを用いた実装 だったりと幾つか本ブログにも紹介しました。 特にゲーム開発に於いては重要な役目を果たすアニメーションでは 引き出しを多く持った方が有利なのは間違い無く 状況に応じて適材適所で手法を適用すれば宜しからんと考えます。 今回は此れ等に加えて Spritekit の Spritenode に依るアニメの実装の事例を記事にしました。

煩わしいライブラリ間の依存の管理は CocoaPods に頼るべしとて流通する情報に任せ手元の開発アプリに導入したのが PhysicsDebugger でした。 SpriteKitフレームワークの物理エンジンで生成される物理体を可視化して 状態の把握を容易にしようと企んでの措置です。 此れは未だ慣れぬ中情報の不足した状況に於いてでしたが Xcode開発環境もフレームワークの SpriteKit も日々有難いことに開発が重ねられ状況も変じていきます。 SpriteKit 標準で物理体の可視化が可能になりました。

必然的に PhysicsDebugger は必要なくなりますので此れを外そうとした処が 此処に問題が発生した顛末が今回の記事となります。