© Cygames, Inc. © Cygames, Inc. CEDEC 2016 内製ゲームエンジン ラウンドテーブル 

© Cygames, Inc. ラウンドテーブルの目的とアンケート結果 

© Cygames, Inc. ラウンドテーブルの目的 • 内製ゲームエンジン開発の動機を見出す • 内製ゲームエンジン開発を成功させるためのコツを見出す • 今後のハイエンドゲーム開発戦略を考えるための材料を得る 

© Cygames, Inc. 事前アンケート結果 • 内製ゲームエンジンを開発したことがある 43.6% • 内製ゲームエンジンは必要だと思う 46.2% • UE4、Unity等の既存エンジンを利用した開発を行っている 56.4% • PC/コンシューマゲーム機向けの大規模タイトルを開発したい 23.1% 

© Cygames, Inc. セッション中のアンケート結果 • 会場で「内製ゲームエンジンは必要だと思う」と「PC/コン シューマゲーム機向けの大規模タイトルを開発したい」の2つ について、アンケートを取ったところ、双方とも8割以上の方 が挙手されました。 • 内製エンジンに非常に関心が高い方、大規模タイトル開発経 験が豊富な方に多くお集まりいただいたセッションとなりま した。 

© Cygames, Inc. 参加者の発言内容 セッション当日に会場の参加者からの発言内容を 画面に映しながら進めた際のテキストです。 

© Cygames, Inc. 参加者の発言内容(1) ・そのエンジンでしかできない事が見えてこない ・パフォーマンス等、自社でしかできない事 ・汎用エンジンだと最適化が至らない？ ・自社の文化に合わせられる ・特定のゲームジャンルに特化する ・ハードウェアロンチなどスケジュールの都合 ・ワークフローを変えずに済む ・ワークフローを変える、チームにあわせられる ・時代にあわせにくい？ ・学習コストを下げられるのでは ・既存ゲームエンジンは最先端であり学習コストはいらない？ ・既存エンジンだと生産コストが低い？ ・内製はカスタマイズしやすい ・既存エンジンではエンジンバグの切り分けがむつかしい ・運用に入ったタイトルでエンジンバグがでるとどうしようもない ・バグをすべて自分で直さないといけないのがデメリット ・エンジンのソース公開について ・UE4だとエンジンソースに手を出さなくてよい？（GTMFの事例 ・あまりエンジンソースに手を出して欲しくない？ ・はじめてきいた！ ・UE3がイケてなかった？ ・Epicとしてソースに手を出してほしくない、というような事はない ・エンジン開発者との距離が近い ・サポートに時間かかるなら意味なくない？ ・Unityは開発がヨーロッパなので、日本の人に言っても効果低い？ ・作って成功した、と感じるゲームエンジン ・タイトルがリリースされれば成功？ ・内製ゲームエンジンを選ぶのは、どちらかというと消去法？ ・「どうしようもない」という状況を避ける ・内製ゲームエンジンの開発には覚悟が必要 ・デメリットは？ ・開発コスト、いろいろなテクノロジーに精通する必要がある ・最初に絵が出るまでに時間がかかってしまう ・既存エンジンと比べるときびしい ・それって最初だけじゃね？ ・エンジンアップデートの人手が足りなくて頓挫したことがある ・保守にコストがかかる、新規プラットフォームとか ・環境が整っているのが前提となる ・逆にどういう条件だったら作れるの？ ・流用できるケース（続編とか似ているゲームとか ・採用からの制限。エンジニアを育てたいか、既存エンジンに精通した人を 求めるか ・社内で統一されると効果が高くなる ・大規模かつ複数タイトルであれば内製の価値が高くなる 

© Cygames, Inc. 参加者の発言内容(2) ・より具体的な条件 ・似たようなゲームジャンル ・ブランド ・人材育成 ・中長期的にどんなタイトルかが見えてないと内製は作りにくい？ ・ゲームの特性に応じたエンジンが作りにくい ・請負だとエンジンの指定が来ることがある ・既存と内製だと、技術力の軸線がずれる ・既存エンジンに特化したスキルが身につくので転用がむつかしい ・エンジンごとの作り方＝導入コストなのでは？ ・既存エンジンを使うとしてもそれなりの技術学習が必要なのでは？ ・なにかプログラム言語をマスターしてれば転用は十分可能 ・だったら既存エンジンへの乗せ換えもむつかしくないのでは？ ・逆に社内共有をしていったほうが長期的にはプラスになる ・ゲームエンジン＝礎。それを既存エンジンに頼りすぎるのは危険では？ ・コストはかかるけど、それを払ったほうがよい ・最終的にはプログラマのせいになるでしょ ・つくるのやめたら、もう一回はじめるのは大変 ・エースがいなくなるとエンジン開発が止まる。 ・深刻な問題。人材はすぐ用意できるものではない ・対策あるの？ ・やめさせない ・エンジンがリクルートに役立つ。優秀な人を集めやすい ・技術的なシンボルになる ・既存のエンジンをつかうべきでは ・特定のライブラリに依存した人材をあつめられる ・内製エンジンを公開する、というのはモチベーションとしては弱い？ ・新規アサインされたスタッフの学習コストはデメリット ・それがデメリットになるなら、既存エンジンでよくね？ ・公開エンジンはドキュメント等資料が充実しているはず ・内製だとそこまで手がまわらないよ！ ・既存だとブログとかウェブがある ・社内勉強会とかで若い人を育てることができる ・ドキュメントがないからエンジンソースを見るんだよ ・UE4とかはソースがあるから、それを教育につかうという手もある ・公開すると大きなアップデートしにくいのでは？ ・クローズであれば、社内だけ調整すればよい ・利害関係の調整が社内のほうがややこしい（こともある ・こっちのプロジェクトを優先しろとか ・エンジンチームにヘイト値がたまる ・既存だと、既存エンジンのせいにできる ・社内調整のやりかた、プロジェクト側からエンジン側にジョインする 

© Cygames, Inc. 参加者の発言内容(3) ・ゲームとエンジンは切り離されて話しているが、ゲームを作れなかった 意味がない ・Unity,UE4もそもそもゲームを作るためのエンジンであったはず ・何かのゲームに特化すべき ・そのほうが効率があがる ・なんでもできるなら既存でよくね？ ・ゲームの都合がエンジンに反映されることがある。その切り分けが 難しい ・特化すればするほど、ゲームの性質がエンジンに色濃く反映されてしまう ・だとすると共有がむつかしくなるのでは？ ・ブランチは？ ・保守が。。。 ・特化したければブランチ。可能なものは本流にフィードバック、が メリット ・ブランチするとマージたいへん ・エンジン側ではなくパラメーターとかタイトル側でできることをやる ・レイヤーで吸収できるのでは。低レイヤー、高レイヤー ・ゲーム＝上位レイヤーをゲーム、エンジンどちらとするか ・レビュワー、権限を明示化、Githubみたいにリクエスト ・特定の人ではなく、組織をわけるという手がある ・全体汎用なレイヤーは特定の組織、真ん中はゲーム側から人を捻出して ・タイトル依存はゲーム側で ・続編とかに新機能を組み込むには？ ・使わない機能の実装に対してもチームからアサイン ・メリットを説明するほうが大変だよね ・ゲーム開発にエンジン側の人をまきこんでいく ・経営者の方にも理解していただく努力をする ・２作目にも利用するからこそエンジンとしてのメリットが出る、そして進化 する ・海外もそんなかんじ ・タイトルがすごく大きければいんじゃね？ ・特化するからこそ価値がでると再認識した ・U系エンジンは規模が重要 ・人員、予算等の余裕がない＝既存エンジン ・内製は体力ないと ・そもそも大きいタイトルがないと内製エンジンのメリットでない気がする ・タイトル小さすぎてUnity買えない事例 ・過去のバブル期に作成した内製エンジンが生きている ・大きい部署が作ったエンジンを小さなプロジェクトで利用する事例 ・サポートしきれないので外注に出しにくい ・教育コストに回帰する ・TAが外注先に教育をしにいく事例 (https://www.youtube.com/watch?v=r_yi537h9HQ 22:45付近から) 

© Cygames, Inc. 参加者の発言内容(4) ・使ってもらった結果をフィードバックもらう ・ツールプログラマはゲームのことがわかってないので ・教えてもらいにいく、というスタンス ・エンジンを作るより、社内の知見をライブラリ化し既存エンジンに対応していったほうがよいのでは？ ・CRIとかが近い ・自社で来るとしても、いろいろな既存ライブラリを統合していく必要がある ・スタンスの違い ・社内エンジンの一部を既存エンジンに転用するのはあまりコストかからない ・であれば、必要に応じてやったほうがよいのでは？ ・言語の違い（PerlとRubyみたいな ・たとえば既存エンジンのコアは置き換え可能なの？ ・ジョブとかレンダリングとか ・Unityでグラフィックコアを差し替えた事例 (http://www.gdcvault.com/play/1023002/Low-Complexity-High-Fidelity-INSIDE) ・アップデートコストがすごいことになる ・えらいひとがUnityをおしてきた ・プロトタイプとか、もろもろの政治的な理由 ・クロージング