DANIEL HENSHAW / GAMES DESIGN FEP
When we started this project, we tasked ourselves with creating a multiplayer movement shooter called “Aftershock”. I wanted to show my skill, ability and ambition within the programming specialism. We wanted the game to feel fast-paced, intense and enjoyable to play for hours. In this evaluation, I will be reviewing our project in great depth. I will break down my personal successes, group successes and where we improve if you work on this project again or create a game with similar mechanics in the near future.
The time planner was a big part of this project. As this was a group project everything needed to be completed on time. If something wasn’t completed on time then it would cause the downfall of my peer too. This meant I had to work extra close to my time planner. This is one of the main reasons we decided to use Trello. Trello allowed us to keep track of all of our tasks. This allowed us to use an agile workflow. Agile workflows make planning and completing tasks on time much easier to conduct. We had to strip back our initial idea when coming into the project as we just didn’t have enough time to get everything we wanted to include implemented. This included a single-player mode, different game modes and multiple maps. We had a lot of feedback from our peers and tutors. Most of which were fairly positive and so we didn’t really make any changes to the idea other than the ones caused by time constraints.
We started our plan by creating a mindmap using Coggle.it. Coggle is a great tool we use on most of our projects. It allows us to visualise all of our ideas and categories them. As a team, we spent a few days brainstorming and conducting research into multiple areas we wanted to include in our project. We decided to split our mindmap into 8 main categories including; Game Features, Market Analysis, Sound, Level Design, and Promotion. After our initial plan on Coggle, we started to implement the main and most important features into our Trello to-do list.
Creating a mindmap is the simplest way of planning but works very well. Being able to visualise all of our ideas in one document is way easier to keep track of than planning using a word document. It also makes adding new ideas and features to the plan way easier while still making the plan easy to follow and understand. Using Coggle saved a lot of time and allowed us to move on to the development of our product early. In combination with Trello, I was able to split my development tasks into multiple sections which allowed for a smoother development period for the game.
Next time I create a mindmap I will most likely swap over to a tool called Miro instead of Coggle. Although Coggle is a great tool Miro is industry standard. By using Miro I will be able to get experience in software the industry actually uses. During the last couple of weeks of development on this project, we were told about this tool by someone working in the industry. If we knew about Miro before creating our plan we would’ve definitely used that instead of Coggle.
I have gained a lot of knowledge throughout the development of this project which I will definitely implement in my future projects. I have gained skills within unity ranging from inheritance and networking as well as outside of unity like using Miro and not over scoping.
In conclusion, I have loved the development of this project. I believe we have been successful in the creation and I have learned a huge amount about what goes into creating a multiplayer game. I am very happy and proud of what I was able to create even in its unfinished form. Now that this project is complete I want to keep researching different methods of networking such as steam. I would love for in the future to be able to release a multiplayer game onto steam. This project has inspired me to keep developing my skills in programming and eventually move on to getting a job in the industry. I am extremely happy with the outcome of this project and I can’t wait to develop my skills further while studying computer science for games at university.
We conducted our primary research around the time we were still creating our mindmap. We aimed to gather more information about the audience such as age and gender however, our main point of the research was to solidify some ideas we had but was unsure about. We also wanted to get a better understanding of what people liked about previous movement shooters. On top of solidifying our ideas, we also gained some inspiration for features which could be included in our game.
We had around 24 responses to our survey. This might’ve led to some inaccurate representation of what people actually wanted to see in our game. Another reason our data could be inaccurate is the fact the main place our survey was sent to was in fact our peers who have a very similar demographic which leads to less diverse results. This can be seen when looking more in-depth at the age range on our survey with the majority of answers being from under 18-24 year olds. 70% of our results were also male answers.
Next time we conduct a survey I would try to send it out to different demographics more. This would diversify the results leading to more accurate responses.
I researched a range of successful movement shooter games that included many features we wanted to include in our project. I wanted to get a better understanding of our Target Audience and style of game. I looked into the movement used in movement shooters which allowed me to get a better understanding of what our game needed to feel like in order to be fun to play. As well as researching features used in other games I wanted to research how to pull them off successfully within unity. This is why I also decided to research and create flowcharts for some of the important mechanics I wanted to include in our project.
I took inspiration mainly from Ghostrunner but wanted to include features seen in titanfall 2 as well. I really like the way Ghostrunners movement feels and wanted to match that to the best of my ability in the production stage of our game. I found an article and youtube tutorial about how to make great wallrunning and decided to use that as a base. From these sources, I was able to create a flowchart which helped in the creation of my product. I also created a flowchart to help me visualize how my networking code will work. I research the Photon PUN forums which gave me an idea of how to create a basic flowchart showing the checks and steps I would need to include in our game.
If I was to conduct my secondary research again I would definitely research more into Inverse Kinematics. My research on IK was very brief and conducted while in the production stage. I also didn’t include much research on Photon other than a brief look at how to create a join/create lobby system. Due to this, I had to search through the documentation and forum posts in order to understand RPCs and events.
The first thing I had to do for my production was to create a unity project and sync it over GitHub. GitHub is an amazing piece of software which allows me to easily push/pull data between anyone I was collaborating with. By using GitHub I could simply make a change and with a click of a button, James had received my updates remotely. As well as synchronization GitHub also acted as a backup and has a built-in feature to backtrack if anything goes wrong. GitHub was a crucial tool in the development of this project and without it, we wouldn’t have been able to create a prototype game as we did.
Before I started development I made sure that the Trello page was up to date with all of the tasks I needed to complete. I did this because using an agile workflow really helps out with time management.
After this, I started the development of my project. My first task was to create a room creation/join system. I used inspiration from my flowchart to get the basic structure of the system correct. While developing I ran into multiple problems with the system but managed to fix most if not all of the bugs. Throughout the process of developing the networking solution, I had to rely on a lot of tutorials, forum posts, and the Photon documentation. These three things helped me the most during this stage of development. This system for networking works very well however, Photon only allows for up to 20 players at a time. If I had done more research into Photon I would’ve known this earlier and used a different networking solution. Although at this stage 20 players are enough maybe sometime in the future it won’t be so using a different solution with the opportunity to play with more people would be better to use in the long run.
After creating networking I needed to make a working player system. Before starting this project I already had a system that would work within this game. This already had movement, wallrunning, and sliding. I converted all of the player code to work with my networking system. The reason I opted into using premade player code was because of the time limitation. I knew that having to code a full player system from scratch would take too long. This was one of the best things I did during the development of this game as it allowed me to focus more on networking. Although all of the movement was already premade I still had to make a lot of changes to the code. This included adding a player model with working animations, syncing data (animations, positions, and rotations) over the network, Inverse Kinematics and sound effects.
After creating a player system I started work on a weapon system. This system needed to be reusable. I decided to look into inheritance. This was new to me as I have never used inheritance before. I got started by researching how inheritance works within unity. By using this method I have created a very versatile system which I have also learned a lot from. I started by creating an item script which included a ‘use’ function. Each weapon script inherits from the item script which allows my input manager to call the use script from any weapon script. This is done by overriding the ‘use’ function within each script. This method allowed me to create semiauto weapons, automatic weapons, and with more development time projectile weapons.
Throughout this project, I believe my time management was very good. This was most likely due to the use of Trello. Although we were unable to finish the game I believe it is of a good standard for a prototype/development build. I believe the main reason our game was unfished was due to the fact of over scoping. We ended up with too big of a game idea for what little time we actually had to develop.
I believe we went above and beyond during the creation of this project but unfortunately, we were unable to complete all of the goals we had in mind. We successfully created a basic prototype version of the game we had planned to make. We included many of the features we wanted to include such as movement, networking and weapons. However, I was unable to complete weapon pickups and a win/loss system. Other than not completing everything I set out to complete I am very proud of myself. This is by far the biggest project I have attempted to create and I would class what we have so far as a success.
We received some great feedback on our final product. It was mostly positive with a couple of places for us to improve. This feedback mainly included polishing the mechanics, creating weapon pickups, and increasing visibility. These are all things we wished to include and fix during development but due to our deadline, we were unable to do so.