Unityチーム開発によくある小問題解決案

UnityにおけるMVPや情報処理のフロー整理などに関するちょっとしたアイデア集です。

2024/05/05に開催される近大卒業生が主催する技術勉強会「Reunion Study Meeting」にて使用します。
https://x.com/KINDAI_CSGR/status/1785901701196833011

Transcript

1. Unityチーム開発に よくある小問題解決案 <author = ‘さねふじ けいた’ > <contact discord = ‘sane21.’ github = ‘sane21’ > <!– 注釈:内容は所属組織を代表するものでなく個人的な見解です --> <title> </title>
2. 自己紹介 • 實藤 敬太 / Sanefuji Keita • 24年 理工学部情報学科 卒業 (学士:工学、教員免許高校情報) • 学生時代の所属 • 22年度 電子計算機研究会 会長 • 22年度 KINDAI Info-Tech HUB 学生キャプテン • KC3運営委員会 • 現在の所属 • 株式会社エイチームエンターテインメント • ゲームプログラマー • 特定非営利活動法人NxTEND • イベント運営の助っ人？ 2
3. Question チーム開発では どんな問題が起こる？ 3
4. Q. チーム開発ではどんな問題が起こる？ Q. みんなでコードを共有するのにどうしよう？ • バージョン管理システムを使う • Git、GitHubやGitLabなど Q. どうやって開発を進めたら良いんだろう？ • ソフトウェアプロセス 授業でやるはず • 本もたくさんある • IPAの資料とかも良い Q. どうやって役割分担しよう？ ← 今日の議題その1 問題 4
5. Question Unityを使ったチーム開発では どんな問題が起こる？ 5
6. Q. Unityのチーム開発ではどんな問題が？ • GitHubでなにが編集されたのか分からない • UnityEditor上での編集はバイナリで表現されるため ↑ 今日の議題その2 • 処理が追いにくい • StartやUpdateがMonoBehaviourの数だけ存在し得るため ↑ 今日の議題その3 問題とその原因 6
7. 7 今回の議題 1. どうやってコードを役割分担しよう？ 2. どうやって処理を追いやすくしよう？ 3. どうやってGitでの管理を見やすくしよう？
8. 8 今回の議題 1. どうやってコードを役割分担しよう？ • 設計 • MVP 2. どうやって処理を追いやすくしよう？ • StartとUpdateの分離 • 一箇所からのみ呼び出し 3. どうやってGitでの管理を見やすくしよう？ • コードでのGameObject取得と生成 • 最小限をコミット
9. No.1 問題 : 役割分担 回答 : 設計をしよう 9
10. 問題の原因 •作りたいものを明確にする → 企画、要件定義 •どのように作るのかを明確にする → 設計 プログラムの役割に意味が持てていない / 弱い 10
11. 開発の工程 1.作りたいものの概要を決める 2.何を作るのかを明確にする 3.どう作るのかを決める 4.実際に作る 11
12. 開発の工程 1.企画 : 作りたいものの概要を決める 2.要件定義 : 何を作るのかを明確にする 3.設計 : どう作るのかを決める 4.開発 : 実際に作る 12
13. なにを作りたいのか 決めること • ターゲット • 打ち出す強み • 既存品との差別化 • かかるコスト • 得られるリターン など 企画 なぜ作るのか 誰のためのどんなゲームか ブレない軸を持てる 道に迷ったときの指針になる 参考 • ビジネスモデルキャンバス など 画像 : いらすとや 13
14. • どんな技術を使う？ • どんな画面がある？ • ユーザは何ができる？ • どんな入力をする？ • 入力にはどんな結果が起こる？ • 放置したらどうなる？ • どんなデータがある？ • データが変わったらどうなる？ • 画面が変わる？ • 他のデータに影響を及ぼす？ など 要件定義 作るために必要なことはなにか 事前に考えられること 用意できることを洗い出す 作るものを明確にイメージできる 作る道筋が明らかになる 画像 : いらすとや 14
15. • アーキテクチャ • オブジェクト指向 • デザインパターン • SOLID原則 • KISS原則 など 設計 どのように作るのか 作る手段や方式を確立する 作る道筋を舗装できる 画像 : いらすとや 15
16. 設計 • MonoBehaviourに依存しがち • データの入出力や見た目の管理などなんでもできる • 〇〇Manager増えがち • 最初からGameManagerがあることに引っ張られる？ • Start()やUpdate()がたくさんできがち • MonoBehaviourの数だけ設定できる side : Unity 16
17. 設計 • MonoBehaviourに依存しがち • データの入出力や見た目の管理などなんでもできる → 継承関係の複雑化 • 〇〇Manager増えがち • 最初からGameManagerがあることに引っ張られる？ → 複数箇所に影響を及ぼす可能性 • Start()やUpdate()がたくさんできがち • MonoBehaviourの数だけ設定できる → 処理を管理しきれない bad : Unity 17
18. 設計 • Model • データを管理する • View • 見た目を管理する • ユーザの入力を受け取る MonoBehaviourはココ • Presenter • Viewからの入力をModelに渡す • Modelのデータの変更をViewに渡す 処理のメインはココ MVPアーキテクチャ 18
19. 設計 • UniRx • Reactive Extensions for Unity • もう更新されないけど、 記事がたくさん • R3 • あたらしいUniRx • より安全に速く • 同じ開発者 • Unity 2021.03 以上 • MVPに便利 データ更新の通知をサポート good : Unity 参考 : https://github.com/neuecc/UniRx https://github.com/Cysharp/R3 19
20. 設計 • Observerパターン • Observable : 被観測対象 • Observer : 観測者 • Observableにイベント発生 → Observerに通知 • MVPでは Model(Observable)にデータ変更 → Presenter(Observer)に通知 → Viewに見た目の変更を命令など データ更新の通知の詳細 20
21. 21 設計 ゲームの流れ
22. No.2 問題 : 処理の追跡 回答 : MonoBehaviourを管理 22
23. 問題の原因 • 開始時 • 毎フレーム • どのStart / Updateから呼ばれるか わからない / わかりにくい たくさんのMonoBehaviourがそれぞれに動作すること 23
24. 対処その１ • 必要なClassを整理・設計する • MonoBehaviour は Model には不要 • 場合によっては、Presenter にも不要 • 必要な View や一部の Presenter のみに MonoBehaviour を継承させる MonoBehaviourを闇雲に増やさない 24
25. 対処その２ • ゲーム全体の進行をつかさどるPresenterを作成 • 仮にGameManagerとする • GameManagerがすべてのPresenterを管理する • UnityのStart、UpdateメソッドはGameManagerのみが呼び出す • GameManagerのStart、Updateから 他のPresenterの開始メソッドや更新メソッドを任意の順番で呼び出す StartやUpdateの使用を一か所に限定する 25
26. 26 対処その２ 一つのClassだけが StartやUpdateを実行 その一つが すべてのPresenterの ManualUpdateを実行 連動してすべての ModelとViewが動作 Updateの場合
27. No.3 問題 : Gitで管理しにくい 回答 : 最小限の編集をコミット 27
28. 問題の原因 • 差分を見ても変更箇所の意味がわからない • コンフリクトしたときに解消が面倒 UnityEditorでの編集が見にくい 28
29. 参考 : https://github.com/github/gitignore/blob/main/Unity.gitignore 29 不要なファイルはignore • 必要なファイルだけコミット • 不要なものの • 各自の環境の値を決めているだけのもの • .csprojファイル • UserSettingsディレクトリ • など • GitHub公式の Unity.gitignore を参照
30. 30 Editor編集を最小限に • UnityEditorのシーン内に置くものを、 Prefab化しておき開始時に生成など • [SerializeField]を最小限にする • Prefabのなかだけで機能するものとか • Viewのもの • MonoBehaviourを継承したClassからGetComponentできる • それ以外の必要なGameObject • Presenterを経由してほかのView等から受け取れば良い
31. まとめ 31
32. 32 今回の議題 1. どうやってコードを役割分担しよう？ • 設計 • MVP 2. どうやって処理を追いやすくしよう？ • StartとUpdateの分離 • 一箇所からのみ呼び出し 3. どうやってGitでの管理を見やすくしよう？ • コードでのGameObject取得と生成 • 最小限をコミット
33. まとめ 1. 企画 ：目標を決める 2. 要件定義 ：目標達成に必要な要素をすべて洗い出す 3. 設計 ：必要な要素を満たすための準備をする 4. 開発 ：がんばれ 開発の手順 33
34. まとめ • MVPアーキテクチャ • Observerパターン • Reactive Extension (UniRx, R3) • データを管理できるように、Modelを定義する！ • 処理を追えるように、Presenterを組み合わせる！ • 見た目を的確に表すために、Viewを整える！ Unityゲームの設計例 34
35. おすすめの書籍 35
36. 画像 : オライリー https://www.oreilly.co.jp/books/9784873115658/ 36 リーダブルコード 変数の命名方法、コメントの記法 細やかな処理のテクニックなど コードの可読性を上げるための ノウハウが詰まってる 他人に読みやすい コードを書くことは 生産性を大きく向上させる ※過去・未来の自分は他人
37. プリンシプル オブ プログラミング さまざまな事例をもとにした プログラミングの原則や思想、 アンチパターンなどを紹介 どのように 開発を進めていくのか を助けてくれる 画像 : 秀和システム https://www.shuwasystem.co.jp/book/9784798046143.html 37
38. 画像 : SBクリエイティブ https://www.sbcr.jp/product/4797311126/ 38 オブジェクト指向における再利用のためのデザインパターン いろんなデザインパターンが わかりやすく解説されてる サンプルコードも豊富で かなり参考になる 知ってるだけでも 取れる選択肢がぐっと増える (なんとなくでも知ってれば 必要になったときに調べれば良い)
39. 画像 : 秀和システム https://www.shuwasystem.co.jp/book/9784798021188.html 39 ゲームプログラマになる前に覚えておきたい技術 ゲームプログラムを0から 書く方法が詰まってる Unityなどのエンジンがやってく れる処理を自力で実装できるため の知識や技術の宝庫 数学や物理学などの情報も 併記されているので安心 効果的な処理を 書けるようになるかも？
40. Keep It Simple, Stupid. 40