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

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
DeNA Technology Conference 2017
その後の・・
DeNAのネイティブアプリ開発
1
2017/02/10
Osamu Ikeda
Executive Officer. SVP
Sub Buisiness Unit Head, Japan Region Game.
DeNA Co., Ltd.

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
自己紹介その１〜基本情報〜
名前：池田修（45）
生まれ：Z80
育ち：MC68000
1995 フリーランスでコンソールゲーム開発等々を請け負う。
2000 大手ゲーム会社に入社。
2011 DeNAへ転職、エンジニアとして入社。
2017 いまだにDeNAでは仕事でコードを書けていない。。
2

自己紹介その２〜趣味〜
音楽（ギターとかベースとか）、自転車が趣味です。
一昨年は、Schecterの８弦ギターを買いました。楽しいです。
去年は、YAMAHAのベースを買いました。楽しいです。
3

自己紹介その２〜趣味〜
ちなみに、最近好きなギタリストはこの辺。
Tosin Abasi
Marco Sfogli
John Petrucci
Guthrie Govan
4

アジェンダ〜本日話すこと〜
DeNAのネイティブアプリ開発の戦略に関して、昨年資料をベースにおさらい。
課題となった点をピックアップして、技術的な観点で深堀。
新たな課題、継続している課題について。
対象となる人：
アプリの開発に興味のある人。
アプリの開発をこれから始める人。
アプリの開発に苦戦している人。
…を中心にDeNAのゲーム開発に興味のある皆様。
5

DeNAのゲーム年表
それでは昨年話したことのおさらいから
6

DeNAのゲーム開発の変遷
〜DeNAがどういうゲームを作ってきたか〜
7

2009 ブラウザゲーム for ガラケー
↓
2011 ブラウザゲーム for スマートフォン
↓
2013 Kickmoter
2013 ブラウザゲーム（SPA）
↓
2015 ネイティブアプリ
8
「怪盗ロワイヤル」
（2009）

↓
↓
2013 Kickmoter
↓
9
「怪盗ロワイヤル」SP版
（2011）

↓
↓
2013 Kickmoter
↓
10
「三国志ロワイヤル」
（2013）

↓
↓
2013 Kickmoter
↓
11
「ダンジョンポッパー」
（2013）

↓
↓
2013 Kickmoter
↓
12
「パズル戦隊デナレンジャー」
（2015）

↓
↓
2013 Kickmoter
↓
13
「戦魂」
（2015）

↓
↓
2013 Kickmoter
↓
14
約５年間の進歩

お詫び
15

↓
↓
2011 ngCore
↓
2013 Kickmoter
↓
16
「忍者ロワイヤル」
（2011）

↓
2011 ngCore
↓
2013 Kickmoter
↓
↓
2016
マルチプレイや3Dのアクション制御にチャレンジしたネイティブアプリタイトル群をリリース。
技術的なチャレンジとクオリティの向上を両立して、絶賛配信中！
17

ネイティブアプリ開発の始動
〜敵を知り己を知れば百戦危うからず〜
18

戦力分析
以下の17項目で150名以上のゲームエンジニアのスキルを評価。
 SystemDesign -ゲームシステム全体を設計するスキル。
 PlayerControl -ユーザの入力にり、ゲームオブジェクトを動かしたり、情報を画面に反映させたりする実装のスキル。
 CharacterAI -ゲーム側のロジックにより、キャラクタ等を動作させる設計、実装のスキル。
 Collision-2D- - ２Ｄゲームにおけるコリジョン判定に関する実装のスキル。
 Collision-3D - ３Ｄゲームコリジョン判定に関する実装や、マップや地形等に関わる制御処理の実装のスキル。
 Physics -力学ベースの挙動の実装に関わるスキル。
 EventControl -ゲームイベントやシナリオの進行制御に関する実装のスキル。
 MemoryHandling -メモリ管理の実装のスキル。
 ResourceHandling -データ管理、処理に関する実装のスキル。
 2DGraphics - 2Dにおけるグラフィック処理の実装のスキル。
 3DGraphics - 3Dにおけるグラフィック処理の実装のスキル。
 Motion – モーション処理に関連する実装のスキル。
 DynamicAnimationSynthesis -アニメーション遷移やモーションブレンディングを使ったアニメーションの動的生成のスキル。
 Effect -エフェクト処理に関連する実装のスキル。
 UI -メニュー画面等のＵＩに関連する実装のスキル。
 Sound -サウンド処理に関連する実装のスキル。
 Movie -動画処理に関連する実装のスキル。
19

戦力分析
１７項目５段階評価で６８点満点。
０pt Beginner（未経験）
１pt Junior（一定の経験と知識はある）
２pt Middle（自走可能）
３pt Senior（該当領域でタイトルをリードできる）
４pt Expert（該当分野で業界でもトップクラス）
評価結果
平均：4.8pt
全項目が0pt、Beginnerのスタッフの割合：75.7%
50pt以上のスタッフ：３名
20

市場分析
市場のアプリを開発難度や技術要素で評価。
Seg1：一目でHTMLによる画面とわかるWebベースのゲーム。
Seg2：単純なHTMLでは作れないがインタラクションが弱いゲーム。
Seg3：相当頑張ればWebベースでも可能なインタラクションの強いゲーム。
Seg4：リアルタイムで複数のオブジェクトが並列制御される、アプリでないとできないゲーム。
Seg5：30FPS以上で3D / 物理演算等の高負荷もしくは開発難度の高い技術を前提としているゲーム。
調査結果：2013-2014 Q1の日本市場の状況
21

市場分析〜参考情報〜
22
2014 Q1(JP) 2015 Q1(JP)
2014 Q1(US) 2015 Q1(US)

開発要素の分析〜Webからアプリへの変化〜
プログラミングパラダイム
マルチメディアデータ
リソースマネジメント
チート
23

ネイティブアプリ開発環境と体制
〜DeNAがどうやってゲームを作っているのか〜
24

ゲームエンジン
DeNAでは二つのゲームエンジンを採用している。
Unity
主に3D系のゲームで利用。
豊富な機能群が開発を後押ししてくれる。
アプリ開発に経験の少ないスタッフでも入りやすい。
LiftEngine
主に2D系のゲームで利用。
Cocos2d-xベースの独自ゲームエンジン。
もはや、かつてCocosであったかも定かではないほど改良されている。
タイトルにあわせたカリカリのチューニングが可能。
25

サーバーサイド
ロジックをクライアントに寄せているので、ゲーム毎に専用のサーバの開発するこ
とは少ない。
Sakasho
ゲームアプリ向けの内製BaaS。
ユーザ管理や決済 / 計上系、資金決済法対応等の工数を一手に引き受ける。
ゲームに特化した機能も多く用意している。
IRIS
マルチプレイゲーム用のサーバ。
汎用的に利用できるような構成になっている。
26

ネイティブアプリ開発苦労話
〜失敗は成功の母〜
27

実際やってみて
ネイティブアプリ開発開始に予測した下記の課題は・・
プログラミングパラダイム →苦労した人はいたが概ね◯
マルチメディアデータ →１回ミスると大体覚えたけど△
リソースマネジメント →パフォーマンスはズルズル下がりがちだったので△
チート →意外とちゃんと対策できてて◯
うまくいかなかったところも、予見できていたので致命的な問題にはならず・・
28

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

なにかの処理の終了を検知して別の処理を実行したい場合・・
コールバック
該当処理が終わったら指定したコールバック関数が呼ばれるので、その関数で必
要な処理を行う。
ポーリング
該当処理が終わったかどうかを判定する関数が提供されるので、その関数の戻り
値で、もしくは、該当処理の駆動関数の戻り値で終了判定し、必要な処理を行う。
30

記述が簡易で馴染みやすいコールバックだが、いくつか落とし穴が。。
タイミング的にコールバックが呼ばれると困るケースの対応。
コールバックが呼ばれない、もしくは２回呼ばれた場合の対応。
逆に該当処理を２回呼びたい場合の対応。
もはや、該当処理が必要なくなった場合の対応。
タイムアウトを入れたい場合の対応。
マルチスレッドへの対応。
複雑な処理の中で様々なケースに対応しようとすると、結局ポーリングに近い実
装になってしまう。また、コールバックを呼ぶ側、呼ばれる側のどちらでなにを
保証するのか、設計が複雑、冗長になりがち。。
31

個人的には最初からポーリングで実装することをオススメします。
32

「でも使ってるミドルウェアのI/Fがコールバック形式なんです！」
33

ミドルウェア等でコールバック形式を要求されている場合でも、アプリケーショ
ン側の実装スタイルに合わせて適切にI/Fを変換しましょう。
コールバック関数内では、簡易なステータス変更のみを行い、そのステータスを
ポーリングするようなI/Fに変換すればよいと思います。
コールバック関数内の記述が長くなってきたり、色んな関数呼び出しが含まれる
ようになってきたら、ご注意を！
34

RDBMS vs 構造体
35

RDBMS vs 構造体
キャラクタのパラメータのデータ構造を設計するとして・・
サーバエンジニアの作るデータ
CREATE TABLE character_data (
id int,
名前 varchar,
ライフ int,
攻撃力 int,
防御力 int,
素早さ int
);
※ライフ値の取得
SELECT ライフ FROM character_data WHERE id = 1;
36

RDBMS vs 構造体
クライアントエンジニアの作るデータ
typedef struct (
char 名前[ MAX_NAME ],
int ライフ、
int 攻撃力
int 防御力,
int 素早さ
} character_data;
※ライフ値の取得（IDが連番の場合・・）
int life = character_data[ 1 ].life;
37

あまり違わないですね…？
38
RDBMS vs 構造体

ここにも落とし穴が…！
39
RDBMS vs 構造体

RDBMS vs 構造体
Sakashoの扱う２つのデータ
アセット
 クライアントのストレージに永続的に記録されるデータ。
 グラフィックやサウンドなど、更新頻度が低くサイズの大きなデータはこちらで扱うことが多い。
 ゲーム起動時に全てダウンロードする前提であることが多い。
マスタ
クライアントのメモリ上で扱われ、都度ダウンロードされるデータ。
更新が頻繁なデータや、利用期間が限定的なデータはこちらで扱うことが多い。
（※「アセット」と「マスタ」という言葉の使い分けかたはたぶんDeNAの方言です。）
双方提供するAPIの機能としては大きな違いはなく（名前を指定してダウンロードするのみ）、用
途に合わせて更新の検知ための仕組みや、管理のための機能が違うだけ。
40

RDBMS vs 構造体
Sakashoはクライアント側のアーキテクチャを優先するために、サーバサイドで
はあまりデータ管理の機能はもたず、クライアントのストレージの延長程度のシ
ンプルで汎用的な機能だけを提供していた。
41
マスター
アセット
Sakasho

RDBMS vs 構造体
例えばクエストを配信するとしたらこんなイメージ。
42
マスター Sakasho
クエストデータ（ファイル）

RDBMS vs 構造体
が、サーバーサイドの感覚で実装したらこうなった。
43
マスター
アセット
Sakasho

RDBMS vs 構造体
が、サーバーサイドの感覚で実装したらこうなった。
44
マスター
アセット
Sakasho
DBのテーブルのような、巨大な表をそのままクライアントに転送。
メモリ内に置かれたDBのように扱った。

前述の「CRATE TABLE」と「typedef struct」は
個人的にこんなイメージ。
45
RDBMS vs 構造体

RDBMS vs 構造体
サーバエンジニアの作るデータ
CREATE TABLE character_data (
id int,
名前 varchar,
ライフ int,
攻撃力 int,
防御力 int,
素早さ int
);
※ライフ値の取得
SELECT ライフ FROM character_data WHERE id = 1;
46
サーバサイドのデータの取り扱い
 RDBMSの豊富なデータ管理機能を利用できる。
 サーバスペックの潤沢なメモリが利用可能。
 クライアントからのネットワークアクセスが前提なので、そ
こまで高速な処理は求められない。

RDBMS vs 構造体
クライアントエンジニアの作るデータ
typedef struct (
char 名前[ MAX_NAME ],
int ライフ、
int 攻撃力
int 防御力,
int 素早さ
} character_data;
※ライフ値の取得（IDが連番の場合・・）
int life = character_data[ 1 ].life;
47
クライアントサイドのデータの取り扱い
 データ管理機能は限定的。
 利用できるメモリは限られている。
 描画レートを維持するために、高速なアクセスが必要。
 データにPKが入らないケースも多い。
※PKはデータ名、ファイル名に入る。
※IDのオフセットによるメモリアクセスが当然高速。

RDBMS vs 構造体
さて、この実装・・
48
マスター
アセット
Sakasho

RDBMS vs 構造体
クライアントでもサーバサイドのDBと同じ感覚でデータを扱えるのはよかったか
もしれない・・が。
とにかくデータがデカい。
データ転送に時間がかかり、ゲームの起動が遅いし、メモリの消費量も激しい。
モバイルのインターネット接続はサーバ-DB間ほど速くない。
クライアントはサーバほどメモリが潤沢ではない。
運営を続けるに従ってデータが追加されるので、転送時間もメモリ消費も増加傾向。
低スペック端末では、メモリ不足で起動しなくなるまでのカウントダウンが始まってしまう！
しかも、自前で実装しない限りは、DBほどデータ操作のための機能は充実していない。
開発段階において「巨大な表」はメンテナンス性が低く、トラブルも多かった。
49

RDBMS vs 構造体
マスタデータのメンテナンス、大変ですね・・
50
Sakasho
開発環境
個人環境個人環境個人環境
たいてい激しくConflictしますね。

RDBMS vs 構造体
プリプロセスを導入しましょう
51

RDBMS vs 構造体
複数のファイルを統合して最終的なマスターとするプリプロセスは有効。
52
Sakasho
開発環境
個人環境個人環境個人環境
プリプロセスで統合

RDBMS vs 構造体
どういう単位でデータを分割するかは重要な戦略。
 配信・ダウンロード単位がいいの？
 作業者によって分割しておくのがいいのか？
 データの有効期限も重要。
 一覧性が開発効率に大きく寄与する場合は分割しない選択も。
最近のDeNAのゲーム開発では、作業者によって分割されたデータをダウンロー
ド単位にパッケージしつつ、バランス調整等で一覧性があったほうが利便性で勝
るデータについては、まとめておく・・・というハイブリッドなプランがトレン
ド。
全てをランタイムで処理する必要はなく、プリプロセスでできることは、あらか
じめ処理しておくというのも有効。
53

RDBMS vs 構造体
ただし、この話の思想は若干オジさん的です。
（※とにかくメモリは節約！節約！！・・の世代）
モバイル端末でもマシンスペックの進歩が著しく、
今後CPUパワーやメモリは余り気味になるかも知れません。
ランタイムの処理効率と開発効率のバランスは適切に！
54

Webサーバ vs （アプリの）ゲームサーバ
55

Webサーバ vs ゲームサーバ
クライアントにゲームロジックや各種制御を寄せるという戦略と、Sakasho開発が先行したこと
もあり、サーバ開発当初は設計思想を切り替えられないメンバー、目指す世界観が理解できない
メンバーが続出。
サーバサイドエンジニアが、「Web頭」から「アプリ頭」への切り替えに、半年くらい時間がか
かることもしばしば。
一方、クライアント開発に転向したエンジニアは、もっとはやく新しい技術をキャッチアップし
ていった。ゼロベースでフラットに学習できることや、プロジェクトとして締め切りがあり、手
を動かして問題を解決していくことによる学習効果が高かったからだと思われる。
現在は複数のアプリタイトルが運用され、開発中の案件も多い。Webサーバを開発してきたエン
ジニアがアプリのゲームサーバ開発を学習する環境も整ってきたので、キャッチアップ期間も短
縮されきた・・はず。
56

が、まだゲームサーバ開発への切り替えに苦労する人が多く、
キャッチアップ期間もかなりかかる！
57

なぜキャッチアップに時間がかかるのだろう？
そもそも論で、やはり設計思想の切り替えには一定の学習コストが必要。
クライアント開発スキルが低いので、クライアント環境の構築やクライアント側のソースコードを確認す
ることによる学習が難しい。
既存のサーバ側のコードを読んでも、クライアント側の処理がわからないので、全体像が掴みにくい。
しかも汎用的に使われているので、ユースケースが様々でさらにわかりにくい。
「コード読め！コラ！」って言われて読んだけどやっぱりよくわからん…という状況
そんな状況で運用中のタイトルも多くなっているので、運用タスクも多い。
言われてみると確かに難易度が高い。。
58

振り返ってみると・・
「ネイティブシフト」をしてみたら、実はサーバサイドが一番辛かった。
・・というお話でした。
59

ご静聴ありがとうございました！
60

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

More Related Content

What's hot

Similar to その後のDeNAのネイティブアプリ開発 #denatechcon

More from DeNA

Recently uploaded

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