Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
世界で渡り合える内製エンジン開発の成功方法を考える!シニア開発者の集い - エンジン各要素の技...
Search
Cygames, Inc.
PRO
September 13, 2016
Technology
5.5k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
世界で渡り合える内製エンジン開発の成功方法を考える!シニア開発者の集い - エンジン各要素の技術選択、特長戦略、開発プロセス、そもそも論まで -
2016/08/24 CEDEC 2016
Cygames, Inc.
PRO
September 13, 2016
More Decks by Cygames, Inc.
See All by Cygames, Inc.
【CEDEC2026】Creative Approaches to Localizing the Dialects and Unique Speech of Umamusume: Pretty Derby Characters in English
cygames
PRO
4
27k
【CEDEC2026】コードレビュー支援ツール開発から学ぶ:LLMを用いた業務システムの実践的な運用設計と誤出力対策
cygames
PRO
0
1k
【CEDEC2026】『ウマ娘 プリティーダービー』 英語版のキャラクターの方言や口調をローカライズするための創造的アプローチ
cygames
PRO
3
1.2k
【CEDEC2026】次世代デジタルカードゲームのサーバー設計と運用 〜『Shadowverse: Worlds Beyond』の舞台裏~
cygames
PRO
2
2k
【CEDEC2026】派手さと見やすさは両立できる!『Shadowverse: Worlds Beyond』エフェクト・3D背景の超進化したビジュアル設計
cygames
PRO
1
1.7k
【CEDEC2026】『Shadowverse: Worlds Beyond』続編開発におけるUIデザイン・アニメーション演出の「超進化」 ~継承と挑戦を両立するデザイン手法~
cygames
PRO
3
5k
【CEDEC2026】『Relink』を拡張せよ - 『GRANBLUE FANTASY: Relink - Endless Ragnarok』の開発速度と品質を守るCI運用
cygames
PRO
1
240
【CEDEC2026】『GRANBLUE FANTASY: Relink - Endless Ragnarok』のバトル制作事例 ~最高のキャラゲーを目指して~
cygames
PRO
2
400
【CEDEC2026】アートとゲームデザインをつなぐVFX設計『GRANBLUE FANTASY: Relink - Endless Ragnarok』における表現と可読性の両立
cygames
PRO
1
1.1k
Other Decks in Technology
See All in Technology
Oracle AI Databaseデータベース・サービス: BaseDB/ExaDB-Dの可用性
oracle4engineer
PRO
1
990
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
54k
1000⼈規模のClaude Enterprise運⽤を「Oktaのグループ」と「Slack」に集約する
sansantech
PRO
1
530
Self Healing Rollouts: Automating Production Fixes with Agentic AI
kdubois
0
100
[2026-08-25]AIによる自動化と人の介入、その狭間で揺れる信頼性についての俺の思いを、波よ聞いてくれ
tosite
0
100
:syncing_time:
sksat
3
870
[RSJ26] Flow as Flow: Modeling Robot Velocity Fields as Probability Velocity Fields
keio_smilab
PRO
0
160
AIレビュー時代に必要なのは、SLOで引く撤退ライン
nobuoooo
0
160
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
3.2k
AWSとAzureのマルチクラウド活用における強い味方___AWS_Kiroを使った二刀流スキル作成.pdf
duelist2020jp
1
150
[ホンマでっか SRE] あなたはなぜ SRE に?
_awache
0
550
internal/testlog で遊ぼう
rokuosan
0
420
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
370
Java REST API Framework Comparison - PWX 2021
mraible
34
9.7k
The untapped power of vector embeddings
frankvandijk
2
1.8k
How to Ace a Technical Interview
jacobian
281
24k
The Cult of Friendly URLs
andyhume
79
7k
Automating Front-end Workflow
addyosmani
1369
210k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
680
Visualization
eitanlees
152
17k
We Have a Design System, Now What?
morganepeng
55
8.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Transcript
© 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みたいにリクエスト ・特定の人ではなく、組織をわけるという手がある ・全体汎用なレイヤーは特定の組織、真ん中はゲーム側から人を捻出して ・タイトル依存はゲーム側で ・続編とかに新機能を組み込むには? ・使わない機能の実装に対してもチームからアサイン ・メリットを説明するほうが大変だよね ・ゲーム開発にエンジン側の人をまきこんでいく ・経営者の方にも理解していただく努力をする ・2作目にも利用するからこそエンジンとしてのメリットが出る、そして進化 する ・海外もそんなかんじ ・タイトルがすごく大きければいんじゃね? ・特化するからこそ価値がでると再認識した ・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をおしてきた ・プロトタイプとか、もろもろの政治的な理由 ・クロージング