みなさんこんにちは、Cygamesにてゲームアートディレクターを務めている佐々木と申します。

8/22〜24に開催されたCEDEC 2018にて、「プリンセスコネクト！Re:Dive 制作事例 ～UIを高速かつ高品質に作るためのプロトタイプ開発のススメ！～」と題した講演を弊社UIデザイナー 齋藤と共に行いました。講演に参加して頂いた皆様には改めて御礼申し上げます。

今回は、講演資料の公開と講演後に沢山のご質問を頂きましたので、フォローアップという形にはなりますが可能な限りご返答したいと思います。

まず、当日の講演資料が下記となります。

質問の回答について

こちらでは、講演内では伝えきれなかったお話や、当日会場でご質問頂いた内容にご返答させて頂きます。

Q: UI開発に携わった人数規模はどれくらいですか？

A: 開発に携わった全体人数は挙げられないのですが、UIのデザイン業務に従事したデザイナーは5名程度です。

Q: どこまでがUIデザイナーの業務範囲だったのですか？

A: UIデザイナーとしては、下記などが主な業務です。

• 画面設計
• インターフェースデザイン
• 演出案作成

しかし、弊社のミッションステートメントに「常に「チーム・サイゲームス」の意識を忘れない」というものがあります。
職域に関わらず各々が出来ることは何でも取り組んでいます。

Q: 低忠実度プロトタイピングを採用しなかった理由はなんですか？

A: 今回は「手触りを改善したかった」という目的で高忠実度プロトタイピングを採用しましたが、プロトタイピングを採用した時期には既に低忠実度プロトタイピングの目的である画面遷移の検証が終わっていたというのも理由として挙げられます。

Q: Unityでプロトタイプを作らなかった理由はなんですか？

A:下記の理由からAdobe Animate CCを採用しました。

• デザイナーだけで小規模にプロトタイプ制作を行いたかった
• ビルド待ちの時間を短縮したかった

以上、会場でいただいたなかでも多かったご質問への返答となります。
みなさまのご参考になれば幸いです。

Cygames 3DCGアーティストの國府です。
2018年8月22日～24日に開催されたCEDEC 2018にて「空撮フォトグラメトリー技術とレーザースキャン技術の融合による広大な現実空間の3Dデータ化方法」という講演をいたしました。
講演にご参加いただいた皆様には、改めて御礼申し上げます。

数年前までは広大な現実世界を高精度な3Dデータにする場合、人手による地道で膨大な作業をこなすしかなく、さらに今ほどの精度を実現すること自体が困難でした。

また、高精度なデータを自動的にスキャンすることは、小規模なエリアなどに限定された使用に留まっていました。しかし、ここ数年で状況は大きく変化し「レーザースキャニング技術」「フォトグラメトリ技術」「ドローンによる空撮技術」などが目覚ましく発展しています。これらを有効に使用することで大規模エリアを高精度な３Dデータとして作成できるようになりました。

制作事例として、佐賀県鳥栖市にあるサッカー専用球技場「ベストアメニティスタジアム」を上記技術を融合し作成すること成功しました。

講演のポイント

今回の講演でポイントとなることは２点あります。

1つ目は、技術の融合です。「レーザースキャニング技術」「フォトグラメトリ技術」「ドローンによる空撮技術」各技術単体では、得意、不得意があり全ての問題を一つの技術で補うことはできません。しかし各技術の特徴を把握し、うまく融合することで問題点を補うとこができました。

2つ目に、異業種との連携です。今回は、測量会社の測量技術の知見を取り入れてプロジェクトを進めました。ありがちなことですが、何か乗り越えなければならない問題が発生した場合、同じ業界の中の情報だけで解決しようとすることがよくあります。
しかし、異業種や他分野で同じような事をやっている業界はないかなど、少し視野を広げて情報を集めてみると、問題の解決や糸口が見つかることがあります。

今回であれば、異業種である測量業界の知見を得る事で、高い精度とスピードでプロジェクトを進めることができました。

2点をまとめると、

• 各技術の特性を知り、利点、問題点を明確に把握し異なる技術を融合することで問題を補うことができた
• 異業種との協力により新たな技術や知見を得ることができ、大幅な時間短縮とクオリティーの向上を実現することができた

また、今後の展望として、今回のデータ作成で得られた知見をもとに、大規模エリアの高精度なデータ化実績を増やし、新たな技術の導入を模索しさらなる効率的な手法の確立を目指します。
そして、この技術の発展や、さらなる有効活用方法の模索のため、このスタジアムデータを大学や研究機関等に無償で提供公開する予定です。

ご興味のある方はCygamesの研究所であるCygames Researchまでご連絡ください。

最後に

Cygamesは「新しいこと」「おもしろいこと」が大好きです！！
Cygamesでは今後も新しいことや面白いことにつながる技術や、アイデアを追求し、ユーザーをに喜んでいただけるコンテンツを作っていきます。ご賛同いただける方は、是非ご一緒に働きましょう！

詳細は、こちらをご覧ください。

Cygames Research所属 コンシューマエンジニアの佐々木です。
2018年8月22日～24日に開催されたCEDEC 2018に於いて『VR/AR/MRの融合：高実在感コンテンツの未来』という講演を行いました。
当日は台風の影響で悪天候の中、沢山の方にお越し頂きありがとうございました。

本講演では、VR/AR/MRの三つのRの間に立ちはだかる壁を取り除き、最高のXR体験をユーザーに提供する為に、開発者はどの様に考えるべきか、どの様な解決手段があり得るかを、弊社で開発したMRアトラクション『VR四騎士』の開発事例を元に紹介いたしました。

以下が講演資料となります。

特に、MRコンテンツについては、現実空間をVR空間に高精度に再現することがユーザー体験の向上につながると定義し、その為に弊社が独自に技術開発した「空間センシング」「空間モデリング」について詳しく解説させて頂きました。

「空間センシング」

「空間センシング」とは、現実空間のスケールや形状を高精度に測定する技術と定義づけています。本講演では、「空間センシング」の採用実例として、工業用のレーザーレンジスキャナを用いた測量方法と、そこから得られた点群（ポイントクラウド）データの利用方法について解説しました。

「空間モデリング」

「空間モデリング」とは、現実空間のテクスチャやマテリアルを高精度に測定する技術と定義づけています。本講演では、フォトグラメトリーを使用して、HDR撮影された大量の写真から現実空間の「質感」を再現する方法について解説しました。

「空間センシング」と「空間モデリング」はそれぞれ独立した技術としても優れていますが、二つを融合することによって高精度な現実空間の再現を行う事が出来ます。これにより、HMDの装着前後で分断されがちなユーザー体験をシームレスにつなぐことが可能となり、より「実在感」と「没入感」を高めることにつながるのです。

他にも、サウンドの情報量とリアリティを高めるために導入した「空間オーディオ」と「フォーリー収録」についても解説させて頂きました。全ては、「最高のXR体験をユーザーに提供する」という目的を達成する為の技術開発の成果です。

Cygames Researchでは、XR以外にも新規性の高い研究開発を多数行っており、それらとIPを絡めた実用化も着々と進行中です。ご自身の研究とゲームを融合させ、世界に挑戦したいという方は、こちらからお問い合わせください。

こんにちは。Cygames インフラ統括マネージャーの佐藤です。

コンテンツ配信を行っている企業のネットワーク担当者であれば、世界最大のコンテンツデリバリネットワーク（CDN）事業者であるAkamai Technologies社（以下、Akamai）はご存知かと思います。

先日、Akamaiや同社のサービスを導入している米国の有名企業を視察する機会を得ました。Cygamesからは私を含めて3名が参加。各自の専門分野ごとに、グローバルな大規模配信、esports、品質管理などのテーマを持って臨みました。

Cygamesはすでに複数のタイトルをグローバル展開していますが、より多くのユーザーに、より快適にコンテンツを楽しんでもらいたいと考えています。そのために必要なインフラを構築するため、先行する米国のトップ企業を見学することにしたのです。

視察の行程は、ロサンゼルス（LA）にあるRiot Games社、ボストンのAkamai本社およびマサチューセッツ工科大学（MIT）のメディアラボを視察。さらに、ニューヨークではBAMTech社、Vimeo社、ROKU社のスタッフを交えた意見交換を行うなど充実した内容でした。今回は私が視察で得た知見をレポートします。

LoLの開発元・Riot Gamesのオフィスを訪問

Riot Gamesは、『League of Legends』（以下、LoL）を開発・運営している企業です。LoLと言えば1億人を超えるプレイ人口を誇るオンラインゲームであり、世界最大規模のesports大会を展開している超ビッグタイトルです。

まずは、LA郊外にあるRiot Gamesの本社オフィスを訪問。12エーカーの広大な敷地内に、低層の建物が点在する形式で、アメリカ西海岸のIT企業らしい雰囲気です。

オフィス内で特に印象的だったのは、グローバル規模のシステムを集中監視するネットワークオペレーションセンター（NOC）です。ここでは同社の全システムのステータスをひと目で把握できるようになっています。

このNOCはフィリピンのマニラやアイルランドのダブリンにも設置されており、LA、マニラ、ダブリンのNOCのうち、常に2つを稼働させているとのこと。全世界のサービス状況を24時間体勢でモニタリングするために、3つのNOCをローテーションで稼働させているようです。

また、オフィスの敷地から道を隔てたところにある同社のesportsセンター（NA LCS Studio）も見学しました。ここの目玉は、400人の観客を収容できるラウンド型のスタジアム。複数台のカメラや階段状の観客席などを備えた、本格的なスポーツスタジアム仕様です。

NA LCS Studio内には、esports大会専用のサーバールームのほか、カメラや音響機材をコントロールする放送局さながらのマスタールームも設置されています。パリで開催された同時視聴者数約6000万人のesportsイベントでも、このマスタールームからカメラのスイッチングなどを行ったそうです。

パリからLAのある米国の西海岸まで、エンコーディングを含めて300ミリ秒という速さで映像を伝送可能だそうで、この部分にAkamaiのサービスが活用されています。ここまでの設備を自前で持つのは、「integrity」（完全性）を重視するRiot Gamesのこだわりを感じました。

世界中のサーバーを1拠点から監視するAkamaiのNOC

ボストンにあるAkamai本社でもNOCを見学させてもらいました。ここでは、世界中に設置しているエッジサーバーの稼働状況、各リージョン（地域）のネットワークキャパシティ、トラフィック量などのさまざまな情報がモニター表示されていました。

驚いたのは、ワールドマップで各リージョンのステータスを確認できるだけでなく、マップを拡大表示していくことでエッジサーバーのクラスター、さらにはクラスター内の各サーバーのステータスまで確認できることです。ポーランドやインドにも同様のセンターがあり、複数のロケーションから監視しているそうです。

ちなみに、私たちがAkamaiを訪れたのは、同じ週にEpic Games社の『Fortnite』がリリースされたタイミングでした。人気タイトルのリリースということで世界中で多くのユーザーが一斉にダウンロードしました。この時も平常時よりかなり高いトラフィックが動いていましたが、異常値を示すステータスはなく、センターは平穏そのもの。Akamaiのネットワークキャパシティの大きさを実感しました。

CygamesにおけるAkamai CDN活用の現状

最後に、当社の本各スマホカードバトルゲーム『Shadowverse』の運用におけるAkamai CDNの利用方法について少し紹介したいと思います。

Shadowverseは世界150カ国以上に配信しており、４カ月に1度、大型アップデートを行って新規カードパックを配信しています。この大型アップデートのタイミングで、下図のように平常時の何十倍という膨大なトラフィックが発生します。毎回、これに備えてAkamaiにネットワークキャパシティを確保してもらうことで、サーバーをダウンさせることなく配信できています。

このほか、API通信などのオリジンサーバーに対するデータサイズが小さい通信に対してもAkamai CDNを利用しています。その理由のひとつは、ネットワークの最適化を行うAkamai独自のソリューション「SureRoute」を利用するためです。SureRouteを利用することで、最短のネットワーク経路を選択し、海外からのリクエストにも低遅延でのレスポンスが可能になります。

もうひとつの理由は、DDoSなどの攻撃対策のためのセキュリティソリューションです。Akamaiのセキュリティソリューションはエッジサーバー上で防御を行うため、エンドユーザーに近いところで効率的に対策できる点を評価しています。

このようにアップデートファイルのダウンロードなどの大容量な静的コンテンツでは「スケーラビリティ」を目的として、API通信では低遅延の実現とセキュリティの確保を目的としてAkamai CDNを利用しています。

また、大容量な静的コンテンツとAPI通信でコンフィグレーションを分離することにより、それぞれの通信が影響し合わないようにしています。例えば、大型アップデートで想定以上のトラフィックが発生しエラーや一時的な輻輳が発生したとしてもAPI通信には影響を及ぼさず、対戦中のお客様のプレイに支障が出ないような設計にしています。

最後に

今回の視察では、Cygamesのコンテンツをより多くのユーザーに届けるために、ネットワークインフラをどう構築していくべきか、世界のトップ企業からノウハウや知見を得ることができました。

この度、Shadowverseで大規模向けセキュリティソリューションを導入し、BoTやDoS攻撃の影響を低減していることなどが、Akamai社に認められ同社が制定する「カスタマーアワード」の1つをCygamesが受賞しました。弊社の取り組みが認められ大変うれしく思います。

とはいえ、私たちが目指しているのは、より多くのユーザーを楽しませることです。今後も楽しく快適にプレイしてもらうことを目標として、日々の作業に取り組んで行きます。

Cygamesでは、ユーザーに最高のコンテンツを届けるため、一緒に活躍してくれるメンバーを募集しています。興味を持っていただけた方はこちらをご覧ください。

Cygames エンジニアの森重です。
2018年9月30日（日）に東洋大学で開催されたCG技術の実装と数理 2018に於いて『Introduction to Direct X Raytracing』という発表を行いました。
CG技術の実装と数理は、SIGGRAPHやEurographicsなどで発表された技術論文やコースを自分で実装して、見えてきた課題やわからなかった点を議論して、次の技術研究開発につなげていく研究会です。
当日は、台風の影響で悪天候の中、発表と議論に、お越しいただいたみなさま、ありがとうございました。

はじめに

本発表では、レイトレーシングをCPU, GPU Compute, DirectX Raytracing(DXR)のそれぞれで実装してみた際の検討事項、課題、結果について紹介しました。
以下が発表資料となります。

「DXR を使ったAmbient OcclusionとIndirect Diffuseの実装」

リアルタイム・レンダリングにおいて、SSAOやRasterizationのCubemap/Spheremapでは取り込めなかった情報(radiance, visibility)が、レイトレーシングでは取り出せました。
今回は、最小のレイで、最大の情報が得られるように、GBuffer Normalから、Ray Scatteringしています。（いわゆる Hybrid Rendering）
結果はレイ数に応じたノイズがあり、EA SEEDが採用したようなDXR向けの近似高速化手法の開発が必要になってくると思いました。次回はその辺りに取り組んでみたいです。

「Simple DXR Framework の設計」

今回の実装で体感したのが、DXR APIを直接使うと、コード量がかなり増えてしまい、実験や描画といった本来の目的達成に時間がかかるということです。
そこで、お勉強も兼ねて、今回取り組んだ、簡単な Simple DXR Frameworkの設計とコードも少しだけ紹介しました。（後日、GitHub で全てのコードを公開予定）
Frameworkは、NVIDIA Falcorがあるのですが、2018年10月現在、PascalやIntel, AMD, Game Consoleでは動かないです。（Fallback Layer が未実装だからです）

おわりに

Cygamesでは、技術研究だけでなく、2018年9月に一般公開されたハイエンドゲーム『Project Awakening』の制作や内製Game Engine, Cyllista の開発も進めております。
既存の技術実装だけでなく、深層学習やRaytracingといった比較的新しい技術トレンドを導入していく余地もあります。ご自身のアイデアや熟練の技を新しいステージに持っていきたい方、世界に挑戦したい方は、こちらからお問い合わせください。

皆さまこんにちは。Cygamesでデバッグマネージャーを務めている安倍と申します。リリース前のゲームを検証し、ユーザーが快適にプレイできる品質を確保するのが主な職務です。

前回のエントリーでご紹介した米国企業視察に、私も参加してきました。レポートの後編となる今回は、デバッグを統括している者の立場から得たいくつかの気づきを共有します。

Cygamesでは世界展開を行うゲームタイトルが増えてきています。同じようにグローバルで成長するゲーム企業が、自社タイトルの品質管理についてどのような取り組みを行っているのかを確かめることが私の目的でした。

世界一のゲームを支える労働環境と開発環境

視察の概要は前編でお伝えしたので、ここでは個人的に興味深かった部分にフォーカスしてお伝えします。いくつかの企業を訪問した中で、特に刺激を受けたのがRiot Gamesの本社です。

Riot Gamesは、オンラインゲームの代表的タイトル『League of Legends』（以下、LoL）の開発・運営会社です。LoLは2009年にリリースされた後、2016年には月間アクティブユーザーが1億を突破した、まさに世界トップクラスのタイトルです。また、同社はesports分野にも力を入れており、本社の敷地内にも大会用のスタジアムを設置しています。

同社の取り組みの中で印象的だったのが、素晴らしいプロダクトを生み出すための充実した開発環境。中でも、開発中のゲームのプレイテストを実施できる「PLAYER RESEARCH LAB」という専用ルームがあるのには驚きました。この部屋に2週間ごとにリサーチプレイヤーを集め、テストプレイを繰り返しているそうです。特定の操作の意見や感想を聞くなどして、ピンポイントにプレイヤーの意見を収集できるのは、デバッグの手法としては効果的だと思いました。

最高のコンテンツを支える最高のデバッグとは

Cygamesでも、手作業によるデバッグには力を入れてきました。創業時からソーシャルゲームがメインだったこともあり、実機検証が大きなウエイトを占めています。

実機検証では、国内で発売される主要なスマートフォンやタブレットなど、すべての携帯端末で動作や表示のチェックをしています。どの端末がどれくらい快適にプレイできるかを、手動でテストするのです。このため、検証用端末はデバッグチームが所有するものだけでも1300台以上にもなります。

最後に

Riot Gamesの「PLAYER RESEARCH LAB」もCygamesの実機検証も、人の手による検証である点は共通です。こうした検証はもちろん重要ですが、いま私は、別方向からのアプローチの必要性を感じています。

開発するゲームタイトルが増え、またゲームの内容も複雑化し、検証項目がどんどん増加しています。もはや人の手では追いつかなくなりつつあるので、AIなどを導入して効率化や品質向上を図っていく必要があるのです。すでにそのための取り組みも始めていて、GDC 2018ではディープラーニングを用いてデバッグを効率化する技術についての研究発表も行いました。

手作業による地道な実機検証に加えて、今後は効率化や自動化を強化したいと考えています。並行して開発するゲームタイトルが増え、また1つのゲームが高度化していく中で、必要十分な検証を短期間に行うことが品質向上のカギとなります。そこをエンジニアリングによって効率化する仕組みが必要なのです。

そのために、分析から提案、設計、自動化を実現してくれるエンジニアを求めています。効率化や自動化に興味がある人は、ぜひ当社の採用ページをご覧ください。一緒に、世界で勝負できるような高い品質のゲームを作りましょう。

初めまして。インフラチームの和田 明久と申します。

2018年12月4日に開催された、日本で初開催となる Amazon Game Developers Day(主催:アマゾン ウェブ サービス ジャパン株式会社)にて「モバイルゲームにおけるカオスエンジニアリング実践に向けて」と題して、弊社におけるカオスエンジニアリングの取り組みについてご紹介させていただきました。会場にご足労いただいたみなさま、誠にありがとうございました。セッション内容を少し振り返ってみます。

弊社の運用タイトルは会社設立以降、増加の一途を辿り、定常的な安定稼働が求められています。モバイルゲームはユーザ様の1アクションがユーザエクスペリエンス(UX)に直結するため、高い稼働率と低遅延が要求されます。ひとたび障害が発生するとUX低下はもとより、機会損失・ユーザ離れ・ゲームへの信頼性低下を招きます。近年、ITインフラ環境が障害等の不安定になっても、耐障害性の高いシステム構築を志向するカオスエンジニアリングという技法が登場しています。そこで、弊社においてもより信頼のおけるゲームシステムを目指すべく、開発フェーズとインフラチーム内において実践したカオスエクスペリメントの一部をご紹介させて頂きました。

こちらが講演資料となります。是非一度お目を通していただけると幸いです。

※ スライド中の「Chaos Loop」「Chaos Sheet」などは社内独自の表現です。

スライドでは説明しきれなかった箇所を補足させていただきます。

例示

カオスエンジニアリングの考え方を我々の現実社会に存在する事例で捉え直しています。例えばインフルエンザの予防接種、災害時において1人でも多くの生命を救うための防災訓練など、被害の拡大を最小化するような事前準備があります。このような考え方をITインフラに取り入れたものがカオスエンジニアリングであり、ITインフラの障害訓練のようなものです。

ChaosConf2018

2018年9月末にSanFransiscoで開催されたChaosConf2018(主催:Gremlin Inc.)へ参加してまいりました。基本から最先端事例を学べるセッションで、広告・メディア・流通といった業種のSREやインフラエンジニアが登壇しておりました。一般的な事例だとサービスのプロダクション環境における一部のコンポーネント（インスタンス）を停止させても自律的に回復するシステムかどうか実験していることが多いですが、”デプロイフローで擬似的にコンポーネントを停止させても正常にロールバックされるか”、”アプリケーションコード中にユーザ単位で障害注入(Fault Injection)しても動作に支障がないか”、といった仮説に基づいたアプローチをしている組織もありました。カオスエンジニアリングの応用範囲は広く、弊社でもアプローチできる対象はいくらでもあることを実感し、帰国後早々に新たな実験対象を考え、手をつけられる箇所から導入しています。内容はこちらから全セッションが確認できますので、興味がある方はご参照ください。

事例 RDS Failover 中に出てくるカーネルパラメーター

Multi-AZ(Availability Zone)構成のRDSでFailoverが発生すると新しいAZに切り替わりIPアドレスも新しくなります。こういった自体に備えるためDNS名でアクセスしていますが、Mysqlクエリ実行中にFailoverが実施されると、Webサーバからの接続は応答待ちとなりプロセスを維持します。こちらが大量発生した場合に新規のリクエストを受け付けなくなることを回避するべく、TCP接続のタイムアウトと再送間隔を短縮するようにカーネルパラメーター（tcp_retries2）を最小推奨値8に修正しました。これによりデフォルト比でタイムアウト時間が1/9となり不要なコネクション解放に繋がりました。

最後に

今回の登壇内容がモバイルゲームに限らずITインフラを支える部門にいらっしゃる方にとって一助となれば幸いです。今後もカオスエンジニアリングを利用して高品質なシステム設計や構築を進めてまいります。皆様のお役に立てそうな事例ができましたら、またご紹介させていただきます。

Cygamesではカオスエンジニアリングに関連する取り組みにご興味のある方、もしくは実践経験のある方を募集しております。国内での事例が少ないため手探りでのアプローチになることも想定されますが、自ら道を切り開いてやりとげるような心持ちの方と高品質なシステムを構築していければと思います。詳細はこちらをご覧ください。

Cy#の河合です。Cy#は今年の9月に設立されたばかりの会社で、その名の通りC#関連の開発を行っていきます。今回はCy#よりオープンソースライブラリとして、Unity向けのリアルタイム通信/API通信統合ライブラリをリリースしました。

GitHub – cysharp/MagicOnion

もともと2年前に最初に公開し、実際にリリースされたモバイルゲームでも使用していたものですが、今回リアルタイム通信向け機能をよりブラッシュアップして、正式公開としました。そういう点では、”既に実績がある”とも言えます。今回より新しいスタートということで、バージョン2.0です。

基本的な機能は サーバークライアント間のストリーミングRPCを提供します。サーバー側をC#、クライアント側もC#で実装し、メッセージのフォーマットはLZ4圧縮されたMessagePack、通信はgRPCによるHTTP/2を用いています。他のミドルウェアにあてはめるとNode.js(JavaScript)によるSocket.io(WebSocket)がイメージとして近いかもしれません。また、同時にAPIサーバーとしての機能もサポートするため、一般のウェブフレームワーク的でもあります。

MagicOnionは最高のパフォーマンスと、C#として手触りの良いインターフェイスの実現に注力しました。

C#により強く型付けされたインターフェイス

サーバーとクライアント間ではC#のインターフェースを共有することによって、クライアント->サーバーへのメソッド呼び出しと、サーバー->クライアントへのメソッド呼び出し両方を、強く型定義します。例として以下のようなインターフェイスやクラスを共有するとします。

// サーバー -> クライアントの通信定義
public interface IGamingHubReceiver
{
    void OnJoin(Player player);
    void OnLeave(Player player);
    void OnMove(Player player);
}

// クライアント -> サーバーの通信定義
public interface IGamingHub : IStreamingHub<IGamingHub, IGamingHubReceiver>
{
    Task<Player[]> JoinAsync(string roomName, string userName, Vector3 position, Quaternion rotation);
    Task LeaveAsync();
    Task MoveAsync(Vector3 position, Quaternion rotation);
}

// 送受信に使うカスタムオブジェクト
[MessagePackObject]
public class Player
{
    [Key(0)]
    public string Name { get; set; }
    [Key(1)]
    public Vector3 Position { get; set; }
    [Key(2)]
    public Quaternion Rotation { get; set; }
}

これをサーバーとクライアントで共有すると、どちらもこのインターフェイスを実装するだけで、正しく通信ができます。

と、いうように、中間言語からのコード生成等も不要で、C#として自然に（複数引数やプリミティブ型などが使える）メソッドを呼ぶだけで、ネットワークを超えてメソッド呼び出しができます。もちろん、入力補完も効きます。

具体的な実装は、以下のようになります。サーバーはIGamingHubとして定義したインターフェイスを実装します。

// サーバー実装
public class GamingHub : StreamingHubBase<IGamingHub, IGamingHubReceiver>, IGamingHub
{
    IGroup room;
    Player self;
    IInMemoryStorage<Player> storage;

    public async Task<Player[]> JoinAsync(string roomName, string userName, Vector3 position, Quaternion rotation)
    {
        self = new Player() { Name = userName, Position = position, Rotation = rotation };

        (room, storage) = await Group.AddAsync(roomName, self);

        Broadcast(room).OnJoin(self);

        return storage.AllValues.ToArray();
    }

    public async Task LeaveAsync()
    {
        await room.RemoveAsync(this.Context);
        Broadcast(room).OnLeave(self);
    }

    public async Task MoveAsync(Vector3 position, Quaternion rotation)
    {
        self.Position = position;
        self.Rotation = rotation;
        Broadcast(room).OnMove(self);
    }
}

ポイントは

• 全て非同期（戻り値Taskでasync)
• 戻り値を返すことも出来る（例外が発生した場合、それもクライアントに例外として伝搬されます）
• Groupでグループ管理してBroadcast(group)でグループ内のクライアントに送信

といったところになっています。クライアントのほうはIGamingHubReceiverとして定義したインターフェイスを実装することでサーバーからブロードキャストしたデータを受け取れます。また、IGamingHubそのものがサーバーへの自動実装されたネットワーククライアントとなっています。

public class GamingHubClient : IGamingHubReceiver
{
    Dictionary<string, GameObject> players = new Dictionary<string, GameObject>();

    // 委譲したメソッドを立てるのが面倒な場合は（面倒）これをそのまま公開したりしても勿論別に良い。
    IGamingHub client;

    public async Task<GameObject> ConnectAsync(Channel grpcChannel, string roomName, string playerName)
    {
        var client = StreamingHubClient.Connect<IGamingHub, IGamingHubReceiver>(grpcChannel, this);

        var roomPlayers = await client.JoinAsync(roomName, playerName, Vector3.zero, Quaternion.identity);
        foreach (var player in roomPlayers)
        {
            (this as IGamingHubReceiver).OnJoin(player);
        }

        return players[playerName]; // 名前だけでマッチとか脆弱の極みですが、まぁサンプルなので。
    }

    // サーバーへ送るメソッド群

    public Task LeaveAsync()
    {
        return client.LeaveAsync();
    }

    public Task MoveAsync(Vector3 position, Quaternion rotation)
    {
        return client.MoveAsync(position, rotation);
    }

    // 後始末するもの
    public Task DisposeAsync()
    {
        return client.DisposeAsync();
    }

    // 正常/異常終了を監視できる。これを待ってリトライかけたりなど。
    public Task WaitForDisconnect()
    {
        return client.WaitForDisconnect();
    }

    // サーバーからBroadcastされたものを受信するメソッド

    void IGamingHubReceiver.OnJoin(Player player)
    {
        Debug.Log("Join Player:" + player.Name);

        var cube = GameObject.CreatePrimitive(PrimitiveType.Cube);
        cube.name = player.Name;
        cube.transform.SetPositionAndRotation(player.Position, player.Rotation);
        players[player.Name] = cube;
    }

    void IGamingHubReceiver.OnLeave(Player player)
    {
        Debug.Log("Leave Player:" + player.Name);

        if (players.TryGetValue(player.Name, out var cube))
        {
            GameObject.Destroy(cube);
        }
    }

    void IGamingHubReceiver.OnMove(Player player)
    {
        Debug.Log("Move Player:" + player.Name);

        if (players.TryGetValue(player.Name, out var cube))
        {
            // 移動に対して補完が入っていないので勿論このままではワープしてしまいます
            // そこに対する補助は（現状は）ないので各自で行ってください
            cube.transform.SetPositionAndRotation(player.Position, player.Rotation);
        }
    }
}

C#として全てが強く型定義されているため、

• メソッド名や引数の変更などに対してのIDEのリファクタリング追跡されてサーバー/クライアント双方で効く
• 実装漏れなどはコンパイルエラーによって自然に防ぐことが出来る
• 文字列を介さないことにより効率的な通信ができる(メソッド名は自動的に数値によるIDに変換されているため、文字列は送りません)
• intなどプリミティブ型が自然に送れる（あえて固有のリクエストクラスなどにラップする必要はない）

というメリットがあります。Protocol Buffers を使う場合 .proto (IDL : 中間定義) ファイルの管理や、生成をどうするかなど、多くの問題が発生しますが、C#そのものである限り、一切その手の問題は起こりません。

ゼロデシリアライゼーションマッピング

RPC、特に頻度の高い通信が行われるリアルタイム通信では、送受信用にデータを変換するシリアライズ処理が性能面でのネックになることがありますが、MagicOnionでは私の開発したC#最速のバイナリシリアライザであるMessagePack for C#によってシリアライズするため、シリアライズ処理はボトルネックになりえません。また、MessagePack for C#でシリアライズできるなら、どんな型でも送ることができるというデータに対する柔軟性も、性能と同時に獲得しています。

また、クライアント/サーバーが共にC#であるため「内部のメモリ上のデータは同一レイアウトが期待できる」ことを生かして、値型の場合にシリアライズ/デシリアライズ処理をせずメモリコピーだけでマッピングする、というオプションを用意しました。

// Vector3などのUnityの標準structとその配列、あるいはカスタムstructとその配列が対応可能
// 厳密にサイズを合わせるため[StructLayout(LayoutKind.Explicit)]で明示することを薦めます
public struct CustomStruct
{
    public long Id;
    public int Hp;
    public int Mp;
    public byte Status;
}

// ---- 初期化事に以下のようなコードを登録する

// 登録することでTとT[]がゼロデシリアライゼーションマッピングになる
UnsafeDirectBlitResolver.Register<CustomStruct>();

// ↑のstructとUnity標準の構造体(Vector2, Rectなど)とその配列を標準登録
CompositeResolver.RegisterAndSetAsDefault(
    UnsafeDirectBlitResolver.Instance,
    MessagePack.Unity.Extension.UnityBlitResolver.Instance
    );

// --- あとは通信で使うと、自然に↑のフォーマットで送受信する
await client.SendAsync(new CustomStruct { Hp = 99 });

これは一切の処理が入らないため、転送処理において理論上最速といえます。ただしstructはコピーが発生するため、巨大なstructを定義するなら全てrefで処理するなどの工夫と規約をしないと、逆に遅くなる可能性もあるので、その点は注意。

大量のTransformを送る、例えばVector3の配列などでは、分かりやすく有効に活用できることと思います。

gRPCのBidirectional Streamingではダメな理由

素のgRPCでも Bidirectional Streaming として双方向通信の機能を持っています。そもそもMagicOnionのストリーミングRPCは Bidirectional Streamingの上に構築されています。

// protoによるBidirectional Streaming定義
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);

しかし、多くの理由でBidirectional Streamingをリアルタイム通信のRPCとして使うことは難しいでしょう。最大の点は、そもそもこの状態だとRPCではないため、コネクションが繋がった後、oneof(ひとつの型が複数の型を持つ)で定義したRequest/Responseを分岐させて、呼び出したいメソッドに手で振り分けることになるでしょう。そこまではやれたとしても、まだまだ足りないものは多く

• クライアントがサーバー側の実行完了を待てない（リクエストを送信できたというところで制御が戻る）
• 待てないということでリクエストに対する戻り値も例外も受け取れない
• 複数の接続を束ねる手段が用意されていない

それらを処理するための仕組みを作ってもなお、結局protoの生成するBidirectional Streamingのテンプレートからは逃れられないため、実装がゴチャついてしまうのは避けられないでしょう。MagicOnionのStreamingHubは、コネクションの確立をBidirectional Streamingの上に構築しつつも、その通信フレームの中で独自の軽量なプロトコルを流すことによって、C#として自然に扱えるリアルタイム通信用のRPCを実現しています。

分散戦略とgRPCを選ぶ理由

Unityのための他のリアルタイム通信エンジンなどと違い、MagicOnion自体はロードバランサーを持ちません。分散処理のための戦略は幾つかありますが、クラウドプラットフォームや各種ミドルウェアを活用する方向の選択をお薦めしています。例えば、完全に独立してインメモリでホスティングする場合、サーバーの台の選択は外部のService Discoveryに任せてしまうのが一つ。

もう一つは、TCPロードバランサーを用いて完全に分散しつつ、Groupによるブロードキャスト処理をRedisに委譲することで異なる台に繋がったクライアントへのデータの送信を可能にします。これは標準でMagicOnion.Redisとして提供しています。例えばチャットの実装などに向いているでしょう。

他、MagicOnion自体はgRPCそのものと同じように、いわゆるMicroservicesの実装にも適しているため、サーバー間でコネクションを繋いで、サーバー-サーバーRPCによって構成を組むことも可能です。

さて、MagicOnionはgRPCの上に構築されていますが、同時に最大の特徴である.protoによる言語非依存のRPC提供という部分を完全に無視しています。おまけにネットワーク通信がHTTP/2(TCP)に限定されるというのは、必ずしもゲーム向きとは言い難いかもしれません。それでもなお、gRPCを選ぶべきと考えた理由があります。

一つはライブラリとしての成熟度で、そもそもUnity含めたサーバー/クライアント実装が使える通信ライブラリは存在しない上に、コア部分(全言語共通のgRPC C)はgoogle含めて圧倒的に世の中で使われているため、安定性が非常に高い。ゲームに特化した部分だけの通信の独自実装は、できなくはないでしょうが、一から安定性を高めていくことを考えると、乗れるものには乗っかたほうが無難でしょう。

ただし、主にパフォーマンス面でgRPCのC#バインディングに関しては不満があります。そのためgRPC C Coreはそのまま使いつつ、C#バインディングだけを完全に置き換えてしまうのはアリだと思っています。少なくともUnity側（クライアント通信）のみならば、現実的かつ効果も高いと思っているので。

もう一つはエコシステムで、gRPCは現行世代のRPCとしてほぼデファクトスタンダードと言える地位を確立したため、多くのサーバー用ミドルウェアが対応しています。NginxのgRPC対応やEnvoyによるリクエスト単位のロードバランシングなど、HTTP/2, gRPCという業界スタンダードなプロトコルだからこそ授かれる恩恵が多くあります。また、gRPCは英語でも日本語でも、ブログや事例スライドが豊富なため、より良いシステム構築を目指しやすいのも大きな利点です。

MagicOnionもアプリケーションレイヤーでは独自のものが構築されていますが、インフラ的な意味ではgRPCそのものなので、ミドルウェアも、共有されているナレッジも、ほとんどがそのまま適用できます。

現代のサーバーアーキテクチャはクラウド前提であるべきだと思いますし、クラウドプロバイダーの提供するインフラやミドルウェアにフルに乗っかったシステムのほうが、全部自前で持とうとするシステムよりも優れた結果を残せると思っています。よって、特にインフラに関わるフレームワーク自体の機能は薄くしていくべきでしょう。

API通信系への対応

MagicOnionはUnified Network Engineを標榜しています。この場合のUnifiedは、サーバーとクライアントがC#で統一されること、を意味するのではなくて、リアルタイム通信系とAPI通信系が統一されて扱えることを意味しています。API通信系も同じように、インターフェイスを共有し、C#として自然にメソッドを定義すれば、クライアントコードも自動で生成される仕組みになっています。

// StreamingHubと同じようにインターフェイスを定義し、共有する
public interface IMyFirstService : IService<IMyFirstService>
{
    UnaryResult<int> SumAsync(int x, int y);
}

// サーバー側はそのインターフェイスを実装する
public class MyFirstService : ServiceBase<IMyFirstService>, IMyFirstService
{
    // マジカルテクノロジにより戻り値がTask<T>じゃなくても良い
    public async UnaryResult<int> SumAsync(int x, int y)
    {
        // 内部は完全に非同期対応なので自然な書き味でノンブロッキングAPIが実装できる
        Logger.Debug($"Received:{x}, {y}");

        return x + y;
    }
}

// クライアント側ではそのインターフェイスを取り出し、呼び出す

// インターフェイスを通信コード実装に置き換えたプロキシを取得する
var client = MagicOnionClient.Create<IMyFirstService>(channel);

// 自然な感じに引数を渡し、自然な感じに戻り値が受け取れる
var result = await client.SumAsync(100, 200);

API系においてもフレームワークレベルで全てが非同期・ノンブロッキングであることが徹底されていますが、C#のasync/await言語機能によりほとんど自然に見せることに成功しています。リクエスト前後をフックするフィルター機能も用意されていて、これも自然に非同期で処理されるようになっています。

// 適用したいメソッドに[SampleFilter]のように属性を付与すると重ね合わせられる
public class SampleFilterAttribute : MagicOnionFilterAttribute
{
    // 前後の処理のフックを非同期で、かつC#の言語仕様のまま自然に書けるようになっています
    // このフィルタを重ね合わせた様がたまねぎ状であることが、MagicOnionの由来となっています
    public override async ValueTask Invoke(ServiceContext context)
    {
        try
        {
            /* 前処理 */
            await Next(context); // メソッド本体、あるいは次のフィルターを呼ぶ
            /* 後処理 */
        }
        catch
        {
            /* 例外時処理 */
            throw;
        }
        finally
        {
            /* 後始末 */
        }
    }
}

なお、フィルターはStreamingHubでも同様に使えます。

Swagger

APIは動作確認しづらい、常にUnityから叩くのも面倒くさいし、gRPCではPostmanのようなツールで叩くこともできない。と、そこでMagicOnionではSwaggerによる実行可能なAPIドキュメントを自動生成することにしました。MagicOnion自身がHTTP/1サーバーとなりホスティングするため、別途外部のプロキシサーバーを立てる必要などはありません、起動部分のコードに数行加えるだけです。

これで簡単に動作確認できるほか、デバッグコマンドなどもAPIとして定義するだけSwagger上に並ぶため、デバッグ用にデータベースを操作するコマンドなども簡単に用意していくことが可能かもしれません。

現状StreamingHubは対応していませんが、WebSocketとMagicOnionを接続するWebSocketGatewayを作る予定はあります。

デプロイとホスティング

従来、C#サーバーサイド最大の難関はデプロイどうしよう、ホスティングどうしよう、ということでした。なにせWindows Serverでしたし。gRPCだったら、更になおIISじゃないから余計に難しかったり。しかし、現在は簡単です。Dockerでコンテナ化してしまえば、別にC#だからって特別なことは何一つありません。.NET Coreによって作成されたMagicOnionアプリケーションをコンテナ化するのは特に複雑なこともなく簡単で(実態はただの.NET Coreコンソールアプリケーションです)、あとはそれをLinuxコンテナにデプロイしてしまえば良い。ECSでもFargateでもGKEでもAKSでも、どこでも良いのです。そのためのプラクティスも、ネットに存在する様々な記事のものをそのまま適用すれば良いでしょう。

現状C#でのコンテナ化の意義は、ローカル環境を構築するためというよりも、開発環境/本番環境に簡単に運ぶため、特に今までC#/Windowsに馴染みのなかった人が特別なことを学ぶことなく豊富なインフラ知識をそのまま活かして適用することができる、ということが最も大きいのではないかなあ、と感じています。

終わりに

Cy#の理念は「C#の可能性を切り開いていく」です。MagicOnionはリアルタイム通信系のためだけに導入してもらってもいいですし、API通信系だけでも十分以上に機能します。高速な通信と、圧縮も考慮されたシリアライザが適用されるため、導入すれば通信関連に関して一切悩む必要はなくなるでしょう。また、Unityにおいてはasync/awaitが活用されているため、最新のC#を導入していくためのゲートウェイとしても機能するかもしれません。

リアルタイム通信フレームワークとしては、Client-ServerのRPCしか提供していません、が、逆にそれがあれば他は全部なんとかなります（モノによりますが実装量もそれほど多くはないはず）。余計なものがついてなくて、RPCに関して最高の手触り（とパフォーマンス、と言いたいですがgRPC C#バインディングのほうで気になるところがあるので最高のパフォーマンスというのは、また次に取っておきます）を提供できたのではないかと自負しています。

また、完全に自前のシステムで完動するため、VR/ARの展示など限定されたLAN環境などでも、LAN内でサーバーを起動しておくだけで問題なく展開することができます……！

Cy#ではMagicOnionを中心に、C#活用の道を作り出していきたいと考えています。
是非、皆さんも試していただければ幸いです。

何かありましたらGitHubのissueや私の個人宛てにどうぞ。

こんにちは。サーバーサイドエンジニアの金山です。

2018年12月15日に開催されたPHPカンファレンス2018にて「Cygamesにおける長期運用のこれまでとこれから〜負荷対策とPHP7への道〜」と題した講演を行いました。
講演に参加して頂いた皆様には改めて御礼申し上げます。

発表資料は下記になります。

※資料のP7に誤りがあり訂正いたしました。
（修正前）リクエスト数 1000-4000/秒
（修正後）リクエスト数 1000-7000/分

発表した内容について

• 運用で気をつけていること
• PHP7.2への移行の流れ
• 負荷対策について

安全かつ安定した環境には負荷対策やバージョンアップが必要です。
ですが、運用タイトルで安全にそれらを行なっていくには気をつけるべきポイントがいくつもあります。

本講演では長期運用タイトルならではの問題も踏まえ、問題点を正しく把握する手段や、安全に改修を行うための手段など、安全にバージョンアップや負荷対策を行うための考えかたや手法を紹介させていただきました。

「安定運用のためのポイント」について、ぜひ資料をご観覧いただければ幸いです。

発表を終えて

PHPカンファレンスで発表させていただき、大変貴重な経験となりました。
普段気を付けていることを整理し資料の形に起こすことは、改めて問題点と向き合いシンプルに整理する大変よい機会となりました。
今回紹介した内容の多くは、些細なことだったり、小さな事の積み重ねかもしれません。ですが、そういった基本的な事を当たり前にやる事こそが、安定運用につながるものだと考えています。

今後の対応としては、PHP7へのコードの最適化や、より効率のいいテスト方法などをすすめていきます。
これからも最高のコンテンツで遊んでいただくために、安定した開発と改善を続けます！

はじめまして、データ分析基盤チームの藤田と申します。

2018年12月15日に開催された Developers boost において「ゲーム運用を影から支えるCygamesのデータ分析基盤について」というタイトルで、弊社のデータ分析基盤の仕組みなどをご紹介させていただきました。
講演にお越しいただいた皆様には改めて御礼申し上げます。

本講演では、Amazon Redshiftを中心としたCygamesのデータ分析基盤の仕組みについて紹介させていただきました。

以下が講演資料となります。

講演の内容について

Cygamesの分析基盤の役目はゲームDBやサーバーログなど、ゲーム環境のデータを分析用にRedshiftに取り込む事です。

Redshiftに取り込まれたデータは分析業務だけでなく、内製BIツールのリソースやゲームのCS対応のために利用されることもあります。
分析業務ではリリース直後やイベント開始直後のいわゆる速報でのアクセス数やKPIが知りたいというケースが度々あるため、データを即座に取り込める事が求められます。

また、アップデートが頻繁に起こるソーシャルゲームにおいては負荷対策などのために急にゲームDBへのスキーマ変更などが入ることもあり、その際にスキーマの変更が起きたためにデータの取り込みが止まってしまう、ということは避けなくてはなりません。

もちろんゲーム運用チームとの連携は密に取り、スキーマの変更の情報などは共有を受ける体制を取っていますが、ゲームの安定した運用のために止むを得ず急な変更が入ることは稀にあるため、そういった状況でも運用を支えられる基盤を構築・運用する事がデータ分析基盤チームのミッションになると考えています。

要件をまとめると以下になります。

•  いつでも必要な時に必要な期間のデータがアドホックに取り込めること
•  ゲーム側でスキーマ変更があってもデータの取り込みに失敗しないこと

これらを満たすための基盤を弊社ではAWSを利用して運用しており、本講演で紹介させていただきました。
詳細は上記の講演資料をご覧いただければ幸いです。

また、今回のセッションでは紹介できなかったのですが、アドホックにデータを取り込むための工夫やRedshift上でのデータの持たせ方などはまた別の機会でお伝えできればと思います。

講演資料の補足

Togetter のまとめなどを見ていて、いくつか資料だけでは前提部分が足りてない部分があると感じたのでこの場をお借りして補足させていただきたいと思います。

Redshift上のデータの保持期間について

過去のデータが必要になるという事を講演内で述べましたが、前提として各ゲーム用のRedshiftのインスタンスである程度古くなったログデータは削除しています。
これは単純にコストの問題で、データを永続的に保持し続けるとRedshiftのストレージのためにコストがかなりかかってしまうためです。
Redshiftからデータを消しても、資料(p.25) にあるようにS3にデータがアーカイブされているため、これを利用することで、必要な期間のデータを即座にロードし直す事ができます。

古いスキーマのテーブルと新しいスキーマのテーブルを跨いだ分析が必要になった場合

基本的にRedshift上に別テーブルでもデータが入ってさえいればほとんど時間をかけずに対応はできる事が多いので、両方のテーブルを包含するようなスキーマで結合するか、その対応も待てない場合は分析クエリ上でJOINなどして結合することになります。

もちろんうまい具合に新旧のスキーマを自動で結合できるような仕組みが理想なのですが、一番避けたいのはスキーマの変更によりデータがRedshift上に入っておらず取り込み処理を1からやりなおしという状況なので、データをRedshiftに入れる事だけは最優先にしています。

おわりに

弊社のデータ分析基盤チームとしては初めて講演の機会を経て、大変貴重な経験をさせて頂けたと思っています。
今回の講演がデータ分析基盤の業務を行なっている方々の参考になりましたら幸いです。
Cygamesの掲げる「最高のコンテンツを作る」というミッションを支えられるデータ分析基盤を目指し、今後も改善を続けていきます。

Cygamesでは、データ分析基盤を一緒に開発していけるエンジニアを募集しています。
今回の講演や資料をご覧になり、興味をお持ちいただけましたらデータマイニング(分析基盤開発)の採用ページをご確認ください。

こんにちは。インフラエンジニアの杉本と申します。

2018年12月15日に行われたDevelopers Boostにて、「運用規模の拡大を乗り越える 〜Toilの撲滅〜」と題して、弊社インフラチームの取り組みを発表させていただきました。講演にご参加いただいた皆様、誠にありがとうございました。

講演資料はこちらになります。

演題にもありますとおり、Toil（苦労）を削減し運用負荷を低減するべく行ったことと、その成果物についてお話させていただきました。Toilとは、サイト・リライアビリティ・エンジニアリングの文脈で用いられる言葉です。日々の作業のうち、手作業である、繰り返されている、自動化が可能であるといった性質が強いものはToilであると言われます。私たちインフラチームは、エンジニアがToilにかける時間を減らし、チームやプロダクトに恒久的な改善を加えるための時間を増やすことで、年々規模が拡大してゆくインフラ運用の負荷を乗り越えてきました。

本講演では“サーバー構成情報管理のToil”および“サーバー構築のToil”を取り上げ、それぞれどのように削減していったかを主要なトピックとしました。以下、発表内ではお伝えしきれなかった点も含めてご説明いたします。

サーバー構成情報管理のToil

インフラチームが管理するサーバーは多数かつ多様なため、サーバー構成情報の一元的な管理が重要になります。そこで、サーバー情報が自動的に登録・更新されるデータベースと、その情報が反映されるローカルネットワーク用プライベートDNSを作成しました。

これらの機能は、各サーバーにインストールする独自実装のエージェントの働きとAWSのマネージドサービスを活用した処理フローによって実現されています。エージェントを独自実装することによって収集したい情報を柔軟に設定することができ、オンプレミス環境とクラウド環境が混在するCygamesのインフラ構成をカバーできます。また、AWSのサービスを活用することで、非同期的・スケーラブルな特性の獲得と、マネージドゆえに低い管理コストを実現できています。

図：サーバー構成情報収集ツールのアーキテクチャ

サーバー構築のToil

サーバーの構築は繰り返しの作業であり、ミスを起こさないよう注意が必要な作業です。内製ツールのインストール作業などはRPM化しプライベートなリポジトリに格納しておくことで、再利用が容易になりました。加えて、サーバー構築をプロビジョニングツールで行うことで、作業の自動化・インフラのコード化が達成されました。

プロビジョニングツールは様々なものを用いてきましたが、徐々にAnsibleを使用するケースが増えてきています。記述がシンプルであることと、エージェントレスで動作することがメリットとなっています。最近では、長期運営タイトルでのPHP 5からPHP 7への移行作業などで活用しています。

おわりに

CygamesではToilの削減やサイト・リライアビリティ・エンジニアリングにご興味のある方、実践経験のある方を募集しております。最高のコンテンツを支える基盤の信頼性を高めるべく、ともに業務効率化を推進しましょう。詳細はこちらをご覧ください。

はじめまして。Cygames Researchでエンジニアをしている朝日田です。

2018年12月15日に開催されたDevelopers Boostにて、「スマホアプリで次世代ARを実現する～ARKit/ARCoreの活用」と題した講演を行いました。講演に参加していただいた皆様には改めて御礼申し上げます。

本講演は、今回開発したスマートフォン向けARアプリに用いた技術を抜粋して解説しました。このブログでは、講演で述べた内容を少し補足したいと思います。

発表資料は下記になります。

高い実在感をARで表現する3つのポイント

今回開発したARアプリは、スマートフォンの内蔵カメラで写した現実世界の中を、3DCGのキャラクターが動き回るというものでした。ARで高い実在感を表現するには、CGやアニメーションの質が大事なことはもちろんですが、それ以上に、いかに現実に溶け込ませるかが重要となります。

そのためには、ユーザーとキャラクターの間に存在する遮蔽物でキャラクターが隠れるように見せること（オクルージョン）で、本当にそのキャラクターが存在しているような実在感を演出します。この表現は、現実の空間をそのまま再現したCG空間を作成し、それをカメラで捉えた現実の景色と重ね合わせることで実現させることができます。

オクルージョンを実現するには、（１）自分（ユーザー）がどこにいるかを認識、（２）物体がどこにあるかを検出、（３）CGを現実に溶け込ませる、という3つの作業が必要となります。今回は、iOS／Androidに搭載されているAR機能であるARKit／ARCoreを使ってこれらを実装しました。ARKit／ARCoreを用いると、スマートフォンだけで以下のようなことができるようになります。

• モーショントラッキング
• 光源の推測
• 特徴点抽出
• 平面検出
• ImageTracking
• 空間共有

（１）自分（ユーザー）がどこにいるかを認識

まず、自分の現在位置を認識させるために、ARKit／ARCoreのモーショントラッキング機能を使用しました。これは、起動時からどれくらい動いたのかという情報を取得することにより自己位置推定を行うもので、スマートフォンが搭載するセンサーとカメラ画像から得られる情報により、現在の位置と向きを計算します。

（２）物体がどこにあるかを検出

物体がどこにあるかを検出するためには、検出したい物体にマーカーを貼り付け、そのマーカーを読み取ることで物体の位置を検出します。このマーカーは「arUcoマーカー」と呼ばれるもので、オープンソースのコンピュータビジョンライブラリである「OpenCV」を使って検出することができます。

ARKit／ARCoreのImageTrackingでも同様の動作ができるのですが、ARKit／ARCoreを使用した場合、検出の精度や実行間隔などを調整するときに、それぞれのライブラリごとに調整する必要が出てきてしまうため、今回は両方のOSで使用できるライブラリであるOpenCVを使用しました。

カメラでarUcoマーカーを撮影すると、マーカーのサイズと歪みから、カメラ位置に対するマーカーの距離と角度を算出します。この情報と、（１）の自分がどこにいるかという情報を統合し、現実空間の位置を推論してCG空間を重ねます。

次に、CG空間上でarUcoマーカーを貼った位置を指定します。これにより、現実の空間とCG空間の位置関係を正確に一致させます。この作業が必要な理由は、arUcoマーカーによって検出できるのは、あくまで「マーカーが（カメラから見て）どこにあるのか」だけで、「マーカーがCG空間内のどこに貼られているのか」まではわからないからです。今回は、一度arUcoマーカーの位置を仮に指定してCGを重ねた後、手入力で仮のマーカー位置と本来のマーカー位置とのずれを補正するという方法を用いました。

（３）CGを現実に溶け込ませる

最後は、CGの物体を現実に溶け込ませる作業です。（１）と（２）により、現在位置とそこから見える遮蔽物の位置関係を把握し、遮蔽物を含む現実空間をアプリ内に再現することがでました。あとは、カメラから見た時に遮蔽物によって物体が隠れて見えるように、その部分の描画を無効にします（これをオクルージョンカリングと呼びます）。こうすることで、キャラクターが遮蔽物の向こう側に存在しているかのように表現でき、実在感をより高めることができるようになります。

おわりに

今回はDevelopers Boostのフォローアップとして、今回講演した内容が実際にはどのように使われたのか、またこの技術が目指したコンテンツとはどのようなものだったのかについてご説明しました。

Cygamesは、ゲームに限らず最高のコンテンツを作ることをビジョンとしています。今までにない最高のコンテンツを作り上げ、最高の体験をユーザーに届けるためにはどうしたらよいか。Cygamesでは、そんなテーマを一緒に追求していけるエンジニアを募集しています。ご興味のある方は、こちらをご覧いただければと思います。

こんにちは。サーバーサイドエンジニアサブマネージャーの星野と申します。

Cygamesでは、毎週木曜日に「スキルサーズデー」という社内勉強会を開催しています。スキル向上や知識の共有を目指し、業務で得られた知見を講演形式で発表するイベントです。過去にも紹介しておりますので、そちらも併せてご参照ください。

有志のスタッフが運営しており、発表・聴講ともに誰でも参加できます。元々はエンジニアが中心になって始めたものですが、今ではエンジニアだけでなく、プランナーやデザイナーなども参加して、多岐にわたる内容が発表されています。講演テーマは基本的に自由で、話したいことがある人が自主的にエントリーするのですが、予定が数カ月先まで埋まるくらい活発な運営が続いています。

このスキルサーズデーでは、外部から専門家を招いて講演していただくこともあります。今回は、タワーズ・クエスト株式会社の代表で、「テスト駆動開発」のエバンジェリストである和田卓人さんをお招きしました。

Cygamesでは一部プロジェクトでユニットテストを導入しているのですが、社内でテスト文化への理解をより広く推進したい意図から、和田さんに講演をお願いました。

テスト駆動開発の理解を深める

テスト駆動開発（TDD）とは、「テストファースト」を主眼とする開発手法です。テストファースト、つまりプログラムの実装前にテストコードを書き、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させていくという工程を繰り返すスタイルです。テストコードを先に書くため、実装するプログラムが持つ役割への理解が深まる、デバッグの時間を短縮できる、バグそのものを減らせるといったメリットがあります。

社内の広めのセミナールームを用意したにもかかわらず、当日は満席に。その道のスペシャリストの話を生で聞ける機会ということで、みんな熱心に聞き入っていました。セッション後の質疑応答も活発で、知識を吸収したいという意欲が伝わってきました。

まとめ

長期運用中のプロジェクトコードについて、いきなりすべてのテストを書くことは難しいところですが、書けるところから少しずつでもテストを書いていくという意識が芽生え、テストファーストの文化が育っていけばと思います。今回の講演が好評だったので、再度和田さんにおいでいただき、次はより実践的なお話をしていただけたらと考えています。

Cy#の河合です。昨年12月に、『MagicOnion』というライブラリのリリースを告知しました。今回、再びオープンソースライブラリとして、C#のためのCLI/Batchライブラリをリリースしました。

[GitHub – Cysharp/MicroBatchFramework]

.NET CoreになってWindows／Mac／Linux問わずクロスプラットフォームなアプリケーション開発環境として機能するようになったC#ですが、そして機能的には十分揃っているのですが、ちょっと気の利いたフレームワークは意外と欠けているところがあります。バッチ・コマンドラインアプリ。というと地味なトピックスですが、ゆえに基本機能以上のサポートがなかったりします。しかし、「C#の可能性を切り開いていく」という理念を掲げるCy#としては、派手・地味を問わず、現状のC#に欠けているものを埋めていくことで、C#がアプリケーションを作る環境として、より良いものなるようにしたいと思っています。

CLIツールのためのフレームワーク

すでにC#にはコマンドライン引数の解析ツールはたくさんあります。とはいえ、そもそもそういうツールを使う時は「コマンドライン引数の解析」がしたいわけではなくて、「パラメータバインディング」をしたいのが一般的と思われます。ということで、『MicroBatchFramework』はウェブフレームワークのようにメソッドを呼び出してくれる仕様にしました。

class Program
{
    static async Task Main(string[] args)
    {
        // エントリポイント。この1行でフレームワークのStartup設定は終わりです。
        await BatchHost.CreateDefaultBuilder().RunBatchEngineAsync<MyFirstBatch>(args);
    }
}

// 実際のバッチの定義
public class MyFirstBatch : BatchBase // BatchBaseを継承してもらって
{
    // void(同期)かTask(非同期)の戻り値が設定可能、パラメータはどんな型も自由(JSONからマッピングします)
    public void Hello(string name, int repeat = 3)
    { 
        for (int i = 0; i < repeat; i++)
        {
            this.Context.Logger.LogInformation($"Hello My Batch from {name}");
        }
    }
}

これは `SampleApp.exe -name “foo” -repeat 5` で呼び出すことが可能、という仕様です。

// 引数に別名や説明をつけたり
public void Hello(
    [Option("n", "name of send user.")]string name,
    [Option("r", "repeat count.")]int repeat = 3)
{
    // ...omit
}

// サブコマンドの作成や、引数順番でもバインディングなどをサポート
[Command("escape")]
public void UrlEscape([Option(0)]string input)
{
    Console.WriteLine(Uri.EscapeDataString(input));
}

煩わしい定型的な引数の解析に悩まされることなく、メソッドだけ定義すれば、あとはすべてよしなにやってくれます。

.NET Coreで作成したアプリは、ランタイムのインストールも不要な実行ファイルを Windows／Linux／Mac向けに作ることができます。また、CIに関してもCircleCIのようなコンテナベースのCIを、他の言語と遜色なく利用することが可能です。例えば以下のような記述で、実行ファイル生成をCIに任せられます。

version: 2.1
executors:
  dotnet:
    docker:
      - image: mcr.microsoft.com/dotnet/core/sdk:2.2
    environment:
      DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
      NUGET_XMLDOC_MODE: skip
jobs:
  publish-all:
    executor: dotnet
    steps:
      - checkout
      - run: dotnet publish -c Release --self-contained -r win-x64 -o ./MicroBatchSample/win-x64
      - run: dotnet publish -c Release --self-contained -r linux-x64 -o ./MicroBatchSample/linux-x64
      - run: dotnet publish -c Release --self-contained -r osx-x64 -o ./MicroBatchSample/osx-x64
      - run: apt update && apt install zip -y
      - run: zip -r MicroBatchSample.zip ./MicroBatchSample
      - store_artifacts:
          path: MicroBatchSample.zip
          destination: MicroBatchSample.zip
workflows:
  version: 2
  publish:
    jobs:
      - publish-all

この辺りは、もはやC#だからといってWindowsに縛られたり、使えるシステムに制約があったりということはなく、自由に組み合わせていくことができる証左と言えるでしょう。

また、配布に関しては.NET CoreグローバルツールというNPM Global Toolsのような仕組みも用意されています。例えば以下のようなUlid生成のためのツールをMicroBatchFrameworkと.NET Coreグローバルツールで作ってみました。

これにより、dotnetコマンドが使える環境に対するCLIツールの配布、管理が容易になっています。

バッチのためのフレームワーク

C#とバッチはけっこう相性が良いと思っています。その最たるところは並列処理で、とりあえず実行時間かかりそうなものはParallelにするだけで、バッチ突き抜け率を大幅に低減することができます。

// これを
foreach(var item in foo)
{
// なんかたくさん処理する
}

// こうするだけ
Parallel.ForEach(item =>
{
// なんか色々やる
});

というのはともかく、実際にプロダクトで使うバッチ処理は複数、むしろ山のように用意することがほとんどだと思います。それらを単一のコンソールアプリケーションで効率よく管理できるように、クラスとメソッドを定義するだけで出し分けられるシステムを用意しました。

class Program
{
    static async Task Main(string[] args)
    {
        // <T>を渡さないと複数検索モードになる
        await BatchHost.CreateDefaultBuilder().RunBatchEngineAsync(args);
    }
}

// こんなクラスや
public class Foo : BatchBase
{
    // こんなメソッドや
    public void Echo(string msg)
    {
        this.Context.Logger.LogInformation(msg);
    }
    // こんなメソッドを
    public void Sum(int x, int y)
    {
        this.Context.Logger.LogInformation($"{x + y}"); 
    }
}

// こんなクラスを
public class Bar : BatchBase
{
    public void Hello2()
    {
        this.Context.Logger.LogInformation("H E L L O");
    }
}

このように、第1引数によって実行するメソッドを切り替えられます。

SampleApp.exe Foo.Echo -msg "aaaaa"
SampleApp.exe Foo.Sum -x 100 -y 200
SampleApp.exe Bar.Hello2

さて、こうして出来たアプリケーションは、コンテナ化するのをお薦めします。.NET CoreならばC#でもコンテナ化は簡単です。

FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS sdk
WORKDIR /workspace
COPY . .
RUN dotnet publish ./MicroBatchFrameworkSample.csproj -c Release -o /app

FROM mcr.microsoft.com/dotnet/core/runtime:2.2
COPY --from=sdk /app .
ENTRYPOINT ["dotnet", "MicroBatchFrameworkSample.dll"]

例えばこれをAWS ECRにCircleCIで上げるなら、以下のようなコンフィグになるでしょう。

version: 2.1
orbs:
  aws-ecr: circleci/aws-ecr@3.1.0
workflows:
  build-push:
    jobs:
      # see: https://circleci.com/orbs/registry/orb/circleci/aws-ecr
      - aws-ecr/build_and_push_image:
          repo: "microbatchsample"

非常にシンプルに書けるし、C#だからといって特別なことはなく、一般的なエコシステムに乗っているわけです。

こうして上がったコンテナは、あとはただのコンテナなので好きなように実行すればいいわけですが、例えばAWS Batchを使えば比較的シンプルに実行もスケジューリング（CloudWatchでイベントトリガを設定可能）も定義可能です。そして、ログはCloudWatchで標準出力が確認できます。

複雑なワークフローを定義したい場合は、別途LuigiやApache Airflowが使えるはずです。

Swaggerによるウェブインターフェイス

開発時など、いちいちコマンド打って確認するのも面倒な場合もあるため、ウェブでホストする機能を付けました。スタートアップとして`RunBatchEngineAsync`の代わりに`RunBatchEngineWebHosting`を使うだけです。

public class Program
{
    public static async Task Main(string[] args)
    {
        await new WebHostBuilder().RunBatchEngineWebHosting("http://localhost:12345");
    }
}

これはSwaggerによってホストされるため、実行確認等が容易になります。

MicroBatchFrameworkの.NET的な新しさ

.NET Generic Hostの上にコンソールアプリケーションを構築するというのが、MicroBatchFrameworkの新しさです。

.NET Generic Hostは、標準的な仕組みとしてロギング／コンフィグ読み込み／DIをサポートしています。これによりコンフィグのマッピング、ロギングなどを標準的な作法でフルサポートしています。

// appconfig.json
{
  "Foo": 42,
  "Bar": true
}

class Program
{
    static async Task Main(string[] args)
    {
        await BatchHost.CreateDefaultBuilder()
            .ConfigureServices((hostContext, services) =>
            {
                // mapping config json to IOption<MyConfig>
                services.Configure<MyConfig>(hostContext.Configuration);
            })
            .RunBatchEngineAsync<MyFirstBatch>(args);
    }
}

public class MyFirstBatch : BatchBase
{
    IOptions<MyConfig> config;
    ILogger<MyFirstBatch> logger;

    // get configuration from DI.
    public MyFirstBatch(IOptions<MyConfig> config, ILogger<MyFirstBatch> logger)
    {
        this.config = config;
        this.logger = logger;
    }

    public void ShowOption()
    {
        logger.LogInformation(config.Value.Bar);
        logger.LogInformation(config.Value.Foo);
    }
}

これをやっているフレームワークって意外とないのです（なぜなら.NET Generic Host自体が最近出来た仕組みなので）。この辺りもまた「現状のC#に欠けているものを埋めていく」ということです。

まとめ

C#でも存外CLIツールを書きやすいな、と思ってもらえるとうれしいですね！ ちゃんと全プラットフォームで動くので、C#でCLI書くのは大いにアリです。そしてまた、C#でも特別なことはなくCircleCIやDockerなどの普通のエコシステムに乗れているということが伝わるとなおうれしいです。

個人的には、サーバーレス(FaaS)は縛りがキツすぎて自由なアプリケーション開発にならないためあまり好きではありません。インフラを気にしたくないのは事実ですが、余計なSDK、ローカル開発におけるエミュレーターやランタイムによる起動の遅さなど、デメリットが多いと感じています。

理想は、シンプルなコンソールアプリケーションで書いてコンテナ化して、それがインフラを気にせず動いてくれるということであり、そしてその中で私がアプリケーション開発者として何よりも優先したいのが「シンプルなコンソールアプリケーション」であること。インフラ面ではAWS Batchのようなフルマネージドなものから、ちょっと学習も必要ですがマネージドKubernetesが主要クラウドサービスでは使えることもあり、理想的なイメージに近づいてきている印象があります。

FaaSに関しては、FaaSだからこそシンプルに実現できること以上のことはやりたくないし、そうじゃないやり方のために MicroBatchFrameworkが助けになれればと思っていますので、ぜひお試しください！

また、Cy#では、こうした次世代のC#の研究を「.NET Core」と「Unity」を主軸に行っています。ご興味のある方は、まずは私宛てにお問い合わせください。

Cy#の河合です。今回、『UniTask』という新しいUnity用の非同期処理ライブラリを公開しました。

[GitHub – Cysharp/UniTask]

新規公開、ではありますが、実は新しいわけではなく、元々UniRxの機能として公開していたものを、分離したものとなります。併せてUniRxも更新していて、お互いに依存が一切ない独立したものになっています。

概要に関しては、以前に公開した以下のスライドで詳しく述べていますが、改めてまとめてみます。

async/awaitまでのC#/Unityの非同期処理

一般に、非同期処理はコールバックで完了後のメソッドを呼び出す形で実装できます。Unityも例外ではなく多用されていますが、

• 複雑な処理でネストが多重になる
• その際、内側の例外は外側には伝搬されない
• 処理順序がコードから見えなくなる

といったような、いわゆるコールバック地獄に陥ります。代わりに、Unityではyield return（ジェネレーター）で実現しているコルーチンで非同期処理を行うことができます。このUnityにおけるコルーチンでは非同期処理がシーケンシャルに書けるという利点がある一方、

• 起動におけるMonoBehaviourとの結合
• 戻り値の伝搬
• 例外の伝搬
• 複数コルーチンのコントロール（直列／並列処理）

といった欠点があります。そこで互いを補うため、長くなる複雑な処理をコルーチンで書きつつ、値の伝搬をコールバックで行い、なるべくネストは深くならないようにする、といったような対応を取ってきたと思います。

UniRxは、そうした非同期処理の複雑さを緩和するために導入できます。ただし、

• 機能が強力すぎるため、パズルのような複雑さを招いてしまいがち
• IObervableだけではイベント（長さ∞）か非同期（長さ1）なのか判別できない
• 結局、手続き的に書けないため、記述のわかりやすさでは劣る

といった副作用もあり、銀の弾丸とはなり得ません。

これら「コールバック・コルーチン・Rx」の欠点を解決するasync/awaitは、言語機能として「同期処理のように非同期処理を書ける」ように設計されていて、Rxとの使い分けとして以下のようなマトリクスが書けます。

同期の単一戻り値の処理は、ただのメソッド呼び出しですが、非同期の単一戻り値は、それにawaitを書くだけです。そして同期の複数戻り値の処理をforeachでやるように、イベント処理をRxでやることで、自然な使い分けができるでしょう。

C# 8.0からはAsyncEnumerableというものが導入されて、非同期foreachが可能になります。Rxとの違いは、AsyncEnumerableがPull型の非同期シーケンス処理で、IObservableがPush型の非同期シーケンス処理ということになります。

async/awaitにより、

• 手続き的に書けて、ネストは消える
• 戻り値も例外処理も同期処理のように自然に扱える

まさに理想的な記述ができるようになりました。ただし、何の副作用もない処理は存在しないように、async/awaitの欠点として

• 非同期型を呼び出すメソッドは全てTask（またはそれに準ずる型）になる

という、「非同期汚染」と呼ばれる状態にはなり得ます。

UniTaskとUnity

Unityは既に最新バージョンのC#をサポートし、async/awaitを十分使える状態にありますが、フレームワーク側での対応が一切なされていないため、そのままでは実用化はできません。UniTaskではコルーチンで行えたことを全て行えるようにすることを目標に、多数の拡張を実装しています。

// Unityの非同期オブジェクトをそのまま待てる
var asset = await Resources.LoadAsync<TextAsset>("foo");

// .ConfigureAwaitでプログレスのコールバックを仕込んだりも可能
await SceneManager.LoadSceneAsync("scene2").ConfigureAwait(Progress.Create<float>(x => Debug.Log(x)));

// 100フレーム待つなどフレームベースの待機
await UniTask.DelayFrame(100); 

// WaitForSeconds/WaitForSecondsRealtimeの置き換え
await UniTask.Delay(TimeSpan.FromSeconds(10), ignoreTimeScale: false);

// yield return WaitForEndOfFrameの置き換え、yield return null, yield return WaitForFixedUpdateの置き換えもYieldで可能
await UniTask.Yield(PlayerLoopTiming.PostLateUpdate);

// IEnumeratorなコルーチンも待てる
await FooCoroutineEnumerator();

// yield return WaitUntilのようなことも可能
await UniTask.WaitUntil( () => isActive == false);

// これより下の処理をスレッドプールで実行させるというマルチスレッド化
await UniTask.SwitchToThreadPool();

// こんなようなUnityWebRequestの非同期Get
async UniTask<string> GetTextAsync(UnityWebRequest req)
{
    var op = await req.SendWebRequest();
    return op.downloadHandler.text;
}

var task1 = GetTextAsync(UnityWebRequest.Get("http://google.com"));
var task2 = GetTextAsync(UnityWebRequest.Get("http://bing.com"));
var task3 = GetTextAsync(UnityWebRequest.Get("http://yahoo.com"));

// 並列実行して待機、みたいなのも簡単に書ける。そして戻り値も簡単に受け取れる。
var (google, bing, yahoo) = await UniTask.WhenAll(task1, task2, task3);

// タイムアウトも簡単にハンドリング
await GetTextAsync(UnityWebRequest.Get("http://unity.com")).Timeout(TimeSpan.FromMilliseconds(300));

UniTaskをインストールしたら、すぐに思いついたところをasync/await化することができるように構築しています。

UniTask vs Task

標準のC#ではasync/awaitの戻り値としてTask<T>が使えますが、UniTaskではパフォーマンスとUnityの親和性を高めるために、汎用性が重視された標準のTaskは使わずに、Unity専用に軽量化したUniTask<T>を用いています。これはC# 7.0から追加されたAsyncMethodBuilderの実装により実現しました。

• ExecutionContext/SynchronizationContextを使わない（オーバーヘッド低減）
• 値型のため内部が同期的に完了する場合はゼロアロケーション
• PlayerLoopを拡張した独自のUnityコルーチン風のメソッド郡
• 独自のトラッキングウィンドウ拡張によりリーク防止

これらにより、UniTaskなしでasync/awaitを使う場合に比べて遥かに多くの利点を提供しています。

まとめ

既に正式版のリリースされているUnity 2018.3以降は、標準でC# 7.0をサポートしたこともあり、制約なくasync/awaitを使っていくことができます。しかし、まだきっちり使いこなせているところは少ないのではないでしょうか。UniTaskが、本格導入のための手助けになってくれれば幸いです。

また、Cy#では導入にあたってのサポート、コンサルティングもお請けできますので、ご興味がありましたら[Cy# – お問い合わせフォーム]よりコンタクトください。

Cy#の河合です。今回新しくオープンソースライブラリとして、マスターデータの管理用途を主眼に置いた、読み取り専用のインメモリデータベースを公開しました。

[GitHub – Cysharp/MasterMemory]

今までのゲーム開発の経験から、「省メモリ（インメモリということもあり使用メモリ量には気を使う」「高速なデータベースロード（構築に時間がかかるとゲームの起動速度に大きく影響する）」「高速な検索（ディクショナリのルックアップと同程度のクエリ）」の３点を重視して作りました。以下がベンチマークの結果となります。

MasterMemory、SQLite、LiteDB、RocksDBがインプロセス、Memcachedのみ別プロセスのマシン内通信による比較です。SQLite（ファイル読み込み型）の4700倍高速で、1クエリでのアロケーションはゼロです。また、保存時のファイルサイズも極小です（十分小さい場合、更新があった場合に丸ごとCDNに載せて置き換えるだけにする、などで運用が楽になります）。

Unityで使用できるほか、サーバーサイドでも .NET Coreアプリケーションでも同様に活用できます。サーバー利用時の比較として同一マシン上にMemcachedを立てて通信するような場合とも比較しましたが、もちろん圧倒的に高速です。

「すべてインメモリの読み取り専用」と割り切ることにより内部構造がシンプルになり、これにより、クエリのための中間オブジェクト生成、通信、データのデシリアライズ、インデックスと実データの結合、ロックなど、多くの処理を省くことが可能になっています。また、単純なインプロセスのハッシュテーブル（Dictionary）と比べても、使用メモリ量が少なく、構築時間が早く、「レンジ検索、近傍検索、複数キー、セカンダリインデックス」といった多くの機能を持つなど、より良い性能特性を持ちます。

同じようなコンセプト（embeddable write-once key-value store）としてLinkedInが開発したPalDBというものがありますが、実装も性能特性も全く異なります。

完全な型付け

C# to C#によるコード生成によって、データベースへの操作は完全に型付けされています。

public enum Gender
{
    Male, Female, Unknown
}

// 要素のクラスを作る
[MemoryTable("person"), MessagePackObject(true)]
public class Person
{
    // 属性でインデックスを定義する
    [PrimaryKey]
    public int PersonId { get; set; }
    [SecondaryKey(0), NonUnique]
    [SecondaryKey(1, keyOrder: 1), NonUnique]
    public int Age { get; set; }
    [SecondaryKey(2), NonUnique]
    [SecondaryKey(1, keyOrder: 0), NonUnique]
    public Gender Gender { get; set; }
    public string Name { get; set; }
}

// ---

var db = new MemoryDatabase(File.ReadAllBytes("db.bin"));

// .PersonTable.FindByPersonIdもコード生成により型が付いてる
Person person = db.PersonTable.FindByPersonId(10);

事前の自動生成ベースにすることは、APIとしての使い勝手の向上のほか、性能特性の改善にも寄与しています。

欠点は、必ずコード生成という煩わしい手段が必要になることです。コード補完など、型が付いていたほうが利便性が高くなり、もし自動生成しないと、安全性が欠けたうえに手書きコード量が多くなると考え、コード生成を前提にしています。また、Unityの場合は内部データの保持にMessagePack for C#を使っている都合上、そちらでのシリアライザ自動生成も必要になっているので、どうせ一つやるならもう一つ追加で、といった精神も少しあります。

検索手段には柔軟性があり、非ユニークの場合はRangeView<T>という範囲を表すコレクションが取得できるほか、多値をキーにする、範囲検索する、近くの値を検索するなどが可能になっています。

// .PersonTable.FindByPersonIdもコード生成により型が付いてる
Person person = db.PersonTable.FindByPersonId(10);

// 女性の23歳を取得。戻り値は複数。
RangeView<Person> result = db.PersonTable.FindByGenderAndAge( (Gender.Female, 23));

// 31歳に最も近い人を取得
RangeView<Person> age1 = db.PersonTable.FindClosestByAge(31);

// 20歳から29際の人を取得
RangeView<Person> age2 = db.PersonTable.FindRangeByAge(20, 29);

有効なインデックスにはすべて型が付いているため入力補完に従うだけで対応できるほか、誤ったクエリを書いてしまう可能性もありません。

ジョインに関しては、クエリが非常に高速なのでLINQ to ObjectsでDictionary感覚で使って結合してしまって構いません。

var result = responses
    .Select(x => new
    {
        Name = db.MonsterTable.FindById(x).Name,
        x.Level,
        Power = db.MonsterPowerTable.FindById(x).Power
    });

といったような具合です。

理論上最小のメモリ使用量と自動インターン化

実際にメモリ中に保持し、使用するデータ（T）は、データベース構築時にヒープ上に生成されます。そして、実データの集合（T[]）以外のデータは保持しません（セカンダリインデックスを使用しない場合）。つまり、この場合のメモリ使用量は理論上最小となります。

また、データベース構築時に文字列は自動でインターン化するため、データ中に非正規化されている文字列データが存在する場合、他の手法に比べて圧倒的に省メモリとなっています。

例えば、

というようなデータがある場合、「ゴブリン」という文字列は、メモリ中に5つが個別に存在します。つまり「ゴブリンゴブリンゴブリンゴブリンゴブリン」というサイズのメモリを使っています。しかし、同一文字列であることはわかっているので、メモリ中に1つの文字列とその参照だけで済むはずです。それを解決する手法が文字列のインターン化で、インターン化するとたとえ10000個の「ゴブリン」という文字列が出現しても、1つ分のメモリだけで済みます。

非常にアグレッシブな手法ですが、MasterMemoryは、一度構築したらアプリケーションの生存期間中はずっと不変で保持し続けるためのデータベース、という前提を持っているため自動でインターン化しても問題は起こりません。

実装面ではMessagePack for C#の柔軟なカスタマイズ性を生かして、データベース構築時 = デシリアライズ時に処理をフックしています。もちろん、自動インターン化は無効にすることも可能です。

差分更新

データベース自体は読み込み専用ですが、更新データを別途受信した際に、差分から新しいデータベースを作成することができます。

// 元のデータからBuilderを作り
var builder = db.ToImmutableBuilder();

// PrimaryKeyで比較して差分のみ追加/置換したり
builder.Diff(addOrReplaceData);

// PrimaryKeyで削除したり
builder.RemovePerson(new[] { 1, 10, 100 });

// そもそもまるごと入れ替えたりして
builder.ReplaceAll(newData);

// 新しいデータベースが作れます
var newDatabase = builder.Build();

例えばゲームのリアルタイム通信（弊社開発のMagicOnionのようなサーバーアプリケーション)を実装している際に、マスターデータの更新があってグローバルのマスターデータは更新したい、けれど1ゲーム内のデータは前のデータのまま使っておきたい、といった場合に、グローバルに保持しているデータベースを都度参照せずに、参照を保持しておけば、差分更新によって作られる幾つものバージョンのデータベースを保持し続けられます。

// 1ゲームにつき1つのManagerインスタンスとした場合
public class GameManager
{
    MemoryDatabase database;

    // 1ゲーム開始時に、「その時点」でのデータベースを確保して使う
    public GameManager(MemoryDatabase database)
    {
        this.database = database;
    }
}

グローバルなデータベースはDIコンテナのシングルトンか、静的プロパティか、何れにせよシングルトンで保持しておくと良いでしょう。

まとめ

大仰にセールストークをしましたが、実態はなんてことはなく、ただの「ソート済み配列」を「二分探索」しているだけ、です。データベースの構築が高速なのは、シリアライズされたソート済み配列をデシリアライズするだけで完了するからであり、メモリ効率が良いのは、保持しているのが実体の配列のみだからです。

それをAPI面でデータベースライクに使えるように整理していること、（最も多いユースケースであるプライマリインデックスでのプリミティブキー検索時に）C#的な実装上の工夫によりハッシュテーブル引きに近い速度を叩き出していること、C#最速のバイナリシリアライザであるMessagePack for C#の活用による高速な展開やバイナリサイズの縮小を果たしていること、などの工夫によりデータベースとしてパッケージングしています。

とはいえ、そうした見せ方というのは大事な話で、MasterMemoryの存在によって、マスターデータの取り扱いについて一定の答えを示せたのではないかと思います（少なくともパフォーマンス的に厳しいものが選択肢に上がるのはなくなって欲しい……）。別にDictionaryで良くね？ という点に関しては、ゲーム開発が進んでマスターデータが巨大になった場合に、構築に時間がかかる（ハッシュテーブルを作るコストは意外と安くない）ことと、メモリ使用量（ハッシュテーブルはデータ構造としてはかなり大きめ）、そして検索が1:1のKeyValueのみで柔軟性がないこと（困ったら全件検索、が多発するとかなり効率悪い）が、以前のゲーム開発ではネックになっていました。

クライアント用途（Unity）、サーバー用途（.NET Core）ともに耐えうる仕様ですので、ぜひお試しを。どちらか片方でも十分使えますが、両方合わせると、取り得るアーキテクチャの選択肢の幅が広がるので、そちらも検討してもらえれば幸いです。また、Cy#では導入にあたってのサポート、コンサルティングもお請けできますので、ご興味がありましたらCy# – お問い合わせフォームよりコンタクトください。

皆さまこんにちは。
ゲーム開発者向けの一大イベントである『CEDEC 2019』が、2019年9月4日（水）～9月6日（金）の3日間、パシフィコ横浜で開催されます。例年通り、Cygamesの開発陣もセッションに登壇しますので、CEDECに参加予定の方はぜひチェックしてください。以下に、各セッションの概要をタイムスケジュール順にご紹介します。

Shadowverseのeスポーツ展開 —ゲームがつなぐコミュニティと地域活性化について—

日本最大規模の本格スマホeスポーツタイトル『Shadowverse』において、これまでに実施したオフラインイベント（大会）と、それによる地域やコミュニティへの波及効果に関する講演です。全国で定期的にイベントを行うための、地域を巻き込んだ施策のノウハウをお伝えします。

• 日時：9月4日（水） 13:30 〜 14:30
• 登壇者：松本竜也
• 詳細

日々の業務から少しずつ始める！TA育成について話すラウンドテーブル

一昨年のCEDECから続く、TAの育成をテーマとしたラウンドテーブルです。今年はこれからTA目指す人、TAを育てる人の両方に有用な内容となっています。実業務へのアサインを通じてのTA育成に焦点を当て、どのような業務へアサインすることがTAとしての知見を深めることにつながるのかを、業界を代表するゲーム会社から集まった7名の登壇者が議論します。

• 日時：9月4日（水） 14:50 〜 15:50
• 登壇者：脇田 卓（ほか6名）
• 詳細

グランサイファーライド制作事例 〜体験型アトラクションはオブジェクトベースのマルチチャンネル音響で攻略せよ！〜

ゲームオーディオとアトラクション音響の次世代融合事例として、体験型アトラクション『グランサイファーライド』のサウンドシステムを紹介するセッションです。40個超のスピーカーを配置し、「d&b Soundscape」を中核とした64chオブジェクトベースの多チャンネル音響という、世界でも類を見ない規模のシステムを解説します。

• 日時：9月4日（水） 16:30 〜 17:30
• 登壇者：丸山雅之、屋敷貴道（ほか1名）
• 詳細

スマホゲームリリース時に絶対サーバを落とさないための負荷試験

負荷対策に関する体系的な知識を提供するセッションです。事前に負荷予測をし、負荷試験を行い、仮に予測以上のアクセスがあってもスケールできる設計にすることで、タイトルのローンチ時に「負荷で絶対落とさないサーバ」を実現するためのノウハウをお伝えします。

• 日時：9月5日（木） 10:00 〜 11:00
• 登壇者：伊藤英知
• 詳細

モバイルゲームのテキスト作成術 ～シナリオ外のテキストで魅せるには？～

モバイルゲームにおけるテキストを分類し、種類に応じた作成の仕方を実例を交えて解説する講演です。ゲームの世界観を伝えるツールとして、シナリオ以外のフレーバーやカードコメントといった細かなテキストに着目し、その作成方法を紹介します。

• 日時：9月5日（木） 11:20 〜 12:20
• 登壇者：坂本正吾
• 詳細

個性的で魅力的なモンスターを量産するためのデザインの秘訣と開発手法紹介 ～プリンセスコネクト！Re:Diveにおけるモンスターデザイン制作事例～

『プリンセスコネクト！Re:Dive』の開発事例を通じ、個性的なモンスターを効率的に生み出す制作手法・開発体制について、ビジュアル・モーションの2つの観点で紹介する講演です。また、モーションデザインにおける緩急をつけたわかりやすさ、爽快かつ華やかな印象を維持した上での物量の最適化を実現したノウハウも披露します。

• 日時：9月5日（木） 13:30 〜 14:30
• 登壇者：野西正武、高 泰俊
• 詳細

Shadowverse流開発手法 ～QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発～

デジタルカードゲームにおける、QAコストの大幅削減を実現する開発手法を紹介するセッションです。膨大なカード組合せ数によるQAコストが課題となっていた『Shadowverse』の開発現場において、プランナー主体のテスト駆動開発で取り入れたツール群やビルド環境、これらを実現するための考え方について語ります。

• 日時：9月5日（木） 14:50 〜 15:50
• 登壇者：柴田有輝、鄒 一舟
• 詳細

「現場最優先のススメ」 ～最高の開発環境を生み出す情報システム部門の在り方～

業務基盤を支える情報システム部門が、ヒットタイトルの様々な要求に対して、どのようにして迅速に対応しているかを事例を交えて紹介する講演です。開発現場の要求に対して迅速に対応できる体制作りと、そこから見えてきた「ゲーム会社における情報システム部門の在り方」について語ります。

• 日時：9月5日（木） 16:30 〜 16:55
• 登壇者：平内義彦
• 詳細

プリンセスコネクト！Re:Dive運用事例 ～リリースの高頻度化と安定化を両立させるプリコネRの運用体制～

高頻度の更新を考慮したアプリ設計や、CIを用いた大量に存在するリソースファイル・開発環境・ブランチ管理コスト改善などの取り組みを紹介する講演です。『プリンセスコネクト！Re:Dive』の運用において、いかにして極力メンテナンスに入らないようにしつつ、イベント等のリリースにおいて大量のファイル・環境の更新を実現していったかをお話しします。

• 日時：9月6日（金） 11:20 〜 12:20
• 登壇者：冨田康之
• 詳細

AAAタイトル開発における、ハイエンドオーディオ制作技術の研究成果と取り組み事例

ワールドワイドに向けたAAAタイトルに必要なゲームオーディオ制作技術について、Cygamesでの研究成果と取り組み事例を紹介する講演です。単一音源の複数地点でのIRをサンプル化して距離減衰・遮蔽に用いる手法や、世界に発信できる楽曲の制作における楽器収録・TDでの課題と解決案などについてお伝えします。

• 日時：9月6日（金） 13:30 〜 14:30
• 登壇者：牧村亮治、安井裕一、久保早瑠菜
• 詳細

プロシージャルゲームコンテンツ制作ブートキャンプ 2019 Part 2 機械学習

高生産性、高品質性を促進する「プロシージャル法」に関する2コマ連続のセッションの第2部です。第1部で紹介したバリエーション作成に続いて、プロシージャル法を用いた機械学習モデル生成までの概要、そしてゲームコンテンツ制作への応用を紹介します。

• 日時：9月6日（金） 14:50 〜 15:50
• 登壇者：岸川貴紀（ほか2名）
• 詳細

フォトグラメトリーとプロシージャルを用いた最新ハイエンドゲーム3DCG背景制作手法 ～ハイエンドゲーム開発の経験がない会社がいかにしてそれらを生み出したか～

現実の風景と錯覚するような写実的な背景制作をテーマに、ハイエンドゲーム制作の経験がない会社がそれらを実現可能にした制作手法とノウハウを紹介するセッションです。フォトグラメトリーとプロシージャルの融合、および伝統的な背景制作のノウハウの活用について語ります。

• 日時：9月6日（金） 16:30 〜 17:30
• 登壇者：吉冨直隆
• 詳細

以上、Cygamesスタッフの登壇セッションの概要をお届けしました。CEDEC終了後にはセッション登壇者からのフォローアップ記事も展開する予定ですので、どうぞご期待ください！

サーバーサイドエンジニアサブマネージャーの崔です。
少し前のことになりますが、テスト駆動開発（TDD）のエバンジェリストである和田卓人（@t-wada）さんを講師としてお招きし、1日かけてレガシーコード改善ワークショップを開催しました。

和田さんには以前にも、社内でテスト文化への理解を広めたいという意図もあり講演をお願いし、非常に好評だったため、今回はより実践的なワークショップを開催することにしました。

私たちが長期にわたって運用を続けるゲームタイトルは、機能追加や改善を繰り返し、システムが大規模かつ複雑になってしまいます。開発のスピードとプログラム品質の両立に影響するため、これらを改善する取り組みのひとつとして、テストを活用して開発効率を上げたいと考えました。

そして、今回はより実践的なワークショップにするために、Cygamesで実際に運用しているゲームタイトルのソースコードを利用しました。和田さんと打ち合わせを重ね、不具合が発生しやすくテスト導入が困難な箇所も選定し、前半は頭で理解し、後半は体で理解するという2部構成で実施しました。

当日の流れ

◾︎前半（頭で理解編）
　　1.講義
　　2.ゲームタイトルのソースコードにテストを書く（ライブコーディング）

◾︎後半（体で理解編）
　　3.ゲームタイトルのソースコードにテストを書く（ペアプログラミング）
　　4.発表会（コードレビュー）

1.講義

最初の講義では、「どこにテストを書いていくか」という狙い目を具体的に説明していただきました。　

講義の様子。みんな真剣に聞き入っていました

2.ゲームタイトルのソースコードにテストを書く（ライブコーディング）

講義の後は、和田さんによるライブコーディング形式のデモです。プログラム内でもシステムの複雑化によって特にバグが出やすい機能を使ったデモなので、実際に起こり得るシチュエーションを元にテストコードの意義を確認できました。

3.ゲームタイトルのソースコードにテストを書く（ペアプログラミング）

続いて後半です。2人1組になり、和田さんが事前に用意くださった初級・中級・上級の課題をクリアしていきます。どのペアも会話をしながら楽しそうに課題に挑んでいるのが印象的でした。

ペアプログラミングでは、2名のエンジニアが相補的な関係となってテストを書きます

4.発表会（コードレビュー）

最後は、課題に対して効果的なアプローチをしていた2組による発表です。「どういうことを考えてこのテストコードを書いたか」という意図を説明し、それに対して質疑応答をしたり、和田さんからは良い点や改善すべき点を指摘していただいたりしました。レビューはかなり盛り上がり、予定を30分以上オーバーしました。

最後はコードレビュー。書いたテストを客観的に振り返ることができます

まとめ

後日、参加者にアンケートを取って勉強会の感想を聞いたところ、「実際のゲームタイトルのソースコードに対するテストの戦略や考え方を得られたのは良かった」など、ポジティブな回答が多く得られました。

ゲームはその内容が年々複雑になる傾向にあり、システムも同様に複雑になってきています。
Cygamesでは、ユーザーに快適に遊んでいただけるように、不具合ゼロに向けて様々な取り組みを試してきました。その取り組みの一つとして、テスト駆動開発も採用してきましたが、これまで苦労することも多くありました。

今回は、実践的なワークショップを通して「テストとどう向き合うか」を再認識することができました。テストの導入に苦労をしていると、いつの間にか、テストを書くことが目的にすり替わりがちです。そんな時には、「テスト駆動にこだわるな」「ユニットテストにこだわるな」「最初から全部やろうとするな」という和田さんのお話を思い出そうと思います。

また、テストは闇雲に書くのではなく、「最も困ってるところから書く」「新機能開発から書く」「バグ修正のところから書く」という考えを参考にしながら、安心してシステムの品質向上に取り組める環境づくりを推進していくつもりです。

このようにして、Cygamesの「最高のコンテンツを作る会社」というビジョンを体現すべく、テストを最大限に活用してさらに開発効率を上げ、品質の高いゲームをユーザーに提供し続けていきたいと考えています。

最後に、とても有意義なワークショップにしてくださった和田さん、どうもありがとうございました！

皆さまこんにちは。Cygamesでクライントサイドエンジニアを務めている冨田と申します。2019年9月6日（金）に開催されたCEDEC 2019にて、「プリンセスコネクト！Re:Dive 運用事例 ～リリースの高頻度化と安定化を両立させるプリコネRの運用体制～」という題名で講演を行いました。聴講いただいた方々には改めてお礼申し上げます。

今回は講演資料の公開と、講演後にいくつか質問をいただきましたので、フォローアップという形でご返答させていただきます。

資料の公開

当日の講演資料は下記となります。

Q: アプリバージョンごとにPrefabダウンロード専用のURLを用意しているとのことでしたが、アプリバージョンの切り替わりによって全リソースの再ダウンロードなどは発生しないのですか？

A： アプリバージョンが変わっても全リソースの再ダウンロードが発生しないよう、ファイル内容に差分がある場合のみリソース再ダウンロードが行われる処理をアプリ側に組んであります。講演ではスライド表示の都合上割愛しましたが、アセットバンドル名まで含めたダウンロードURLは下記のようになります。

https：//priconne/Ver1/assetbundle_a
https：//priconne/Ver2/assetbundle_a

「Ver1」「Ver2」部分はユーザーがインストールしているアプリのバージョンに応じて変わるため、結果ダウンロードURLも変わります。上記URLのようにVer1、Ver2にも「assetbundle_a」というリソースが存在していた場合、アプリアップデート時にこの「assetbundle_a」リソースを再ダウンロードするか否かは、同じ階層に配置している「resource_filelist」というファイルを基に決めています。

https：//priconne/Ver1/resource_filelist
https：//priconne/Ver2/resource_filelist

このファイル内には「ファイル名とファイルハッシュ値」を組みにした情報がリスト形式で保存されており、アプリはまずこのファイルをダウンロードしてきます。一度もダウンロードされていないファイルの場合は通常通りダウンロードを行い、既にダウンロード済みのファイルの場合はファイルハッシュ値に差分があった場合のみファイルをダウンロードしなおすようにアプリ側で処理が組まれています。「既にダウンロード済みか？ 最後にダウンロードしたファイルのファイルハッシュ値は何か？」という情報はアプリ側のローカルストレージに別途保存して管理しています。

※URLやファイル名は全て架空のものです。

※当日いただいた質問への回答にて「アプリバージョンが上がるとアセットバンドル名も変わる」と返答してしまいましたが、こちら回答に誤りがありました、大変申し訳ありません。URLアドレス上でアプリバージョンが上がると変わるのは、上記URLの「Ver1」「Ver2」の部分だけで、アセットバンドル名は変わりません。

Q: ブランチのマージ作業全般は誰がどのように管理を行っていますか？

A： 「リリース管理」という専任者を立ててマージ対応をしています。スライド内では「マージ担当者」という形で紹介していますが、実際にはブランチのマージに留まらず、ブランチ運用に関係するあらゆる作業を担当しています。開発全体を俯瞰し、進捗管理を行うのが「リリース管理」の主な作業です。具体的には、各種機能開発や不具合修正のスケジュール管理にはじまり、新規リリース用のブランチ作成、後続のリリース用ブランチへの伝播マージ、stagingチェックでのリソースビルドやサーバーデプロイ、などが作業内容として挙げられます。今回の講演でご紹介した様々な自動化・効率化は、実はこの「リリース管理」の負荷を減らすための取り組みも含んでいます。しかし、イベント開催時などの繁忙期には作業負荷が集中しやすいポジションでもあるため、マージ作業などを持ち回りで担当することもあります。

Q. Unityアップデート時のアプリ更新もメンテナンスフリーで行ったのですか？

A： はい、スライドでも紹介しているようにPrefabリソース、通常リソース、ともにUnity2017用、Unity2018用の2バージョンリソースを用意し、Unityアップデート対応を含んだアプリ更新もメンテナンスフリーで行いました。しかし、通常リソース側も2バージョン存在する状態での運用は、大量のリソースがどちらのバージョンにもきちんと過不足なく存在しているか（マージ漏れ等はないか）というブランチ管理上の問題や、本番環境へのリリースフローの複雑化など様々な困難が生じるため、こういった2バージョン管理状態は可能な限り回避する方針を取っています。

以上、いただいたご質問への返答となります。
みなさまのご参考になれば幸いです。

Cygamesゲームエンジニア／クライアントサイドの柴田です。
2019年9月5日（木）に開催されたCEDEC 2019にて、「Shadowverse流開発手法 ～QAコスト削減と堅牢性強化を実現するプランナーによるテスト駆動開発～」という講演を、弊社ゲームエンジニア／クライアントサイドの鄒とともに行いました。
講演にご参加いただいた皆様には、改めて御礼申し上げます。

本講演では『Shadowverse』を運用していく中で問題となったQAコストの増加と堅牢性の低下に対して我々がどのように対応したかを、AI開発、スキル開発に分けて解説させていただきました。
ここではフォローアップとして、講演後にいただいた質問に返答したいと思います。

Q：テストケース再生時は改めてAIの処理を呼び出すのか？

A：そうです。AIがプレイした結果が正解盤面と一致しないことは想定した動きを実現できないことを意味するので、NGとします。一部のスキル付与や盤面再現のために非AI側の行動も行いますが、その場合はスタート盤面と一緒に手順も記録して再生します。

Q：複数の正解がある場合はどうやってテストシナリオを作るのか

A：基本的に1つのテストケースに正解は1つしかありません。複数の正解があるということは、複数の性質の異なる行動プランを立てられることになり、そのケースに含まれる戦術が1つだけではないということになります。その場合、要件をさらに切り分けられるかをプランナーと一緒に考えます。

Q：テストのための要素切り出しが難しいのではないか？

A：おそらくエンジニアだけでは非常に難しいです。テストシナリオと同様に、AIとスキルのどちらにおいても実装段階からエンジニアとプランナーで協力をして各構成要素を細かく算出し、それらを使用したテストの仕組みの作成や実装を行っていく必要があるかと思います。

Q：AIを搭載していないゲームの場合自動テストのためにAIを作ることになると思うが、やるだけの価値はあるか？

A：やる価値は非常に高いと思います。運用が長くなってきたときやプロジェクトが大規模化してきたときなどに、何か修正や実装を加える際にエンジニアの心の余裕も生まれますし、影響範囲が広い修正や実装だったりすると、どうしても人力ではチェックが追いつかないところが出てくるので、そのサポートをする意味でもやったほうが良いです。
また、AIに関しては賢いものである必要はありません、最低限オートでバトルを実行できて、法則性を持った動きをしなければ十分テスト用としては機能すると思います。

以上、講演後に頂いたご質問へのご返答になります。
皆さんのご参考になれば幸いです。