Platform(GCP)を使って開発したお話を紹介します。カテゴリが追加されています。このカテゴリに入っている次の5つのブラウザゲームを、私の所属しているチームが開発しました。ハリピットバブルハリピットと呼ばれるキャラクターをモチーフにしたマッチスリーパズル。大好物のスイーツを求め、スイーツが実る木があるという不思議な森へお出かけ。バブルに覆われている沢山のスイーツが地面に落ちる前に、たくさん収穫しよう。そろえて!ミルチョミルチョと呼ばれるキャラクターをコレクションできるマッチスリーパズル。その他、次のようなタイトルがあります。プランナー兼デザイナー1名、エンジニア2名(後に3名)です。エンジニアは主な担当をフロント/サーバサイドで分けましたが、どちらも分け隔てなく担当するマインドで動いています。導入する技術も多かったため、経験のあるエンジニアからアドバイスを頂いたり、インフラエンジニア、プラットフォームチーム、QAチームには都度相談させてもらいました。以下ではプロジェクト立ち上げにあたって、少人数、短期間で効率よく開発できるように選択した環境などをご紹介したいと思います。試行錯誤の様子が多々含まれていますがご参考になれば幸いです。Creatorを利用しています。新しく開発したGUIのゲーム開発ツールで、昨年2016年3月にリリースされており、現在も活発に開発されています。Creatorで開発しています。動作するGUIでゲーム画面を作成できるため、生産性が高い開発環境の候補としては、Unityが真っ先に候補に上がりましたが、スマホブラウザ向けにビルドできないため候補から外れました。CreatorのUIや使い勝手はUnityに似ていいるため、Unityに慣れている開発者であれば、導入のハードルは低いと思います。5月にリリースされたバージョン1.5で次のような大きな機能追加がありました。Creatorを使い始めた時点では物理エンジンと統合されておらず、Cocosのオブジェクトと物理エンジンのオブジェクトとの橋渡しをプログラムする必要がありました。カメラもないため、視点を固定しておいてゲームステージの方を動かすなど、いろいろな難しさがあったのですが、1.5からはそのような苦労も不要になりそうです。公式サポートされており、特別な設定は不要で、すぐに使い始めることが出来ます。Creatorで作ったゲームのデバッグができます。Trelloにまとまっています。Creatorで実装したソースはWebモバイルをターゲットとしてビルドしています。ビルドするとminfiyされたJavaScriptファイルと多数のJSONファイルが生成されます。当初はこれらのファイルもGitリポジトリに入れていたのですが、複数人が同時に作業するとコンフリクトが多発し開発スピードを落とす原因になっていました。余りにもコンフリクト対応に時間がかかりコードレビューの阻害にもなっていたため、Jenkinsに詳しいエンジニアの手を借りつつ、最終的には次のような構成にしてビルドファイルをGitリポジトリから追放しています。Creatorがインストールされています。次のようなフローでデプロイします。Creatorはコマンドラインからビルドできる仕組みが備っているため、このような構成が可能でした。5分〜10分でビルドが終わっています。1.3では突発的に15分以上かかることもありましたが、1.4にアップデートしてからはビルド時間が安定して短縮されました。Creatorのビルド結果ファイルなどの静的ファイルはAppEngineで配布しています。AppEngineで配布されている静的ファイルはGoogleのCDNであるエッジキャッシュでキャッシュしてくれますので、AppEngineで配布さえすれば自動的にGoogleのエッジキャッシュに乗ることになります。AppEngineのデプロイはコマンド一発できることや、バージョン管理とその切り戻しが簡単にできるという特徴がありましたので、少ない手間で静的ファイルを公開、管理することに向いていると考えました。Platform、APIサーバのプログラミング言語はGo、Webフレームワークとしてechoを使っています。Datastoreを利用しました。現在5つのゲームのAPIサーバが稼働していますが、すべて同じGKEクラスタに入れていることもあり、料金は安価に抑えることができています。Runtimeに依存してしまうため今回は利用を見送りました。み込みの並行処理・ライブラリやIDEの充実など、経験のあるエンジニアからすばらしい特徴を聞いていましたので、素早く立ち上げるプロジェクトに向いていると判断して採用しました。実際に使ってみるとカジュアルゲームの仕様がシンプルだったこともあり、Go言語のシンプルさとよく合っているように感じました。複数のゲームから利用する共通ライブラリを作るにあたって型の継承が出来ないこと、Genericsが無いことがネックになるケースがありました。このあたりはGo言語でのやり方に慣れればまた違うのかもしれません。Strageへバックアップしています。一度Export設定してしまえば、自動的にそれぞれのソースへ日別にログを出力してくれるため、ログをアーカイブしたりローテートする必要がありません。Strageは使用料もそれほどかからないため、長期間保存しておくこともできます。ログの調査/解析にBigQueryのクエリが使えるため、特定の条件でフィルタリングすることがすぐにできます。将来的には、Goプログラムから出力するログのフォーマットを、BigQueryで扱いやすいフォーマットにすればさらにログの解析が簡単になりそうです。CIサーバCIサーバとしてJenkins2を使っています。CreatorをWindowsサーバで動作させる必要があるのですが、Jenkinsスレーブとして自然にCI化できています。ビルドスクリプトは、ほぼGroovyスクリプトで記載しGit管理しています。昨年(2016年)8月にGAリリースされてからはGKEなどAppEngine以外からも利用できるようになりました。次のような特徴が謳われています。シャーディングとレプリケーションを自動的に処理し、アプリケーションの負荷にあわせて自動的にスケールする、可用性と耐久性に優れたデータベースを提供します。ライクなクエリ、インデックスなどの多くの機能を備えています。)実際に使ってみると上記の特徴のおかげで、一般的なリレーショナルDBサーバの場合よりも管理コスト・開発コストが少なくなりました。具体的には次のようなコストが削減されています。冗長化の仕組みが不要NoSQLのためスキーマ変更の負担が少ないレプリカサーバの管理などが不要になるためメンテナンスコストが圧倒的に減りました。DatastoreはNoSQLですので、スキーマを変更する場合はGo言語のstructを変更するのみでよく、リレーショナル・データベースにあるようなマイグレーション作業は不要です。Datastoreのトランザクションでつまずいた話ただDatastoreのトランザクションには次のような特徴があり注意が必要でした。Datastoreドキュメントから引用しています。失敗することになります。複数のアップデート処理が同時に実行された場合は、片方は実行を待つ(暗黙的に排他ロックがかかる)と想定してたのですが、実際には同時にアップデート処理が実行され、先にcommitした方が採用されます。し、正常に適用された場合でも、エラーが返されることがあります。トランザクションのべき等性を確保する必要があります。スコアの更新など、トランザクションエラーが許容されづらい箇所には、トランザクションのリトライ処理を入れました。リトライされても同じ結果になるように、プログラム側が気をつける必要があります。対する単一の一貫したスナップショットを参照することが保証されています。オペレーションは、トランザクション内の以前の書き込み結果を参照しません。トランザクション内でエンティティを追加しても、同じトランザクション内からはそのエンティティが見えません。開発当初は上記の特性をよく理解せずに開発を進めてしまい、負荷テストの段階で並列・大量に更新処理かけた際にやっとおかしいことに気づき慌てて修正しました・・・おわりにスマホ向けブラウザゲームを開発したお話を紹介させていただきました。Creator、GCPなど便利なツールやサービスを使うことで、開発や運用のコストを下げることが出来たと感じています。改善の余地はありそうですが、こちらの記事が何かのお役に立てば幸いです。CocosCreatorGCPnshmura大阪在住です。サーバサイドエンジニア・Androidエンジニアとしてペコリなど複数のアプリを担当しました。現在はカジュアルゲームを開発しています。