What's New In 1.2.3

確定的コマンドAPI

これは大きな変化です。低頻度のプレイヤーやゲームの入力を入力構造体にエンコードする必要はなくなりました。明示的なコマンドを作成しましょう。

public class EquipInventoryItem : DeterministicCommand {
    public Int32 ItemId;

    public override void Serialize(BitStream stream) {
        stream.Serialize(ref ItemId);
    }
}

var equipCommand = new DeterministicCommand { ItemId = 10 };
QuantumRunner.Default.Game.SendCommand(equipCommand);

コマンドの詳細をご覧ください。

NavMeshエージェントコールバック

navmeshの使用とそのパス検索はゲームに依存しませんが、エージェントのステアリングとエージェントの回避は作成しているゲーム固有な場合があります。Quantum NavMeshAgentの更新中、独自のステアリングおよび/または回避ロジックを挿入したい開発者に協力し、その上、2つの新しいコールバックを導入することで、パスファインディングと物理の幅広いフェーズを利用できるようにしています：

OnNavMeshUpdateSteering と OnNavMeshUpdateAvoidance

任意のシステムにこれらのコールバックを実装して、内部のステアリングと回避を上書きします。

public void OnNavMeshUpdateSteering(Frame f, NavMeshAgent* agent, Entity* entity, NavMeshAgentSteeringData* data) {
    data->IgnoreInternalSteering = true;
    transform->Rotation += 90 * FP.Deg2Rad * f.DeltaTime;
}

public void OnNavMeshUpdateAvoidance(Frame f, NavMeshAgent* agentA, Entity* entityA, NavMeshAgent* agentB, Entity* entityB, NavMeshAgentAvoidanceData* data) {
    data->IgnoreInternalAvoidance = true;
    // ..
}

詳細はこちら： Navigation System - NavMesh Callbacks

Navmeshの今後の変更

Unity NavMeshの動的障害物に似たシステムを追加して、実行中にNavMesh三角形を有効または非有効にできるようにします。これは1.2.4で既に確認されています。

また、パスの品質だけでなく、エージェントの移動と回避の品質にも改善の余地があることに気付きました。

DSL：プリミティブ配列への対応

DSLでプリミティブ配列を定義できます：

component Foo {
    array<Int32>[26] Parameters;
}

適切な対応を追加することができたので、もう次のように保存されることは ありません：

public unsafe partial struct Foo {
    private Int32 Parameters0;
    private Int32 Parameters1;
    private Int32 Parameters2;
    private Int32 Parameters3;
    private Int32 Parameters4;
    private Int32 Parameters5;
    //...
    public Int32 ParametersSize {
        get {
          return 26;
        }
    }

次のように表示され、通常の配列のように使用できます：

public unsafe partial struct Foo {
    public fixed Int32 Parameters[26];
    public Int32 ParametersSize {
        get {
          return 26;
        }
    }

コードの移行方法については、こちらをご覧ください： Migration Notes - DSL: Changed Primitive Type Array Generation (Breaking Change)

ECS：新しいエンティティライフサイクル

Quantumエンティティに合理的な量の状態を導入して、それらの状態をより簡単に、またはより明確に操作できるようにしました。Entity.IsActiveプロパティは使用するべきではありません。代わりに Entity.Flagsで次を確認します：

[Flags]
public enum EntityFlags : int {
    Active = 1 << 0,
    DestroyPending = 1 << 1,
    Culled = 1 << 2,
    NotCullable = 1 << 3
}

エンティティがDestroyEntity()またはDestroyEntityType()の呼び出しを介してフレームの最後に破棄されるように計画すると、 DestroyPendingフラグが設定されます。

GetAllEntityType()および GetAllComponentType()メソッドは、デフォルトで、破棄する予定のエンティティを返さなくなりました。コードがすべてのエンティティを返すという古い動作に依存している場合、DSLで#pragma legacy_entity_active_semantics 1を設定できます。

予測カリング

EntityFlags.Culledの意味を疑問に思うかもしれません。これは、クライアントの純粋なパフォーマンス最適化です。ゲームシーンの一部のみがプレイヤーに表示される場合に使用します。たとえば次のような2Dゲームです：

各プレイヤーが自分のアバター周辺の限られたエリアしか見れない場合。

rampageRの予測カリングを有効にすると、ビュー範囲外のすべてのエンティティは予測に入らず、検証されたフレーム中にのみ更新されます。いくつかの注意事項がありますが、一般的には設定が非常に簡単で、安全に使用できます。

詳細については、こちらの記事をお読みください： Prediction Culling

Photon Unity Networking 1.93

アップグレードした理由

RuntimePlayerの新しいサイズ制限と新しいDeterministic Commands APIに対応するため

Asset StoreからPUN Classicを使用できますか？

はい。AssetStoreの最新バージョンでQuantumパッケージのPUNを更新できます。
- 余剰のNewtonsoft.Json.dllを削除します。
- 「hk」リージョンを手動でCloudRegionCode と CloudRegionFlagに追加します。
- 注：手動で PhotonNetwork.versionPUNを変更しない限り、異なるPUNバージョンはお互いをオンラインで検出しません。
- Switchでゲームを実行する場合、新しい Photon3Unity3D.dll (4.1.2.9)が必要です。

** PUN2にアップグレードしない理由**

私たちの計画は、PUNをQuantumから完全に削除し、Photon Realtime API で直接構築することです。この変更は1.3で導入される予定です。たとえば、現在PUNをマッチメイキングに統合している場合、もちろんそれは対応されます。

入力帯域幅の改善

帯域幅は私達にとっても、エンドユーザーにとっても負荷がかかります。リアルタイムアプリのQuantumは、各プレイヤーの入力を非常に高い頻度で送信します。入力構造は既に小さく、開発者はそれをさらに小さくするために最善を尽くしていますが、累積帯域幅は見落すべきではありせん。どのような改善でも行うべきです。

何を行ったか

ヘッダー情報を削除して、サーバーからクライアントに入力を送信するために使用される直列化を改善しました。また、ゲーム状態シリアライザーが使用するのと同じビットパッキング直列化に切り替えました。

固定入力サイズを有効にするオプションが追加されました。これにより、サーバーからクライアントに入力を送信するときに、Quantumが入力データのサイズをバイトストリームに書き込むのを防ぎます： DeterministicInput.FixedSizeInput

QuantumRunner.ShutdownAll

新しいシャットダウン方法により、Quantumを任意の実行ポイントから簡単に停止できます。

QuantumRunner.ShutdownAll(bool immediate = false)

immediateがtrueの場合、すべてのランナーが破棄され、その後Quantumのゲームとセッションがすぐに破棄されます。Quantumイベントまたはコールバック中などに、シミュレーションの「内部」からこれを呼び出すと、エラーと例外が発生します。Unityのメイントレッドと更新ループからこれを呼び出すのは安全です。

immediateがfalseの場合、すべてのランナーにフラグが設定され、次のセッションの更新後にシャットダウンが実行されます（QuantumRunner.Update()を参照）。これは、どこからでもいつでも呼び出すことができます。

ランナーがシャットダウンすると、以下が起こります:

[QuantumRunner] ランナーGameObjectが破棄されます
[QuantumRunner] QuantumRunner.OnDisable()がトリガーされます
[QuantumRunner] セッションが破棄されます
    [DeterministicSession] スレッド化されている場合：スレッドは結合されて破棄されます
    [DeterministicSession] QuantumGame.OnDestroy()が呼び出されます
        [QuantumGame] OnGameDestroyedコールバックが呼び出されます
            [EntityPrefabViewUpdater] エンティティGameObjectsを破壊します  
        [QuantumGame] コールバックが破棄されます
    [DeterministicSession] シミュレーターが破壊されます
    [DeterministicSession] DeterministicNetwork.Destroy()が呼び出されます
        [DeterministicNetwork] QuantumNetworkCommunicator.OnDestroy() が呼び出されます
    [DeterministicSession] FrameContextが破棄されます
    [DeterministicSession] QuantumRunner.Dispose()が呼び出されます

レベルのアンロードなど、Quantumゲームの破壊に対応したい場合は、 OnGameDestroyedコールバックにフックします。

確定的コマンドAPI
NavMeshエージェントコールバック
DSL：プリミティブ配列への対応
ECS：新しいエンティティライフサイクル
予測カリング
Photon Unity Networking 1.93
入力帯域幅の改善
QuantumRunner.ShutdownAll