The night is lonely, barely any stars live to light your path during the Dark Days. You walk against the cold Winter winds, wanting for nourishment, for a place to rest your head after a long and tiresome trip. In the distance, you see a merchant's hut, adorned with lights and wares that serve as a glint of hope in the night, food, you think to yourself. As you approach, the store keeper beckons you to come near, but upon closer inspection, you realize the shop isn't functional yet, because the HUD doesn't work, and the items don't have functionality. You realize you're in a part Marcos is developing, and you damn it all because his shop isn't finished yet. You keep walking into the cold night.

Hello, it's Marcos.

This week, I assigned myself the shop system. Our game will have shops scattered throughout, where players can come in and spend their coins for beneficial items. This fun system isn't too complicated, but it has it's own issues, of course. I encountered my biggest roadblock so far at the very start, when I was deciding what type of data structure to use to contain the item data. I needed something modular and flexible, mostly so we can make items quickly with one system, but also so my teammates have an easier time understanding my work. After a *very* large amount of iterations with enums, structs, and the combination of the two in different ways, I settled on using Data Assets. Data Assets can contain the information necessary to make items quickly, AND they have an event graph, which can be used for our benefit if we need to. This will be used à la prefab: right click, create new, fill data fields, and you're set. Most of the functionality will be shared between items. For example, of course a +3 and +5 to roll item will have the same graph, but something like a "teleport to a random tile" and "swap tiles with another player" have the same functionality at their core with slight variations. I'm very excited for this system.