DeNA TechCon 2017に参加しました
- 基調講演―実世界の人工知能
- その後のDeNAのネイティブアプリ開発
- DeNAのゲームを支えるプラットフォーム Sakasho
- Unityネイティブプラグインマニアクス
- DeNA内製ゲームエンジンの現状と目指す未来
- Cygames × DeNA エンジニアが語るこれからのゲーム開発
- いつも通り参加したセッションの私的メモ(ˊ꒳ˋ*)
- 基本的にはD-STAGE (DeNAのゲーム開発) にいました
- (資料は上後日公開予定なのであくまで一時的なメモ)
基調講演―実世界の人工知能
- Preferred Networks 岡野原 大輔さん
- toT/AIにフォーカスして会社
- Industrial IoT 分野における活動を目指している
ディープラーニング (真相学習)
- 2014~1015中に出された関連論文数は1500を超える
- 画像認識/音声認識等で劇的な精度向上、多くが既に実用化
自動車分野への活用
- CityScape Dataset
- 人/車/自転車の検出
- 光やOcclusionの問題を解消
- フリースペース (車の通行可能な範囲) をほぼリアルタイムで検出
- 地図ベースでの認識が主流だったが、イレギュラーな変更が多い
- 車自体の制御
- 車の自動運転を評価学習して学ばせる
- ぶつからない場合は報酬を上げ、ぶつかったとき罰を与える
- 将来的にどういう風に行動したら良いのか学習する
- トヨタ自動車とのぶつからない車デモ (CES2016)
- ロボット
- FANUCと共同開発
- ドローンの自動運転
- 車の自動運転の技術/学習を転用
- 異常検知
- 人でも異常の定義は難しい
- 正常なデータのみから異常検知モデルを作れる (教師無し学習)
- 故障の40日前に故障の予兆を捉える
- バイオヘルスケア
- 更なる可能性/発展性
- ゲノム解析によるがん治療
- 客観的な多数の情報からで０たに基づく医療が実現出来る
- コミュニケーション
- 直前のワードには反応出来るが、文の意味や文脈は理解できていない
- クリエイター
- 画像の自動生成
- Chainer-gogh
- 1枚目に渡した画像のスタイルを2枚目に適応
- Chainer-DCGAN
- 画像を0から生成する
- 背景/前衛の分岐や個数を加須植えるのが苦手
- PaintsChainer
- 自動着色
- 色のある画像から線画を生成して差分を学習
- U-Net+絵の拡大学習
- Chainer-gogh
- 画像の自動生成
- Chainer
- マルチノード分散学習による高速化 (ChainerMN)
- 精度は変わらない
まとめ
- 深層学習は様々な分野で利用されて行く
- 研究と実用化とビジネスかが同時に起こっている
- 実用レベルになってからのビジネス化が早い (AmazonAlexa)
その後のDeNAのネイティブアプリ開発
- DeNA 池田 修さん
昨年のおさらい
- 社員のアプリ開発能力を評価
- 市場のアプリを開発何度や技術要素で評価
- アプリの仕様で戦えるタイトルありそう、というスタート
- 開発要素の変更
- プログラミングパラダイム (設計)
- マルチメディアデータ
- リソースマネジメント
- チート
- 環境と体制
コールバックvsポーリング
- 終了検知処理周りの話
- コールバックの落とし穴
- コールバックが呼ばれると困るケース
- コールバック時の該当オブジェクトが存在しないケース
- 呼ばれない、もしくは2回呼ばれた
- 逆に該当処理を2回呼びたい場合のケース
- 該当処理が必要なくなったケース
- タイムアウト対応
- マルチスレッド対応
- 最終的にはポーリングに近い実装になってしまう
- コールバックが呼ばれると困るケース
- 「ミドルウェイアのI/Fがコールバック形式なんです！」
- 薄い層でwrapする
- コールバック関数内でステータス変更し、その結果をポーリングする
- 薄い層でwrapする
RDBMSvs構造体
- RDBMS
- deadlock意識
- 必要なデータだけ取得する思想
- 構造体
- どうメモリに乗るか意識
- データにPKが入らないことが多い
- Sakashoで扱うデータ群
- アセット
- クライアントストレージに永続記録されるデータ
- マスター
- クライアントのメモリ上で扱われ、都度ダウンロードされるデータ
- 更新が頻発、期間が限定的なデータ
- アセット
- サーバサイド(RDBMS)主体で設計したら
- DB丸ごと起動時にメモリ内ストレージに乗せていた
- メモリ消費量が激しくて、メモリの消費量尾激しい
- DBほどデータ操作のための機能は充実していない
- マスターデータの管理
- コンフリクト
- プロプロセスでの解消
- 細切れのデータをマージ
- どういう単位でデータを分割するか？
- 配信/ダウンロード単位
- 作業者
- 有効期限
- (メモリ節約時代の話)
- モバイル端末のマシンスペック進歩著しい
- 処理効率と開発効率の兼ね合いで
DeNAのゲームを支えるプラットフォーム Sakasho
Sakasho
- モバイルゲーム用プラットフォーム
- 社内専用プラットフォーム
- クライアント開発に集中出来る
Sakashoの機能
- モバイルゲーム作成上で必要な機能を提供
- アカウント管理
- ユーザデータ管理
- 課金処理
- マスタ配信
- アセット配信
- CS対応の為の仕組み
- (ゲーム専用サーバとは別)
- SDK
- 各ゲーム専用サーバと連携
- WebAPIを提供
- 汎用的なWebページも簡単に
- お知らせや利用規約等
- ペライチ
Sakashoの構成
- Proxyサーバ (認証): 約9台
- APIサーバ (マイクロサービス的にお知らせ、通知、プレイヤー … etc ) : 約36台
- SakashoDB: 約31台
- 管理ツール
- 構成を考える上で
- 障碍への影響は最小限に押さえ込みたい
- 一貫性を重視
- 1つのトランザクションで複数のデータの更新
- マイクロサービス化の利点
- サービスが小さい
- デプロイが独立して行える
- 耐障害性の向上
- 役割毎に分割したAPI
- 実際に開発、運用してみて
- 運用を進めるにつれ、APIが増加してメンテナンスが大変
- 発生したデメリット
マイクロサービスからモノシリックに
- 10あったAPIのうち2つを統合済み
- (良い所は引き継ぎつつ)
堅実な開発を目指して
- 重要なポイント
- 要件定義からエンジニアが参加して仕様が作る
- ゲームチームと一緒になって作る
- とにかく聞きまくる
- プレイヤーに届けたい価値を共有する
- 必要であればCSやQA、関連チームの意見も集約する
- ユースケースをベースにしたI/F作成
- 呼び出し方やエラーレスポンス等
- ゲームチームと一緒になって作る
- 仕様通りに作る
- 仕様通りに動くことを担保する
- 要件定義からエンジニアが参加して仕様が作る
安定した運用
- スパイクを避ける
- キャパシティ管理
- リソースの過不足を判断出来るレポート
- dailyでレポートメール
- CPU/メモリの使用量
- サーバやWorker増やす指標
- Workerの枯渇監視
- rack-server_statusを使ったworkerの枯渇監視
- 継続的なパフォーマンス改善
- クエリ改善/キャッシュ導入/ロジック改善
- メモリキャッシュとアプリの修正
- WebAPI <-> DBネットワークの帯域の使用量が増えた
- DBに大量のデータを取りに行くようなクエリが発行された
- WebAPIのプロセスキャッシュを導入
- 平行して大量にデータを取りに行かないように仕様を変えずにWebAPIを修正
- WebAPI <-> DBネットワークの帯域の使用量が増えた
- キャッシュテーブルの導入
- プレイヤーデータの圧縮
Sakashoの取り組み
- 社内専用という利点を生かした開発
- 横断的にゲームチームをサポート/情報収集
- CS対応のサポート
- ポリシー等の確認
- プロモーション時の負荷対策
Sakashoの課題とこれから
- 特定の構成に最適化させた作りになっていた
- 異なる構成のゲームに対応すると要件が複雑になる
- クライアントに実装されたロジックでゲームが進行するような構成のゲームに最適化
- MMOなどのサーバ上に多くのステータスを持つゲームには向いていない
- 安定運用が定着したので、制約を超えたい
- ゲームロジックをサーバ側に
- 面白いゲーム作りに集中出来る環境
- ゲームロジックをサーバ側に
Unityネイティブプラグインマニアクス
ネイティブプラグインとは？
- Unity - マニュアル: ネイテイブプラグイン
- Unityが提供していないプラットフォームAPIを使用する
- ネイティブ機能をUnityで利用するため
- 技術資産の流用
- 社内モジュール
- OSS
作り方
- マネージドコード (C#)
- monoでビルドした場合は仮想マシン上で実行されるコード
- IL2CPPでビルドした場合は最終的にネイティブコードになる
- ネイティブコード/アンマネージドコード (C/C++/Java … etc)
[DllImport("native")]
private static extern int ad(int x, int y);
libnative.so int add(int x, int y);
必要な実装
- マネージドコードから呼び出す為のI/F (ネイティブ)
- C Linkageの関数として実装する必要がある
- ネイティブコードの連携実装 (マネージド)
- P/Inboke (Platform/Invoke)
- CLIの機能で、ネイティブコードをマネージドコードのように呼び出す事が可能
[DllImport("ロード対象のプラグイン")]- マーシャラにてマーシャリングする必要があるケース (型変換…etc)
- AndroidJavaObjectなど (Androidのみ)
- UnitySendMessage
- ネイティブコード => マネージドコード側に文字列を渡せる
- 指定したGameObjectの指定したメソッドに対して、stringを引数にして呼び出す
- 非同期のため、同一フレーム間でメッセージを受け取れない
- 利用者向けの呼び出しフロントエンド実装(マネージド)
- C#側で使いやすいようにWrapperを用意する
注意点と対応策
- マルチプラットフォーム対応
- ネイティブプラグインのライフサイクル
- マネージコードを呼び出す実装の注意点
- 安定性
- 実機上での実行効率
- ヒープを意識する必要がある
- メモリコピーの回避
- マネージドヒープ (GC対象となる)
- 任意のタイミングで削除される可能性
- ネイティブヒープ
- マネージドヒープ (GC対象となる)
- メモリコピーはマーシャリング時に発生する
- やり取りするデータが大きく、頻度が高い場合はマーシャリングを回避するようにする
- Blittable型 (bool, charを除くプリミティブな価型(int, float…)) を使う
- P/Invokeで受け渡す際にマーシャリングせず直接参照する
- アドレスの参照が保証されるのは関数呼び出しの間のみ
- Out方向属性を指定すると、書き込みを行う事も可能
- GCHandle
- 非同期に処理を行いたい場合に使用する (データのパースや複合化)
- 指定したインスタンスのがベージコレクタのハンドルを取得する機構
- GCHandleを使用する事で固定化 (Blittable型のみ)
- ‘GCHandle.Alloc’
- ‘GCHandleType.Pinned’
- この辺りの話を参考
DeNA内製ゲームエンジンの現状と目指す未来
LiftEngineとは？
- ネイティブアプリ開発の取り組みの一つ
- cocos2d-xがベース
- 作り方をAPIで制限し、迷いを排除
- cocos2d-x (2.X) に欠けていた機能の実装
- 徹底的な最適化
- OPTPiX Sprite Statdio ランタイム
- 内製AnimationBuilder用の最適化
採用タイトル
- デナレンジャー
- ガールアックス
- …
今はどうなった？
- 3Dゲームエンジン化 (最中)
- クイックにゲームを作るのであればUnityで十分
- すべてを自由に出来るゲーム開発環境も欲しい
- ビルド周り等
- ゲーム仕様に特化したチューニングが出来る
- ネイティブプラグインでは越えられない壁
- Unityの場０ジョンアップに寄る仕様変更の弊害
- ゲーム開発における選択肢を広げる
- 自分たちのやりたい事にマッチするソリューションを採用しよう
- タイトル特化型の最適化をゲームシステムだけでなく、コンテンツパイプラインやワークフローも合わせて構築したい
DeNAにおけるアプリ開発状況
- 選択と集中によりネイティブ開発に対応出来た
- 基盤開発に寄る技術力の積み上げ
- ゲーム開発エンジニアとしてコンテンツ開発に集中する
- 課題
- 効率的な運用/審査
- コンテンツの増大
- チーム規模の拡大
- 結果として、生産性の低下
LiftEngineの3D化要件
- DeNAが目指すゲーム開発の方向性に合致するもの
- 何でも出来る汎用エンジンは求めない
- ゲームエンジンを作る事自体が目的ではない
- 開発効率の向上、Try&Errorをやりやすくする
- タイトル毎に必要に応じて部分的な再実装を可能にする
- 「便利なものが高効率というわけではない！」
- LiftEngineとしての立ち位置を精査
- プラットフォームAPIラッパー
- 3D化のためのプリミティブな機能
- ゲームシステム実装に対する制限は、LiftEngineより上のレイヤーで適応する
実装した新機能
- 新レンダリングパイプライン
- レンダリングは専用スレッド (コマンドバッファを採用)
- cocos2d-xベースの描画処理も移植
- 3D系の算術演算
- シリアライズの為の仕組み
- 暮らすオブジェクトを簡単にデータ化するための枠組み
- より高速なメモリ管理
- TLSFアロケータ
- スレッドキャッシュ
- 動的Bitmapフォントテクスチャの生成
- マウス/キーボード入力ハンドリング
- ツール開発用
ApplicationLibrary (Arcana)
- LiftEngineの上位に存在するアプリケーションフレームワーク
- ゲーム作りのルールはここで規定する
- 共通レンダリングエンジンの提供
- LiftEngine世のコマンドバッファを構築
- シリアライズ周り、パーティクル、物理シュミレーション、アニメーション…. etc
- シーングラフ管理
- シーングラフノードの組み合わせによる振るまい実装
- シリアライズ可能
- リソース管理
- 取り扱い方を統一する
- レンダリングエンジン
- ツール開発環境
- ゲーム.dll をツール.exe も ゲーム.exe も参照
- dll化するメリットはメタデータの共通化
- ゲームの機能をツール側でも使えるように
- ゲーム.dll をツール.exe も ゲーム.exe も参照
LifeEngineが目指す未来
- 開発効率を上げる
- タイトルの開発に合わせて必要なツールが揃ってくる
- 先のタイトルに鳴ればなるほど効率が上がる方向で
- 人海戦術には頼らない、少人数でもコンテンツ開発
- グラフィックに関しては選択と集中
- 表現に注力すると開発工数は増大する
- 表現力は出来る限りシステム側で引き上げる
- デザイナー工数は必要なところに集中する
- 自動生成/シミュレーションも活用
Cygames × DeNA エンジニアが語るこれからのゲーム開発
自己紹介
初めて開発したネイティブアプリ
- 芦原さん
- 池田さん
- デナレンジャーってすごい名前
- 社内のMTG「正式なタイトルを教えてくださいよ」
- やれる人は一部のみ、だけどエンジニアはクライアントも行けるのでは？
- 恵良さん
- ゲームの面白さに関係ない部分は基盤として整備
- デバッグ期間が地獄だった
- Sakashoだったりオーディオエンジンだったり、あらゆる物を一緒に検証してた時期だった
アプリシフトを決めた背景
- 芦原さん
- 世間的にもスマホメイン、アプリにした方が表現力上がる
- どの分野でも最高を目指したい
- ちょうどいい企画がコンテストで上がって来たので上からも下からも熱があった
- クオリティファーストでのリリース
- 池田さん
- トップダウンでの指示と開発チームからの検証/熱量のタイミング
2D => 3D への挑戦
- 芦原さん
- 3Dの話の前にcocos2dxを使用している時の話
- 3Dのモデルをプリレンダーで2Dで表示
- 3Dのデザイナーはいた状態
- 慣れていないC++に慣れるステージだった
- 古閑さん
- ネイティブ作るエンジニアは少ない状態だった
- 改善の余地が見えていたので楽しかった
- 芦原さん
- メモリ管理に慣れていないメンバーが多かった
- コンシューマ経験者に来ていただく流れ
- 3Dのゲームは実験的に作ったりしていた
- 2011年にはUnity触っていた
- 恵良さん
- 池田さん
- 2Dのアプリやったら3Dやろうということになっていた
- 3Dの中でも敷居が低いところで攻めようと思っていた
- 一方で企画は既に決まっていた
- 3D経験者はそんなにいなかった
- この前に perl 書いてたのに shader 書きました！みたいな人も
- キャッチアップが得意なリードエンジニアは早い、2,3ヶ月で適応
コンシューマー経験者との融合
- 古閑さん
- コンシューマーからサーバ、クライアントに来た
- ゲーム作りたい、というところが基準なので、すんなり適応した
- 芦原さん
- ソーシャルに来た時はマネージャー系
- サーバ屋さんがソーシャルにいっぱいいた
- 池田さん
- ゲーム会社でサーバ担当していた時は孤独だった
- DeNAに来たら「あ、ここにいたんだ」
- 恵良さん
- 池田さん
- ターゲットプラットフォームが違うだけど、やらなきゃいけないことは一緒
- 古閑さん
- スマホの性能も上がっているのでトレースしている感じ
今後の方針
- 芦原さん
- CygamesNextで発表した
- コンシューマ開発はエンジンから頑張る
- 色々なプラットフォームで新しい事をやっていきたい
- VR/ARの研究、データベースエンジン
- お客さんに驚いてもらいたい、びっくりするようなものを
- 古閑さん
- Cygamesはグラフィックの強さを感じる
- スマホは月単位で表現出来るレベルが上がっている
- テクニカルアーティスト、エンジニアとデザイナーを繋ぐ環境作り
- 芦原さん
- テクニカルアーティストみたいな人がスマホでも重要になって来た
- 池田さん
- (自分が作りたいもの) アクションゲーム作りたい！
- モバイルゲームは時間内中で一番楽しい所やってもらうのはいいこと
- 没入感にもっと踏み込んだコンテンツを提供したい
- 恵良さん
- 作りたいゲームは特に無いが、作りたいメンバーが気持ちよく作れる環境を作って行きたい
