The ui style I went for derived from a fancy medieval red and gold to a transparent blue with a gold/yellow outline. It wasn’t particularily thought out or well designed but I tried to keep all the UI similar and in the same in style so it wouldn’t look odd. I used many sound effects to try make the game more entertaining and immersive although I didn’t make many special effects besides a singular quickly made explosion. I think the sound effects are a effective touch to make the project feel like a game and they are also very easy to implement.

I primarily used blender and unreal however I also used illustrator and photoshop to create images for my plan and also textures.
I also used google slides ans sheets to help with planning.

I encountered many problems although most of them I could solve and worked out in my devlog. However one problem I did not bother to solve was with the packing of the unreal project to a playable file. I debugged it unreal and completely cleared all of the packing errors and references however when packing the projects code would still be messed up. I created a temporary fix for this to record the gameplay video and other than the slight bugs caused from packaging, the game ran fine, and for me since I love tower defenses it was pretty fun trying to beat.

Most of the setbacks I encountered that I wrote about in my devlogs I would tackle by writing how I wanted to code it in a flow chart then re-creating the code to function better. And if it was debugging code, since I wrote all of my code myself and knew what was working, I could fairly easily trace back through the interfaces and blueprints using debug print screens to find the source of the bug.

What I learnt:
-Interfaces. Before this unit I did not really understand how to send messages and variables between blueprints however I think I grasp how to use interfaces pretty well and they were incredibly cruical in my development.

-Collision overlap. In unit 7 I was struggling with comprehending how the node worked and how to create the puzzle system. However I now grasp the concept that the node runs for every overlapped actor not just at once gathering them all. This allowed me to write half of the overlap code inside of the placement unit and also the units that were already in the level.

-Game instances. I don’t quite understand what they are yet however, I learnt that they can be used to save data between levels, for example the variables that held the data for what units to use in which slot in the game.

-Levels. I had not used levels before and I found out some painful things about them. Firstly opening them basically restarts the game and wipes all variables. Actors will not run code from different levels however actors like the character will need a way to run code differently between levels which I did in a shabby way of detecting the level name then setting a boolean if it was the correct level.

-Packaging. I learnt that this is a giant buggy pain and should be avoided or I need to learn how to refine the process so that my code doesn’t bug in the shipped version.

-Data Tables. I don’t know how relevantly efficient they are for most cases however these were key to my devlopment since I used them to entirely define the wave structure and every unit upgrade. They are cool as I can basically just input my planned values from google sheets then be able to access the variables of any wave of unit level in any blueprint.

-Sound effects. I had never used sound effects before however they were easy to learn how to use and customise with sound cues and are quick and fun to implement.

Improvements:
-I would have liked to have had the motivation and time to learn to animate and to have made the models and textures for the enemies but Im happy that I focused on mechanics since the gameplay (for me atleast) is fairly enjoyable.

-I think structures/ structs could have been useful as they store multiple variables in them but I didn’t learn what they are since I used tables instead.

-I would have liked to add more special effects lilke niagra particles and more projectile functions if I had more time.

Proud of:
-Im very happy with my outcome and I think I learnt alot from aiming for a fairly complicated project. Although I couldn’t hit the unrealistic goals I set I did accomplish the main mechanics that I was focusing on and my understanding of unreal has definitely increased.
-The game is fairly well optimised and un-buggy.

Time management:
I stuck to my planned gant chart amost esactly besides taking a on/off week break during the middle of the 2 weeks of easter.
I didn’t finish the plan when I wanted to but my reason behind that was because to plan something, I had to remotely know what I was doing first by testing in production. I would then refine the code by planning it out with a flow chart and then remake the code to function flawlessly in Unreal. I Started the review A week late but still did it In the planned time so overall I managed my time well and achieved above the minimum goals I set myself when thinking of this game idea.