Hi!
We’ve developed a game prototype in Algorand two months ago, and we faced a number of challenges.
I want to check what is the state of these challenges today and if there are plans to address them.
No float and negative number support in Teal. We used a workaround for float numbers with multiplying every number to 100, but it makes debugging harder. Are there any plans for native support or a standard practice to follow?
No support for complex data types. Again we used a workaround to serialize objects to binary and store them and deserialize for reuse. Currently, serialization is not very efficient and uses a lot of gas which makes contract call expensive.
Very limited contract cost (execution) budget. Complex contract calls has a lot of computation and although it’s possible to make a group transaction to increase cost budget, it’s not practical to do so. There’s also a limit on program size (max 8 KB). For reference, look here and also here.
Mandatory opt-in for receiving every new Token/NFT. As games use a lot of NFTs, it doubles the transaction needed to receive a group of them. For example, 10 transactions are needed for receiving 5 NFTs. Is there a better way to do it?
Extremely difficult contract debugging. PyTeal is essentially a wrapper around Teal, and after you go into debugging, you need to face it. You actually need to know Teal inside out in order to effectively debug your contract, which questions the usability of PyTeal.
From my understanding, gas is not really a term used in Algorand. Algorand uses the term fees, which are very cheap per transaction. For instance, most Payment transactions require 1000 microalgos, which is less than $0.10 at the current market price. You can have one transaction in your grouped transaction pay for all of the fees in the grouped transaction.
Oh, thanks for mentioning it. I should clarify that I was referring to App computational cost limit which is 700 for a single contract call, which can be increased with group transaction.
I also forgot something else , which was the program size limit at 2 KB that can increase to 8 KB (still very limited for a game contract).
Yeah those some of the limitations of the AVM 1.0.
You could also create additional smart logic sigs or smart contracts that can pair with your main smart contract to increase the budget that way. You would need to include checks in your main smart contract to make sure that the other smart contracts or smart logic sigs are also getting called in a grouped transaction.
ApplicationCalls from inner transactions are probably going to be supported by the AVM soon, so that is something to look forward to.
Regarding the floating points support -
The main issue with supporting floating points is that the hardware implementation for these tend to be non-deterministic. This limit the AVM from using these hardware instructions.
The method that you’ve taken ( multiplying by a constant ) is a very common way to work around that exact limitation. Given that the AVM does support 64 bit integers, it could work well.
, which was the program size limit at 2 KB that can increase to 8 KB (still very limited for a game contract).