what went right
animator team comms
A google sheet was created for the animator team, including a milestone based task completion tracking system for all of the objects in the game, with each object assigned to a person. There was also a section for swapping out parts of said task (such as texturing). This was coupled with my overseeing of the team, implementing daily skype meetings and weekly face to faces to account for any setbacks, holdups and to allow showing off of each team members work. This was made possible by some team building exercises, such as working together on drawings, creating in-jokes amongst the team, or staying on the skype call together after a meeting to catch up with each other (only if they were available)
This can be replicated by working on team building exercises, making that a part of the time allocated in the time management, rather than only talking to each other under work conditions. This sort of thing seems to come fairly naturally amongst the games students, as most of our interactions have been online. In the past I have tried to stamp out most of the shenanigans, as they distract from the work at hand, on average taking between 30 minutes to several hours before people got back on task, but making time available for these things could prove very useful for team building. Even better would be to begin research into structured frivolities.
While it took us a couple of weeks to get around to doing it, this was the most documentation I have had a part in creating for a project. This was very helpful for defining our project, and just as it should, creating an HCD made a GDD and then a TDD much more possible. It helped to keep people accountable and on track. We found that the team members who took a greater part in working on the documentation also had a greater shared knowledge of what the game was, how it worked and what happened.
In the future, I would like to focus more heavily on setting up documentation, creating the structures around that and getting it all done earlier in the pipeline.
what went wrong
Most of our team were struck by sickness throughout our production time. While we had not set up a Gantt chart, it was easy to see that this was blocking others from working. We were unable to set up full group meetings and found this as an easy excuse to put off work like design, documentation, and build. Too much work was being placed on the shoulders of the healthy, who soon became exhausted or overloaded, lowering the quality and quantity of work being done. There were brief moments when we were all able to get together and complete large amounts of work, but this project was scoped for a healthy team who were mostly there the whole time.
Unfortunately this sort of risk, while easy to expect, is hard to accommodate. The result of this sickness is a reduction in available working hours, once you burn through the flex time and reassign tasks onto already overloaded available resources, the only thing you can do is reduce the scope of the project. Our project did receive this treatment, although it was not controlled at all. Tasks were simply not being completed.
A possible way of avoiding this in the future is to have better leadership in the team, and to plan out the scope of the game in a more modular way. The core game loop should either be extremely simple or not wholly rely on every part to be implemented to work. for example, our game was meant to use VR, and one of the goals was to make that optional. This was implemented and when I failed to get the VR working, the project did not fail due to that. It did fail though, as most of the other functionality was unable to be completed.
Lack of leadership
This was a huge issue. At the start of the project, we let a team member opt-in to project management, which I chose not to ask for, as I had been the project lead for every project so far. The person who became project manager failed to oversee the project or check up on any of the tasks. they were also in charge of time management. I failed to identify this earlier and take charge of this, despite being hinted into doing this multiple times. What needed to happen was that the project lead needed to complete time management tasks, with the help of the whole team and identify tasks that were behind, properly reassigning them as was needed. When tasks were not being completed, there needed to be follow up and when the project was falling behind the scope needed to be reduced.
Next time, Tasks need to be assigned within the first week of the project and the team lead needs to be reassigned the second the current lead fails. This is a difficult situation, as we all thought, every time, that this would be the last time, and that they would pull through or catch up by tomorrow.
Lack of motivation
With this sickness and lack of leadership came a lack of motivation. As a group, we started thinking, if no one else is doing anything, I don’t want to either. If I turn around and do everyone’s work for them, then they will keep avoiding their work. At least, this is how I felt, with good reason, as this is what happened in my last project. This was one of the main reasons why I did not want to become project lead. We also had KPI feedback during the project, with some bad news adversely affecting some of our team members. I tried to cheer them up, suggesting things they could do to help them achieve their goals, but it still affected their workload. Not much could be done about the general lack of motivation, as it meant that team members would not log into skype, or decide to leave the team early. I have noticed that team members throughout our core team and also collaborators that were not a part in any team building were much more likely to leave early or be affected more by lower moral and motivations. This may be subject to confirmation bias, so I hope to further test this in future projects.
So how do you encourage motivation in your team?
Get your team to feel something about what they are creating. Get them to share a story. Create a focus on the progress of your project. These are the things that went right with the animator team on this project. I described the story, explained to them all of the things that would excite them about the project, showed them the progress of the project, and their effects upon it. I kept them on track, ensuring that they knew about their deadlines, which they set for themselves. If anything was behind, everyone knew about it, but instead of shaming the person who had fallen behind, we instead looked into finding out why it had happened, and what could be done to fix it (this is how the task swapping came to be, as one of the team members had not provided concepts. I found out it was not due to laziness but because they felt they were very bad at it).
While the animator team was managed pretty well, The programmers and designers did a terrible job at it, which was terrible, as everything went wrong and even some simple time management would have given us a chance to reassign tasks and correctly identify when the project needed to be scaled back. This issue with time management is one that I have had with every group project I have worked on. It’s the first thing that needs to get done, yet is often the last, or just never done. It seems to happen because of different reasons each time, this time, it was because of sickness and lack of communication. due to not being able to get the team together in a group, we felt we could not complete the HCD and other documentation in a fashion that would satisfy the whole team, and without that we had no clue on what the actual task breakdown would be. To be honest, the only way I can see this getting done is by locking down the team in a 12-hour face to face meeting during the first day or even week, to knock out all the basic documentation and a crude task breakdown, which would immediately get set up into the rough Gantt chart. From now on, I will not settle for any less in a group that I work in.
Lack of skill
I have a problem where I assume that any task that is currently outside of our knowledge is simply solved by adding research time to the task. The issue is that most of these tasks are being completed early in the morning, and the time required to comprehend and solve the issue is much larger than anyone ever applies to the task. I had an issue with trying to find if an object is currently being rendered within the view frustum. I ended up creating planes to visualize where these planes actually were, and they were rotating all over the place as I looked around the scene, so I knew so little about it after hours of working on it that I could not even set up a debug to correctly visualize it. This lack of skill also meant that tasks that were worked on for hours had to be reassigned to someone else, taking up their time too.
In future I would definitely limit the amount of tasks that sit outside our current bounds of knowledge to a minimum, and focus on creating the documentation like a TDD as early as possible, to help identify gaps in our knowledge.