由ERC 721Token代表的游戲裝備

從 Cryptokitties 開始，目前的以太坊 Dapps 游戲以Token為中心，符合ERC 721標準。 ERC 721Token標準定義了不FungibleToken元數據，并將其用作游戲裝備或角色。

例如，在 Cryptokitties中 ，我們定義了一個連接到ERC 721TokenID的Kitty結構（struct），并在那里存儲了角色的必要參數。

：kitty.sol

struct Kitty {

uint256 gene;

uint64 birthTime;

uint64 cooldownEndBlock;

uint32 matronId;

uint32 sireId;

uint32 siringWithId;

uint16 cooldownIndex;

uint16 generation;

}

在Cryptokitteis中 ，此結構中包含的參數管理由ERC 721Token表示的字符的元數據。 各種 Dapps 游戲存在時，符合ERC721Token， 是由擺動到一個單一Token元數據和ID來區分的裝備。

用 Dapp表達 游戲物品

由這種元數據的“游戲裝備抽象化”是 Dapps 開發中非常重要的元素。 在CryptoKitties 的示例中，除了作為決定外觀的因素的gene之外，元數據還包括關于交配，父母和世代的信息。 通過在元數據中包含這樣的信息，它對應于拍賣功能和配對功能，但是將來可能難以添加更多功能。

因此，在 Dapp中 ，可以說在開始時定義的數據結構在此之后極大地影響了游戲的發展。

查看Etheremon 示例，以下結構被定義為表示怪物的結構。

：etheremon.sol

struct MonsterObj {

uint64 monsterId;

uint32 classId;

address trainer;

string name;

uint32 exp;

uint8［］ statBases;

uint8［］ skills;

uint32 createIndex;

uint32 lastClaimIndex;

uint createTime;

}

例如，在這個 結構中，可以想象 statBases 表示添加了早期怪物參數，技能的技能和參數。 正如我們在 CryptoKitties 的例子中所證實的那樣 ，開頭定義的元數據結構在此之后改變了游戲的可擴展性。

在下文中，我們將考慮ERC 721Token是否能夠正確表示游戲裝備以及ERC 1155Token的有用性，以及它們的示例。

ERC 721代幣可以代表游戲物品嗎？

在符合 ERC 721Token的Dapps 游戲中，游戲物品被表示為Non-Fungible Token ，因此可以逐一區分它們。 當然，對于每個裝備都有自己的屬性或參數隨用戶開發而變化的裝備，可以說使用Non-FungibleToken是合適的。

然而，物品如配件的參數為不變的物品及裝備（如：“草藥”，“劍”，“石子”等等）， 這類更準確的應該被分為FungibleToken。 為固有的虛擬代幣提供單獨的元數據可以減少游戲裝備的流動性，這可以說是區塊鏈游戲創新的核心以及在想要節省數據資源的區塊鏈游戲中會產生多余的情況的一個原因。

我們來舉一個具體的例子。假設存在不必逐一區分的“普通的劍”和在游戲中逐個參數不同的“稀有的劍”。 將前者表示為Fungible，將后者表示為Non FungibleToken是恰當的。 但是，當所有物品都被歸類為Non Fungible時，當你想要逐一交換“10把普通劍”和“1把稀有劍”，“10把普通劍”時它需要被替換為一把單獨的劍。

因此，在交易時會產生額外的交易成本。 這被認為是區塊鏈游戲中的一大損失，其中交易費是一個大問題。

在這方面，我認為需要一個可以代替Non-FungibleToken和FungibleToken的新Token標準 ，取代ERC 721標準。 從接下來一張我們開始講述我們計劃采用的ERC1155Token。

ERC 1155標準的概述

為了管理多種Token類型的智能合約的標準接口。 單個ERC 1155Contract可以包括Fungible Token，Non Fungible Token或其他配置（例如，半替代Token）的任何組合。

此標準是一個智能合約界面，可以表示 任意數量的 Fungible和Non-FungibleToken類型。 現有標準（如ERC-20）要求為每種Token類型部署單獨的Contract。 ERC-721標準中的TokenID是單個非替代索引，這些非替代組被部署為包含整個集合的設置的單個Contract。 相反，ERC-1155多Token標準允許每個TokenID 表示新的可配置Token類型 。 此Token類型具有自己的元數據，耗材和其他屬性。

_id參數包含在每個函數的參數中，并指示交易中的特定標記或標記類型。

諸如ERC-20和ERC-721之類的Token標準要求您為每種類型的Token部署單獨的Contract。 這會在以太坊區塊鏈中放置大量冗余字節碼，并將每個TokenContract分成其自己的授權地址，這也限制了某些功能。 隨著區塊鏈游戲和支持它們的平臺的出現，游戲開發者可能已經創建了數千種Token類型，并且需要新類型的Token標準來支持它們 。 但是，ERC-1155并非特定于游戲，因此許多其他應用程序可以從這種靈活性中受益。

此設計允許新功能，例如一次傳輸多個Token類型，從而節省交易成本。 可以在此標準上構建多個Token交易（托管/原子交換），從而無需單獨“批準”單個TokenContract。 在單個Contract中描述和混合多個可替代或不FungibleToken類型也很容易。

ERC1155的規格

以下 說明基于EIP1155的ERC1155Token所要求的特征部分。

· 區分Fungible和Non Fungible

Contract中使用的_id是uint256，前半部分和后半部分可以除以128位。

為方便起見，前半部分稱為 TokenId ，后半部分稱為IndexId 。

例如， 通過運行薄荷功能ERC1155， 產生一次FungibleToken，_id 是： 在 mintNonFungible 函數發生兩次NonFungibleToken。

也就是說，它具有以下特征。

· FT的負責人總是0

· FT的 IndexId （后半部分Id）將始終為0000000000000000

· NFT的負責人總是1

· 每次執行 mintNonFungible 函數時， NFT的 IndexId （下半部分的Id）都會增加。

因此，在 ERC 1155中，FT和NFT之間的區別在_id的開始（0或1）處執行，并且NFT之間的區別 由后半部分中的 IndexId 執行。 當然，FT之間沒有區別。

· Token的移動

：erc1155Spec.sol

//移動多個Token

function safeBatchTransferFrom（address _from， address _to， uint256［］ calldata _ids， uint256［］ calldata _values， bytes calldata _data） external;

//移動Token

function safeTransferFrom（address _from， address _to， uint256 _id， uint256 _value， bytes calldata _data） external;

正如上面提到的，ERC1155Token， 除了safeTransferFrom， 支持功能還提供了safeBatchTransferFrom。 在這里，使用uint256 ［］ _ ids，uint256_value，可以指定要移動的多個標記和值的ID。

也就是說， 可以在單個交易中交換十個FungibleTokenA，一個Non FungibleTokenB和一個Non FungibleTokenC.

如何定義ERC1155Token的元數據

如開頭所述，在定義游戲項時如何定義元數據結構非常重要。

雖然ERC 1155Token允許以后自由生成Token，但以后無法自由設置元數據。 因此，當使用ERC 1155Token作為游戲項時，有必要在開始時仔細設置元數據。

正如我們在前面的示例中看到的， CryptoKitties 元數據和 Etheremon 元數據是完全不同的。 這是因為 ，雖然 CryptoKitties中沒有所謂游戲中戰斗的概念，但 Etheremon 具有諸如戰斗，技能增長和進化等參數。 如果您打算創建一個高度可擴展的游戲，例如，以NonFungibleToken示例，將需要同時擁有想要戰斗的裝備（角色）和與戰斗無關的裝備（例如：怪物和裝備物品）。 此外，一些裝備 （角色）將隨著游戲的進展而增長， 并且一些角色將保持與其初始值不變。 另外，對于FungibleToken，有“收獲”是恢復裝備，并且還有諸如“劍”和“槍”之類的裝備，這些也會增強裝備技能。

如何設置可以表達這些差異的抽象元數據？ 當使用ERC 1155Token作為游戲物品時，這一點被認為是非常困難的一點。

作為不FungibleERC1 155Token的元數據，參考ERC 721案例，定義gene和技能等元數據，并且在具有增長和變化的Token的情況下，適當地改變這些值。有可能通過表達角色的成長

另一方面，在 FungibleToken中， 除了包括在現有ERC 20標記中的 totalSupply 和name之類的參數之外 ，我們認為還應包括關于裝備特征，string和 uint 類型的，像skills和effects這樣的信息參數。

在任何情況下，通過設置適當的元數據，將能夠創建比現有 Dapps 游戲更具有可擴展性和流暢性的游戲。

ERC1155Token元數據設置示例

以下是 使用ERC1155的游戲道具的示例。 例如，以下的Non FungibleToken為例。

：nonFungible.sol

struct NonFungibleMetaData {

uint256 id;

uint256 genes;

uint8［］ skills;

string name;

uint256 winCount;

uint256 papaId;

uint256 momId;

uint256 saleDuration;

bool isOnSale;

}

在此示例中 ，設置元數據以支持Non-FungibleToken的名稱，能力，外觀，交配和拍賣等功能。 如果這是現有 Dapp 字符 的 圖像，則上述功能可能不是必需的和充分的。

另一方面， 請將以下內容視為FungibleToken。

：fungible.sol

struct FungibleItems {

string name;

uint256 totalSupply;

uint256 itemPrice;

FungibleItemExecInterface tokenContract;

mapping（address =》 uint256） balances;

}

在這里，我們準備了FungibleToken名稱，總供應量，價格，持有量和裝備執行界面。

通過設置 FungibleItemExecInterface ，可以將如草藥和武器之類的Fungible物品抽象化，甚至可以執行其物品。

下面是 FungibleItemExecInterface的示例。

：fungibleItemEffect.sol

contract FungibleItemExecInterface {

function modifyGenes（uint256 _gene） external returns（uint256）;

function modifySkills（uint8［］ _skills） external returns（uint8［］）;

}

這里 定義了兩個函數。 modifyGenes 是一個接收 nonFungibleItem 的gene之后并將修改的gene 返送回去的函數。

另外，ModifySkills 是接收NonFungibleItem的skills后將修改的skills返送回去的函數。

通過以這種方式定義界面，可以為更改每個裝備賦予角色的效果。

如果想為每個游戲（例如戰斗或抽獎系統）實現獨特的功能，則需要考慮進一步考慮與線下時的合作，但通過設置如上所述的元數據，它將適用于多個裝備，更有可能靈活的對應。

Dex 與ERC1155Token的兼容

Moldex α版本通過構造符合帶有如上所述的ERC1155Token的 Dex 實現更具有靈活性的Token傳輸 。

目前的 ERC 721的 Dex 僅支持Non FungibleToken，但是通過支持包括Fungible Tokens在內的ERC 1155標準， Moldex 不僅適用于Non Fungible和角色，還適用于“購買10個草藥”這樣Fungible的裝備。 這不僅會增加游戲間的資產轉移，還會促進ERC 1155Token的傳播，并有望為 Dapps Games做出進一步的發展與貢獻 。