FEP - FINAL EVALUATION:

When I first finished my proposal, I was happy with it, but I sent it off to get some feedback on it. I did this to get improvements and to see what I needed to change. Looking back this helped my proposal overall as my work was already good but adding the improvements just ensured it was to a high enough standard. I got many suggestions and aimed to work on them all. Most of the suggestions were about my detail and working on explaining my ideas. This helped me work on the concise nature of my work. I would not change much about this approach, but I would have aimed to be more straightforward from the start. I believe I covered everything I needed to cover and I believe I expanded on the idea enough. 

I do think I could have been more concise and covered the same topics in fewer words. I could have done this while maintaining the same level of work but in a better easy-to-read format. This can be seen in my word count as I wrote over six thousand words. This was even a smaller amount than I started with as I worked on this at the end. Looking back I think I could have both saved time and effort if I worked on making sure each point was concise and covered well.

Looking back, I believe I did a good job planning the proposal, as I combined multiple past guides to ensure I was covering the problems I had. I did this to ensure I wrote my proposal to a good standard and that I was happy with my plan. I was able to use the plan while creating the proposal, and it helped me understand each topic. The only problem looking back on my proposal was the detail. I think I could have gone into more detail on the plan, which would have helped me stay in scope.

If I were to do this project all over again from the point I started, there would have been a few big changes throughout. First, looking back on the finished state I have now, I wish I had planned more carefully on what I would do each week and scaled back my developments. Knowing now that there are mechanics like the grenade and knife that I did not manage to get incorporated, I would remove them to have been able to polish the other mechanics I worked on. I would space out each week differently and make sure I have one clear goal for each week. 

Next time I plan a project like this, I will ensure I am starting with the most important aspects, so I can ensure they are completed. I think this proposal was on the larger side, comparing what I managed to get completed overall. This is an issue I would have liked to fix if I were to do it again. I would have been smarter and more assertive in my goals compared to how I was during this project.

There is a lot I would have kept the same, including the overall breakdown of each task including the planning, research, production, and reflection. I would have liked to make a complete time planner including days and weeks, so if I decided to do the project again, I would aim to include one. This would have helped me stay on track more. One thing I have learned more from this project is that if I can not get mechanics to work or spend longer than planned, I should maybe suspend it temporarily. So if I were to do the project again, I would make sure if I do not get a goal done on time, I suspend it if it is not the most important task. This would give me longer on the essential mechanics.

For the time planner, we had to create a detailed plan for each week, entailing what task we aimed to complete for that week. We had to create a plan for each week going over each of the targets, including planning, research, production, and reflection. For each week, we had to entail the tools we would need to get the work done. I made a time planner to keep a plan and I aimed to stick to this plan., I also had the plan of tools which I will review to see what I used and did not.

First I made all the weeks, but as it happens every time I did not manage to stick completely to the weeks. The first reason for this is the project not being on GitHub. This was a decision from Zak as he did not want to put the project on GitHub. Another reason for the game not being on GitHub is the size of the project compared to the GitHub file size limit. This issue led to a few missed goals and plans, the first being the fact GitHub is on the tool list. This means I did not hit the goal of using GitHub from the tool planner. 

Next, this impacted week 7 onwards as I had planned to get my mechanics implemented by then. In the planner, I had written down my hope to get the mechanics implemented by then. Unfortunately, this did not happen as the implementation happened in a later week. This changed the order of a few steps and added a bit of confusion to the project. I was working on creating a pack of all the assets I had made and sent it in an updated version every time I changed something.

In the time planner, we had written down our ideas and what we had hoped to create. This was to help us understand the idea and what we hoped to create. I feel we overreached in the idea, as is evident by what we got to complete. This is another aspect of the plan, as the weeks reflected what I had hoped to get done. This issue mainly fell into two camps, one being getting it to work with multiplayer, and finding the research for each mechanic. A good example of this was the idea of each gun being different, which is not the case in the final game.

The main reason for this is the series I found on making a multiplayer FPS being lacklustre in terms of information. After the video on shooting, there were no more videos on anything, including reloading and creating different shooting effects. The other series had slightly more information, but I did not have time to incorporate it all, and it was hard to ensure it would all work together.

The general opinion on the proposal was good. Most people saw what we were trying to do, and we had clear and precise ideas. Other than being slightly generic, we got mostly good feedback. From this, we decided to add the grapple to the game to add to the diversity. This was an idea from Mitchell, Kyle, and Alex. This helped us differentiate our idea from other shooters on the market. We got a ton of feedback in the initial stages, which was helpful in development.

For my planning, it happened in a few stages. First was the original idea of what we planned to get done. To start on this, I looked at what I needed to make for our idea and wrote them down. This was to help me to get an understanding of what I had to create, which will help in the research. Looking back, this was helpful for the initial stages as it helped me understand the tasks I had to do. This elevated my research and later planning.

Google Form Planning:

After that, the next stage was planning my Google Forms. These would be my first part of research, along with the basic mechanic research. My main aim with this was to get a basic understanding of what to ask in the survey. It was also to ensure that my surveys have relevant questions on them, pertinent to the project at hand. This helped me greatly as I managed to get two complete surveys with mostly great questions. These gave me a big insight into what I needed to develop and what players expect to see.

While I was evaluating the planning of the Google forms, I did notice a few issues. First, there were a few questions that came to the same conclusion. An example of this is in the second form with questions seven and nine. In one, I asked if the game should have music in the game or not, and in the next I asked what parts of the game should have music. These both achieved the same results and looking back, I could have just made one question and got the same results. I could have planned a bit better and ensured one hundred per cent that each question was adding valuable information. So if I could do it again, I would improve on this and ensure that each question was unique.

MoodBoards:

Next, I worked on making mood boards for menu planning. Here I created a mood board for each menu using a wide selection of games gathered from my Google form research. Here I got the selection of games and separated them based on how similar to the game we are making they are. I would create a mood board for each topic on each side. This would help me understand the layouts, colour choices, and style of each menu, both similar and not. My intention for this was to help me develop a style for the menu concept. I created a mood board layout that I would later change, and I made some planning for the colours. Looking back on this initial part, I could have reviewed my mood board layout more, as it turned out to be a bad layout. This was due to the area not being large enough for the images, so I later changed it. I could have saved time by planning its layout more carefully. This would have saved time and made a better layout overall.

For each part of the menu, I broke them down into a mood board. After this, I searched for an image from the current game that fit that part of the menu. I created one for each style, both similar and not. I am happy with how this turned out as I got a selection of images for each menu section including both styles. Furthermore, I even sorted these into parts based on what features were found in the images. This helped me understand what was great about each image. I got these categories from the Google form I sent out where I asked what features people look for. I wish more of the games had menus based on online features, but this is hard to control as I was being hit on the chosen games. If I were to do it again, I would try to find some games of my own choice or find some based on web pages ranking game menus. This would have widened the selection, aiding the problems I had.

FlowCharts:

Next for the planning I worked on creating the flowcharts. I created these to help me understand the mechanics I had to make and to showcase how they would work to others. This would ensure a viewer can understand how the mechanic worked as well as my team. I created a flowchart for some of the many mechanics I had to create. Looking back the flowcharts are mostly true, some mechanics changed but most stayed the same. Some mechanics got more complicated than I originally planned, but most stuck close. A good example of this is the grenade flowcharts, as the grenade and its controls were a bit more complicated in the final version. Looking back there is not much I would change as the issues only changed based on the production.

Showcase Planning:

Lastly, for planning, I worked on planning the showcase. Here I aimed to detail my plan fort what I hope to showcase in the final product. Here I went over what I hoped to show and how I would present them. This was added later as I got feedback from a tutor detailing some changes to my blog. Here I wrote down the tree ways I had in mind to showcase my additions. I am happy with my plan and looking back I do not think I would change much. 

Google Form Research:

The first form of research I did for this project was the Google form research. In this primary research, I created two Google forms to get a ton of information from my peers. This would give me an insight into the actual audience the game would be getting. Looking back on these, I am happy with the results of my surveys, as they gave me insights I could have not got from Google. I found out many things, from the game's gameplay style to the most important parts of the game. The only thing, looking back, I would change is the wording of a few questions. On a few questions, I did not gain anything from them because of the similar format.

Target Audience Research:

Next for research, I looked at my part of the target audience, the cost of the game. The team and I all looked into one part of the target audience research to get a grasp of the audience, with mine being to look at the cost of the game. I analysed the games similar to ours, comparing the prices of each one. I looked at a wide range of games, from main triple-A games to indie games. Furthermore, I did this to get a range for the research which I am happy with. I would not change much even if I were to do it again. End to ensure no bias in prices, I looked at reviews to see if the prices correlate to the reviews. While I did not get tons from this, I could see the big game worth a lot was getting bad reviews because the content did not match the price.

I am happy with my analysis of each aspect as well as looking at the reviews. I wish I could have done more in other research aspects, as looking at the real world gives accurate information on the industry. I believe there was maybe more I could have looked into, but I am happy with the results.

Music And Sounds Research:

For the next part, I looked at the music and sounds for the game. In the end, I did not manage to add any music or sounds I did research the music and sounds for the game. I looked at examples of music and sounds from similar and non-similar games. To start I used my other research from Google Forms to get a list of games to look into for the music and sounds. I analysed songs from certain parts of the games and compared them I looked at the parts of the songs and analysed the soundscape.

I am happy with the results from this, as I managed to analyse many songs and sounds. Furthermore, I got sounds for the items I was creating and found relevant research. I believe I could have maybe done more research, but I got a good deal of videos. While there was only one for each effect, they included many examples. Looking back, I would have potentially found a few more examples to add to my work.

Video And Article Research:

Lastly for this type of research, I looked into some videos and articles on games in our game genre to find tips and features that add to the gameplay of that game. I analysed videos looking at the information presented and taking notes of what works for certain games. From this, I gained a lot and found a great amount of useful information. Looking back I am happy with the total research I did on the videos but I wish I could have used more of it in the final product.

For the articles, I looked at a few articles going through them and looking at the information presented. From there, I aimed to gain data on the audience and look for improvements our games can make. Looking back I managed to get a good look at data made by the writers, Looking at how players play the games presented. I would not change anything about my approach and I am happy with the overall amount of article research I did.

Game Engine Research:

For this part of the research, I looked into the options for game engines and coding languages. The aim of this was to look into the reasons for our choices and compare the available tools. This would aid our decision in what engine to use and inform our research. Unfortunately, I did not do this at the start and this was a part of our feedback mid-way. This did mean I had already started using tools but the research didn't change the tools. This means looking back I would have done this at the start and will do it in later projects.

I looked at each engine and compared them critically, looking at their features, strengths, and weaknesses. I did this for a few engines, looking at their prices and their engine power. Furthermore, I compared the graphics and tools available to decide on the best one for our project. Besides, I believe I looked deeply enough as I analysed many aspects. I compared the aspects between each other to find the best for use. Using these I made a choice, and I am glad about it looking back. I do not think this project was possible in some other engines, so Unity was the best choice.

After this, I looked into the available languages for the engine of choice and the available tools to program in. For this the only available programming language for Unity was C# so there was not much to decide from, although I did research the history. Then for the tools, I researched into Visual Studio because it is the main tool for programming, especially in C#. I am happy with this tool as my choice as it has many add-ons to make coding easier.

Overall:

Overall I am happy with the complete amount of research I managed to do and I am glad I got a good variety of sources from videos to articles. I am happy that I got both secondary and research in different forms and evaluated them based on what I got from them. I think I could have gone quicker on my google forms as some of the questions were redundant. But overall looking back I do not think any of my research was wasted in terms of learning.

I believe looking back I could have foregone the video and article research. Even though I learned a lot from them I did not manage to get much of it implemented in the final product. If I were able to do the research again I would have tried to get it implemented better or not do it at all. I would approach some of the research slightly differently as I could have done it more efficiently. If I were to do it again I would ensure I spend a day on a topic and once it was done move on to the next.

Creating The Gun Items:

To start this project, I went with the obvious step of working on the shooting. For week five, the first week of my production, I decided to work on the initial start-up of the shooting scripts by creating the item class structure. I managed to get the very basics, but not much more. This leads to my biggest regret being just how much I was unable to get done. 

Now, this is because I had some unexpected issues, but I could have done better to avoid them. Looking back, I should have communicated better and asked my team more about some of the issues I was having. I wish I had demonstrated and shown more of my work to improve the mechanics.

For what it is, the system works well, and I am happy with the functions so far. The equipping works and the player was able to load all the weapons in the list. But because it was only at this point, I had to do even more work in the later weeks, pushing back my progress. I feel this is one of the biggest contributions to my struggles with time management. As it pushed me back, it started an avalanche effect, getting worse week by week.

From this process, I learned a lot about the initial architecture of an item system. I learned about how to properly structure a system like a weapon system and how to lay it out. From this, I will be able to access this skill in the future. This can be used to create a lot more than gun systems and I can see it being useful for a ton more. I believe this benefited the work as a whole as it eventually allowed each gun to have different properties without a ton of scripts.

Main Menu & UI:

The menu was a big part of week five, as it took a lot of the time that I had hoped to put into other parts of development. This is due to a ton of problems that I faced while making the menu, mostly stemming from team communication. There were a lot of disagreements in the team and I felt like my opinions were being overruled too easily as it seemed everyone else was the ones we had to go with. I feel like when people asked for me to change aspects, even when I gave reasons why I should not, they just said to do it. And when I asked why I had to change it, they blamed it on the communication on my part.

This is partly true as I think I could have done more communication, but I was demonstrating the menu through the process and did not encounter complaints for a few days. If I had done this, I could have avoided the menu change, but I still feel it wrote off a lot of my research and planning. I am still happy with the final menu, but I wish I could have had more of a say in its style as I was working on it.

For the menu I made before the team changes, I am was with the work I did, even if it did not see through to fruition. I managed to keep the main menu simple and I created all the buttons. While keeping it simple, I got all the required mechanics included, and it worked well in Unity. Another benefit of the menu before the team decision was that it aligned with the mood boards I made in the research weeks. I was happy with the style I made, and I even added the green selection colour I outlined in the mood board, again utilizing the planning. 

There are improvements my team added that I was grateful for, as getting more yes on it is a good way to improve. An example of this is the white text, which looking back looked better and worked better as a whole.

For the Settings menu, I enjoyed having the environment blurred, as it made it easier to focus it on the player. I preferred the style of keeping all the menus similar with a background just blurred compared to the new menu. Looking back, I would have liked to add more animation to this menu, as it would make the menu smoother. This would improve the players' experience using the menu.

Now for the end of that week, I was changing the menu with the suggestion, I feel it was a worse time overall. Not only did it make the menu take a few days longer as I had to make a lot of changes, I think it led to a worse product. I still like the menu looking back, but I prefer the old menu. I think what this shows the most, is that you can not be too personal in these productions, because the team has to decide as a whole. To improve from this, I wish I had just got more opinions, so the team could have made a more informed decision instead of going from our personal feelings. I need to improve on this in the future and will aim to do so.

I do feel that as the menu was my job, the team could have left it more to me. In a real game design team, the concept artists would determine the entire look, with only feedback changing a part slightly. From now on, I will make sure to take these practices in and look for more feedback from people not in the team. I hope this will lead to better products and production weeks in my future work.

As a whole, I did not learn much technique-wise as I have made countless mnues before and they are really simple to make. However, I spent my team researching in hopes of ensuring a polished final workpiece. I have improved in this aspect from past projects as I made sure to analyse what makes a menu good to look at and go through.

Throwing System:

The throwing system was next aspect I produced was the throwing system in the first part of week six. I made the throwing system for the grenade and the flash-bang but did not implement them yet. I am happy with the underlying throwing system and I like how it works with the throwing setting. Furthermore, I wish I could have included the system in the item class I made previously. Looking back, this would have made the system work in the final product and if I had learned more I could have done it.

One of the biggest problems I have with the system is the lack of customization, as I did not manage to add any customization for each throwable. I aimed to get this done in week seven, but I never did. Looking back, I wish I did manage to do this, and I wish looked more into it. This would have improved the grenade system and maybe allowed it to get included in the final game. I am glad I spent time tweaking the systems as I managed to get a good feel for each throwable.

I learned a lot about how to make a throwing system. While I learned a lot most of the systems are aspects I have done before. Most of the learning came from how they got put together. going forward I can use these skills to make similar systems as it is an easily expandable system. He is the video and was able to use it for knives and grenades, so I can see it is very useful for any throwing applications. I was able to get this system done quickly and I am happy with how well I stuck to the plan. I had aimed to do something different but this was still required.

FlashBang Implementation:

Next, during the same week, I managed to get the flash-bang implemented as well. Most of this was getting the item to work on the throwing system. I made the flash-bang mechanics so that if the player looked at the object, then they would be blinded. Looking back, I like the flash bang, there are some problems, but it is my favourite throwing weapon. I am disappointed that it did not manage to get incorporated into the final game.

The main issue I have with the flash bang is the fact is it does not work how I intended it to. I had the one of it being infective if the distance was too great. Unfortunately, I did not manage to get this done. If I were to do this again, I would spend time researching a way to create this effect. Looking back, I do not think it would have been too hard, but it would have added a lot to the project. I do love the fact that obstacles block the effect, as that does help mitigate the first issue.

I did manage to get this done quickly, as I got it all done in the same weeks as the grenade. This did help me improve my time management as it got me closer to being on track with my goals.

Grenade Explosion & Physics:

For the grenade itself, I managed to make it react with the physics object in the scene. As I did not create these mechanics, I can not say much about the steps, but I did look over the code. I am happy with the result of the grenade physics but wish I could have made it myself.

Making it myself would have helped me understand the mechanics and learn new parts of game development. I wish I had the chance to do more research on this, but I had to make sure it worked with the system I had already made. This would have helped me gain new skills and made me better overall. Going forward, I aim to do a better job of ensuring I understand everything about the code I add.

For the grenade effect, I enjoyed making it, as I managed to get a complete effect to work in the final scene. I managed to use the visual effect graph to make a complete grenade effect. I added it to an object and finished getting it implemented.

For the actual grenade effect, I am not the most happy with it, as it is not a fit for our game style. I could not find many videos on how to create the effect I wanted, but I believe I could have done more experimentation to find a better look.  Looking back, I would have changed the final effect to make sure it looks closer to an actual grenade explosion. I wish the mood boards I made had had more impact on the final effect, as it would have improved the effect and made it fit better.

I am glad about my new skills in the Unity visual effects graph, and I am glad I chose to use this method over the other options I had. This is because I believe it will be the main way to do this in the future of Unity. Furthermore, I believe I hit my aim to learn the new tools that I had to use to achieve this effect. Looking back, I would not change the tool I used, even though am not the most happy with the final look. I think I could have got it closer to the actual look of a grenade.  Moving forward, I will look more into using the visual effects graph in more projects.

Adding Assets:

Throughout the week I managed to add some assets' whether it was buildings or weapons. The process always stayed the same as a few objects like windows. For the actual assets in Unity, I am happy with their incorporation, and they look as if they are intended from the versions in Substance Painter. I did not run into any issues when adding most of them, but the plasterboard has some slight issues. This mainly was the problem of being able to see through the object slightly.

Another issue I faced was the scaling of the items. As I did not make any of these models, I did not know the intended scale made by the modellers. I wish they could have had a more consistent scale. This would have made the process easier and simpler on my side. Again I will call this under team communication as I could have asked them to make sure they are all relatively scaled. From now on, in future projects, I will make sure to ask if the models can be kept at a consistent scale.

Game Testing:

For one of the weeks, I managed to get some testing done for the game. I went on with the team and played a few rounds of our game. This was to help Zak gain some new information on the project and know what to improve. I also did it to help me understand what need fixing or improving, which it did help me do. 

The testing proved very helpful l as it helped me find issues in the multiplayer test, allowing Zak to understand the bugs and what he should aim to fix later. It has also helped me get a better understanding of what the game looks like and what we have so far. This helped me understand what was missing, which I later added in.

For the grenade system, I believe this testing improved the overall feel and made it much more like an actual grenade. I did the same with the flash bang, making that overall improved too.

Gun Switching:

For the gun switching, I managed to get the gun to switch either by the scroll wheel or the number pad. Although I coded it in the gun switching being second in multiplayer never managed to get it into the final game.

I am glad I managed to get both methods of weapon switching in, including the scroll wheel and the number keys. Looking back, I would not change the methods I chose, as I think giving the players many options is the best choice I could have made. This is because the audience gets to decide on how they work the game. 

The main problem, as I mentioned above, is that the syncing did not sync in the final game. This is one of the parts removed by Zak as it did not work with his version. I wish I could have got this to work, but it is not the most important feature.

Gun Shooting:

For the gun system, I made a complex infrastructure of item and gun class scripts. I managed to get guns that dealt different damages as well as different fire rates eventually.

The biggest problem I had with this system was how complex it was. As the code had multiple paths, it was hard to understand for a first-time project like this one. Looking back, I would have gone for a different one and found a simpler one overall. The series I was following ended around this point in the system, but I feel more parts should be added. Many aspects are missing, like reloading and fire rate. Looking back, I wish I used the other series for the mechanics. This may have led to a better, more thought-out system.

The main reason behind me picking this as the series I followed was because of the infrastructure of the gun item system. I do like this aspect of the item class, and each one has certain aspects, but the rest is missing. I do not believe the structure makes up for the lack of necessary features. This series did not go on further and did not cover aspects like reloading, which I wish it did. So, looking back, I wish I could have added more to the system and improved the final product. So, moving forward, I will make sure to analyse closer and make demos using both systems. This will ensure I can tell the downfalls before I have no options left.

This did teach me a ton about the class systems ass I had used them before but not to this level. I did learn a lot about multiplayer syncing but I never got to see it in action. I would have liked to do the multiplayer side but it would have been impossible in the time frame. I hope in the future to advance in this area and improve as a whole. So moving forward I will aim to develop my skills and ensure the systems work with my own eyes.

Incorporating My Assets:

At the end of the FEP weeks, Zak and I went about putting the scripts from mine into his. Here we faced a massive issue we did not see coming. This was an issue of both production and communication and could have easily been avoided. The main reason behind this was in the beginning we found two series going through the same process and I thought me and Zak was going through the same one. But it turns out we had both used one of the current ones from each other. This led to a ton of issues last minute trying to get our things to work together. A ton of the work I thought he was doing was not being done, and instead, he was making a completely different script. This led to us having to find and download some scripts from the series I was following to get my stuff to work. 

We as a team should have communicated better as a team to make sure we are following the right series for each other to make sure our work is compatible. Looking back, I should have taken that lead and asked what series people were following. This would have ensured we were all on the same page and made this step easier. While Zak and I got a good amount of our work done, we had to add and override a lot of our work with the new scripts to get things working. The reason we are doing this is to ensure a good final product and make sure it works better as a whole. I also believe that towards the end he removed some of my code by commenting on it which got it to work in the game scene.

Written Work:

I am really happy with my blog and I believe it is a step up from the previous work I have done, and I am proud of the work I have done overall. I managed to hit the goal I had and write enough for each part. I wish there were written more in-depth, especially on some written work on certain week's reflections, but I still did enough to get my aims completed.

I did hope some of my written work was more unique, as a ton of it is derivative as I reflect similarly each time. This is nearly impossible to hide, but I believe I could look more into writing styles to improve the work overall. I am happy with my reflection overall, as I got a ton of information on it and tried to evaluate my work on it. I tried to ensure I looked at what I did and evaluated if I could have improved it and what I would do differently.

My Mechanics:

For my mechanics, I am happy with what I managed to produce, although I wish I could have expanded on the systems I made. I got the complete list of game mechanics I aimed to complete, but I wish I could have expanded on them. I managed to get the shooting done, but I aimed to complete the system to an expanded stage. Looking back, I did not hit the aim I made in my proposal. I aimed to have each gun work differently, especially on the sniper and rocket launcher. If I were to improve, this would expand on the shooing and add features like bullets and bullet holes. This would have made the game even better and given more player feedback. This would help the player understand what is happening in the game rather than being in the dark. I would have liked to expand on the system and add a reloading system and fire rate. These were added by Zak, but I would have liked to make them. I would have also expanded on these, leading to a better-feeling game experience.

For the grenade, I am happy with the system, but I did not manage to get it implemented in the final game. I would have liked to get the grenades working and affecting the other players. This would have expanded the game, giving it a more defined feeling and making the gameplay less repetitive. The main reason I did not get this done was that even if it affected the health of other players, it would not show on their screens. Looking back, I wish I had learned more about syncing, in photon so the grenades could be included in the final game. This would have improved the final product and made my efforts not in vain. The same goes for the flash bang, as it is a part of the same system.

I am happy with the menu I made and the total experience I had. I got this into the final product and made sure it worked, but the menu has features that do not work in the final game. Looking back, I wish I changed some features like the volume control to ensure the experience using it was as simple as possible. This would have made the player have a more enjoyable experience playing on the menu. There was also a switch-up on the menu, as the team decided to change the menu during the week. I did not learn much, as I have made menus before, but I did learn about Polish and making the menu as nice to use as possible. This included transitions and button animation, which I am happy with. Moving forward, I will use these in further projects as they improve the menu feel.

Final Game:

For the final product, we managed to make one online game mode for our first-person shooter. We managed to get shooting moving and grappling into the game. We got the overall idea for the free-for-all we had planned, but we did not get to add the other mode we had planned. I think this is a good showcase of our over-scoping during the project. This is also a showing of how we did not manage to fully meet the proposal as we had hoped to get the two modes in. I would have also liked to get the grenades working in this final product, as the final game is missing these. I believe the product reflects the proposal, but it is missing a ton of the content we had planned. Looking back, I wish we had made a less complex idea so it matched what we produced.

I am happy with the final product as I can join the match and play against other people. I am also happy with the shooting, although I wanted it to be more complex. Furthermore, I think what we got was a reflection of our skills and our improvements. I would have liked to show off more of my skills in the final game product. To improve on this, I would have added more complexity to the gun system and made it my priority. As the grenades did not make it in, I think, looking back, I would have removed these from my plan and focused on the shooting mechanics. I would have done this to make the final product more polished with the sacrifice of scale. This is because, in my mind, the polish is more important for the player's experience.

Mechanic Showcase:

For the final video, I am happy with the video I made showcasing the mechanics and I believe it is a good standard of work showcasing my project. I believe this was the best method to showcase the mechanics independently, giving each one a separate time in the limelight. Looking back, I am very happy with the outcome of this video, as I added music and transitions to ensure it was good to watch. I showcased all my work, which led to a complete showcase of my skills. I could have maybe spent more time editing it, but it would not have got much better. To get feedback, I sent the video out to a few people, and they enjoyed the choice of music and watched the whole project. This feedback pluses the final product has met my hopes and is a good showcase of the final work I made.

Gameplay Video:

Lastly, for video products, I made a video recording of a round of our game. This was to showcase the game in action rather than the static mechanics like in my other video. This type of product is the one most people will want to see as it shows the actual final product rather than just a part of it. The main issue with the method looking back is it does not show much of my mechanics compared to the other videos. This is instead sacrificed for a better method of presentation in total. I am happy I did this as I believe it will add to my blog and showcase our final project completely. Moving forward, this will be the main way to advertise and showcase my games other than just letting people play them. 

Code Repository:

To show off the code, made a repository of all the scripts I made during the production. I decided this was the best way to show off the code I made directly, in case anyone wanted to read it. I still showed my mechanics off, but I also wanted to showcase the actual scripts that I wrote. Looking back, I am glad I did this, although not many people will be interested in reading it. This is because it allows me to look back on it and make sure I am on track for improving. I believe I will do this moving forward for other programming I will write, whether it is the whole project or just the scripts.

Now that I have finished the project overall, I am happy with the outcome, although we did not get the exact final product we had hoped for. Looking back, I do wish we could have finished the project to the standard we had originally planned, but there were many unthought-of issues, leading to a lesser product. I am still happy with what we got done, as making a working multiplayer experience is still a hard challenge, and we managed to get that. I think we over-scaled the idea from the start and should have spent more time ensuring the final product would be one hundred per cent achievable. We could have made only one game mode and thought of a simpler set of mechanics, but I am incredibly happy with what got done. Taking this into account, I hope in future projects to ensure the first goal is, making sure the scope is set in stone and achievable.

I am happy with my progress, as I made entirely new mechanics and learned a lot of new tools. I am happy with what I learned about the VFX graph, as it is a tool I have never used before. Furthermore, I aim to pursue it further and use it more in later projects. I am happy with what I have learned about making shooting mechanics, and it will be helpful in future projects. I believe what I have done in this project will come in handy in later work. Looking back, I believe I have developed in my speciality of programming and improved a ton compared to how I was before. I learned a lot more about class structures and scriptable objects, which will aid me in the future.

In the future, I hope to improve further in my programming and aim to learn new mechanics and features. I aim to work on more projects using these tools and advance my skills. I aim to improve each year and ensure I am learning something new. Furthermore, I will stay on top of new tools and software to make sure I am up-to-date in my work.