Posted by ※『マジカミ』はStudio MGCMより提供しております。
こんにちは、サーバーサイドエンジニアのsengokです。
先月11日、PC版マジカミのリリースから1年の時を経てiOS / Android版のマジカミがリリースされました。
遊んでいただいている皆様ありがとうございます！！
今回、私としてもGRIPHONEとしても初のiOS / Android版の開発ということで、どこから手を付ければいいのだろう？ゲームロジック以外にプラットフォームごとに特別にやらないといけないことって何があるの？といった具合に、かなり手探りでの開発になりました。
この記事では、私と同じようにスマホゲーム開発のメインエンジニアになったはいいけど何をしたらいいの？という方向けに、サーバサイドエンジニアとして早めに考慮しておけると幸せになれる点について書いていきたいと思います。
ユーザーデータ
サインアップ/サインイン
ユーザーがアプリを起動した際に何をフックにしてサインアップ/サインインをするか早めに検討できると良いです。
特に、アプリの再インストールによるリセマラを許容する場合、アプリのインストールごとに変更は入るものの、通常通り遊んでいる間は変わらないユニークなIDをどこかで発行する仕組みが必要になります。
リセマラ
リセマラを許容した場合、シンプルにユーザーIDなどで数値を見てしまうと一見DAUなどがすごいことになってしまいます。
サインアップ/サインイン時に使うユニークIDとは別に再インストールに関わらず、ある端末を使う限りずっとユニークなIDとして何を使うか考えられると良いです。
データ連携または引き継ぎ
まずは言葉の定義から早めに企画とすり合わせられると良いです。
例えば、マジカミではデータ連携（複数の端末で同じデータで遊べる）と引き継ぎ（旧端末から新端末にデータを移行し旧端末では遊べなくなる）と定義し、データ連携の仕様を採用しました。
特に、データ連携を採用した場合、ある端末ではバトルを行いながらまたある端末ではストーリーを読むといった同時挙動を認めるかどうかも検討すると良いです。
アクセス制御
メンテナンス
全体メンテナンス機能とは別に、プラットフォームごと、ガチャやショップなど特定機能だけのメンテナンスも用意できると良いです。
特に、あるプラットフォームだけで課金障害が起きた時などに最低限の機能だけ切り離し、その他の影響のない機能は遊べる状態を提供できると良いです。
※ 例えば、イベント期間中に特定プラットフォームだけ十分にイベントを走れないといったケースもあるためメリデメは懸念として残ります！
アカウントの利用停止
こちらもメンテナンス同様、全ての機能を利用停止にするか特定の機能のみに絞るかまで考慮できると良いです。
特にマジカミのようにデータ連携を採用した場合、iOS版では利用停止になったが、Android版では継続して遊べるといった抜け道が無いように作れると良いです。
バージョン管理
iOS / Androidではユーザーのアップデート状況により複数のアプリバージョンが混在する状況が発生します。
許容するアプリバージョンを最新のみにするか複数許容するか、許容や強制アップデートの管理をどこで行うのか検討できると良いです。
特に、新規に開発したバージョンのアプリに関してはAppleとGoogleの審査を受ける必要があるため、どのアプリバージョンが審査に当たるのかも管理する必要があります。
審査用のアプリバージョンで遊んだ際は接続先としてどのサーバー（本番用、審査用、開発用などなど）を選択するのかといった起動〜接続シーケンスは早めにクライアントも交えて話せると良いです。
運用によってはアプリバージョンだけでなく、APIやマスタデータのバージョンなども考慮する必要があります。大変ですね笑
課金
有償/無償通貨
まず、有償通貨（一般にジュエルやダイヤ、〇〇石と呼ばれるアレです）と無償通貨を分けて扱うのはもちろんのこと、有償通貨をiOS / Androidでも分けて扱うかまで考慮できると良いです。
有償通貨をプラットフォームごとに分けて扱う場合、どのプラットフォームで課金が行われて獲得したのかを判別できるように実装する必要があります。
特に、障害が起きた際はレシートや購入履歴のログにも獲得経路を記録できていると良いです。
ストア商品
iOS / Androidで課金アイテムを販売する場合、それぞれのストアにユニークな商品IDを用意して商品登録をする必要があります。
この商品IDは一度登録してしまうと、例えば下記のようなケースで再登録することができないため注意が必要です。
- 間違えて登録してしまったため、一度削除して再度登録する
- 同じ組織で本番用アプリとテスト用アプリを用意していた
テスト用アプリで商品ID item1の課金テストが終わったので本番用アプリにも同じ商品ID item1という商品を登録しようとした
レシート検証
iOS / Android の課金では、クライアントで課金決済時に各プラットフォームからレシートと呼ばれるものが発行されます。
サーバーサイドでは、このレシートを元に課金決済が不正に行われたものでないかなどを検証してあげることで、課金処理全体の堅牢性を高めることができます。
iOS / Androidでは検証の方法も異なり、本番用アプリとテスト用アプリでも検証方法が異なるため、複雑化しないように実装できると良いです。
返金対応
Android版（Google Play版）では、購入済みの商品に対してGoogle Play経由で比較的簡単に返金申請ができるようになっています。
返金の状況はGoogle Play ConsoleからGUIで確認できるほか、Google Play Developer APIのVoided Purchase APIを通じても知ることができます。
返金が行われた場合のゲーム内のアイテムはどうするか（例えば、回収を行うのか）、悪意を持って返金が行われた場合はどうするか（回収だけでなくアカウントの利用停止等のペナルティを課すのかなど）プロジェクトの方針も含めて話しておくと良いです。
その他
プラットフォームごとの情報の出し分け
例えば、iOS版だけで起きた不具合のお知らせやiOS版のみで使える機能（Sign in with Appleなど）のヘルプはiOSだけで露出するようにする、といったプラットフォームごとの情報の出し分けを考慮できると良いです。
KPI分析
有償/無償通貨の項目でも少し触れましたが、例えば、アイテムを獲得したといったような行動ログには、誰が、いつ、何を、何個獲得したといったような情報に加えて、それがどのプラットフォームで行われたのかまで記録しておくと良いです。
これらのログは、例えば障害時の復旧のためにサーバーエンジニアが利用するだけでなく、データマイニング/マーケティング/その他様々なチームがアプリの運用方針を決めるためのKPI分析の基として利用することにもなるため、事前に何をどこまで取るべきかすり合わせておけると良いです。
広告効果測定
アプリの運用方針を決めるためには、ゲーム内の行動ログを分析して分かるKPIの他に、どの広告から流入した時に継続率がいいのか、といった広告効果に対する分析から分かるKPIも有用です。
より細かな広告効果測定のためには、ユーザーがある成果地点に到達した際に記録を行うようにする、といった追加実装が必要なケースもあります。
事前にデータマイニング/マーケティングチームなどとすり合わせておけると良いです。
ちなみに現在マジカミでは、Adjustというサービスを利用しています。
プッシュ通知
「18:00から新イベントが始まるよ！」といったプッシュ通知を行うことで、アプリの継続率を高める、離脱率を減らすことに繋がる場合があります。
「忘れずにデイリーミッションをクリアしよう！」といったまだクリアし終わっいないユーザーだけにプッシュ通知を行いたいという場合もあります。
この場合、広告効果測定の項目と同様にユーザーの進捗を別途記録する追加実装が必要なケースもあるためこちらも事前にすり合わせておけると良いです。
ちなみに現在マジカミでは、Reproというサービスを利用しています。
チート対策
アプリの運用を健全に行うために不正行為やボットに対する対策も検討しておけると良いです。
例えば、https://tech.griphone.co.jp/2020/06/30/php-safetynet-api/ で紹介したSafetyNetの導入やRMTなどを目的としたボットへの対策などが考慮されていると良いです。
おわりに
この記事では主にiOS / Androidの2つのプラットフォームがあることで、ゲーム内ロジックとは別に早めに考慮しておけると良いことについてまとめました。
今回の内容の他にもまだまだ考慮すべき点はあるかと思いますが、開発時の備忘録の一つとして使用していただけると幸いです。
それでは次回の記事もお楽しみに！
