GCC2018に参加してきた際のメモになります。
ゲームクリエイターズカンファレンス'18 | GAME CREATORS CONFERENCE'18
※ほぼスライドの文字をそのままメモったものになります
たまにお話されていたものも混ざっています
また、メモが追いつかなくて抜けもちょこちょこありますのでご注意ください
◆講演タイトル
『複数タイトルの並行開発を維持しつつ大規模化に適応した中小企業エンジニアの取り組み』
フロム・ソフトウェアの講演です。
◆前提の共有
伊藤 淳さん
Ｒ＆Ｄセクション 部長 プログラマー／ゲームエンジニアアナリスト
会社紹介
280名程度 ほぼ全員開発者
東京 普通の中小企業
キティちゃんとかも作っている
フロムソフトならではの用語の説明
・ライン
ひとつのタイトルの制作を直接担当するチーム
・R&D
研究開発チーム
タイトル制作は行わない
会社全体や全ラインに関係する業務を行う
・チーム間の移動は比較的頻繁に行われる
チームのメンバは固定されていない
複数タイトルの平行開発
・具体的には？
大小5ライン前後が平行
ピークのライン1～2
量産開始中 1～2
プロトタイプ中のライン1～2
エンジニアは全体で70名程度
ライン専属が1ライン10名前後
R&D（とグラフィック）で残り30名くらい
※質疑応答でもR&Dで27～28名とのこと
大規模化
・具体的には？
ハードウェア的には
PS2＞3＞4世代
・主流の画面解像度やメモリサイズは
480i＞720p＞1080p＞2K
数十MB＞数百MB＞数千MB（数GB）
・開発期間
1年前後＞2年前後＞それ以上
◆PS2世代の開発体制
・主流の画面解像度は480i
・メモリサイズは数十MB
・開発期間は1年前後
・シングルプラットフォーム（独占状態）
特定のプラットオーム専用にタイトル開発
他のプラットフォームには移植
具体的なリリースタイトル
・ARMORED CORE シリーズ
・Another Century Episored
・義経
・RUNE
・O・TO・GI
※大体2005年頃までのタイトル
⇒ これらがどのような開発体制だったか？
開発体制
・独自の開発体制を築く
プラットフォームに特化した作り方が効率的
タイトルの内容に特化した作り方が効率的
開発期間が1年前後と短いので
・他ラインと連携するメリットがあまりない
各ラインが独自の進化をする
お互いに干渉せずやりやすいように作る
⇒ 今の感覚ではひどい作り方のように感じるが
この時代はこういった作り方が効率的だった
◆PS3世代の取り組みと開発体制
・主流の画面解像度は720p
・メモリサイズは数百MB
・開発期間は2年前後＋DLCで1年くらい
・マルチプラットフォーム
複数のプラットフォームにタイトルを同時リリースする
⇒ ハードウェアの進化だけではなく
プラットフォームの外側で大きな環境変化が起きた
具体的なリリースタイトル
・Demons Souls
・機動戦士ガンダムUC
・NINJA BLADE
・ARMORED CORE
・DARK SOULS
※大体2014年頃までのタイトル
⇒ マルチプラットフォーム対応への転換
開発体制
・マルチプラットフォーム対応が移植作業になる
ひとつのプラットフォーム完成後にあらためて開発
同時発売するには向かない
・リソースの大規模化との相性が悪い
データ化せずプログラムで作り込み
初動を優先した小規模かつ短期間での開発を前提とした作り方
大規模な量産には向かない
⇒ このままではまずい
R&D主導でのタイトル開発環境の構築
・理想の実現への取り組み
R&D製マルチプラットフォームライブラリの新規開発
低レベルからリソース管理や描画などの高レベルまで
R&D製ツールとデータ形式とビルドシステムの新規開発
・単体の理想としては悪くはなかった
実現するとなるとそれだけではだめだった
・うまくいったものもあったが失敗といえるものも多かった
比較的うまくいったもの
・ライン側エンジニアの協力が得られたもの
負担を肩代わりするようなもの
プラットフォームAPIをラップするライブラリ
世代交代に伴うデータ形式の刷新
・ライン側エンジニアに負担がなく絵デメリットもないもの
R&Dが導入を肩代わりして完結するようなもの
静的解析とか分散ビルドなどの導入
⇒ これらは全ライン共通でうまくいった
トラブルがあっても強力して解決していけた
あまりうまくいかなかったもの
・ライン側エンジニアに負担があってメリットがないもの
既存の仕組みをミドルウェアやR&D製に置き換えるもの
手間やリスクが発生する
・ラインの協力を得られずにR&D側が置き換え
ライン側の協力なしでは互換性維持して置き換えが限界
無理矢理になるし余計なトラブルも発生する
⇒ ライン側の協力なしではそうそううまくいかない
エンジニア以外への影響が大きいもの
・データ作成ツールやワークフローに関わるもの
メニューやカットシーンの制作環境
グラフィカルな状態遷移ツール
トップダウンで強引に導入したもの
リソースを含めたバージョン管理システム
⇒ エンジニア以外の協力はなかなか得られなかった
ラインごとに採用状況がバラバラになった
ひと段落ついてからの取り組み
・ツール開発を全ライン対応の方針へ
各ラインのツールの機能を全て取り入れていく
ラインからの要望には片っ端から答えていく
大量の設定がある全部入りのツールにする
・メンテナンスはどんどん大変になっていく
⇒ とにかくツールを統一することを優先
使われ方などはバラバラだが全ラインで採用
・ミドルウェア類のサポート窓口として機能
ベンダーへの問い合わせやノウハウの蓄積を担う
バージョンアップの事前検証や取り組みサポート
新規導入時の比較検証や組み込みサポート
・ライン間の橋渡し的な形で間接的に連携をサポート
うまくいったものの継続的メンテナンス
ライン側のトラブルや要望には優先対応
⇒ 結果として新しい試みをする余裕がなくなっていく
裏方的仕事がメイン 対応に追われる日々
・ライン側でも大規模化へ効率化で対応
・ツールの拡充やデータドリブンの加速
プログラマはゲーム側の実装より環境整備優先
実装は可能な範囲でプランナーが肩代わりする体制に
・ワークフロー改善のための仕組みを整備
DCCツールからワンボタンでホットリロードなど
・様々な自動化の取り組み
物量に対応していくため＆人為的ミスを減らしていく
プログラマが付き合ってられない
⇒ 相変わらずラインごとの取り組みではあった
・マルチプラットフォーム対応
R&D製のライブラリが全ラインで採用された
・大規模化にはライン単位での効率化で対応
自動化など一通りは手をつけた
・ワークフローや高レベルの実装はライン独自
多少連携はあっても基本はそれぞれやりやすいように
⇒ ライン独自路線は変わらず
◆PS4世代の取り組みと開発体制
・主流の画面解像度は1080p
・メモリサイズは数千MB
・開発期間は3年前後＋DLC1年
・求められるデータの規模や品質がさらにあがる
⇒ PS3世代のときにうらべて変化は小さめ
新世代「感」のリソースへの依存度は大きい
具体的なリリースタイトル
・DARK SOULS 2
・DARK SOULS 3
・Bloodborne
～現在のタイトル
⇒ 大規模化、長期化する開発への対応が必要
DLCをしっかり作っていることも要因の一つ
前世代の問題点
・ラインの環境整備による効率化はもう伸びしろがない
効果的なものは全世代であらかた手をつけてしまった
・現状の環境のメンテナンスで手一杯
当然ゲームエンジンや諸々の世代交代も必要
・R&Dもすでに現状維持で手一杯
メンテナンス作業や要望対応で余裕がない
⇒ このままではまずい
ライン開発環境を全ラインで共通化する
・今回はライン手動での取り組み
・なぜ共通化なのか
開発環境を全ラインで協力したら担当者数が数倍に！
ライン単位の運用を考慮しても実質1.5～2倍程度は期待
R&Dの全部入りツール負担が数分の1に激減！
ライン間の移動が容易になって人員配置が柔軟になる
今までは新しいラインに慣れるのに1週間～1ヶ月などかかっていた
⇒ 人員の効率運用で大規模化に対応することに
共通化を後押しする要因
・ライン開発環境が実は意外と共通化されていた
R&Dのマルチプラットフォーム対応は全ラインで共通すでに完了していた
全部入り戦略で全ライン共通
ツールの半分以上がR&D製で実行ファイルは共通
枠フローなどが各ラインでバラバラなだけ
結果的ではあるが共通化への足がかりができていた
⇒ ライン側がしっかり連携すっれば共通化が可能 なはず
最初のとっかかり
・2ライン合流で開発体制の構築を開始
・1ラインで取り組んでもうまくいく見込みがなかった
具体的にはBloodborneに将来ダクソ3を作るチームを引き抜いて合流
合流して取り込むことを提案して実現
・加えて他ラインからも人員を引き抜き
各ラインのノウハウが
・分離でPS4世代のラインが2ラインになる
開発環境は共通
PS4世代ネイティブの環境はこれだけ
・新しいラインはこの環境をベースにするのが自然
結果的に全ラインが共通の環境で立ち上がる
・ただし、あくまでもベースにしただけ
つまり放置したらそれぞれ独自進化して共通ではなくなる
⇒ 共通環境を維持する工夫が必要
共通環境を維持するための工夫
・情報共通を密に行う
思想の共有を徹底的に行う なぜそういった実装なのか
やりたいことに対して妥当な方針がどういったものか
・作業状況をつぶやいて全ラインでリアルタイム共有
ツイッター的なツール
困っていたら誰かがすぐフォローする
不適切な機能追加などを防ぐ
⇒ 共通環境を維持することにメリットを感じてもらう
メンテナンスや機能追加はラインの作業として行う
・自分たちのための作業として取り組むことを徹底
専門チームを作るべきという意見がでるが避けるべき
必要な機能が必要なだけ実装される
・ひとつのラインが実装したら全ラインで共有
自分たちのための実装を他のラインがやってくれてお得
・多少、出来が悪くても共通化することを優先
共通化後のリファクタはできても逆は厳しい
⇒ ラインの互助システムとして共通化を機能させる
とにかく他職種を巻き込んだ
・理解や興味を示してくれる見方を増やす
現状の問題や解決方法について相談の機会を多く持つ
・各職種の統一見解を引き出せるように
新しいアイディアの相談には窓口の台頭を立ててもらう
・機能ではなく困っていることを相談してもらうように
こういう機能のボタンを追加して欲しい的な要望をNGにした
これらを徹底してその後エンジニアと一緒に相談
⇒ 他職種の協力も得られるように
全ラインで共通の開発環境をベースに開発
・全ラインで共通のワークフロー
ツールの使い方や命名規則など諸々
・新しい機能の追加なども情報共有して連携
ラインをまたいで関係者とすり合わせしながら進める
・実装はひとつのラインで担当してから共有
⇒ 人員の効率的な運用も実現
◆課題と今後の取り組み
共通化に関する誤解の問題
・新しい取り組みに対する萎縮
共通化を優先するために新しいことはNGという誤解
新しいこと（改善）と好き勝手（好み）の区別が難しい
・気軽に試せない＆効率悪いという考え
全ラインの合意を得ないと試せないという誤解
実際は気軽に試してから不況でもかまわない
⇒ 不満につながる誤解なので放置してはいけない
共通化とは
・良いアイディアを独り占めしないこと
そしてそれをみんなで共有していく取り組み
・現状維持をしてやりくりすることではなく
変化をみんなで受け入れていく取り組み
・結果的としてさらに改善する機会が得られる
いまいちだった場合にも発覚が早まる
⇒ こういった取り組みだという啓蒙が必要
契約上の問題 ※弊社のケース
・タイトル固有情報についての共有はNG
エンジニアにはついては共通エンジンを前提とした契約
権利関係の問題だけではなく情報共有のしやすさにも影響する
・他職種の場合は条件が異なる可能性が高いので注意
エンジニアに比べてかなり制限のある共有に限定される
⇒ とにかく法務への確認と連携を怠らないように！！
法務担当者と協力的な関係を築くように
今後の取り組み
・問題としてあげた2点の改善
共有がもっと前向きに受け入れられるようにしたい
契約上の制限を緩和したい
・次も現世代の延長では多分対応できなくなる
別の軸で対応することになるが
開発期間を延ばすのはそろそろ限界のはず
人を増やすのも簡単なことではない
毎年発売を維持できなくなる
DLCを続けてリリース？ ⇒ 本編が失敗したらDLCも失敗するのでリスクが大きい
⇒ さてどうしたものか
今のところは
・ゲームそのものの作り方を効率化できないか
エンジニア以外にも共通エンジンのような仕組み
攻めのプロシージャル
⇒ データ作成を直接効率化するのではなく
その根っこの効率化を図ることでデータ制作の歩止まりを向上させる
Q「R&Dの人数は？」
A「現在27～28名くらい」
Q「た職種への理解や仕組みを入れる中でプログラマへの理解が重要と思うが
その中で工夫されていることは？」
A「基本的にはプログラマが協力者と思ってもらえるよう気を付けている
こういう機能を追加してくれというのは要求せず
とにかく困っていることを共有して寄り添っている 相談できるように」
Q「便利屋になりそうだが」
A「そこは気を付けている お互いにできることをやり合う関係を作る
情報をグラフィッカーがやりたいことがあった時に
他のグラフィッカーはどう思っているか？をグラフィッカー自体に集めてもらう
お互いが努力するような体制を作る」
Q「自動化はどういったものを？」
A「ツールからボタンを押したらホットリロードとかメモリ状況などの収集とか
出たワーニングを担当者に分配するとか 細かいことも含めて色々やっている
Q「共通化していくと 変更が他のプロジェクトに影響していくのでは？」
A「そこは課題があるがパターンとしては共通のライブラリになっている
他ラインに自動的に反映されるケースとそれぞれのラインがマージをするケースの2つある
マージする方は結構手間なのでもう少し良いやり方を検討している
一番簡単なのはライブラリ化していくこと
今できていない理由は手が回っていない まずは手を回るよう時間を作る
Gitなどの環境で解決していく 色々やりようはあるかなと」
Q「これらの導入の決断は現場？上層？」
A「フロムソフトウェアは元々システムを作っていた会社なので
恐らく最初からそういう体制だった」
Q「新しい人が入ると把握ができていないと思うが育成は？」
A「半年くらい新人研修に時間を使っている
後は経験者に部下としてつけて学んでいってもらう」
