まべ☆てっくvol.3 Unityのお道具箱 に参加しました
- 概要
- うちではこうやってます!UI構築ルールとPlaymakerを使った画面遷移
- Unityパッケージ管理について本気出して考えてみた
- モバイル向けAnimation/AnimatorのTIPS
- LTメモ
概要
- 参加しました(ˊ꒳ˋ*)
- 株式会社マーベラスさん主催の勉強会です!
- 会社独自でやってる取り組みや仕組みオープンにしてくださるのとても嬉しい…!!
うちではこうやってます!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
- npmを使用したパッケージ管理ツール
- 依存管理の仕組みはnpmに乗っかる
- イベントシステムはUnity向けにカスタマイズ
- 事前準備
- アセット群を npm publish する
- プライベートなリポジトリ(レジストリ)で管理する
- npm Enterprise
- Vardaccio
- 実行
- npm i -S ${name-of-package} でインストールしつつpackage.jsonの生成
モバイル向けAnimation/AnimatorのTIPS
UnityTechnologyJapan 山村さん ( テラシュールブログ の 椿さん )
Mecanimについて
- Mecanim (以下の機能の総称)
- Animator
- AnimationController
- AnimationClip
- 細かくできること
Animatorに関するTips
- ステートマシンを整理する
- MecanimはGUIで1キャラクターを作り込めるが複雑になりがち
- サブステートマシンでまとめる
- 注意: Exitに出た時に次のステートが存在しない場合、最初のステートに戻ってしまう
- 明示的に任意のステートに割り振らなきゃいけない
- ブレンドツリー使う
- 日本のゲームの場合、色々なキャラがいる
- 1体のキャラを作り込むのではなく、モーションを微調整する
- AnimationControllerが大量にできてしまう
- 理想はAnimationControllerを汎用的に使い回すこと
- リグを合わせる
- Humanoid: HUmanoid同士ならアニメーションは共有可能
- Generic: ボーン構造が一致すれば使える
- リグを合わせる
- 基本となるAnimationContollerを作り込む
- AnimationOverrideContollerでアニメーションを上書き
- 注意: 構造が異なるステートマシンがあると問題になる
- 余裕を持ったアニメーションコントローラーを作る
- PlayableAPI を使う
- ダイナミックにAnimationClipを実行する
- AnimationControllerのブレンドもできる
- Unity5.6で変更入ったので注意
パフォーマンスの話 / モバイル向けのあれこれ
- モバイルには色々制約がある
- ApplyRootMotionを使用しない
- 無駄なCPUを結構使う
- AnimationContoller内で合成するLayerを減らす
- Transion を増やしすぎない
- PlayやFadeで代替する
- AnimatorのついたGameObjectを非アクティブにしない
- Animatorが持つメモリやStateMachine等を破棄する
- 再度有効にした時に再構築される
- Animatorコンポーネントをdisabledにする
- Animatorが持つメモリやStateMachine等を破棄する
- 見えないアニメーションは再生しない
- AnimatorのCullingModeを変更する
- CameraのOcculusionCullingでもOK
- そもそもSkinnedMeshRendererを減らす
- qualityもできれば減らす
- Animationのキーフレームを減らす
- Keyframe Reductionを有効にする
- OptimizeGameObjectを使用する
- Unityに配置したモデルをアニメーション向けに最適化する - テラシュールブログ
- GameObjectの数が減って起動が早くなる
- SkinnedMeshのコストが減る
- Unityに配置したモデルをアニメーション向けに最適化する - テラシュールブログ
- AssetBundleでAnimationをUnloadしないで使い回す
LTメモ
Hot Reloading on Unity Editor
資料: Hot Readloading on Unity Editor
技術書展へのお誘い
Unityで『ニーア オートマタ』の義体システムっぽい機能を作る
- UnityとNCMBで作る話
使ってみようTimeline
サムザップテックナイト vol.2に参加しました
- 参加しました!(ˊ꒳ˋ*)
- ちなみに前回のサムザップテックナイトvol.1は @ryuzee さんの「強いチームの作り方」の話でした
Unityでの絵作りにおける挑戦的表現 / パフォーマンスチューニングとのベストバランス
はじめに
ゲーム絵作りの基本
- ゲーム機で絵を出すには?
- アーティストだけではなくプログラマも必要
それぞれの役割
- アーティスト
- ゲームイメージを固める
- モデル/イラスト/アニメーションを実際に制作する
- プログラマ
- アーティストが作ったデータを適切に表示する
- 表示する為のデータ仕様を作成/提示
- アーティストの手の届きにくい部分のグラフィック処理
- ライティング処理
- ポストフィルタ
- ハードウェアの制御が必要
- グラフィック処理は関連するハードウェアが多い
CPU/GPUの基本動作
- CPU: ゲーム処理
- GPU: 絵を描く処理
- フレーム
- 垂直同期のタイミングが一定 (1/60秒が主)
- 1秒間のフレーム数がfps
- 1/60秒動作の時は60fps
- 処理落ち
- ゲーム処理が1フレームに収まらない場合、無駄に待ち時間が発生する
- GPUの処理落ちもありうる
- 今回はGPUに着目
GPU負荷軽減
- シェーダ
- DrawCall
- 1フレームにおいて必要なオブジェクトを部分部分1つずつ書く
- この回数をDrawCall数と呼ぶ
- UnityではFrameDebuggerで確認出来る
- 負荷計測
- Unity: GPU負荷を測りにくい
- XCode: GPUFrameCapture (OpenGL ES Frame Debugger)
- 何回も見るのもしんどいので何が重いか何となく知っておくと良い
- ゲーム仕様との最適化
- 「削る」って単語がドライなイメージ
- 極論何も描かれないのが一番軽い
- それは本当にゲームの演出として適切か?
- 仕様を見極めてバランスを取るための提案
- 「削る」って単語がドライなイメージ
- 背景
- 動的なライティングを行うか?
- オープンワールドはリアルタイムに天候変化
- そうでないときは頂点カラーなどに焼き付けておけば軽い
- それともUniyならライティング焼き付けを使う?
- 影を受けるかどうか?
- 受けると重い
- 平面限定なら丸影にする
- 動的なライティングを行うか?
- ポストフィルタ
- けっこう負荷になりがち
- 標準のポストフィルタを使うと高負荷になりがち
- 複数使用していないか?
- 自作する勇気
- 元の負荷が高いので大きな軽減が見込める
思い込みを無くす
- グラフィックプログラマは司令塔みたいなもの
- 思い込みで指示を出さない
- 「半透明は重い」「DrawCall数はとにかく減らせ」
- 本当に…?
- 半透明
- 「いけにえと雪のセツナ」グラフィック解説(第1回・フロー編)
- Cutoutシェーダについての項目を参照
- カットアウト/パンチ抜き vs 半透明
- GPUによっては半透明に対しての負荷が軽いケースも
- 「いけにえと雪のセツナ」グラフィック解説(第1回・フロー編)
- DrawCall
- e.g) Shaderの中で部分UVスクロール
- 部分適応外の部分もUVスクロールしない、という判定
- マテリアル(DrawCall数)増やして処理を狭めた方がGPU的には優しい
- e.g) Shaderの中で部分UVスクロール
チャレンジ処理
- 雪を凹む表現
- Unityでのリニアワークフロー処理
- チャレンジして発信した方がアピールになる
- 最近は技術が売りになる
- 技術ブログやセミナー等
- 1タイトルで1つくらいチャレンジ
- 最近は技術が売りになる
- 敷居が高い?
まとめ
- 絵作りに関わる人間
- アーティスト/プログラマ
- 思い込みで指示を出さない
- なんでそうなるのかを知っておく
- 技術チャレンジについて
- 積極的にやる
- 商品としての完成度アップや宣伝になる
FAQ
- Q, グラフィックプログラマの育成は?
- 人材少なめ、若手がいない
- ポストフィルタ辺りから触ってもらうのが楽かもしれない
- Q. 最近のグラフィックのレンダリングの流れはデザイナーも知らないとポテンシャル出せない、一方で教えるのはしんどい
- 好きにさせてる事は多い
- あまりにも多かったら減らす処理を入れる
- 逐次確認して説明している
感想
- この分野、最近関わりを持つようになったのに対し、全然知識ない状態だった
- そのタイミングでの今回の話は、かなり敷居の低い所から話してくださり、良い導入になった
- 思い込みの件、実測しないとデザイナーさんにも効果伝わらないし、完全に耳が痛かった
- シェーダはやるやる言ってて中々踏み出せてないのそろそろどうにかせなアカン
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日前に故障の予兆を捉える
- バイオヘルスケア
- 更なる可能性/発展性
- ゲノム解析によるがん治療
- 客観的な多数の情報からで0たに基づく医療が実現出来る
- コミュニケーション
- 直前のワードには反応出来るが、文の意味や文脈は理解できていない
- クリエイター
- 画像の自動生成
- 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の場0ジョンアップに寄る仕様変更の弊害
- ゲーム開発における選択肢を広げる
- 自分たちのやりたい事にマッチするソリューションを採用しよう
- タイトル特化型の最適化をゲームシステムだけでなく、コンテンツパイプラインやワークフローも合わせて構築したい
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はグラフィックの強さを感じる
- スマホは月単位で表現出来るレベルが上がっている
- テクニカルアーティスト、エンジニアとデザイナーを繋ぐ環境作り
- 芦原さん
- テクニカルアーティストみたいな人がスマホでも重要になって来た
- 池田さん
- (自分が作りたいもの) アクションゲーム作りたい!
- モバイルゲームは時間内中で一番楽しい所やってもらうのはいいこと
- 没入感にもっと踏み込んだコンテンツを提供したい
- 恵良さん
- 作りたいゲームは特に無いが、作りたいメンバーが気持ちよく作れる環境を作って行きたい