본문으로 건너뛰기

Sui에서의 게이밍

Sui에서의 게이밍은 블록체인 기술을 활용하여 게임 내 경제, 소유권, 상호작용을 강화한다. Dynamic NFTs, Kiosk, soulbound assets, on-chain randomness와 같은 기능을 통해 Sui는 빌더에게 몰입감 있고 투명하며 공정한 게이밍 경험을 만들 수 있는 도구를 제공한다. 플레이어는 사용성을 저해하지 않으면서 진정한 자산 소유권, 탈중앙화 마켓플레이스, 원활한 Web3 통합의 혜택을 누린다.

이 주제에서는 게이밍을 위한 Sui의 핵심 기능, 실제 사용 사례, 빌더를 위한 필수 도구를 살펴본다. RPG, 레이싱 게임, 디지털 카드 게임 중 무엇을 만들든 Sui는 차세대 게이밍 프로젝트를 구동할 Web3 인프라를 제공한다.

Player onboarding​

Sui는 플레이어 계정과 프로필 생성을 간소화하는 데 도움이 되는 다양한 도구를 제공한다.

zkLogin​

많은 플레이어는 single sign-on (SSO) 또는 social login을 사용해 게임 계정을 만든다. [zkLogin], a Sui primitive, (https://www.sui.io/zklogin)은 익숙한 인증 흐름을 통해 블록체인 계정 생성을 가능하게 하여 기존 지갑 설정 과정의 복잡성을 줄인다.

현대의 플레이어는 대체로 선불 비용이 필요 없는 free-to-play (F2P) 게임을 선택한다. Sponsored transactions를 사용하면 사용자 또는 지정된 엔터티가 플레이어에게 필요한 gas fees를 대신 부담할 수 있으므로, 처음에 SUI tokens를 구매할 필요가 없어진다.

Representing in-game objects on-chain​

블록체인 게임은 일반적으로 게임 내 assets를 on-chain objects로 표현한다. 화폐, 아이템, 캐릭터 속성 또는 기타 게임 요소를 관리하든, 이러한 objects를 생성하고 통합하는 방법을 이해하는 것은 블록체인 기반 게임 경험을 구축하는 데 기본이 된다.

On-chain randomness and verification​

Sui는 온체인 랜덤니스를 제공하므로 게임이 중앙화된 운영자를 신뢰하지 않고도 작동할 수 있다.

또한 Sui 네트워크의 모든 transactions는 조회 가능하고 검증 가능하다. Sui는 threshold cryptography와 Distributed Key Generation (DKG)을 활용하며, 이는 각 epoch 시작 시 distributed key의 secret shares를 생성하고 이를 계속 사용해 randomness를 생성한다.

Off-chain computation도 Nautilus 설계를 참고해 on-chain에서 검증할 수 있다.

In-game currencies​

In-game currencies를 사용하면 사용자가 아이템, 업그레이드, 프리미엄 콘텐츠와 같은 게임 기능을 구매할 수 있다. Web2 게임에서는 이러한 화폐가 오직 게임 내에만 존재하며, 그 가치는 개발자가 정한다.

Sui를 사용하면 플레이어는 이제 true ownership of their in-game currency를 가질 수 있다. 이 화폐는 token on the Sui blockchain으로 존재하므로, 플레이어는 그 화폐를 on-chain에 존재하는 다른 무엇과도 사고팔거나 교환할 수 있다고 상상할 수 있다. 게임 생태계를 만든다면 플레이어는 한 게임에서 화폐를 구매하고 동일한 화폐를 사용하는 다른 게임에서 그 화폐를 사용할 수 있다. 가능성은 광범위하지만, 먼저 그 화폐를 만드는 방법을 배워야 한다.

Closed-Loop Tokens​

In-game currencies와 유사하게 Closed-Loop Tokens는 Web3 없이는 불가능한 수준의 참여와 제어를 게임 경험에 통합한다.

예를 들어 게임과 연관된 토큰을 만들어 사용자 기반의 reward loyalty할 수 있다. 또한 특정 capability를 보유한 사람이 토큰에 접근 가능한 addresses를 제어할 수 있게 하는 regulated tokens를 생성할 수도 있으며, 이는 특별 이벤트, 리그, 기타 게임 기능에 대한 gated access를 용이하게 한다.

Game features​

Non-fungible tokens (NFTs)은 게임 내 objects, battle passes, rewards, skins, game cards or keys, loot boxes와 같은 많은 전통적인 게임 기능을 표현할 수 있다.

이러한 NFTs는 일반적으로 dynamic assets 또는 soulbound assets로 분류되는 game assets라고 생각할 수 있다.

Dynamic assets​

Sui에서 object는 key-value pair 데이터 구조로 볼 수 있다. Sui의 smart contract 언어인 Move에서 objects는 struct로 정의된다. 예를 들어 tic-tac-toe 게임의 game board를 생각해 보자:

examples/tic-tac-toe/move/sources/owned.move
public struct Game has key, store {
    id: UID,
    board: vector<u8>,
    turn: u8,
    x: address,
    o: address,
    admin: vector<u8>,
}

모든 object의 첫 번째 key-value pair는 id: address이며, 이는 UID 타입의 고유한 값이다. 모든 object는 서로 다른 address를 가지며, 이 필수 key-value pair가 각 object를 구별하고 고유하게 만들기 때문에 모든 object가 NFT이다.

Creating assets​

Smart contracts에는 objects를 생성하는 함수가 포함된다. 이전 예제를 사용하면, object를 생성하는 함수(new)는 표현된 object(디지털 tic-tac-toe gameboard)에 대해 각 attribute의 값을 제공한다. Sui framework는 이 특정 게임을 고유하게 식별하는 UID를 생성한다.

examples/tic-tac-toe/move/sources/owned.move
public fun new(x: address, o: address, admin: vector<u8>, ctx: &mut TxContext): Game {
    let game = Game {
        id: object::new(ctx),
        board: vector[MARK__, MARK__, MARK__, MARK__, MARK__, MARK__, MARK__, MARK__, MARK__],
        turn: 0,
        x,
        o,
        admin,
    };

    let turn = TurnCap {
        id: object::new(ctx),
        game: object::id(&game),
    };

    transfer::transfer(turn, x);
    game
}

이는 on-chain action, 즉 transaction이다. 이 경우 transaction은 체인에 object를 생성해 달라는 요청이다. 함수에 필요한 데이터를 제공하고 네트워크 validators의 계산 노력에 대한 gas fee를 지불한다. 그 결과 address(id)에 존재하는 새로운 NFT가 Sui 블록체인에 생성된다.

Updating assets​

Sui에서는 NFT를 정의하는 smart contract가 허용하는 경우 별도의 transaction을 사용해 NFT asset을 업데이트할 수 있다. 생성과 마찬가지로 관련 update 함수에 데이터를 제공하고 pay the gas fee를 지불하면 smart contract가 올바른 address의 object를 새로운 정보로 업데이트한다.

tic-tac-toe 예제를 사용하면, 사용 가능한 칸에 x를 놓기 위해 smart contract에 gameboard object를 업데이트하라고 지시할 수 있다. 대부분의 업데이트에 필요한 계산 노력은 원래 object를 생성하는 데 필요한 노력보다 적기 때문에, 결과로 발생하는 gas fees도 일반적으로 더 적다.

Composing assets​

Sui에서는 한 object 안에 다른 object를 포함할 수 있다(dynamic fields). 예를 들어 Parent라는 이름의 object가 Child 타입의 objects를 포함할 수 있다. Smart contract는 parent에서 child objects를 추가하고 제거하는 데 필요한 함수를 제공할 수 있다.

examples/move/dynamic_fields/sources/example.move
public struct Parent has key {
    id: UID,
}
examples/move/dynamic_fields/sources/example.move
public struct Child has key, store {
    id: UID,
    count: u64,
}

Child objects를 parent에 추가하는 함수는 다음과 비슷할 수 있다. 이 경우 ofield는 sui::dynamic_object_field package의 alias이다.

examples/move/dynamic_fields/sources/example.move
public fun add_child(parent: &mut Parent, child: Child) {
    ofield::add(&mut parent.id, b"child", child);
}

Dynamic fields는 많은 사용 사례에 적용할 수 있다. 예를 들어 TicketBooth라는 object는 ConcertTicket 타입의 objects를 포함할 수 있다. Car 타입의 object는 Engine, Tires, Body, Wheel과 같은 필요한 모든 objects가 존재할 때까지 false인 is_functioning 필드를 가질 수 있으며, 이 시점에 is_functioning 필드를 자동으로 true로 업데이트할 수 있다.

Composability는 Sui의 매우 중요한 기능이다. 이는 Sui에서 아이디어를 개발할 때 많은 선택지를 제공할 뿐 아니라, 기존 프로젝트 위에 구축하고 프로젝트 안에서 third-party assets를 사용할 수 있게 한다. 이는 "특정 NFT를 소유한 사용자만 할인을 받을 수 있다"에서부터 두 개의 서로 다른 프로젝트 간 완전한 협업까지, 그리고 그 사이의 모든 것을 smart contract 수준에서 가능하게 할 수 있다.

Transfer to object​

Sui는 transfer to object feature를 통해 더 많은 사용 사례를 가능하게 하며, 이 기능은 owned object를 다른 object(shared 또는 owned)로 보낼 수 있게 한다. 이 경우 전송된 object는 parent object가 소유한 것으로 나타난다. 위 예제들에서는 objects가 다른 objects 안에 wrapping되며, parent object를 검사할 때 parent object의 metadata에서 이를 확인할 수 있다.

Object가 다른 object로 전송되면 parent object의 metadata는 그대로 유지되지만, 그 id는 새로운 object를 갖는다. 이 기능은 Wallet object를 사용해 다른 objects를 예치하는 on-chain wallets와 같은 사용 사례를 가능하게 할 수 있다. 이를 transfer to object와 결합하면 복잡하고 흥미로운 사용 사례로 이어질 수 있다.

Deleting assets​

Sui에서는 smart contract가 작업을 허용하면 object를 삭제할 수 있다. 올바른 smart contract 함수가 있다면 단일 transaction으로 object를 삭제할 수 있다. 이는 gas-fee rebate로 이어지며, 체인에서 bytes가 해제될 때마다 이런 일이 발생한다. Transaction의 gas payer는 더 이상 필요하지 않지만 이미 비용이 지불된 object의 미래 저장을 고려해 receives a rebate를 받는다.

Soulbound assets​

Soulbound asset은 address에 속하며 transfer하거나 delete할 수 없는 NFT이다. Sui에서 assets는 일반적으로 addresses 간에 자유롭게 transferable하지만, 어떤 경우에는 이것이 바람직하지 않은 동작이다.

게임 season passes, loyalty accrual assets, avatars, 제품용 identification assets, 그리고 smart contract 수준에서 특정 privileges를 부여하는 assets와 같은 것은 transfer나 deletion 옵션 없이 address에 binding되기에 적합하다.

Sui에서는 이러한 asset을 구현하기 쉽고, 인프라는 원하는 동작이 항상 유지되도록 보장한다.

NFT asset은 contract 수준에서 soulbound로 정의한다. 일단 soulbound로 지정되면 일반적인 transferable asset으로 변환할 수 없다. 이를 변경하려면 같은 이름의 새 asset과, soulbound asset을 삭제하고 그 자리를 대신할 일반 asset을 만드는 것과 같은 migration strategy가 필요하다.

Soulbound assets는 store ability를 생략해 생성한다. 이 ability가 없으면 soulbound assets를 다른 objects 안에 저장할 수 없다. Asset 타입을 결정할 때 이 동작을 염두에 두어야 한다. 즉 Soulbound assets는 완전히 composable하지 않으며, 다른 assets를 저장할 수는 있지만 다른 assets 안에 저장될 수는 없다.

같은 패턴을 사용해 특정 상황에서만 transfer 가능하거나 burn 가능한 NFT assets를 구현할 수 있다. Asset을 soulbound로 만들고 custom transfer 및 burn 함수를 정의함으로써 이러한 상황을 smart contract 수준에서 정의할 수 있다.

Sui Object Display​

Sui Object Display standard는 앱과 인터페이스에서 objects가 어떻게 보이는지 정의하는 데 도움이 되는 도구이다. 이는 object의 데이터를 삽입해 표시 방식을 제어할 수 있는 template처럼 동작한다. 데이터 자체가 on-chain에 저장되고 표시는 off-chain(앱 또는 웹사이트)에서 일어나더라도, 이를 사용해 다양한 타입의 데이터가 어떻게 표시되는지 관리할 수 있다.

Sui Object Display standard는 몇 가지 핵심 이점과 구성 요소를 제공한다:

  • Controlled representation: 기본 asset과 직접 상호작용하지 않고 assets가 온라인에 표시되는 방식을 관리한다. Assets와 독립적으로 display를 업데이트할 수 있으며 타입 <T>의 모든 assets가 표시되는 방식에 영향을 줄 수 있다.
  • Flexibility: 사용자 정의할 수 있는 필드에 제한이 없다.
  • Enhancing asset information: ERC721 또는 ERC1155 NFTs에 추가 세부 정보를 더하는 것과 비슷하게 Sui Object Display를 사용하면 이름, 설명, 이미지 등과 같은 특정 세부 정보를 디지털 아이템에 추가할 수 있다.
  • Stored data and off-chain representation: metadata standards에 따라 저장된 데이터를 관리하고 그것이 off-chain에서 어떻게 표현되는지 제어한다.
  • Dynamic display: 타입 <T>의 모든 NFTs에 걸쳐 공유 속성이 균일하게 표시되도록 하여, 고유 IDs에서 파생된 image URLs와 같은 공통 필드의 일관된 표현과 asset collection 전체의 응집된 display 형식을 유지한다.

주의해야 할 몇 가지 제한 사항이 있다. 첫째, 현재 Sui Object Display의 구조는 타입별이므로 범위가 제한된다. 둘째, 그 구조는 nested attributes나 enums를 허용하지 않는다.

Implementation overview​

높은 수준에서 이 기능은 다음 단계로 구현한다:

  1. 자신이 소유한 Publisher object를 사용하여 특정 타입에 대한 sui::display를 설정한다.
  2. Sui Move의 Display<T>는 다양한 타입이 어떻게 보이는지 정의한다. 예를 들어 Display<0x2::capy::Capy>는 타입의 외형을 형성한다.
  3. Sui Full nodes는 쿼리에서 { showDisplay: true }로 요청될 때 Display definitions를 사용해 데이터를 정리한다.

Display는 keys와 values의 map이며 둘 다 strings이다. Values는 string interpolation을 허용하므로, 이는 보고 있는 NFT에 따라 value가 동적으로 바뀐다는 의미이다.

기본 예제는 Asset objects를 위한 Display를 만드는 것이다:

public struct Asset has key, store {
  id: "0x3301",
  expiration: 123456789
}

public struct Display has store {
  "random_field": "The ID is {id} and it expires at {expiration}"
}

위의 Display는 예시 Asset에 대해 다음과 같이 된다:

Display
{
  "random_field": "The ID is 0x3301 and it expires at 123456789"
}

다른 Asset의 경우 id와 expiration 값은 새 Asset의 값에 따라 바뀐다.

앱은 custom keys를 이해할 수 있는 Display object를 사용할 수 있다. 기본적으로 explorers나 wallets와 같은 대부분의 third-party apps는 아래에 설명된 attributes를 인식한다.

  • name: object를 볼 때 표시되는 object의 이름이다.
  • description: object를 볼 때 표시되는 object의 설명이다.
  • link: 애플리케이션에서 사용하기 위한 object에 대한 링크이다.
  • image_url: object의 이미지에 대한 URL 또는 blob이다.
  • thumbnail_url: wallets, explorers, 기타 products에서 미리보기로 사용하기 위한 더 작은 이미지 URL이다.
  • project_url: object 또는 creator와 연관된 웹사이트 링크이다.
  • creator: object creator를 나타내는 string이다.

Game economies​

Sui 블록체인에서 토큰과 coins를 설계하고 관리하는 것은 실행 가능한 game economy를 만드는 데 중요하다.

GameFi​

GameFi (Gaming Finance)는 게이밍과 블록체인 기반 금융 인센티브를 결합한다. 이는 게임 내 성취에 대한 토큰 보상을 통해 플레이어에게 경제적 혜택을 제공한다. 최근 GameFi의 부상은 게이밍 ecosystems를 지원하기 위한 토큰 출시의 상당한 증가로 이어졌다.

다음 용어들은 GameFi를 논의할 때 자주 사용되므로, 용어의 정의가 문서와 일치하는지 확인하는 것이 중요하다.

  • Token generation event (TGE): 토큰의 최초 생성 및 배포이다.
  • Initial coin offering (ICO): 토큰 판매를 사용하는 초기 자금 조달 모델이다.
  • Vesting: 시간이 지나며 토큰이 점진적으로 release되는 것이다.
  • Staking: 네트워크 운영에 참여하고 rewards를 얻기 위해 토큰을 잠그는 것이다.
  • Cliff: 토큰 vesting이 시작되기 전의 초기 대기 기간이다.
  • Annual percentage yield (APY): 1년 동안 staked asset의 실질 수익률이다.
  • Decentralized autonomous organization (DAO): smart contracts와 토큰을 사용해 의사결정을 수행하는 governance model이다.
  • 거버넌스 토큰: 탈중앙화 네트워크에서 voting power를 부여하는 토큰이다.

Token economics (Tokenomics)​

Tokenomics는 Web3 ecosystem을 위한 토큰을 지배하는 규칙의 모델과 설계를 의미한다. GameFi의 경우, 이는 토큰이 게이밍 플랫폼 안에서 어떻게 생성되고, 배포되고, 활용되고, 유지되는지를 정의한다. 토큰 economics를 구성하는 기능에는 supply 세부 정보, distribution mechanisms, staking, vesting 등이 포함된다.

On-chain ecosystem에 대한 tokenomics를 논의할 때 고려되는 토큰 공급량의 여러 유형이 있다.

Supply typeDescription
Total supply존재하게 될 최대 토큰 수이다.
Circulating supply현재 사용 중이며 거래 가능한 토큰이다.
Adjusted supplyburning 또는 minting events 이후 조정된 토큰이다.
Fixed supply미래에 변경이 없는 사전 결정된 토큰 수이다.

Distribution mechanics의 유형도 하나 이상 있지만 반드시 모두 사용되는 것은 아니다.

Distribution mechanismsDescription
Initial distributionICO, TGE, airdrops, 또는 private sales를 통한 배포이다.
Ongoing distributionstaking, liquidity mining, 또는 incentive programs를 통한 배포이다.

Ongoing distribution은 staking and vesting of GameFi tokens을 의미한다. 모든 game economies가 staking 또는 vesting models를 포함하는 것은 아니다. 여러분의 economy에 이를 포함할지 결정할 때는 다음 이점을 고려한다:

  • 장기적인 참여를 장려한다.
  • Circulating supply를 줄여 토큰 가격을 잠재적으로 안정화한다.
  • Ecosystem의 적극적인 참여자에게 보상한다.
  • 참여 기간에 걸쳐 team members에게 보상한다.

Tokens를 가장 잘 출시하는 방법을 결정할 때는 몇 가지 핵심 사항을 고려하는 것이 중요하다:

  • Fixed supply와 adjusted supply 중 어떤 coin supply를 선택할 것인가? Fixed supply는 모든 토큰이 TGE에서 mint된다는 뜻이다. Adjusted supply는 minting 및 burning functions를 신중하게 제어해야 한다.
  • Token이 regulated되어야 하는가? regulated coin은 누가 토큰에 접근할 수 있는지에 대해 더 큰 제어를 제공하지만, deny list를 추가로 유지 관리해야 하는 비용이 따른다.
  • Metadata requirements도 고려해야 한다.
    • Decimal places: 토큰의 precision을 사전에 정의한다.
    • Metadata management: metadata가 immutable이어야 하는지 결정한다.
    • Burning mechanisms: 토큰 burning에 대한 규칙을 정의한다.

Kiosk​

Sui에서 owned objects는 자유롭게 transferable하거나 non-transferable하다. Royalties를 보장하기 위해 Sui는 Kiosk라는 standard를 제공한다. Kiosk는 단일 address 또는 user에 대한 접근을 제한하는 shared object이다.

Kiosk 소유자(shared object는 Sui의 관점에서 owner가 없지만 smart contract는 오직 하나의 address만 접근할 수 있도록 보장한다)는 다음을 할 수 있다:

  • 자신의 address에서 kiosk 안으로 assets를 넣는다.
  • kiosk에서 자신의 address로 assets를 다시 가져온다.
  • 자신의 address에 있거나 이미 kiosk 안에 들어 있는 assets를 lock하여 "take" 작업이 불가능하게 만든다.
  • 안에 assets가 없는 kiosk를 파괴한다.
  • SUI로 가격이 표시된 asset을 판매 목록에 올린다.
  • SUI로 가격이 표시된 asset을 특정 address에만 판매하도록 목록에 올린다.

다른 any address는 다음을 할 수 있다:

  • "list" 작업을 거친 item을 구매한다.
  • asset이 그런 방식으로 "listed"되었을 경우 특정 address를 위한 item을 구매한다.

Kiosk의 채택은 marketplaces가 서로 다른 kiosks 안에 있는 "listed" items의 집합체가 된다는 뜻이다.

"lock" 작업을 거친 asset은 더 이상 "take" 작업을 할 수 없고, 오직 "list" 작업만 할 수 있다.

Transfer policy​

"buy" 작업에는 transfer policy라는 또 다른 object가 필요하다. 이는 보통 shared object이며 "buy" 작업을 지배하는 규칙을 담고 있고, 가장 흔한 규칙은 "Royalties"이다.

정의된 transfer policy가 없는 asset에 대해서는 "buy" 작업을 완료할 수 없다.

규칙이 없는 비어 있는 transfer policy는 asset이 자유롭게 거래 가능하다는 뜻이다. Kiosk는 "list"와 "buy"의 작업 쌍만 허용하므로 가격을 0 SUI로 설정하면 transfer가 가능하다.

규칙은 Move로 프로그래밍할 수 있는 어떤 것이든 될 수 있다. Marketplaces를 사용하려면 asset creator는 https://github.com/MystenLabs/apps/tree/main/kiosk/sources/rules 에 정의된 규칙을 사용해야 한다.

Common rules는 다음을 포함한다:

  • Royalty rule: asset creator에게 가는 가격의 일정 비율이다(실제로는 transfer policy 안으로 들어가며 creator는 언제든 이를 transfer할 수 있다).
  • Floor price rule: asset이 "listed"될 수 있는 최소 가격이다.
  • Lock rule: "buy" 작업 이후 asset이 kiosk 안에 lock되도록 강제한다.

Lock rule과 royalty rule의 조합은 creator에게 royalties가 지급되도록 강제한다. Lock rule은 asset이 kiosk 밖으로 "taken"되어 자유롭게 거래될 수 없게 하고, royalty rule은 Kiosk를 통해 거래되는 모든 asset에서 transaction 시 royalties가 차감되도록 보장한다.

Royalties가 엄격한 요구 사항일 때는 lock rule을 추가하는 것이 권장된다. Marketplaces가 Sui에서 Kiosk만 지원하는 동안에는, lock rule이 없더라도 사용자에게 다른 선택지가 없을 수도 있다. Peer-to-peer trading은 안전하지 않다고 가정해도 무방하며, 대부분의 사용자는 transaction이 원활하게 이루어짐을 보장할 방법이 없기 때문에 이를 피한다. Peer-to-peer transactions에서는 누군가가 asset transfer 또는 payment transfer 중 하나를 먼저 시작해야 하고, 이후 단계가 실제로 이어진다는 보장이 없다.

가장 중요한 점은 asset의 초기 airdrop 또는 minting 시점에, 그 asset이 kiosk 안에 들어가고 address로 직접 전송되지 않도록 보장하는 것이다.

Tools​

Sui ecosystem에는 Sui 게임 비전을 실현하는 데 도움이 되는 여러 도구가 있다.

Playtron GameOS는 PCs, handhelds, desktops를 전용 게이밍 콘솔로 바꾸는 것을 목표로 하는 Linux 기반 운영 체제이다. 이는 Steam과 Epic Games 같은 여러 game stores를 지원하여 Steam Deck, ROG Ally, Lenovo Legion Go와 같은 기기에서 원활한 게이밍 경험을 제공한다.

Example integrations​

이 섹션에서 설명하는 통합에 대한 실제 구현은 없다. 이러한 예제는 Sui 네트워크에서 실행 가능한 게임 통합의 가능성을 보여주기 위한 사고 실험이다.

ShadowQuest는 판타지와 RPG battle mechanics를 결합한 multiplayer 게임이다. ShadowQuest는 Web3 technologies로 게이밍 경험을 향상하기 위해, 전체 게이밍 경험을 해치지 않으면서 플레이어에게 원활한 블록체인 상호작용을 제공하도록 Sui와 통합하고 있다.

Seamless player onboarding and wallet integration

ShadowQuest는 특히 Web3에 익숙하지 않은 플레이어에게 복잡성을 추가하지 않으면서 플레이어를 onboard하고자 한다. zkLogin을 사용하면 플레이어는 Google, Facebook, Twitch, Apple과 같은 social platforms를 사용해 sign in할 수 있다. 이는 ShadowQuest 계정에 연결된 Sui wallet을 자동으로 생성하여 블록체인 상호작용을 원활하게 만든다.

Simplified transaction handling

ShadowQuest의 플레이어는 NFTs 또는 $SHADOW tokens와 같은 in-game assets를 획득하거나 사용한다. ShadowQuest는 Web3에 익숙하지 않은 플레이어를 끌어들이기 위해 transactions 서명을 위한 wallets 팝업과 같은 Web3 friction을 피할 수 있도록 game transactions를 관리한다. Player transactions를 sponsor함으로써 ShadowQuest 플레이어는 transaction costs와 gas fees를 직접 지불하지 않게 되므로 friction이 최소화된다.

Enoki transactions는 transaction 승인을 위해 플레이어의 confirmation을 요구하지 않고 서명될 수 있다.

ShadowQuest는 Enoki Gas Pool을 사용해 transactions를 sponsor하고 플레이어의 gas fees를 부담한다. 이는 모든 in-game transactions가 플레이어에게 원활하고 무료가 되도록 하여 더 나은 user experience를 제공한다.

NFT marketplace and royalty enforcement

ShadowQuest는 플레이어가 무기, 갑옷, cosmetic items와 같은 in-game items를 사고, 팔고, 거래할 수 있게 한다. 이러한 items는 creators가 각 transaction의 혜택을 받을 수 있도록 royalties를 존중해야 한다.

Kiosk는 탈중앙화 marketplace 솔루션을 제공하여 모든 NFT 거래에서 royalties가 집행되도록 보장한다. 이는 게임 개발자와 creators 모두가 secondary sales에 대한 제어를 유지하도록 도와주며, asset lifecycle 전체에 걸친 수익 창출을 보장한다.

NFT usage for game access

ShadowQuest는 NFTs를 다양한 game modes와 events의 입장 ticket으로 사용한다. 플레이어는 다양한 Runes를 획득하거나 얻을 수 있으며, 이는 특정 game challenges 또는 seasonal competitions에 대한 접근 권한을 부여한다. 이러한 NFTs는 다른 플레이어에게 거래되거나 transfer될 수 없다.

소울바운드 NFT는 gameplay를 통해 획득하거나 구매하는 서로 다른 Runes를 나타낸다. 이러한 NFTs는 matches와 seasonal challenges에 대한 독점 access를 부여하지만, 일단 플레이어에게 bound되면 거래될 수 없다.