}}DSLでC#で定義された構造体を使用する場合(コンポーネント内部など)、構造体の定義を手動でインポートする必要があります。サイズの定数に対応していませんので、毎回正確な数値を指定する必要があります。コンポーネントと構造体の比較どのような理由で、またどのような場合に、通常の構造体ではなくコンポーネントを使うべきなのかが重要です(結局、コンポーネントは構造体でもあります)。コンポーネントには生成されたメタデータが含まれており、それを以下の機能を持つ特殊な型に変換します:エンティティに直接取り付けることができます。ゲームステートを横断する際にエンティティをフィルタリングするために使用されます(次の章ではフィルタAPIについて説明します)。コンポーネントは他の構造体と同様に、ポインタまたは値型として、パラメータとしてアクセス、使用、または渡すことができます。動的コレクションQuantumのカスタムアロケータは、ロールバック可能なゲームステートの一部として、転送可能なコレクションを公開しています。コレクションは転送可能な型(すなわちプリミティブ型とDSL定義型)のみをサポートしています。ヒープ上のコレクションのためのスペースを割り当てる。コレクションのメモリを解放/割り当て解除する。ポインタを解決してコレクションにアクセスする。コレクションを解放した後は、必ずdefaultに設定して、コレクションを無効にしなければなりません。これは、ゲームの状態をシリアライズするために必要です。ヌル化を省略すると、不確定な動作や非同期が発生します。複数のコンポーネントが同じコレクションインスタンスを防御できます。動的コレクションは、コンポーネントや構造体の内部に参照として格納されます。あり、さらに重要なのは、不要になったときには解放されるべきです。コレクションがコンポーネントの一部である場合、2つの方法があります。実装し、コレクションの割り当てと解放を行います。(これらの特定のシグナルに関する詳細は、マニュアルのECSセクションにあるコンポーネントのページを参照してください)。[AlocateOnComponentAdded]と[AllocateOnComponentAdded]属性を使って,コンポーネントが追加されたときと削除されたときに,それぞれQuantumに割り当てと解放を任せます.Quantumは、少なくとも値がない限り、プロトタイプからコレクションを事前に割り当てることはありません。コレクションが空の場合は、メモリを手動で割り当てる必要があります。コレクションを2回以上解放しようとすると、エラーが発生し、ヒープが内部的に無効な状態になります。MyListを用いて定義することができます。Enemies;}これらのリストを扱うための基本的なAPIメソッドは以下の通りです。リストに期待されるすべてのAPIメソッドを使用して、反復処理や操作を行うことができます。型のコンポーネントでリストを使用するには、以下のようなシステムを作成することができます。MyDictionaryのように、DSLでディクショナリを宣言することができます。ptr)他のダイナミックコレクションと同様に、使用する前に割り当てを行い、使用後にフレームデータから割り当て解除する必要がありますです。上記のリストに記載されている例を参照してください。MyHashSetのように宣言することができます。ProcessedNodes;}これらのディクショナリを扱うための基本的なAPIメソッドは以下の通りです。ptr)他の動的コレクションと同様に、ハッシュセットを使用する前に割り当てを行い、フレームデータからの割り当てを解除し、ハッシュセットが使用されなくなったら無効にすることが必須です。前述のリストの項で紹介した例をご覧ください。ユニオン、Enum、ビットセットCのような共用体や列挙型も生成できます。以下の例は、相互に排他的なデータ型/値を重ね合わせて共用体にすることでデータメモリを節減する方法を示しています。(どの共用体型が追加されているかを伝えるための)微分器プロパティも含まれます。"すると、このプロパティが適切な値に設定されます。ビットセットは、任意の目的のために固定サイズのメモリブロックを宣言するために使用することができます(例えば、フォグオブウォー、ピクセルパーフェクトなゲームメカニクスのためのグリッドのような構造体など)。Map;}入力Quantumでは、クライアント間でやり取りされるランタイム入力もDSLで宣言されています。この例では、ゲームの入力として単純な動きベクトルとFireボタンを定義しています。Movement;}ボタンのような入力の場合、Quantumは状態変化を安全に計算することができます(これは次の章-システムで取り上げます)。Fire;}ボタンは多くの場合、ネットワークプロトコルのシングルビットのみを使用するため、予測/ロールバックゲームに理想的な型です。入力構造体はティックごとにポーリングされ、サーバーに送信されます(オンラインでプレイする場合)。サーバーは、フルティックセット(全プレイヤーの入力)の入力確認を一括して送信する役割を担っています。このため、この構造体は可能な限り最小限のサイズに抑える必要があります。予測コマンド(該当する章を参照してください)は、Quantumの別の入力パスです。任意のデータとサイズを設定できるため、予測コマンドは入力の特別な型(たとえば「このアイテムを買う」、「どこかにテレポートする」など)に適するよう設定可能です。シグナルシグナルは、デカップリングされたシステム間通信API(パブリッシャー/サブスクライバーAPIの1つの形態)として使用される関数シグネチャです。これらについてはこの章の最後に記載します)。entity);これにより、以下のようなインターフェースが生成されます(どのシステムでも実装可能)。entity);}シグナルはQuantumのDSLでポインタを直接宣言できる唯一の概念です。このため、参照でデータを渡すことによって、それらの具体的な実装で元のデータを直接修正することができます。resources);これによって、コンポーネントポインタ―を渡すことが許可される点に留意してください(エンティティ参照型の代わりに)。イベントイベントは、シミュレーション内での発生事項をレンダリングエンジンに伝えるための精度の高いソリューションです(ゲームステートの一部を変更したり更新したりするために使用してはいけません)。キーワード「event」を使用して、名前とデータを定義します。Volume;}継承はイベントに利用可能です(オプションでいくつかのイベントを抽象化して、直接トリガーされないようにブロックし、具体的なサブクラスのみを許可することもできます)。Power;}入力データがサーバーから確認された場合に特定のイベントの送信のみをおこなう点を保証するには(ロールバックに誘発された、誤った正数を回避)、「同期した」キーワードを使用してください。TriggerSound{}望ましくない重複ディスパッチを避けるため、Quantumはすべてのイベントタイプのハッシュコード関数を自動生成します(イベントデータをソースとして使用します)。特定の条件では、ディベロッパーは(イベントインスタンスを一意にする)キー候補データが何であるかを厳密に制御したい場合があるかもしれません。わずかなロールバックによる位置の変化によって同じイベントの2つのインスタンスが、2つの実際に異なるイベントと誤って解釈されてしまう場合です。これを避けるために、「nothashed」キーワードを使用して、ハッシュ関数でイベントデータの一部を強制的に無視させることができます。キーワードを適用して、これらのイベントをフィルタリングすることができます。Killed;}このイベントがUnity側でディスパッチされると、まず、player_ref変数が、その前のキーワードと一致するかどうかをチェックします。上記の例では、_キラー_がローカルプレイヤーであり、かつ、_キルされた_プレイヤーがリモートプレイヤーである場合にのみ、Unityでイベントが発生することを意味します。これらの条件のいずれかが意味されていない場合、イベントはUnityで抑制されます。キーワードを使用してイベントを修飾することで、イベントをさらにフィルタリングすることができます。とマークされている場合は、クライアントのビルドでのみトリガーされます。キーワードは、サーバープラグインでのみイベントがトリガーされます。注意:__これは、カスタムプラグインを使用してサーバーサイドシミュレーションを実行する場合にのみ該当します。Project)にディスパッチ/確認/キャンセルされる仕組みについては、次の章も参照してください。グローバルDSLでは、グローバルにアクセス可能な変数を定義することができます。グローバルは、どの.qtnファイルでも、globalスコープを使って宣言することができます。MyGlobalValue;}DSL定義のすべてのものと同様に、グローバル変数は状態の一部であり、予測-ロールバック・システムと完全に互換性があります。APIを通じて利用可能になります。これらは、フレームにアクセスできる場所であれば、どこからでもアクセス(読み取り/書き込み)することができます。ECSセクションの_Systems_ドキュメントを参照してください。グローバル変数の代わりに、シングルトン・コンポーネントを使用することもできます。詳細については、マニュアルのECSセクションにある_Components_のページを参照してください。特別な型Quantumにはいくつかの特別な型があり、複雑な概念(エンティティ参照、プレイヤーインデックスなど)を抽象化したり、管理されていないコードによって一般的な間違いから保護したり、あるいはその両方に使用されます。以下の特殊な型は、他のデータ型(コンポーネント内、イベント内、シグナルなど)の内部で使用することができます。ランタイムのプレイヤーインデックスを表します(Int32にキャストされたり、Int32からキャストされたりします)。コンポーネントで定義されている場合、どのプレイヤーが関連するエンティティを制御しているかの保存に使用できます(Quantumのプレイヤーインデックスベースの入力と組み合わせて)。Quantumの各フレーム/ティックデータは別のメモリ領域/ブロックに存在するため(ロールバックをサポートするためにQuantumはいくつかのコピーを保持しています)、フレーム間でのポインタのキャッシュはできません(Unityスクリプトでもゲームステートでも)。エンティティ参照は、エンティティのインデックスとバージョンのプロパティを抽象化します(開発者が誤って古い参照で、破棄または再利用されたエンティティスロット上の非推奨データに誤ってアクセスすることを防ぎます)。(データアセットの章を参照してください)。フレームヒープに格納されています)。転送可能な型(プリミティブおよびDSL定義型)のみをサポートしています。データコレクションを表すための固定サイズの「配列」。通常のC#配列であれば、ヒープ割り当てされたオブジェクト参照(プロパティなどを保持)になりQuantumのメモリ要件に抵触します。このため、特殊な配列型ではポインタベースのシンプルなAPIを生成し、ゲームステートの内部にロールバック可能なデータコレクションを保持しています。アセットについての留意事項アセットはQuantumの特別な機能です。ディベロッパーがデータ駆動型のコンテナ(通常のクラス、継承、多態性メソッドなど)を定義し、インデックス化されたデータベース内で不変のインスタンスとして終了することを可能にします。「asset」キーワードは、(既存の)クラスを、ゲームステートの内部で参照を割り当て可能なデータアセットとして割り当てるために使用されます(機能や制限についてはデータアセットの章を参照してください)。TenNumbers;}利用可能な型DSLで作業をする場合、様々な型を使用できます。パーサーによって事前にインポートされているものもあれば、手動インポートが必要なものもあります。デフォルトQuantumのDSLパーサーにはゲームの状態定義で使用可能な、あらかじめインポートされたクロスプラットフォームの予測型のリストがあります。内部的には同じように動作するQBooleanでラップされます(取得/設定、比較など)。HingeJointNは文字列の合計サイズをバイト数で表したもので、記帳に使用される2バイトを差し引いた値です。QString<64>は最大バイト長が62バイトの文字列に対して64バイト、つまりUTF-16で最大31文字までを使用することになります。手動インポート前のセクションで記載されていない型が必要な場合は、QTNファイルの先頭にある以下の構文を使用して手動でインポートする必要があります。他の名前空間で定義されている型をインポートするには、次の構文を使用します。宣言であらかじめ定義されています。そのため、いくつかの安全対策を追加することが重要です。つに追加することをお勧めします。}}アップグレード中に組み込み構造体のサイズが変更された場合、このAssertがスローされ、DSLの値を更新できるようになります。Inspectorにパラメータを表示するために、いくつかの属性をサポートしています。条件がtrueと評価された場合のみプロパティを表示します。