This post is written in Japanese.
2015年9月、iOS版GoogleMobileAdsのduplicate symbols問題もYosemite & Xcode 6.4へのアップデートでようやく解決し、開発の終わりが見えてきた。
ということで開発後記。
開発者の視点に興味がない人は読まなくて大丈夫です。
開発動機
2014年9月、別のアプリを作ろうと思ってUnityを試してみたら、レンダーテクスチャが有料版でしか使えないことがわかり、まずは無料版でUnityの基礎を覚えるため、習作としてWIRE KIDの開発に着手。
リリースするかは決めてなかったが、試作の段階でスマホ向きのゲーム(後述)であることに気付いたのでちゃんと作りこむことにした。
道のり
基本的にMSX版、iアプリ版のリメイクということもあり、ゲームの本体部分は一か月足らずでほぼ完成。
遅くとも2014年末にはリリースできると思っていた・・・
本業が忙しくなると仕事のことしか考えないため、期間と稼働時間は必ずしも一致しないが、全体の流れはこんな感じ。
2014年10月 画面遷移を実装(OnGUI)
2014年11月 リプレイデータのシェア、広告ユニット組み込み。この辺からプラグイン周りで苦労し始める。
2014年12月 iOS版とAndroid版のリーダーボード実装。
2015年1月 年末に間に合わなかったことで吹っ切れて、ゲームの細かい調整に乗り出す。
2015年2月 Unity 4.6に移行。画面遷移をuGUIで完全に作り直す。
2015年3月 実績を実装。
2015年4月 宇宙に星を描いたり、各種アニメーションをいじったり。
2015年5月 Unity 5に移行。GoogleMobileAdsと同プラグインも差し替え。
2015年6月 GIMPでお絵描き(スプライト書き直し)
2015年7月 GIMPでお絵描き(エフェクト系アクセサリ実装)
2015年8月 GIMPでお絵描き(着せ替え系アクセサリ実装、アイコンも追加)
開発環境やライブラリの更新では必ずトラブルに見舞われており、対応にそれなりの時間を割いている。
ゲーム作りにもっと頭を使いたいんだけどなー。
ワンキーアクション
WIRE KIDは「押す」より「放す」ほうが重要なゲームになっていて、幸運なことにスマホとの相性が良い。
人間の指がガラス板を強打するようには出来ていないことを僕はjubeat plus(KONAMI)から学んだ。
フック
iアプリ版以前はボタン押下時に画面右上に向かって射出される移動物体だった。
今回はボタン押下中に自機の移動方向から左90度に存在するリングに向かって射出される光速の何かになった。
物理的にはあり得ないが、ゲーム的には正義。
ワイヤー
一方、こちらは物理エンジンの力を借りている。
ブランコの動画とかめっちゃ見て勉強した。
5倍の重力環境と光速フックさえ用意できれば君もリアルワイヤーキッドだ！
ちなみにiアプリ版以前はワイヤーを放した瞬間、掴んでいたリングの位置にかかわらず画面右方向に謎の推進力が発生していた。
Unity 4から5への移行で物理エンジンの挙動が変わって過去のリプレイデータがすべて死んだ。
今後もあり得る話だが、気にしないことにした(伏線)。
リング
ワイヤーを放すまでにリングの配置をどれだけ把握できるかで難易度が変わる。
なので、進行方向の視界を広げるために2.5D画面とし、上下画面外の手がかりとしてリングを鉄柱で連結した。
何はともあれ三角トラスは美しい。
東京スカイツリーより東京タワーがかっこいいのは何故かを考えていたときに鉄柱をトラス構造にしようと決めた。
リーダーボード
デイリーのリーダーボードは内部的には曜日ごとに用意していて、その週間データを表示している。
Game Centerは単純に直近1週間分のデータを取ってくるのであまり考えなくていいが、Google Play Game Serviceは全期間、週間、日次がそれぞれ独立した別テーブルらしく、週間データは日曜23:59(PST)にリセットされる。
デイリーステージが夕方ごろに切り替わるのはこの仕様に合わせたため。
ただ、実際にはPST 0時より1時間早くリセットされている。これが噂のサマータイムなのか？
半信半疑なまま、PDT→PST、PST→PDTを実装してみたが、これで正しいのかは11月になるまでわからない。
iアプリ版ではランキングにリプレイデータが紐づいていて1位の人の超絶プレイが簡単に見られた。
今回もやろうと思えばできたが、ワールドワイドなトッププレイヤーのプレイなんてドン引きするほどクレイジー(褒め言葉)に決まっているので、あえてやらないことにした。
というのも実際にiアプリ版でドン引きしたからだ。
たかし氏には敬意を表する。
リプレイデータ
そのリプレイデータについて今回はURLにエンコードしてシェアする形で実装した。
短縮URLサービスをストレージとして利用させてもらっているとも言える。
射出フック数に上限を設定しているのはリプレイデータが大きくなりすぎると短縮URLサービスが利用できなくなる心配があるため。
実績
Google Play Game Service、Game Center、アプリ内部の三か所にデータを準備して管理するのがとにかく大変だった。
各プラットフォームサービスを必須にすればアプリ内部にデータを持たなくて済むが、利用率がわからないため決断しにくい。
あと、iOS 7で実績解除バナーが出ない、Unity 5のReportProgressが機能してない等、散々悩んだ末に環境のバグだったときの徒労感。
もうやりたくない。
アクセサリ
装備品による自機のパワーアップも考えたが、以下の理由により不要と判断した。
- パワーアップの有無で味わいの変化をつなくても素のワイヤーアクションが十分に楽しい
- 自機が段階的にパワーアップするなら、それに合わせた壁(ステージ)を用意するべきだが、そういうゲームデザインではない
- アクセサリを揃えないと同一条件でスコアを競えない
- シェアされたリプレイデータが性能重視のアクセサリばかりだとつまらない
バナー広告
画面上のどこを押しても良いワンキーゲームだと、バナー広告は操作の邪魔にならない限り常に出しっぱなしのほうが誤クリックを減らせるのではないかと思うが、パフォーマンス上の懸念からゲーム中は非表示にしている。
最高に重いテスト広告とか配信してくれないかなぁ。
インタースティシャル広告
よそのゲームで同じ広告が短時間に何度も表示された経験から、インタースティシャル広告自体の表示頻度を極端に低く設計した。
どんなに儲かるとしても同じ広告を繰り返しユーザに閉じさせるのはダメだと思う。
実際にAdMobがそういう配信の仕方をするのかはテスト広告が1種類しかないので不明。
というか、もしかしてテストデバイスはリリース版でもテスト広告しか見られない？
→ストアからダウンロードしてもテスト広告だったわー
リリース
まず、Android版を公開してみたらPlayゲームのサインインで10004エラー。
数時間の調査後、Google PlayじゃないほうのコンソールでクライアントIDの名前がクリックできることに気づいてフィンガープリントが空になっているのを発見。
結果から原因までの距離が遠い、遠いよ！
あと、誰かアプリとサービスとAPIの相関図を書いて欲しい。
最後はiOS版を申請するだけ。
ところが最終動作確認でAndroid版のリプレイデータが正しくリプレイできないことが発覚。
arm64のためにUnityのIL2CPPを有効にしたことで物理エンジンの挙動が微妙に変わっている。
開発初期ならともかく今更物理エンジンを捨てて自前のロジックに置き換える気にはなれない。
結局、シェア時にAndroid版かiOS版かを区別できるようにして逃げた。
いつかUnityのIL2CPPが改善されることを期待しながら・・・
総括
頑張りすぎた。
もっと気楽に緩いアプリを作りたい。