J'aime 0
Fork 0

Dernière activité 1781220150

Révision 2cb5e9bc0e648f5a44d13d5795dbcfbda3af6e25

Gemma4-Graph-Code.md Brut

When you move from a World Boss (where "close enough" is fine) to an Economy (where a single duplicate item can destroy the game), you must switch from Eventual Consistency to Strong Consistency.

In distributed systems, this is the "hard mode" of engineering. To handle this, the DSL moves away from the Delta-Sync model and implements Two-Phase Commit (2PC) and Distributed Locking with Deadlock Avoidance.

Here is how the DSL handles absolute consistency for P2P trades and Auction Houses.

1. The P2P Trade: The "Prepare-Commit" Pattern

A cross-shard trade is dangerous because if the server crashes after taking the item from Player A but before giving it to Player B, the item vanishes.

To prevent this, the DSL uses a Two-Phase Commit (2PC) logic wrapped in a Saga.

# ==============================================================================
# SCENARIO: Cross-Shard Player-to-Player Trade
# STRATEGY: Two-Phase Commit (Reserve -> Commit) + Compensation
# ==============================================================================

Module CrossShardTrade {
    # 1. The Setup: Lock both players to prevent them from trading with others
    # We lock by ID in a fixed order (e.g., lower ID first) to avoid Deadlocks
    Lock (SortedIds($player_a, $player_b)) {
        
        # PHASE 1: PREPARE (The "Reservation" Phase)
        # We don't move the items yet; we just "freeze" them.
        Trade.ReserveItem($player_a, $item_id) -> ReserveA.Success
        Trade.ReserveCurrency($player_b, $price) -> ReserveB.Success

        # Check if both reservations succeeded
        [ReserveA.Success, ReserveB.Success] J-> Trade.Commit
        
        # If either fails (e.g., Player B spent their money), trigger the Undo
        [ReserveA.Fail, ReserveB.Fail] -> Trade.Abort
    }

    # PHASE 2: COMMIT (The "Atomic" Phase)
    Trade.Commit /execute {
        # These two operations are wrapped in a single distributed transaction
        # If one fails here, the system triggers a critical recovery saga
        Saga.AtomicTransfer {
            RemoveItem($player_a, $item_id),
            AddItem($player_b, $item_id),
            RemoveCurrency($player_b, $price),
            AddCurrency($player_a, $price)
        }
        -> Trade.Complete
    }

    # THE UNDO: ABORT (Compensation)
    Trade.Abort /execute {
        # Unfreeze the items/currency
        Saga.UndoReservation($player_a, $item_id),
        Saga.UndoReservation($player_b, $price)
        -> Trade.Failed
    }
}

2. The Global Auction House: The "Escrow" Pattern

An Auction House is even more complex because it's an Asynchronous Trade (Seller is not present). To handle this, the DSL implements an Escrow (Third-Party Vault).

Instead of moving money directly from Buyer to Seller, the system uses a Vault as the source of truth.

# ==============================================================================
# SCENARIO: Global Auction House
# STRATEGY: Escrow Vault + Atomic Swap
# ==============================================================================

Module AuctionHouse {
    # 1. Listing the Item
    # The item is REMOVED from the player and placed in the VAULT.
    # This prevents the player from trading the item while it's for sale.
    Auction.ListItem /execute {
        Lock ($seller_id) {
            EXT:Vault.DepositItem { item: $item_id, owner: $seller_id }
        }
    }

    # 2. Placing a Bid (The Atomic Swap)
    # We must ensure the previous high bidder is refunded instantly
    # and the new bidder's funds are locked.
    Auction.PlaceBid /execute {
        Lock ($item_id) { # Lock the item to prevent double-bidding
            # A. Reserve new bid funds
            Vault.ReserveFunds($bidder_id, $new_price) -> Bid.Reserve
            
            # B. Refund previous bidder
            if ($previous_bidder) {
                Vault.ReleaseFunds($previous_bidder, $old_price)
            }
            
            # C. Update the high bidder state
            GlobalAuctionState.Update { 
                high_bidder: $bidder_id, 
                current_price: $new_price 
            }
        }
    }

    # 3. Closing the Auction (The Settlement)
    Auction.Settle /execute {
        Lock ($item_id) {
            # Atomic transfer from Vault -> Buyer and Funds -> Seller
            Saga.AtomicSettle {
                Vault.TransferItem($buyer_id),
                Vault.TransferFunds($seller_id)
            }
        }
    }
}

3. Solving the "Distributed Nightmare" Problems

A. Deadlock Avoidance (The "Dining Philosophers" Problem)

In the P2P trade, if Player A locks Player A and waits for Player B, while Player B locks Player B and waits for Player A, the system freezes.

  • The DSL Solution: SortedIds($player_a, $player_b).
  • By always locking the IDs in numerical order (e.g., always lock ID 10 before ID 50), the system ensures that circular dependencies are impossible.

B. The "Atomic" Guarantee (The Vault)

To avoid "Item Duplication" (the most feared bug in game dev), the DSL relies on Idempotent Transactions.

  • Every single move of an item is assigned a Unique Transaction ID (UUID).
  • If the server crashes and restarts the Saga.AtomicTransfer, the Vault checks the UUID. If it sees the item was already moved, it ignores the second request rather than moving the item again.

C. Performance vs. Consistency

Because these workflows use Locks and Strong Consistency, they are significantly slower than the World Boss's Delta-Sync.

  • The DSL Strategy: The engine routes these to a High-Consistency Partition.
  • While the "Combat Engine" uses fast, eventual consistency, the "Trade Engine" uses a dedicated, highly-consistent database (like CockroachDB or FoundationDB) that supports distributed ACID transactions.

Summary: Delta-Sync vs. Strong Consistency

Feature World Boss (Delta-Sync) Trade/Auction (Strong Consistency)
Priority Throughput & Low Latency Accuracy & Integrity
Core Logic HP -= Delta Lock $\rightarrow$ Reserve $\rightarrow$ Commit
Conflict Handling Commutative (Order doesn't matter) Sequential (Order is everything)
Error Recovery Eventual Correction (Saga) Atomic Rollback (Undo)
Latency Extremely Low (Buffered) Moderate (Lock-wait)
Risk Small inaccuracies (Acceptable) Item Duplication (Catastrophic)

Propulsé par Opengist ⋅ Load: 41ms⋅

Français