roblox-architecture

Robloxのアーキテクチャ

読み込むタイミング

所有権、統合、境界、起動、モジュール分割を扱う場合に読み込みます。

クイックリファレンス

再構築する前に、実績のあるプロジェクトモジュールを再利用してください。契約と失敗時・クリーンアップ時の経路を確認してください。統合ワークフローについては、full.md を参照してください。

まず所有者を1つにする

各動作について、次の項目を明確にします。

• 権威ある状態と、それを変更できる主体
• 公開操作と呼び出し元
• 所有するRobloxインスタンス、接続、タスク
• 永続化またはネットワークの境界
• 起動条件と終了条件

1つの変更をまとめられる場合は、機能ごとにグループ化します。サーバー、クライアント、共有コードの分割は、ランタイム境界で必要な場合に限ります。共有コードにシークレットや、権威ある可変状態を含めてはいけません。

依存関係の形を最小限にする

通常は、モジュールを直接呼び出します。1つの発行元に本当に独立したオブザーバーがいる場合に限り、シグナルを使います。通常の依存関係を隠すために、イベントバス、依存関係コンテナー、マネージャークラス、Init／Start の儀式を追加してはいけません。

モジュールのトップレベル処理は軽量にし、yieldしないようにします。順序が必要な起動処理は、小規模なブートストラップが担い、順番に呼び出して失敗を明示させます。並行処理は自動的にあちこちで task.spawn を使うのではなく、明示的かつ安全に行います。

複製を通じて依存関係が届く場合は、WaitForChild にタイムアウトを設定します。無期限の待機は、インスタンスがない場合に処理を無言で停止させます。

ランタイムの権限を徹底する

クライアントは提示と予測を行い、サーバーは検証して決定します。リモートは、型、上限、所有権、不正利用対策、失敗時の動作を備えたAPIです。詳細は roblox-networking と roblox-security を参照してください。

根拠がある場合に限り分割する

ライフサイクルや権限の境界が別にある場合、永続化の契約が異なる場合、独立してテスト可能な純粋なコアがある場合、または変更理由が互いに無関係な場合に分割します。

データ指向の代替案：根拠がある場合に限る

多くの類似エンティティが毎フレーム、順序に依存しないロジックで更新される場合、または複雑に絡み合ったエンティティごとのスクリプトを横断的なクエリで置き換えられる場合に限り、ECSのコストに見合います。フックで不変条件を守り、順序付きシステムで判断します。バージョン固有の注意点については、full.md の「ECS on Roblox」を参照してください。

レビュー

変更ごとに正規の所有者を1つにし、隠れた起動時のyieldや複製を介した信頼判断を避け、クリーンアップを明示し、追跡可能な最小限の構造にします。タグは検出、属性は設定に使い、アタッチ／削除時のクリーンアップは1つの所有者に任せます。

詳細：references/full.md