開発者向けオンボーディング

このページでは、他のエンジンから来たエンジニアが最初の数週間に最も必要とするRobloxの基本をカバーしています。各セクションでは、コアアイデアを説明し、詳細なガイドへのリンクを提供します。

一般的な用語

• ゲーム: プレイヤーがゲームのスタートプレイスを通じて参加する場所のコレクション。データストア、シークレット、分析、ゲーム内購入はすべてゲームにスコープされており、経験やユニバースとも呼ばれることがあります。
• プレイス: ゲーム内のシーンやゾーンで、独自のデータモデルを持っています。各サーバーは1つのプレイスを実行し、プレイヤーをプレイス間で移動させるにはテレポートが必要です。
• インスタンス: プロパティ、メソッド、イベントを持つデータモデル内のノード。PartsおよびModelsは、物理オブジェクトを構築するための最も一般的なインスタンスです。
• アセット: グローバルに一意のアセットIDを持つアップロードされたコンテンツ（画像、メッシュ、サウンド、アニメーションなど）。モデルやアニメーションのような一部のアセットタイプはその場で更新できますが、画像やサウンドのような他のアセットは新しいアセットをアップロードする必要があります。
• スクリプト: データモデル内のインスタンスとして保存されたコード。スクリプトをコピーすると、元のファイルへの参照ではなく、完全で独立したコピーが作成されます。

ゲームとプレイスの関係についての詳細は、ゲームとプレイスを参照してください。

データモデルの構造

データモデルは、プレイスを構成するインスタンスのツリーです。そのトップレベルのサービスはそれぞれ特定の目的とレプリケーションの動作を持っています：

Explorer内の階層は主に組織的です：

• パーツはワールドスペースの変換を使用し、親に対する変換ではありません。パーツを互いに接続するには、最も一般的なWeldConstraintを使用します。詳細については、機械的制約を参照してください。
• Attachmentsは例外で、親パーツに対して相対的に位置します。
• Modelsは、全体のモデルを移動およびピボットするための基準点としてPrimaryPartを使用します。

スクリプティングモデル

ほとんどの場合、必要なのは2種類のスクリプトだけです：

• Scriptで、そのRunContextがServerまたはClientに設定されているもの。
• 他のスクリプトがrequire()で読み込む値を返すModuleScript。共有ライブラリ、関数、データにはモジュールを使用します。

LegacyランコンテキストやLocalScriptsは避けてください。これらの動作は配置場所に依存し、コードの整理が難しくなります。推奨される場所については、スクリプトの種類と場所を参照してください。

サーバースクリプトはクライアントにレプリケートされません。モジュールは、クライアントがアクセスできるコンテナ（ReplicatedStorageなど）にある場合にクライアントにレプリケートされます。サーバー専用のモジュールはServerScriptServiceまたはServerStorageに保持してください。

ネットワーキングとレプリケーション

Robloxはクライアント-サーバーモデルを使用しています：

• サーバーがインスタンスに加える変更（プロパティ、属性、タグを含む）は、自動的にクライアントにレプリケートされます。
• クライアントが加える変更は、いくつかの例外を除いてサーバーにレプリケートされません。主な例外は、クライアントが所有するパーツ（自分のキャラクターなど）に対する物理学と、入力アクションシステムからの入力です。
• エンジンは、サーバーとクライアント間で物理シミュレーションを分配します。クライアントは自分が所有するパーツをシミュレートし、位置と速度をサーバーに送信します。

クライアントとサーバー間で通信するには、リモートイベントとコールバックを使用します：

• RemoteEventとRemoteFunctionは信頼性が高く、順序が保証されています。
• UnreliableRemoteEventは信頼性が低く、順序が保証されていないため、メッセージが失われても問題ない頻繁な更新に使用します。
• リモートはデフォルトで保護されていません。サーバーがクライアントから受け取るデータは常に検証してください。

サーバー権限

競技ゲームでは、サーバー権限により、サーバーが物理学とゲームプレイに対して権限を持ち、クライアントは自分のキャラクターや近くの物理オブジェクトを予測します。クライアントが誤って予測した場合、ロールバックして再シミュレーションします。

入力

入力アクションシステムを使用して入力を処理します。InputContextインスタンスでジャンプやスプリントなどのアクションを定義し、InputBindingインスタンスを使用してキー、ボタン、タッチコントロールにバインドします。サーバー権限を使用する場合、各InputContextはPlayerの子孫である必要があり、エンジンはどのプレイヤーがそれを所有しているかを知ることができます。1つのアプローチは、ReplicatedStorageにコンテキストを保持し、サーバースクリプトから各プレイヤーにクローンすることです。詳細については、入力アクションを参照してください。

ストリーミング

インスタンスストリーミングは、プレイヤーが世界を移動する際にワークスペースの一部を各クライアントにロードし、すべてのデバイスでロード時間とメモリを低く保ちます。

• ReplicatedStorage内のインスタンスは、プレイヤーが参加する際に完全にレプリケートされ、スクリプトが実行される前に安全にアクセスできます。
• ワークスペース内のインスタンスはストリーミングされ、クライアントコードはまだロードされていないインスタンスを処理する必要があります。
• 制約で接続されたインスタンスは一緒にストリーミングされ、物理を安定させます。

各Modelには、ストリーミングの方法を制御するModelStreamingModeがあります：

テクスチャ、メッシュ、オーディオなどのアセットもランタイムでストリーミングされます。画像は最初に低解像度でロードされ、その後デバイスや画面上のサイズに基づいて改善されます。

データの永続性

DataStoreServiceは、セッション間でプレイヤーデータを保存します。そのAPIは低レベルであるため、保存システムを設計する前にデータストアとプレイヤーデータと購入を読むことをお勧めします。これらのガイドでは、レート制限、セッションロック、安全な購入処理などの一般的な落とし穴をカバーしています。

データストアはゲームにスコープされています。テストデータを本番から除外するには、開発用に別のゲームを使用してください。詳細については、環境を参照してください。

一般的なタスクを解決する

インスタンス間での動作の再利用

コピーされたスクリプトは独立したコピーであるため、必要なすべてのインスタンスに同じスクリプトのコピーを置くことは避けてください。代わりに、CollectionServiceでインスタンスにタグを付け、すべてのタグ付けされたインスタンスに動作を付加する1つのスクリプトをModuleScriptでバックアップして書きます。

カスタムキャラクターを使用する

キャラクターはプラットフォームアバター、カスタムルックのプラットフォームリグ、または完全にカスタムのリグを使用できます。デフォルトのスポーンシステムを維持しつつキャラクターを置き換えるには、StarterPlayer内にStarterCharacterという名前のモデルを配置します。

デフォルトの制御スクリプトをオーバーライドする

Robloxは各プレイヤーにデフォルトのカメラスクリプトと制御スクリプトを追加します。これらを置き換えるには：

1. Workspace.PlayerScriptsUseInputActionSystemを有効にし、デフォルトのプレイヤースクリプトをStarterPlayerの下に移動します。
2. StarterPlayer.CreateDefaultPlayerModuleをfalseに設定して、デフォルトのカメラスクリプトと制御スクリプトが追加されないようにします。
3. 自分のカメラスクリプトと制御スクリプトを追加します。

シェーダーのような効果を作成する

Robloxはカスタムシェーダーをサポートしていません。代わりに：

• PBRマテリアルにはSurfaceAppearanceまたはMaterialVariantを使用します。
• エミッシブサーフェスにはSurfaceAppearanceまたはNeonマテリアルを使用します。
• 交差効果にはForceFieldマテリアルを使用します。
• 特殊なケースでは、EditableImageとEditableMeshを使用して動的なテクスチャとジオメトリを生成します。

パフォーマンス

Robloxのパフォーマンスは、主に追加するコンテンツとスクリプトが各フレームでかかる時間に依存します。ターゲットハードウェアで定期的にテストし、シーンの複雑さ（三角形、ドローコール、動的ライト）、物理、レプリケーション、フレームごとのスクリプト時間のために早期に予算を設定してください。ほとんどのパフォーマンスの問題は、誤って構成されたコンテンツから生じ、遅れて修正することはしばしばアセットの再作成を意味します。

• 自動品質: ほとんどのプレイヤーは自動グラフィックス品質を使用しており、10段階のレベルがあります。レベルが下がるとフレームレートを維持するために、エンジンはレンダリング距離、ジオメトリ品質（詳細レベルやSLIM）、シェーディング品質、ライティング品質、影、パーティクル放出、ストリーミング半径を低下させます。描画距離は500スタッドを下回ることはなく、影はレベル4未満でオフになり、地形の水やビームはすべてのレベルで同じに見えます。Robloxはこれらの値を継続的に調整しているため、正確な数値に基づいて設計しないでください。プレビューするには、Studio設定でエディター品質レベルを変更し、最低レベルと最高レベルの両方でテストします。詳細については、グラフィックス品質レベルを参照してください。
• テクスチャストリーミング: テクスチャは自動的にストリーミングされ、メモリ予算と画面上のサイズに合わせてスケールします。
• オクルージョンカリング: エンジンは、他のオブジェクトの背後に隠れているパーツ、メッシュ、地形のドローコールを自動的にスキップします。壁や他の視界ブロッカーでレベルを構成することで、シーンの複雑さを管理できます。壁の中にシンプルな隠れたブロックパーツを作成することで、詳細なメッシュに依存するよりもオクルージョンテストを安くできます。ドローコールを減らすための他の方法については、レンダリングを参照してください。
• スクリプティング: Luauは複雑で動的なゲームプレイコードに十分な速度です。ガーベジコレクションを避けたり、オブジェクトをプールしたりする必要はなく、ランタイムでインスタンスを作成するのも速いです。
• ライティング: シーンは多くのライトを使用できます。Robloxはデバイスに応じてライティング品質を自動的にスケールし、複雑なシーンではコストの低いライティングパスにフォールバックします。

問題を測定し修正するためのツールについては、パフォーマンス最適化を参照してください。

ツールとAI

• 外部エディタ: VS CodeやScript SyncやRojoを使用する他のエディタを使用します。タイプチェックとリンティングのためにLuau Language Serverとseleneリンターを追加します。チームセットアップについては、ファイルベースのワークフローを比較を参照してください。
• Studio MCPサーバー: ほとんどのプロの開発者は、ターミナルやエディタ内のコーディングエージェントのような独自のAIツールとエージェントハーネスを使用したいと考えています。Studio MCPサーバーは、これらのツールをStudioに接続し、オープンセッション内で直接ビルドおよびテストできるようにします。
• アシスタント: アシスタントは、コードを書くためのStudioの組み込みAIヘルパーであり、独自のツールを設定せずにAIの助けを必要とする場合に便利です。