完全管理されたRojo

すべてがGitに存在するRobloxプロジェクトのチームワークフロー：コード、設定、アート、レベルレイアウト。プレースはリポジトリから構築され、手動で編集されることはなく、すべてのビルドはコミットに追跡可能です。

これがStudioの役割をどのように変えるか

このワークフローは、Roblox Studioを正確に2つのものとして扱います：

1. デプロイメントターゲット。 Rojoはリポジトリから.rbxlプレースファイルを組み立てます。Studioはそれを開き、実行し、公開しますが、プレースは決して真実のソースではありません。
2. .rbxmモデルを構築するためのツール。 Studioで1つのアセットまたは1つのエリアを構築または編集し、次にファイルに保存でリポジトリにエクスポートします。Rojoはエクスポートされたファイルをプレースにまとめます。

ゲームの構成を定義するのはStudioではなくリポジトリです。 プロジェクトファイルとフォルダーレイアウトは、どの.rbxmファイルがどこに行くかを示します。これらのファイルはStudioから1つずつエクスポートします。

このため、通常のStudioワークフローは適用されません：

• チーム作成なし。 誰も共有プレースを共同編集しません。コラボレーションはブランチとPRを通じて行われます。
• ライブプレースでの反復的なワールド編集なし。 Devでレベルを時間をかけて構築し、プレースを保存することはできません。.rbxmにエクスポートされていない編集は、次のビルドで破棄されます。
• パッケージなし。 Gitはパッケージが提供するバージョン管理と共有を提供します。

チームがTeam Createとプレースでのレベル編集に依存している場合は、代わりにRojo + パッケージワークフローを使用してください。

短いバージョン

• コード、設定、アート、レベルはsrc/の下にGitに存在します。アートとレベルのピースは.rbxmファイルです。
• Rojoはリポジトリからプレースを構築します。 コードはrojo serveでライブに反復します。アートの変更はプレースを再構築することで反映されます。
• 全員が自分のユーザープレースで作業し、PRを通じて変更を提出します。
• CIはマージごとにDevをビルドして公開し、リリースタグからStableをビルドします。
• Prodはライブゲームです。

プレース

すべてのプレースはプロジェクトのグループによって所有されています。

DevまたはStableを手動で編集しないでください。 次のCI公開で上書きされます。何かを変更する必要がある場合は、Gitで変更してください。

どこに何があるか

ファイルを整理するためのいくつかのルール：

• アセットまたはエリアごとに1ファイルにすることで、差分が小さく、マージコンフリクトが少なくなります。ファイル名は構築されたプレースのインスタンス名になります。
• アートとレベルには.rbxmを使用します。 バイナリファイルはメッシュを含む場合、XMLよりもはるかに小さくなります。rbx-mergeを使用して、それらを差分およびマージします。詳細は以下を参照してください。
• すべての設定はGitに含める必要があります。 構築されたプレースにはリポジトリにあるものだけが含まれます。照明やWorkspace.StreamingEnabled、Players.CharacterAutoLoadsのような設定はプロジェクトファイルに入れます。Studioでのみ設定されたものは次のビルドで失われます。
• 地形はバイナリであり、Rojoはライブ同期できません。 それを1人の人が所有する独自のファイルに保管してください。依存する前に、rojo buildで生き残ることを確認してください。

プロジェクトファイル

{
  "name": "MyGame",
  "tree": {
    "$className": "DataModel",
    "ReplicatedStorage": { "$path": "src/ReplicatedStorage" },
    "ServerScriptService": { "$path": "src/ServerScriptService" },
    "Workspace": {
      "$path": "src/Workspace",
      "$properties": { "StreamingEnabled": true }
    },
    "Lighting": {
      "$properties": { "Technology": "Future", "ClockTime": 14 }
    }
  }
}

リポジトリレイアウト

src/
├── ReplicatedStorage/
│   ├── Systems/
│   ├── Libraries/
│   └── ManagedContent/
│       ├── ItemDefinitions/
│       └── Art/
│           ├── Props/Crate.rbxm
│           └── Characters/Hero.rbxm
├── ServerScriptService/
│   ├── Systems/
│   └── ManagedContent/
└── Workspace/
    └── Areas/
        ├── Town.rbxm
        └── Forest.rbxm

アートが再構築される理由、ライブ同期されない理由

Rojoのライブ同期（rojo serve）はStudioプラグインAPIを介して行われ、このAPIは一部のプロパティを設定できません：MeshPart.MeshId、地形、CSGパーツ。rojo buildはプレースファイルを直接書き込み、この制限はありません。Rojo同期の詳細を参照してください。

したがって、ルールは次のとおりです：

• コードと設定の変更： 通常通りrojo serve + 接続。
• アートとレベルの変更： rojo buildでプレースを再構築し、再度開きます。

セットアップ（プロジェクトごとに1回）

1. リポジトリをクローンし、Rokitでツールチェーンをインストールします：rokit installを実行します。
2. rbx-mergeを設定して、.rbxmファイルが適切に差分およびマージされるようにします：

   • リポジトリごとに1人がこれを実行し、結果をコミットします：rbx-merge install --write-gitattributes。
   • クローンごとに、全員がrbx-merge installを実行し、その後rbx-merge doctorを実行して動作を確認します。
3. ソースアートストレージを設定します： Git LFSをインストール（git lfs install）、またはプロジェクトのPerforceデポへのアクセスを設定します。
4. ユーザープレースを構築します：

   • rojo build default.project.json -o build/place.rbxlを実行し、次にStudioでbuild/place.rbxlを開きます。
   • 他の人とテストするには、ファイル → 別名で公開を選択し、プロジェクトグループを選択し、USER / [名前] - [プロジェクト] - [レベル]と名付けます。
5. Rojoを接続します： rojo serveを実行し、次にStudio Rojoプラグインで接続をクリックします。

エンジニア：コードループ

1. mainからブランチを作成します。
2. ユーザープレースを構築し（セットアップステップ4）、rojo serveを接続します。
3. 通常通り作業します。アートの変更をプルしたら、プレースを再構築して再度開きます。
4. PRを開く前にstylua（フォーマット）とselene（リンティング）を実行します。
5. PRを開いてレビューを受けます。CIはすべてのPRでテストrojo buildを実行する必要があります。
6. mainにマージします。CIが新しいビルドをDevに公開します。

アーティスト：アセットループ

ソースアートのインポート

1. ソースファイル（FBX、PSD、テクスチャ）をGit LFSまたはPerforceに保管します。
2. Studioの3Dインポーターを使用してインポートし、プロジェクトグループにアップロードします。アセットはグループに属し、リポジトリから構築されたすべてのプレースで使用できます。アセットのプライバシーを参照してください。
3. メッシュやテクスチャを変更する場合は、再度アップロードする必要があり、新しいアセットIDが付与されます。それを使用するインスタンスを更新し、.rbxmを再保存します。

アセットの追加または変更

1. ブランチを作成し、ユーザープレースを構築して開きます。
2. Studioでアセットを構築または編集します。各アセットを単一のモデルとして保持します。
3. 右クリックして、ファイルに保存 → .rbxmを選択し、ManagedContent/Art/…の下のパスに保存します。既存のアセットを上書きするには同じパスを使用します。
4. プレースを再構築し、アセットが正しく表示されることを確認します。
5. コミットしてPRを開きます。レビュアーはgit diffで変更を確認でき、rbx-mergeがそれを読みやすいテキストに変換します。
6. マージします。CIが変更をDevに公開します。

レベルレイアウト

• 各エリアはsrc/Workspace/Areas/の下に1つの.rbxmです。
• ユーザープレースでエリアを編集し、同じファイルにファイルに保存で戻します。
• 再構築すると、保存されていないStudioの変更が破棄されます。 再構築またはプルする前にファイルに保存してください。
• 各エリアの所有者を合意します。2人が同じエリアを編集すると、通常はコンフリクトが発生します。

レベルにアセットを配置する

• 構築されたプレースにはパッケージスタイルのリンクはありません。エリアに配置されたアセットのコピーは、元のアセットファイルを変更しても更新されません。
• オプション1（推奨）： よく再利用するキットピースの場合、コピーの代わりにレベルにマーカーを配置します。たとえば、Crateという名前のタグ付きパーツです。スクリプトが実行時に各マーカーをManagedContent/Artからのアセットに置き換えます。アセットファイルを変更すると、すべての配置が更新されます。
• オプション2： 完全なコピーを配置し、元のアセットが変更されたときに手動で更新します。

マージとコンフリクト

• rbx-mergeは.rbxmファイルをインスタンスごとにマージします。2人が同じファイルの異なる部分を変更した場合、マージは自動的に完了します。
• 両方の側が同じプロパティを変更した場合、 Gitはコンフリクトを報告し、rbx-mergeは.rbxmerge/<file>/conflicts.txtにレポートを書き込みます。解決するには：

  1. レポートで、各コンフリクトに対してresolution = ours | theirs | baseを設定します。
  2. rbx-merge resolve --stash-dir .rbxmerge/<file> --out <file>を実行します。
  3. git add <file>を実行し、マージを続行します。
• ソースアートはマージできません。 LFSファイルロック（git lfs lock）またはPerforceの排他的チェックアウトを使用して、1人だけがファイルを編集できるようにします。

CI：ビルドと公開

パイプラインには、アセット権限と読み取りおよび書き込みアクセスを持つOpen Cloud APIキーが必要で、各プレースのIDも必要です。これらをCIシークレットとして保存します。

すべてのビルドはコミットから来ているため、悪いリリースの後でも、以前のバージョンを再ビルドおよび再公開できます。

コミュニケーション

各プロジェクトに一般チャンネル、エンジニアリングチャンネル（PRリンク、技術的議論）、アートチャンネル（WIP、レビュー）を設けます。

参考

• Rojoプロジェクト形式
• Rojo同期の詳細
• rbx-merge
• Git LFS
• アセットのプライバシー
• Open Cloudプレース公開