パフォーマンスのための設計とは、ゲームを作成する際に主に従うべきベストプラクティスのことを指します。開発プロセスの後半でパフォーマンスの問題を見つけて修正するのに比べ、早い段階でパフォーマンスを考慮して設計することで、多くの時間と労力を節約できます。
低スペックデバイス
低スペックデバイス、とりわけモバイルデバイスは、厳しいメモリ制限があり、メモリ不足（OOM）エラーによるクラッシュに対して非常に敏感です：
低スペックデバイスをサポートするには、少なくとも1つの「ベースライン」デバイスを選択し、開発プロセスを通じてその上でゲームをテストすること、フレームレートやメモリ使用量に注意を払うことをお勧めします。ゲーム内の問題領域を見つけた際は、それを利用してデバイスの限界を特定してください。
例えば、Render (ShiftF2) と Summary (ShiftF2) のデバッグ統計を有効にした状態でゲームをテストすることがあります。特に混雑したエリアでフレームレートが低下し始めた場合、Draw (scene) 数値を調査して、ゲームがベースラインデバイス上で順調に動作するためには1,000回の描画コールと1,000,000個の三角形を下回る必要があることを確認できます。
または、Developer Console (F9) をチェックし、ストリーミングを有効にしない限りメモリ使用量がやや高いことに気付くかもしれません。デバイスの限界を明確に理解しておくことで、ゲームの構築を続ける中でその限界を下回るようにできます。
Roblox Studioのデバイスエミュレーターはアスペクト比とコントロールを確認するのに便利ですが、メモリ使用量の正確性には欠けています。Studioでゲームをテストすると、サーバーとクライアントの両方が実行されるため、メモリ使用量は大幅に増加します。
Robloxはデバイスのメモリ全体にアクセスできません。オペレーティングシステムや他のアプリケーションに一定量のメモリが必要です。
一般的に、さまざまなデバイスでのテストが、異なるグラフィック品質レベルでゲームが視覚的およびパフォーマンス的に期待に応えることを確認するのに役立ちます。低スペックのモバイルデバイス向けにゲームを最適化する際の詳細な例については、リアルワールドのビルディングおよびスクリプト最適化を参照してください。
ストリーミングとテレポーテーション
インスタンスストリーミングを使用すると、Robloxは3Dコンテンツを動的にロードおよびアンロードできるため、大きな場所、とりわけ大きな場所にとって優れたオプションです。ストリーミングは参加時間を改善し、メモリ使用量を削減し、フレームレートを向上させます。
例えば、Workspace.EnableSLIMAvatarsを有効にし、ワールドモデルのLevelOfDetailプロパティをSLIMに設定すると、ソーシャルスペースや混雑するイベントを持つ視覚的に豊かな世界を作成でき、幅広いデバイス性能にスケーリングできます。詳細については、SLIMおよびパフォーマンスの向上を参照してください。
大きな場所をより管理しやすいものに分割し、テレポーテーションを使用してプレイヤーをそれらの間で移動させることを検討してください。このアプローチは、初期の参加時間を短縮できますが、プレイヤーが場所から場所へテレポートする際に追加の参加時間をもたらします。メモリ使用量の利点は、場所のサイズやストリーミングを有効にしたかどうかによって変わります。
パフォーマンスを考慮せずとも、複数の場所を持つことで、特に新しいコンテンツを定期的にゲームに追加する場合や大きなチームの一員である場合に、開発プロセスが簡素化されることがあります。
マテリアルと重複
ビルトインマテリアルはカスタムテクスチャよりもはるかに少ないメモリを使用しますが、アーティスティックビジョンと一致しない場合があります。ゲームにとって重要なテクスチャのためにメモリ予算を節約するために、可能な限りマテリアルを使用してください。
アセットを作成する際は、それらをパッケージに変換してください。パッケージをワークフローの一部とすることで、異なるIDを持つ重複したアセットの一般的な問題を避けるのに役立ち、パフォーマンスを損なうことができます。
メッシュやテクスチャを追加する際は、それらを使用したり再利用したりし、重複したコピーをインポートしないようにしてください。サイズ変更、回転、重なりを使用することで、非常に少ない描画コールでリッチで多様な環境を作成できます。詳細については、重複したテクスチャを削除するを参照してください。
透明性
- 0（表示）および1（非表示）以外の透明度を避けてください。部分的な透明度を使用する場合は、特に高透明度オーバードロウを避けるように注意してください。
スクリプト
可能な限り、フレーム毎の計算ではなく、イベント駆動型のコードを書くようにしてください。60 FPSの場合、各フレームの合計予算は16.67ミリ秒（ms）です。見た目は小さく見えるフレーム毎の計算でも、それはその予算のかなりの部分を使用する可能性があります。
長時間実行されるコードを管理可能なチャンクに分ける方法を見つけてください。コードの一部が完了するのに100 msかかり、それを毎フレーム実行すると、ゲームは10 FPSでしか動作できません。60 FPSで動作するゲームでコードを毎秒1回だけ実行することに決めると、59フレームは16.67 ms後に到着し、その後の1フレームは100 ms後に到着し、これが唐突なスタッターを引き起こします。
代わりに、コードを分割する方法を探求してください。おそらく、毎フレーム5 msの作業を行い、task.wait()を利用して20フレームごとに計算を完了することで、60 FPSを維持しながら作業できます。マルチスレッド処理（時にはParallel Luauと呼ばれる）も役立ちます。
RBXScriptConnection:Disconnect()メソッドを使用して、次回イベントが発生する際に関数が不必要に呼び出されないようにしてください。
値が必要なたびに同じメソッドを呼び出さないでください。メソッドを一度呼び出して値を保存し、その後必要に応じて上書きしてください。
すべてをReplicatedStorageに格納しないでください。このコンテナにあるものは、クライアントがすべて読み込むためです。代わりに、クライアントがアクセスする必要のないものにはServerStorageを使用してください。