Developing a Blockchain Game, a New Field of Its Own
It has been about a week since GoCryptobot, a blockchain game that I developed at Kodebox, has been released. Even at this moment, Ether is being traded for GCC through the Smart Contract within the game, and the PvP, an event where up to 128 players can participate in, is being held up to 6 times per day. Since there are only a few mainstream blockchain games out there, especially for the mobile platform, we faced a variety of new, difficult cases never documented before. In this article, I plan on discussing these problems and solutions in detail, and the points of caution I suggest you to consider when making a blockchain game. I hope this can be helpful for blockchain game development teams out there.
1. We Never Know When a Transaction Will Be Mined: Don’t Make Match/Game Schedules Too Tight
In GoCryptobot, there are 6 PvP matches everyday. Before every match, users must register for the PvP and when the match starts, a Smart Contract that calls the transactions will be called. Ethereum’s PoW protocol requires around 15 more blocks in order to guarantee finality. At first, we thought that 10 minutes would be enough for this process. However, there were many cases where the transactions did not mine in time, and the PvP match did not successfully terminate at the 10 minute mark.
We decided that the 10 minute window was too small to guarantee every PvP match, and thus, extended the time to 20 minutes.
2. When Urgent, Raise the Gas Price and Retransmit
If the mining just isn’t happening due to low gas price setting, then you should increase the gas price and create another transaction.
When creating another transaction with a higher gas fee, the transaction’s nonce value has to be identical to the transaction sent previously, or else it would be like a sending a completely new transaction and have no priority. This is because transactions are mined based on the nonce values in the Ethereum network. The transactions with the lower gas fee will be ignored if there is another transaction that has been mined with the same nonce value.
web3.eth.sendTransaction()
myContract.methods.myMethod()
In Web3, the nonce value can be set with the above functions.
3. Ethereum Accounts Should Be Separated Depending on Purpose
Mining rates depend on the amount of gas. There are transactions that need to be mined quickly or slowly depending on the situation. As mentioned above, Ethereum transactions are processed in a first-come-first-serve basis, and using a single account to process multiple transactions will render you unable to change gas fees to speed up the mining rates. Even if you raise the gas fee to speed up a certain transaction, it will have to wait for the previous transaction to finish. If that previous transaction has a low gas fee, then it will be a bottleneck for the following transactions.
Thus, depending on usage and purpose, Ethereum accounts should be used separately.
4. Let’s Be Attentive to Gas Fees
Gas fees are constantly fluctuating, and thus, if you want guaranteed results in the blockchain, then you must implement a system that automatically changes the gas fees depending on the situation.
By doing this, you can use gas fees that range between 10~30 Gwei, and edit gas fees when appropriate.
5. Unpredictable Error in the Web3 Library
When creating a transaction from the Web3 library, there were errors that occured. There was an error when a transaction was not mined within 50 blocks; however, it was confirmed that this transaction was actually mined later in the Ethereum network.
“Error: Transaction was not mined within 50 blocks, please make sure your transaction was properly sent. Be aware that it might still be mined!”
The function that transfers GCC into Ether has an exchange logic that is enveloped by the DB transaction. If there is an Error like above, then our system is set to rollback. However, if the mining has actually been complete, the server DB has been rolled back, and the Ethereum has actually been transferred to another user, which actually sounds like absolute catastrophe.
In order to solve this problem, we decided to make a function that detects when Web3 has an error, and notifies the developer.
Conclusion
This concludes my experience of developing the mobile blockchain game, GoCryptobot. The contents may sound cliche; however, there are large amounts of money involved when creating a system such as this, and since blockchains are not forgiving when it comes to editing already transmitted data, I hope this article can help you to reinforce your own blockchain app that is either in or finished development.
GoCryptobot can be downloaded through the links below:
- App Store: https://apple.co/2KbMipn
- Google Play: https://bit.ly/2K5tYhx
(For the Korean version of this article, click here.)
