イベント

2019.05.24

【イベントレポ:第2回DeNA×CA勉強会】両社のエンジニアが推進する技術的アプローチとは?

  • Facebookでシェア
  • Twitterでツイート
  • はてなブックマークでブクマする!
  • LINEで送る
  • follow us in feedly
  • Facebookでシェア
  • Twitterでツイート
  • はてなブックマークでブクマする!
  • LINEで送る
  • follow us in feedly

2019年3月27日、DeNA本社にて、DeNAとサイバーエージェントの二社合同でゲーム開発・運用技術に関する、若手向けのクローズドな勉強会&交流会が開催されました。

第二回目となる本勉強会のコンセプトは「若手のエンジニアが発表しやすい雰囲気の勉強会」となっており、DeNAとサイバーエージェント関連会社のエンジニアが2名ずつ、それぞれ約15分ほどのプレゼンテーションを実施しました。本記事ではその発表内容の一部をレポートします。

▼前回の勉強会の模様はこちら!

【イベントレポ】DeNA×サイバーエージェントのエンジニア合同勉強会に潜入!

DeNAマスタデータ管理システムOyakataの全容

DeNA開発基盤部の人西 聖樹から、マスタデータの編集・管理システム「Oyakata」の機能を中心に紹介するプレゼンが実施されました。

DeNA人西 聖樹DeNA 人西 聖樹

マスタデータについて

マスタデータとは、ゲームプランナーが主に編集する、ゲームのパラメータを設定するデータのことで、本勉強会ではレベルデザインに関するものはマスタデータと呼ばないことにすると、冒頭で人西は話しました。

DeNAの今のマスタデータ運用

DeNAの運用中タイトルについて、ゲームはUnity製、マスタデータの管理はGoogle Spread Sheet、Jenkins上でSpread Sheet->ゲームデータ(JSON)に変換、バージョン管理はgitおよびGithubをそれぞれ利用しており、主な制作フローも公開されました。そして、現状のフローでの課題点として、以下の3点が挙げられました。

課題1:並行での開発に対応できていない

現在のフローでは、複数のイベントを並行開発する際に、イベント間での編集の影響範囲が切り分けられず、前段でシート編集中の場合、後続の作業も影響を受けてエラーになっていまいます。

同じく、前段のイベント作業でエラーが出るような値を入力していると、後続も影響を受けてエラーになってしまいます。

課題2:実機確認までに時間がかかる

並行での開発に対応できないと、以下のような弊害が発生します。

・マスタデータのゲームデータへの変換がjenkins頼みになる
・jenkinsのビルドを長時間待たないと、入力したマスタをゲーム実機で確認できない

課題3:差分が見にくい

マスタデータの変更レビュー時や、変換後のデータをgithub上で差分の確認の際、JSONやCSVでのテキスト差分を肉眼で確認するのはとても見づらく、誤った編集の見落としの原因にもなっています。

Oyakataのおもな機能

上記で説明したような課題の解決のために、DeNAでは「Oyakata」というマスタデータの編集・管理システムを開発しています。構成するコンポーネントの機能の詳細は以下の通りです。

ビューワー(viewer)

Webアプリケーションでマスタデータを一覧で表示できる機能を持ち、テーブルを複数に分割して表示、分割したテーブルをまとめて表示。オーソドックスな検索機能で絞り込みも可能です。

編集履歴表示機能では、git likeなコミット単位でのバージョン管理が可能で、編集差分、リリースブランチの差分や、ブランチ間の編集の影響範囲の切り分けなどの表示が可能です。

エディター(editor)

マスタデータを編集する機能で、マスタデータのスキーマの作成・変更・削除ができます。マスタデータはWebおよびExcel上で作成・変更・削除ができ、編集したデータはゲーム上のデータに変換することが可能です。

編集したマスタデータをレビューする機能(いわゆるGithubのPull Request)では、見やすく、人間の目に優しい差分表示ができます。

コンバーター(converter)

マスタデータをゲーム用のデータに変換する機能で、CLIツールとして提供。今後JSONやFlatBuffers Protocol Buffersなど一通りのデータやフォーマットに対応する予定です。

この機能はプランナーのローカルPC上で実行できるので、実機確認をjenkinsを介さないで実施することが可能です。

バリデーター(validator)

マスタデータが正しいのかをチェックする機能で、CLIツールとして提供します。外部テーブルが存在するかを確認する「リレーションチェック」や、タイトル固有の数値を確認する「バリデーションチェック」などが可能です。

Excel上での入力規則チェック、およびチェックスクリプトでの2種類のチェックが可能。タイトル固有でのカスタマイズも可能です。

Oyakataはこれまでの仕組みと何が違う?

大きな違いは「ブランチ管理」をサポートしていることです。他の人の作業の影響を受けなくなり、エンジニアがgitで当たり前のように受けている恩恵を、プランナーも享受することができます。

また、ゲームデータへの変換が個々のローカルPCで可能なため、jenkinsの処理を待たずに実機確認がすばやくできます。さらに、マスタデータ形式に特化した差分表示で、見やすい表示が可能になりました。

まとめと課題

DeNAではこれまでGoogle Spread Sheet、Jenkinsでマスタデータ管理の仕組みを構築し続けたため、並行開発の切り分けやjenkinsに依存した管理と順番待ちの時間が発生していました。さらに人間の目を悩ますcsvやJSONの目視確認もつらかったとのことです。

そのような課題をすべて解決する、マスタデータ管理の共通基盤としてOyakataを開発しています。

質疑応答

Q:Oyakataは開発完了後、社内ツールとしてクローズドで使うのでしょうか?

A:まずは、社内と協力している外部の開発会社さんに導入することを目指しています。Oyakataはあまり他にはないマスタデータ管理システムなので、他社で使えるようなOSSや技術サポートのように、将来的に他のモバイルゲーム開発会社で当たり前に使用できるようなツールになればいいと考えています。

『逆転オセロニア』対戦型AIのバックエンドの実装

続いては、DeNAエンジニア宮下 奨平より、『逆転オセロニア』において対戦型AIのバックエンドの実装についてプレゼンを行いました。

DeNA宮下 奨平DeNA 宮下 奨平

『逆転オセロニア』とAIプロジェクト

『逆転オセロニア』は通常の「オセロ」と同じく、黒と白の駒ではさんでひっくりかえすルールで対戦していきます。プレイヤーは、それぞれHPや攻撃力、さまざまなスキルが設定されたキャラクター駒をデッキを組みます。相手のHPをゼロにすれば勝利となるため盤面を有利に取っていくだけではない、戦略的な立ち回りが必要です。

一般的なボードゲーム「オセロ」については、すでに人間の頭脳を上回るAIが開発されていますが、『逆転オセロニア』ではオセロよりも複雑なルールであり、手駒の置き方などで状況は変わっていくため、一般的なゲームAIの構築手法では強いCPUの実装が困難になっていました。そこで深層学習を利用して『逆転オセロニア』のAIを構築することになりました。

このAIプロジェクトのスケジュールとして、2017年4月から深層学習を用いたAIの研究開発を行い、その後、2018年4月頃からAIが本当に十分な強さを持っているかの検証、さらに2018年9月にAIをゲーム内で利用するための実装を開始し、2019年3月に代表的なデッキタイプのAIと戦える「オセロニア道場」がリリースされました。

『逆転オセロニア』深層学習AI

ゲーム内のPvPにおける大量の棋譜の中から、ランクが高いプレイヤーの棋譜を抽出し、学習用データとして利用します。このデータでAIは特徴量から「強いプレイヤーが打ちそうな手」を推測できるようになり、人間レベルのAIを作ることが可能になりました。前処理はPythonで実装しています。

※棋譜とは:ボードゲームなどで、お互いの対局者の手を順番に記録したデータのこと

盤面、手駒の状況やお互いのデッキなどの情報など、ゲームのすべての情報はJSONファイルで管理し、棋譜には同じ状況を再現できるすべての情報を持っています。

ただし、AIは棋譜(JSON)をそのまま理解することはできないため、テンソル(数字だけの多次元配列)に変換する必要があります。その工程を特徴量の抽出と呼びます。

学習の全体像として、プレイヤー同士の対戦で集まる棋譜を特徴量抽出器(Python)で特徴量に変換、それをAIが読み取って学習していきます。

つまり、とある盤面を再現できる十分な情報を持った棋譜をAIを通して、すべての打ち手に対する盤面を考慮した打ちての良さを「評価値」として算出できるということです。

『逆転オセロニア』AIサーバー

ゲームと深層学習AIをつなげる方法について、サーバー側の実装で、クライアントから都度、推論対象の棋譜をリクエストとして送ってもらう形を採用しました。

プラットフォームは「Google Cloud Platform」を使用、AIモデルをデプロイするシステムを持っている、AI研究の段階でも使用していたことが採用の大きな理由となります。

AIのデプロイについて、Google Cloud Machine Learning Engineに学習済みAIモデルをデプロイすると、APIを通じて推論が可能になり、かつ、負荷に応じてクラスタをオートスケールしてくれるため、構築しやすいのが利点です。

AI APIサーバを実装した要件は「クライアントから棋譜を受け取り、評価値を返す」こと、RPS(秒間リクエスト)1000に耐えること(過去のPvEイベントからあり得る最大のRPSを見積もり)です。この部分はかなり苦労したとのことです。

原因を究明したところ、盤面の特徴量がかなり大量のデータであり抽出にCPUリソースを使ってしまうこと、Google Cloud Machine Learning Engineのレスポンスを平均3秒ほど待つ必要が出ることがわかりました。

Google App Engine(GAE)は、ソースコードをデプロイするだけでさまざまな恩恵を受けることができますが、その中で並列リクエスト数の上限に引っかかってしまったことが原因となったようです。

解決策として、Google Cloud Machine Learning Engine APIや特徴量抽出を待つためのサーバーと特徴量を抽出するためにサーバーを区別します。

特徴量抽出サーバーは、学習時に作ったPythonのプログラムをサーバー化、Google Cloud Machine Learning Engineとは関わらず特徴量の抽出だけをするサーバーとしてGAEをデプロイしています。

またフロントエンドでAPIサーバー(Go)として、Google Kubernetes Engineにデプロイし、処理を待つためだけのクライアントと直接繋がるAPIサーバーを作成しました。

この結果完成したGoogle Cloud Platformの大まかな構成は、クライアントからまずLoad BalencerからGoogle Kubernetes Engineの内部APIサーバーを通り、棋譜を受け取り、それを特徴量抽出サーバーで抽出。そのデータをGoogle Cloud Machine Learning Engineに投げて評価値を算出する、となっています。

この構成なら秒間リクエスト1000に耐えることができるようになりました。

まとめ

Google Cloud Platformは、Google App Engine(GAE)やGoogle Kubernetes Engine(GKE)など多彩なサービスが用意されているため、AIコンテンツを実装しやすいが、実装してみると思わぬ落とし穴があるので、それに負けない強い心が必要だと感じたと、宮下は締めくくりました。

質疑応答

Q:APIサーバーにGoを選定した理由は?

A:Pythonでは、シングルセットで動く場合に並列を待ち受けるワーカーの仕組みでは、あらかじめ固定数で指定する必要があり、それを超えて並列で待つとレスポンスが結構遅くなります。

それに比べてGoなら、リクエストの数に応じてそのたびにGoルーチンを発行して待つことが得意だったため、Goを選びました。

横軸技術組織の成果と学び

最後のプレゼンは、QualiArtsおよびSGE Unity代表責任者の住田 直樹氏より、「横軸技術組織の成果と学び」について発表されました。

QualiArts Unityクライアントエンジニア 住田 直樹QualiArts Unityクライアントエンジニア 住田 直樹氏

SGEとは

Smartphone Game&Entertainment(SGE)は、サイバーエージェントのゲーム事業をメインとした13社が集まった子会社群のことです。また、SGE Unityとは、SGE全体でUnityの技術共有や活性化を図るコミュニティ組織になります。メンバーは、新卒者やボードメンバーなどさまざまな役職の人間で構成されています。

主な活動内容は、勉強会の運営・技術施策の運用などで、週1回のMTGで相談をしています。目的としては、SGE全体においてUnityの技術力の向上、プロジェクトのスピードやクオリティの向上を目指し、会社間の技術的な隔たりをなくして助け合えるように、それぞれが持っているノウハウや失敗例やライブラリの共有をしています。

活動内容

各種勉強会の企画と運営について、さまざまな軸で勉強会を運用しています。特にCygamesやUnityなど外部との合同勉強会に注力し、特別講演などでクリエイターとの繋がりを作っています。

そのほか、外部カンファレンス参加による知見の獲得と共有をする「Unite報告会」、Zenjectなど独自ツールのハンズオンをプロジェクトのエンジニアを呼んで講演する「勉強会」や、Cygames・Unity・SGEの3社合同の勉強会などを実施しました。

最近では勉強会などの参加人数も増えていて、講演の模様は録画と社内動画ストリーミングで配信しており、参加できない人も後日チェックすることが可能です。

また、イベント開催による技術発信の促進のため、それぞれのプロジェクト事例を文章化して蓄積・共有する社内Qiita Teamが存在し、各職種のエンジニアやクリエイターが自由に投稿ができます。

技術書の作成では、有志を募ってUnityの開発に役立つTips集「UniTips」を作成、個人開発や業務で得た知見をまとめて文書化しています。シリーズを通して住田氏も執筆に参加しているとのこと。

技術書典では、学生やフリーランスなどさまざまなエンジニア、クリエイターが多数来場しているようです。

組織としての成果

大きな成果は「ナレッジの蓄積」で、約1年で1,000件を超える数を持つSGE Qiitaの記事では、個々のプロジェクトを踏まえた特有のケースなども多数収録されています。

SGE内の動画配信媒体「SGETube」を活用し、参加できなかった人も後日に閲覧が可能になっています。

また、会社間のノウハウ共有による開発の効率化も実現でき、それぞれの分野の知見を活かし各社の不足している部分を補填でき、技術組織の底上げができています。

さらに、Unityに関する勉強会や懇親会などの施策実施について、相談窓口の存在となっており、外部との交流を深め、インプットとアウトプットを通しての組織力の向上が図れました。

個人としての学び

住田氏が自身の学びとして強く感じたことは、技術者としての視野の拡張だと話し、多くのエンジニアやプロジェクトと交流したことで、ノウハウを学びながら、どのような技術施策が組織開発の活性化に繋がるか、技術的にどのような挑戦をしていくかを経験ができたことと、嬉しそうに話しました。

また、何よりも技術組織の責任者を経験したことも良いプレッシャーとなり、さらに良い技術者になるためのエネルギー源にもなったと語っています。

まとめ

技術組織を活性化させることによる、幅広い知見の共有と獲得
さまざまな得意分野・技術・開発体型を持つ子会社群のノウハウの有効活用。動画や文書などによる知的財産の蓄積

横軸規模の技術組織を運営することによる技術者としての成長
多くのエンジニアとの交流や技術施策の運営を通した知見の獲得、業界的な技術挑戦に対するアプローチの検討

技術者としての目線上げ
組織的にどう貢献するか、技術者としてどう成長していくか?

質疑応答

Q:SGE Unityの活動について、ゲームタイトル開発側の評価はいかがでしょうか?

A:詳細なヒアリングをしていないのですが、個人的に活動についてのポジティブな反応をさまざまな職種の人から聞いています。

エンジニア同士で盛り上がる懇親会

各社エンジニアのプレゼンテーション後は、懇親会が開催され、会社の垣根を超えて積極的に親睦を深めていました。このような勉強会は今後も定期的に開催していくとのことです。

取材・文・撮影:細谷亮介

※本記事は2019年3月時点の情報です。

オセロ・Othelloは登録商標です。TM&© Othello,Co. and MegaHouse
© 2016 DeNA Co.,Ltd.

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitter アカウントにて確認いただけます。ぜひフォローをお願いします!

JOIN US!
DeNAゲーム事業部の採用情報はこちら