スクリプトの種類と場所

多くの開発者にとって、Robloxスクリプティングに適応する際の基本的な課題は、ファイルの場所と Script.RunContext プロパティの重要性です。スクリプトの種類、Explorer内の場所、および実行コンテキストによって、スクリプトの動作は非常に異なる場合があります。特定のメソッド呼び出しが失敗することがあるかもしれませんし、ゲーム内のオブジェクトにアクセスできないこともあります。また、スクリプトが全く実行されないこともあります。

この複雑さの理由は、Robloxゲームがデフォルトでマルチプレイヤーであるためです。スクリプトは、サーバー上でのみ実行される、クライアント上でのみ実行される、または両方で共有される必要があります。Robloxプラットフォームの進化は、状況をさらに複雑にしています。

スクリプトの種類

Robloxには3種類のスクリプトがあります：

• Script - その場所と Script.RunContext プロパティに応じて、サーバーまたはクライアントのいずれかで実行されるコード。
• LocalScript - クライアント上でのみ実行されるコード。実行コンテキストはありません。
• ModuleScript - 他のスクリプトで再利用できるコード。実行コンテキストはありません。

Scriptを作成すると、そのデフォルトの実行コンテキストは Legacy であり、つまり a) サーバーサイドスクリプトであり、b) ServerScriptService や Workspace などのサーバーコンテナ内にある場合にのみ実行されます。

• スクリプトの実行コンテキストを Server に変更すると、ReplicatedStorage でも実行できるようになりますが、推奨はしません。その場所の内容はクライアントに複製されるため、サーバーサイドスクリプトには不適切な場所です。
• スクリプトの実行コンテキストを Client に変更すると、ReplicatedStorage で実行できるようになります。また、StarterCharacterScripts や StarterPlayerScripts でも実行できます。ただし、スタートコンテナはクライアントにコピーされるため、元のスクリプト と コピーが実行されることになり、望ましくありません。

スクリプトの実行コンテキストを変更するには、Explorer でスクリプトを選択し、Properties ウィンドウで値を変更します。

推奨事項

• RunContext が Client の単一の Script を ReplicatedStorage に配置します。

• RunContext が Server の単一の Script を ServerScriptService に配置します。

• 可能な限り多くのクライアントおよびサーバーコードに ModuleScripts を使用します。これらのモジュールをクライアントスクリプトとサーバースクリプトから要求します。

  このアプローチにより、クライアントとサーバーの両方でコードの単一のエントリポイントが提供され、整理が簡素化され、問題のあるモジュールを隔離または無効にするのが容易になります。各 ModuleScript に start() 関数を追加して、コードの実行を開始する前にすべてのモジュールをロードできるようにします：

  サンプルサーバースクリプト

  --!strict
  local ServerScriptService = game:GetService("ServerScriptService")
  local SampleModule = require(ServerScriptService.SampleModule)
  local AnotherSampleModule = require(ServerScriptService.AnotherSampleModule)
  SampleModule.start()
  AnotherSampleModule.start()

  サンプルモジュール

  --!strict
  local CollectionService = game:GetService("CollectionService")
  
  local NPC_TAG = "npc"
  
  local SampleModule = {}
  
  local function setUpNpc(npc: Instance)
      -- 各NPCを初期化
  end
  
  local function cleanUpNpc(npc: Instance)
      -- イベントが発火したときに実行
  end
  
  function SampleModule.start() -- 関数をテーブルに追加
      -- タグに基づくセットアップの例ループ
      for _, npc in CollectionService:GetTagged(NPC_TAG) do
          setUpNpc(npc)
      end
  
      -- イベントが発火したときに関数を実行
      CollectionService:GetInstanceAddedSignal(NPC_TAG):Connect(setUpNpc)
      CollectionService:GetInstanceRemovedSignal(NPC_TAG):Connect(cleanUpNpc)
  end
  
  return SampleModule

• コードを共有するには、ReplicatedStorage に ModuleScripts を使用し、クライアントスクリプトとサーバースクリプトの両方でそれらを要求します。

• ゲームに必要な場合は、ReplicatedFirst に同じパターンを繰り返し、単一のクライアントスクリプトと最小限の ModuleScripts を使用してローディングスクリーンを実装します。ReplicatedFirst について詳しくは、Replication orderを参照してください。

• LocalScripts は控えめに使用します。使用する必要がある場合は、StarterCharacterScripts、StarterPlayerScripts、StarterGui、または StarterPack に配置します。

  これらのコンテナ内のスクリプトは、1つの場所から実行されるのではなく、プレイヤーコンテナにクローンされるため、デバッグが複雑になる可能性があります。クライアントコードに ReplicatedStorage を使用すると、Output ウィンドウで行をクリックして ReplicatedStorage.YourScript（スクリプトの安定した場所）に移動できるのに対し、Players.YourName.PlayerScripts.YourLocalScript（ランタイムでスクリプトがコピーされた一時的な場所）には移動できません。

• Workspace のインスタンスに直接スクリプトを添付することは避けてください。代わりに、インスタンスにタグを付けるを行い、CollectionService を使用してそれらを単一の ModuleScript から操作します。

  重要な例外は、Creator Storeでモデルやパッケージを配布する場合です。その場合、インスタンス階層内にスクリプトを含める必要があるかもしれません。各スクリプトの RunContext を指定して、どのように実行されるかの曖昧さを取り除きます。このプロパティを明示的に設定することで、さまざまな場所からモデルやパッケージが正しく機能する可能性が高くなります。

プロジェクト構造の例

Plant リファレンスプロジェクトは、大規模で複雑なゲームでコードをどのように整理するかを示しています。再利用可能な ModuleScripts として、そのコードの大部分を保存しています。

スクリプトの場所

この画像は、どの Explorer ウィンドウの場所にクライアントスクリプトを含めることができるかを示しています。ReplicatedFirst と ReplicatedStorage には、Scripts が RunContext の Client を持つことができますが、Starter[] コンテナは LocalScripts を使用する必要があります。