本記事はFirebase Advent Calendar 2018の10日目の記事です。
まえふり
以前からFirebaseとUnityでどんなゲーム開発ができるのか触りながら探っています。
SDKがアプリに入った時のSDK自体の品質問題もあるのですが、そもそもサーバサイドの開発とサーバ管理のコストを減らせるメリットを持っているFirebaseに全てバックエンドを任せることは、とても危険です。
いくつかの発表資料（上記資料など）でも、一部の機能のバックエンドをFirebaseで対応されている話しはよく聞くため、どこまでできるのかをベースに採用判断しなければならない。
マイグレーションはできないと思って良い（所感）
個人的にFirebaseは、マイグレーションはできないと考えています。
ゲームアプリのバックエンドは、Webアプリと同じ構成をベースに作って良いのですが、Webアプリとゲームアプリの一番の違いはアクセス頻度であり、全アクセスに耐えられる環境をすぐに用意できるかできないかで開発・運用がゴロッと変わります。
Firebaseのデータベースは、JsonまたはNoSQLとなっており、NoSQLだったらDynamoDBに移行できるんじゃないかと考えますが、Cloud Firestoreのドキュメントに以下の内容が書かれています。
データをエクスポートする
エクスポートを実行すると、データベース内のドキュメントが Cloud Storage バケットの一連のファイルにコピーされます。エクスポートは、エクスポート開始時に取得された正確なデータベース スナップショットではありません。エクスポートには、オペレーションの実行中に追加された変更が含まれる場合があります。
現時点でDynamoDBへの移行はできず（もしかしたら超頑張ったらできるかもしれないけども）、FirebaseはGCPと連携できるため、おそらくCLOUD DATASTOREにマイグレーションは可能かもしれません。
ですが、ゲーム系でGCPの事例は少ないためFirebaseもGCPもゲームアプリで使うには、要件次第では両方茨の道だと思いました笑
Firebaseでゲームアプリをどこまで開発できるのか
Firebaseの使用例やCloud Functions で可能な処理を見ると、マイクロサービスに向いているのかなぁという印象でした。
なので、ゲームアプリでFirebaseを使うのならランキングの集計やRemote Configで操作できるシステムに関しては、Firebaseに任せてもいいなと考えていました。
また、Firebaseを用いてギリギリどこまでなら作れるか考えてみました。
Firebaseと大規模サービス
先にFirebaseでできない開発パターンを洗い出すと意外とFirebaseで作れるゲームアプリは考えられます。
- 例えば、数百万ユーザー以上で数千万PV以上などの大規模アプリを作ってしまうとFirebaseの従量課金制で酷い事になるため使えない。
- ガチャやイベント、PvPなどのゲームアプリのキモになるようなシステムのバックエンドは柔軟な運用が必要になるため使えない。
- 課金システムのバックエンドをFirebaseにしてしまうと、セキュリティーを意識したルールの対応ができずにハッキングされやすい状況になっていたり、簡単にデータ削除できてしまうことがあるため、安全に任せることができない判断＆諸々課題をカバーする対応にコストがかかってしまう問題があるため使えない。
- ...etc
ゲームに関することがベースであるものの、Webアプリでも1つ目は当てはまるかなと思います。Webアプリでこの内容だと、何かのプラットフォームサービスに等しい規模だと感じますね。
ゲームアプリに関わらずFirebaseの強みを把握した上で、どこのシステムのバックエンドをFirebaseに任せることができるのか、という観点を持たなくてはなりません。
Firebaseの強みを活かしたゲームアプリ開発
大きく2つに分けて一緒に考えていきましょー！
バックエンド全てFirebase
だいたい相談されるのがこれですね。全部Firebaseでサーバサイドの開発とインフラのコストのコストカットを考えていると。もし、PvPやマルチ対戦を考えているゲームでこの話が来た時はすごい必死なんだろうなぁって苦笑
ゲームアプリのバックエンドで作られるシステムを洗い出していきましょう。
- ユーザーに関連する情報（Cloud Firestore & Firebase Authentication）
- 固有情報
- 履歴情報
- 所持している情報
- レシート情報
- ゲームに関連する情報（Cloud Firestore & Cloud Storage）
- クエスト
- イベント
- キャラクター
- アイテム
- アプリ内課金に関する情報（Cloud Firestore & Cloud Storage）
- 課金アイテム
- ゲームの共通設定（Remote Config）
- ゲーム内メッセージ
- メンテナンスモード
- プッシュ通知（Cloud Messaging）
- WebAPIやサーバサイドの処理（Cloud Functions）
- 複数のデータをサーバ側で取得して整形してアプリに(GET/POST)通信する
- バックエンド完結する処理（ユーザー履歴やクエスト達成後の後処理など）
- ...etc
細かく追っていくと他にもいっぱいありますが、一旦こんな感じでFirebaseに適応させるならこのサービスかなぁと思って付けてみました。
ここでバックエンドを全てFirebaseにできる条件を以下の3つほど考えました。
- データが早いスピードで肥大化しない
- 頻繁にデータが作成/変更/削除などが行われない
- アプリ内課金をしない
1については、ユーザーが増えていくことは止められないし止めたくないのでしょうがないとして、ゲーム関連のデータが1ヶ月で数万件〜数千万件以上右肩上がりに増えていくゲームアプリは、運用が大変になることと金銭面も一緒に肥大すると本末転倒なので避けたいです。2も似たような理由ですね。
3は、ルールの設定のミスやデータを謝って全削除してしまった時の対応・対策が柔軟にできないからです。
従来だとバックアップの他に何らかの対応で復帰できる術があったりするものの、Firebaseはブラックボックスで柔軟に対応できないため、日々のバックアップを怠らず、2重3重と対策を考えないと問題が起きた時に一番怖い箇所なので、大変なら最初っから避けたいところとして上げました。
なので、買い切りアプリまたはアプリ内課金の無い完全無料アプリでサクッと楽しめるカジュアルゲームだったら、バックエンド全てFirebaseでもいいかなと思いましたー！
一部のシステムのバックエンドがFirebase
お金がかからないFirebaseのサービスをうまく活用すると良いと思います。例えば、
などはSDKもありますし、お金もかからないですし、管理さえしっかり押さえておけば要件に合うゲームアプリ内のシステムに使って良いと考えています。これが、Firebaseの強みを活かす使い方じゃないかなぁと思いますー！
プライベートやカジュアルゲームについて
逆にFirebaseを活用して、多くのゲームアプリを開発すると良いと思います。
プライベートなら色々考えなくて済みますし、逆に上記のようなことを経験できる訳なので、バンバン使っていきましょー！！
カジュアルゲームは、Webアプリのマイクロサービスに近しい規模だとならFirebaseを使っても大きな問題にはならないんじゃないかなぁと思うけども、やっぱし要件次第だなぁ笑
ただし、ルールの設定や個人情報の取り扱いを意識したサービス開発は、Webアプリでもゲームアプリでもどんなシステム開発でも共通する話しだと思うのでお忘れなく！
さいごに
これを把握した上でさらにFirebaseを使い倒すドMがいらっしゃると思うので(僕もその1人ですかね)w、そのために次の技術書典でFirebaseとUnityについてだけの丸々1冊を作ろうと企んでいます。
実はまだ1WeekGameJamは参加していないので、Firebaseを使ったカジュアルゲームを1つ作りたいなぁと考えていたりするので、これからまたTwitterの方でいろんな情報をアップしていきますー！＼＼\٩( 'ω' )و //／／
AdventCalendarの捕捉
当初やりたかったことが完成できず、記事にするのも辛かったため、GDG DevFest 2018で発表した資料を見直し上記の記事を急遽予定変更して作りました。
できなかったものは、来年のFJUGイベントで発表できるものに仕上げてリベンジしようと思います🙇