Last week my team and I presented our game Titan Tussle for playtesting, this is my findings on our notes and feedback from that.
People found the balance of each character to be fair, each had their strengths and weaknesses (usually attacking created vulnerability) and most saw that teamwork would be required to successfully take down an enemy.
The main issues people had were:
Figuring out how to play (no one read the instructions, even when instructed to do so, it turns out everyone hates them and are then disappointed in the game as they did not know what to do) and players did not understand the objective of the game.
This means that players either need to be forced to read instructions (something very simple, like ‘Knock out the enemy team!’) or be showed some graphic on how to play a game, like a simple or animated image, or a simplified round. Pressing/holding the A button could be required to begin the game also. The original idea had the players choosing their character, where some of these options could be used to explain play to the players.
Players were unaware of teams.
Several set-ups were planned for the game that had not made it into this version yet, like the colour themes for each character reflecting their team and players choosing their characters (where each team will be displayed in this menu). Another brilliant suggestion was team colour outlines on the titan models and on their respective icons at the top of the screen.
They found the controls for the small titan confusing and found the small titan too weak.
The control issue was my own stuff up, I forgot to reverse the input value on their turning, which made them overly complicated. As for them being too weak, there are a few values that can be played with to fix this, like reducing the time they are busy attacking to be much more than the stun time and increasing the range of the stun attack. Another thing that will help is the visual feedback of animating the attack and adding some ‘swipe’ effects like you would find on a sword swing.
There are also some serious visibility issues that need to be worked on, like the difference between fading out an object so a titan can be seen behind it and destroying the object, and also how to better handle distant titans, as their abilities and facing directions can become hard to see when they only take up 1% of the screen.
This is my post-mortem of the project so far.
What went right
Team Management of animators and quality of work from the animators.
This was due to a great work ethic on their part and through great communication, we were able to figure out what the amount of workload they were each capable of. We set up a task sheet for them, with broken down goals and assigned tasks to them there, while passing out deadlines as we were made aware of them. We also assigned a team leader to the group of animators to help keep them on track.
Got a working game loop set up in time for the play testing session.
This is less than I have done in the past but is an achievement in the face of the struggles our project had leading up to it, namely multiple failures in source control and hours of work lost, and the hours of time needed to repair the project. I was able to prioritise the functions and mechanics that were core to the game through the intense development and iteration processes that our project had undergone in the previous 3 weeks and when I was lost, was able to go through the documentation that we had set up to help identify the next jobs I had to do.
The assets the animation team had provided also helped give me direction, as I felt it necessary to implement and show off all the work they had put into this project.
This shows why it is necessary during a project to have all hands possible take part in the design, iteration and testing processes, as it helps form the game in their mind and helps them create the game envisioned by the team, even when everything is failing.
What went wrong
Source Control, Documentation, Meetings, Team management of everyone else, Parts of code broken
I didn’t know enough about it to properly set up a new bitbucket project & didn’t think of that as an issue. This was a lack of knowledge in the tool and in the consequences, as I thought just setting up a gitignore file was enough. I failed to set up the file structure correctly, was not aware of the correct contents of the gitignore file and did not know how to set up the unity project either. What I needed to do was research the subject, or even go to a lecturer at SAE to walk me through it. Since becoming aware of the depth of this issue, I have set up a meeting with Ian McManus to help walk me through this problem and to also create a video of this process to be shared with my colleagues and anyone else who is struggling with source control.
Didn’t do anywhere near enough documentation, specifically a Gantt chart, risk assessment, failed to complete an HCD or GDD of good quality, and haven’t yet completed a TDD.
This documentation were planned to be set up and worked out as a group during face to face meetings, however, our team failed to show up to these meetings and the documentation either suffered or were never created. They further suffered from a lack of enthusiasm in our whole team for the project. We also suffered in communication, as the team leader it was up to me to push for our team to work together and get everything done to a high standard. I was unable to communicate with my team at most times and feared that pushing my team to hard would seem like I was asking for more than I was doing.
There was little to no team management from myself, attempts that I made to document tasks were not maintained and barely followed up, some team members are only contactable on facebook.
Due to a failure in source control, and not creating a local backup, and failing to save regularly, a unity crash lost hours of work, and when it tried to recover data some code was broken without throwing an exception. this meant that the main mechanic (titans knocking around other titans) was not in the backup build presented during playtesting.
In the future, working locally or through source control, I must stick to a schedule for saving and backing up data. I only missed the issue with the main mechanic being broken because I was very tired and out of time to work on the project anymore, but learning how to correctly use source control and saving more often should help to reduce the chance of such a bug getting past me again.