Intro
Long time ago, even before I came into blockchain industry, I was a hobbyist game developer.
When Ethereum came into existence I was trying to build a game on it. It proves to be impossible to build a game with a deep gameplay due to a set of problems with Ethereum. The main problem there was transaction fees.
Now EOS has appeared, and at the moment it is the most advanced platform for the development of smart-contracts. It seems that it will retain its status for several years, because I don’t see any competitors who would offer something viable to compete with EOS from a technical point of view.
I developed the game on EOS and it currently works on the mainnet. Next, I will outline the difficulties that I encountered, as well as describe my findings on the EOS as a platform.
The main goal of the development of this game was to research advantages/shortcomings of EOS as a smart-contract development platform.
Gameplay depth and game balance are not tuned well.
UI is also a reference implementation only and it serves for studying the capabilities of Scatter and other EOS wallets.I’m planning to develop a more sophisticated game in future.
If you are willing to contribute feel free to contact me: dexaran@ethereumclassic.org
References
Detailed game description can be found here.
The contract is currently published at dexaraniiznx (EOS mainnet).
The source code of the reference smart-contract can be found at this repo.
Reference UI: https://sparke2.github.io/universex-ui/
Game development
Time consumption:
- Core mechanics and main functions: 20% of total time
- (!) Storage cleaning functions: 13% of total time
- Debugging: 61% of total time
- Helper functions and structural updates during the development process: 6% of total time
Smart-contract economy
I’m trying to make the game contract pay for whatever it can to reduce the resource requirements for users.
This primitive game consumes ~1 MB RAM (90 EOS) in total assuming that it supports about 20 players. I assume that an average player can control 5 cells at the map.
Currently, 700 KB are allocated for the contract code and 300 KB for storing players data. The more players have joined the game, the more RAM the contract will consume.
Based on my rough calculations, it will take more than 6000 EOS to make sure that 5000 players do not cause a lack of resources for the contract. Average player upkeep is ~1.2 EOS per player.
I want my game to update its state once per X minutes to (1) generate resource incomes and (2) accomplish active tasks and display the actual state automatically. Unfortunately we have a hard limit of 30 ms for the execution of the transaction on EOS mainnet. This makes it impossible to update the game map in one transaction, thus the game is updating 100 cells per transaction. Updating 100 cells per 6 minutes consumes ~2 sec of CPU (currently 15 EOS) per EOS resource regenerate round which means that this will be enough to make smart-contract updating itself forever. However, in case of network congestion this cyclic update transactions will fail to execute.
Important notes on designing a EOS smart-contract game
EOS is only suitable for games that do not require quick interaction or a huge number of decisions per unit of time. Thus, EOS is mostly suitable for:
- Turn based games
- Gambling
- “Board games”
- Continuous games with relatively small number of decisions
When developing the interface, we worked with Scatter. It needs to be said that there can be a significant delay before the moment of “decision making” and the moment of transaction confirmation.
Although EOS block time is 0.5 sec, you can not rely on this time in your game due to possible delays at UI side. Even if you whitelist a transaction in Scatter it may take up to 3 seconds between you pressed a button in the game and the confirmation of the transaction at EOS network.
If in your game the players reaction speed plays at least some role, then EOS is not suitable for this game.
Scatter nodes and half of EOS Block producer nodes are blacklisted in Russia. Users will have hard times connecting to EOS network from there. It will require a decent knowledge of what is the reason of the problem and how to set up a VPN to make everything work smoothly.
Contract storage cleaning is a cumbersome task. I’ve spent a lot of time on storage cleaning functions. It should be noted that you need to implement a complicated logic of storage cleaning, test it and debug it because you can only clear contract storage from inside the contract. If you will change some data structures then the contract will fail to update/clean it and you will be forced to roll back the contract to the previous implementation, clear the storage, then update a contract again and then re-initialize data structures. Clearing large data structures will exceed the 30ms transaction CPU limit and it is necessary to make the clearing functions iterative.
The game contract can not update its state on its own. It’s impossible to tell the game to update its state once per X minutes. This is the main problem of EOS which makes it unsuitable for most types of the games.
The only way to update a contract is to call its action with a transaction. The only way to schedule a transaction in future in EOS is to submit a deferred transaction. In theory it could be possible to schedule a deferred transaction that will invoke an action of the smart-contract, that will schedule a new deferred transaction and so on. This could serve as a cyclic update of the contract state, however the official EOSIO documentation states that “you should never design your application based on the determenistic execution of the deferrred transaction”.
I was running my game with a cyclic updates at EOS mainnet and I can say that cyclic updates stop whenever a certain network congestion occurs. In my particular case, the contract stops approximately once per week.
From EOSIO documentation:
It turns out that EOS is not suitable for continuous processes and this is my main concern.
In theory we can set up a watchdog server that will keep an eye on the contract that needs to be updated repeatedly. Whenever the cyclic update fails to execute the watchdog server can invoke the contract again. In fact this raises a question: If we still need a centralized server to make contract operating then why don’t we throw EOS away and just go with a standard client-server arcitechture?
I am a game designer. Why should I consider using EOS?
Honestly, there is only one reason for considering using a blockchain-based development platform for the development of a game. The reason is built-in monetization system.
This is a decent advantage to keep in mind. At the other hand, EOS has a number of serious disadvantages. The main disadvantage of this platform is the lack of transaction scheduling possibility which makes it unsuitable for the development of a wide range of “decentralized applications”.
In addition, building a game on EOS will increase the complexity (and costs) of the development a lot. EOS introduces a lot of additional restrictions and security concerns to deal with.
EOS vs Ethereum
I was developing Ethereum smart-contracts since the very first days of Ethereum and I can say that I’m really familiar with all the shortcomings of this platform.
I am glad to see that we now have a better alternative. As I’ve already said some time ago, EOS is an important step in smart-contract development area and it introduces a number of essential features that Ethereum lacks:
- C++. In fact, there was absolutely no reason to invent a new programming language for the development of smart-contracts, if there are time-tested, ready-to-use alternatives supported by reliable compilers and a set of tools. Solidity is a mistake.
- Upgradeable contracts. This is a major security improvement. Writing error-free code is impossible (if you are developing something more complicated than a primitive calculator). Thats why you need the ability to debug/upgrade your contracts.
- Free transactions. The problem of micro-transactions is an important problem for each blockchain. The problem has no solutions apart from fee-free transactions. EOS solves this.
- Communication model. Ethereum ERC20 tokens lack event handling mechanisms. This means that all ERC20 tokens are insecure by default, and this already leads to a huge loss of funds for the Ethereum community. It seems that Ethereum will never solve this. The problem can only resolve with a newer platform with new standards and development practices.
- Performance. EOS allows to build programs. Ethereum is so slow that using loops is an antipattern there.
A couple of words about TRX
While I didn’t like TRX, now it seems to be the second largest smart-contract platform. I can say that TRX addresses some issues of Ethereum and at least it is a working smart-contract platform.
I’ve seen plenty of smart-contracts developed on TRX and we audited some of them in Callisto.
There are some DApps that have a live user base. WINK is worth mentioning (however 95% of the value of this DApp is its beautiful UI but not the core mechanics).
I’m not a Solidity fan and I don’t see any value in EthereumVM, but the GalaxEOS game I described can be built on TRX.
And a couple of words about Cardano (ADA)
There has been a lot of talk about ADA in the past. Although its idea was promising, we still cannot develop smart-contracts on ADA.
Conclusion
EOS
I can definitely build the described game on EOS. It is impossible to make it work independently though. I need a centralized server to maintain the contract and make sure that it will work continuously.
If I still need a server then I should evaluate the use of EOS compared to traditional client-server architecture. I can name the only advantage of EOS: easy monetization scheme.
(I will keep developing EOS contracts cause I’m a blockchain fan and I believe that the above mentioned problems of EOS will be resolved or a newer platform will appear to resolve this problems)
TRX
I could build the described game on TRX.
Ethereum, EthereumCLassic, ADA, CLO, UBQ, EXP
It would be impossible to make this game work on this platforms.