Wolf
@wolfonchain
0 reply
0 recast
0 reaction
However, ran into a classic Solidity issue: contract size limits. Solidity contracts have a max size of 24.5kb, and after finishing the implementation, my contract was around 30kb, making it too large to deploy.
Spent a few hours optimising the code, trimming unnecessary parts, and reducing contract bloat. Now it's sitting at 23.5kb, which is better but still tight, since more code will likely be added. One thing that surprised me: events take up a lot of space - removing a single event saved about 0.5-1kb.
Excited to move into more practical development over the next few days. While contract development is great, it’s really cool to hook the contracts up to an indexer, creating tables that can be queried and displayed in the UI or used elsewhere. 1 reply
0 recast
0 reaction
Today's progress:
Finished the equipping/unequipping logic. Items can now be equipped to specific slots like head, chest, main hand, off hand, etc.
Most items have a single slot they can be equipped to (e.g., a helmet to a head slot). Others have multiple valid slots (e.g., a one-handed weapon can be equipped to the main hand or off hand), and some take up multiple slots (e.g., a two-handed weapon is equipped in the main hand but also occupies the off-hand slot).
Handling all these cases in the equipItems/unequipItems functions took a bit longer than expected, but it's now working.
Converting the logic from ERC1155 to ERC721 was also a bit tricky. In ERC1155, the tokenId usually defines the item type (unless it's used to define NFTs via totalSupply 1). In ERC721, the tokenId is unique per NFT, but the item type is separate.
All tests are now also passing again after the introduction of the ItemSystem, which is a nice milestone. 1 reply
0 recast
0 reaction
1 reply
0 recast
0 reaction
0 reply
0 recast
0 reaction
1 reply
0 recast
0 reaction
1 reply
0 recast
0 reaction
1 reply
0 recast
0 reaction
Todays lesson:
When developing smart contracts, it's critical to find a good balance between designing for future use cases and keeping it simple.
In this case, I decided against making the contract highly generic, as it would create unnecessary complexity and overhead. Instead, I focused on the three main ERC721 items: Weapons, Armor, and Accessories.
Another lesson is that it's better to refactor existing code if the design pattern could be improved - even if the tests are already written and working. Once the contract is live, even with upgradeability, modifying anything related to storage is either impossible, risky or requires migration.
So, better to think twice while still keeping it simple. 0 reply
0 recast
0 reaction
Today's progress:
Started designing the logic and data structure for the new contract and named it InventorySystem. Had to figure out the category for the items and the available slots, i.e., Main Hand, Off Hand, Head, Shoulder, Chest, Fingers, etc.
Continued developing the code for equipping/unequipping items and initially chose the existing ERC1155 contract for the new items (Weapons, Armor, Accessories).
After writing the tests and having a working first version, I realized that the items needed to be ERC721 instead - allowing for different stats, enchantments, durabilities, and more per item.
This led me to create another ERC721 contract, ItemSystem, along with new data structures for these ERC721-based game items. The items can so far be Weapons, Armor, or Accessories. The base code has been written, including the logic for minting these items (via Signature).
Existing tests will need to be refactored due to the items now being ERC721 instead of ERC1155. 1 reply
0 recast
0 reaction
1 reply
0 recast
0 reaction
0 reply
0 recast
0 reaction
0 reply
0 recast
0 reaction
0 reply
0 recast
1 reaction
0 reply
0 recast
1 reaction
0 reply
0 recast
1 reaction
0 reply
0 recast
1 reaction
0 reply
0 recast
2 reactions
0 reply
0 recast
0 reaction
0 reply
0 recast
0 reaction