TechCon2017 - D-Stage04:DeNA内製ゲームエンジンの現状と目指す未来(惠良和隆)

2017年2月10日に開催された「TechCon2017」のなかで、ゲーム事業本部開発基盤部部長の惠良和隆によるセッション「DeNA内製ゲームエンジンの現状と目指す未来」が行われました。DeNAのゲーム開発を支える内製ゲームエンジン『Lift Engine』の現在と未来についてお話しました。

トピックス一覧

1. 自己紹介
2. 内製ゲームエンジンLift Engineとは?
3. Lift Engineの現在
4. Lift Engineが目指す未来
5. まとめ

自己紹介

画像

みなさん、初めまして。DeNAの惠良と申します。
今日はDeNAの内製でつくっているゲームエンジンがあるんですけども、そのゲームエンジンについての説明、紹介と、今後どういう方向に向かっていくのかということについてお話します。

画像

まず、私の自己紹介からなんですけども、私は大学と院を卒業しまして、新卒で株式会社フロム・ソフトウェアというコンソールゲームの会社に就職し、10年ちょっとの間、ゲームをつくったり、基盤部分の開発をやってきたんですけども。
2013年10月、だいたい3年ちょっと前、株式会社ディー・エヌ・エーにジョインしまして、今ではモバイルゲームの基盤部分の開発を担当しています。

画像

それでは次に、今日のお話なんですけども、先ほどお話をしたDeNA内製ゲームエンジンなんですけども、Lift Engineという名前を付けていまして、このLift Engineの説明と、あとは今どういう状況になっているのかというところと、今後、Lift Engineをどうしたいのかを話して、最後にまとめという流れでいきたいと思います。

内製ゲームエンジンLift Engineとは?

まず、内製ゲームエンジン、Lift Engineの説明なんですけども。まず「Lift Engineとは?」と。
ネイティブアプリ開発をDeNAが始めるにあたって、コンテンツに特化したつくり方をしたいという要求がありまして、そのためにできるだけなかまで手が届く、ブラックボックスのないゲームシステム、ゲームエンジンをつくりたいという要望があり、つくり始めました。

画像

最初は、Cocos2d-xをベースにした2Dのゲームエンジンとしてスタートしました。
Cocos2d-xは、結構いろんな使われ方をしてると思うんですけども、便利な反面、つくり方がいろいろ考えられるので迷っちゃうというところがあるので、Lift Engineはつくり方をAPIで意図的に制限して、ゲームシステムの設計とか、そういったものにおける迷いをなくすというポリシーでつくっていました。
あとは、ゲーム開発で当然必要な機能というのが、意外とCocos2d-xに欠けていたんですけども、そういったものを独自に実装しました。メモリ管理であったり、マルチスレッド対応だとか、非同期I/Oだとか、必ず使うだろうと。
この話は、Cocos2d-xが古いバージョンの時代の話なので、最近はどうなっているかちょっとわからないですけども、その当時はいろいろ欠けていたので、そういうものを足していたという感じです。

画像

内製にして何をしたいかといったら、やはりパフォーマンスをしっかりと出していきたい、と。
徹底的に最適化をしていきたいというところがありまして。
Cocos2d-xなので、2D描画が基本ではあるんですけども、その描画に特化して、ダイナミックバッチングを自分でつくったりとか、あとはレイヤー構造をうまく使って、できるだけバッチングしやすいように、マルチレイヤーの構造を独自でつくったりとか、あとはフォントのテクスチャですね。
Cocos2d-xって、システム側のフォントの描画、IPAを使ってフォントテクスチャを生成してるんですけども、それが非常に遅いので、Free Typeによるフォントテクスチャの描画処理というのを自前で全部つくって、できるだけ高速に動くようにしました。
あとはSpriteStudioとか、そういった私製のツールをも使って開発するんですけども、そういった私製ツール、ランタイム部分で、ソースコードが適用されてはいるんですけども、結構パフォーマンスがよろしくないというものが多かったので、シェーダであったりとか、描画の処理フローであったりとか、そういったものをとことん最適化して、パフォーマンスを数倍から数十倍というぐらいに上げるということをやってました。
内製のアニメーション作成ツールでAnimationBuilderというのが、結構昔からDeNAでは使われてたんですけども、それのランタイムを最適化して、Lift Engineに組み込むということをやっていました。

画像

Lift Engineの採用タイトルなんですけど、一番最初にDeNAがネイティブをちゃんとつくり始めて出した「デナレンジャー」というパズルゲームがありまして。
そのあと「ガールアックス」というマルチプレイのゲームを出したんですが、あとほかにも、ちょっとここに出せないんですけども、他社さんでパブリッシュされてるタイトルもあったりします。基本的に全部2Dゲームですね。
といったところが、Lift Engineの簡単な説明になります。

Lift Engineの現在

画像

今どうなってるかということをご説明したいんですけども、もともと2Dゲームエンジンだったのが、今は3Dゲームエンジンに変わりました。
今、変わってる最中と言ったほうが正しいんですけども、これはちょっと、いまさらと思われる方もたくさんいらっしゃると思います。

画像

どうして3Dゲームエンジンに変えようとしたのかということについて、ちょっとお話をしますと、そもそも世の中、Unityとか、Unrealとか、便利なものがたくさんあって。
「なんでいまさらつくるねん」という考えが普通にあると思うんですけども、当然、クイックにものをつくる、ゲームをつくるというだけであれば、全然、Unityで十分なんですね。
一方で、すべてを自由に、ブラックボックスのない開発というものも欲しくなるときがあるんですね。特にビルド回りであったりとか、長く運用を続けるタイトルであると、コンテンツの量が増えてきて、いろいろ取り回しが苦しくなったりすることもよくあるんですけども、そういったときに、自分で解決することができるという環境というのは、やはり欲しくなると。

画像

あとは、ゲーム仕様に特化したチューニングができるというところはやはり大きくて。
先ほどのセッションでいろいろ説明されてたと思うんですけども、ネイティブプラグインで機能拡張することはできるんですけども、性能向上をさせたりというところに関しては、やはり一定の限界はあったりとか。あとはUnityって、バージョンが上がると、結構ドラスティックに、0.1上がるだけですごい変わっちゃったりとかするので、そういうところに追従するというのも結構大変だというところがあったりします。

もう一つ、ゲーム開発における選択肢を広げたいというのがあって、3Dゲームをつくる場合、Unityしかないですという状況よりは、もう少し広い選択肢のなかで一番自分たちがやりたいことにベストマッチするソリューションを使おうということができるようになりたいなというのがあって、3Dゲームエンジンをつくると。
あとはやはりタイトル特化のゲームエンジンをつくることによって、より高速な動作を実現するというのもあるんですけども、もう一つ重要なのが、コンテンツパイプラインですね。あとはワークフローですね。特にデータをつくったり、量産したりというところを、できるだけ自分たちのやり方に合ったかたちのものにしたいというのがあって、それも含めて独自の3Dゲームエンジンが欲しいなというところがありました。

画像

話はちょっと変わりまして、DeNAにおけるアプリ開発の状況をちょっとお話しますと、DeNAはちょっとアプリへの参入が遅れたんですね。2013年末ぐらいから着手が始まって、選択と集中をきちんとやってきたおかげで、なんとかネイティブアプリの開発はできるようにはなってきたんですね。今回、TechConでいろいろとお話をさせていただいてる基盤技術であったりとか、ほかにもいろいろあるんですけども、そういったものを積み上げてきて、ゲーム開発をするエンジニアは、できるだけコンテンツの開発に集中すると。
いろいろ覚えなきゃいけないことはあるんですけども、全部やると、どうしても薄くなってしまうので、ゲームそのものを面白くする部分、手触りをよくするとか、そういったところに注力してもらうということをやってきて、なんとかネイティブアプリの開発はできるようにはなってきたんですが、一方で、結構課題もまだ残されてるなという認識があって。

例えば、効率的な運用ができない、と。
アプリだと、やはりすぐに更新できないと。iOSの場合はAppleさんの審査が必要だったりということもありますが、それ以上に開発そのものが大変だというのが実際のところです。
最近のゲームって結構複雑になってきて、コンテンツ量も増えてくる、と。
一つのイベントをやるにあたっても、投下する必要なデータ量も増えてくるし、イベントを開催する頻度も高くしないと、ユーザーさんに楽しく遊び続けてもらえないということがあったりとか、そういうことがあって、つくる量が多くなってきて大変になると。
そうすると、やはりチームの規模も大きくなってきて、チームの規模が大きくなると、お約束で生産性がどんどん下がっていく、と。大量のものを大量の人数で一斉につくろうとすると、やはりなかなかうまくいかないということがありますと。この課題をなんとかしたいなというところがあります。
これはべつに内製のゲームエンジンをつくるからという話だけではなくて、Unityを使った開発でも、同じ課題は当然あって、それはUnityを使った開発でも、同じように解決しなければいけないんですけども、この部分について、内製エンジンをつくるからこそ、取り得るソリューションというのをちょっと考えてやってみようということで始めました。

画像

Lift Engineを3D化するというところにあたっては、このような要件を出していました。
まず、DeNAが目指すゲーム開発の方向性に合致するもの、と。
これは当然ではあるんですけども、基本的には面白いゲームをつくるために、われわれはゲームをつくってるんですけども、なんでもできる汎用エンジンを求めるわけではなくて、自分たちがつくりたいものに合わせたもの、必要のないものはつくらない、と。基本的には、ゲームエンジンをつくることが目的ではないので、ゲームをつくるためのものとしてやっていく、と。
あとは、先ほどから話してる効率ですね。開発効率を上げるというのは、結局のところ、ゲーム品質を上げるためのTry&Errorをしやすくするということにも直結するんですけども、ワークフローだったり、ツールだったりとか、ゲームエンジンそのものも含めて、いろいろ最適化をしていって、できるだけ開発効率を上げましょうというものも求められました。

それと、自分たちのゲームづくりに最適化した環境そのものをつくりやすくするというところですね。
もうできあがったものを提供するだけじゃなくて、ゲーム開発チームが、自分たちでワークフローをしっかりと組み上げていって、効率的な開発をできるようにする、と。そういったものが必要だろうと。

あとは、場合によっては、タイトルごとに必要な部分をあらためて再実装する。
できないことはないよというようなかたちで提供するという感じですね。基本ポリシーとしては、こういうものを要件として挙げてるんですけども、重要なことは、便利なものが高効率であるというわけじゃない、と。
ここは結構気にしていて、なんでもできるものとか、すごい先回りをしていろんな機能を足すということがすべてプラスに働くわけではないので、やはり自分たちが必要になったものをきちんとつくって提供していくということをやっていこうというように進めています。

画像

概要としては、先ほども言いましたけど、3Dエンジンを開発することが目的じゃないので、ゲームをちゃんとつくりやすいようにする、と。
そのためには、これまで以前に、2Dゲームエンジンのときに取っていた立ち位置からちょっと変えて、新しいLift Engineとしての立ち位置を再定義しましょうということをやりました。
重要なのは、ゲームそのものに対して制約を与えないことではあるんですけども、ちょっと全然、逆のことを言ってるとは思うんですけども、ゲームづくりへの制約というのは、一定与えはするんですけども、できるだけその制約というのは柔軟に変えていけるようにしたいというように思ってまして、レイヤーとして、下のほうのレイヤーではできるだけ自由度を高くして、アプリケーションに近いところのレイヤーで制約を掛けていくというような構造にしようと考えました。なので、Lift Engineは、プラットフォームのAPIラッパーとして生まれ変わらせると。
あとは3D化を行うためにどうしても必要になるものなんですね。
プリミティブな機能というのもつくりましょうと。汎用的なものというのは当然つくるんですけども、できるだけ自由度が高く、変な制限を、Lift Engineのレイヤーでは付けないようにしましょうというかたちでやりました。以前のLift Engineだと、プラットフォームがありまして、その上にEngineがあって、実際にはこのなかにCocos2d-xとかも含まれてはいて、アプリケーションがその上に載るという構造だったんですけども、これをこういうかたちに変えました。

画像
画像

Lift Engineのレイヤーはあるんですけども、その上にさらにApplication Libraryのレイヤーを足しまして、ゲーム開発はこの上の部分をつくる、と。
この2つを提供するかたちで、Lift Engine全体として運用していこうというかたちにしています。
ここからちょっと具体的な新規機能の実装をしたものを説明しようと思います。

画像

Cocos2d-xベースの2D時代は、普通にシングルスレッドでゲームの処理が回って、そこでシーングラフをトレースして描画するというかたちだったんですけども、それだとやはり処理効率がよくないので、Rendering Threadをちゃんと切りました、と。
これはUnityとかも同じようなかたちになってるんですけども、Main Threadでコマンドバッファを構築して、次のフレームで描画するというようなかたちを取っています。こうすると、Main Threadのほうはできるだけゲームの処理に時間を使って、レンダリングの部分もきっちり1フレーム、レンダリングに回す構造にしました。

画像

ただし、Cocos2d-xベースの描画機能というのもまだ残ってはいるので、それを全部捨てちゃうと、これまでに積み上げてきたものが全部使えなくなっちゃうので、それはよろしくないというところで、先ほどのコマンドバッファベースのレンダリングパイプラインをCocos2d-xのほうにつなぎ込んで、Cocos2d-xの描画もバックグラウンドのRendering Threadでちゃんと描画できるように実装しています。
基本的に描画系のオブジェクトのセットアップは、これまでどおり、Main Threadでやるんですけども、描画処理そのものはきちんとRendering Threadに移行する、と。
結構Cocos2d-xは、中身のところで、OpenGLのAPIをばんばんたたいちゃうんですけども、それをやっちゃうと、コンテキストスイッチが頻繁に起きちゃうので、できるだけそれが起きないように気を付けながら実装する、と。
最終的には、Cocos2d-xの描画処理というのは、全部、撤廃するというか、排除していく方向には向かうんですけども、それがいきなりできるわけではないので、徐々に徐々にやると。それまでのつなぎとして、一応、つないでいるというようなものです。

画像

あとは、お約束の3Dの算術系の演算ですね。ベクトル、行列演算をSIMDで提供する、と。
モバイルの場合だとNEONで実装するものが普通なんですけども、そういったものを使って、さらにプリミティブなコリジョン判定の計算の実装を行うというようなものをつくっています。

あとはシリアライズのための仕組みも提供してまして、クラスオブジェクトを簡単にゲームデータとして扱えるようにするという仕組みもつくりました。
いわゆるC++のtype_infoとか、type_indexみたいなものを独自に実装している。これはなんで独自に実装しているかというと、いろいろとメモリの都合であったり、パフォーマンスの都合であったりとか、そういったところで独自につくったんですけども。こういったものをつくって、シリアライズしやすいように仕組みを提供していると。

あとメモリ管理も新しくちゃんとつくり直していて。
以前は結構ランタイムヒープをそのまま使ってたんですけども、やはりOpenGLとか、そういう物理メモリを意識しないといけないようなAPIは、なかでメモリを確保するときにフラグメントが起きてると、テクスチャがロードできないとか、そういう問題がしょっちゅう起きるので、できるだけゲーム側が使うメモリは、もうプロセスが立ち上がったときにばこっと取ってしまって、それをちゃんと使い回しましょうというところで、自分たちでアロケータをちゃんと実装してやります、と。
マルチスレッドでゲームをつくっていくので、スレッドキャッシュとかを独自にちゃんと実装して、単純に高速なアロケータをつくるだけだとちょっと足りなくて、スレッドセーフにするために同期オブジェクトをロック、アンロックするとか、そういったことをやってしまうと、そこがどうしても遅くなっちゃうので。なので、できるだけ同期オブジェクトに触らずにメモリ確保、開放ができるように、スレッドごとにキャッシュを設けるというようなことをやったりしています。

画像

あとは、先ほどのLift Engineの2D時代にちょっとお話をしたフォント周りの話を、今回もうちょっと頑張ってつくり直しています。Cocos2d-xは、もともと普通にラベル単位で、1つ文字列を表示する単位でテクスチャを生成して、それをSpriteでぺっと貼るというような構造になってたんですけど、それだとバッチ描画、バッチングができないというところがあって、Lift Engine 2Dでは、複数のラベルを1つのテクスチャに全部まとめて描いちゃって、バッチ描画をするということをやってました。
Free Typeを使って、できるだけシステムのフォント描画は使わない、と。
システムのフォント描画自体は悪くないんですけども、Androidのほうは、どうしてもJavaのほうの実装に頼ることになるので、JavaのGCが走ると非常に重くなるというようなことがあったので。Free Typeを使っているんですけども、普通にトゥルータイプフォントのラベルを描画するだけではなくて、ビットマップフォントの描画にも使いたいなというのがあって、ビットマップフォント用の画像描画もFree Typeで動的に行うようにして、レイアウトの仕方はLabelTTFとまったく同じようなかたち。
実際にはこれをさらに拡張したものがあるんですけども、それと同じようなレイアウトの仕方をして、2D、3D、どっちでもビットマップフォントを使う、と。高速にバッチ描画が行われるような構造にしてということをやりました。
あとは、マウスとかキーボードの入力ハンドリングも、ちょっとCocos2d-xの実装だけだと足りないので、できるだけWindowsとかMacのプログラムとして動かしたときに利便性を高めるような、ツール開発のための機能としてこういったものもちゃんと用意しました。

画像

次に、Application Library層の説明をしていきたいんですけども、Lift Engineの上に載ってて、ゲーム側に近い、ゲームに対して直接、制約を掛ける層なんですけども、Arcanaという名前を取りあえず付けて開発していますと。

画像

特にArcanaという名前に意味はないんですけども、Lift Engine 3Dの上位に位置するアプリケーションフレームワークとしてつくりました。
ゲームのつくり方は、かなり制約して、規定しています。
例えば、シーングラフとか、リソースの管理とか、この辺のやり方はきっちりと制約を付けて、こういうつくり方をしましょうというのをアプリケーション側にもう求めてしまう。そういうものになっています。

画像

完全にタイトルごとに独自のレンダリングエンジンをつくるというのもさすがに大変なので、汎用という意味ではないんですけど、共通のレンダリングエンジンですね。
描画パスのコントロールとか、どの描画処理でも必ずいるでしょうというような機能からスタートしまして、あとは標準的な描画の処理、フィーチャーを使ったレンダリングというのを提供すると。基本的に描画の処理はコマンドバッファをつくるということにそのまま帰結するので、ここでコマンドバッファをつくって、Lift Engineのほうでそれを描画するという流れになります。
あとは、先ほどから何度も話しているゲーム開発の新しいスタイル。できるだけ効率よくゲーム開発をするための仕組みを提供するというところで、ツール開発のフレームワークであったりとか、ツールそのものをつくりやすくすることですね。
そういったものであったりとか、先ほど話をしたシリアライズ周りの話。そういった機能をちゃんと使うためのものというのを提供する、と。
あとは汎用だけど、ゲーム仕様に寄ったモジュールの提供。
例えば、パーティクル・システムであったりとか、物理シミュレーションであったりとか、アニメーションであったり、AIであったりとか、いわゆるゲームテクノロジーでよくあるものなんですけど、そういったものをモジュールとしてArcanaのなかに提供していく、と。
実際にはよりアプリケーション寄りのモジュールとしてつくることにはなるんですけども、こういったものを提供していきましょうということでやっています。

画像

まず、どういうものを強く規定するかというところについて説明しますと、シーングラフですね。一般的なシーングラフとそんなに変わらないです。Unityみたいなゲームオブジェクトとか、そういう概念をちゃんと入れて、親子関係をここでつくっていきましょう、と。コンポジションの概念をちゃんと使って、機能拡張というのをやりやすくすると。シーングラフノードはいろんなものを用意してあって、それぞれに振る舞いをちゃんと設定しておいて、その組み合わせによってゲームのなかをうまく表現してくださいという構造にしています。
シーングラフ自体はシリアライズ可能で、そのまま、例えばプログラムでハードコードしてつくったものをファイルに吐き出すということができるようになっていますと。

次にリソース管理なんですけども、ゲームが使用するリソース、例えば、ジオメトリモデルですね。あとはマテリアル、テクスチャとか、シェーダーとか、あとはアニメーションデータで、UIのレイアウトであったりとか、オーディオデータであったりとか、いろいろあるんですけども、こういったリソースの取り扱いはできるだけ統一化しましょうというかたちをしています。
それだけじゃなくて、ゲーム側で独自に実装しているカスタムクラスも当然あるんですけども、そういったカスタムクラスもしっかりとシリアライズできるように扱う、と。
この辺のリソース管理というのは、ゲームのなかだけじゃなくて、ゲームを開発するためのツールを開発すると思うんですけども、そういうツールでも同じルールを適用すると。同じ仕組みでツールの開発でのリソース管理を行えるようにするというものを規定しております。

画像

あとはレンダリングエンジンも、ある程度、提供してるんですけども、結構モダンなレンダリングフィーチャーを提供しています。
Deferred Rendering、Forward Renderingというのはあるとしても、Physically Based Renderingとか、Image Based Lightingとか、HDRとか、Screen Space Ambient Occlusionであったりとか、Screen Space、ピクセル単位のMotion Blurを入れたりとか、Shadow Mapとか、Soft Shadowとか、ありがちなやつなんですけども、こういった比較的モダンなレンダリングの技術というのも提供しています。

画像

これらのレンダリング技術は、技術的には、だいたい前世代ですね。PS3とか、Xbox360とか、それぐらいでAAAクラスのタイトルが提供してたような技術ではあるんですけども、それとほとんど同じぐらいの技術を使えるようにはなってきたかな、と。PS4とか、Xbox ONEとか、最近のPCとか、現行世代の技術はさすがにまだ性能が足りてないんですけども、そのうち、ハードの性能が上がればできるようになるかなとは思うんですけども、われわれとしては想定スペックを、取りあえず、2020年のころの低性能端末ですね。下位スペックの端末をターゲットにしていますと。このぐらいの時期の低スペック端末だったら、PS3やXbox360くらいのグラフィックスは、なんとかさばけるんじゃないのかなというように予想しています。
課題としては、ちょっとメモリ帯域が課題としてあるんですけども、それもなんとかなるんじゃないのかなというように考えています。2020年の低性能端末というと、例えば、どんなものかというと、iPhone 7とか、3年後とかになると、当然もうスペック的には低スペックになってくるので、そういったもので普通に動くような技術を使っていくというように考えています。
ただ、先ほど見せた、こういった技術なんですけども、全部使うわけじゃなくて、タイトルごとに必要なものを選択して使ってくださいよというかたちで考えています。なので、全然もう、もっとクラシカルな表現をするということもありますし、比較的ハイエンドな表現をするということもあります。

画像

その次に、ツール開発環境も結構大きめのフィーチャーとして提供してまして、Lift EngineとArcanaを使ったゲーム開発をする場合、主に開発はWindowsかMacですね。基本的にはWindowsアプリとMacアプリをつくるというようなかたちで開発を進めます。
モバイル用のビルドというのは、実機で確認したいときだけしか使わないというようなかたちでやってます。ゲームの実装の大半はもうDLLに寄せちゃって、ゲーム本体であったりとか、ツールがその実行ファイル、DLLを動的リンクすると。ゲーム本体がここに入ってて、それをちょっとラップするようなゲームの実行ファイルだったりとか、ツールだったりというものをこういう構造にしています。これによって、ゲームの機能を、ゲーム本体だけじゃなくてツール側も使うということができるようになってます。

画像

次に、ゲームの実装をDLL化するメリットというところについて軽く話すと、基本的にはメタデータの共通化ですね。
先ほどから何度かお話をさせてもらってるんですけども、シリアライズの機能というのをつくってるんですけども、シリアライズの機能って、基本的にはそのクラスのメタデータをどう扱うかというところなんですけども、このメタデータは、例えば、floatの値ですとか、intの値ですよとか、floatのベクトルですよとか、そういった情報が入ってるわけなんですけども、これをちゃんと読んであげることによっていろんなことができると。
例えば、ツールのUIを、Inspectorなどに表示するUIを自動的に生成してあげたりとか、そういうことができる、と。

あとは、不必要にファイルフォーマットをつくる必要がない、と。
とにかくシリアルにしてファイルに吐けばいいというところで、デシリアライズを簡単にやることもできるようになるので、専用のフォーマットを何個も何個もつくって、パースを何度も何度も書くということをしなくてもいいということは非常にメリットが大きいかなというところですね。

あとはCUI、GUIのツール。
どっちに限らず、ゲームのなかで使うデータを直接扱うことができるので、それが便利なんですけども、ただそれだけだと、こういったツールをつくるのもなかなか大変なので、ツールをつくるためのベースのテンプレートを用意して提供してたりということをやっています。
あとは、こういった全部を含めて、できるだけゲーム開発チームが自分たちの開発作業効率を上げるためのカスタムツールをつくりやすくするというようにしています。

画像

ざっくり言うと、こういうものがあるかなと。
例えば、Excelを使って、データをつくって、それをConvertしてゲームで使うであったりとか、GUIのツール、プレビューがないようなものですね。それがデータを吐いて、それをゲームが使うとか。あとはGUIでプレビューがあるようなものだと、直接それをプレビューで見ながら調整して、最終的にはゲームのほうにデータを流す、と。
あとはゲームエンジンそのもののなかで、Debug機能とかでパラメーター調整できるような仕組みであったりとか、そういうパターンの開発環境というのを簡単につくれるようにするというところが、やっていきたいメインのところになります。

画像

あとは、提供するモジュール。
先ほど言いましたけど、Particleであったりとか、Post Effect、Animation、AI、Collision、Cloth Simulationとか。こういったものがいろいろあるんですけども、この辺はタイトルが必要になったときに随時入れる、と。先回りしてつくることは基本的にしないというポリシーでやっています。

画像
画像

ここからちょっとデモをお見せしたいと思います。
これがLift EngineとArcanaを使ったレンダリングで、ちょっと暗いのでわかりにくいかもしれないんですけども、これはDeferred Renderingを使って、物理ベースRenderingしてるというようなものですね。こういう瓶みたいなものとかが、ライトの影響受けて光ったりとか、基本的に全体を一つの同じシェーダーで表現されてるんですけども、こういったものが実際に表現できるようなものになってます。
これは、モデルはちょっと、動きとしてはそんなに大きくないんですけども、基本的には全部一枚のテクスチャで、一枚というか、物理ベースのマテリアルを描き込んだテクスチャは一つで、あとはアルベドカラーと法線方向の情報というようなもので表現されています。

画像

あとは同じエンジンのコアの部分を使ったツールですね。
これはちょっとアニメーションにいろんなデータを載せるようなツールなんですけども、この表示されてる部分というのは、ゲームのコア部分と同じものがそっくり使われてますと。このUI部分は、メタデータを使って自動的に生成するようなかたちになってます。タイムラインでちょっとイベントを仕込んで、そのあいだ、コリジョンが適用されるようなデモなんですけども、これ、ツール自体、まだまだつくってる真っ最中で、全然、完成の域には達してないんですけども、こういったかたちで、できるだけゲーム側の機能というのを使いこなせる。ツールのほうでも使いこなせるようにするということをやっています。

Lift Engineが目指す未来

画像

ここから、この先どういう方向に向かっていくのかということについて、軽くお話をします。基本的に目標としては、先ほどから何度も言っているように、開発効率、運用効率を上げていきましょう、と。
そのためにできることをやっていくということなんですけども、現状はまだまだそろってはないので、開発効率を引き上げるため、仕組みであったりとか、コンポーネントであったりとか、そういったものをどんどん提供するというフェーズになっています。
タイトルの開発に合わせて、それらがそろってくるはずなので、そういったそろってきたツール群をどんどん積み上げていって、次の開発、次の開発と、先のタイトルになればなるほど、どんどん効率が上がるような、そういうかたちでやっていきたいと思ってます。基本的な目標としては、タイトルがリリースするタイミングで、運用効率がもう最高、ベストの状態になってると。最高の状態でタイトルリリースをするのが一番いいなと。人海戦術に頼らないというようなかたちで、少人数でもしっかりとしたコンテンツ開発ができるというところを目指してやっていくと。

あとはグラフィックスに関しては、選択と集中と書いてますけども、基本的にハイエンドのグラフィックスって、お金もかかるんです。それはなんでかというと、単純に人がたくさん必要なんですね。
一つのモデルをつくるにしても時間がかかるので、どんどん並行してつくらなければいけない、と。そういったかたちで、パワーでなんとかするというのがこれまでのコンソールのつくり方だったんですけど、同じようなことをやってしまうと、同じ苦しみを味わうだけなので、できるだけそういう方向には行きたくないなと思ってます。できるだけ、プログラムというか、システム側で表現力というのは引き上げる。デザイナー工数というのは、必要なところには集中するんですけども、全貼りはしないというようなかたちですね。

画像

例えば、自動生成だったりとか、シミュレーションであったりとか、そういったものを積極活用して、できるだけ工数を使わずに表現力を上げるという方向に持っていきたいなと考えてます。あとは先ほど説明した、こういうワークフローですね。パイプラインの部分なんですけども、このイテレーションを徹底的に短くする、と。
できるだけ確認を素早くできるようにするという感じですね。これがやはり当面の目標になります。

まとめ

画像

では、まとめます。
DeNAでは、タイトル開発効率を向上することを徹底していこう、ということをやっています。
これはUnityを使った開発だけではなく、独自エンジンを使った開発であっても、独自のワークフローをきちんとつくって最適化して、それを推し進めていきたいというように考えています。面白いゲームをつくるために、品質向上に時間を割くということが、やはり重要になってくるので、ここをメインにやっていきたいなと思っています。
一番はここなんですけども、面白いゲームをユーザーのみなさんに楽しんでもらうためには、やはり質の高いコンテンツをできるだけ提供したいというように思っていますので、そのためにも、効率的な開発であったりとか、運営体制を整えることに今後も挑戦していきたいなと思っています。
以上です、ご清聴ありがとうございました。


TechCon トップへ戻る

RECRUIT - 募集職種一覧

「DeNAのイメージを破壊」してくれる、ゲームクリエイターを常に募集しています。

EVENT - イベント

Game Developer's Meeting
PAGE TOP

DeNA for GAME CREATORS