For this postmortem, three topics are going to be discuss. When i write these post postmortems i always try to include 4 main topics to talk about, although when thinking over my project all the events always lead back to three main topics. The topics that were the core of this project were: Good meetings, consistent iteration and poor documentation. When analyzing my previous postmortem and comparing it, I can clearly see that i have improved. More positive topics meant i took a different approach when thinking how i write my recommendations. I want to dissect them so that i can understand what went right and try and use this for the future.
A consistent amount of team meeting each week allowed the group to easily iterate, discuss ideas, check-up on completed work and fix problems.
Each week we would would come in about 1 to 2 hours before class and have a face-to-face meeting. We would have 1 to 4 Skype meetings each week. If we weren’t in a meeting we would be casually discussing topics over Skype using text. We had two Skype groups one for game designers and one for the whole group this included the artists.
Skype was a very productive way for our group to have meetings, everyone already had it installed and owned a microphone. At the beginning i missed a few meeting as they were very early in the morning. But it eventually changed to happen mid-day which was a lot better for the group.
To have consistent meeting it is very important that you use a program that everyone has and is easy to use. If everyone in your group has a microphone it is probably better if you use a program that allows for voice chat as a lot more can be discussed by word. It is also a good idea to have face-to-face meetings before class. Everyone is already going to be there showing up an hour early to discuss and work in person, helps both the project and your group’s understanding of each other.
Team didn’t spend a huge amount of time into documentation. We rarely updated all the documents. This meant if we wanted to do work it was better to have a meeting to understand what we were making instead of looking at the documentation.
Documentation happened a lot at the start but as the project continued less work was put into it. This is because we wanted to spend more time on the project, which is a trap i fall into often.
The documents did not have clear version control. This information could be found on the document itself thanks to google’s recent changes tab. Though a lack of clear documentation on this information meant it was hard to tell what had been updated, and what hasn’t been added. This caused updating the document to be a pain to change.
Update the documents as you work on the project, this way everything is getting added straight away although sometimes you forget or miss something. Make sure that you make a version control section down the bottom with dates, the name of who updated it and information about what has been added. This way you can put a version number at the top of the document to keep track of how many times it’s been updated and how recent.
The team changed the idea for the game and mechanics used a lot to try and optimism the game’s performance and meet the brief.
The game was constantly being changed, i don’t think there was a week that went by where we did not change at least 5 elements of the game.
Good communication and constant meeting meant we could discuss new ideas for the game almost daily.
To Iterate a lot don’t stop when the game is finished and done. Keep adding more to the game, changing and balancing weak parts of the game. Improving and expanding on strong key parts of you game, to fully send the message you want your game to say. The last thing i recommend is if you are in a group, communicate as much as possible. Everyone has different ideas and views, use this to your advantage. Make sure to at least have two group meeting a week.