Meowder Mystery Post Mortem

Meowder Mystery: the purrfect crime is the result of our teams pivot for our Remembrance project. We were finally made aware that Remembrance was a terrible game that had only run into issues and would completely fail at its main objective, to make someone feel a connection. During a class, we had a lot of fun playing around with the idea of instead having the player control from the perspective of a cat, that would display subtitles for it’s meows. For now, though, let’s go through everything that went right and wrong during the production of this game.

What went right

Pivot
Boy did we pivot. Our game went from being a story about a father’s battle with depression and grief after the loss of his daughter, with the player being able to affect the trajectory of the father’s battle through interactions with objects in his memories, all wrapped up in a VR experience to a story about a cat who must uncover clues to solve the mystery of its dead or missing family through questioning and abusing inanimate objects, without any VR. This was made fairly simple by building the game around the assets and scripts that we already had available. Due to the general behavior of the scripts being very close to what we needed, a lot of the changes that we needed to make was the removal of a lot of the code and only had to set up a few smaller codes for things like the cat idle animation (when you are holding an object).

I really wish we were working on this game weeks earlier, this problem stemming from our team latching onto a single idea at the beginning of production. There was a mix of some members not being open to other ideas and not many other ideas being available (possibly from the first idea involving a hospital to explain the no player movement constraint) To help avoid this in the future, we really need to push each team member to create several ideas for the game and in a brainstorming session, go through each one, build it up and identify the best parts of it, then pick the best one and pull any brilliant parts out of other ideas and work them into the best one, if possible.

After that, there should be a way of getting outside perspective into the project as often as possible, to help identify any areas that are just not working, like playtest sessions. If any of the feedback hits on one of the areas that are in the core brief (like people constantly asking how we expect to make the player feel anything for the daughter, our main point of connection) then that may be a good time to pivot the whole game.

Do not fear pivot, it sounds like you have to start from scratch, but that’s not true. Many of the assets and scripts can very easily be repurposed into almost anything with very minimal effort. Trying to keep most or all these things in the new pivoted game is also a huge amount of constraint, which is very healthy to the design/brainstorm process.

Collaboration
This is something I went over in my previous post-mortem, before we hit pivot (found here), and went over in greater detail why our collaboration team worked so well (here). To recap though, I basically set up a cheap and nasty version of what was required for our production documentation for the collaborators and held skype meetings every night at 8pm, to ensure all the work required for that day had been done. To improve upon this should include bringing the collaborators further into the production process. I think this should be made as easy as possible for them, as a lot of time spent on figuring out these complex structures may discourage them from joining in, but I mean this in a ‘user experience’ kind of way, not a ‘don’t include them in the work’ kind of way.

Meetings
Our team mostly did a decent job at meetings, we got into regular skype calls and stayed online to help or support each other during production hours and to help ensure work was getting done and each member was on the right track with each task. It has been brought to my attention that these skype meetings sounded like a waste of a lot of peoples time, but a lot of development happened during these calls and they were also comforting. They tended to help people get work done and ensured that others were working. They allowed people to just ask any questions, as they cropped up in people’s head and also helped deal with any working blocks as soon as they arose. This also helped build a team identity, when work needed to get done, most members were more likely to put in their working hours when it felt to them that the whole team was doing the same, that we were all putting in the effort.

While this felt very positive, it is important to also make sure that our use of time is as efficient as possible. These meetings should have started off with a structure to them, for example, go over the work that had been completed since the last meeting and identify its successes or flaws and how to improve on them, ensure that tasks are being met and go over the next set of tasks that are due. These could also include a time for taking a step back on our project and taking a look at its current state. Is it still meeting the brief? are our time estimates still falling within the deadlines? are there any blocks or risks that we can forsee? Has anything cropped up amongst the team members that will shift the pipeline or timeline? Are any team members failing their duties and if so why and how can we fix it?

Better management
When we pivoted our game, one of the main issues we identified was poor leadership and a lack of availability from a few of our team members. Before the pivot, we were strung along with the completion of the production tasks, such as the Gantt chart and risk management. As a team, we failed to recognize that this was not actually being done and needed to be shifted onto someone else. There was also a large amount of sickness and other blockers in our team and with little to no management, this brought our production of our game to a halt. We did eventually get back on track, but our game was about a week or two behind where it needed to be, which we failed to really identify or act upon. After pivot, Harry and I took on the tasks of setting up our production and team management, also designing the pivoted game to be completable by the three people who were regularly available to work. We should have spent more time maintaining the tasks list and Gantt chart that was made up, but defaulted to reporting and assigning tasks over the skype meetings. These verbal task reports took the form of the ‘current three most important tasks until the game is done’ model, outlined in class, but followed the general task list set in the GDD.

This better management was able to take into account the needs of each member, like time to write their blogs, ask for expected availability and set tasks that should fit into that time slot.

The game was playable
This was due to the pivot of our game having a decent way of keeping the scope in check. We kept the ‘crucial’ parts of our game to a minimum and had as many non-crucial elements as possible. This way, if they did not make it in, the game was still playable. This should be taken into consideration right from the start of the project, as the only way to deal with a loss of working hours due to sickness or other risks is to use any flex time you have set up for your project, which is unrealistic as most people in the team will have to sacrifice other things like projects or home time. No one wants to be forced to work till 7 in the morning on a project because someone else couldn’t make it in. This way you can start cutting out the less important parts of a project and still be able to provide an MVP. If you do find you have extra time, this means you can even bring back in those non-crucial parts that were cut out, or even the extra stuff you thought wouldn’t make it in. This also allows you to structure and set up tasks for the project once MVP has been met, rather than lose your team’s interest in working as their work is ‘done’.
In saying that, you have to be able to create an MVP that takes next to no time at all to produce, in the off chance that you lose the main amount of working hours available. This is done by building up the idea of your game and then cutting back everything you can while still being able to call your game a game.

What went wrong

Time management and production
When we started the project, tasks were handed out amongst the team, and the project lead took over the task management job. A confusing spreadsheet was set up to use, and we were told to fill it out. This never happened and needed a full team meeting with direction on how to fill this out and needed to be kept up to date, most likely through daily meetings that went over these tasks, to identify what was getting done and what was missing. The team was soon struck with sickness and indifference towards the project and this was the last effort to be put towards the production management. After this our meetings were mainly focussed on arguing over design elements of the game and a couple of weeks in, we started working on seriously working on the documentation of the game, including taking meeting notes and setting tasks in those notes. It was brought to the team’s attention that the Gantt chart had not been set up, so we allocated meeting times to generate the task lists for the chart and were assured by the team lead that the documentation required would be set up asap. Not getting a deadline for this meant that we never knew when the task should be completed by and in our heads, all we could do is ask about it the next time we got a chance to talk. We did not want to do it ourselves as we were already overloaded with tasks and the production management tasks were a huge amount of work. It felt wrong to complain about it, as we were being assured that it would get done and the person who was working on it was providing other work also. To bring this up with Tony or Steve would be the same as stabbing them in the back as we didn’t know if it could adversely affect them.

I myself ended up spending way too much time into trying to make a VR device work on my laptop, to no avail. This was critical choice for our game, and had affected the way we designed the systems and the MDA of our game. Not being able to get this to work was very disappointing but was not removed from the game till much later and this possibility did not even make it into our risk assessment. If this task was managed correctly, it would have been a non-critical task and only had a few hours dedicated to getting it to work.

To avoid this, the main thing we need to do is correctly identify when a critical task is not being completed much sooner. Every task needs a deadline set up when it is assigned and this needs to apply to the initial production documents creation. This will allow to sooner identify a failure to complete and allow a task to be reassigned. The set up of a project needs to be treated so very carefully, as the last three projects have completely failed to get any production documentation like the Gantt chart due to someone or something falling through and no one else realising that it hasn’t been done until it was way too late for it to be of any use at all.
To help assist with this, face to face meetings and skype meetings should be going on for most of the early project, so the whole team can be a part of the creation of the game, helping avoid a team member not knowing what the game is and allowing task breakdown notes to be generated during.
Good team management is what is required for this to be completed successfully, described in this blog.

We also needed to maintain our production documents. This did not happen due to them not being set up until way too late in the production cycle to be of any use yet again, but I have seen this work correctly with the animation team task reporting. This worked as it was set up to allocate tasks, deadlines for each task was assigned by the individual who was creating the object, the document was dynamic, able to change to suit the needs of the users (adding in a task swap section so that broken down parts could be handed over to someone who was able to do it) and the document use was managed, due to going over the current tasks that were due each night. This exact setup with a Gantt chart will allow for its maintenance and usefulness. Setting up a Gantt chart at the start of a project will also allow for it to be used and maintained.

Poorly assessed and managed risks
While we did eventually get a risk management document, it was well after we suffered from most of the worst risks defined in it. The reason we didn’t have this set up is explained with the time management and production issues, but this is a document we have created before and these risks are common. We were not ready to have half the team go missing and were also unaware of the consequences that that would have, namely the healthy team members losing interest in doing any work for the project. This happened due to the realisation that we would have to pick up their tasks after we had already had a huge amount loaded onto each of us. We also no longer had the whole team available to bounce ideas off or work through the game design with, so we could no longer make team decisions. I myself did not want to work on the TDD without my team of programmers, as I was not aware of their capabilities and couldn’t tap into their ideas of how to set certain systems up.

These risks should be set up at the start of the project and maintained. Meetings should include a time for attempting to foresee any future issues, possibly with tasks that require research and the chance that they may not come to fruition.

Audio
For this and other blogs, I have been talking about how strong our collaborator team management and the team themselves were, but I have not taken into consideration our audio guy. He was absolutely fantastic, I asked him to work through our timeline setup for the story and plan our the audio feel and planning, which took him a few hours to do, and a week later he provided his concept work for us to put into our game. This was about all of the contact that I had with him, a failure on my part to set up meetings and task management with him. This meant that there was no iteration or polish on his work, and we failed to put anything he had provided into our game or even tell him about the pivot.

We also had the issue of leaving our audio till last. This is mainly an issue with the production documentation being left until too late and not being able to identify that it wasn’t being done. We didn’t have anyone in the team who was particularly interested in the music, so it was left until last.
Once again, this should be fixed through production documentation created at the start of the project, rather than at the end.

The management part is fairly easy to handle in the future, just manage the audio team in the same way that I managed the animator team. I did not include him in the animator collab meetings as I felt he would be spending most of his time listening to information that did not affect him, but I did not realise that this meant he lacked a team identity and was not able to have his efforts presented to the team, he would get no recognition for his work. Even just sitting in would allow him to generate a better understanding of what the game was, through seeing what it looked like, and showing his work would give the animators a better idea of how the game was meant to feel. This was a terrible choice on my part and one I should never replicate again.

 

To be better in the future

• Start a project with role assignment.
• Ensure that multiple ideas are brainstormed
• Get task notes during documentation generation
• Create a Gantt chart as early as possible
• Work as a team to generate tasks for the Gantt chart
• Have constant team meetings until the production documents are created
• Set up repeatable meeting topics, and have very regular meetings
• Do not segregate disciplines, the work they provide helps define your project
• Minimalize the critical path and pipeline
• Make your project modular
• Pivot early

 

Bezier Spline tool!

Here is where I found the tutorial to help me make this

Here is the repo link containing the Unity Package

This is what I learned while making it
First of all, I need to thank  Shaun Allen for helping me with figuring out how to export a package in unity, all you have to do is download a single file and import it in Unity, exporting has an automatic dependencies option, so you just select the main scripts and/or prefabs you want and it also selects anything else it requires to run. It’s good practice to remove anything that is not critical and include instructions on how to use the tool, especially a video tutorial. You should bury anything that isn’t used directly by the user, and ensure you set up useful folders and names. Also, comment your code! If something doesn’t work, or someone needs to change the scripts to do what they want, you can save a lot of time through commenting what everything does, what it talks to and why, and this will also help people learn how to set this sort of thing up themselves. I haven’t set up any comments in this myself, as this is the first time I have created a tool and the script itself is fairly complex, I still need to work through everything to fully understand the inner workings, so keep an eye out here for an updated version in the future.

In doing this, I learned a few things about creating tools in unity, like GUI functions and how to create an editor panel. Enabling the use of ctrl+z, and getting unity to ask if you want to save your changes when you try to close it after making changes to the spline. I even tested creating my own contextual buttons, which worked but had trouble with the script itself (I was trying to insert points to the middle of the array of points, but there are a few arrays that stopped functioning correctly, this is why I need to work through it again)
I was also made aware of other types of curves available other than bezier. The problem with a bezier curve is that to shape the curve, you need to pull its point around a lot further out than the curve sits, the problem here is that the curve never intersects a point, and is, therefore, difficult for a person to use.
The scenario would be that the curve is being used as a path for a camera, which needs to hit a very specific point or even several. On a Catmull curve, for example, the curve intersects each point which are what gets placed by the user. This is very precise, and the tool I created also does this (as this is a spline, every 4th points is intersected by the line, with the two points in between controlling the curve of the path). To control the curve, there are two ‘rotation’ handles surrounding the main handle, this is what controls the angle of the curve and speed of movement along the path.
Here is the maths behind a bezier curve. We should be using a simplified version of the cubic bezier curve.

Things I learned from playtesting the tool
The tool controls are fiddly. If you click off it, it deselects, which is some bad ‘player feedback’, and is too easy for this to happen as the handles on the tool are very small.
The handles need to have an adjustable size, this way people can decide what works best for them, as if it is too big, it will obscure too much of the scene it is in.
Its a little hard to know how to use the tool right from the get go, as it requires several scripts on separate game objects. this is mainly run through in the instructions, but thats also a wall of text, no one reads instructions anymore. A good way to fix this is to create a prefab on the top level of the hierarchy, to easily pull into the scene a working example of its functions, a demo scene of all the cool things it can do, and a tutorial video running through the correct set up of this scene.

 

 

The juice in Blossom Blast Saga

 

SO, what is juice? well, it’s what puts the ‘spring’ in Springfield. check out these amazing presentations on what it is and why you need it

 

 

In Bloom Blossom Saga there is an amazing amount of juice, but before I break down each specific part, I would like to talk about my favorite one, the cascading effect. What I mean by this is when you burst one flower, and that bursts another flower, and so on. This is one of my favorite things to experience, reminding me of stacking the huge LRM40’s onto a longbow from the old mech warrior games.
This ‘reward cascade’ Is why gambling machines don’t pay out all at once, instead slowly spurting out each coin one by one, so that winning 20 bucks feels like the best part of your day. It’s why the game has a chance to give you 20 free consecutive auto rolls, rather than just adding 20 to the amount you have left. It starts up a fanfare, adds in a multiplier. It does all of this to make your small input feel as though it has a huge effect on the game space.
Its some extremely powerful feedback to the player, I think it fits in well with the player feedback loop described by Jan Willem Nijman, the idea that is created in the player is the feeling of a heavy effect from their actions, from the creation of a domino effect, or cascade.

Another reason that I know this is the main goal in the game is their trailer on the google play store (here is an example)

As you can see, it is the main function that is shown when advertising what their game can do, this is the core player experience.

Now, let’s break down all of the juice that can be found in this game

flowers fall down into the scene in rows, this feels like a really quick sand timer, but offers order and pattern.

you make a line of flowers, they make a burst and a sparkle noise, burst into a puff of petals and glitter, each regular flower is replaced except the one you end on, which grows in size, and matures. the new flowers fall into place around it, and each flower that moves also ‘bounces’ while moving

when selecting flowers, there is a nice, slightly punchy sound of (maybe hitting a patch of grass?) to let you know you selected something, but the whole game freezes so you know you are having an effect

if you line up heaps of flowers, the final one grows into a huge flower, through several stages, each one making a punchy (bursting plant) sound, kind of like a wet tree snapping a bit. This flower bursts into heaps of petals, with extra sparkle noises, and a success bling noise (that rises in pitch with each successive flower grown to this state triggered in this chain)

If the player sets up a particularly large combo (not chain) then there is a (bright lights getting sucked inwards) animated image overlayed under the players finger

Oh man, if you combo a bunch of flowers (like 7-8) in one shot it explodes a super bright light outwards, with an even more blingy bling noise, rays of light shoot outwards across the screen and all the flowers around it are brought to full maturity, setting up a huge cascade of flowers bursting, nearly entirely wiping the whole board, all building up the pitch of the bling sounds and covering the screen with bursts of flower petals everywhere! this would be the perfect time to have the phone vibrate, if available.

there is a cavalcade to announce the ‘final flower’, which automatically clears the board for you, and plays a bright and uplifting jingle for completing the board. It scrolls up the screen, tells the player they are awesome, tallies up the score, adding huge points for bonuses, and then tallies it up again dishing out a star rating based on the score (while playing another bling noise for each hundred points as it tallies up)

These are the Audio and Visual feedback systems found in this game. Each one is added to the game to make the player feel as though their actions have an even greater effect on the game, a consequence (though not necessarily a bad one). This makes the player feel as though their actions have weight, this feeling is the ‘idea’ placed into the player and is what makes the game have a lasting effect on them.

Another awesome game by King is Farm Heroes Saga, and I want to talk about some juice they put in here to make the player feel like a super smarty pants. When they tally up your score, instead of adding a couple of zeros on the end of the points you actually get (which in itself is pretty amazing) They actually give you a completion percentage. Which they allow to go over 100%. This means that, given you meet the reasonable target set in each level, your efforts are rewarded, by telling the player exactly how much better they really did. It lets you know where the expectation bar was, and allows you to hit scores like 500%! With a normal scoring system, you either have no way to gauge exactly how well you did or have to do mental backflips to figure out the maths (or worse yet, are pitted against your friends who have no life and play this game 24/7)

Meowder Mystery dev blog

Today I have been working mainly on maintaining and polishing documentation, updating older information or task charts, and updating the object task list and allocations. I’m pretty glad about how my object task allocation sheet was set up, cause it made updating it very easy and despite the huge pivot our game took, was still very relevant.
When I say huge pivot, I’m not joking, the entire premise of our game has changed. We are trying to keep as much of the assets and code already made as possible, so it’s still essentially a sit, point and click game, but the player experience is completely different. Instead of trying to get the player to connect to the characters through well-designed characters and a shared understanding and experience of grief and depression, we now are trying to connect to a player through a shared understanding and experience of cats are jerks and that a mismatch of themes is funny.

I also tidied up a script for a team mate, quickly fixing some small bugs and linking their script to the director script. The bugs were mainly small spelling errors and trying to access a variable that did not exist in the Director script yet, so that took like 5 minutes, and I was easily able to identify what was needed as we worked together to plan out the entire script in our TDD.

I pulled out all of the old lines of code that were no longer needed out of the director, and tonight I plan on finishing its functionality. This was pretty simple also, due to planning in the TDD and I just had to tie up anything that was relying on the variables or functions that were removed (anything relying on them were set to be removed also, anyway).

All in all, a fairly busy day of documentation. Happy Birthday to me!

How to effectively build and manage your team

Why do you need to do any of this?
Team building is a difficult task to accomplish but is essential in the creation of a quality product. A team of people who have become invested and passionate about a project are more willing to work harder and more likely to provide a higher quality of work. They will also make your life a lot easier, being more likely to follow through with task deadlines and make themselves more available for you.
In our instructions of how to report on post-mortems, we were instructed to avoid describing successes as “try to work with ‘Bob'”, Bob being the one person on your team who pulled the whole project through and made everything just… work.
Team building is essentially turning every team member into a ‘Bob’.
The aim is to generate a passion for the project in everyone working on it. Create a strong emotion for the project in each team member, as emotion is an insanely powerful driving force. It is what advertising aims to do in only a few seconds and is so powerful that there is a whole industry behind it. Here is a quick explanation of how that works. You don’t need to use these particular techniques to get your team to feel anything for your project, but you do need to sell it to them, this is why we have pitched to other students to get them to work on our teams, rather than having them equally assigned.

You don’t need to use these particular techniques to get your team to feel anything for your project, but you do need to sell it to them, this is why we have pitched to other students to get them to work on our teams, rather than having them equally assigned.

 

Be a good leader, above all else.
There are a lot of resources available on becoming a good leader, however, most of it will seem disingenuous.
The main points you should focus on is avoiding hypocrisy, delegate tasks equally, be aware of the needs of your team members, be positive, avoid shaming and know (and have passion for,) your project.

Always remember that these team members are people, not resources. If they have failed to complete a task, it is most likely your own fault, for not understanding why they could not do it and working out a solution.

Team building
Yet another well-known subject that is commonly mocked or treated with disdain. Most situations in which you may have experienced this will be some horribly artificial ‘team building task’ and you may find yourself rolling your eyes at just the mention of this. You do not want to create this situation yourself, as it will do very little to help build a tightly knit team or a passion for your project.
Instead, the entrance into a team building exercise should feel very natural, like simply allowing for the forming of a conversation. At the end of meetings, I did not close off the call but instead asked people questions about how their other projects were going, or their interests.

As a team, we played around and made jokes, learned more about each other. This also helped to find out about specific tasks that each member would excel at or struggle with, allowing for task management procedures or management styles to evolve into what was needed to effectively look after my team and ensure tasks were being completed.
Some of the team also took part in a ‘multiplayer drawing session’ using the google draw tool. As a team, we had a lot of fun together and developed in-jokes and a team identity.
The team members who were involved in this told me that they felt much more a part of a team after this session than before, and had a greater interest in not ‘letting the team down’
That is the main goal of team building, exercises or strategies.

Task management
The main issues with setting up a task list or breakdown that I have come across is the insurmountable task size of breaking everything down, allocating time and resources to each task and somehow divining all of these required tasks before the full requirements of the project are realized. I am mainly not fond of Gantt charts and would not wish them upon my worst enemy, let alone the new bonds forming amongst a team of people who may not have met each other yet.

What I found to be successful was to create a more ‘general’ task list, that did not require full completion within its conception for it to be useful, instead relying more heavily on its iteration and upkeep. Due to it being set up in a google drive sheet, it was also available to each team member to update their own tasks as they were completed, rather than one person needing to spend an hour every day updating everyone’s tasks.

Everyone was allocated to each of the tasks, and required to assign their own deadline and estimated time, so each of these tasks could be transferred into a Gantt chart when available.

It did not require each task to be broken down into separate tasks, but allowed for that, and also allowed for these separate tasks to be swapped out between team members, but left the person originally assigned to the task culpable for that swapped out sub-task in charge of keeping track of the work (this divided the job of tracking task completions down amongst the team. the sheet kept track of these changes, making it simple for each member to remember who was working on what)

Regular meetings
Regular meetings are very important, they should be scheduled out and everyone should make themselves available for them. Plan out topics, structure your meetings, as this will help your team feel as though there is structure throughout the entire project.
These meetings should be used to go over tasks that are due and find out any developing blockers like required research for lack of skill.
This time can also be used to show to each team member and the team as a whole, the effect that their work is having on a project, for example, my team of animators were creating all of the models required in the game, so I showed them where their models were placed in the game, so they could see how they looked in engine, what they were being used for and how they affected the scene overall.

This should help give closure to the team member, seeing the culmination of their efforts and getting a chance to sit in the spotlight, allowing the team to give praise for their hard work while also incentivising other team members to put their best efforts in for their own work.
Not all people will wish to share this spotlight, though, so you need to identify as early as you can those who would find themselves uncomfortable in this scenario, so you can quietly praise them.
This also sets up a good environment to provide feedback or ask for changes that are required in the task, as team members should be in a generally good mood.
I had my meetings set up for every night at 8:00 pm, so I asked my team members to set cascading deadlines for each of their task milestones, this way several members will have completed some part of their tasks for each meeting. This helped to keep a positive attitude amongst the team and also allowed me to spread out the task of confirming that each task was completed and determine if it needed any further work, rather than having to do everything at once. It also offered more control over scaling workloads up or down and gave me the ability to reassign tasks before their group of tasks were due, so I did not find out something was not completed after they were due to be put into the project itself.

It also offered more control over scaling workloads up or down and gave me the ability to reassign tasks before their group of tasks were due, so I did not find out something was not completed after they were due to be put into the project itself.
Remember that this is not a place for public shaming, nor should that be any part of your management structure. You may find that some team members are either not completing tasks on time or at all or their provided work is sub-par. This needs to be handled carefully.
You need to ensure that they are aware that their work is not good enough while focussing on finding out what the problem is and fixing that. The best way to help is have the team work together on finding a solution, like swapping out tasks or offering help or instruction on how to better complete the task.
Remember to ensure that everyone is aware of their responsibilities and the next tasks that they are due to complete.

Do some research on team building techniques, like exercises or find the standards of successful businesses and the stuff they do to get their team members to get more invested in their projects. What about you? have you been a part of any great (or terrible) team building exercises? share your experiences in the comments!

 

Post Mortem of Remembrance

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.

Documentation
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

Sickness
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).
Time management
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.