Midway through the project, COVID19 reached the UK and the University of Southampton closed its doors shortly before the whole country went into lockdown. This was, obviously, not ideal for a team of three working on a final major project. Luckily, Sid and I live together in Winchester, but Kerris went home to Essex, meaning we were all working remotely.
To tackle this newfound working situation, we made some changes to our work process to help us stay connected and on track.
Daily Stand-Ups
Whilst we were working together in the same studio, we were already doing daily stand-ups, though less officially. Being in constant proximity to each other meant any time there was an issue or change of plan or something that needed to be done, it could be instantly communicated. That said, our stand-ups weren't scheduled properly and oftentimes wouldn't be done properly, as the classic "yesterday I did ___, today I'm going to be doing ___".
Using Slack, we decided to set a time for these stand-ups to happen every working day without fail. This was done initially for the benefit of Kerris, as Sid and I have an office that we work together in, and can communicate at any time to each other. We noticed in the first couple of weeks, however, that our communication as a team was suffering because we were only relying on updating each other whenever we felt it was necessary via message on Slack. So instead we began calling every day, sometimes lengthy conversations where we discussed big issues about the game, sometimes calls that lasted literally 5 minutes where we just gave each other the run down of what we were doing.
I think doing this raised spirits, we could hear each other's voices and properly chat like we were in the same room. It also helped me personally to be more accountable, I wouldn't stray from my designated tasks just because I felt like doing something else, because I'd told everyone what I was going to be doing that day.
Priority Labels
The mental health of the whole team was affected by this massive change of circumstances, with our London arcade showcase being cancelled, as well as several events we had planned to visit. Because of this, motivation initially fell a little short, and as a team we stopped being organised about working on high-priority tasks to the extent that we lost a little bit of time faffing around with things that weren't strictly necessary.
To tackle this, we sat down as a team and reevaluated what the most important things to be done were. I created custom labels on Trello that could be attached to tasks: Red for high priority, yellow for medium priority, green for low priority. These were in the context of the progress of the whole game, not individual task lists. Doing this helped give a visual cue to keep us all on track with what we were doing.
Animation Test World
Towards the back end of the project the priority process got out of sync. Kerris and I had completed the bulk of our urgent tasks and were moving onto smaller ones like animations and sound, but Sid was still working on creating the main three book mechanics which was heftier work and took significantly longer. The issue with this was that we ended up in a situation where Kerris couldn't continue work on her animations without having them tested - this was high priority on Kerris' personal tasks, however it was low priority on Sid's tasks, and taking time out of doing the main mechanics meant that he was starting to fall behind schedule. It was Adam's idea to create a test world separate to the main build where the animations and other things could be tested. As the team member with the lowest priority workload, I took responsibility for the test world, testing the animations whenever they came in. This meant workflow ran smoother - Kerris was able to immediately respond to feedback on the functionality of her animations whilst Sid was working on the main bulk of the game.
To accompany the test world, and to streamline feedback, I created two spreadsheets: one for Kerris and one for Sid.
Kerris' spreadsheet contained information on whether the animations were functioning properly, and if necessary, if different objects were working together. This was a fairly binary system, with simple yes/no's as to whether things worked, however I knew that wasn't enough to help Kerris fix the issue, and so I made a notes section in which I could describe the issues with the files so she knew what the problem was. At the beginning of the process I made a comprehensive list of things that needed to be included or excluded in every file: for example, having cameras and lights in the animation file translated to extra work for Sid later down the line when he had to import the files and delete those components.
Sid's spreadsheet was definitive information about whether the animations needed to be looped in game and what speed they needed to be played at. There was also a note section for anything not easily explainable via these methods.
Employing these methods and techniques meant that creating the game ran much smoother. Each team member could work to their highest priority tasks without pulling someone else away from theirs, meaning version control in terms of the builds that were put out was really consistent.