部分管理されたRojo

コードをGitで管理し、アートをパッケージでバージョン管理し、全員が互いの変更を上書きすることなく作業できるRobloxプロジェクトのチームワークフロー。

短いバージョン

• コードはGitにあり、Rojoを通じてStudioに入ります。
• アートはRobloxにパッケージとして存在します。オリジナルはAsset placeにあり、Dev placeのコピーは自動的に更新されます。
• 全員が自分のUser placeで作業し、完成した作業を共有のDev placeに持ち込みます。
• Stableはプレイテスト用のDevの凍結スナップショットです。Prodはライブゲームです。

プレイス

すべてのプレイスはプロジェクトのグループが所有しています。Publish Asをクリックする前に、グループが選択されていることを常に確認してください。

物の配置

Rojoは部分管理として設定されています：Gitがコードと設定を所有し、プレイスファイルがアートとレベルを所有します。各ランタイムロケーション（ReplicatedStorage、ServerScriptService）には2つのコンテンツフォルダーがあります：

ManagedContent：Gitが真実の源

• Rojoはディスクから再構築するため、Studioの編集は次の同期で上書きされます。ディスク上のファイルを編集してください。
• ファイルは.luauモジュール、.model.json記述子、または.rbxmxインスタンスです。
• Studioで作成したものをManagedContentに移動するには：

  • 右クリックしてSave to File → .rbxmxを選択します。XML形式は、バイナリの.rbxmとは異なり、可読な差分を提供します。
  • ファイルをManagedContent/の下に置き、コミットします。
• 設定としてコードが読み取るものに使用します。コードレビューとGitの履歴がそれをカバーします。

コンテンツ：プレイスファイルが真実の源

• Rojoはそれを無視し、ディスク上にファイルがないため、エディタのオートコンプリートはそれを認識できません。
• MeshPartsに必要です。Rojoはそれらを同期できません。
• アーティストがStudioで編集するアートに使用します：小道具、キャラクター、VFX、ステージング。
• コードが所有する設定をここに置かないでください。レビューや差分が見えなくなります。
• 唯一の履歴はRobloxのプレイスバージョン履歴です。したがって、Devを定期的に公開してください。

プロジェクトファイル

RojoにContentを無視させるには、$ignoreUnknownInstancesを使用します：

"ReplicatedStorage": {
  "$path": "src/ReplicatedStorage",
  "Content": {
    "$className": "Folder",
    "$ignoreUnknownInstances": true
  }
}

リポジトリのレイアウト：

src/
├── ReplicatedStorage/       # 共有 + クライアント
│   ├── Systems/
│   ├── Libraries/
│   └── ManagedContent/
└── ServerScriptService/     # サーバー専用、複製されない
    ├── Systems/
    ├── Libraries/
    └── ManagedContent/

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

1. リポジトリをクローンし、ツールチェーンをインストールします。私たちはRokitを使用します：rokit installを実行してrojo、selene、StyLua、luau-lsp、luneを取得します。
2. User placeを作成します：

   • Dev placeを開きます。
   • File → Publish Asを選択し、プロジェクトグループを選択して、USER / [Name] - [Project] - [Level]という新しいプレイスを作成します。
   • Devを閉じて、新しいプレイスを開きます。
3. Rojoを接続します：

   • エディタでリポジトリを開き、rojo serveを実行します。
   • Studioで、RojoプラグインのConnectをクリックします。

あなたのUser placeはDevのコピーであるため、そのパッケージはリンクされたままです。プレイスを開くたびに最新バージョンに更新されます。

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

1. mainからブランチを作成します。
2. DevからUser placeを更新し、最新のレイアウトとアートから始めます：

   • Dev placeを開きます。
   • File → Publish Asを選択し、プロジェクトグループを選択して、既存のUser placeを上書きします。
3. rojo serveが接続された状態でUser placeで作業します。
4. PRを開く前にstylua（フォーマット）とselene（リンティング）を実行します。
5. PRを開いてレビューを受けます。
6. 承認されたら、mainにマージします。
7. Devを同期します：

   • git checkout main && git pullを実行します。
   • Dev placeを開き、rojo serveを実行し、接続します。
   • 変更がプレイス内のレイアウト変更（新しい属性やプレースホルダーアセットなど）を必要とする場合は、それらもDevに追加します。RojoはコードとManagedContentのみを同期するため、それらを持ち越しません。

Rojo管理されたスクリプトやManagedContentをStudioで手動で編集しないでください。次の同期で消去されます。

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

既存のアセットを変更する

1. Asset placeを開き、オリジナルのパッケージを編集します。
2. 右クリックしてPublish to Packageを選択します。
3. Dev内のコピーが変更を受け取ります：

   • AutoUpdateがオンのコピーは、次回Devを開いたときに更新されます。
   • Devがすでに開いている場合は、コピーを右クリックしてGet Latest Packageを選択します。また、Update Allを使用してゲーム内のすべてのプレイスを更新することもできます。
4. オプションで、Package Details → Versionsの下にバージョンノートを追加します。

新しいアセットを追加する

1. Asset placeでそれを構築します。後で子を追加できるように、単一のオブジェクトであってもModelとしてグループ化します。
2. 右クリックしてConvert to Packageを選択します。

   • Ownershipをプロジェクトグループに設定します。所有権は後で移転できません。
3. PackageLinkを選択し、AutoUpdateをオンにします。
4. Devに追加します：Toolboxで、Creations → Group Packagesに移動し、それを挿入してWorkspaceまたはContentに配置します。

レイアウトとレベル作業

• User placeで物を配置します。
• リードが承認したら、変更をDevにコピーします。Devで共有レイアウトパスのためにTeam Createを使用します。

パッケージルール

• Asset placeでのみパッケージを編集します。Devでコピーを編集すると、変更されたとマークされ、自動更新が停止します。誤って編集した場合は、右クリックしてUndo Changes to Packageを選択します。
• PackageLinkを削除または移動しないでください。そうすると、コピーが通常のモデルに戻ります。
• ネストされたパッケージ：内側のパッケージを最初に公開し、その後外側のものを公開します。
• ロールバック：Package Details → Versionsに移動し、以前のバージョンを選択してSubmitをクリックします。
• バージョンの比較：パッケージを右クリックしてPackage Options → Compare Package Versionsを選択します。
• AutoUpdateはデフォルトでオフです。コピーのPackageLinkでAutoUpdateをオンにすると自動的に更新されます。オフのままにすると手動でコピーを更新します。
• アクセス：チーム全体が使用および編集できるように、グループとパッケージを共有します。Asset privacyを参照してください。

リリース：Dev → Stable → Prod

Dev → Stable（デプロイスクリプト）

小さなデプロイスクリプトを書きます；Luneがこれに適しています。スケジュールで実行するか、各プレイテストの前に実行します。スクリプトは次のことを行うべきです：

1. 現在のDev placeをダウンロードし、Content、Workspace、ライティングを含めます。
2. すべてのPackageLinkを削除します。パッケージは通常のモデルになり、Stableは凍結され、アーティストが新しいパッケージバージョンを公開しても変更されません。
3. 結果をStable placeに公開します。Open Cloud place publishing APIを使用します。assets権限とReadおよびWriteアクセスを持つAPIキーが必要で、プレイスIDも必要です。

テスターは、チームがDevで作業を続ける間に安定したビルドを受け取ります。誰も手動でStableを編集しません。

Stable → Prod

リリースオーナーがStableをProdにコピーし、承認が必要です。Prodはライブであるため、他の誰もそれに触れません。

コミュニケーション

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

参考

• Packages
• Asset privacy
• Collaboration and Team Create
• Open Cloud place publishing
• Rojo project format