playb3

Day 2 of building a smart contract-based inventory system for EthgardLegends.com on B3.

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).

Day 3 of "Building a Solidity-based Equipment System for 
EthgardLegends.com“ on B3.

Size does matter - in today's case:

✨ Smaller is Better! ✨

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.

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.

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.