As a user, I would like pick up items

[Jack-Saysana]

@zbostock56 @griffintarzan @GameShiba I'm not working on much of any item management, but much of the current sprint's larger features like #100 and #93 are reliant on a unified system of item simulation in exploration mode, so it might be good if we had a solid plan laid out so everyone working with item simulation was on the same page. Here are some of the ideas I had for how we can get everything to work:

Item simulation

item entity structure

• New exploration mode struct in chunk_str.h which can hold
  • item id
  • quantity
  • tile coords inside current chunk
  • despawn timer (at zero, item despawns)
• Each island has a list of these item entity structs
  • Perhaps buffer is fixed size, and once something is added, another item is forcibly despawned?
  • Simple, easy to implement, serialize, etc...
  • Malloced buffer is flexible but requires a bit more nuanced serialization and book keeping for chunk management
  • If you're real ballsy, you could even store these in a spatial data structure like a k-d tree or quad tree
  • Allows us to quickly coalesce nearby items of the same type into a single stack
  • Also allows for quick searching for prompts
  • Probably not necessary unless time allows
  • Dropping items would then consist of just moving an item from a container/inventory to the appropriate item buffer in an island
  • Picking up items would be the opposite: moving an item from the island buffer to the container/inventory

• Important note: Serialization will have to change to save and load the buffer of items

Item "containers" (chests, resource sources, treasure, etc)

• Right now, we have a single item container in exploration mode: The hard-coded home island container
  • Position is calculated during island initialization, with a random grass tile selected as the tile for the container
  • Not really a robust approach for resource sources, treasure chests, etc...

    Updated container struct

• Update the container struct in container_str.h to contains:
  • tile coords inside current chunk

    Containers/resources in exploration mode

• Perhaps during tile generation, we have new "container" tiles such as treasure chests, resources, etc...?
  • This implies a need for a container to be tied to each potential resource/container tile generated for a single island
  • Can get pretty expensive, even if number of containers/resource tiles is fixed per island
• Alternative: Perhaps resource tiles have no container attached to them, instead, interacting with an item tile or chest will spit out the item entities onto the island for the player to pick up, removing the possible bloat of numerous item containers
  • Harvested resource tiles are replaced with "depleted" variants of the tiles, which may refill with time
• Alongside the previous idea, perhaps each island can also have a very small, fixed number of special chests which contain items
  • Keeps number of containers small, but gives possibility for more varied interactions with items and containers
  • Ties containers to islands, rather than the current, disorganized method where the home island container is a global variable

• Again, these changes will also effect serialization and chunk management

  • For the flexibility of representing multiple different types of containers across the game, a container struct's items will have to be malloced and freed during chunk management/serialization

Once again, these are just some ideas so everyone might have a jumping off point for keeping things organized, since item simulation will touch many different areas of the game, and relates to multiple peoples' work this sprint.

[zbostock56]

@griffintarzan @GameShiba @Jack-Saysana

For the record, here it my plan as it pertains to item spawning:

For each island that is currently being rendered, we have a timer that is being run in the event.c file. This timer can be adjusted to change spawn rates. After the timer expires, an item tile that is located somewhere in the island will have an item spawned on it. If there are no free "item tiles", then an item will be despawned and replaced by a new item to keep an orderly policy of item spawning. Regarding the ITEM_TILE struct, there will be four things:

• TILE type
• REC_IDS resource
• unsigned int quantity
• vec2 position

The TILE type will contain the terrain type of tile such that the terrain can be rendered properly underneath of the resource. REC_IDS resource will contain the type of resource to be spawned at the tile itself. Unsigned int quantity will denote the number of resources that are located at that tile. Finally, vec2 position will store two things. Firstly, it will store the tile location of the resource by casting the values of the vec2 to an integer. Then, secondarily, it will store the "intra-tile" position of the resource within the tile such that the resource can be located anywhere within the tile without being centered all the time. Think about how items in Minecraft can be located at many different places on top of a block.

When items are being spawned, the number of items that are being spawned on an island is determined by the size of the island. The current numbers I am using to determine the number of items is I_WIDTH I_WIDTH 0.001. This means, if the island of size 512 x 512 tiles, the maximum number of items that can be spawned is 262 items. This doesn't necessarily mean that there will be that many based on RNG.

Other details should be fairly self explanatory in the code. If I change any of the numbers that I am using that I mentioned above, I will try to remember to update this post to contain those new numbers.

[zbostock56]

RESOURCE RNG TABLE:

Name	Value	Spawn Chance
Grain	5	30%
Cotton	6	^
Wool	8	^
Dyes	8	^
Sugar	10	^
Leather	12	25%
Cheese	15	^
Iron Ore	18	^
Wine	20	15%
Copper Ore	20	^
Spice	25	^
Herb	28	10%
Tea	30	^
Silver Ore	30	7%
Porcelain	35	5%
Silk	40	3%
Pearl	45	2%
Gold Ore	50	1.5%
Saffron	55	1%
Ambergris	60	0.5%