Project C – Postmortem
In month nine, Team C has been continuing developing Project C. Project C is an isometric real-time RGP inspired by other games of the genre such as the Diablo series. The team consisted of three developers, two designers, and two artists. Both artists focused on making weapons such as swords or guns for the entire month, which I was one. Our three developers were all split between different tasks to try and make it simpler to integrate and manage. We had one designer. The entire project was developed using Unity as the engine, Maya as a modeling software, Google docs for any documentation, Visual studio for programming, C# was the language used, and Github was used for source control.
Overall, the development went well although there were some minor setbacks and complications. With all the issues within the project the team moved forward and the project ended well.
What Went Right
During the development of the entire project the team had amazing communication. We had meetings every Monday, Wednesday, Friday and Sunday. Even though I had never worked with this team before it was easy to communicate with and get my tasks. The entire team was part of the discussion where this project stood and where we want this project to proceed. This was an amazing thing for the project because it helped us flesh out the ideas, call each other out on what is going into the game and what changes we would make. This was important because there was not any bad and pointless mechanics going into the game without the entire team agreeing to it.
The team set the mood to the game in a previous month. The mood of the game was set to be a dark and horror feeling to it. The theme of alien attacking a fantasy country set to the game play of Diablo was captured perfectly.
The team was updating the game at every meeting with assets and new script. It was very easy to add in the swords and other weapons I made into the game. The team was on top of it whenever I had an asset ready to import.
What Went Wrong
To put it simply, GitHub was the largest issue we had in the first half of the class. The group had clogged up the GitHub and we had to individually upload every file in the game back into a new Github repository. Something we can do next time to avoid this issue is keep all our work in different branches so when we push it That won’t mess up the master branch. This mistake caused a pause for five days none of us could push our work into the game which became horrible set back.
We had a problem with some members of our team not properly logging bugs. It was difficult for the Devs to try and fix bug so we couldn’t get to everything to a working state by Sunday. Something we could do better is have a set document or program such as, Jira, so the Devs and bug testers can work together and not be in their own worlds during production.
The team had a problem with updating our time sheet and work log. This made it hard to tell how much time each person had done. I believe that the team was working on their task and at our meetings everyone presented their work. However, I believe in the work environment there is no way to tell if we actually had our work done due to our sheets where never filled in on time.
Overall, the project was a success. The game did operate as we intended by the end of the class. Even with the many setbacks the team suffered the product is operational and properly portrays what the game is and how it is played. The team proved they can make this type of game and learned a lot about what to do during the development and what to avoid.
Till Next Month,