Githubを用いたチーム制作
#記事
#VRC演出ワールド制作固有のTips
Github自体の解説は世に溢れていますが、VRC演出ワールド制作固有のGithubの使い方についてはあまり共有されていません。
私はGit/Githubについて全然、Gitクライアントからしか操作できない程度には詳しくないのですが、この記事をきっかけにより良い情報が共有されることも期待して、私が運用を決めて良い場合にどうしているかを紹介します。
gitignore
UdonSharp/.gitignore at master · MerlinVR/UdonSharp
これとか、Unity標準のgitignoreをベースに作るので良いと思います。
サンプル通りですが、以下のような内容を足して使ってます。
vscodeなどUserごとの設定関連
Houdini関連ファイル(indieライセンスではシーンファイルやアセットの共有は認められていない、出力されたものはOK)
キャッシュやバックアップは単に重い
fbxを読むとfbmフォルダが生成されるので除外
サブスタンスもオートセーブがあるので除外
ASEとBakeryはほぼ100%入れるので除外
その他のアセットは個別に記載せずAssets/AssetStoreTools以下に移動して除外する
UnityRecorderも制作したエフェクトの共有等でよく使うのでAssets/Recordingsを除外
code:ignoresample
# Visual Studio cache directory
.vs/
.vscode/
# UserSettings
/UserSettings/QuickSearch.settings
# Houdini backup
backup
# Houdini cache
*filecache*
# hip and backup
*.hip*
*backup*
# sbs backup
*.autosave*
# CliantSimStorage
ClientSimStorage*
#BuildReport
Assets/_LastBuild*
# Bakery
Assets/Bakery*
Assets/Editor*
Assets/Settings/Bakery*
Assets/Settings.meta
# Assets
Assets/AmplifyShaderEditor*
Assets/AssetStoreTools*
Assets/**/*Iignore*
Assets/Recordings*
# fbm
*.fbm
*.fbm.meta
SerializedUdonProgramsどうするのか問題
これは自分のところでは未解決で、Udonスクリプトから参照されるのでgitignoreには含められず、しかし更新をプッシュする必要はない(逆にしてしまっても問題ない)という状態で運用しています。
ビルドするたび/実行するたびに更新され参照するguidが変わり、無意味に差分が発生します。
そのうち整理して解消しておきたいですが、単に見た目上邪魔である以外の問題も発生していません。
とりあえず以下で運用しています。正しいかはわかりません。
初回作成時はプッシュする
変更時はプッシュしてもしなくても動作に影響なし(再作成されるため)
競合した場合もどちらを破棄しても問題ない
何かいい感じの情報があれば教えてください。
情報を頂いたので、近いうちこれを試してみようと思います。
anatawa12/git-vrc: A command line extension for git to reduce meaningless diff on git of VRC project.
Prefab管理
Prefab自体についての解説は割愛します。
どのPrefabに自分の更新が書き込まれているのか(またはシーンに直書きしているのか)というのは最低限意識して操作できた方がいいです。
非エンジニア的な人にそれを求めるのは少し難しいという側面もありますが、シーンに直書きしたり、上の階層のPrefabで変更すると下の階層での変更は上書きされてしまい、それ以上各セクションの担当者側での変更が出来なくなってしまうということは理解してもらう必要があるように思います。
その辺の説明も込みで早めにやるつもりでいたほうが、あとで苦労しないだろうと思います。
私は毎回おおむねこんな感じのPrefab構成です。
https://scrapbox.io/files/6958ae1d3c60a53017b1c9d2.png
Gimmickとか入れたりすることもあります。
Artistが存在しなければArtistがなかったりとか。
MainTimelineの下にビームライト用のTimelineやAudio用のタイムラインを早めに入れてネストしておき、それぞれ担当者が好きに作業を進められるようにしておくとよいです。
EnvironmentsにはStageとかBuildingsとかそういうものが入りますが、モデラー側で触る大本のPrefabのPrefab Variantを作っておき、それをEnvironments内に入れておくのもアリだと思います。Variantを我々が触ることで、最適化やベイクの設定をモデルの更新と競合することなく行えます。
もちろんモデラー側の設定変更を上書きしてしまうので、モデラーがそのあたりをどれくらいわかっている/やりたい人なのかによって変わってきます。
オブジェクト名や階層が変更されるとこちら側の設定変更が飛ぶので、それは伝えておく必要があります。
ブランチの切り方
Asset SerializationをForce Text(デフォルト)にしていても、何らかの条件(多分一定以上複雑な内容になったとき)でSceneやPrefabはバイナリファイルとして扱われるようになり、マージができなくなります。
ブランチは基本切らず、どのPrefabを誰が触るかの管理を厳格に行うことで並行作業ができるようにしています。
Prefabを複数人が別々に編集した場合は必ずコンフリクトすることになるので、その発覚はむしろ早い方が被害が少ないです。できるだけこまめにPushしてもらうようにしています。
演出制作においてはよほど綺麗に閉じた領域でなければプルリクをもらってもレビューすることが難しいです。何度かやったことがありますが、あまり時間対効果があると思えなかったのでやっていません。
Githubの説明で想定されがちなwebサービス等と異なり、制作途中でも常に正しく動作する必要性は薄く、不具合があったら都度直せばいいだけです。
コンフリクト発生時のマージだけ注意して行います。大抵は一方が担当ではないファイルを誤って更新しているだけなので、そちらを破棄します。
ただし完成後に調整したり、複数の公開パターンがある場合などブランチを切ったほうがいいことはもちろんあります。
TimelineBindingResolver(TBR)
ここまでの内容を踏まえて、以下の解説資料を読むと素晴らしさがよくわかる…かもしれません。
実際のチーム制作を1回やれば、いずれにしてもわかると思います。
たのしいTimelineBindingResolver
要は上層のPrefabに入れざるを得ないTimelineのBinding(他オブジェクトへの参照)を自身に記録し、Sceneを開いたときに復元することでPrefab内に収めておくことができるコンポーネントです。
チーム制作にはほぼ必須といえます。
同様の問題は実はTimelineに限らずConstraintやスイッチ系ギミックでも発生しますが、大抵は数が多くならないのでRootPrefabで吸収する形で十分なことが多いです。
本当は作ったほうがいいです、AnythingBindingResolverを…
GameObjectやTransformの参照だけでよければ全然できそうな気もします。