こんにちは。SWETの加藤です。
1月29日、DeNAは技術カンファレンス「 DeNA TechCon 2016 」を開催いたしました。 DeNAエンジニアブログでは数回に渡りその内容を振り返り、発表がどのようなものだったかをご紹介します。
第2回となる本記事は、以下の講演についてのものになります。
DeNAのゲーム開発を支える技術クライアントサイド編
弊社の BONO HIRONORI による、HTML5のブラウザゲームの基盤技術の発表です。
DeNAがパートナーに提供している、 CreateJS ベースのゲームエンジン CreateJS-Lite（仮）と、さらにネイティブAPIを使うことにより高速化したCreateJS-Lite Acceleratorが紹介されました。
CreateJS-Lite（仮） Acceleratorは近日リリース予定の ラプラスリンク に使われています。
ちなみに、 CreateJS はオープンソースのJS製ゲームエンジンで、CanvasなどHTML5の機能を利用したブラウザゲームを開発できるものです。
発表概要
CreateJS-Lite（仮）と CreateJS-Lite Acceleratorは、ネイティブアプリ並の品質を、ブラウザゲーム並の開発費で作るために作られているとのこと。
なお、CreateJSの実行速度を10倍にする（！）というミッションで作られたそうです。
CreateJSはもともとCanvas 2Dで画像を描画しているが、CreateJS-Lite（仮）ではCanvasではなくWebGLやNative OpenGL ESを使うことで高速化したらしいです。また、サウンドも、CreateJSで使われるWeb AudioやHTML Audioだけでなく、OpenSL ESも使うようにしているのだとか。
さらに、CreateJS-Lite（仮）では、キャッシュにIndexedDBを利用しているそうです。IndexedDBはバイナリを扱えるので、それを使って画像や音声をキャッシュしているんですね。
ただ、CreateJS-Lite（仮）はCreateJSの100%互換ではなく、バグもあるそうです。たとえば、メモリ使用量が多くなり、CSSアニメーションみたいなCPUを使う機能と同時に使いにくいなど課題もあるのだとか。そういった事情から、CreateJSアニメーションの負担を軽くしたり、不要なCreateJSオブジェクトを削除するなどの工夫をゲーム開発者にしてもらっているそうです。
CreateJS-Lite（仮） AcceleratorはCreateJS-Lite（仮）を更に高速化したものです。こちらはネイティブAPIを直接呼び出しているため、理論上はネイティブアプリと同等の処理速度が出せるようになっています。
感想
スピーカーのユニークな人柄が表れた発表でした。「CreateJSの速度を10倍にする」と聞いたときは本気かこの人はと思ったものですが、やろうと思えばネイティブアプリレベルまで高速化はできるんですね。驚きました。
DeNAのゲーム開発を支えるGame Backend as a Service
Sakashoという、社内で開発・運用しているBaaSについての発表です。Sakashoはネイティブアプリゲーム開発のサーバサイドを担当するもので、これさえあれば、ゲーム開発者がサーバ側の開発をほぼしなくてもよくなります。
Sakashoという名前が表に出るのは今回初めてとのこと。妙なネーミングですが、これは日本酒のプロフェッショナルを意味する「酒匠」からとったようです。
なお、当初は弊社の YOKOTA TAKEHIKO ( @i_am_skirnir ) が発表する予定だったのですが、スピーカーを交代して HARUYAMA MAKOTO ( @Spring_MT ) の発表となりました。
発表概要
Sakashoはゲームのサーバサイドを担当するが、それをクライアントで利用するためのSDKも提供しており、課金・Push通知などOS依存の機能も用意しているそうです。ランキング、掲示板、ギルド、ログインボーナス……。「スマートフォン向けゲームならあるだろう」という機能が一通り揃っているとのこと。
Sakashoを開発するにあたり、最初からMicroservices的な設計で開発していったのですが、そのことを今は後悔しているそうです。
まず、Microservicesは運用工数がけっこうかかるとのこと。Sakashoチームは10人前後で構成されているのですが、担当を細かくわけてはおらず、全員が全部を見る状態になっていて、結局管理工数が大きくなってしまったのだとか。今では「最初はモノリシックな作りにして、あとで必要になってから分けたほうがよかった」と考えているそうです。
また、Sakashoの開発言語にはRubyを選択したそうです。DeNAはPerlの会社のイメージが強かったが、Rubyで開発、運用をこなしているメンバーが多かったし、フォローできる人材もいたため、Rubyを採用できると考えたのだとか。
ただ、Perlで作られた資産をRubyに移行するにはそれなりの苦労もあったようです。たとえば、DeNAで使っているdaemontoolsでRubyのWebアプリケーションを管理するための仕組みを作ったこと（詳しくは 「Server::Starterに対応するとはどういうことか」の補足 に書かれています）や、社内でのPerl Webアプリケーションと同様の運用体制を実現するために、UnicornのWorker状態監視ライブラリやUnicornのデバッグ用ライブラリを作ったことなどが話題になりました。ほかにも、社内Rubygemsサーバーを構築したり、社内アプリ配信ツールのIotaをRailsで作って、社内での実績を作ってRubyへの信頼を高めていったそうです。
感想
Sakasho便利そうですよね。これがあったら、面倒な、それでいて必要不可欠な作業がかなり省略できて、ゲーム開発が楽になりますね。
Microserviceの失敗について、率直な振り返りがなされたのが印象的でした。開発の初期段階ではモノリシックに作ったほうが効率が良くなってしまうのですよね。設計をMicroservices的にするかはよく考えてからのほうがよく、もしもMicroservicesにするのなら、軌道に乗ってからにすべき、という教訓が得られました。
そういえば、先日開催された Cookpad TechConf 2016 で、 巨大なモノリシックアプリケーションとなったサービスの分割に関する発表 がありました。こちらの発表では、モノリシックなアプリケーションを分割するのに苦労したという話だったのですが、開発効率の観点からすれば、開発の初期ではモノリシックに作ったほうがよく、最初期にモノリシックなサービスにしたのはむしろ大正解だったのではないかなと思いました。
また、開発言語にRubyを採用した結果、自分たちでRubyのライブラリをたくさん作ることになったというエピソードも興味深いです。Webアプリケーションの開発といえばいまや「とりあえずRubyでRails」と考えてしまいがちですが、案外、PerlにあってRubyにないライブラリがあったりするのですよね。欲しいライブラリがRubyにないとき、自分たちでライブラリを作れる技術力がSakashoチームの強みになっていることがわかりました。
他の来場者の方のまとめ
DeNA TechCon 2016をブログ記事にまとめてくださった方もいます。ぜひこちらもご覧ください。
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。