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
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.
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.
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?
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.
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