Evaluation

Proposal

To begin, the proposal was built on multiple topics that conveyed our ideas for the project and what exactly I would be doing for the project. There were different word count goals on each segment of the proposal that I was required to meet. These segments included: 

Pathway preferred specialism, this was an explanation and small analysis of what my specialism in game development is and why I feel it is my specialism. The project concept is an overview of what our idea for the project is as well as my personal goals for the project. Project rationale which is a huge analysis of all of my past projects and an explanation of what exactly I learned from those projects that can assist me in this project. Reflection and evaluation which is a plan and overview of how I will be assessing myself throughout the project and at the end of the project. Finally, resources and bibliography will analyse how I will present my primary and secondary research of the project as well as how I will display my sources of research.

During the first week, I wasted no time in beginning to fill out the proposal. However, I immediately ran into a problem as I was involved in a big game jam at the time. During the week I worked through the segments and got stuck on the project concept due to the game jam. This hindered my ability to complete the proposal as quickly as I felt. This didn't deter me from completing it at a high level of quality though as I pushed through and managed to complete the entire proposal by the middle of the second week of the project.

 This situation could not have been avoided during this time as this game jam was personally essential for me at the time. However, situations similar to this can be avoided in the future by planning ahead and controlling my work schedule a little more clearly. I could do this by making sure that either I have no other major events going on at the time of a big project or by changing my schedule to work around multiple projects at the same time.

Another issue with the proposal was the concept idea of our project. I personally feel that we heavily underestimated how long it would take to complete all of the ideas we came up with, this is evident with the amount of mechanics and models we produced. While we got an incredible amount of work done, I think for the time limit on this project, the idea was just too long and had difficult parts of work to it especially programming-wise.

 Now that I have finished this project, I have learnt that next time, I could do better with coming up with ideas by calculating how long my roles will take with more consideration. This would be a big improvement as it would prevent any work being missing from the final product and could help with my time management throughout the whole project as well as my stress levels and motivation.

Time Planner

The time planner was an essential part of this project that allowed me to track what work needed to be completed each week and allowed me to calculate how far ahead, behind or on time I was throughout the project. To complete the time planner, I was required to properly plan exactly what I would be doing each week, and what software and equipment I would need to complete those tasks. I aimed to stick to this time plan and track whether I was on time, behind or ahead during the project.

To create the time planner, I referred to my proposal, specifically the project concept and analysed my role and goals of the project to create a plan of what I'll be doing each week. I also communicated with my team about their roles and my role to create a more effective time plan. I worked closely with my teammates on the time planner and by the end of week 2 we had all created our time planners. I was personally a little late on creating the time planner due to the lost time from the game jam mentioned in the proposal section. 

A problem that I did not anticipate at the time was GitHub. Usually with sharing projects, we would use GitHub which is an effective way of updating a project when multiple people are working on a game engine. However, for this project, we didn't use it as this was Zak's choice. There is also a file limit for GitHub so we may have not been able to use it anyway later in the project. 

Not using GitHub did cause some issues for me in the later weeks of this project as sharing my work with Zak was a lot more difficult. Instead of simply uploading my work on GitHub, I had to export my movement mechanics and my player object and send it to Zak manually. Doing this was a much more lengthy process and more complicated as I had never exported game objects with attached components before. I think the programmers of this project (me, Zak and Joseph) could have communicated a little better to come up with an easier compromise rather than having to learn something quickly which resulted in some time loss. Learning from this, I will make sure I communicate an effective compromise in future projects if a situation like this happens again.

Another big issue I had with the time planner, is that I hugely overestimated how much work I could do in the time frame of this project. My goal for this project was to create a movement system with animations and a functioning player model. I feel that all of our team members also overestimated how much they could do in this project as many things were missing in the final product such as my animations, some of the guns in the game are missing and the player model is just a capsule. 

The main reason I could not finish all of my ideas is because of the time frame which I heavily overestimated as well as a lot of issues in creating my movement mechanics that all together, resulted in a huge time loss. For example, on my grappling idea, I was hoping to create an automatic targeting system but there was very little to no information on how to create such a mechanic. I eventually had to drop the automatic targeting idea and remake the grappling system to have free targeting which I found a useful tutorial for.

Overall, the time planner had many issues for me during the project but was a good tracker for when I should have my research, planning and production finished. My main improvements for the time planner are to be careful with how many ideas I come up with for the project and consider the time frame of the project more deeply. My time management also fluctuated in this project so it is also something I need to work on by changing my work schedule to figure out what works best for me. My communication could be improved in some aspects such as ideas and software usage as we had some issues in these areas.

To create my planning for this project, I broke it down into a couple of stages to make it easier for me. The time planner was a big help as it contained all of my ideas for the project which helped structure my flowcharts and google form.

Google Form:

To plan the google form, I aimed to understand exactly what mechanics players want to see in advanced movement. I based some questions on my initial ideas in my proposal. Because I am doing movement, I aimed to ask certain questions based around different mechanic ideas and gain an insight on player opinions. I managed to form my questions in good time and released it as soon as I finished the form.

I also planned to create a second google form after I produced some mechanics. From this I wanted to gain feedback and find out what needs to be improved. To do this, I planned to have a video showcasing my mechanics in action. From this, the players can then give their opinions. 

I think this was an effective way to plan out the google forms for my primary research as it is aimed at my roles for this project and is detailed with relevant questions. Each question successfully gives me insight of what exactly players would like to see in my mechanics. The second form also is a good way to receive feedback which allows me to make necessary improvements. There is a couple of problems and improvements that could have been solved such as the animation side of my goals, I never made a form around this subject as I already felt a little rushed with the programming side. This links back to my mistake of overestimating how much work I could complete in this time limit. For the future I need to take extra care in coming up with ideas for projects as this is a major mistake that led to work not being done.

Flow Charts:

To help myself visualise how my code will work as well as how I would program it, I created several flow charts that visually show how each mechanic would work. The flow charts not only help me understand my code, it also helps other viewers as well as my teammates understand too, especially the other programmers who I need to work closely with. The mechanics I created in my production followed the flowcharts in general, some changed a little bit while some didn't change at all. One that didn't change at all was the double jumping as this mechanic was rather simple to make. 

Overall the flowcharts worked very well in guiding me on how my programs should work as well as presenting how they will work in a simple and understandable way for others. I do think they can be a little too simple though and I think they could have been improved by adding a few more little details in or adding another chart for another mechanic such as camera movement. For next time, I could analyse my flowcharts and code plans further which would make me able to add more details as well as more charts.

To write up my research, I looked into a few different topics, primary research which involved my google forms I sent out, secondary research which has YouTube videos and articles being analysed, technical research which is an analysis into game engines, controls and IDE's. Finally, collaborative research which was a group effort to look into different aspects of target audience. 

Primary Research:

Form One:

To begin my primary research, I looked at the plan I made for the first google form during the second week. I then wrote up my various questions which revolved around getting opinions around movement in games and looking for the players preferences. The results from the survey were very helpful and enlightening. I found that players generally preferred quicker and crazy style movements than realistic tactical style movements in shooter games. While I was already planning on making advanced movement, this did surprise me a little. The reasons as to why the players preferred this varied, from faster being more fun to always wanting to be in the combat zone and waste no time moving there. This survey also presented me with multiple mechanic ideas such as dashing and wall running which was something I should have looked more into as they could have been effective mechanics. 

I think the questions I asked in this survey were perfectly relevant to my role in the project and were effective at gaining a better insight to how I should be shaping my mechanics. The answers I received had a huge effect on my decision making for what I will be developing, I had to sum up each idea suggested to me and decide which ones are do able for me and which ones fit the project the most. I think this survey could have been slightly improved if I put some suggested mechanics first which would ask if players would put that in a game or not. This could solidify if the ideas I came up with are good for the project. Next time I will add a couple more questions that would ask about my planned ideas a little more and ask for feedback to the idea. This would give me a solid idea of the general opinion of the idea and whether it's good or bad.

Form Two:

I produced the second form around the middle to end of the project after I finished implementing my mechanics. This form aimed to gain player's opinions on my movement and to suggest any improvements. My questions were based around a video of my mechanics in action. The feedback I got was quite helpful but could have been better. I think this is due to how many questions I asked and how in depth I could have gone with the survey. For example, it was helpful as I had a lot of feedback for how to improve my gameplay, but I could have also asked if anything would need adding to the game such as the previously mentioned dashing or wall running. This is something I need to improve on for next time, I need to consider more questions to get more adequate feedback.

Other than that, I think this form was effective at giving me useful feedback for some little issues that needed resolving. It allowed me to fix some pretty minor issues and tweak the variables a little to make the gameplay feel more smooth. I also asked some preferences on some mechanics which I should have done in the first form, for example, I asked if the grappling would be better being free targeting or automatic targeting. While the answers to this were helpful, these are questions I should have asked on the first form. Next time, I will aim to ask more idea type questions in the first form at the beginning of the project and all bug fixes and tweaking type feedback for the second form to avoid mixing these questions.

Secondary Research:

My secondary research consisted of multiple videos of different games showing off the mechanics. I used this for each mechanic idea I had and looked into different games for reference as to how I would like mine to feel. I also looked into a article based around grappling and movement in games.

Firstly I looked at my grappling mechanic. I looked at two videos of gameplay from Spider-Man, Batman Arkham Knight and Gotham Knights. I analysed the details from these games and summarised which mechanics would be more useful to use as reference for how I want my grappling to look and play like. I took into account how long I think it would take to develop something similar, how well it would fit our game and if I think it would feel fun and play nicely. 

Next, I looked into the double jumping mechanic of the game and found some games to take reference from. I looked at how Genji works from Overwatch, from this character, I looked at how Genji has advanced movement mechanics such as double jumping, climbing and dashing. In addition to this, I looked at Call of Duty Black Ops 3 for a jump boost which works similarly to a double jump. These videos helped me greatly in terms of deciding how to approach not only double jumping, but advanced movement as a whole. I eventually chose to follow Genji's movement as I felt that I could follow other parts of his movement. 

These videos I looked at helped me in a variety of ways. They gave me new ideas to work with such as automatic grappling targeting and rocket boosting, I took these ideas into consideration against my current plan. These videos did affect my decision making to an extent as I had trouble calculating how long it would take for some of the mechanics to be developed. I am satisfied with the work I did here because it helped me greatly with solidifying my plans. However, this section could be improved, I feel that I could have looked into some other mechanics that I could look into to potentially implement into my game. Even if I don't end up using them, looking into them is still useful to me. This is something to do next time and learn from.

Phil Savage's Article:

I decided to look elsewhere from YouTube videos to look at why players enjoy a grappling hook and what makes this mechanic great. I stumbled upon an article written by Phil Savage which investigates the grappling hook mechanic in depth. He speaks about games he grew up with that featured this mechanic and why he enjoyed them. From that section, I discovered that Phil enjoyed using the grappling hook in combination. This made me feel more confident in using a pull and swing mechanic and my intention was for these mechanics to be used together. He also spoke about how movement is his personal favourite part of a game. 

After that section, Phil spoke about how sometimes the grappling hook can be totally ridiculous, as seen in the Just Cause series. From this, I realised that grappling needs to have some restrictions in a series game like ours. If not, then the mechanic would have likely been exploited and unbalanced. This is something I had to be careful with when developing as I had to balance the amount of restrictions to allow the mechanic to still be fun and not too underwhelming from restriction. 

Overall this article was extremely helpful towards how I should develop my grappling, as well as some of my other movement mechanics as this article helped me understand what players love to see in movement mechanics, especially with grappling. This entire article impacted my decision making in a positive way as I had to take a little more time deciding how to approach developing. I think next time I would benefit from looking through one or two more articles to get a little more information around the other mechanics I will be making. This would make me feel more confident in producing mechanics that players will love experimenting with.

Collaborative Research:

To aim at the target audience part of research, as a team, we decided to split the target audience up into multiple parts and each of us cover one area of it. My role in this was to research the average playtime in shooter games. 

To research average playtime, I looked into how long a average game of Call of Duty, Destiny and Apex legends last. These are 3 different types of shooters. I found that Apex legends lasted too long, Destiny dint have a time limit and Call of Duty was 10 - 15 minutes which was perfect for out game. 

While this research wasn't exactly essential for me personally, it was a big need for the whole group because the other programmers needed to know how long to make a timer for the multiplayer and the modellers needed to know this as a reference as to how big the map should be. If I were to do this section again, I'd try to get better references as most of the sources I found could potentially be not credible as they are wiki pages for some of the games I mentioned. This isn't great as there could be bias in there or incorrect information.

Technical Research

In this section of my research, I looked into some technical things such as game engines and IDE's. This involved looking to Unity, Unreal and Godot engine, this is to figure out which game engine would be the most suitable to use for me and the rest of the team. This was very important as we all had to take into consideration how familiar we were with different game engines, which game engine would run our game as well as which engine would be the easiest to develop our game with. 

In this research, I found that Unreal is superior with 3D projects which would have been more optimal for us, but some of us have little experience with Unreal, especially with me since I do not know C++. Godot seems to be a little new and can be a little limited with its 3D side. With Unity, we all had decent experience and know the engine quite well, Unity also has a decent 3D system that is easy to develop with.

Next, I studied how controls would work with the project. I looked into what controls would work best with movement mechanics. I found that the standard WASD is perfect for moving around and space should control the jumping. The only issue I came across was the grappling controls, I couldn't use left click and right click (which would have been the easiest) as those were taken by the shooting. My only other idea was to have these buttons customizable which would work quite well as different players may differ with preferences. Coming up with this solution did take some time and as a result, I spent more time than I wanted on this section.

Finally, I studied IDE's which are what software I can program in. This didn't take much time to look into as I was already set on programming in visual studio which is the only IDE I have good experience in. Visual Studio also works very well with Unity. We did have another few options such as using a blue print type addon which works with Unity. While I did do this section quite quickly, I think it could've been a little more detailed. For next time, I think I could look more into different IDE's and how they work with different game engines.

Overall this section has some issues such as the lack of detail in the IDE's and especially the time loss from figuring out controls for the grappling. These could have been resolved more quickly if I communicated a little better with Joseph around the controls of the game. This research was a useful insight to what other certain game engines do better than other engines, for example, Unreal has much higher graphical capabilities than Unity which makes it great for big 3D projects with high quality models and graphics. If I were to do this section again, I would look into maybe another game engine for a slightly more wider insight as well as look at some more IDE's which could prove useful for other game engines such as blue prints.

Research Conclusion:

To conclude my research, I think I did a good job at looking at a wide variety of information, from taking surveys to looking at the more technical side of game development and looking at how mechanics work in different games. I think my strongest sections of my research was the article I looked into and the YouTube videos I looked at. I feel that these segments helped me the greatest with solidifying my ideas for my mechanics as well as giving me a greater insight of how to program them for maximum performance and enjoyment. 

My time management during this time was a struggle as I worked towards achieving a higher work output during each week of research as I felt I was falling behind my time planner schedule. I was falling behind as my motivation during these times wasn't great, I attempted to fix this issue by changing up my work schedule to perform a lower amount of work each session I work but have more work sessions, essentially, this is little but often. I found that overtime this did help my time management and my motivation which helped me get back on track with my time planner.

Some improvements and additions I would do next time in my research is to add another form to my primary research. I think another form with some updated bug fixes and tweaks would have been great to get some feedback on, I would have done this if I had more time which links back to me overestimating how much work I could get done during this project during my planning. Another thing is to look into a few more games in my secondary research. This could have widened my view of how some mechanics work in other games as well as some additional mechanic ideas such as dashing. I would also have liked to have looked into more articles as the article I did look into, proved to be extremely useful to me in terms of how mechanics should look and feel.

My movement production was a bit of a roller coaster as I had multiple changes to make throughout its development. 

I first got started with a tutorial that presented how to produce some effective basic movement for a first person game. I got it programmed after a few days during week 5. I looked at the flowcharts I made as well as a tutorial I found which assisted me greatly. The flowchart helped me keep the goals of the script in mind and helped me structure my script. This was done in good time and I felt satisfied with how the movement felt. I came across my first major issue during this time that resulted in major time loss. The camera started jittering which happened when the player ran into other objects in the game. This took me too long to fix I think and was a frustrating fix, this added to my stress levels at the time which affected my motivation which then affected my time management in a negative way, this was like a domino effect. This then impacted my progress as I had to attempt to get back on track with my time planner. I did eventually manage to catch up and get further movement produced.

After I got the issue fixed, I didn't really come back to the movement until I encountered an issue with the grappling targeting system. This problem will be evaluated in the grappling production section, but the issue meant I had to reprogram my movement to follow a tutorial to do the grappling differently than planned. This also resulted quite the time loss but not awful as I had a tutorial I could follow as guidance. This greatly impacted my time plan as I essentially just restarted the movement which meant I had to almost rush to get the rest of my movement done in time for the next mechanics.

I created the new movement system that references the grappling pull and swinging scripts heavily, this is why I had to scrap the older script and reprogram the movement. This movement works even better than the last one and feels smoother. This is because this movement uses Unity's rigidbody physics in every aspect of the movement. This is something that I am happy with as this makes the movement feel so much more fun to play with. The flowchart I made didn't really come into use as much with this movement system as it is much more complex than I had originally planned.

After the movement was developed, I started the bug fixing later down the project, this step was a little frustrating as I came across some annoying issues such as the player sliding too much across the floor or the player sticking to the side of buildings. A physical material with low friction fixed sticking to buildings  and making the player a little heavier fixed the sliding issue.

I then made my second google form which aimed to receive some feedback towards my mechanics. In terms of the movement, some feedback I received was that the movement looks a little floaty, this was likely due to the gravity scale of the project which could be intensified to make the player fall a little quicker. Other feedback was positive and stated that my movement looks smooth and fluid.

Overall my movement was a great success for our game and in the final product, works nicely and still functions smoothly despite it going into a server. An issue that did happen was the camera starting to lag or seriously jitter when playing on the server. After some investigation, I think that it could have been that the camera was in an Update function and not FixedUpdate. FixedUpdate did improve the camera but there could also be a problem with the frame rate which could also be causing this. From programming the movement in this project, I have learnt many new techniques such as how to cross reference scripts at a higher level such as how my grappling and movement tie in so closely together. I have also learnt that there is so many different ways to program movement, from using transforms to physics, there are definitely some major differences between these methods that I could look further into in the future to improve as a programmer. My time management during this section of production was generally good as during the production I worked on changing my work flow which helped greatly with managing my time well. This was a good impact as I did eventually manage to get back on track from issues previously mentioned. This means that I did not have to rush further production on my other mechanics which allowed me to develop them with a proper mind and left no room for silly mistakes.

The grappling mechanic in this project changed quite frequently throughout the production period of the project, this was caused by different issues and a problem that I couldn't solve.

To begin the grappling, I followed the idea of making automatic targeting, the plan was to make a UI target appear when the player was looking at a grappleable object. I managed to program this in good time and found that the results were good. I was particularly happy with myself during this stage as I used my own knowledge to program this without any guidance as I could not find any tutorials or sources that guided me on how to do this part. I definitely learnt from this too as I now know how to use instantiate a little better as well as how to use ScreenToWorldPoint function properly which is how the image of the target is moved to the target object.

After developing this part, I thought it could be definitely improved as the UI placement was limited to the center of the object, I wanted to make the UI be able to slide along the edges of the object which would have saved me time going forward as I would have had to place an extreme amount of game objects to be targeted throughout the map. This wasn't great as that would not have been efficient and could slow the game down a little. I did learn though that I couldn't leave some mechanics being inefficient and should always make them as efficient as possible. 

This is where I ran into a major issue, since there wasn't any tutorials or sources that I could use to help develop this improvement, I couldn't seem to program this mechanic any further. I then had to make a big decision whether to keep the automatic and run the grappling inefficiently or restart the grappling and movement as I did have a tutorial for regular grappling. I eventually decided to restart the grappling and movement and follow a tutorial I found to develop these mechanics in a different way. 

Using the research I found with the tutorial, I began programming the movement, grappling pull and swing systems. I kept the article I found in mind which affected how restrictive I programmed the systems. The tutorial carried me through developing this section and I eventually finished coding it. During this, I learnt some very complicated things such as calculating force and using anchoring components on the swing which allows the mechanic to function like a proper swing. 

After this, I received feedback from my second google form, in this form, I found that there were positive feelings towards my grappling system as it looked "snappy and responsive" as well as smooth. To improve the grappling, I was suggested to restrict the swinging a little more as it sort of outshines the rest of the grappling by being the player's faster movement tool. 

Overall the grappling is one of my favourite parts of our project, the smoothness of the grapples and swings feel really enjoyable and make the game feel fast and has a sense of chaos from this. Some problems that I had while developing the grappling was some overshooting and undershooting issues on the pull. This was caused by some values in the script being either too high or too low, specifically the grappling speed and overshootY. My time management in this section was decent as my motivation was quite high during the grappling development because I felt great satisfaction and enjoyment while developing it. Despite having to restart the grappling and movement, I managed to recover lost time and finish the production of these mechanics but I did have to begin almost rushing this section to ensure that I could finish other mechanics I had to program. This could have negatively impacted this section as rushing code isn't exactly a great idea as it can leave room for bugs. An issue that could have been improved on for next time was that when the player tries to shoot a grapple below themselves, the grapple doesn't work and the script outputs an error. In the multiplayer server, this crashes the game for the player which isn't good at all. If I had some more time, I could have looked into properly fixing this issue. This again links back to my big problem of overestimating the work load at the beginning of this project.

The double jumping mechanic was a lot quicker and simpler to develop than the other mechanics I programmed. 

I started by going back to the movement script which contained the jump function. My plan at this point was to allow the game to track when the first jump has occurred, I did this by making a new bool. I then made another bool to track if the player has jumped in the air which is essentially the double jump. Then I tried to call the normal jump function again when the player should be able to double jump. This however did not work as I found the player either could not double jump at all or both jumps occurred at the same time. This issue was caused by the ground check game object being a little too small which allowed the double jump to occur at the same time. The reason why the player couldn't double jump at all was due to the program using the same jump function.

To improve the double jump and make it more consistent, I created another jump function that is exclusively for the double jump. This fixed the issue of the double jump working at all. Throughout developing the double jump, I learnt how to track events that happen in the script, and allow other things to happen after something has happened. This is why I had issues with the double jump at first as I had to learn this first. 

My time management during this part of development was good as I stuck to my work schedule and my motivation was high as I was nearly finished with all of the production at this point. I did lose some time during this part as the double jumping took a lot longer than expected because of the issues I ran into. This did mean that I was a little slower than I wanted to be which affected how much time I had left after this. I think I could have done this part faster if I did a bit more research into double jumping and find some resources to guide me on how to do it properly. This would have reduced they amount of time it took for me to develop it.

Some changes I made to the double jump during the bug fixing stage, was that the player could infinitely double jump, this happened because to reset the bools for the double jump, the script must read the ResetRestrictions function. This allows the player to do all the jumps again. This function is read after the player has finished swinging. If the player spams the swing button and tries to double jump, they can do this infinitely. To fix this, I made it so the jumps are only reset when the player touches the ground again.

Some feedback I got on the double jumping mechanic from my second google form was that the double jump synchronises very nicely with the other mechanics to make the movement quick and advanced. Another point I got from my feedback was that the second jump looks a little higher than the first jump. The reason for this is that the double jump needs to be high enough so the player can still reach the grapple target as sometimes the grappling comes a little bit short. If I made my first jump higher, then I think the player would be jumping a little too high. The flowchart and research I did create, helped greatly with creating this mechanic as the flowchart helped me structure how the program should work as well as translating the flowchart to code. I could have wrote some pseudo code to further help me. The research I put into Genji from Overwatch also heavily helped me create this mechanic as I used Genji as a reference as to how the double jump should look and feel.

Overall, I am satisfied with the double jumping I made, I think it works very well but some improvements could be made to it. I think I could have made the jump vary a little bit to make it more interesting. For example, if the player uses the double jump after a grapple, it could be a little bit higher or faster than a regular double jump. This would have been an interesting change to the mechanic and could help with some balancing. I do think I could have been faster developing this part which would have let me have more time to bug fix and tweak some mechanics for smoother gameplay. This also kind of links back to me overestimating the amount of work I had to do during this project which did affect a lot of periods of work I did.

To conclude all of my production, I am satisfied with the work I have produced, I think it portrays advanced movement quite well and it feels smooth and fun. I made many changes to the mechanics I created which did cost time, but was worth it in the end as the mechanics were heavily improved. A good example of this is the movement, it went from being pretty smooth to working in depth with the grappling and swinging and feeling even smoother. While this did cost a lot of time, I'm not sure if it would've felt as good if I left it how it was.

The grappling also went through some time costly changes but was also worth it as it feels brilliant to play with now. The feedback I got on all of my movement was very useful to me as it allowed me to fix some issues with the movement that I could not see myself. A great example of this was that the movement looked a little floaty, after turning the gravity scale up, the movement looked even better and more immersive.

During the whole production, I learnt many new skills and techniques in programming. During grappling I learnt how to reference scripts a little more in depth, this can be seen in the movement script which calculates some Vector3 values from the grappling script to calculate how much force to give the player and in what direction to simulate the grappling pull. During the swinging production, I learnt how to use anchors which I had never used before. While this was a learning curve, the tutorial I was following was a great help and allowed me to learn even faster. The grappling pulling helped me learn how to make physics calculations in Unity. While this is something that is incredibly difficult to do, it was heavily worth learning as it is something I will use in the future. 

My time management throughout the production varied a little bit. I found that my motivation and stress levels heavily affect my time management. I made several changes to my work schedule in an attempt to improve these personal skills and I discovered that a work schedule that allows me to work little but often works the best for me. I also found that if I'm struggling too much with one section, I'm better off leaving it for a little bit and work on something else until I feel confident enough to come back to it. A lot of issues did happen during production that did negatively affect my personal skills at the time such as having to restart the movement and grappling. I did have to almost rush these sections after this which led to some bugs, I did manage to fix these bugs during the fixing stages of development. I feel that as a whole, my time management fluctuated a bit but was overall good looking back on all of my production.

However, getting all of my movement into the multiplayer version of the game was quite a hassle. This was because we didn't use GitHub as this was Zak's decision. This made things a whole lot more complicated as to get my code to Zak to add into the game, I had to learn to export everything as a prefab and set it all up again in his version of the game which was quite complicated. I think that if we did use GitHub, this wouldn't have happened and moving things over would have not only been a lot quicker, but much easier too. I also had to perform many new bug fixes on this version as when the multiplayer was active, some odd things were happining such camera lag and jitter, not being able to see other player's grapples and other players appearing to lag. Some of this could be issues with Zak's server but I couldn't fix all of these issues.

Overall, my production went quite well as I managed to get all the programming that I wanted done, I also did the programming at a high standard and made sure that everything works without any game breaking issues or bugs. The movement is a great fit for the game and definitely makes the game feel really fun. I have learnt how physics can greatly affect movement in gameplay as well as just how important movement really is in games. 

To create my weekly logs, I decided to make a PowerPoint at the end of every week to keep track of what I have done during the week and if I met my goals for the week. If I was falling behind, I would make sure that I have logged it properly and explained why I didn't quite meet my goal for the week. Then on the next week, I'd make sure I catch back up.

I feel like these weekly logs were a big help with keeping track of the work I had done and what needed to be done and it worked well with my time planner. I think that they could have been a bit better if I reflected on them a litter further as on some weeks, I feel that I didn't quite reflect enough on them. Other than that I feel that the details I put on the logs were good and they explained exactly what I did each week very well. I logged each mistake and improvements that I was doing for my time management as well as for whatever I was doing that week.

Some issues I had with the logs were my time management. I found that I often fell out of rhythm when making them at the end of each week, especially near the end of the project as I found myself to be two weeks behind on the logs. This could have impacted how accurate the logs were near the end and this also impacted my motivation as near the end of the project I was feeling tired.

I have learnt from these weekly logs though, I learnt how to keep track of my progress a lot easier with these logs as well as keeping track of my missed goals and improvements I intend to make. Using these weekly logs is something I can use again for big future projects as I think they are brilliant for keeping track of progress.

Overall I feel that I have used these weekly logs to their full potential on this project despite falling behind on them. Falling behind did lead to some last minute work on them but I managed to catch up on them in good time. There is definitely some improvements for next time with time management specifically as I fell out of rhythm but this is something I am constantly working on to improve myself. Another improvement I could add is a deeper reflection as I felt with some that I didn't reflect enough. This could impact further weeks as a deeper reflection could mean better improvement on what I wanted to make better in the later weeks.

My Mechanics:

For the mechanics I made during this project, I am happy with what I managed to produce throughout. I managed to get the movement working smoothly along with complex grappling and swinging which adds to the advanced movement feel of the game. There are many things I wish I could expand on or add to the game to make it feel even more fun such as sliding and dashing. I believe these mechanics would have made the game much more fun to play. Looking back at my proposal and ideas, I did not get everything done that I aimed for, particularly, the animations of the project. This is because I valued the programming side a lot more than the animations and I decided to get that done to a high standard first. 

 While I am extremely happy with the grappling, I could have expanded on the pull system a little more. I think I could have made it work a little smoother by instead of just launching the player, It could slowly move the player towards the target. I could even add a ledge mantle system where if the player was close enough to a ledge after grappling, they could pull themselves up. These ideas is what could have made the grappling feel just that bit smoother and fun. Looking back, I should have learned a little more about how my mechanics would have synced to other players in servers as my grappling had a few issues there as well as my movement. Some issues are that the grappling isn't synced properly, so the you can't see other players grapples so it looks like they're just flying through the air. The movement also looks a little jittery and lagged when looking at other players. 

Final Game:

Our final product consisted of a multiplayer version of the game that uses a server that players can connect to. My movement and grappling mechanics are present in the final game as well as Josephs shooting along with the free for all game mode. The other game modes however, are not present. My animation ideas are also not present as the players are just capsule game objects from Unity. I think this definitely reflects just how badly we overestimated the work flow as quite a chunk of our ideas from our proposal were not finished. I feel that if we carefully considered the work load, then we could have produced a more solid game that has more detail in the areas we did develop. I feel that my expectations from the proposal were not met in terms of things I wanted to produce in the project, but from the programming area, I am more than satisfied with what I've contributed to the game.

This doesn't mean the final game isn't great though, I feel that it plays really smoothly and is a ton of fun to play around in especially with friends. I think the movement I produced is a big highlight of the game and it definitely reflects my skills as a programmer and how far I have come during my time programming. Again to improve on the final game, I would have liked to work more closely with Zak and learn how to properly sync movement to make other players movements look a lot better and to have the grapple ropes from other players be visible. In a strange way, I am happy that I didn't waste my time on working on animations for the player as I feel that my coding heavily outshines any form of animation that I would have done. This is because I prefer to see more polished functions in games and my programming skills are much higher than my animation skill.

Mechanics Showcase:

To show off the mechanics of my game, I made a video that all the movements the player can do in detail. This ranges from grappling to double jump around the map. I think this was a good way of showing off my mechanics properly as the viewers can easily tell what the player can do in the game and the full potential of how to move around the map quickly. While making the video, I added transitions and music to help make the video more interesting and ensuring it stays to the point. I made sure to edit it to the best of my abilities to properly showcase my skills I used to develop these mechanics. I didn't receive much feedback on this video as it was made when the time was nearly up on the project. The video does represent my aspirations and goals from the proposal in terms of the programming ideas I had and I am happy with how I have showcased these mechanics.

Gameplay Video:

To finally show off my mechanics in the final version of the game, I recorded some gameplay from a match with friends. In the video, I am playing the game casually and having fun. This video was target more towards everyone's final product rather than my own mechanics. This is to demonstrate that we have accomplished our goals from our proposals and can showcase how we have worked together during the project. While this video isn't the most useful to showing off what I have done, I think it's a great way to show off the whole project. This could also be a fantastic way to advertise myself in the future moving forward rather than just throwing people straight into the game and letting them play with no knowledge of anything about the game.

Code Repository:

To show off my code specifically, I made a code repository on GitHub which will store all of my scripts which I have used for this project. I believe that this is the greatest way to show off my scripts to anyone who is interested in looking more deeply into my programming work. While my mechanics has already been shown off, I want to cover all grounds in case anyone would like to dive into the specifics of how my code works. I am glad I did this as not only is it good for others to look at, its great for me to look back on in the future and improve upon the code I produced during this project.

Now that I have finished the whole project, I feel extremely happy and satisfied with what I managed to pull off. I definitely think I overestimated the work flow at the beginning which did lead to a lot of stress and lack of motivation. This heavily threw me off track with time management and keeping up to date with my time planner. All this then led to a lesser version of our game that is missing various features. However, looking back at our main goal, we aimed to make a multiplayer first person shooter game, which I think we absolutely nailed. Despite the game having missing features, I'm still extremely happy with the game we made as well as how I performed as making a multiplayer game is a very challenging experience. My next goal for future products is making sure the idea is certainly achievable which would avoid missing features in future projects.

I feel that I have made a ton of progress in my personal and industry skills in terms of programming. I am really happy that I managed to learn new methods of programming and learning how to program complex physics into mechanics. I feel that it was a big challenge to do and I feel very accomplished with what I  have done. Not only have I learned more programming skills, I now understand Unity a little better and can use more components such as the line renderer and anchor. All of these skills I have now learnt will allow me to improve upon myself further on with my specialty in programming as I feel that I can now program even more complex forms of movement in games as well as more complex mechanics. I could even try to develop more physics based experiences as I now understand not only programming, but physics itself better too. These skills will definitely aid me in the future and will be extremely helpful to me.

In terms of the future, I aim to further develop skills in my specialty and create even more complex and challenging projects which would allow me to learn even more mechanics, skills and tools in Unity and other game engines. My main goal when developing projects from now is to learn something new and improve myself. I will also attempt to learn new tools, game engines and methods of programming to become more diverse in how I develop games.