回顧
在第一部分中，我概述了在以太坊區塊鏈上開發網球經理模擬遊戲的想法。我創建了ERC721 代幣和TrainableTennisPlayer 合約，使所有者能夠通過訓練或休息來增加他們的球員數據。
第二部分介紹了CompetingTennisPlayercontract，負責計算球員之間比賽的獲勝者。
從那時起，我為這些合約編寫了單元測試。它們絕不是完整的，但我想嘗試盡快構建一組可用的合約來測試基本的前沿。如果你想幫助測試和構建應用程序，請查看Github 存儲庫。
我還修改了TennisPlayerBase 合約以擴展ERC721Enumerable，而不是Openzeppelin 提供的標準ERC721 令牌。這使我們的遊戲能夠使用_tokensOfOwner(address) 檢索地址擁有的所有令牌。實現這意味著不需要用戶在每次登錄時記住他們的令牌ID。
正如我在上一篇文章中提到的，我期待著啟動並運行一個基本的界面來開始與遊戲進行交互。
拉在一起
圖1 顯示了上一期之後的合約圖。
圖1：合約結構
我希望遊戲Dapp 可以通過盡可能少的智能合約訪問，所以前端代碼不會太複雜。因此，SomethingHere 的原因。
我創建了一個合約來代替SomethingHere 稱為TennisPlayer。這顯示在以下代碼中。
注意第9 行的myPlayers() 如何使用從ERC721Enumerable 繼承的_tokensOfOwner() 函數。如前所述，這允許前端加載用戶擁有的所有播放器。
創建新玩家
在第一部分中，我使用自定義訪問修飾符onlyOwner（繼承自Openzeppelin 的Ownable 合約）在TennisPlayerBase 中創建了newPlayer() 函數。這意味著只有令牌的所有者才能創建新玩家，其他人不能。如果遊戲要控制新玩家的起始屬性設置，就必須這樣。否則，用戶可以創建一個新玩家並立即最大化統計數據。
為此，我們需要一個總體遊戲智能合約，該合約在部署時會創建TennisPlayer ERC721 代幣合約，從而成為所有者。
以下是執行此操作的智能合約Game.sol。
注意第11 行到第16 行的默認屬性值。每個新玩家都從這些開始。將來，可能會引入隨機性元素，因此每個新玩家的優勢和劣勢都略有不同。 （雖然隨機性是一個癥結）
智能合約還在第9 行存儲了一個名為publicTokenAddress 的地址，表示我們的ERC721 代幣的位置。當在第19 行創建代幣時，構造函數會檢索該地址。
newPlayer() 函數在第22 行公開，只從用戶那裡獲取新玩家的姓名、年齡和身高。這是進入遊戲Dapp 的入口點。
在此階段，用戶可以通過遊戲合約創建新玩家，並與TennisPlayer 中的功能進行交互以訓練休息和與其他玩家競爭。這似乎是開始構建前端的好地方。
前端
Truffle 套件提供了一堆Truffle 盒子，它們與你選擇的框架打包在一起。我正在使用React 框和Redux（我自己添加的）。
為了讓我們的DApp 能夠與遊戲進行交互，Redux 商店還需要保存有關它所連接的區塊鏈、智能合約以及用戶正在使用的帳戶的信息。
我使用這種模式來確保所有這些都被正確加載。最初，它可能看起來有點矯枉過正，但如果在加載階段出現問題，它有助於將其可視化。
圖4：加載區塊鏈
圖5：加載區塊鏈
顯示播放器
為了顯示用戶擁有的所有球員，DApp 需要調用TennisPlayer 合約中的myPlayers() 函數，並將結果存儲在Redux 存儲中。從那裡，組件可以選擇數據，並將其顯示在頁面上。
我已經編寫了一個負責這個名為PlayerList 的組件，如下面的代碼所示。
PlayerList 呈現帶有標題、玩家列表和用於創建新玩家的表單的Bootstrap 卡片。沒有任何播放器，它看起來像圖7，一旦用戶創建了播放器，列表就會顯示ID，如圖8 所示。
圖7：沒有玩家的PlayerList
圖8：列表中玩家0 的PlayerList
該列表是可選擇的。通過單擊列表中的項目，DApp 會檢索播放器的詳細信息並將其存儲在Redux 商店中。
顯示玩家詳細信息
另一個名為PlayerDetails 的組件負責從Redux 存儲中選擇玩家詳細信息並將其顯示在頁面上。
下面顯示了PlayerDetails 組件的代碼。
該組件呈現另一個Bootstrap 卡，當處於活動狀態時，如圖10 所示。
圖10：玩家詳細信息卡片
綜合起來，圖11 顯示了處於當前狀態的前端。非常基本，非常笨重，而且還遠未完成。它尚未實現智能合約中可用的所有功能，但這是一個良好的開端。
圖11：全前端
下一步
該項目正在積極開發中。在撰寫本文時，代碼的當前狀態如本文所述。
我希望能夠盡快通過界面進行訓練、休息和與玩家競爭。訓練和休息將是我的下一個功能，因為它們只需要一名球員，而比賽至少需要兩名球員，因此需要稍微多一些。
一旦支持所有可用的智能合約功能，我將考慮擴展匹配邏輯，或者讓前端看起來更有吸引力和更像遊戲。
還有很長的路要走，但讓整個堆棧協同工作是一大步
代碼存儲庫位於Github 上，因此它是公開的並對拉取請求開放。如果你有興趣提供幫助，請貢獻這是回購。
進一步閱讀
如果你想了解有關加密貨幣生態系統的更多信息，請註冊每週通訊。
資訊來源：由0x資訊編譯自COINCODECAP。版權歸作者Gaurav所有，未經許可，不得轉載