Day 3 of "Building an Equipment System with Smart Contracts" for @ethgardlegends.
Imagine you find a cool sword and want to equip it to your hero to gain benefits in the game. That's what I'm building.
In technical terms, the goal is to allow items (ERC1155/ERC721) to be equippable on ERC721 tokens (i.e., Heroes).
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
tokenIdusually defines the item type (unless it's used to define NFTs via totalSupply 1). - In ERC721, the
tokenIdis unique per NFT, but the item type is separate.
Example:
- A sword with
tokenId = 0(first minted item) butitemId = 2(because it's a sword). - A shield with
tokenId = 1butitemId = 11. - Another sword with
tokenId = 3anditemId = 2.
All tests are now passing again after the introduction of the ItemSystem, which is a nice milestone.
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 optimizing 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 (once I'm happy with the contract size of course). 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.
Today's lesson:
Comments, comments, comments.
They make a huge difference, especially in smart contract development, where mistakes aren’t acceptable but inefficient code isn’t either.
Unlike in TypeScript or Python, where inefficient code is just a performance hit, Solidity has strict size limit, high gas costs and of course security risks due to the code being completely public. Comments help balance efficient code with readability, which provides security.
In my case, I was reading through some functions over and over again - code that got complex really quickly. Formatting it properly and writing well-structured comments made it much more readable and easier to work with.
PS: If you're having trouble understanding certain parts but want to learn more, try the AI feature on Peakd or ChatGPT/Grok to have it explained 👍.