Project 2

Proficiency: For this main class project, I took up the role of programmer for the traps in the game. This was the first time I really got into programming stuff in a while but I was still pretty good at it. There were some points where I didn't have the best experience to fall back on, like with working with lerps (I was never able to fully understand how it worked), but I was able to use trial and error with trying different methods to solve the problems I was having, such as swapping around variables in formulas to see which works and get a better understanding of how it works.

The Unity C# documentation also helped me a lot, as well as forums such as the Unity Forum and StackOverflow from people who were having problems similar to mine. It was especially helpful in trying to troubleshoot an error such as errors like "cannot implicitly convert GameObject to Transform" and then actually getting it to click in my head when the Unity editor wasn't helping much at all. 

I also found some useful programming information in Michelle Menard and Bryan Wagstaff's Game Development with Unity (2014) book, including some things I didn't even know about, such as the various functions in the Mathf section of Appendix B: Common Classes (pp. 409). The same section also contains information on the lerp function, which I already mentioned I don't have the best experience with, so while I probably won't be able to put what I learnt from this book into these trap scripts as I've already finalised them, this is something I will be able to put into practice in a future project.

Process: I tried to improve the workflow of my programming by looking into solutions for solving problems I encountered when debugging scripts I created for the traps, especially with errors the Unity editor threw at me that I didn't quite understand. I found that the Unity documentation and forums such as StackOverflow helped me get through my issues. For example, setting up lerps in the dart launcher trap, I found that the Game Dev Beginner's The right way to Lerp in Unity (with examples) blog post by John French (2020) was a massive help in getting a baseline understanding of how lerps work and how to use them to translate the position of my dart over time, and to also realise how messy lerping in scripting can be, but at least it works. 

I did also try to look at some books that have sections on debugging in Unity, such as the Debugging section in Part 2 of Jeremy Bond's Introduction to Game Design, Prototyping, and Development (2017) book (pp. 425-440), but I found that a lot of the information shown in these books are either very outdated, with sections dedicated to debugging with MonoDevelop, a script editor program that the Unity editor has since scrapped in favour of Microsoft's Visual Studio, or information that I had already learnt from my current history of programming in Unity, which unfortunately includes the entire aforementioned Debugging section of Jeremy Bond's book.

Person: Even though I was a programmer, I found that I was not only communicating with the other programmers at times, but also the level designers. Firstly, there were plenty of times where I had to communicate with Ronan, the programmer in charge of the camera and player systems, to try and solve an issue I encountered when setting up my traps to work with his player controller, or even working together to fix an issue we found, like when the slow down effect of my poison darts was producing unexpected results so we had to work together to fix the issue in his script (the fix was to add a bool in his script to stop the player altogether).

Secondly, I was communicating with the level designers as well because, as per the order of operations in the team, I would have to hand off my traps to the level designers who were in charge of properly implementing the traps into their level, and I would make sure the level designers understood how to use the traps, such as with parameters I set up in the inspector component for the scripts to control various functions. I also sometimes had to work with the level designers to correctly implement the traps into the levels, and in the case of the Nordic level it was due to an oversight in the placement of the trigger and collider of the pitfall trap.

I didn't receive a whole lot of feedback for my traps, but I did receive feedback from the lecturer about the way I set the parameters for the dart trap in the Greek level. I set the darts to fire pretty much randomly, and the lecturer suggested that I should instead set them up to be in a pattern, which is something I didn't even think about but makes complete sense. Next time I take on the programming role and do something like the traps again, I'll consider this feedback.