Those who have read my previous posts will know that I've been working on a 3D puzzle platforming game names Stitches for the past few months. Now as this project comes to an end I would like to reflect on my role in it and how that role was different compared to that in other projects. I hope to look back at how my team has functioned and how well I served my role in it. Please note that in the future I will also be doing a reflection on the growth to my personal abilities as a developer but in this blog I will be focusing on my place in the team and the overall workings of it.
From the start of this project It was clear that this team and my role in the project would be much different from what they were in the past. In total our team was made up of one producer, two artists and five designers. It should be clearly evident that this team was unbalanced in abilities. The most glaring omission from this composition was the complete lack of a dedicate programmer. This was the first big hurdle that our team had to overcome. Ultimately another designer and I volunteered to take a minimal role in the design work of the game and serve as the games primary programmers. Though programing was not our specialty we volunteered as we had a better knowledge of it then the rest of the team.
This was the first time on a major group project that I had served as a programmer. In the past while I had assisted the programmers in my team when required it was never my primary role. This meant that learning new things and adapting to new situations would be crucial to my success as a team member.
This experience taught me the importance of adaptability on a team level and a personal level. On a personal level I learned to be prepared to take on different responsibilities than I am used to in order to make the game a success. I also learned not to be afraid not being fully versed in these responsibilities as learning new things is necessary for any projects. At a team level I learned how necessary it is to adapt the vision of the game to the accommodate the team's dynamic. In our initial prototyping we over scoped on various technical elements of a prototype. This lead to that prototype not turning out successful and made it clear that if it went forward it would fail. Find a balance between personal adaptation tam adaptation was essential for the success of this project. In the future I will always be keeping in mid the balance between personal adaptation and team adaptation going forward.
The team's second biggest hurdle was choosing an idea to begin developing and in a way this proved to be our biggest failure. We decided to do a prototype per sprint for three sprints (our sprints were seven days long) then at the end chose a concept to work on for the remaining nine sprints. Instead of taking a concept and running with it like we should have done we began overthinking each idea. We would refuse to start development on a prototype until each element was fully thought though. This would often mean that we could not begin development till halfway though the week. It goes without saying that this put the actual creation of a prototype on a very tight schedule. Have you ever had to code half a prototype in one night without sleeping because you other programmer had personal issues? It's not fun.
In future project I will be encouraging my team to trust the iterative cycle more. I hope to lead my future teams towards focusing on the core of a project during the beginning. Additions outside the project's core should come though iteration overtime. Attempting to plan a project out fully at the beginning not only wastes valuable time but also closes our minds to new possibilities.
Kommentare