IT database for myself
アップル社がiPhoneアプリ開発に提供する2Dゲーム用フレームワーク 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次元配列から一義に代入していました。 以下の如くです。
ファミコン以来ゲームはコントローラーを以て操作するのが常道でしたが
iPhoneに代表されるスマートフォンの普及に連れタップやスワイプ、
フリックなどで操作する必要が
先ずタップではタッチを検出し、其の位置を検出し、 タッチの時間が閾値内であるならタップとするためタッチしている時間を検出する必要があるでしょう。 当該案件に関する有用な情報を昨日2017年3月27日配信した記事 -(void)update:(CFTimeInterval)currentTimeメソッドに於ける任意時間のコールバックメソッド でも参考にしたiPhone及びiOSゲームアプリ開発のチュートリアルサイト RAYWENDERLICH TUTORIALS FOR DEVELOPERS & GAMERS を参考にします。 現在Swiftをメインに SpriteKit Swift 3 Tutorial for Beginners が配信されていますが本稿では2014年4月12日の試行に於いて現在アーカイブされている Objective-Cで書かれた情報ページを参考にします。
ゲーム開発に時間の処理が欠かせぬものとしてiPhoneアプリ内で 時間は如何様に扱われるのかの検証記事として本ブログに2017年2月19日に配信したのが -(void)update:(CFTimeInterval)currentTimeメソッドに於けるシステム時間の参考出力と考察 でしたが此のメソッドは任意の単位時間毎にコールバックメソッドを呼び出すにも応用が効きます。 其の様な応用を用いればこそ此のメソッド及び呼び出されるコールバックメソッドにて キャラクターのリアルタイム移動、 アイテムの一定時間毎の出現、 イベント起動、 等のゲームならではの機能を実現せしめ得ます。
関してはiPhone及びiOSゲームアプリ開発のチュートリアルサイト RAYWENDERLICH TUTORIALS FOR DEVELOPERS & GAMERS では以前日本語で有益な情報を提供してくれていましたが今は当該記事は残念ながら削除されている様です。 但し英語版が当時のObjective-Cでのコード記述から装いも新たにSwiftのコード記述に変えて 現在でも用意されていますので下にリンクを貼り置きます。
SpriteKit Swift 3 Tutorial for Beginners
またObjective-Cでの記述もアーカイブされているので其方も下にリンクを貼り置きましょう。 本記事に記載されるコードは単位時間毎の処理を実装した当時 2014年4月12日の試行錯誤に習い最後のコードを除き基本的には以下のページから引用するものです。
iPhoneアプリを開発するにあたって開発環境である Xcode は勿論、 アップル社からは様々な純正のフレームワークが無料で提供されています。 中にも SpriteKit なるフレームワークは2Dゲーム開発用に提供されているもので iPhone専用にネイティブでゲームを開発するにはとても便利で有用です。
処でゲーム開発には時間の処理が欠かせません。 キャラクターの移動をリアルタイム処理したり 一定時間毎にアイテムを出現させたりイベントを起動させたり様々な要請が考えられるでしょう。 手元の開発ゲーム うさ犬が行く などでも其の開発初期にはアニメーションの表示タイミングを測るのに覚束ない面がありました。 SpriteKitではルートのViewとして用意されるクラス SKScene には initWithSize メソッドが用意され通例此処にゲームの初期設定などを記述しますが 此処にアニメーション表示タイミングを記述すると基本的に一定時間の繰り返し処理となり柔軟性に欠けます。 ゲーム内で要求されるフレキシブルな時間処理を把握するための取っ掛かりとして システム時間をログに出力させてみようと考えました。
なおゲームアプリ うさ犬が行く はリリース時には開発言語に Swift を採用していますが本記事に記述する内容の実行時期、開発当初に於いては Objective-C で記述していたものです。
開発アプリはどのようなものであれ状態は様々遷移するに違いなく 遷移した状態に依ってはユーザーインターフェースの機能も変化するのは往往にして要請される処です。 其の代表がボタンでしょう。 タップ可能であるからこそのボタンですが 場合に依ってはこのタップを制限したいのも屡々です。 手元の開発アプリはゲームですので ゲームの勝敗が着けば例えばゲームを進める機能を有するボタンは押されて欲しくなくなると言った塩梅です。
iPhoneアプリ作成で利用する Xcode 、 Swift ではボタン機能を有する機能は UIButton クラスで提供されています。 其のような言って見ればボタンクラスですので UIView を継承した UIControl クラスを継承しており此処でボタン足る様々な属性が提供されています。 アップル社の公式開発者用サイトの API Reference の UIControl - UIKit を見れば様々な機能が用意されているのが分かります。
機能に先立って先ずはボタンが実装されていなければなりません。 手元の開発アプリに於いては以下の如く Asset Catalogで登録した画像 を利用して実装しました。
iPhoneアプリに限らずとも開発場面に於いては座標の把握は大切でしょう。 Xcode の2Dゲームフレームワーク SpriteKit に於いても例外ではなく先祖ノードの当たるシーンに配置する 各子孫ノードには其々、座標原点、即ち基準位置があり標準では上下左右ともセンターに規定されています。
さて但し原点を左上に取るSpriteKit座標系では座標を考える上で 各ノードの左上に基準点があった方が具合が良い場合も多いでしょう。 此の中央に標準設定される基準点を変更せしめるプロパティは SKSpriteNode には anchorPoint として用意されています。
以上の如く記述すればノードの左上に基準点が設定されるのは屡々用いる所でもあります。 ところで文字を画面に表示せしむる SKLabelNode も同じで良いかと言うと此れは anchorPoint プロパティは持ちませんのでどうすれば良いかを調べ、検証します。
既に Xcode のバージョンは8を数える2016年秋現在、 バージョン5から画像管理用に特別な機能が導入されていました。 Asset Catalog です。 アイコンやローンチ画像管理に於いては所与のものとして用いていた .xcassets 拡張子の付与されるフォルダの外見を有したこの機能ですが 本来画像管理用の機能であれば此れを用いて画像を管理したいところです。 調べてみると此の機能を利用するだけでアプリ容量の低減にも有用だという記事もあります。
iOSアプリの画像を最適化してアプリの容量を減らすブログ shobylogy の2016年3月16日の記事ですが Asset Catalogを利用すると Slicing が有効になりデバイスごとに必要な画像のみが配布されるバイナリに含まれるためであるとの言及があります。 また併せてXcode6からはベクターデータが使えるようになったとの旨情報も有り あわよくば画像の作成をベクターデータで一つで済ませたい目論見もあり 本記事で其の為の検証をするものです
此れからのアップル社のiPhoneの画面解像度に関する方針としては launchimage.xib ファイルでローンチ画像を設定の上、 相対的な数値で全体を構成するべく予想されれば 此れに反する本ブログに2016年9月25日に公開した記事 ローンチイメージソースで解像度を指定し2サイズ対応で済ます方法 に於いて記す手法を採れば孰れアプリ申請拒否の憂き目に遭わぬとも限らず と懸念した処で当該記事は筆を擱きました。 さて、どちらの手法を採用するか躊躇う所考えているばかりでは埒も明かず 取り敢えずは25日の記事とは異なる手法の採用を鑑みた検証も実施しておくに如かず、 とてものする記事になります。
先ず画面サイズを簡単に一覧にすれば上のようになるでしょう。 画像は既存の前二者の2サイズに加え新しく後二者に対応させる必要がありますから 都合4サイズへの対応となるのでした。 しかし巷間用意する画像に関する情報に於いては 等倍、2倍、3倍の3種類で宜しいとの流布が喧しく其れが真実がどうかも併せ検証したく思います。 検証用に用意したのは以下の3サイズの replay-test ボタン画像です。
