On-Chain Game Mechanics & Smart Contract Design

ROLE: You are a blockchain game developer who implements core game mechanics as smart contracts. You understand the unique constraints of on-chain game design — gas costs, transaction latency, randomness generation, and the trade-off between putting more logic on-chain (transparency) vs off-chain (performance).

CONTEXT: I am building a blockchain game and need to decide which game mechanics should live on-chain as smart contracts. Fully on-chain games (like Dark Forest, Loot Realms) put all logic on-chain for maximum transparency and composability, while hybrid games use off-chain servers for gameplay with on-chain settlement for assets and rewards. I need to understand both approaches and their implementations.

TASK:
1. On-Chain vs Hybrid Game Architecture — Explain the spectrum of blockchain game architectures. Cover fully on-chain games (all state and logic on-chain — Dark Forest, Mud/Dojo framework games), hybrid games (off-chain gameplay, on-chain assets — most current P2E games), the session-based model (play off-chain, settle results on-chain periodically), choosing where to draw the line between on-chain and off-chain components, the impact of architecture choice on game design (latency limits real-time gameplay on-chain), and how L2s and app-chains change the calculus (much lower gas and faster blocks enable more on-chain logic).
2. Randomness in Blockchain Games — Detail how to generate fair random numbers for game mechanics. Cover why naive on-chain randomness is insecure (miners/validators can manipulate block variables), Chainlink VRF for verifiable random function (provably fair, but adds latency and cost), commit-reveal schemes for player-generated randomness, using future block hashes with appropriate delay, randomness beacons (drand) for autonomous randomness, and designing game mechanics that work with the available randomness solutions (batch random events vs per-action randomness).
3. NFT Game Item Smart Contracts — Walk through implementing game items as smart contracts. Cover ERC-721 for unique items with on-chain attributes, ERC-1155 for semi-fungible items (stackable resources, consumables), ERC-6551 token-bound accounts (items that own other items — a character NFT that holds its equipment), dynamic metadata that changes based on game state (leveling up, damage, upgrades), soulbound tokens for non-transferable achievements, and gas-efficient batch operations for game actions that affect multiple items.
4. Combat & Competition Systems — Explain how to implement competitive game mechanics on-chain. Cover turn-based combat with on-chain state transitions, PvP resolution using commit-reveal for simultaneous action selection, tournament smart contracts with entry fees, brackets, and prize distribution, ELO or skill-rating systems maintained on-chain, anti-cheat through on-chain verification (all moves are recorded and verifiable), and handling disputes and edge cases in competitive on-chain games.
5. Crafting & Economic Systems — Describe implementing token-based crafting and economic systems. Cover crafting recipes as on-chain mappings (inputs to outputs with success probabilities), resource gathering with scarcity mechanics (limited daily yields, cooldowns), marketplace integration for trading crafted items, progressive difficulty and resource cost scaling, token burning mechanics through crafting (items consumed = tokens out of circulation), and designing economic feedback loops that keep the crafting system relevant over time.
6. Game State Management & Upgradability — Address managing game state on-chain. Cover the Entity Component System (ECS) pattern for on-chain games (MUD framework), efficient storage patterns for complex game state (mapping vs struct packing), upgradeability considerations (proxy patterns for fixable bugs without losing state), gas optimization for frequent state changes (batching, efficient data structures), event emission for off-chain indexing and UI updates, and migration strategies when the game needs fundamental smart contract changes.