I want to start off this post by thanking my team and my mentors for an amazing four months. This project would not have been the same without them, and I'm very happy I got stuck with the people I did.

To reflect on the project a little bit, I want to highlight some mistakes I made that I learned to not repeat.

1. We used a Game Instance (GI) to keep track of our data. A GI is a library of variables, functions, and other data that stays alive throughout the whole run of the game. What this allows us to do is keep data alive that we needed for all scenes and levels: Player positions, inventory, currency, etc. What I did WRONG with this, though, is that I depended on it too much. At the beginning, using it for one or two things was fine, but I got overly comfortable using it to send data from the players to the level. What this did was cause a mess of spaghetti code that was not easy to decouple. Lesson learned, trust in the GI, don't depend on the GI.

2. I was using this GI to send information from the player, to the GI, to the board, then to the Board Shop, which is it's own BP. Big mistake! I did not realize this soon enough, but an easier alternative to this would have been to just... get a reference to the shop blueprint in the player character. It sounds very simple, and I might be remembering wrong, but I believe at the beginning of development something was barring us from doing this, so I didn't think to do it properly until it was too late. Lesson learned, just get references to actors in the level.

Those were my biggest mistakes. Here's a bit of things that I did well and learned they work really well:

1. Using player starts allows me to spawn and keep references to each player character more easily than already having them in the level. Technically, I could call "get all actors of class Player", but the resulting array of this function is not certified to have the players in order, which we needed to have for easy access of data. Spawning them with Player Starts allowed me to keep an ordered array of the characters without the need to reorganize them myself. This is something I will use in the future.

2. The inventory UI was almost perfect. The way I had it binded to each player's inventory array was one of my best ideas. This system allowed modular use for easy editing for either expansion, or other changes.

3. Data Assets! They're beautiful! A data asset is a big variable that can hold all sorts of variables within it. I made a Base Item Data Asset that had:
- String Name
- Int Cost
- Texture Icon
- ENUM Functionality
- Int Functionality Value 

What this allowed me to do was go all out on making items through children of this data asset, and fill them out with their unique information. Then, through the custom ENUM I made titled Functionality, I was able to call different functions based on a switch. Example: An item that gave you "+10" to your roll would have Functionality Roll Mod. A function was then called specific to this enum that took in the int Functionality Value of 10 and added it to the current player's roll. Pretty good, right?

Those are my highlights. I didn't have too much trouble, but I'm still happy for the trouble I did have, because it allowed me to learn concepts I otherwise would not have known of. I can confidently say I graduated with a lot more experience and confidence in my ability to create a game. I would not replace this adventure for anything.

From the bottom of my heart, to my team, thank you for everything.

This has been Marcos, signing out.