全鏈游戲，簡而言之，就是將游戲的所有核心邏輯，包括狀態(tài)存儲、計算與執(zhí)行等，全部部署于區(qū)塊鏈上。直觀來說，現(xiàn)有的區(qū)塊鏈技術(shù)一定是無法滿足大部分游戲的部署需求。

　　正如我們所熟知的，游戲開發(fā)首先需要一套引擎，例如unity，或者unreal引擎。游戲引擎并非必須，但如果從頭自己開發(fā)一部游戲作品，是中小型開發(fā)者所無法承擔(dān)成本的一種選擇（對于大廠來說，出于競爭、定制化需求以及效率提升的緣故，他們有動機開發(fā)自己的引擎，例如Rockstar開發(fā)了自己的引擎RAGE）。

　　另一個必不可少的基礎(chǔ)設(shè)施，是云計算服務(wù)。NFT鏈游系統(tǒng)13z開4z77發(fā)z558，諸如AWS、Google Cloud、Microsoft Azure等，可以實現(xiàn)游戲開發(fā)、構(gòu)建、測試、發(fā)布、部署全流程全鏈條的托管，對游戲開發(fā)效率的提升是數(shù)量級式的；云計算同時在資源與帶寬共享、即時和動態(tài)后端支持等多方面實現(xiàn)更好的效果。

　　游戲?qū)τ嬎愕囊髽O高，大部分游戲均有客戶端與服務(wù)器長連接、網(wǎng)絡(luò)低延遲、頻繁的數(shù)據(jù)寫入（并發(fā)讀寫）、玩家交互、承載彈性等各類計算能力需求。并發(fā)讀寫、低延時、極高的tps要求，這些都決定了現(xiàn)階段甚至未來的區(qū)塊鏈技術(shù)，本身很難承擔(dān)游戲計算的職責(zé)。

　　假使不考慮計算，僅考慮存儲，當(dāng)前一款普通的游戲，游戲本身幾個G到上百G的容量，加上運存要求，也并非當(dāng)前區(qū)塊鏈所能承受的范圍。ETH自2015年，全部交易歷史在標(biāo)準(zhǔn)模式下大約是1TB，這僅僅相當(dāng)于十幾部大型游戲的容量。

　　普通鏈游、傳統(tǒng)游戲之間的對比

　　如前所述，鏈游市場經(jīng)歷了最初一波的火熱與沉寂后，很多傳統(tǒng)游戲產(chǎn)業(yè)的開發(fā)者加入，新一代的鏈游在游戲質(zhì)量與可玩性上將有極大提升，且經(jīng)濟模型設(shè)計也將有優(yōu)化。為了便于區(qū)分，筆者將它們分別稱為“初代鏈游”與“二代鏈游”。

　　NFT智能合約代碼，我們基于OpenZeppelin庫的ERC-721實現(xiàn)。復(fù)制并粘貼以下內(nèi)容到你的MyNFT.sol文件中:

　　//Contract based on[https://docs.openzeppelin.com/contracts/3.x/erc721](https://docs.openzeppelin.com/contracts/3.x/erc721)

　　//SPDX-License-Identifier:MIT

　　pragma solidity^0.8.0;

　　import"openzeppelin/contracts/token/ERC721/ERC721.sol";

　　import"openzeppelin/contracts/utils/Counters.sol";

　　import"openzeppelin/contracts/access/Ownable.sol";

　　import"openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";

　　contract MyNFT is ERC721URIStorage,Ownable{

　　using Counters for Counters.Counter;

　　Counters.Counter private _tokenIds;

　　constructor()ERC721("MyNFT","NFT"){}

　　function mintNFT(address recipient,string memory tokenURI)

　　public onlyOwner

　　returns(uint256)

　　{

　　_tokenIds.increment();

　　uint256 newItemId=_tokenIds.current();

　　_mint(recipient,newItemId);

　　_setTokenURI(newItemId,tokenURI);

　　return newItemId;

　　}

　　}

　　因為我們要從OpenZeppelin合約庫中繼承基礎(chǔ)合約類，在你的命令行中運行npm install openzeppelin/contracts來把這個庫安裝到我們的工程中。

　　那么，上面這段代碼到底做了什么？讓我們逐行分解：

　　在我們的智能合約的頂部，我們導(dǎo)入了三個OpenZeppelin智能合約類：

　　openzeppelin/contracts/token/ERC721/ERC721.sol包含ERC-721標(biāo)準(zhǔn)的實現(xiàn)，我們的NFT智能合約將繼承這個標(biāo)準(zhǔn)。(要成為一個有效的NFT，你的智能合約必須實現(xiàn)ERC-721標(biāo)準(zhǔn)的所有方法)。要了解更多關(guān)于繼承的ERC-721功能，請查看接口定義這里。

　　openzeppelin/contracts/utils/Counters.sol提供了只能加1或減1的計數(shù)器。我們的智能合約使用計數(shù)器來跟蹤已鑄幣的NFT總數(shù)，并在我們的新NFT上設(shè)置唯一的ID。(每個使用智能合約鑄造的NFT必須被分配一個唯一的ID--在本文案例中，我們的唯一ID只是由存在的NFT總數(shù)決定。例如，我們用智能合約鑄造的第一個NFT的ID是1，我們的第二個NFT的ID是2，等等）。

　　openzeppelin/contracts/access/Ownable.sol在我們的智能合約上設(shè)置了訪問控制，所以只有智能合約的所有者（你）可以鑄幣NFT。(注意，包括訪問控制完全是一種偏好。如果你希望任何人都能使用你的智能合約鑄造NFT，請刪除第10行的Ownable一詞和第17行的onlyOwner）。

　　在我們的導(dǎo)入語句之后，我們有了自定義的NFT智能合約，它出乎意料地短--它只包含一個計數(shù)器、一個構(gòu)造函數(shù)和一個函數(shù)！這要歸功于我們繼承的OpenZeppelin合約，它實現(xiàn)了我們需要創(chuàng)建NFT的大部分方法，，例如ownerOf，它返回NFT的所有者，以及transferFrom，它將NFT的所有權(quán)從一個賬戶轉(zhuǎn)移到另一個賬戶。

　　在我們的ERC-721構(gòu)造函數(shù)中，你會注意到我們傳遞了兩個字符串，MyNFT和NFT。第一個變量是智能合約的名稱，第二個是其符號。你可以隨心所欲地給這些變量命名!

　　最后，我們有我們的函數(shù)mintNFT(address recipient,string memory tokenURI)，用來鑄造一個NFT，你會注意到這個函數(shù)接收了兩個變量：

　　address recipient指定將收到你新鑄的NFT的地址

　　string memory tokenURI是一個字符串，應(yīng)該解析為一個描述NFT元數(shù)據(jù)的JSON文檔。NFT的元數(shù)據(jù)實際上是給它帶來生命的東西，允許它有可配置的屬性，如名稱、描述、圖像和其他屬性。在本教程的第二部分，我們將描述如何配置這個元數(shù)據(jù)。

　　mintNFT從繼承的ERC-721庫中調(diào)用一些方法，并最終返回一個數(shù)字，代表新鑄造的NFT的ID。