【新サービス公開】GS2-Limit 回数制限管理サービス

みなさん、こんにちは。GS2 CEOの丹羽です。

本日は新サービスの公開を告知します。
GS-Limit はゲーム内のアクション回数に回数制限をつける時に実行回数をサーバサイドで管理する仕組みです。

これによって、アカウントあたり1回だけ購入出来る商品。のような機能を実現出来ます。
また、回数制限にはリセット周期を定義することも出来ますので、
例えば、毎日3回だけ挑戦出来るデイリークエストの挑戦条件判定や、毎週1回だけ無料でガチャが引ける場合の条件判定といったものを実現することも可能です。

使い方は簡単で、Unity SDK を使用する場合は

yield return Gs2.Limit.Up(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
        Debug.Log("Counter Value: " + r.Result.Count);
    },
    Session,                // ゲームセッション
    LimitName,           // 回数制限名
    CounterName);    // カウンター名

これで回数制限をインクリメント出来ます。結果にはカウントアップ後の実行回数も返ります。
制限回数をオーバーした場合は r.Error に ConflictException が返ります。

カウントアップせずに現在のカウント値を取得するには

yield return Gs2.Limit.Get(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
        Debug.Log("Counter Value: " + r.Result.Count);
    },
    Session,                // ゲームセッション
    LimitName,           // 回数制限名
    CounterName);    // カウンター名

これで取得出来ますので、カウントアップ前に条件の確認をすることも出来ます。

GS2-Limit の利用料金は完全従量制で

カウンターの取得	1円/1,000回
カウンターの操作	3円/1,000回
カウンターマスタのエクスポート	1円/回

で利用出来ます。

GS2-Limit は本日よりご利用いただけます。

それでは、また。

【新サービス公開】イベントスケジュール管理機能

みなさんこんにちは。GS2 CEOの丹羽です。

gs2.hatenablog.com

こちらで告知していたイベントスケジュール管理機能を公開しましたのでお知らせします。
機能の説明について同じ話をしても意味が無いので、今回は実装例を紹介します。

イベントマスターデータの管理については以下のページを参照してください。

イベントマスタフォーマット - GS2 Documents

現在有効なイベントの一覧を取得する場合のサンプル

yield return Gs2.Schedule.List(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
        foreach (var eve in r.Result.Events)
        {
            Debug.Log("name: " + eve.Name);        // イベント名
            Debug.Log("meta: " + eve.Meta);        // メタデータ
            Debug.Log("begin: " + eve.Begin);    // 開始日時
            Debug.Log("end: " + eve.End);        // 終了日時
        }
    },
    Session,                            // ゲームセッション
    ScheduleName,                        // スケジュール名
    new []{EventName1, EventName2});    // イベント名のリスト（省略することで全件取得）

現在有効なイベントを取得する場合のサンプル

yield return Gs2.Schedule.Get(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
        Debug.Log("name: " + r.Result.Name); // イベント名
        Debug.Log("meta: " + r.Result.Meta); // メタデータ
        Debug.Log("begin: " + r.Result.Begin); // 開始日時
        Debug.Log("end: " + r.Result.End); // 終了日時
    },
    Session, // ゲームセッション
    ScheduleName, // スケジュール名
    EventName1);        // イベント名

アカウント登録時に相対時間のイベントを開始する

schedule_client = client('schedule')  –- GS2-Schedule のクライアントを初期化
result = schedule_client.pull_trigger({
    scheduleName="schedule-0001", -- スケジュール名 
    triggerName="trigger-0001", -- トリガー名
    userId="user-0001", -- ユーザID
    action="pull_again" -- トリガーの引き方
})
result = {permit=not result.isError} -- トリガーを引くのに失敗した場合失敗とする

このスクリプトを GS2-Script に登録し GS2-Account のアカウント登録イベントでフックすることで、
アカウント登録時にイベントの開始トリガーを引くことが出来ます。

利用料金は完全従量制で

イベントの取得	1円/1,000件
トリガーの操作	3円/1,000回
イベントマスタのエクスポート	1円/回

＋ API呼び出し回数 3円/1,000回

と非常に扱いやすい内容になっています。

それでは、また。

【新サービス発表】イベントスケジュール管理サービス

みなさん、こんにちは。GS2の丹羽です。

本日は近日公開予定の新サービス GS2-Schedule を発表いたします。
GS2-Schedule はゲーム内のイベントの管理を行うマイクロサービスです。

イベントは2種類定義することが可能です。
1つ目は絶対時間、2つ目は相対時間です。

絶対時間は開始日時/終了日時を明示してイベントの開催期間を定義出来ます。
相対時間はユーザ毎にトリガーを引いてから一定期間をイベントの開催期間と定義するものです。

前者は一般的なクリスマスやお正月にあわせたイベント開催に、
後者はチュートリアル突破後24時間限定のイベントなどの定義に使用出来ます。

マスターデータはGS2のマネージメントコンソールで定義することも出来ますが、
マスターデータは最終的にJSON形式のファイルにエクスポートして、実サービスに適用するように設計されています。
これは、開発環境で作成したマスターデータを製品環境に適用するコストを最小に抑えるためと、
イベントの定義をGS2のマネージメントコンソールだけでなく、独自のツールを使ってフォーマットに沿ったJSONを出力することでも定義出来るようにするためです。

GS2-Schedule は今後GS2のマイクロサービスと連携することで本領を発揮します。
たとえば、今後GS2の開発マイルストーンには、ガチャ/アイテムショップ/お知らせ といったサービスの開発が計画されています。
これらのサービスと GS2-Scedule を連携されることで、イベント期間のみガチャを解放したり、チュートリアル突破後24時間限定でショップで買える商品を定義することが出来るようになる計画です。

料金や機能の詳細はサービス提供開始にあわせて後日発表しますので、しばらくお待ちください。

それでは、また。

【事例紹介】株式会社スタジオリール SOCCER DUEL ONLINE

SOCCER DUEL ONLINE について

サッカーとチェスを組み合わせたオンライン対戦ゲーム。
相手との読み合いが勝利へのカギとなる。
思考型のゲームだが、試合はリアルタイムで進むため、意外と忙しい。
海外をメイン市場に据えた商品。

基本無料。
消費型アイテム課金制。
アプリ内広告あり。

GS2 が選ばれた理由

資金決済法に対応する課金通貨購入、管理してくれるサービスを探していたところ、GS2を見つけました。
SOCCER DUEL ONLINE は Unity で開発を進めており、Unity 向けの SDK を提供している GS2 はすぐに導入できました。
また、初期費用を低く抑えたいと考えており、初期費用が一切必要無い GS2 はその点でも魅力的でした。
ゲームサーバの多くは様々な機能がオールインワンになっているものが多いのですが、
GS2 は機能単位で契約して使用できるため、余計な機能に費用が発生することがないのが魅力的でした。

GS2 に対する開発面での感想

サンプルを見ながらスムーズに組み込むことができました。
何カ所か実装中につまずいたこともあったのですが、丁寧にサポートしていただけました。
今後導入する方のためにコミュニティがあるといいと思います。つまづいたところなどを共有したいです。

GS2 に対する運用面での感想

REST API であらゆる機能がアクセス出来るようになっており、好きなように運営ツールも作れそうなのはとてもよい。
反面、マネージメントコンソールでは 絞り込み・ソートなどの検索まわり・エクスポート機能 といった機能が不足していると感じる。
今後の改善に期待しています。

GS2 に対する費用面での感想

トライアル期間として十分な無料枠があることで導入検討しやすかったです。おかげでリリース直前まで費用が一切かかりませんでした。
ただ、API呼び出し回数などで費用計算されるため、リリース後に、実際はどの程度の費用が発生するかの見積もりが難しかったです。

GS2全体を通しての感想

正直に申し上げて、現時点でのGS2は採用実績が乏しく採用するにあたっては不安がありました。
しかし、いろいろな質問をサポートに問い合わせた際に、設計面や思想まで含めて丁寧に答えていただけたことで安心感につながりました。

GS2 CEO の丹羽さんと直接お会いする機会がありましたが、誠実で信頼のできる方でした。
今ではGS2を選んで良かったと思っています。

Game Server Services は現在アカウント登録していただいた皆様に 30,000円分のクーポン（有効期限: 登録日から3ヶ月間）をプレゼントしています。
この機会にお試しください。
gs2.io

SOCCER DUEL ONLINE

• studio R.E.E.L
• ゲーム
• 無料
• 

play.google.com

【新機能公開】GS2-Script によるサービス間の連携機能を公開

みなさん、こんにちは。GS2 CEO の丹羽です。

先日告知していた GS2-Script によるサービス間の連携機能を公開しました。
これにより、GS2 のマイクロサービス間をサーバレスで繋いで利用できるようになります。

利用例は以下のようになります。

スクリプトの実装・編集はマネージメントコンソール上で行えます。
引数はドロップダウンボックスでイベントの種類を選択するだけで、適切なパラメータのサンプル値が設定されます。

GS2-Script の API リファレンスは以下でご確認いただけます。
GS2-Script 内で使用できるAPIリファレンス - GS2 Documents

今後も GS2 ではゲーム開発者の皆さんがサーバレスでゲーム開発が出来るよう機能の拡充を進めます。

それでは、また。

【新機能】GS2-Script によるマイクロサービス間を協調動作できるように

みなさんこんにちは。GS2の丹羽です。

今日は近日公開予定の新機能の案内をしたいと思います。
今回紹介する機能は GS2 にとって今後重要な役割を果たす機能です。

GS2のいろいろなマイクロサービスで発生したイベントをトリガーとして GS2-Script を起動できるようになります。
また、GS2-Script 内で GS2-SDK が利用可能となり、そのイベント内でさらに GS2 の様々なマイクロサービスを呼び出すことが出来るようになります。

例として、GS2-ConsumableItem と GS2-Stamina を使って説明したいと思います。
GS2-ConsumableItem には アイテムの設定値として『アイテムを消費したとき』 をトリガーとして GS2-Script を起動できます。
その際に以下のパラメータが GS2-Script に渡されます。

{
  "itemPoolName": "アイテムプール名",
  "itemName": "アイテム名",
  "userId": "使用者のユーザID",
  "count": "消費数量",
  "accessToken": "アクセストークン"
}

『アイテムを消費したとき』のレスポンスとしては result に消費を許可するかをbool値で返します。
オプションで count を返すことで指定された消費数量を異なる値に変更することも出来ます。

result = {
  permit=true
}

では、さっそくこの仕組みを使用してスタミナを回復するアイテムを実装してみます。
スタミナを回復する『StaminaPotion』というアイテムを作成し、アイテムを消費したときのイベントとして 『UseStaminaPotion』 という GS2-Script を関連づけます。
これで、StaminaPotion を消費したときに GS2-Script が実行されるようになります。

次に 『UseStaminaPotion』というスクリプトに以下の実装をします。

stamina_client = client('stamina')
stamina_client:change_stamina({
  staminaPoolName='stamina-0001',
  variation=10*args.count,
  maxValue=100,
  overflow=false,
  accessToken=args.accessToken
})
result = {
  permit=true
}

これで、『StaminaPotion』を消費したときに GS2-Stamina の 『stamina-0001』のスタミナ値が 消費数量×10 回復します。
※ スタミナの最大値である maxValue を引数で取るようになっていますが、
　 GS2-Script 側でスタミナの最大値を取得する GS2-Script を定義でき、こちらを定義した場合は maxValue の指定は不要になります。

では、もうすこしちゃんとエラーハンドリングをして、スタミナの回復に失敗したときにはアイテムを消費しないようにします。

stamina_client = client('stamina')
response = stamina_client:change_stamina({
  staminaPoolName='stamina-0001',
  variation=10*args.count,
  maxValue=100,
  overflow=false,
  accessToken=args.accessToken
})
result = {
  permit=not(response.isError)
}

permit への戻り値に 『stamina_client:change_stamina』の戻り値に含まれるAPIの実行に成功したかを含むことで
何らかの理由でAPIの呼び出しに失敗した場合はアイテムを消費しないようにできます。

『スタミナの回復』 というチートされるとゲームバランスを崩壊されかねない操作を GS2-Script を経由して実行することで、より安全に設計することが出来るようになります。
このように、独自のゲームサーバを持たずとも『高い自由度』で『安全』で『スケールする』サーバプログラム開発を行えるようにしていきます。

それでは、また。

Serverlessconf Tokyo 2017 に登壇しました。そのほか雑感

みなさん、こんにちは。GS2 CEO の丹羽です。

昨日から始まった Serverlessconf Tokyo 2017 ですが、無事終わりましたね。
参加者の皆さん、スタッフの皆さん、スピーカーの皆さん。本当にお疲れ様でした。

オープニングで昨年の約300人の参加に対して、今年は450人以上と約1.5倍に参加者が増えたと聞きました。
一方で、今年は昨年の1トラックだったのに対して、2トラックになったことで一体感が薄れてしまったのか
Twitterでハッシュタグがトレンド入りした昨年に対して、今年はそこまでTwitter上での盛り上がりが無かったように感じたのが少し残念でした。
参加者の傾向としては、まだまだ私服の人が多く、身軽なベンチャー系のエンジニアの人が興味を持っている段階というのは変わってないようです。
私の登壇時にゲーム系の開発者がどのくらいいるのか。というの質問を昨年に引き続き、今年もしたのですが数パーセント程度という状態も変わってないようです。
昨年は直前にはチケットが売り切れていた記憶がありますので、もしかすると潜在的にはそれほど1年で変化がでていない。という可能性もありそうです。
Serverless の普及という文脈で考えたとき、この一年でサーバレスに興味をもつ人たちのユーザ層を増やせていない。という状態なのだろうな。と課題を感じました。

足元の環境の考察は置いておいて、セッションの内容は昨年と比べて今年はどう変わったのだろう。と振り返ってみました。

yoshidashingo.hatenablog.com
Serverlessconf Tokyo を主催している吉田さんのブログに昨年のセッションのまとめがあります。

昨年は概念的な話や方法論的な話が多かったのに対して、今年は具体的な実装の話が増えたように感じます。
昨年ホットだったワードは《サーバレスとは？》《ピタゴラ装置》《ステートレス》だったのに対して、
今年は《コールドスタート》《トランザクション》《冪当性》と、より具体的なワードがいろいろなセッションで見ることが多くなったように感じました。
なので、先駆者達はこの1年で確実に技術スタックを積み上げてきている。と感じています。

そして、興味深いのは昨年のランチセッションで きはるさんが Firebase のセッションをしたときに
Twitter上では「FirebaseってServerlessなの？ServerlessってLambdaのことじゃないの？」とざわつきましたが、
今年は Firebase をはじめとした マネージドサービスもサーバレスだという文脈で皆さんとらえていたように感じました。

それに対して、原さんがSaaSはサーバレスって言えるの？と一石投じるセッションをしていたり、興味深い流れも感じました。

実は、私もSaaSはサーバレスなのか？という事に対しては、ちょっと思うところがあります。
私はフルマネージドサービスはサーバレスだと思いますが、マネージドサービスはサーバレスではない。と思っているためです。
また、別の言い方をすると、スケールに限界があるモノはサーバレスではない。と思っています。
つまり、使用方法さえ間違えなければ《勝手に》《無限に》スケールするフルマネージドサービスこそがサーバレス。と言えるのではないか。と思っています。

なので、インスタンスタイプを明示してキャパシティ管理が必要なRDSやElastiCacheはサーバレスではないし、
リード/ライトキャパシティユニットを予約する必要のあるDynamoDBもあやしい。と思っています。ただ、明確な上限が無いという面ではRDSなどと比べて明らかな違いがあります。
（なので、キャパシティのオートスケールが実装されたので、ギリギリセーフかも？）

そうなると、サービスクラスによってIOレートを予約する必要のあるGS2はサーバレスではないSaaS。ということになってしまうのでしょう。
この裏には、DynamoDBのキャパシティ予約だったり、Lambdaの同時実行数の制限緩和などいろいろな事情があるので仕方がない部分もあるのですが、
今後の課題としてサービスクラスという考え方自体を廃止していけるのであれば廃止していきたいな。と改めて考えさせられました。

さて、ながながと感想を書きましたが、以下が私の登壇時に使用したスライドです。

それでは、また。