パフォーマンスのための設計

*このコンテンツは、ベータ版のAI（人工知能）を使用して翻訳されており、エラーが含まれている可能性があります。このページを英語で表示するには、 こちら をクリックしてください。

パフォーマンスを設計するということは、経験を構築するときに、数少ないベストプラクティスを追うことを意味します as you build あなたの経験。開発プロセスの後でパフォーマンスの問題を見つけて修正するのと比べて、開発の初期段階でパフォーマンスを設計すると、多くの時間と労力を節約できます。

低エンドデバイス

低端デバイス、特にモバイルデバイスは、メモリの制限が厳しく、メモリが不足しているためクラッシュが発生しやすい:

  • 低エンドデバイスをサポートしたい場合は、少なくとも 1つの「ベースライン」デバイスを選択し、開発プロセス全体でその経験をテストし、フレームレートとメモリ使用量に注意を払います。エクスペリエンスで問題領域を見つけたときは、それらの領域を使用してデバイスの制限を特定します。

    たとえば、 レンダー ( ShiftF2 ) と 概要 ( ShiftF2 ) デバッグ統計が有効になっているエクスペリエンスをテストすることができます。フレームレートが特に混乱した領域で低下し始めると、 描画 (シーン) 数を調べて、ベースラインデバイスでバージョンアップエクスペリエンスがうまく動作するために、1,000ドローコールと 1,000,000トライアングルを 1,000以下に保つ必要があることを確認できます。

    または、開発者コンソール (）を調べて、メモリ使用が少し高いことに注意して、ストリーミング を有効にしない限り。デバイスの制限を明確に理解することで、エクスペリエンスを構築し続けるにつれて、それらの下に留まるのを助けることができます。

  • Roblox Studio のデバイスエミュレータは、アスペクト比とコントロールをチェックするのに便利ですが、メモリ使用量には正確ではありません; Studio でエクスペリエンスをテストすると、サーバーとクライアントが実行されるので、メモリ使用量が大幅に高くなります。

より一般的に、さまざまなデバイスでのテストは、異なるグラフィック品質レベルでビジュアルとパフォーマンスの期待に一致するかどうかをチェックするのに役立ちます。低レベルモバイルデバイス向けにエクスペリエンスを最適化する方法のより詳細な例については、実世界のビルドとスクリプト最適化 を参照してください。

ストリーミングとテレポート

  • インスタンスストリーミング で Roblox は 3D コンテンツを動的に読み込み、削除し、ほとんどの場所、特に大きなものに最適なオプションです。ストリーミングは、接続時間を改善し、メモリフットプリントを減少し、フレームレートを増加させます。詳しくは、パフォーマンスの向上を参照してください。

  • 大きな場所をより管理可能なものに分割し、テレポートを使用してプレイヤーをそれらの間で移動させます。このアプローチは、 最初の 接続時間を削減できますが、プレイヤーが場所から場所へテレポートすると、追加の接続時間が課せられます。メモリ使用のメリットは、場所のサイズとストリーミングを有効にしたかどうかによって異なります。

    パフォーマンスの考慮を無視しても、複数の場所を持つことで、特にエクスペリエンスに新しいコンテンツを定期的に追加したり、より大きなチームの一部であったりする場合、開発プロセスが簡素化されることがあります。

素材と複製

  • 組み込み素材は、カスタムテクスチャよりもはるかに少ないメモリを使用しますが、あなたの芸術的ビジョンに一致しない可能性があります。可能な限り素材を使用して、エクスペリエンスの中心になるテクスチャのメモリ予算を節約します。

  • アセットを作成すると、パッケージに変換します。パッケージをワークフローの一部にすると、異なるID の複製アセットによるパフォーマンスの低下の問題を避けることができます。

  • メッシュとテクスチャを追加するときは、複製をインポートするのではなく、使用して再利用します。サイズ変更、回転、オーバーラップで、非常に少ない ドローコール が必要な、豊富で多様な環境を作成できます。詳しくは、複製のテクスチャを削除する を参照してください。

透明性

  • 透明度が 0（可視）と 1（非可視）以外の値を避けます。部分透明を使用するときは、高透明度のオーバードロップを避けるように注意してください。

スクリプト化

  • 可能な限り、フレームごとの計算ではなくイベント駆動型コードを書きます。60FPS では、各フレームの総予算は 16.67 ミリ秒 (ms) です。見た目上は小さな毎フレームの計算でも、その予算の大部分を使用できます。

  • 長時間実行中のコードを管理可能なチャンクに分割する方法を見つけるコードの 1 部が実行に 100ms かかり、毎フレーム実行すると、エクスペリエンスは 10FPS でしか動作しません。経験でコードを 1 秒に 1 回だけ実行することを決めた場合、60 FPS で実行されている経験では、16.67 ms 後に 59 のフレームが到達します...そして 100ms 後に 1つ、これはジャーリングスタッターを引き起こします。

    代わりに、コードをどのように分解できるかを調査します。たぶん、フレームごとに 5ms の作業を実行し、task.wait() を使用し、60 FPS を維持しながら 20 フレームごとに完了した計算を行うことができます。マルチスレッド、時には並列 Luauと呼ばれることもありますが、助けになることもあります。

  • メソッドを使用して、次回のイベント発動時に不必要に呼び出される機能を停止する

  • 値が必要なときに同じメソッドを呼び出さないでください。一度メソッドを呼び出し、値を保存し、必要に応じて後で上書きします。

  • すべてを ReplicatedStorage に保存しないでください。クライアントは、このコンテナにあるすべてをロードします。代わりに、ServerStorage を使用して、クライアントがアクセスする必要のないものにアクセスします。