backend(mBaaS)。UnitymBaaSのスクリプト機能を使うことでアプリ内のロジックをクラウドで処理できるようになります。様々な使い方が考えられますが、ゲームではガチャ機能やチート防止に使われたりします。仁志氏にお話を伺いました。backendとUnityとの相性はいかがでしょうか。mBaaSを導入した際に分かりにくかったところ、詰まったところはありましたか?機能要望などはありますか?NCMBの「データストア」はどのようにご利用いただいていますか?データストアの構造はリリース当初と比べて変わっていますか?スクリプトはどこで利用していますか?他に管理画面で要望はありますか?パフォーマンスについてはいかがでしょうか。GAMEというゲームになります。タップ操作だけのアプリで、敵を倒してゴールドを得て、そしてキャラクターを倒してステージを進めるというRPGゲームになります。特徴として時間を戻すという機能があります。これによって最初のステージへステータスも戻りますが、ステータスをアップするアイテムを手に入れられます。それを何度も繰り返すというタイムリープ型の楽しみ方ができます。newgame.nestopi.co.jpこのタイプのゲームとしてはあまりないのですが、クリアが明確に存在します。言え、クリア後もステータスはあがっていく仕組みなので長く遊んでもらえます。ランキングシステムを取り入れているのでユーザ同士でも熱い戦いが繰り広げられるのが特徴です。backendを使っています。一部(CDNやWebView用の表示)にGMOアプリクラウドを利用しています。WebViewの表示はよく使われているGREE社が開発しているプラグインを使っています。iOSの一部で表示がうまくいかない問題があるので多少カスタマイズしています。後はUnity標準のプラグインで課金と動画広告のプラグインを使っています。Analyticsです。backendをお選びいただいた理由はなんでしょうか?元々候補として自社でやるか、PHPのフレームワーク(CakePHPなど)を使うかで模索していました。そんな時、2〜3人の知人がNCMBを使っており、お勧めされました。後、サーバ側の開発を担当している青木が何度かセミナーにも参加させてもらっていたこともあります。人数は短期間、コストがかけられないというハードルがあったので自作ではなく、NCMBを使おうという決断にいたりました。開発者とのコミュニケーションや国内開発の安心感もあり、会社からもOKが出ました。backendとUnityとの相性はいかがでしょうか。これは私(栗田氏)からの要望でした。Unityに入れようとして大変だったり、そもそも動かないというのは問題外です。そのまま動き、サンプルもちゃんと動くのが大事です。少人数、短期間での開発においては一つのトラブルが致命的な問題になりかねません。その点、NCMBはサンプルも簡単に動きました。忘れもしないですが、はじめて試したのが正月の時期で、お昼過ぎに試し始めたら2時間くらい、3時にはログインができあがっていました。言えばスクリプトのサンプルが少ないなと感じます。JavaScriptには不慣れなので、スクリプトならではの書き方や、こういう風に書いた方が良いと言った情報があると嬉しいです。mBaaSを導入した際に分かりにくかったところ、詰まったところはありましたか?今はGitHubにガチャサンプルがありますが、当時はありませんでした。あればもっと良かったなと思います。後はクラス単位でのインポート、エクスポートができないのが辛いですね。本番運用がはじまってから、実際に動いているデータを使ってテスト環境で同じような動きになるか試したいと思うことがあります。ステージング環境で作ったガチャのデータをそのまま本番環境に移したい、とか。今、弊社ではステージングアプリケーションとデベロップメント、本番の3つがあります。デベロップメント環境で作ったものがステージングに、さらに本番にとデータを移しています。データを管理するガチャマスターですね。逆に本番環境のデータを移すニーズとしては、データにゴミが入ってしまってユーザの環境だけでエラーが出る場合の再現に使います。その状態で起動して、何か問題があるのか見てみたいと言った場合です。今、半年近く運営していますがエクスポートだけで数時間かかるので気軽に実行できません。サーバのメンテナンス中やデータの不具合が発生していた時にもエクスポート、インポートできると楽ですね。バックアップにもなりますし。後はポインターの概念が感覚的には分かりづらいかなと。管理画面からポインターの参照を変更する場合などが若干大変ですね。スクリプトについて言えばJavaScript以外の言語でも書けると嬉しいです。個人的にはRuby、PHP、C#、Perlなどで書けると嬉しいです。後は管理画面でAPIのエラーが何で発生したのかが分かりづらいです。スクリプトサイズ限界(8K)エラーなど。NCMB特有なデータとして配列がありますが、あの扱いもなかなか慣れませんでした。ドキュメントに記載されていなかったので問い合わせしています。JSONオブジェクトをコンバートして扱うというプログラムを見たことがなかったので、データを何にキャストして使ったら良いのか分からなかったです。試して、動いたからOKみたいになってしまっています。機能要望などはありますか?障害発生時、我々がすぐに確認できるようなステータスページ的な仕組みが欲しいです。後は時間のかかった処理が分かる、スロークエリーの可視化のような仕組みが欲しいです。現状、処理時間の問題切り分けが難しいので、アプリ側で測定しています。これがあらかじめ分かると嬉しいです。障害の時間が短縮できたり、ある機能だけ切ったりできます。現在、我々はユーザの操作を再現するボットを作っています。ログインや特定の機能に時間かかったりするとSlackに通知するような仕組みを用意しています。スクリプトについて言うと、多数のスクリプトを管理していると、今どのスクリプトをアップロードしたのかが分からなくなります。バージョン管理できると嬉しいです。先ほども言いましたが、8KB問題は大きな問題になっています。そのため、変数名削ったり、圧縮ツールを使ってバイト数を減らしたりしています。なると手元のファイルとアップロードされているファイルで単純な比較もできなくなってしまいます。NCMBの「データストア」はどのようにご利用いただいていますか?データストアについてはプレーヤーの状態の管理を行っています。管理用データとして、スクリプトを実行した際のログデータ(実行時間、エラー内容)の保存にも使っています。お客さんからの問い合わせの内容。クライアント、サーバ両方で参照する。データストアのおおむねの構造としては、まず会員管理でアカウントを作ってもらいますが、その際に「プレイヤーID」というフィールドを必ず持ってもらいます。これは、その後に生成するデータストア上の情報を参照するときに使うキーとなる物です。ユーザーが一番最初に起動した時にPlayerクラスのデータがなければ新規作成します。ここでユニークなIDとなるObjectIDができますので、これを会員管理のIDとパスワードに該当した扱いにします。アカウントを消さない限りはユーザ情報が参照できます。プレイヤーデータクラスは、サインインした時にプレイヤーIDとアカウント情報に書き戻します。これで新しくガチャが始まった際や、プレゼントボックスから何らかのプレゼントが来た際は、全てプレイヤーIDと紐付けて保存しています。プレイヤーIDですべてのデータを引っ張ってくるようにしているので、たとえば端末間のデータ引き継ぎが発生して会員管理側のレコードが変わっても、すぐに差し替えることができます。プレイヤーIDが分かってしまうとチートの危険性があるので、外には出していません。ユーザーを識別する「お問い合わせするためのユニークキー」をプレイヤークラスに書き戻していまして、このキーを使うことで運営側にはどのデータか分かるようになっています。一つの利点はBANの対応です。一時的にプレイヤーIDを不正なものに書き換えると、全てのデータが参照できなくなりますから、ログイン処理ができてもその先に進まない「BAN」の状態を作り出すことができます。このあたりは、会員情報にアクセスレベルをつけて、一般ユーザーとGMを分けて管理してます。データストアの構造はリリース当初と比べて変わっていますか?フィールドの追加は日常的です。データストアは簡単に構造が変えられるのが嬉しいです。ちなみに本番環境ではフィールド追加を制限できると嬉しいです。タイプミスして変な名前のフィールドができることもあるので...。後、フィールドに入れるデフォルト値が決められると嬉しいです。今はundefinedになってしまうのでデータの内容がちぐはぐになります。数値しか入らないところであれば0を規定値に設定したいです。前回のアップデートで女神コインという機能を追加して、データストアも拡張されています。ユーザによってそのフィールドがあったりなかったりします。そのためクライアント側で判別しないといけなかったり、場合によってはカラムがないために落ちる可能性があります。スクリプトはどこで利用していますか?アプリのかなりの箇所で使っています。主にはチートされたくないところであったり、パフォーマンスを出したいところですね。クライアントアプリ側で処理せず、NCMB側で処理させることでチートを防止しています。基本的にはスクリプトを利用する流れは一緒ですが、「ガチャ」を例に説明します。クライアントアプリからスクリプト実行の命令をだします。最後にクライアントアプリ側にJSONで結果を返却という流れです。データストア上に、どんなカードがどんな確率で出るかを記述したガチャのマスターがあり、それを参照して動いています。「ガチャスケジュール」という別途のテーブルを使って、アプリのバージョンによって出して良いキャラクターを区別しています。自体のパラメーターと、それをいつ出して良いかの条件を別クラスで分けて管理することで、過去に行ったがチャを再利用したりすることも容易にできるようにしています。この「ガチャ」と同じ仕組みを作って期間限定プレゼントの処理もしています。同様の「ログインボーナスクラス」と「ログインボーナススケジュールクラス」を分けており、「どんなログインボーナスか」「どんな機関にもらえるか」という情報を分けています。新しくログインボーナスを組むときは、スケジュールだけを変更すればOKです。したデータを入れるところは専用に開発した管理ツールを使っていますが、中身の確認はNCMBの標準の管理画面上で行っています。スクリプト機能が重要なのは「レシート検証」の所だと思います。アプリのストアでダイヤを買ったあと、実際のリソースを増減させる部分はスクリプトで処理させます。開発当初からの方針として、課金周りは必ずスクリプト機能を使ってNCMB側でやろうと決めていました。チートをされてしまうと、ちゃんとお金を払っている人に迷惑がかかってしまいますので。言いつつも、実は運営していく中で最初はスクリプト処理をしていたものをローカルに戻したことがあります。この対応をする中では、配信してもう動いているゲームのスクリプト機能を停止させて、後からGMツールで配りましょう、と方針を変えるまで、1時間かからずにできたのは非常に大きかったと思います。スクリプト機能で実装しておくことで、何かあったときの対策を後からお客さんが知らずに差し替えることができます。通常ではサーバを更新しないといけないような決断ですが、NCMBの場合は修正したスクリプトをアップロードし直すだけで即時反映されるので、助かりました。アプリケーションサーバで機能単位で止められる機能を作るのは大変ですが、NCMBの場合は単にスクリプトを止めてしまえばその機能がオフにできます。この仕組みは開発者にとってとてもありがたいです。ふつうは「緊急メンテナンス」になるところ、打たずに済みました。仁志氏その後、クライアントの中に自分にプレゼントできる機能があるのはチート行為の温床になりやすいと考えまして。それを防止するために、クライアント側でプレゼントを発行したときにサーバ側でフラグ判断を行っています。二個目以降同じアイテムが受け取れないよう、サーバー側で管理をしています。他に管理画面で要望はありますか?検索機能が弱いので強化して欲しいです。データストアには100万レコードを超えているクラスがあります。それは表示しようと思ってもなかなか出なかったり、検索結果の表示が崩れることもあります。後、別なクラスとジョインして表示したいです。パフォーマンスについてはいかがでしょうか。データストアについては現状問題なく使えています。検索頻度の高いクラスについてはレコードが多いとインデックスを貼らないとゲームにならない速度になってしまいます。インデックス貼るのが必須になっています。スクリプトについては基本的には速く動いています。時間帯によって実行速度にばらつきがあります。普段、200ms以内に終わっているのが突然数十秒かかることがあります。時間帯としては18〜19時、21〜23時、朝の通勤時間などが重たい印象です。実際、このスクリプトがどれくらいの時間で終わったのかといった情報がとれるとボトルネックが判別しやすくなります。スクリプトは処理時間による課金なので、30秒かかってしまうと普段200msをいかに短くしようかという努力がムダになってしまいます。どれくらいの規模のゲームアプリ開発にmBaaSは適しているでしょうか?今回の強くてニューゲームについて言えばエンジニア4名(サーバサイドは1名)、企画2名、プロデューサー1名、ゲーム設計ディレクター1名、課金モデル(ソーシャルゲームのマネタイズ部分)1名という体制です。デザイナーは今回外部協力会社で、QAチームは後から入ってもらっています。した10名くらいの規模でもNCMBを使えばソーシャルゲームを作れます。最初、エンジニア4名は厳しいと思っていました。サーバサイドのエンジニアは2名までと考えていたのですが、実際は1名で回っています。サーバ側の開発期間は約2ヶ月です。NCMBを使い倒していると感じています。サーバ側について言えば、まだメニューを隠しているものもあり、機能的には先行的に入れているくらいの余裕がありました。NCMBのお陰で開発を速く進められました。データストアだけでもクライアントで何でもできる印象です。速く作るだけならデータストアでできます。スクリプトを使えば後で動的にロジックを変更できます。その意味では個人制作から企業まで、どの規模でもNCMBがサポートできるのかなと。自分が学生の時にあったら嬉しかったと思いますね。自分の思い描く部分だけ作れるようになるので。通信どうしたらいいのかと考えていた時にNCMBを使えばとても楽だったと思います。私は通信部分を殆ど分からないのですが、サーバサイド担当の青木と話すことができるんですね。データストアの基本と設計の基礎がわかっていれば一緒に話ができます。NCMBに今後求めたいことはありますか?幾つかあるんですが、まず管理画面のクラスデータの表示について言えば、フィールドの表示順番を変えたいです。右側によく見るフィールドがあるのが辛いです。後はパフォーマンスで、データ量が多いクラスが表示までに時間がかかったり、絞り込みで落ちることがあります。100万レコードくらいに閾値を感じます。技術的なところではトランザクションが欲しいです。強くてニューゲームについて言えば、時間を巻き戻す処理があります。リセットしてレベルを戻した時に「ここまで進んだのでこのアイテムを配置して」といった処理があります。8K問題もあって実行を分割せざるを得ない状態で、「ここまで成功した時に全体を成功にしたい」というニーズがあります。現在はどこまで処理したかをフラグで判別しています。マスターツール絡みで言うと、プレイヤーIDを総なめしている処理があります。この時、大量のアクセスが発生するのですが、サーバ側で通信を切られてしまうことがあります。アタックや無限ループした時などの対策で行われているのだと思いますが、管理側のツールではもっと一度のアクセス量を増やせると嬉しいです。後は定期的に自動実行する、Cron的なものが欲しいです。今後のアップデート予告はありますか?現在は毎月アプリ内容のアップデートをしていますが、今後モード追加も予定しています。タップだけではなく、隙間時間を使う遊びも考えていて、年末までにはリリースできる予定です。遊んでみて欲しいです!まとめゲームアプリのバックエンド開発においては、様々なサービスを連携して開発することが多くあります。backendもいくつかのサービスと併用されることもありますが、本タイトルは機能のほとんどをmBaaS内で完結しています。エンジニアの負担を減らし、コンテンツ開発側に集中してもらえる環境を提供することで、短期間でクオリティの高いアプリ開発の実現に近づきます。backendを触ってみてもらえればと思います。ヘッドハイ代表取締役、ゲーム作家。1995』(Steam/3DS)。Relation事業を展開。篤司NCMBエヴァンジェリスト。プログラマ、エンジニアとしていくつかの企業で働き、28歳のときに独立。2004年、まだ情報が少なかったオープンソースソフトの技術ブログ「MOONGIFT」を開設し、毎日情報を発信している。2013年に法人化、ビジネスとエンジニアを結ぶDXエージェンシー「DevRel」活動をスタート。backendが採用されましたエヴァンジェリストの一條です。Service)とは、スマートフォンアプリでよく利用される汎用的な機能をSDKとクラウドから提供するサービスです。backendのちょっと便利な使いかた・非公式SDKやアプリ開発の関連情報などをお届けするブログです。※記事内には、サポート対象外の内容も含みます。本ブログではコメント機能を公開しておりません。アプリ開発を行う上での課題解決には、ユーザーコミュニティやもくもく会などもご活用ください。LIMITEDスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。