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