Rewizja Gemma4 Game Code

Pobierz ZIP

Z zrewidował ten Gist 1781220150. Przejdź do rewizji

Brak zmian

Z zrewidował ten Gist 1777602466. Przejdź do rewizji

1 file changed, 0 insertions, 0 deletions

Gemma4-Game-Commits.md zmieniono nazwę na Gemma4-Game-Code.md

Zmieniono nazwę pliku bez modyfikacji zawartości

Z zrewidował ten Gist 1777602352. Przejdź do rewizji

1 file changed, 0 insertions, 0 deletions

Gemma4-Game-Code.md zmieniono nazwę na Gemma4-Game-Commits.md

Zmieniono nazwę pliku bez modyfikacji zawartości

Z zrewidował ten Gist 1777602298. Przejdź do rewizji

1 file changed, 0 insertions, 0 deletions

Gemma4-Graph-Code.md zmieniono nazwę na Gemma4-Game-Code.md

Zmieniono nazwę pliku bez modyfikacji zawartości

Z zrewidował ten Gist 1777599571. Przejdź do rewizji

1 file changed, 1 insertion, 1 deletion

Gemma4-Graph-Code.md

			@@ -138,7 +138,7 @@ Because these workflows use Locks and Strong Consistency, they are signi
138	138		\| Feature \| World Boss (Delta-Sync) \| Trade/Auction (Strong Consistency) \|
139	139		\| :--- \| :--- \| :--- \|
140	140		\| Priority \| Throughput & Low Latency \| Accuracy & Integrity \|
141		-	\| Core Logic \| `HP -= Delta` \| `Lock` $\rightarrow$ `Reserve` $\rightarrow$ `Commit` \|
	141	+	\| Core Logic \| `HP -= Delta` \| `Lock` > `Reserve` >`Commit` \|
142	142		\| Conflict Handling\| Commutative (Order doesn't matter) \| Sequential (Order is everything) \|
143	143		\| Error Recovery \| Eventual Correction (Saga) \| Atomic Rollback (Undo) \|
144	144		\| Latency \| Extremely Low (Buffered) \| Moderate (Lock-wait) \|

Z zrewidował ten Gist 1777599490. Przejdź do rewizji

1 file changed, 145 insertions

Gemma4-Graph-Code.md(stworzono plik)

		@@ -0,0 +1,145 @@
1	+	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.
2	+
3	+	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.
4	+
5	+	Here is how the DSL handles absolute consistency for P2P trades and Auction Houses.
6	+
7	+	---
8	+
9	+	### 1. The P2P Trade: The "Prepare-Commit" Pattern
10	+	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.
11	+
12	+	To prevent this, the DSL uses a Two-Phase Commit (2PC) logic wrapped in a Saga.
13	+
14	+	```python
15	+	# ==============================================================================
16	+	# SCENARIO: Cross-Shard Player-to-Player Trade
17	+	# STRATEGY: Two-Phase Commit (Reserve -> Commit) + Compensation
18	+	# ==============================================================================
19	+
20	+	Module CrossShardTrade {
21	+	# 1. The Setup: Lock both players to prevent them from trading with others
22	+	# We lock by ID in a fixed order (e.g., lower ID first) to avoid Deadlocks
23	+	Lock (SortedIds($player_a, $player_b)) {
24	+
25	+	# PHASE 1: PREPARE (The "Reservation" Phase)
26	+	# We don't move the items yet; we just "freeze" them.
27	+	Trade.ReserveItem($player_a, $item_id) -> ReserveA.Success
28	+	Trade.ReserveCurrency($player_b, $price) -> ReserveB.Success
29	+
30	+	# Check if both reservations succeeded
31	+	[ReserveA.Success, ReserveB.Success] J-> Trade.Commit
32	+
33	+	# If either fails (e.g., Player B spent their money), trigger the Undo
34	+	[ReserveA.Fail, ReserveB.Fail] -> Trade.Abort
35	+	}
36	+
37	+	# PHASE 2: COMMIT (The "Atomic" Phase)
38	+	Trade.Commit /execute {
39	+	# These two operations are wrapped in a single distributed transaction
40	+	# If one fails here, the system triggers a critical recovery saga
41	+	Saga.AtomicTransfer {
42	+	RemoveItem($player_a, $item_id),
43	+	AddItem($player_b, $item_id),
44	+	RemoveCurrency($player_b, $price),
45	+	AddCurrency($player_a, $price)
46	+	}
47	+	-> Trade.Complete
48	+	}
49	+
50	+	# THE UNDO: ABORT (Compensation)
51	+	Trade.Abort /execute {
52	+	# Unfreeze the items/currency
53	+	Saga.UndoReservation($player_a, $item_id),
54	+	Saga.UndoReservation($player_b, $price)
55	+	-> Trade.Failed
56	+	}
57	+	}
58	+	```
59	+
60	+	---
61	+
62	+	### 2. The Global Auction House: The "Escrow" Pattern
63	+	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).
64	+
65	+	Instead of moving money directly from Buyer to Seller, the system uses a Vault as the source of truth.
66	+
67	+	```python
68	+	# ==============================================================================
69	+	# SCENARIO: Global Auction House
70	+	# STRATEGY: Escrow Vault + Atomic Swap
71	+	# ==============================================================================
72	+
73	+	Module AuctionHouse {
74	+	# 1. Listing the Item
75	+	# The item is REMOVED from the player and placed in the VAULT.
76	+	# This prevents the player from trading the item while it's for sale.
77	+	Auction.ListItem /execute {
78	+	Lock ($seller_id) {
79	+	EXT:Vault.DepositItem { item: $item_id, owner: $seller_id }
80	+	}
81	+	}
82	+
83	+	# 2. Placing a Bid (The Atomic Swap)
84	+	# We must ensure the previous high bidder is refunded instantly
85	+	# and the new bidder's funds are locked.
86	+	Auction.PlaceBid /execute {
87	+	Lock ($item_id) { # Lock the item to prevent double-bidding
88	+	# A. Reserve new bid funds
89	+	Vault.ReserveFunds($bidder_id, $new_price) -> Bid.Reserve
90	+
91	+	# B. Refund previous bidder
92	+	if ($previous_bidder) {
93	+	Vault.ReleaseFunds($previous_bidder, $old_price)
94	+	}
95	+
96	+	# C. Update the high bidder state
97	+	GlobalAuctionState.Update {
98	+	high_bidder: $bidder_id,
99	+	current_price: $new_price
100	+	}
101	+	}
102	+	}
103	+
104	+	# 3. Closing the Auction (The Settlement)
105	+	Auction.Settle /execute {
106	+	Lock ($item_id) {
107	+	# Atomic transfer from Vault -> Buyer and Funds -> Seller
108	+	Saga.AtomicSettle {
109	+	Vault.TransferItem($buyer_id),
110	+	Vault.TransferFunds($seller_id)
111	+	}
112	+	}
113	+	}
114	+	}
115	+	```
116	+
117	+	---
118	+
119	+	### 3. Solving the "Distributed Nightmare" Problems
120	+
121	+	#### A. Deadlock Avoidance (The "Dining Philosophers" Problem)
122	+	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.
123	+	* The DSL Solution: `SortedIds($player_a, $player_b)`.
124	+	* 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.
125	+
126	+	#### B. The "Atomic" Guarantee (The Vault)
127	+	To avoid "Item Duplication" (the most feared bug in game dev), the DSL relies on Idempotent Transactions.
128	+	* Every single move of an item is assigned a Unique Transaction ID (UUID).
129	+	* 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.
130	+
131	+	#### C. Performance vs. Consistency
132	+	Because these workflows use Locks and Strong Consistency, they are significantly slower than the World Boss's Delta-Sync.
133	+	* The DSL Strategy: The engine routes these to a High-Consistency Partition.
134	+	* 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.
135	+
136	+	### Summary: Delta-Sync vs. Strong Consistency
137	+
138	+	\| Feature \| World Boss (Delta-Sync) \| Trade/Auction (Strong Consistency) \|
139	+	\| :--- \| :--- \| :--- \|
140	+	\| Priority \| Throughput & Low Latency \| Accuracy & Integrity \|
141	+	\| Core Logic \| `HP -= Delta` \| `Lock` $\rightarrow$ `Reserve` $\rightarrow$ `Commit` \|
142	+	\| Conflict Handling\| Commutative (Order doesn't matter) \| Sequential (Order is everything) \|
143	+	\| Error Recovery \| Eventual Correction (Saga) \| Atomic Rollback (Undo) \|
144	+	\| Latency \| Extremely Low (Buffered) \| Moderate (Lock-wait) \|
145	+	\| Risk \| Small inaccuracies (Acceptable) \| Item Duplication (Catastrophic) \|

Nowsze Starsze