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