ゲームを制作しながらどうやって開発環境を整えるか？“現場“のツール作成手法

by gree_tech

Slide 1

Slide 1 text

ゲームを制作しながらどうやって開発環境を整えるか？ “現場“のツール作成手法株式会社WFS ゲームプログラマー奥村　典史

Slide 2

Slide 2 text

ゲームを作るということはツールを作るということ！ 2

Slide 3

Slide 3 text

自己紹介奧村典史株式会社フロム・ソフトウェアを経て、 2012年に入社。「ららマジ」などの開発に携わる。その後「アナザーエデン時空を超える猫」に参加し、2018年ごろから「ヘブンバーンズレッド」にメインプログラマーとして参画。スケジュール管理やアドベンチャーパートの実装、その他ゲーム全体のシーケンスなどを担っている。 3

Slide 4

Slide 4 text

ツール＝ゲームを作るために必要な全てのソフトウェア 4

Slide 5

Slide 5 text

ゲーム開発で必要なソフトウェア ● データを作る ● 効率を上げる 5

Slide 6

Slide 6 text

ゲーム開発で必要なソフトウェア ● データを作る ● 効率を上げる ○ 速度を上げる ○ 作る難しさを緩和する 6

Slide 7

Slide 7 text

もくじ ● なぜツールをつくるのか？ ● なぜツールを「現場」でつくるのか？ ● ツールを現場で作ることの問題点 ● 時間が無い！ ● 共通化出来ない！ ● さいごに 7

Slide 8

Slide 8 text

なぜツールをつくるのか？ 8

Slide 9

Slide 9 text

なぜツールを作るのか？ ● 1.データを作る ● 2.関わる人を減らす ● 3.単純作業や大量の作業をこなす ● 4.コンテキストスイッチを減らす ● 5.イテレーションの速度を上げる ● 6.知識を補う ● 7.ミスを防ぐ 9

Slide 10

Slide 10 text

1.データを作るとあるゲーム制作者がゲームを作る・・・ ● 絵が書きたい ● プログラムを書きたい ● ゲームバランスや設計されたレベルデザインを作りたい 10 なぜツールを作るのか？ ↑彼

Slide 11

Slide 11 text

ゲームを作るデータを作る ● 絵を作るツール ● プログラムを書くツール ● ゲームバランスやレベルデザインを作るツール 1.データを作る 11 なぜツールを作るのか？０１０１０１０１０１００１０１０１０００１０１０１０００１０１０１０１００１０００

Slide 12

Slide 12 text

1.データを作る画像を作るツール ● Photoshop ● Illustrator プログラムを作るツール ● VisualStudio ● Rider 12 なぜツールを作るのか？

Slide 13

Slide 13 text

1.データを作るゲームエンジン ● Unity ● Unreal Engine 13 なぜツールを作るのか？

Slide 14

Slide 14 text

1.データを作るゲーム固有のデータ ● マップ作成ツール ○ 各プロダクト用のデータを作る 14 なぜツールを作るのか？

Slide 15

Slide 15 text

1.データを作る画像データから特定のゲームの中だけで使われるデータまでありとあらゆるデータでゲームはできているツールによって効率的にデータの作成ができる 15 なぜツールを作るのか？

Slide 16

Slide 16 text

2.関わる人を減らす人にデータを依頼・・・考えたものを人に作ってもらうのは非常にコストがかかる 16 なぜツールを作るのか？

Slide 17

Slide 17 text

例えば・・・ ● プランナーさんが敵の攻撃行動を考える ● プランナーさんと会議を開きエンジニアに内容を伝える ● エンジニアがAIを実装する 2.関わる人を減らす 17 なぜツールを作るのか？

Slide 18

Slide 18 text

2.関わる人を減らす例えば・・・ ● プランナーさんが敵の攻撃行動を考える ● プランナーさんがビヘイビアツリーで実装するツールによって工程と関わる人が減った！ 18 なぜツールを作るのか？

Slide 19

Slide 19 text

2.関わる人を減らす考えている人が考えていることをそのまま出力できると・・・ ● 時間的な効率が上がる ● クオリティが上がる無駄なお手玉を減らすためにツールが活躍する 19 なぜツールを作るのか？

Slide 20

Slide 20 text

3.単純作業や大量の作業をこなす単純作業や大量の作業の例 ● FBXのモデルからゲームで使えるデータに変換する ● ファイルを一定の規則でリネームする 20 なぜツールを作るのか？

Slide 21

Slide 21 text

3.単純作業や大量の作業をこなす 1000ファイルの名前を変えよう！　MQ010105.lua→MQ01_01_05.lua 21 リネームにかかる時間 20秒　✕　1000　 =　20000秒　 =　5時間33分20秒！なぜツールを作るのか？

Slide 22

Slide 22 text

3.単純作業や大量の作業をこなす 1000ファイルの名前を変えよう！　MQ010105.lua→MQ01_01_05.lua 会議とリネームで今日が終わった・・・ 22 リネームにかかる時間 20秒　✕　1000　 =　20000秒　 =　5時間33分20秒！なぜツールを作るのか？

Slide 23

Slide 23 text

3.単純作業や大量の作業をこなすリネームツールなら一瞬ですよ！ 23 リネームにかかる時間 0.001秒　✕　1000　 =　1秒　なぜツールを作るのか？

Slide 24

Slide 24 text

3.単純作業や大量の作業をこなす大量の仕事をツールで自動化する人間には出来ないことを機械にやってもらう 24 なぜツールを作るのか？

Slide 25

Slide 25 text

4.コンテキストスイッチを減らす一瞬目を奪われたり、ファイルの作業をするだけで人は今やっている事を忘れる！ 25 なぜツールを作るのか？

Slide 26

Slide 26 text

4.コンテキストスイッチを減らすそうだ、このシーンに木を一本、生やそう 26 なぜツールを作るのか？

Slide 27

Slide 27 text

4.コンテキストスイッチを減らすどれどれ？このシーンの名前は・・・ Main・・・ちがうなBaseTown_A_PL0807.unityか・・・・ 27 なぜツールを作るのか？

Slide 28

Slide 28 text

4.コンテキストスイッチを減らすじゃあまずは、BaseTown_A_PL0807.unityを探さないとな 28 なぜツールを作るのか？

Slide 29

Slide 29 text

4.コンテキストスイッチを減らす BaseTown_A_PL0804.unity BaseTown_A_PL0805.unity BaseTown_A_PL0806.unity BaseTown_A_PL0807.unity BaseTown_A_PL0808.unity BaseTown_A_PL0809.unity BaseTown_A_PL0810.unity 29 なぜツールを作るのか？

Slide 30

Slide 30 text

4.コンテキストスイッチを減らす BaseTown_A_PL0804.unity BaseTown_A_PL0805.unity BaseTown_A_PL0806.unity BaseTown_A_PL0807.unity　これだ！ BaseTown_A_PL0808.unity BaseTown_A_PL0809.unity BaseTown_A_PL0810.unity 30 なぜツールを作るのか？

Slide 31

Slide 31 text

4.コンテキストスイッチを減らすここであなたの大切な猫がモニターとキーボードのあいだを横切ります 31 なぜツールを作るのか？

Slide 32

Slide 32 text

4.コンテキストスイッチを減らす BaseTown_A_PL0807.unityを開いた 32 なぜツールを作るのか？

Slide 33

Slide 33 text

4.コンテキストスイッチを減らすなにするんだっけ・・・？ 33 ？なぜツールを作るのか？

Slide 34

Slide 34 text

4.コンテキストスイッチを減らすそうだ、このシーンに木を一本、生やそうここに「シーンを開く」ボタンがあるだけで防げたはず・・・！ 34 開くなぜツールを作るのか？

Slide 35

Slide 35 text

4.コンテキストスイッチを減らす一瞬忘れると作業を思い出すのに意外に時間はかかる ● 操作するところをまとめたり、ボタンを一つ作るだけでコンテキストスイッチは減る想像しているより、小さなボタンの効果は大きい 35 なぜツールを作るのか？

Slide 36

Slide 36 text

5.イテレーション速度を上げるゲームでは何回も同じ場所をブラッシュアップしていきます。天才が1回で作ったものよりも凡人が100回作り直したものの方が面白いことが多い！ 36 なぜツールを作るのか？

Slide 37

Slide 37 text

5.イテレーション速度を上げるじゃあぼくは100回ブラッシュアップしましょう！タイトル画面から、Aの街のなかの町娘Cに話しかけて、選択肢Aを選んだ後に道具屋に話しかけると200秒かかりました　 37 ブラッシュアップにかかる時間 200秒　✕　100　 =　20000秒　 =　5時間33分20秒！なぜツールを作るのか？

Slide 38

Slide 38 text

5.イテレーション速度を上げるじゃあぼくは100回ブラッシュアップしましょう！タイトル画面から、Aの街のなかの町娘Cに話しかけて、選択肢Aを選んだ後に道具屋に話しかけると200秒かかりました会議とNPCに話しかけてたら今日が終わった・・・・ 38 ブラッシュアップにかかる時間 200秒　✕　100　 =　20000秒　 =　5時間33分20秒！なぜツールを作るのか？

Slide 39

Slide 39 text

5.イテレーション速度を上げる状況を再現するのが20秒に短縮されたら・・・ 39 ブラッシュアップにかかる時間 20秒　✕　100　 =　2000秒　 =　33分20秒！なぜツールを作るのか？

Slide 40

Slide 40 text

5.イテレーション速度を上げる状況を再現するのが20秒に短縮されたら・・・日が沈まない！祈る時間が増えた 40 ブラッシュアップにかかる時間 20秒　✕　100　 =　2000秒　 =　33分20秒！なぜツールを作るのか？

Slide 41

Slide 41 text

5.イテレーション速度を上げる現在のゲームの状態が一瞬で再現できるデバッグメニュー ● ユーザーデータを保存、ロードできる ● ロード時にすぐにゲーム自体がリスタートする 41 なぜツールを作るのか？

Slide 42

Slide 42 text

5.イテレーション速度を上げる単体の機能だけが置いてあるシーン ● 再生するだけで機能の確認が出来る 42 なぜツールを作るのか？

Slide 43

Slide 43 text

5.イテレーション速度を上げる繰り返しのボトルネックをツールで減らす時間効率はクオリティに直結する 43 なぜツールを作るのか？

Slide 44

Slide 44 text

6.知識を補うドキュメントも立派なツールです 44 なぜツールを作るのか？

Slide 45

Slide 45 text

6.知識を補うツールチップとか 45 なぜツールを作るのか？

Slide 46

Slide 46 text

6.知識を補うヘルプボタンとか 46 なぜツールを作るのか？

Slide 47

Slide 47 text

6.知識を補う Gitを使うのが苦手な人が簡単にgitを使えるツール FireCommitter 47 なぜツールを作るのか？

Slide 48

Slide 48 text

6.知識を補うツールを通して知識を共有する知識が共有されることでチーム全体の効率を上げることができる 48 なぜツールを作るのか？

Slide 49

Slide 49 text

7.ミスを防ぐマスターバリデーション ● 値の範囲チェック ● 他マスターとの繋がりチェック ● アセット参照チェック →変換時にチェックすることで環境が壊れることを防ぐ 49 なぜツールを作るのか？

Slide 50

Slide 50 text

7.ミスを防ぐ一つのミスは連鎖的に次のミスにつながるチーム全体を止めてしまう事もあるミスをすることを恐れて効率を落としてしまうこともあるミスを防ぐツールは速度も向上させる 50 なぜツールを作るのか？

Slide 51

Slide 51 text

なぜツールを作るのか？ ● 1.データを作る ● 2.関わる人を減らす ● 3.単純作業や大量の作業をこなす ● 4.コンテキストスイッチを減らす ● 5.イテレーションの速度を上げる ● 6.知識を補う ● 7.ミスを防ぐ 51

Slide 52

Slide 52 text

なぜ「現場」でツールをつくるのか？ 52

Slide 53

Slide 53 text

なぜ「現場」でツールをつくるのか？ ● 1.同じゲームは２つとない ● 2.「現場」のことは「現場」でしかわからない 53

Slide 54

Slide 54 text

1.同じゲームは２つと無いあなたのゲームにはあなたのゲームにしか無い「しくみ」がある 54 なぜ「現場」でツールをつくるのか？

Slide 55

Slide 55 text

1.同じゲームは２つと無い CharacterAssetConcierge ● 1ボタンでとてもたくさんの作業をするツール ● 「ららマジ」でしか使わないキャラクターのアセットを作るために存在している 55 １ボタンでやっている処理一覧 Bake退避データのインポート Spineのインポート Bakeデータ作成　defaultのダメージコリジョンの作成　defaultのトランスフォームアニメーション　新しいRootモーションに更新するアニメーターの作成　（アニメーションクリップの生成）　defaultのメカニムをコピートランスフォームアニメーション作成エフェクトのSpineデータインポートエフェクトのアニメーター作成 Viewのプレハブをつくる　インスタンス化　飛び道具のコピー　モーションエフェクターのコピー　コリジョンのコピー　ステータスエフェクトをのせる　ボーンを減らす UIViewのプレハブを作る容量オーバーのBakeを退避なぜ「現場」でツールをつくるのか？

Slide 56

Slide 56 text

1.同じゲームは２つと無い探検マップエディター ● 「ヘブンバーンズレッド」の探検機能を作るためだけに存在 ● ミニマップととそれと同じ構造のダンジョンのつながりを作る 56 なぜ「現場」でツールをつくるのか？

Slide 57

Slide 57 text

1.同じゲームは２つと無いすべてが同じ仕様のゲームはこの世に２つ存在しないだから、ゲーム作りでは共通化出来ないツールも作らなければならない 57 なぜ「現場」でツールをつくるのか？

Slide 58

Slide 58 text

2.「現場」のことは「現場」でしかわからない ● 「こんなツールが欲しい！」は使う人にしか分からない ● 「使いやすい」は使う人にしかわからない欲しくないツール使いにくいツールはどうなる？ 58 なぜ「現場」でツールをつくるのか？

Slide 59

Slide 59 text

使われない 59

Slide 60

Slide 60 text

2.「現場」のことは「現場」でしかわからない現場の困っていることを解決 FireCommitter ● Gitを使えない人でも簡単に使えるツール ○ 手元を最新にする（git pull) ○ ファイルをアップロードする（ git commit） 60 なぜ「現場」でツールをつくるのか？

Slide 61

Slide 61 text

2.「現場」のことは「現場」でしかわからない FireCommtterが生まれたあらすじ ● ファイルを最新に出来ない ○ Unityは時々勝手にmetaファイルを変える ○ 変更されたファイルがローカルにあると gitはpullしない ○ git checkout .などでファイルを戻さなければいけないが・・・ ■ アートさんはわからない ● コマンドは難しいし ● GUIツールでも難しい ● 自分で変えたわけではない ○ じゃあ、全部git checkout .で「燃やし尽くして」から pullすればいいじゃん！ ■ →すごく乱暴だけど上手くいった。みんな pullできるようになった。 61 なぜ「現場」でツールをつくるのか？

Slide 62

Slide 62 text

2.「現場」のことは「現場」でしかわからない FireCommtterが生まれたあらすじ ● ファイルをアップロードできない ○ アップロードするためには・・・ ■ git checkout -b feature/hogehoge 　←ブランチを切ってるブランチ名を決めなきゃだ ■ git add hogeFile.unity ←ファイルをステージしてる。ステージって何？ ■ git add hogeFile2.unity ←全部ステージしなきゃいけない ■ git commit -C “ファイルを更新”　←ちゃんとコミットログ書いて欲しい ■ git push origin feature/hogehoge ←ネットにアップしてる ■ Githubでプルリクを出す ○ どうか1ボタンで・・・・・ 62 なぜ「現場」でツールをつくるのか？

Slide 63

Slide 63 text

なぜ「現場」でツールをつくるのか？ ● 1.同じゲームは２つとない ● 2.「現場」のことは「現場」でしかわからない 63

Slide 64

Slide 64 text

ツールを現場でつくることの問題点 64

Slide 65

Slide 65 text

ツールを現場でつくることの問題点 ● 時間がない ● 共通化出来ない 65

Slide 66

Slide 66 text

だけど・・・ ● 時間がないけどツールは現場で作る必要がある、またツールを作らないとよけいに時間はなくなる ● 共通化全ては無理だけど、出来る部分もあるはずだだから、現場でツールを作ろう！共通化しよう！チームや組織で肯定していこう 66 ツールを現場でつくることの問題点

Slide 67

Slide 67 text

ツールを現場でつくることの問題点 ● 時間がない ● 共通化出来ない 67

Slide 68

Slide 68 text

時間がない！ 68

Slide 69

Slide 69 text

時間がない！ ● 1.ツールを作るコストを減らす ● 2.ゲームと同時に作る ● 3.効率化することで、時間を作り出す ● 4.作る人を増やすことで、時間を増やす 69

Slide 70

Slide 70 text

1.ツールを作るコストを減らす ● 「ツールを作るツール」を使う ● 「ツールを作るツール」を作る ● コードの依存性を切り、機能を独立させる 70 時間がない！

Slide 71

Slide 71 text

1.ツールを作るコストを減らす ● 「ツールを作るツール」を使う 71 時間がない！

Slide 72

Slide 72 text

1.ツールを作るコストを減らす ● 「ツールを作るツール」を作る ○ Decoma 72 時間がない！

Slide 73

Slide 73 text

1.ツールを作るコストを減らす ● コードの依存性を切り、機能を独立させる ○ 機能の依存の樹を小さくする ○ プロジェクトのコードがシンプルじゃないとツールを作るコストも上がる！ 73 時間がない！

Slide 74

Slide 74 text

2.ゲームと同時に作るゲームを作るには ● データを作らなければならない ● イテレーションを繰り返さなければならない 74 時間がない！

Slide 75

Slide 75 text

2.ゲームと同時に作るゲームを作るには ● データを作らなければならない →データを作るツール ● イテレーションを繰り返さなければならない →イテレーションを早くするツール 75 時間がない！

Slide 76

Slide 76 text

2.ゲームと同時に作るデータを作るツール ● 最初はどういうゲームを作ればいいかわからない ● エンジニアが企画を聞いて最低限で実装 ○ 実装を作る時にツールも実装 ○ 完璧でなくていいし、未完成で良い、方向性が正しいか見てもらうのが重要 ● ゲームの仕様変更に合わせてデータを作るツールを改善していく ○ 最初から作りすぎてしまうと変更に時間がかかる ○ 未完成の方が軌道修正のコストが小さくてすむ 76 時間がない！

Slide 77

Slide 77 text

2.ゲームと同時に作るイテレーション（確認）を早くするツール ● 「開発中」が一番たくさん確認する ○ もっともツールの効果が最大化する ● 細かく確認してもらう事で仕様変更が小さくなる 77 時間がない！

Slide 78

Slide 78 text

2.ゲームと同時に作るゲームと同時にツールを作っていく ● 探検マップエディター ○ どうやってマップ間をつなげるのか？ ○ そのデータはどう作るのか？ ○ どんな見た目のミニマップを作るのか？ ○ マップ上には何を配置するのか？様々な事をゲームと同時に決めながらツールの制作を行った！ 78 時間がない！

Slide 79

Slide 79 text

2.ゲームと同時に作るゲームと同時にツールを作っていく ● 細かく早く確認してもらうことで仕様変更が小さく細かくなる ○ 作りすぎる事が少なくなる！ ● 早く準備することによってツールで減らせるコストは最大化する時間を作れる！ 79 時間がない！

Slide 80

Slide 80 text

3.効率化することで、時間を作り出すシナリオ変換ツール「ちゅーりっぷ」シナリオファイルをLuaファイルに変換！ ● いちいちコピペで書き写すよりも1 ファイル10分以上の節約に！ 80 時間がない！

Slide 81

Slide 81 text

4.作る人を増やすことで、時間を増やす簡単にデバッグコマンドを作れるツール「Decoma」 ● アドレスとIMGUIを書けば簡単に誰でもデバッグコマンドを作成可能なツール 81 new DebugCommand("Debug/リセット", () => { if (GUILayout.Button("リセット")) { Reboot(); } }); 時間がない！

Slide 82

Slide 82 text

4.作る人を増やすことで、時間を増やす ● デバッグメニューの作成のハードルを下げることで・・・ ○ 経験の浅いプログラマーでも！ ○ 痒いところに手が届かないのをもどかしく思っていたプランナーでも！ ○ 簡単に状況を作り出してデバッグしたい QAでも！実際に作れました！ 82 時間がない！

Slide 83

Slide 83 text

4.作る人を増やすことで、時間を増やすプログラムを書くことを職掌でフタをしない ● 「誰でもかける様」にしておくこと！ ● 「誰でも書いて良い」にしておくこと！おかしなプログラムが入ってきたら怖い →場所をエディターやデバッグコマンドに限定する →コードレビューをきちんとする 83 時間がない！

Slide 84

Slide 84 text

4.作る人を増やすことで、時間を増やす企画者ウインドウ ● フタをしなかった結果、生まれた良い例 ● 企画者の得意な人がC#で書いてくれた ● プログラマーが書くよりも「要件」をよく知っている人が書いたので便利！ 84 時間がない！

Slide 85

Slide 85 text

● 1.ツールを作るコストを減らす ● 2.ゲームと同時に作る ● 3.効率化することで、時間を作り出す ● 4.作る人を増やすことで、時間を増やす時間がない！ 85 時間はない！永遠にない！しかし、ツールを作らなければもっとない！みんなで時間を生み出そう

Slide 86

Slide 86 text

共通化出来ない！ 86

Slide 87

Slide 87 text

共通化出来ない！ ● 共通化はなんで難しいか？ ● 共通化が成功したツール ● 1.命名せよ！ ● 2.パッケージ化せよ！ ● 3.前のプロジェクトを継承してゆっくり育てる ● 4.ドキュメント制作会議 87

Slide 88

Slide 88 text

共通化はなんで難しいか ● どんなツールがあるのか知らない ● 他の現場のツールを持ってくることが出来ない ● 機能が少ないので使ってくれない ● ドキュメントが無い 88 共通化出来ない！

Slide 89

Slide 89 text

共通化が成功したツール ● OniUI ○ MVCで言うところのViewのレイヤーを完全に切り分けるための UIライブラリ ○ 詳しくはCEDEC2022のUIの講演でも紹介しています →UIの開発スピードを高速化させる仕組み ~ヘブンバーンズレッドにおけるUnityを用いた事例~ https://cedil.cesa.or.jp/cedil_s essions/view/2651 このツールで有効だった手段をいくつか・・・ 89 共通化出来ない！

Slide 90

Slide 90 text

1.命名せよ！ “まるで鬼神のごとき速さでUIを実装するライブラリ「OniUI」” ● 使う人が呼んでくれる ● 何に対しての会話かが分かる ● 導入する時にも「◯◯がほしい！」「◯◯でいこう！」と言える ● 導入しないときにも「◯◯は今回はなしで！」と言える 90 共通化出来ない！

Slide 91

Slide 91 text

2.パッケージ化せよ！もしかしたら共通化出来ないツールでも積極的にサブモジュール化する ● プロジェクトに依存したコードを排除できる ● 他のプロジェクトが簡単に導入する事ができる ● 開発中の段階から２つ以上のプロジェクトで変更を入れていくことができる 91 共通化出来ない！

Slide 92

Slide 92 text

3.前のプロジェクトを継承しゆっくり育てる！ Project AnimalでのOniUI ● LWFをUIに使っていた ● LWFのオブジェクトに対して値を入れる中継クラスがあった 92 Project A 共通化出来ない！

Slide 93

Slide 93 text

3.前のプロジェクトを継承しゆっくり育てる！ Project XaiでのOniUI ● LWFで実装してあったコードをそのままにNGUIに置き換える必要があった ● 同じインターフェイスでNGUIに置き換えられうように ● コード自動生成なし ● オートバインドなし 93 Project A Project X 共通化出来ない！

Slide 94

Slide 94 text

3.前のプロジェクトを継承しゆっくり育てる！「ららマジ」でのOniUI ● インターフェイスのコードを拡充 ● UITechさんによるViewのコードを書く場所を追加 ● UIのベースクラスの自動生成 Project WでのOniUI ● UGUIへの置き換え ● カルーセルの機構追加 ● イケてるバーチャルスクロール 94 Project A Project X ららマジ Project W 共通化出来ない！

Slide 95

Slide 95 text

3.前のプロジェクトを継承しゆっくり育てる！「ヘブンバーンズレッド」でのOniUI ● コードバインドの自動生成 95 Project A Project X ららマジ Project W ヘブバン Next Next 共通化出来ない！

Slide 96

Slide 96 text

3.前のプロジェクトを継承しゆっくり育てる！思想やプログラムは人と一緒に移動する！ ● 奥村が昔のプログラムを持ってProjectを移動する ● UITechさんがプログラムをもって別のProjectに移動する人の移動によって思想が広まっていき、多くのProjectに入っていった思想だけでも移動すると共通化が進んでいく 96 共通化出来ない！

Slide 97

Slide 97 text

4.ドキュメント制作会議ドキュメントがないから直接教えて欲しい！ ● 教えて欲しい人を募って会議 ● 機能ややり方を解説する ● 参加者がその場でまとめる → あら不思議！ドキュメントが完成！ 97 共通化出来ない！

Slide 98

Slide 98 text

共通化出来ない！ ● 共通化はなんで難しいか？ ● 共通化が成功したツール ● 1.命名せよ！ ● 2.パッケージ化せよ！ ● 3.前のプロジェクトを継承してゆっくり育てる ● 4.ドキュメント制作会議 98

Slide 99

Slide 99 text

参考 [CEDEC2022]ヘブンバーンズレッドにおけるLuaの活用事例   https://cedil.cesa.or.jp/cedil_sessions/view/2697   [CEDEC2022]UIの開発スピードを高速化させる仕組み ~ヘブンバーンズレッドにおけるUnityを用いた事例~   https://cedil.cesa.or.jp/cedil_sessions/view/2651   [CEDEC2018]『アナザーエデン時空を超える猫』における“ツール運営“事例〜開発ツールの運用で学んだこと〜   https://cedec.cesa.or.jp/2018/session/detail/s5ab9f3ac0efa3.html   [Unite 2017 Tokyo]Unityで出来る『見える開発』のススメ～スマホゲーム「ららマジ」開発事例～   https://events.unity3d.jp/unitetokyo/2017/session-lineup.html#session81   [Unity Sync2022]『ヘブンバーンズレッド』の大規模開発と高速イテレーションを支える、自作ツール群の秘密   https://events.unity3d.jp/sync/session/8/   Unityで開発しているゲームの単体テストをCI環境で運用している話   https://labs.gree.jp/blog/2015/12/15392/   [WFS Tech Talk ＃1]ららマジでしかできない！？キャラクターアセット最適化事例   https://www.slideshare.net/greetech/ss-149149594   [GREE Tech Conference 2022] ヘブンバーンズレッド × バトル × アドベンチャー〜WFSのゲーム制作・演出の最大化手法〜   https://techcon.gree.jp/2022/session/TrackB-2     99

Slide 100

Slide 100 text

さいごに ● 走りながらツールをつくろう ● ゲームを作る人にしか出来ないツールづくりがあるこの発表がもし、あなたのゲーム作りの助けになれば！ 100

Slide 101

Slide 101 text

101