Sticky Situation: Post Mortem

Over the last 4 weeks I have been working in a team to create a game called “Sticky Situation”. This project had things that went well, but also some things that didn’t go well. In this post-mortem I will explain what happened, why these things happened and how it can be avoided in the future.

Good

Animator Collaborators

Our team was lucky enough to be working with 3 very talented animators to help us create 3D models and animations for Sticky Situation. Learning from previous projects, I knew it was important to have a way to contact our animators as early as possible in the project. Our team did this by creating a private thread on Slack that we added the animators too. This allowed our team to keep in contact with our collaborators and allowed our animators to keep us updated with how the 3D models were coming along.

Scheduling

The schedule I used consisted of the task, details on the task, the person or people that would be working on it and the estimated task length. It also had a progress meter for the bigger tasks and a column to represent whether it was completed or not. This allowed my team to see exactly what each person was doing, as well as having a clear representation on how much time I had to set aside for tasks. What this allowed me to do was spread my workload over the week rather than rushing to get tasks finished the day before it was due. To improve this scheduling in future projects, I have to start scheduling from day one, rather than a week into the project.

Bad

Communication

Communication in this project was not sufficient. Within our team, there was some communication through the slack thread and through our schedule, but we could have benefited from more communication such as team meetings and skype calls. To keep a project on track, the team needs to communicate effectively both in person and through other mediums. This can be done by scheduling a meeting, either as a conference call or in person, to discuss the work we have been doing, and what work needs to be done. This would keep the team on the same page and allow everyone to focus on important tasks and share tasks if needed.

Game Design Document

Our teams GDD wasn’t thorough enough to be able to properly refer back to it if we were confused about something. This was because our GDD wasn’t properly kept updated as we were planning and developing the game. This document could have been used to its full potential if it was properly updated to match the progress of the project. In future projects, the GDD should be updated regularly and changed depending on the way the project is pivoting. This will allow people working on the game to refer back to it if they are unsure about something.

Art Bible

The art bible was not in depth enough to allow the animators to refer back to it if they were unsure of the style of the models and materials they were making. This was because our team failed to update the art bible with the correct information on 3D assets in the game. The document contained information on the overall style we wanted in our game, but didn’t give insight into what assets needed to be created, and to what technical constraints such as scale, which we had problems with in the project. For future projects, when working with animators or artists, the art bible should contain the technical constraints for the project, such as scale, the style we require for the assets, and how each asset should look when they are submitted to us.

Technical Design Document

The TDD we used for this project had no where near enough information in it. This was because in the first pass of this document, there wasn’t the correct information in the document. After the first past, Ryan wen’t through and added all the scripts he would think he would need for the stuff he was doing, which made the document for usable, but it was still far from finished. For future projects, as soon as we start designing the game, the TDD’s should be updated accordingly with each script that will need to be written, and what each script should do. These scripts should then be organised into what objects they will be attached to. This will allow the team to visualize exactly what scripting needs to be done for each game object to work as intended.

 

Audio Collaborators

For this project we had audio collaborators on board to help us create an original track for our game. The issue was after giving them some information on what we wanted, we failed to communicate with them effectively. This was due to the fact that one of the audio collaborators was never present for the few meetings we had at the start of the project, and the lack of communication between our team and the collaborators. Another possible reason we didn’t receive anything from them was that we didn’t give them enough information on what we wanted. To prevent this happening again in future projects, consistent communication is a must.  A document that explains to the audio people the theme and feel that we want from the audio, as well as sample tracks that give the collaborators an idea on what sound we like.

In Conclusion

Overall, the project had a lot of things that we as a team need to improve on, as well as things I need to improve on myself. It is important to use this process to improve the outcome of future projects to help better myself as a game designer.