Skip to main content

Core Technology

Our main framework used:​

  • Game App: Unity, Fmod (C#), online using Mirror (websocket)
  • Website: NextJs (typescripts), EtherJs
  • API: NodeJs (typescripts) / python, EtherJs
  • Server: Amazon S3, DB MongoDB.
  • Smart Contract: Solidity, HardHat

Blockchain - Server - Client challenge:​

  • Safeguard the integrity and transparency of value-critical processes, such as breeding, by conducting them on the blockchain.
  • Mitigate the risk of cheating through man-in-the-middle data injection attacks.
  • Empower players with the authority to manage alterations and upgrades to their NFTs.
  • Facilitate intricate gameplay actions without imposing unnecessary restrictions.

alt text

Blockchain consideration:​

Previously, games operated by storing data and executing actions in two distinct locations: the client, which held authority over player input, and the server, which maintained control over the recorded game-state. Kugle innovates by introducing the blockchain as a third integral component in the system. In crypto-based games, data replication now extends to two additional parties.

The blockchain imposes certain limitations that necessitate careful consideration:

  • Smart contracts lack the capability to "read" data directly from an API. The blockchain cannot initiate calls to external endpoints; it can only access stateful information from function parameters or saved state from prior function executions.

  • Each function call on the blockchain is deterministic within the block in which it is processed. Validators can re-run functions, and the results will consistently match the officially recorded result in the block. This deterministic nature complicates the generation of random numbers.

  • Any RPC (Remote Procedure Call) that modifies data on the blockchain occurs asynchronously. Placing a transaction in the queue does not guarantee immediate processing or success. Some transactions may take minutes or even hours to resolve.

  • The blockchain communicates externally by emitting subscriptable events.

  • The blockchain generates new blocks approximately every 2 seconds, resulting in frequent Uncle Blocks. The likelihood of a transaction being orphaned decreases with each additional confirmation added on top of it. However, there exists a grey area where a processed transaction might still be undone. To address this, we adopt a cautious approach by waiting for a sufficient number of confirmation blocks (typically 20-80 blocks) before acknowledging transaction events.

Our implementation​

Our implementation considers blockchain constraints and data security issues, all while ensuring a seamless user experience. The goal is to keep the player focused on one thing: having fun, with trading as a secondary priority.

  • Our core tokenomics are based on our SmartContract for the gameplay loop: Hatch, Breed, Claim
  • Our game-app is made with Unity, with Fmod for the sound
  • We use a scalable API that create on-the-go multiple game-server on demands
  • Game-server are used for our online game-modes, we use Mirror (websocket), server authoritative.