![image.png](https://images.hive.blog/DQmX78ru9TVDK3hS918GqTkMdSy3Ea41fKT8SKivxsxt5in/image.png)

I just finished my first crypto game today.  I am just doing some decisions on the math and some testing before I am ready to announce it.

I really enjoyed building this game as I ran across a lot of issues I had to solve.

The first is I don't do web development, I mean I know the basics, but I generally stay as far as I possible can from front end development.  This posed a major problem for me to going ahead and building something, but surprisingly I made a lot of progress starting from zero in a very short period of time.  I am very happy with how it came out.

One thing that was critical to this project was real-time UI. It wasn't required but I really wanted to do it as it makes the game a lot more interesting but it was the stumbling block for not finishing my first game.  I decided to shift gears and start this project as it didn't **depend** on real-time UI so I could add it in as I went along but I ended up making every element of the game real-time giving a lot of experience for my next game.

Every little detail in the game has real-time elements.  There are a ton of small details most people will likely never notice directly to make the experience better.  There is a lot of ticking behind the scenes to provide real-time data and allow elements to react and handle input with intelligence.  I'll be the first to admit the game isn't complex, it is in fact more of an idle game than an interactive one.  I still wanted to go the extra mile to make the experience better.

![](https://i.imgur.com/8iGsG77.gif) 

![](https://i.imgur.com/K4tydKt.gif)

One of the biggest hurdles is the main aspect of the game.  It potentially can send thousands of transactions more than once per block if enough users are playing.  I wanted to prepare for that situation from the start so it isn't an issue.  

I am using Postgres database to handle daily transactions and submit payouts to the blockchain at midnight UTC daily.  The biggest reason for this is the computational load of some of the functions.  One particular function requires looking at Hive Engine API to find all holders of the APE token.  While this is sub second while there are no holders of the token, profiling other tokens like STEM it can take as long as 8-10 seconds to get that list.  Like I said earlier, there may be two or more of these transactions per block, that's 16-20 seconds of computation in 3 seconds worth of block time.  This can add delays to the game when sometimes it is quick and sometimes there is a delay.

By maintaining the state of APE token holders in real-time I am able to do this update to hundreds or thousands of users in under a second.

Another concern to me was recovery and atomic transactions.  I put a lot of the important logic in stored procedures so I can process all game transactions for a single block in one transaction.  If for whatever reason the game engine has to restart, it pulls the last block processed in the database and starts one block later.  Under no circumstances will any transactions in that block be partially completed.  Either all transactions for that block are written to the db, or none.  Restarting just kicks off where it was without any worry about duplicate transactions.  This has the added benefit of making the error handling a lot easier, if there is any problem just restart.

I will be providing more information about the game really soon.  I could literally launch it in 5 minutes from now if I really wanted to.  There will be plenty of warning to get in on the game when it is ready.  I will make an announcement and give people at least 24 hours to get prepared for opening hour.

![image.png](https://images.hive.blog/DQmVGmoeNnVo9PxJTBYFz2xUuFHLvyJbDtyBay9y8iDFpbc/image.png)
    *Never go full ape!*

Posted Using [LeoFinance <sup>Beta</sup>](https://leofinance.io/@themarkymark/unique-challenges-building-my-first-crypto-game)