Using Destiny 2 as a reference, I first began by creating and actor component to attach to both the Player and the Enemy to calculate their health. I later created a duplicate with slight alterations for calculating the shield amount of the Enemy. Both components use event dispatchers to send a message to their owner when damaged that cause a color change on the mesh or display the UI (for the Enemy and Player respectively). On the Enemy blueprint, I added a toggle-able ranged attack that targets the Player and uses the Enemy's attack and attack rate variable.



Next were the creation of the Enemy Stats struct and data table. The Player Stats struct and data table are again a duplicated variant of the Enemy version minus the attack rate variable. Once I exported and imported the csv file to have the ability to edit outside of UE4, I create a simple UI to display on the screen and show which enemy is currently spawned by taking the variables from the enemy actor. A health bar and name were also added to above the Enemy actor to confirm this as well. The array's are navigated with button inputs that can go in either direction in the array. Having this created also made the changing of damage types and Player stat blocks easier to setup later on.

Originally I had the array for retrieving these variables on the UI itself, but I soon moved them to their own blueprint that would not only load the next stat block from the data table, but also remove the old actor (if applicable) and spawn the next one. 

Finally I setup the shield actor component and the damage types for the Enemy. Since Destiny 2 is the reference, it looks for if there is a shield and if the damage type matches it before calculating damage done. Any overflow damage done is also applied to the enemy if the shield breaks. While it is still pretty basic, more things such as different actor meshes, materials, sounds, and animations could all be added to these data tables to rapidly test the different variables inside each row.

---------
Part 2

Now that basic enemies are created, I wanted to see how I could use data tables for filling out a shop that the player can buy items from. Initially I tried using a map as the variable in the struct but realized it just added a lot of extra work and left it as just a string and integer variable for Name and Price. Finally I took all of the variables and put them into arrays on the shopkeeper blueprint. I realize this is probably not the most efficient way of doing things and it would be better if the shopkeeper could instead just pull the specific items they want from the data table. As far as I could tell, that would require knowing the row names or having a document open to reference from which didn't seem like an easier option. In the end though, I ended up having a little bit of both.

Next, I placed a sphere overlap on the shopkeeper blueprint to enable the interaction widget on the player. When the input to interact is pressed: the interact widget is removed, the input mode is appropriately set, character movement is disabled, the cursor is shown.

After all that, the shopkeeper displays the shop widget. Having the shop window cover the whole screen is intentional, as the reference does so too. Rather than spend the time replicating the UI, I used these basic buttons because anything more complicated would be more UI design that working with the data tables.

The hardest part about all of creating the shops was actually populating them with the content from the data table. After trial and error of trying to make something efficient, I settled on displaying only three items instead of all items assigned to the shopkeeper. (This related back to the decision of storing all strings and integers on each blueprint.) The widget first finds which shopkeeper the player is in front of and storing a reference, it then checks to see if will display random items from the data table or a specific row (by using the index number) and stores these values into the widget. For using specific rows, the integers are public variables on the shopkeeper blueprint, but again the user will have to reference the data table for which index it will be using.

As seen above, the widget is organizing everything using a uniform grid panel. Each name and price text is using the "RandomItem?" boolean set from the shopkeeper to decide which index's to use and sets their text appropriately.

When a button is clicked, it checks the "RandomItem?" boolean and sets another integer that's used for calculations. Based on which button is pressed, it will then be able to find the item's price and seeing if the purchase can be made. If so, the player's currency is updated and the string is added to an array on the player aka their "inventory".

Now that I had a data table full of "items," I could then make an object that enemies drop which contained a random item from the table. When is overlaps the player it adds itself to the array of strings that acts as the player's inventory and destroys itself. Currently it is guaranteed drop, but in the future I'd like to add in a drop chance as well as make the "items" actually have an effect. 

For the experience points, I made a single float in a struct and created the data table. I then used a formula of "=POWER(2*[level] +2, 3)" to create the curve, copied those values to under the "ExperiencePoints" column inside Excel and removed the original formula. Keeping the formula in was of course breaking the import. I then got all of the values in the experience points column and converted them from string back to floats before saving them into an array on the player. This would make updating the EXP curve a lot easier if it should occur.

Lastly, I needed to update the struct and data table for enemies to include currency and experience points. On, death, it sends these to the player. On tick, the player checks to see if the float containing their experience points is greater than the entry on the experience points array and updates the level on the stat HUD accordingly. This is of course set to the loadout's level and experience points if a loadout is switched.

I had completely forgotten about the usage of enumerators prior, so here is where I am going back and making adjustments to the above code as well as implementing new things such as a pickup item that switches the player's damage type. I've given the damage types proper names to match the reference game and created an enum with each of them as well as a Normal option. This way I can have just a single pickup for switching damage types and use a public variable to change its effect and color.