This project has been an enjoyable challenge to work on as I've wanted to try to code multiplayer in Unity C# ever since I did it in Unreal for another project of mine. It is a good thing to learn from each project you do and with this one, there are a lot more things I had to learn when approaching this project, good or bad results either way I had fun struggling and succeeding in this project and that to me is what makes each game project great in the gaming industry, just like when games get a sequel it's usually better than the last because of the things learned from the first time.
I'm not going to lie the pressure I felt during this project was a lot especially when grouped with talented people. Because of their last project, which they did together resulted in a game that they published a few weeks later after their deadline, and their game was really fun and enjoyable to play, besides from a few bugs here and there. I tried my hardest to produce work that reached up to the standard of the team and ended up pushing myself too hard which ended up affecting the finishing product. Since this was an unknown task I was given I should have taken moments for myself to step back and assess the situation from start to finish, determining whether I needed to continue and take a breather to avoid burning out, but since I tried to impress the others I let myself get too focus into one task causing me to forget the other takes that still needed work on. Other than the pressure, the work was complicated to wrap my head around at first, but once I started to break the task down into smaller pieces by taking one task and breaking to down to see what I needed to do to achieve that task then breaking it further to see how to start working up to it, it became easier to understand how to complete a task or work up towards.
No, there are several issues I can bring up right now about it but the main reason why it's not fully finished is due to time and experience. I did not possess the experience to blast through the start and get to advanced parts of the multiplayer system as it was all too different from unreal, and learning all this to get what I have now took a lot of time than I thought.
In terms of planned features mechanics and modes yeah it was too much to do in a short period, especially since I had no experience coding multiplayer with Unity. I should have reduced the work that was planned into a much simpler and smaller job to do instead to dreaming big, that way it would have been much better in terms of quality and quality is better than quantity with these types of projects.
I would change the goal to be much smaller and aim to achieve a basic game mode going like FFA (free for all) and since I now have more experience than before I know what I should work on first.
How will it change the final product?
Implementing this approach will help to reduce the complexity of tasks, making them less intimidating and more efficient to complete. This method is better suited for a small team like ours, as it enhances manageability and coordination.
The main importance in my eyes for a game was being able to navigate menus to play the game, return to the main menu, and quit to the desktop because it made the game look more polished and accessible for people who wished to change basic settings.
Without a way to exit the game, the quality diminished. Because my mind was set on figuring out how to get two players connected, I could have utilized my time better by creating parts of the game that I had experience doing before attempting parts that I needed to learn to implement.
How will it change the final product?
By tackling the easy tasks It guarantees that main game features such as a menu system are ready to be used. This will also make it easier to decide what features are possible within the deadline.
Next time, we include Git to prevent any confusion when compiling scrips together. Using Git will allow us to identify fix and improved any issues with ease from changes that are made. It's a great way to keep everything in one place.
I'd also incorporate Unity version control to make sure all unity project so that all Unity projects are the same version to avoid errors when compiling scripts.
How will it change the final product?
Cooperation was improved and brought better quality to the final product as it allowed the team to identify and fix bugs at a speed faster than in this project.
I wouldn't have changed much about the team, I preferred to keep it the same since every member was very talented and we got along well as a group of friends who weren't afraid to give suggestions and workarounds for scripts that were bad. That level of trust went a long way. I would have changed Joseph's role to dip into the multiplayer side of things while handling the weapon scripting.
Why?
It would have been more beneficial if we had tried testing different ideas of code and made the weapon code more compatible with multiplayer. This could have also helped him get the grenades fully working, as working more with the multiplayer system would have helped him understand how to make an object viewable to others.
Additionally, keeping the team the same, now that we knew what to expect, made organizing easier since we all knew how the code needed to go together.
I made a time planner for the duration of the project which is 12 weeks that laid out tasks that I will be aiming to complete during that week and the equipment that I will need that complete the task.
The planner had the start dates for the start of the week and dates for the end of the week followed by the week number making it easy what task was upcoming and what week I was on. This was useful because I often lose track of what week I was on and referring back to what date I was on was easy to look at when looking at a calendar to check the start of the week and find it in the time planner.
The tasks could have been played out better as some stuff would have to be done later due to stuff needing its own system to be set up before the task planned could be started. This is mainly because I didn't know how the tool I was using (photon) worked fully but I'll get into that later in the evaluation.
In the situation mentioned below, If I had a separate time planner to use as a backup in case the current one fell apart too much. The backup time planner prioritized implementing the essentials such as a main menu (reason mentioned above), loading screen basic UI, and other easy-to-implement features. This way, even if the main task I was set to deliver was no longer possible, it could be reshaped so that the others' work wouldn't go to waste and would be shown working in the final product.
Unfortunately, I ran into some unexpected problems during the research and final product preparation stage of the planner that resulted in me falling behind the schedule, causing me to rush critical parts of research I needed such as surveys to implement and improve certain features creating poor quality code that hindered the final result I planned to achieve.
I followed the time planner as close as I could but due to a lack of information during research, I had to work on tasks that were different from the assigned goals on the planner which required further research at that time.
I could have asked my fellow programmers to see if they could spare some of their time to help me solve my issues to keep on track with my schedule or get ahead.
Why?
If I had done that it would have made a better opportunity to show the team the whereabouts i was with the project and the same could have been done for the other programmers as we are capable as mentioned (TEAM) of giving feedback and solutions.
I tried to reach out to indie game developers and industry developers through Discord or X (formerly known as Twitter), but this resulted in either no response or references to articles of other developers that specialise in multiplayer networking, using studio-level netcode that are explained in those articles that are too advanced for the method I plan to use.
If I did manage to get in frequent contact with a developer from the industry I would have asked them for advice and for solutions to problems I had in case they had some workarounds to fix them, I would have especially asked them for the best way of implementing a multiplayer system in a game that is easier with other developers working on other mechanics. With that advice, I could have tuned my code to be more compatible with others' code.
I organised with my team a playtest session to see how well the multiplayer part of the game functions to see key elements that are common in online games such as:
Connectivity
How the server handles players
Deplay
Lag compensation
Syncing errors
Crashes
I did get good quality feedback from my team members about the state of my multiplayer netcode through playtests and made changes that had a positive impact on the quality of the code making it run much more smoothly.
I would have sent public test builds and a survey to my peers; however, there were some reasons I didn't or couldn't.
Firstly, there was the possibility that the third-party server I was using (Photon) could overload and shut down because the server was only for small-scale projects. This meant that if there were too many devices connected, the server couldn't handle it and would shut down, which could have delayed the changes that needed to be tested.
Secondly, I did not have time to list out and investigate whether the issues were server-side, mechanical, or user-related. I needed data from the users, which required them to spend more time and effort than most normal surveys.
Example:
User 1: "Gun don't shoot while moving" - mechanic issue.
User 2: "My player moves on its own when someone joins" - Net code issue.
User 3: "It takes a long time to connect to the server and when I do everybody is teleporting around the map" - connection issue (reason being due to poor internet speed).
Furthermore, when a computer (running Windows) received a test build that required the program to connect to somewhere on the user's device, Windows Defender flagged the application as suspicious. This created an odd situation for me if people misunderstood the reason behind it.
Lastly, there was a chance that when the user tested the multiplayer, there would be nobody else testing the game at the same time, resulting in unreliable data and time that could have been put to better use.
I could have asked people if they liked games that's similar to ours and then asked for their time and planned a test date of a build that would be ready ahead of time for the volunteers to join play and find any issues with the multiplayer side this way creating feedback for core mechanics for gameplay for other members of my team while also gathering direct feedback and issues from the volunteers. When the playtest session is done a survey will be provided asking the participants how their experience was, creating valuable information as to what could have been changed.
This way I could have a group to contact again when testing new mechanics or changes to the server.
I set out to gather every and any bit of information I could that had to do with what goes into a multiplayer game, what common features are, and the steps it took for them to achieve their multiplayer system.
By learning the principles of what elements affect gameplay, I knew what I needed to look out for when setting up the multiplayer, such as prediction, reconciliation, and interpolation.
When looking at other games such as Call of Duty, TF2 and Overwatch all have common UI elements in them such as
Leader Board
health ammo count
kill feet
score count
name tags
kill screen
By looking at these and figuring out they are common in games It becomes a feature to strive to add to this project.
The research I used did not have much information to offer about the tools I was using such as photon as it was relatively new to me so I could have utilised it to the fullest. With this information, I could use it to adapt to the time planner to make more realistic takes that could be done for those weeks
Most material I gathered has been put into a miro board but left messy and disorganised making it difficult to find certain bits of information when trying to rush about or trying to show my peers what I had learned.
The next time I decide to use unfamiliar tools, I plan to research and understand the common issues that people have encountered while using them. By doing so, I hope to avoid making common mistakes and improve my chances of success when working on similar projects in the future.
Next time I use Miro for gathering research I'll utilise their framing feature and name each frame a name that fits the material inside of them such as "Menu design ideas", "common online features in games", and "developer article. This way it will be easier to find and identify research that I need in an instant.
I would use all my research material from this project and organise them to be clear and organised, then add additional material that I find worth adding on to.
Any tool I'm not familiar with will have its page of research material that provides information on how to troubleshoot and use effectively such as documents videos on common issues articles on problems and fixes.
I set out to make a multiplayer system where the user could boot up the game and play with others and have fun. To show off my coding and networking understanding and execution skills, and also to challenge myself by doing something I've done before but in a different game engine.
The thing I'm happy about this project was the multiplayer system, I managed to set out a task and do it, and that was my main goal for this project, to show off my programming skills and networking capabilities between two players, and compiling scripts altogether that would need to be reworked to be accepted into the multiplayer system, such as the movement scripts and weapon scripts.
I demonstrated my ability to think quickly and solve challenging problems, such as when I encountered a firewall issue while testing the multiplayer connection in a build.
I'm also now happy about how well I've managed to understand how it all works, so if I tried something like this again I'd be able to get the basic down much faster than I would have done this time.
Looking back at the results of our product there are some issues I have with it
We wanted to add so much more to the project like grenades and melee weapons but we ran out of time to get it all synced up, as the main scrips for the movement, grappling and weapon controller had issues with being imported to another project as some values needed to be reworked to be compatible with the final version of the project that had my multiplayer system running. There is a list of other features I wanted to add to the project such as:
Chat system: Creating a chat system would have made the game look more polished. There's a chance that as a player, you would like to play in a lobby, chat, and chill while having a friendly match with others whom you may not know.
Server list: A server list that shows the number of people in the game would have been a great opportunity for players to choose the type of experience they want in their game session. They could find a lobby with no players to study the map without disruption and practice as much as they like until other players start to join. Alternatively, they could find a lobby with players already in it and jump straight into the action with others!
Working game mode: Having a game with an objective, such as getting the most kills or points to win, gives the player a much clearer goal of what they should be doing. With a time limit or a score limit, it will push the player to be better than others, creating competitive gameplay.
I also never got a chance to put in a proper menu system for the multiplayer. Menus such as connecting to different lobbies, in case someone doesn't like the current lobby that they're in, they could always leave and go to another one with different game modes or the same but with different players. But I ran out of time and I was never able to do that but also I don't think I would have had enough time to do that anyway.
The research I used did not have much information to offer about the tools I was using such as photon as it was relatively new to me so I could utilise it to the fullest.
I managed to create a leaderboard, but I wasn't able to make the score counter work to track kills. I ran out of time to fix and test it. The score counter was supposed to do more than count kills; it was also going to track deaths, pings, and current KD (kill-death ratio). Additionally, if I ever plan to add a voice chat feature, there will be a button next to each player's name on the leaderboard to mute them.
I should have sent out a set of instructions of what needed to be a part of Mitchell's and Joseph's code before it got sent to me, like a preset code, a criteria that needed to be reached for it to be compatible with my multiplayer code, because all my problems started when our code was being imported and that wasted of time trying to figure it out and relearn their code was a big hindrance to most of our time.
So if I had just sent out a basic list of instructions of what needed to connect to what with my code, I think I could have saved myself a lot of hassle and trouble.
If I visit the Photon website, I can find numerous troubleshooting tips on how to solve minor issues like syncing. It's common to encounter such problems when using any complex tool. The website should have been the first place to look for solutions and explanations to the problems I encountered.
I should have taken some of my knowledge from using Unreal when making multiplayer games as I did the menu and code for that, and could have used similar techniques to have things in place for this project.
I should have managed my time better as I was too laid back, I was too confident and gave myself little time to fix errors.
There were some days that I didn't feel like coding when I really should have just pushed through and just did it because even a minute of time that goes by is crucial.
So next time I ever do something with multiplayer with another group, I'll have a list of criteria that need to be reached for it to work with the multiplayer side of things very easily, or I should ask for stuff to be commented with notes to say what part needs to go where and what it's purpose.
If I attempt another project like this I'm going to try and work on some templates to get some menu designs going and the next time I proceed to do something like this I'll be able to just click and drag menus at my disposal and choose any designs or create different designs that fit the current theme or game that we're going with. It'll also help the group art to save any jobs that I would have taken on time.
the next time I work with new tools I'm going to see what common issues people encounter with them so I'll know how to avoid making common mistakes with them
I will allocate separate time for social activities and work, allowing myself the opportunity to address any potential errors. If I had followed this approach, I could have contributed significantly more to the project, bringing it to a better state.
I will make sure the next time i start a project such as this will run it by staff that i may have to reach to fix problems that will can only be solved by them. Such as IT when i needed firewall access. This will prevent much stress and production lost.