ぷらこあ

ゆるふわゲームクリエイター / イベントオーガナイザーを目指してます

まべ☆てっくvol.3 Unityのお道具箱 に参加しました

概要

marv-tech.connpass.com

togetter.com

  • 参加しました(ˊ꒳ˋ*)
  • 株式会社マーベラスさん主催の勉強会です!
  • 会社独自でやってる取り組みや仕組みオープンにしてくださるのとても嬉しい…!!

うちではこうやってます!UI構築ルールとPlaymakerを使った画面遷移

資料

www.slideshare.net

目的

  • 人数増加を見越して悩まずに画面/機能を量産可能な仕組みである
  • 導入時にルールが少なく説明しやすい
  • 実装時に他の実装から真似でき、担当者が入れ替わってもパッと分かる

Playmaker + uGUI を使用した画面遷移

  • Playmaker
  • ページ構成
    • Scene入れ替え方式
    • ただし1つのSceneに対し1つのGameObjectのみを配置
      • HomeSequenceというGameObjectにてステート管理を行う
      • PlaymakerFSM + シーケンスマネージャ
  • Playmakerを使ったステート管理
    • グラフィカルなステートマシンとして利用
      • ステートの配色でグルーピングを行う等工夫
    • Playmaker上で使用するアクションは基本CallMethodのみ
  • 各ステートで行うこと
    • シーケンスマネージャに用意したメソッドをCallMethodで呼ぶ
    • UIPrefabのInstantiateや状態管理など
  • UIPrefab
    • UI要素はPrefabに格納した状態で用意する
    • UIHome / UIMenu / UIHeader … etc
  • 画面内で発火したイベントの処理について
    • 子から親にイベントを伝搬し、その結果から子に指示/

作業フロー

  • 仕様書: 企画
  • 仕様確認: 全員
  • UIPrefabの作成: デザイナ
    • UIPrefab作成用のシーンを用意し、解像度などの設定をCanvasに適応しておく
  • UIPrefab修正 : エンジニア
  • スクリプト開発: エンジニア
  • FSM開発: エンジニア

Unityパッケージ管理について本気出して考えてみた

株式会社キッズスター / もんりぃさん

導入

  • 新規プロジェクトを作る際に自作のライブラリ入れる
  • でもUniRxとTexturePackImporterに依存してるぞ
  • AssetStoreからダウンロードマネージャ開いて … めんどい!!!!!
  • 依存関係を解消してくるライブラリ作ってるよ

upm

github.com

  • npmを使用したパッケージ管理ツール
  • 依存管理の仕組みはnpmに乗っかる
  • イベントシステムはUnity向けにカスタマイズ
  • 事前準備
  • アセット群を npm publish する
  • プライベートなリポジトリ(レジストリ)で管理する
    • npm Enterprise
    • Vardaccio
  • 実行
  • npm i -S ${name-of-package} でインストールしつつpackage.jsonの生成

モバイル向けAnimation/AnimatorのTIPS

UnityTechnologyJapan 山村さん ( テラシュールブログ椿さん )

Mecanimについて

Animatorに関するTips

  • ステートマシンを整理する
    • MecanimはGUIで1キャラクターを作り込めるが複雑になりがち
    • サブステートマシンでまとめる
      • 注意: Exitに出た時に次のステートが存在しない場合、最初のステートに戻ってしまう
      • 明示的に任意のステートに割り振らなきゃいけない
    • ブレンドツリー使う
  • 日本のゲームの場合、色々なキャラがいる
    • 1体のキャラを作り込むのではなく、モーションを微調整する
    • AnimationControllerが大量にできてしまう
    • 理想はAnimationControllerを汎用的に使い回すこと
      • リグを合わせる
        • Humanoid: HUmanoid同士ならアニメーションは共有可能
        • Generic: ボーン構造が一致すれば使える
  • 基本となるAnimationContollerを作り込む
    • AnimationOverrideContollerでアニメーションを上書き
    • 注意: 構造が異なるステートマシンがあると問題になる
      • 余裕を持ったアニメーションコントローラーを作る
      • PlayableAPI を使う
        • ダイナミックにAnimationClipを実行する
        • AnimationControllerのブレンドもできる
        • Unity5.6で変更入ったので注意

パフォーマンスの話 / モバイル向けのあれこれ

  • モバイルには色々制約がある
    • 100MBの制限
      • ダイナミックに配信する仕組みが必要
    • IO/CPU/GPUが遅い
      • ロード時間の短縮とGPU負荷の軽減が必要
      • 削れるところは削りましょう
  • ApplyRootMotionを使用しない
    • 無駄なCPUを結構使う
    • AnimationContoller内で合成するLayerを減らす
    • Transion を増やしすぎない
      • PlayやFadeで代替する
  • AnimatorのついたGameObjectを非アクティブにしない
    • Animatorが持つメモリやStateMachine等を破棄する
      • 再度有効にした時に再構築される
    • Animatorコンポーネントをdisabledにする
  • 見えないアニメーションは再生しない
  • そもそもSkinnedMeshRendererを減らす
    • qualityもできれば減らす
  • Animationのキーフレームを減らす
  • OptimizeGameObjectを使用する
  • AssetBundleでAnimationをUnloadしないで使い回す

LTメモ

Hot Reloading on Unity Editor

資料: Hot Readloading on Unity Editor

技術書展へのお誘い

pub.fieldnotes.jp

techbookfest.org

techbookfest.org

Unityで『ニーア オートマタ』の義体システムっぽい機能を作る

  • UnityとNCMBで作る話

qiita.com

使ってみようTimeline

tsubakit1.hateblo.jp

www.shibuya24.info

nn-hokuson.hatenablog.com

サムザップテックナイト vol.2に参加しました

sumzaptechnight.connpass.com

  • 参加しました!(ˊ꒳ˋ*)
  • ちなみに前回のサムザップテックナイトvol.1は @ryuzee さんの「強いチームの作り方」の話でした

www.ryuzee.com

Unityでの絵作りにおける挑戦的表現 / パフォーマンスチューニングとのベストバランス

はじめに

www.youtube.com

ゲーム絵作りの基本

  • ゲーム機で絵を出すには?

それぞれの役割

  • アーティスト
    • ゲームイメージを固める
    • モデル/イラスト/アニメーションを実際に制作する
  • プログラマ
    • アーティストが作ったデータを適切に表示する
    • 表示する為のデータ仕様を作成/提示
    • アーティストの手の届きにくい部分のグラフィック処理
      • ライティング処理
      • ポストフィルタ
    • ハードウェアの制御が必要
      • グラフィック処理は関連するハードウェアが多い

CPU/GPUの基本動作

  • CPU: ゲーム処理
  • GPU: 絵を描く処理
  • フレーム
    • 垂直同期のタイミングが一定 (1/60秒が主)
    • 1秒間のフレーム数がfps
    • 1/60秒動作の時は60fps
  • 処理落ち
    • ゲーム処理が1フレームに収まらない場合、無駄に待ち時間が発生する
    • GPUの処理落ちもありうる
  • 今回はGPUに着目

GPU負荷軽減

  • シェーダ
    • 3Dオブジェクトの描画
      • 頂点シェーダ
        • 頂点に対して座標変換を行う
        • ポリゴン1つに対して3回
      • ピクセルシェーダ
        • 塗りつぶすピクセル数だけ処理を行う
        • 高負荷になりやすい
  • DrawCall
    • 1フレームにおいて必要なオブジェクトを部分部分1つずつ書く
    • この回数をDrawCall数と呼ぶ
    • UnityではFrameDebuggerで確認出来る
  • 負荷計測
  • ゲーム仕様との最適化
    • 「削る」って単語がドライなイメージ
      • 極論何も描かれないのが一番軽い
      • それは本当にゲームの演出として適切か?
    • 仕様を見極めてバランスを取るための提案
  • 背景
    • 動的なライティングを行うか?
      • オープンワールドはリアルタイムに天候変化
      • そうでないときは頂点カラーなどに焼き付けておけば軽い
      • それともUniyならライティング焼き付けを使う?
    • 影を受けるかどうか?
      • 受けると重い
      • 平面限定なら丸影にする
  • ポストフィルタ
    • けっこう負荷になりがち
    • 標準のポストフィルタを使うと高負荷になりがち
    • 複数使用していないか?
    • 自作する勇気
      • 元の負荷が高いので大きな軽減が見込める

思い込みを無くす

  • グラフィックプログラマは司令塔みたいなもの
    • 思い込みで指示を出さない
  • 「半透明は重い」「DrawCall数はとにかく減らせ」
    • 本当に…?
  • 半透明
  • DrawCall
    • e.g) Shaderの中で部分UVスクロール
      • 部分適応外の部分もUVスクロールしない、という判定
      • マテリアル(DrawCall数)増やして処理を狭めた方がGPU的には優しい

チャレンジ処理

まとめ

  • 絵作りに関わる人間
  • 思い込みで指示を出さない
    • なんでそうなるのかを知っておく
  • 技術チャレンジについて
    • 積極的にやる
    • 商品としての完成度アップや宣伝になる

FAQ

  • Q, グラフィックプログラマの育成は?
    • 人材少なめ、若手がいない
    • ポストフィルタ辺りから触ってもらうのが楽かもしれない
  • Q. 最近のグラフィックのレンダリングの流れはデザイナーも知らないとポテンシャル出せない、一方で教えるのはしんどい
    • 好きにさせてる事は多い
    • あまりにも多かったら減らす処理を入れる
    • 逐次確認して説明している

感想

  • この分野、最近関わりを持つようになったのに対し、全然知識ない状態だった
  • そのタイミングでの今回の話は、かなり敷居の低い所から話してくださり、良い導入になった
  • 思い込みの件、実測しないとデザイナーさんにも効果伝わらないし、完全に耳が痛かった
  • シェーダはやるやる言ってて中々踏み出せてないのそろそろどうにかせなアカン

DeNA TechCon 2017に参加しました

techcon.dena.com

  • いつも通り参加したセッションの私的メモ(ˊ꒳ˋ*)
  • 基本的にはD-STAGE (DeNAのゲーム開発) にいました
  • (資料は上後日公開予定なのであくまで一時的なメモ)

基調講演―実世界の人工知能

  • Preferred Networks 岡野原 大輔さん
  • toT/AIにフォーカスして会社
  • Industrial IoT 分野における活動を目指している

ディープラーニング (真相学習)

  • 2014~1015中に出された関連論文数は1500を超える
  • 画像認識/音声認識等で劇的な精度向上、多くが既に実用化

自動車分野への活用

  • CityScape Dataset
    • 人/車/自転車の検出
    • 光やOcclusionの問題を解消
    • フリースペース (車の通行可能な範囲) をほぼリアルタイムで検出
      • 地図ベースでの認識が主流だったが、イレギュラーな変更が多い
  • 車自体の制御
    • 車の自動運転を評価学習して学ばせる
    • ぶつからない場合は報酬を上げ、ぶつかったとき罰を与える
    • 将来的にどういう風に行動したら良いのか学習する
    • トヨタ自動車とのぶつからない車デモ (CES2016)

www.youtube.com

  • ロボット
    • FANUCと共同開発
    • ドローンの自動運転
      • 車の自動運転の技術/学習を転用
  • 異常検知
    • 人でも異常の定義は難しい
    • 正常なデータのみから異常検知モデルを作れる (教師無し学習)
    • 故障の40日前に故障の予兆を捉える
  • バイオヘルスケア
  • 更なる可能性/発展性
    • 他の眼の予測、ステージ予想、良性/悪性の見極め … etc
    • 人工知能を活用した等号的含意量システム開発プロジェクト開始」(2016/11/29)
  • ゲノム解析によるがん治療
    • 客観的な多数の情報からで0たに基づく医療が実現出来る
  • コミュニケーション
    • 直前のワードには反応出来るが、文の意味や文脈は理解できていない
  • クリエイター
    • 画像の自動生成
      • Chainer-gogh
        • 1枚目に渡した画像のスタイルを2枚目に適応
      • Chainer-DCGAN
        • 画像を0から生成する
        • 背景/前衛の分岐や個数を加須植えるのが苦手
      • PaintsChainer
        • 自動着色
        • 色のある画像から線画を生成して差分を学習
        • U-Net+絵の拡大学習
  • Chainer
  • マルチノード分散学習による高速化 (ChainerMN)
    • 精度は変わらない

まとめ

  • 深層学習は様々な分野で利用されて行く
  • 研究と実用化とビジネスかが同時に起こっている
    • 実用レベルになってからのビジネス化が早い (AmazonAlexa)

その後のDeNAのネイティブアプリ開発

  • DeNA 池田 修さん

昨年のおさらい

  • 社員のアプリ開発能力を評価
  • 市場のアプリを開発何度や技術要素で評価
    • アプリの仕様で戦えるタイトルありそう、というスタート
  • 開発要素の変更
    • プログラミングパラダイム (設計)
    • マルチメディアデータ
    • リソースマネジメント
    • チート
  • 環境と体制
    • ゲームエンジン
      • 比較対象のある組織、競争出来る組織を意識
        • 思考停止、視野が狭くなる
      • Unity
      • LiftEngine (内製エンジン)
    • サーバサイド

コールバックvsポーリング

  • 終了検知処理周りの話
  • コールバックの落とし穴
    • コールバックが呼ばれると困るケース
      • コールバック時の該当オブジェクトが存在しないケース
    • 呼ばれない、もしくは2回呼ばれた
    • 逆に該当処理を2回呼びたい場合のケース
    • 該当処理が必要なくなったケース
    • タイムアウト対応
    • マルチスレッド対応
    • 最終的にはポーリングに近い実装になってしまう
  • 「ミドルウェイアのI/Fがコールバック形式なんです!」
    • 薄い層で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台
  • 管理ツール
  • 構成を考える上で
    • 障碍への影響は最小限に押さえ込みたい
    • 一貫性を重視
  • マイクロサービス化の利点
    • サービスが小さい
    • デプロイが独立して行える
    • 耐障害性の向上
  • 役割毎に分割したAPI
    • ひとつのAPIが止まっても他のAPIに影響が出ない状態にする
  • 実際に開発、運用してみて
    • 運用を進めるにつれ、APIが増加してメンテナンスが大変
  • 発生したデメリット
    • APIをまたいだ共通モジュール群が存在してしまう
    • API毎の担当制ではない
    • API毎のコードは独立指定が、DBは共通

マイクロサービスからモノシリックに

  • 10あったAPIのうち2つを統合済み
  • (良い所は引き継ぎつつ)

堅実な開発を目指して

  • 重要なポイント
    • 要件定義からエンジニアが参加して仕様が作る
      • ゲームチームと一緒になって作る
        • とにかく聞きまくる
      • プレイヤーに届けたい価値を共有する
        • 必要であればCSやQA、関連チームの意見も集約する
      • ユースケースをベースにしたI/F作成
        • 呼び出し方やエラーレスポンス等
    • 仕様通りに作る
      • 設計
        • GitHubで仕様管理
        • 仕様の段階でチーム内レビュー
      • 実装
      • テスト
        • テストアプリを使った動作テスト
          • 組み込んだSDKから自動的に機能/IFを反映するのでメンテフリー
        • QAチームによるテスト
    • 仕様通りに動くことを担保する

安定した運用

  • スパイクを避ける
    • APIサーバのslow restart
      • Unicorn(ruby API server) の新しいプロセスが立ち上がってから古いプロセスを消す
      • 瞬間的にメモリの使用量が増える
      • 新しいworkerプロセスを1つ起動出来たタイミングで1古いプロセスを消す
  • キャパシティ管理
  • 継続的なパフォーマンス改善
    • クエリ改善/キャッシュ導入/ロジック改善
    • メモリキャッシュとアプリの修正
      • WebAPI <-> DBネットワークの帯域の使用量が増えた
        • DBに大量のデータを取りに行くようなクエリが発行された
        • WebAPIのプロセスキャッシュを導入
        • 平行して大量にデータを取りに行かないように仕様を変えずにWebAPIを修正
    • キャッシュテーブルの導入
    • プレイヤーデータの圧縮

Sakashoの取り組み

  • 社内専用という利点を生かした開発
    • 横断的にゲームチームをサポート/情報収集
    • CS対応のサポート
    • ポリシー等の確認
    • プロモーション時の負荷対策

Sakashoの課題とこれから

  • 特定の構成に最適化させた作りになっていた
    • 異なる構成のゲームに対応すると要件が複雑になる
    • クライアントに実装されたロジックでゲームが進行するような構成のゲームに最適化
      • MMOなどのサーバ上に多くのステータスを持つゲームには向いていない
  • 安定運用が定着したので、制約を超えたい
    • ゲームロジックをサーバ側に
      • 面白いゲーム作りに集中出来る環境

Unityネイティブプラグインマニアクス

ネイティブプラグインとは?

  • Unity - マニュアル: ネイテイブプラグイン
  • Unityが提供していないプラットフォームAPIを使用する
    • iOSのPush通知/動画再生等はいける
    • 一方でWebViewや空きディスク容量取得等はUnity側で使用していないものはネイティブプラグインとして用意する必要がある
  • ネイティブ機能を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);

必要な実装

    1. 拡張機能のコア実装 (ネイティブ)
    2. 拡張機能のコア実装
    1. マネージドコードから呼び出す為のI/F (ネイティブ)
    2. C Linkageの関数として実装する必要がある
    1. ネイティブコードの連携実装 (マネージド)
    2. P/Inboke (Platform/Invoke)
      • CLIの機能で、ネイティブコードをマネージドコードのように呼び出す事が可能
      • [DllImport("ロード対象のプラグイン")]
      • マーシャラにてマーシャリングする必要があるケース (型変換…etc)
    3. AndroidJavaObjectなど (Androidのみ)
    4. UnitySendMessage
      • ネイティブコード => マネージドコード側に文字列を渡せる
      • 指定したGameObjectの指定したメソッドに対して、stringを引数にして呼び出す
      • 非同期のため、同一フレーム間でメッセージを受け取れない
    1. 利用者向けの呼び出しフロントエンド実装(マネージド)
    2. C#側で使いやすいようにWrapperを用意する

注意点と対応策

  • マルチプラットフォーム対応
    • UnityEditor上の動作を保証する為にmac/windowsにも対応する
    • .a (static) / .so (shaded) / .bundle (shaded) / .dll (shaded)
    • プロプロセッサディレクティブによる分岐
    • IL2CPPビルドを使う場合
      • Androidでは DLLImport(“__internal”) (iOS向け) が宣言されないようにする
  • ネイティブプラグインのライフサイクル
    • Android
      • ロードの順序が担保されない
        • AndroidOSバージョンによってはライブラリの依存関係が解消されない
    • JNI_ONLoadが呼び出されないケースがある
    • 関数曜日ダシ時にロードされる為、ライブラリをロードする為の関数を依存関係順に呼び出しておく
    • UnityEditor
      • プラグインがロードされるのは初回再生時の初回の呼び出し時
      • 再生停止時には影響されない、アンロードされない
      • 初期か処理が複数回呼ばれうる処理にする
        • ゲームコードがリコンパイルされた後のアセンブリ置き換え
        • 終了処理が呼ばれないまま初期枯れるケースがある
  • マネージコードを呼び出す実装の注意点
    • iOS/Android
      • Unityのメインスレッド前提の処理の一部で例外が発生する事がある
      • ネイティブで作成したスレッドからマネージドコードのコールバック処理は直接呼び出さず問い合わせる (pull 型の実装)
    • UntiyEditor
      • デバッガ接続を行うとUnityEditorが応答不能になる
  • 安定性
    • フェイルセーフ制の担保
      • マネージドからエラーをハンドリング出来る仕組み
      • ネイティブプラグインで発生したエラーもUnityEditor上から把握出来るように
    • アライメント問題
      • P/Invoke使用時
      • マーシャリング対象のため、アライメントを意識して構造体を定義する
      • 8byteのフィールド (int_16_t / int_32_t … ) は8の倍数の位置から配置される
      • その間はパディングとして未使用のフィールドになる
  • 実機上での実行効率
    • ヒープを意識する必要がある
    • メモリコピーの回避
      • マネージドヒープ (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) に欠けていた機能の実装
  • 徹底的な最適化
    • 2D描画に特化したダイナミックバッチング
    • マルチレイヤーレンダリング
    • 独自フォントテクスチャ描画
      • FreeTypeによるフォントテクスチャ描画を導入
  • OPTPiX Sprite Statdio ランタイム
  • 内製AnimationBuilder用の最適化

採用タイトル

  • デナレンジャー
  • ガールアックス

今はどうなった?

  • 3Dゲームエンジン化 (最中)
    • クイックにゲームを作るのであればUnityで十分
    • すべてを自由に出来るゲーム開発環境も欲しい
      • ビルド周り等
    • ゲーム仕様に特化したチューニングが出来る
      • ネイティブプラグインでは越えられない壁
      • Unityの場0ジョンアップに寄る仕様変更の弊害
    • ゲーム開発における選択肢を広げる
      • 自分たちのやりたい事にマッチするソリューションを採用しよう
    • タイトル特化型の最適化をゲームシステムだけでなく、コンテンツパイプラインやワークフローも合わせて構築したい

DeNAにおけるアプリ開発状況

  • 選択と集中によりネイティブ開発に対応出来た
    • 基盤開発に寄る技術力の積み上げ
    • ゲーム開発エンジニアとしてコンテンツ開発に集中する
  • 課題
    • 効率的な運用/審査
    • コンテンツの増大
    • チーム規模の拡大
    • 結果として、生産性の低下

LiftEngineの3D化要件

  • DeNAが目指すゲーム開発の方向性に合致するもの
  • 何でも出来る汎用エンジンは求めない
  • 開発効率の向上、Try&Errorをやりやすくする
  • タイトル毎に必要に応じて部分的な再実装を可能にする
  • 「便利なものが高効率というわけではない!」
  • LiftEngineとしての立ち位置を精査
    • プラットフォームAPIラッパー
    • 3D化のためのプリミティブな機能
    • ゲームシステム実装に対する制限は、LiftEngineより上のレイヤーで適応する

実装した新機能

  • レンダリングパイプライン
    • レンダリングは専用スレッド (コマンドバッファを採用)
    • cocos2d-xベースの描画処理も移植
  • 3D系の算術演算
  • シリアライズの為の仕組み
    • 暮らすオブジェクトを簡単にデータ化するための枠組み
  • より高速なメモリ管理
    • TLSFアロケータ
    • スレッドキャッシュ
  • 動的Bitmapフォントテクスチャの生成
  • マウス/キーボード入力ハンドリング
    • ツール開発用

ApplicationLibrary (Arcana)

  • LiftEngineの上位に存在するアプリケーションフレームワーク
  • ゲーム作りのルールはここで規定する
  • 共通レンダリングエンジンの提供
    • LiftEngine世のコマンドバッファを構築
  • シリアライズ周り、パーティクル、物理シュミレーション、アニメーション…. etc
  • シーングラフ管理
    • シーングラフノードの組み合わせによる振るまい実装
    • シリアライズ可能
  • リソース管理
    • 取り扱い方を統一する
  • レンダリングエンジン
    • PBR/HDR/Shadows/MotionBlur/AmbientOcclusion … etc
    • 技術的にはPS3/Xbox360と同等水準
      • PS3/XboxONE世代の技術もそのうち…
      • 想定スペックは2020年の低スペック端末
  • ツール開発環境
    • ゲーム.dll をツール.exe も ゲーム.exe も参照
    • ゲームの機能をツール側でも使えるように

LifeEngineが目指す未来

  • 開発効率を上げる
    • タイトルの開発に合わせて必要なツールが揃ってくる
    • 先のタイトルに鳴ればなるほど効率が上がる方向で
    • 人海戦術には頼らない、少人数でもコンテンツ開発
  • グラフィックに関しては選択と集中
    • 表現に注力すると開発工数は増大する
    • 表現力は出来る限りシステム側で引き上げる
    • デザイナー工数は必要なところに集中する
    • 自動生成/シミュレーションも活用

Cygames × DeNA エンジニアが語るこれからのゲーム開発

自己紹介

  • 芦原さん (Cygames/CTO)
  • 古閑さん (Cygames)
  • 恵良さん (DeNA)
  • 池田さん (DeNA)
  • 田川さん (DeNA)

初めて開発したネイティブアプリ

  • 芦原さん
    • 社内の企画コンテストで出た案からスタート
    • スマホでもガラケーでも究極のゲームを作りたい
    • グループ会社と協力してネイティブ得意なところと一緒に
      • 企画やグラフィックはサイゲ、コードはグループ会社
    • ネットワーク、DLの速度、単位が小さいと遅かったり大きいと失敗したり -
  • 池田さん
    • デナレンジャーってすごい名前
    • 社内のMTG「正式なタイトルを教えてくださいよ」
    • やれる人は一部のみ、だけどエンジニアはクライアントも行けるのでは?
  • 恵良さん
    • ゲームの面白さに関係ない部分は基盤として整備
    • デバッグ期間が地獄だった
    • Sakashoだったりオーディオエンジンだったり、あらゆる物を一緒に検証してた時期だった

アプリシフトを決めた背景

  • 芦原さん
    • 世間的にもスマホメイン、アプリにした方が表現力上がる
    • どの分野でも最高を目指したい
    • ちょうどいい企画がコンテストで上がって来たので上からも下からも熱があった
    • クオリティファーストでのリリース
  • 池田さん
    • トップダウンでの指示と開発チームからの検証/熱量のタイミング

2D => 3D への挑戦

  • 芦原さん
    • 3Dの話の前にcocos2dxを使用している時の話
    • 3Dのモデルをプリレンダーで2Dで表示
    • 3Dのデザイナーはいた状態
    • 慣れていないC++に慣れるステージだった
  • 古閑さん
    • ネイティブ作るエンジニアは少ない状態だった
    • 改善の余地が見えていたので楽しかった
  • 芦原さん
    • メモリ管理に慣れていないメンバーが多かった
    • コンシューマ経験者に来ていただく流れ
    • 3Dのゲームは実験的に作ったりしていた
      • 2011年にはUnity触っていた
  • 恵良さん
    • DeNAはデナレンジャーの脇で触ってた
    • perl触ってた人間がUnityでC#書き始める
  • 池田さん
    • 2Dのアプリやったら3Dやろうということになっていた
    • 3Dの中でも敷居が低いところで攻めようと思っていた
    • 一方で企画は既に決まっていた
    • 3D経験者はそんなにいなかった
    • この前に perl 書いてたのに shader 書きました!みたいな人も
      • キャッチアップが得意なリードエンジニアは早い、2,3ヶ月で適応

コンシューマー経験者との融合

  • 古閑さん
    • コンシューマーからサーバ、クライアントに来た
    • ゲーム作りたい、というところが基準なので、すんなり適応した
  • 芦原さん
    • ソーシャルに来た時はマネージャー系
    • サーバ屋さんがソーシャルにいっぱいいた
  • 池田さん
    • ゲーム会社でサーバ担当していた時は孤独だった
    • DeNAに来たら「あ、ここにいたんだ」
  • 恵良さん
    • 大体似たような感じ
    • DeNAに来た時のインパクトは色んなサービスがあるのでゲーム会社っぽくない
    • 興味を持つ部分がズレてる、OSS等への興味がある人多かった
    • 自分は好き勝手やれる感じだった、やれそうなことを探す
  • 池田さん
    • ターゲットプラットフォームが違うだけど、やらなきゃいけないことは一緒
  • 古閑さん
    • スマホの性能も上がっているのでトレースしている感じ

今後の方針

  • 芦原さん
    • CygamesNextで発表した
    • コンシューマ開発はエンジンから頑張る
    • 色々なプラットフォームで新しい事をやっていきたい
      • VR/ARの研究、データベースエンジン
    • お客さんに驚いてもらいたい、びっくりするようなものを
  • 古閑さん
    • Cygamesはグラフィックの強さを感じる
    • スマホは月単位で表現出来るレベルが上がっている
    • テクニカルアーティスト、エンジニアとデザイナーを繋ぐ環境作り
  • 芦原さん
    • テクニカルアーティストみたいな人がスマホでも重要になって来た
  • 池田さん
    • (自分が作りたいもの) アクションゲーム作りたい!
    • モバイルゲームは時間内中で一番楽しい所やってもらうのはいいこと
    • 没入感にもっと踏み込んだコンテンツを提供したい
  • 恵良さん
    • 作りたいゲームは特に無いが、作りたいメンバーが気持ちよく作れる環境を作って行きたい